Programming Microsoft Windows CE by Douglas Boling

From the Publisher

Design sleek, high-performance applications for the newest generation of smart devices with Programming Microsoft Windows CE. This practical, authoritative reference explains how to extend your Windows or embedded programming skills to the Windows CE environment. You'll review the basics of event-driven development, then tackle the intricacies and idiosyncrasies of this modular, compact architecture.

Product Details

• Table of Contents
• Read an Excerpt

Table of Contents

Read an Excerpt

Chapter 7: Files, Databases, and the Registry

The Windows CE file API is taken directly from Win32. Aside from the lack of functions that directly reference volumes, the API is fairly complete. Windows CE implements the standard registry API, albeit without the vast levels of security found in Windows NT. The database API, however, is unique to Windows CE. The database functions provide a simple tool for managing and organizing data. They aren't to be confused with the powerful, multilevel SQL databases found on other computers. Even with its modest functionality, the database API is convenient for storing and organizing simple groups of data, such as address lists or mail folders.

Some differences in the object store do expose themselves to the programmer. Execute-in-place files, stored in ROM, appear as files in the object store but these functions can't be opened and read as standard files. Some of the ROM-based applications are also statically linked to other ROM-based dynamic-link libraries (DLLs). Thismeans that some ROM-based DLLs can't be replaced by copying an identically named file into the object store.

The concept of the current directory, so important in other versions of Windows, isn't present in Windows CE. Files are specified by their complete path. DLLs must be in the Windows directory, the root directory of the object store, or in the root directory of an attached file storage device, such as a PC Card.

As a general rule, Windows CE doesn't support the deep application-level security available under Windows NT. However, because the generic Win32 API was originally based on Windows NT, a number of the functions for file and registry operations have one or more parameters that deal with security rights. Under Windows CE, these values should be set to their default, not security state. This means you should almost always pass NULL in the security parameters for functions that request security information.

In this rather long chapter, I'll first explain the file system and the file API. Then I'll give you an overview of the database API. Finally, we'll do a tour of the registry API. The database API is one of the areas that has experienced a fair amount of change as Windows CE has evolved. Essentially, functionality has been added to later versions of Windows CE. Where appropriate, I'll cover the differences between the different versions and present workarounds, where possible, for maintaining a common code base.

The Windows CE File System

In addition to the object store, Windows CE supports multiple, installable file systems that can support up to 256 different storage devices or partitions on storage devices. (The limit is 10 storage devices for Windows CE 2.0 and earlier.) The interface to these devices is the installable file system (IFS) API. Most Windows CE platforms include an IFS driver for the FAT file system for files stored on ATA flash cards or hard disks. In addition, under Windows CE 2.1 and later, third party manufacturers can write an IFS driver to support other file systems.

Windows CE doesn't use drive letters as is the practice on PCs. Instead, every storage device is simply a directory off the root directory. Under Windows CE 1.0, an application can count on the name of the directory of the external drive being PC Card. If more than one PC Card was inserted, the additional ones are numbered, as in PC Card 1 and PC Card 2, up to PC Card 99 for the 100th card. Under Windows CE 2.0, the default name was changed from PC Card to Storage Card, but the numbering concept stayed the same. For Windows CE 2.1, Windows CE doesn't assume a name. Instead it asks the driver what it wants to call the directory. Later in this chapter, I'll demonstrate a method for determining which directories in the root are directories and which are actually storage devices.

As should be expected for a Win32-compatible operating system, the filename format for Windows CE is the same as its larger counterparts. Windows CE supports long filenames. Filenames and their complete path can be up to MAX_PATH in length, which is currently defined at 260 bytes. Filenames have the same name.ext format as they do in other Windows operating systems. The extension is the three characters following the last period in the filename and defines the type of file. The file type is used by the shell when determining the difference between executable files and different documents. Allowable characters in filenames are the same as for Windows NT and Windows 98.

Windows CE files support most of the same attribute flags as Windows 98 with a few additions. Attribute flags include the standard read-only, system, hidden, compressed, and archive flags. A few additional flags have been included to support the special RAM/ROM mix of files in the object store.

The Object Store vs. Other Storage Media

