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

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

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

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

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).

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.

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.

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().

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

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.

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 3 rd party devices (GPS receivers, printers, etc.)

Interface between Kernel and Native Driver Event Handler (EH) Interrupt Service Handler (ISH) Kernel OAL Interrupt Service Routine (ISR) Native Driver Interrupt Service Thread (IST) Platform Dependent Driver HARDWARE

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.

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.

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.

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