LibCat » Книги » Справочная литература » Руководства » Nicolas Besson - Microsoft Windows Embedded CE 6.0 Exam Preparation Kit

Nicolas Besson - Microsoft Windows Embedded CE 6.0 Exam Preparation Kit

Здесь есть возможность читать онлайн «Nicolas Besson - Microsoft Windows Embedded CE 6.0 Exam Preparation Kit» весь текст электронной книги совершенно бесплатно (целиком полную версию без сокращений). В некоторых случаях можно слушать аудио, скачать через торрент в формате fb2 и присутствует краткое содержание. Город: Redmond, Год выпуска: 2008, Издательство: Microsoft, Жанр: Руководства, ОС и Сети, Программы, на английском языке. Описание произведения, (предисловие) а так же отзывы посетителей доступны на портале библиотеки ЛибКат.

Читать книгу

Название:
Microsoft Windows Embedded CE 6.0 Exam Preparation Kit
Автор:
Nicolas Besson
Издательство:
Microsoft
Жанр:
Руководства / ОС и Сети / Программы / на английском языке
Год:
2008
Город:
Redmond
ISBN:
нет данных
Рейтинг книги:
5 / 5. Голосов: 1
Избранное:

Добавить в избранное
Отзывы:
Написать комментарий
Ваша оценка:
- 100
- 1
- 2
- 3
- 4
- 5

Microsoft Windows Embedded CE 6.0 Exam Preparation Kit: краткое содержание, описание и аннотация

Предлагаем к чтению аннотацию, описание, краткое содержание или предисловие (зависит от того, что написал сам автор книги «Microsoft Windows Embedded CE 6.0 Exam Preparation Kit»). Если вы не нашли необходимую информацию о книге — напишите в комментариях, мы постараемся отыскать её.

Microsoft Windows Embedded CE 6.0 Exam Preparation Kit — читать онлайн бесплатно полную книгу (весь текст) целиком

Ниже представлен текст книги, разбитый по страницам. Система сохранения места последней прочитанной страницы, позволяет с удобством читать онлайн бесплатно книгу «Microsoft Windows Embedded CE 6.0 Exam Preparation Kit», без необходимости каждый раз заново искать на чём Вы остановились. Поставьте закладку, и сможете в любой момент перейти на страницу, на которой закончили чтение.

Тёмная тема

Шрифт:

↓

↑

Сбросить

Интервал:

↓

↑

Закладка:

Сделать

Windows Embedded CE 6.0 supports the following naming conventions for stream drivers:<\/p>

■ Legacy names<\/strong>The classical naming convention for stream drivers consists of three upper case letters, a digit, and a colon. The format is XXX[0-9]:, where XXX stands for the three-letter driver name and [0-9] is the index of the driver as specified in the driver's registry settings (see Lesson 3, "Configuring and Loading a Driver"). Because the driver index has only one digit, legacy names only support up to ten instances of a stream driver. The first instance corresponds to index 1, the ninth instance uses index 9, and the tenth instance refers to index 0. For example, CreateFile(L"COM1:"...)<\/strong>accesses the stream driver for the first serial port by using the legacy name COM1:.<\/p>

NOTE<\/div>

Legacy name limitation<\/div>

The legacy naming convention does not support more than ten instances per stream driver.<\/p> <\/cite>

■ Device names<\/strong>To access a stream driver with an index of ten or higher, you can use the device name instead of the legacy name. The device name conforms to the format \$device\XXX[index]<\/strong>, where \$device\ is a namespace that indicates that this is a device name, XXX<\/em> stands for the three-letter driver name and [index]<\/em> is the index of the driver. The index can have multiple digits. For example, CreateFile(L"\$device\COM11"...) would access the stream driver for the eleventh serial port. Stream drivers with a legacy name can also be accessed, such as CreateFile(L"\$device\COM1"...).<\/p>

NOTE<\/div>

Legacy and device name access<\/div>

Although legacy names and device names differ in format and supported range of driver instances, CreateFile returns the same handle with access to the same stream driver in both cases.<\/p> <\/cite>

