FAQ for Microsoft Windows CE 2.1
Summary: This document contains frequently asked questions about Microsoft Windows CE 2.1. (20 printed pages)
- 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?
- 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?
- What is the support for Internationalization in Windows CE?
- What is the support for Localization in Windows CE?
- 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. ¼ panel 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 email client? Is SMTP supported?
- 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)?
- 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 ensure less power consuming I/O cards (modems, multi function cards, etc.)? What are the supported cards?
- Does Microsoft provide a way to include 3rd party Drivers in Windows CE?
- 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?
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.
Is There Support for a PATH Equivalent, Allowing Fonts, Drivers, DLLs, etc., to be Placed Elsewhere in FILESYSTEM Besides \WINDOWS?
- Fonts can be placed anywhere. By default, Windows CE will only load fonts from the \Windows directory. But, an application or an embedded shell can call AddFontResource to load a font and make it available system wide.
- A DLL can exist anywhere as long as you observe the rules for LoadLibrary() as documented in the SDK. Note that in version 2.1, a new rule was added for looking in the application directory.
- All system components including drivers should be placed in the "\Windows" directory. But, since a driver is a DLL, you could potentially place it outside the "\Windows" directory (see #2 above). However, we do not encourage this practice.
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 ProfileStart and ProfileStop functions. 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.
Localization and Internationalization
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.
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?
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.
Can the Shell Fix the Task Bar to a Physical Screen Size (e.g. ¼ Panel VGA) But Allow Applications a Virtual Window That is Larger than the Physical Screen?
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.
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?
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.
Does Windows CE Support an SNMP Agent That Can Support Dynamically Registering/De-registering SNMP Sub-agents?
Windows CE version 2.1 does not provide SNMP support at this time. We are considering providing this support in a future OS release.
Are Fast Ethernet and Token Ring Supported? If So, When Would a New Version of NDIS Become Available?
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.
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?
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 WHQL Web site, so OEMs should check this site for updated information on this initiative.
Testing/Debugging Support, Other Development Tools
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.