The object store in Windows CE has some basic limitations. First, the size of the object store is currently limited to 16 MB of RAM. Given the compression features of the object store, this means that the amount of data that the object store can contain is somewhere around 32 MB. Individual files in the object store are limited to 4 MB under Windows CE 2.0 and earlier. Files under Windows CE 2.1 and later are limited only by the size of the object store's 16-MB limit. These file size limits don't apply to files on secondary storage such as hard disks, PC Cards, or Compact Flash Cards.

Standard File I/0

Windows CE doesn't support the overlapped I/0 that's supported under Windows NT. Files or devices can't be opened with the FILE_FLAG_OVERLAPPED flag nor can reads or writes use the overlapped mode of asynchronous calls and returns.

File operations in Windows CE follow the traditional handle-based methodology used since the days of MS-DOS. Files are opened by means of a function that returns a handle. Read and write functions are passed the handle to indicate the file to act on. Data is read from or written to the offset in the file indicated by a system-maintained file pointer. Finally, when the reading and writing have been completed, the application indicates this by closing the file handle. Now on to the specifics.

Creating and Opening Files

HANDLE CreateFile

(LPCTSTR lpFileName, DWORD dwDesiredAccess, DWORD dwShareMode, LPSECURITY_ATTRIBUTES lpSecurityAttributes, DWORD dwCreationDistribution, DWORD dwFlagsAndAttributes, HANDLE hTemplateFile);

The first parameter is the filename of the file to be opened or created. The name of the file should have a fully specified path. Filenames with no path information are assumed to be in the root directory of the object store.

The dwDesiredAccess parameter indicate the requested access rights. The allowable flags are GENERIC_READ to request read access to the file and GENERIC_WRITE for write access. Both flags must be passed to get read/write access. You can open a file with neither read nor write permissions. This is handy if you just want to get the attributes of a device. The dwShareMode parameter specifies the access rights that can be granted to other processes. This parameter can be FILE_SHARE_READ and/or FILE_SHARE_WRITE. The lpSecurityAttributes parameter is ignored by Windows CE and should be set to NULL.

The dwCreationDistribution parameter tells CreateMe how to open or create the file. The following flags are allowed:

• CREATE_NEW    Creates a new file. If the file already exists, the function fails.
• CREATE_ALWAYS    Creates a new file or truncates an existing file.
• OPEN_EXISTING    Opens a file only if it already exists.
• OPEN_ALWAYS    Opens a file or creates a file if it doesn't exist. This differs from CREATE_ALWAYS because it doesn't truncate the file to 0 bytes if the file exists.
• TRUNCATE_EXISTING    Opens a file and truncates it to 0 bytes. The function fails if the file doesn't already exist.

Drivers are not supported in Windows 98.

ISDN drivers from the ISDN version 1.0 Accelerator Pack are not supported in Windows 98. Contact your ISDN adapterc;

• FILE_ATTRIBUTE_NORMAL    This is the default attribute. It's overridden by any of the other file attribute flags.
• FILE_ATTRIBUTE_READONLY    Sets the read-only attribute bit for the file. Subsequent attempts to open the file with write access will fail.
• FILE_ATTRIBUTE_ARCHIVE    Sets the archive bit for the file.
• FILE_ATTRIBUTE_SYSTEM    Sets the system bit for the file indicating that the file is critical to the operation of the system.
• FILE_ATTRIBUTE_HIDDEN    Sets the hidden bit. The file will be visible only to users who have the View All Files option set in the Explorer.
• FILE_FLAG_WRITE_THR0UGH    Write operations to the file won't be lazily cached in memory.
• FILE_FLAG_RANDOM_ACCESS    Indicates to the system that the file will be randomly accessed instead of sequentially accessed. This flag can help the system determine the proper caching strategy for the file.

Under Windows NT and Windows 98, the flag FILE_ATTRIBUTE_TEMPORARY is used to indicate a temporary file, but as we'll see below, it's used by Windows CE to indicate a directory that is in reality a separate drive or network share.

The final parameter in CreateMe, hTemplate, is ignored by Windows CE and should be set to 0. CreateFile returns a handle to the opened file if the function was successful. If the function fails, it returns INVALID_HANDLE_VALUE. To determine why the function failed, call GetLastError. If the dwCreationDistribution flags included CREATE_ALWAYS or OPEN_ALWAYS, you can determine whether the file previously existed by calling GetLastError to see if it returns ERROR_ALREADY_EXISTS. CreateFile will set this error code even though the function succeeded. ...