■ Bus name<\/strong>Stream drivers for devices on a bus, such as Personal Computer Memory Card International Association (PCMCIA) or Universal Serial Bus (USB), correspond to bus names that the relevant bus driver passes to Device Manager when enumerating the drivers available on the bus. Bus names relate to the underlying bus structure. The general format is \$bus\BUSNAME_[bus number]_[device number]_[function number]<\/strong>, where \$bus\ is a namespace that indicates that this is a bus name, BUSNAME<\/em> refers to the name or type of the bus, and [ bus number<\/em> ], [ device number<\/em> ], and [ function number<\/em> ] are bus-specific identifiers. For example, CreateFile(L"\$ bus\PCMCIA_0_0_0"…) accesses device 0, function 0, on PCMCIA bus 0, which might correspond to a serial port.<\/p>

NOTE<\/div>

Bus name access<\/div>

Bus names are primarily used to obtain handles for unloading and reloading bus drivers and for power management, but not for data read and write operations.<\/p> <\/cite>

Stream Interface API<\/p> <\/div>

For Device Manager to load and manage a stream driver successfully, the stream driver must export a common interface, generally referred to as the stream interface. The stream interface consists of 12 functions to initialize and open the device, read and write data, power up or down the device, and close and de-initialize the device, as summarized in Table 6-1.<\/p>

Table 6-1 Stream interface functions<\/strong> <\/p>

Function Name<\/th>	Description<\/th> <\/tr>
XXX_Init<\/td>	Device Manager calls this function to load a driver during the boot process or in answer to calls to ActivateDeviceEx in order to initialize the hardware and any memory structures used by the device.<\/td> <\/tr>
XXX_PreDeinit<\/td>	Device Manager calls this function before calling XXX_Deinit to give the driver a chance to wake sleeping threads and invalidate open handles in order to accelerate the de-initialization process. Applications do not call this function.<\/td> <\/tr>
XXX_Deinit<\/td>	Device Manager calls this function to de-initialize and deallocate memory structures and other resources in response to a DeActivateDevice call after deactivating and unloading a driver.<\/td> <\/tr>
XXX_Open<\/td>	Device Manager calls this function when an application requests access to the device by calling CreateFile for reading, writing, or both.<\/td> <\/tr>
XXX_PreClose<\/td>	Device Manager calls this function to give the driver a chance to invalidate handles and wake sleeping threads in order to accelerate the unloading process. Applications do not call this function.<\/td> <\/tr>
XXX_Close<\/td>	Device Manager calls this function when an application closes an open instance of the driver, such as by calling the CloseHandle function. The stream driver must de-allocate all memory and resources allocated during the previous XXX_Open call.<\/td> <\/tr>
XXX_PowerUp<\/td>	Device Manager calls this function when the operating system comes out of a low power mode. Applications do not call this function. This function executes in kernel mode, can therefore not call external APIs, and must not be paged out because the operating system is running in single-threaded, non-paged mode. Microsoft recommends that drivers implement power management based on Power Manager and power management IOCTLs for suspend and resume functionality in a driver.<\/td> <\/tr>
XXX_PowerDown<\/td>	Device Manager calls this function when the operating system transitions into suspend mode. Similar to XXX_PowerUp, this function executes in kernel mode, can therefore not call external APIs, and must not be paged out. Applications do not call this function. Microsoft recommends that drivers implement power management based on Power Manager and power management IOCTLs.<\/td> <\/tr> <\/table> NOTE<\/div> XXX prefix<\/div> In the function names, the prefix XXX<\/em> is a placeholder that refers to the three-letter driver name. You need to replace this prefix with the actual name in the driver code, such as COM_Init for a driver called COM, or SPI_Init for a Serial Peripheral Interface (SPI) driver.<\/p> <\/cite> Device Driver Context<\/p> <\/div> Device Manager supports context management based on device context and open context parameters, which Device Manager passes as DWORD values to the stream driver with each function call. Context management is vital if a driver must allocate and deallocate instance-specific resources, such as blocks of memory. It is important to keep in mind that device drivers are DLLs, which implies that global variables and other memory structures defined or allocated in the driver are shared by all driver instances. Deallocating the wrong resources in response to an XXX_Close or XXX_Deinit call can lead to memory leaks, application failures, and general system instabilities.Stream drivers can manage context information per device driver instance based on the following two levels:<\/p>