Windows CE Object Store Overview

1. Windows CE Object Store • Windows CE name for persistent storage • Provides storage for the • Registry • Databases • File System • In a non-volatile portion of RAM

2. Registry • To centralize applicationr, user and system settings • Consolidates what was done earlier with autoexec.bat, config.sys, etc. • Stored as a hierarchy, with each element termed a key. • Each key has a default value and several optional extra values • Four hierarchies • HKEY_LOCAL_MACHINE: char. of m/c • HKEY_USERS: default user config. • HKEY_CURRENT_USER: for current user • HKEY_CLASSES_ROOT: types and properties of supported documents

3. Registry (contd.) • RegCeateKeyEx() to create keys • RegSetValueEx() to update a value of a key • RegQueryValueEx() retrieves the associated type and data

4. Databases • CE offers an integrated database not offered by other Windows versions • Note that this is not really a DBMS • No SQL (direct API) • No concurrency control • No transactional notion

5. Terminology • Volume: A collection of tables • Database: One of these tables • Record: One row of table • Property: A column of the table • Sort Order: A method to quickly access rows • Each database can support upto 4 sort orders (specified at creation).

6. Databases are stored in a file (called volume). First mount a volume using CeMountDBVol() CeCreateDatabaseEx() to create a database CeOpenDatabaseEx() to open an existing database – can ask to be notified if someone else modifies when in use. CeWriteRecordProps() to create or update a record. Each call to CeReadRecordProps() returns the next record in the specified sort order (at open) CeSeekDatabase() to seek to a specific record – record id, matching a value, having the immediate previous value, etc.

7. File System • Portion of object store where files reside (\Windows) • Differences from normal Windows: • No security/access permissions • No notion of drives (A:, C:, etc.) – everything is accessible from “\” • No concept of current directory, always need to specify from “\” • When inserting flash cards, they appear under the directory “\StorageCard1”, “\StorageCard2”, etc.

8. File System API • CreateFile() to create files – analogous to Unix open • ReadFile() and WriteFile() to read and write data from/to files. • Writes are buffered and flushed to appropriate device sometime later • Applications can force the writes with FlushFileBuffers() call • File seeking is done with SetFilePointer() call. • Can use same calls for device interfaces as well. In addition there is a DeviceIOControl() call similar to Unix ioctl().

9. Memory Mapped Files • Allows normal memory load/store interface to files • Also, allows creating shared memory • Different from traditional Unix in that it increases the virtual address space of process. E.g. a process (normally 32MB) mapping a 4MB file becomes 36MB, but not all of it is contiguous

10. Memory Mapping API • CreateFileForMapping() is done first • Then the handle is passed to CreateFileMapping() which creates a file mapping object and associates it with the opened file. • MapViewOfFile() maps the file in memory and returns a memory pointer to it. • When two processes do this, they have created a shared memory region.

11. Device Drivers • Native drivers • Control low level devices built-in with the CE platform (audio, battery display, keyboards …) • They can have unique APIs • Stream drivers • They export the same API • They usually drive 3rd party devices (GPS receivers, printers, etc.)

12. Interface between Kernel and Native Driver Kernel Interrupt Service Handler (ISH) Event Handler (EH) 6 Native Driver 4 Interrupt Service Thread (IST) OAL 2 3 1 7 5 Interrupt Service Routine (ISR) Platform Dependent Driver HARDWARE

13. EH in kernel is first invoked. • EH disables all interrupts and invokes appropriate ISR in OAL • ISR performs some minimal processing and returns interrupt id to kernel • ISH re-enables all but this interrupt, uses the interrupt id to signal an event on which a IST of a native driver is waiting (Event Object). • IST may need to perform some hardware specific actions to process interrupt • IST then notifies kernel once it is done • ISH then re-enables this interrupt by calling some functions in OAL.

14. Stream Drivers • Presents the device as being a special file • Standard API regardless of the device • Strict naming rules: 3 upper case letters (identifies function prefix) + single digit + colon • They can be loaded/unloaded by the Device Manager.

15. Loading Drivers • At boot time, Device Manager loads all drivers listed under HKEY_LOCAL_MACHINE\Drivers\Builtin registry key. • When a device is connected, the Device Manager calls the native socket driver to obtain a Plug and Play id. This id is compared against registry entries in HKEY_LOCAL_MACHINE\Drivers\PCMCIA. If found, that driver is loaded. Else, it calls functions listed in ….\PCMCIA\Detect that are Stream Driver functions. If one of them says it can handle, then that driver is loaded. • If an application attempts to open a device without driver loaded, then the application can explicitly load the driver.

16. Stream Interface Functions • XXX_Close() • XXX_Deinit() • XXX_Init() • XXX_IoControl() • XXX_Open() • XXX_PowerDown() • XXX_PowerUp() • XXX_Read() • XXX_Seek() • XXX_Write()