 Important: |
|---|
| This is retired content. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. |
Microsoft Corporation
April 2000
Summary:This document contains frequently asked questions about Microsoft Windows CE 2.1. (20 printed pages)
Contents
Core OS
In the Microsoft Windows CE version 2.1 operating system, we're
planning to add support for the following processors: ARM 720T,
SA-1100, VR4111 (in 32-bit mode), VR4300, and Sh1. All of these
chips are undergoing thorough testing in our OS Lab and our ability
to ship them is dependent on their successfully passing rigorous
testing of the hardware, compiler, kernel and OAL changes, etc.
Various Application Specific Standard Product (ASSP) processors
will also be supported in version 2.1. ASSPs are subject to
rigorous validation by an independent test lab. Yes. In Windows CE version 2.1, both databases and registry can
exist in RAM, flash PC cards, or anywhere there is a file system.
The database is accessed and updated in place (where the customer
located it). The registry is accessed and updated in RAM. The
embedded customer can call Windows CE API to back up the registry
to persistent storage. At system boot, the location of the registry
is determined. If the registry is located outside of RAM, the
registry is copied at that time into RAM. Registry reads and writes
are made from the RAM-based registry. Yes, the FAT file system driver now supports FAT32 structure.
Previously, it only supported FAT16 and FAT12 structures. The maximum size of a file in the RAM object store has now been
increased to 16MB (from 4MB), which is also the object store limit.
However, because the registry and other objects are placed in the
object store, the practical limit will be slightly less than
16MB. Yes. We allow the use of other file systems. There is a new file
system wrapper that enables the creation of additional file system
drivers. Windows CE version 2.1 supports up to 256 installable file
systems. The CRT functionality has existed since Windows CE version 1.0.
In Windows CE version 2.1, the CRT functions are located in the
COREDLL.DLL module, instead of being in a static library. This
reduces the size of the Windows CE image and reduces RAM
requirements, bringing savings to both the ROM and RAM budget of
the device. For ISV/IHV customers, Windows CE exposes two functions to do
performance measurements - GetThreadTime() and
QueryPerformanceCounter(). Embedded developers and OEMs can use the
Instrumented Kernel that is shipped in the Embedded Toolkit. There are 3 mechanisms to support profiling under Windows CE
version 2.1 - a) Instrumented Kernel Profiling, b) Monte Carlo
Profiling, and c) Hardware Assisted Profiling. In version 2.1, we
provide a profile-enabled Kernel Library, called NKPROF.LIB, that
is used by both Instrumented Kernel Profiler (for KCALL profiling
and Object Call profiling) and the Monte Carlo Profiler. Both these
profiling methods allow OEMs to profile the performance of the
Windows CE Kernel and OS components running on the OEM platform.
The OEM implements APIs at the OAL layer that the Kernel calls to
perform profiling. These 2 methods also enable profiling from
applications by using the
ProfileStartand
ProfileStopfunctions. Monte Carlo profiling involves
interrupting the system at a high rate and recording the
interrupted address. By interrupting at a high rate, the samples
will give a good representation of what routines are taking the
highest amount of time. Hardware Assisted Profiling - Windows CE version 2.1 provides
API support for Process Level Tracking that enables an OEM to be
notified when a process or thread is created, terminated, or when a
thread is scheduled. The information that is passed to the OEM can
be used to perform additional functionality like Profiling. To
enable the functionality, the OEM must assign several global
pointers in the OAL, and the Kernel will use these pointers to pass
information to the OEM's Adaptation Layer. Yes, Windows CE version 2.1 added MessageBox options to the
registry that will enable support for displaying large MessageBox
in narrow screens. For example, the MessageBox() API does not
display the "
Cancel/Ignore" button but instead uses the "
Close/Cancel" (that is, X) button to achieve the same
functionality. This saves screen space when screens are narrow and
text strings are long. Yes. In Windows CE version 2.1, we've added Soft Input Panel
(SIP) technology. This is based on the Microsoft Palm-size PC
SIP/IM technology but has been modified to make it more generic and
useful to a wider variety of products. This technology was
developed mainly to support keyboard-less devices and provide a
common interface for ISVs on all Windows CE platforms. Yes. TrueType fonts have been available in Windows CE since
version 2.0. Yes, Windows CE version 2.1 provides support for Font Linking.
Font Linking is the ability to link one or more fonts called linked
fonts to another font called the base font. Once linked, code
points that don't exist in the base font, but do exist in one of
the linked fonts, can be displayed using the base font. For
example, font linking could be used to link a Hangul font and a
Japanese font to a Latin font giving the user to ability to display
both Korean and Japanese in the Latin font using Unicode text APIs.
It is important to note that font linking can only add glyphs to a
base font. In other words, it is impossible to override or replace
glyphs in the base font. We've have added support for an Input Method Manager (IMM)
module in Windows CE version 2.1. IMM is a module that handles
communication between Input Method Editors (IME) and applications.
An IME is a program that performs the conversion between keystrokes
and ideographs or other characters, usually by user-guided
dictionary lookup. Windows CE support is primarily targeted at IMM
support. A sample IME is provided for purposes of demonstrating how
an OEM would hook up their IME in a Windows CE-based system. The
Windows CE implementation of the IMM module is based on Microsoft
Windows NT 4.0 and Windows 95 IMM specification. Windows CE version 2.1 will be localized in World-Wide English
(WWE), Japanese, German, French, Italian, Spanish, Brazilian
Portuguese, Dutch, and Swedish. In addition, we are also providing
a better OEM localization model in version 2.1, one that is based
on .RES files vs. proprietary technologies. This makes it possible
for embedded developers to easily select and build an OS image
using the localized resources for their targeted language. In Windows CE version 2.1, we'll ship the building blocks that
allow customers to build an Embedded Shell tailored to the needs
and form factor of their embedded device. The building blocks
include console support, control panel and applets, common
controls, common dialogs, notifications (reminders, alarms), shell
API (e.g. ShellExecuteEx), and communication components. We will
not be shipping the H/PC Shell or any other shell application.
Questions about licensing Shells from any Microsoft Windows
CE-based products should be directed to Microsoft OEM Sales. Unlike Windows 95 and Windows NT operating systems, Windows CE
was designed to be used in many devices, with many different
capabilities. This will range from relatively general purpose
devices like the Handheld PC to devices which may not have any UI
or even a screen. Given that range, it is better left to the device
designers to design and implement an appropriate shell and/or
applications that make sense on their device and for their target
audience. The Embedded Shell, included in Windows CE version 2.1, does not
provide support for a taskbar. With respect to a virtual window
larger than the physical screen size, this is theoretically
possible via a custom display driver. As far as Microsoft is
concerned, this has never been done, so it's difficult to comment
on any problems an OEM would run into while developing this
driver. Starting with version 2.1, Windows CE includes support for
standard I/O routines (STDIO) and also includes a command processor
(CMD.exe). No. Windows CE version 2.1 does not provide a standalone
browser, nor do we provide browser functionality in the Embedded
Shell building blocks (see above for more about the Embedded
Shell). No. Windows CE version 2.1 does not support SMTP. We are not
providing an e-mail client as part of Windows CE. Windows CE version 2.1 supports Fast IR. We will be providing an
NDIS sample based on the National Semiconductors PC87108 and the
PC87338 chipsets. The FastIR stack will be shipped to customers
along with the rest of the OS. Windows CE version 2.0 and version 2.1 do not provide Consumer
IR support. But a 3rd party developer could write a driver to
provide this support. Windows CE version 2.1 supports TCP/IP, PPP, SLIP, and IrDA
protocols. Other protocols can be added by third-party
developers. In Windows CE version 2.1, we continue to provide a subset of
the Windows Sockets 1.1 specifications. At this time, we don't
provide a Service Provider Interface layer but we are considering
providing this support in a future release of Windows CE. Yes, Windows CE will suspend power when a socket is open (for
example, HTTP server with an open socket on a listening state).
But, Windows CE will not automatically suspend power if there is a
connected socket. Embedded customers are free to change the
implementation of the suspend state, thereby allowing them to
completely control how their embedded system behaves. Windows CE version 2.1 does not provide SNMP support at this
time. We are considering providing this support in a future OS
release. Windows CE version 2.1 does not provide SNMP support at this
time. We are considering providing this support in a future OS
release. These features are not supported in Windows CE version 2.1. As
we expand NDIS to support other protocols, we'll again look at Fast
Ethernet and Token Ring. We're likely to address Fast Ethernet
first, because Token Ring will require much more NDIS support than
we currently offer. No. Windows CE version 2.1 does not provide support for Smart
Cards. We will consider providing support Smart Cards in a future
release of Windows CE. No. Windows CE version 2.1 does not provide an HTTP server. We
will consider providing this support in a future release of Windows
CE. No. Windows CE version 2.1 does not provide PPTP at this time.
We are currently investigating our options in this area. We are
aware that it is important to provide our customers with secure
data access across the Internet. Windows CE supports all the above protocols. They can be
accessed via Windows Sockets, WinINET, or the CAPI 1.0 APIs, all of
which are available in Windows CE version 2.1. IP multicast is supported in Windows CE version 2.1 and is
exposed through the Windows Socket function
setsockopt()and its flags. Available options are
IP_MULTICAST_TTL,
IP_MULTICAST_IF,
IP_ADD_MEMBERSHIP,
IP_DROP_MEMBERSHIP. Windows CE version 2.0 and version 2.1 support installable TAPI
service providers. No, TAPI only supports outbound modem calls in Windows CE
versions 2.0 and 2.1. We will consider providing support for
inbound data calls via TAPI in a future release of Windows CE. Windows CE version 2.0 introduced the WNet APIs that allow
browsing of file resources on Windows NT and Windows 95 -based
machines. In Windows CE version 2.1, support was added to enable
browsing of print resources as well. The SMB redirector component
is based on the Windows NT LM .12 SMB specs. For more information
on how to use these APIs, refer to the Windows CE SDK
documentation. In the past, we have referred to two types of drivers in Windows
CE—Built-in drivers for devices built into the platform (such as
Comm ports, PCMCIA adapter, audio, etc.) and Installable drivers
for devices that are attached or inserted while the system is up
and running. This high-level description still applies to the
Windows CE driver architecture, but here we will provide a more
specific description of the different drivers in Windows CE. "Native Drivers" are drivers for devices that are native to the
platform. These drivers follow no common interface model. They are
loaded and called directly by their "parent" process, which could
be either the GWES module or the Device Manager. These drivers
could be either Layered (consisting of a small PDD layer that is
written by the OEM and an MDD layer that is provided by Microsoft)
or Monolithic (like UNIX) which the OEM writes completely. The
drivers that fit into this category are Touch Panel, Printers,
Display, Keyboard, LED, Battery, and PCMCIA. "Stream Interface Drivers" are drivers that implement the 10
Stream Interface functions in Windows CE. These drivers are loaded
by Device Manager and are exposed to applications through the file
system. This category of drivers could apply to both built-in and
installable devices in your platform. Stream Interface Drivers can be loaded in a number of
circumstances. Some are loaded at boot time by the Device Manager,
because of special registry entries for those drivers - Audio and
Serial drivers are examples. Some are loaded in response to Windows
CE detecting the connection of some additional hardware, such as a
PC Card. ATADISK and TrueFFS are examples. Finally, applications
can also ship with their own custom stream interface drivers and
load the drivers on the system when the application is run. Such
drivers generally sit on top of an existing driver and present the
underlying driver's services to the application. See the block
diagram below for a better understanding of the Windows CE Driver
model.
Figure 1. Windows CE Driver model
A device driver is just a DLL so regular IPC mechanisms can be
used (that is, messages, loopback, synchronization objects, and
shared memory). For example, to send data to the keyboard driver,
the embedded customer could use keybd_event or, if only keystrokes
are required, use PostKeybdMessage. Drivers can also open each
other (that is, one driver can do a CreateFile() of another driver
and communicate via DeviceIOControl() or
ReadFile()/WriteFile()). Windows CE does not support the Win32 Overlapped I/O functions
but our Serial driver is written to allow multiple threads to
access the serial port at once (that is, a thread can be blocked on
a ReadFile() call while another thread calls WriteFile()). The
sample serial port also supports multiple opens (either from the
same process or multiple processes), only one open can be
Read/Write, the others must be Read Only. An OEM has the choice of
restricting multiple threads or open calls. Windows CE client drivers are Installable Device Drivers, which
are user-mode DLLs. They all expose the same Stream Interface API.
So porting an installable driver to Windows CE might be easier than
other types of drivers. But, in general, device drivers should not
be looked at as portable entities. Usually, the main functions of
the driver can be ported to Windows CE with little change, but the
Windows NT IRP interface code would need to be changed to the
Stream Interface API. Yes, Windows CE version 2.1 added support for USB. In the
Windows CE USB subsystem, we will provide an OHCI Host Controller
driver (OHCD), a USB Driver (USBD) which exposes a complete client
driver interface (USBDI) for writing client drivers. For version
2.1, we'll also release a sample mouse client driver on the Host
side. No generic class (for example, HID) drivers will be provided
in version 2.1. We will not be providing any USB function drivers
on the client side (that is, in a peripheral). The Embedded Toolkit ships with a sample host controller driver
(OHCD) for the PC-Based Hardware Development Platform (a.k.a. CE/PC
platform). But at the minimum, an OEM has to provide platform
dependent drivers for their own Host Controller on their platform
(or use our OHCD for the CE/PC platform), as well as client drivers
for each planned USB device. For basic verification of the OHCI
host stack, the sample mouse driver could be used. For verification
of the USB device drivers, Microsoft will provide Device Driver
Test Kit (DDTK) routines in the ETK. For complete OHCI testing on
an OEM platform, an OEM will have to use the Intel 8x930Ax
Peripheral Controller kit and associated firmware. It is beyond the
scope of this FAQ to cover all possible interactions of USB
testing. Microsoft does not plan to test/support USB devices such as
Printers, Scanners, Cameras, Input devices, SCSI and other storage
devices (like Clik drives), and so forth, in Windows CE version
2.1. The Windows CE USB subsystem provides full OHCI host support
(on the PC-Based Hardware Development platform), such that OEMs can
write their own USB client drivers to support planned devices. OEMs
can refer to the MOUSE client driver as an example. No, IEEE 1394 (Firewire) standard bus is not supported in
Windows CE. OEMs can seek available third party solutions for 1394
support on Windows CE (for example, 3A, Inc. recently announced
support for 1394 devices on Windows CE). Windows CE provided support for the ATA IDE interface via PCMCIA
and CF card form factors since version 1.0. But, Windows CE does
not provide separate drivers to support external SCSI, IDE, and
Floppy devices. But an OEM can implement their own drivers based on
our sample drivers shipped in the Embedded Toolkit. No, Microsoft does not provide any PC card video drivers. But an
OEM can write their own video drivers based on our sample drivers.
There are a few OEMs that do provide such video drivers. Yes. Windows CE version 2.1 supports a parallel port driver
using the IEEE1284 Compatibility mode in the forward direction and
nibble mode in the reverse direction. The parallel port driver is
supported on our PC-based development platform (a.k.a. CE/PC). In Windows CE version 2.1, we are including a PCL sample in the
Embedded Toolkit. No other sample drivers are included at this
time. Third party developers and OEMs can create and add additional
printer drivers as needed. The print subsystem is capable of
handling multiple printer drivers loaded in the system. For
example, it is possible to have a PCL3 driver and a PostScript
driver loaded on the Windows CE-based device. The user can select
the desired printer device using the Common Print Dialog. Yes. The printer driver supports printing over Parallel, Serial,
IR, and Network printing. The Common Print Dialog allows the user
to choose the connection type. In version 2.1, we introduce basic
network printing—that is, the print subsystem makes no attempt to
figure out what type of printer is on the other end of the wire.
Rather, the user selects the connection type and specifies the
printer device using its UNC name, for example, \\server\share. In Windows CE version 2.1, there is support for linear flash
devices via the True Flash File System (TrueFFS) driver that
Windows CE has licensed from M-Systems. TrueFFS is a block device
driver and is serviced by the existing FAT filesystem in Windows
CE. Currently, TrueFFS driver will support linear flash devices
only on PC Card, Miniature Card, and M-Systems' DiskOnChip form
factors. A future release of Windows CE will support Resident Flash
Array (RFA) device. An OEM can customize the TrueFFS driver to
include the combination of MTD, Socket layer, and translation layer
that meets the needs of their platform. There is no support for DMA in the version 2.1 release of the
PCMCIA Card Services interface. However, we support LockPages API,
so that an OEM can implement DMA on their own. Yes, the built-in PCMCIA Socket driver supports true
multifunction cards as well as Dev/Multi cards (multiple devices of
the same type, for example DUALIO). There is a DUALIO sample that
ships in the DDK to illustrate the concept of writing a Dev/Multi
driver. True Multifunction cards are handled via the PnP ID key
that is obtained from the CIS structure. Note that /Dev/Multi cards
need not be of the same type, it can be used for loading drivers
for any multifunction card that does not meet the multifunction
card specification. Microsoft is working with Independent Hardware Vendors and its
Technology Partners to provide broad-based support for diverse card
form factors and card functions. For current information on the
list of cards that have undergone or are being tested for
compatibility/certification, please refer to the Microsoft
Windows Hardware Quality Lab (WHQL)Web
site. We're in the process of exploring how we might create a Windows
CE Driver Library (CEDL), similar to the Windows Driver Library
(WDL). Once the CEDL is finalized and implemented, OEMs and 3rd
party driver writers will be able to submit their fully functional
driver and supported hardware to the Windows Hardware Quality Lab
(WHQL) or an independent test authority for compatibility testing
and subsequent inclusion of the driver into the CEDL. We'll post
the latest information on the CEDL to the
WHQLWeb site, so OEMs should check this site
for updated information on this initiative. Use the DDTK (Device Driver Test Kit) routines that are provided
in the Embedded Toolkit. To test the higher-level layers of your
driver, use the FSLOGO tests (if appropriate), or pick individual
tests geared specifically towards the individual components of your
driver. As an example, for PCMCIA devices use fslogo.dll in the
case of storage cards, t_sledge.dll in the case of modem/network
cards, and choose from among the suite of low-level PCMCIA driver
tests for all cards. There are also test suites for other devices
like battery, keyboard, audio, serial, display, and so forth. Native debug services include Debug Messages, WinDBG (along with
kernel debugger component, KDSTUB) and CESH. All these services are
transport independent and configurable in Windows CE version 2.1,
and they are also available for Ethernet debugging. In addition, an
OEM can also extend this toolset to write their own debug tools via
the Ethernet Debug (EDBG) API support in Windows CE. Specific to
Drivers and OAL debugging, you could also use additional methods
like LED macros/routines, Logic Analyzer Methods, ROMulators, and
so forth. Windows CE version 2.1 also supports the standard Win32
ToolHelp and Debug APIs, so an OEM can write their own debugger if
needed. Yes, we provide remote debugging via the Ethernet Debug Services
as well as a few transport-independent Debug Services. The Release
Notes in the Embedded Toolkit will contain more information on how
to use these services. We will also provide a sample Ethernet
Bootloader program (EBOOT) for the ODO platform and sample
libraries to access the Ethernet Controller hardware for the
SMC91C94 and NE2000 compatible Ethernet cards, so as to enable
embedded customers to write similar programs for other
platforms. No, these features will not be delivered in Windows CE version
2.1.
User, GDI
Localization and Internationalization
Shell, Browser, E-mail Client
Communications, Security
Drivers
Testing/Debugging Support, Other
Development Tools
Core OS
User, GDI
Localization and
Internationalization
Shell, Browser, E-mail Client
Communications, Security
Drivers
Testing/Debugging Support, Other
Development Tools
Core OS
Processors - What Support Will be
Available, and When?
Is Persistence of Databases and Registry
Supported?
Is There Support for a PATH Equivalent,
Allowing Fonts, Drivers, DLLs, etc., to be Placed Elsewhere in
FILESYSTEM Besides \WINDOWS?
Does Windows CE Provide Support for
FAT32 Structure?
What is the Max Size of a File in the
Object Store?
Can I Add Support for Other File
Systems?
What Kind of Support Does Windows CE
Provide for CRT Functions?
Is There API Support for Performance
Measurements?
What Kind of Support Does Windows CE
Provide for Profiling?
User, GDI
Does CE Support Displaying Large
MESSAGEBOX on Narrow Screens?
Does CE Support Keyboard-less platforms
or Devices?
Does Windows CE Support Truetype
Fonts?
What About Support for Font
Linking?
Localization and Internationalization
What is the Support for
Internationalization in Windows CE?
What is the Support for Localization in
Windows CE?
Shell, Browser, E-mail Client
Embedded Shell - What Does it Look
Like, How is it Shipped (Source or Binary), What is and isn't
Supported as Compared to the H/PC Shell?
Why Doesn't Windows CE Include a
Shell?
Can the Shell Fix the Task Bar to a
Physical Screen Size (e.g. Quarter VGA) But Allow Applications a
Virtual Window That is Larger than the Physical Screen?
Does Windows CE Support Console
Applications?
Does Windows CE Include Pocket Internet
Explorer or a Different Browser?
Does Windows CE Include Pocket Inbox or
a Different E-mail Client? Is SMTP Supported?
Communications, Security
Is Fast IrDA Supported?
Does Windows CE Support Consumer
IR?
Are Protocol Stacks Other than TCP/IP
Supported?
Is Winsock 2.0 Supported? What About
Support for Multiple Socket Service Providers?
Is the TCP/IP Stack Power-management
Aware? For Example, is it Possible to Permit Suspend State When a
Socket is Open on a Windows CE Platform?
Is MIB II Supported for the TCP/IP Stack
and is There a Documented API to Access This MIB?
Does Windows CE Support an SNMP Agent
That Can Support Dynamically Registering/De-registering SNMP
Sub-agents?
Are Fast Ethernet and Token Ring
Supported? If So, When Would a New Version of NDIS Become
Available?
Does Windows CE Provide Full Native
Support for Smart Cards?
Does Windows CE Provide a Lightweight
HTTP Server?
Does Windows CE Support the
Point-to-Point Tunneling Protocol (PPTP)?
Support for SSL 2.0, 3.0, and Personal
Communications Technology (PCT) 1.0?
Support for IP Multicast (IGMP)?
What about TAPI/UNIMODEM and Installable
TAPI Service Providers (TSPI) Support?
Does TAPI Support Inbound Data
Calls?
Is There Support for a Network Client
(a.k.a. SMB Redirector)?
Drivers
What is the Windows CE Driver
Model?
What is the IPC Mechanism for Device
Drivers?
Is Overlapped I/O Supported? For
Example, Can Multiple Threads Access the Serial Port?
How Can I Port My Windows 9x or
Windows NT Driver to Windows CE?
Does Windows CE Support USB? What
Form Will This Support Take?
What Do I Need to Test USB on My
Platform with Version 2.1 Release?
What USB Devices are Supported/Tested
Under Windows CE?
Will IEEE 1394 (Firewire) be
Supported? If so, in What Form?
What About Other Storage Drivers Like
SCSI, IDE, Floppy Drivers?
Is There Support for Any External
Video Drivers?
Is a Parallel Port Driver Included in
Windows CE?
Are Non-PCL Printer Drivers
Supported?
Is Parallel Printing Supported? What
About Network Printing?
Is There Flash Filesystem Support -
Both Linear Flash PC Cards and On-board Flash?
PC Cards - (When) Will There be
Support for DMA in Card Services?
PC Cards - (When) Will There be
Support for Multifunction Cards?
Is Microsoft Working with PC Card and
Other Miniaturized Card Vendors to Insure Less Power Consuming I/O
Cards (Modems, Multi Function Cards, etc.)? What are the Supported
Cards?
Does Microsoft Provide a Way to
Include Third Party Drivers in Windows CE?
Testing/Debugging Support, Other Development
Tools
How Do I Test My Own Windows CE
Drivers That I Have Developed?
What Debugging Methods or Services
are Available in Windows CE to Debug My Applications or
Drivers?
Does Windows CE Support Remote
Debugging? What About Ethernet Debugging?
Is Symbolic Trace with Logic
Analyzers and Symbolic Debugging with In-Circuit Emulators
Supported?