Программирование для Windows CE статья по информатике , Руководство, Проектов, Исследование из Информатика

Скачай Программирование для Windows CE статья по информатике и еще Руководство, Проектов, Исследование в формате PDF Информатика только на Docsity! Программирование для Windows CE Дуглас Боулинг Введение "Третья" Windows - новая операционная система Windows CE - не получила такой известности, как ее старшие сестры - Windows 98 и Windows NT, но ситуация начинает меняться. Windows CE предназначена для небольших, питающихся от батареек устройств, таких, как персональные электронные ассистенты. Несмотря на огромную разницу между этими приборами и настольными и портативными ПК, методики разработки программ для устройств Windows CE и компьютеров Windows во многом схожи. В данной статье мы расскажем о программировании для устройств Windows CE, но прежде всего попытаемся разобраться, что именно представляет собой Windows CE, чтобы провести черту между операционной системой и конкретными платформами, на которых она работает. Windows CE - это совершенно новая версия Windows. Ее нельзя назвать обновленной или упрощенной версией Windows 98 или Windows NT. В отличие от них Windows CE с самого начала проектировалась как новая операционная система для устройств с питанием от батарей, по габаритам значительно уступающих стандартным ПК. Пользователям, вероятно, чаще приходилось слышать о Windows CE-компьютерах, таких, как ручные (hand-held, РПК) или карманные (Palm-size, КПК) ПК, чем о самой операционной системе. В ПЗУ подобных устройств, выпускаемых обычно производителями комплексного оборудования (OEM), например фирмами Hewlett Packard и Casio, занесена версия Windows CE. Поэтому пользователи избавлены от необходимости устанавливать Windows CE, она поставляется с такими приборами по умолчанию. Интерфейс Windows CE предусматривает подмножество функций интерфейса прикладного программирования API Win32, применяемого в Windows 98 и Windows NT. Наверное, разработчики программ для Windows NT, услышав о "подмножестве", будут разочарованы, но не стоит волноваться, так как различия в API между версиями Windows для настольных ПК и Windows CE не вызовут больших проблем. Основные различия между ними сводятся к тому, что интерфейс Windows CE избавлен от избыточных функций, присутствующих в API Win32 для совместимости с предшествующими версиями Windows. Например, в версиях Windows для настольных систем имеется три или четыре способа открытия файла программными средствами. В среде Windows CE для этого существует только один способ - с помощью функции CreateFile. Другие отличия API состоят в том, что в Windows CE не реализованы целые группы функций, которыми располагает Windows NT. Например, библиотека Winsock из состава Windows CE не содержит большинства функций WSAAsync, представленных в Windows 98 и NT. При этом функционально Windows CE отнюдь не беднее, только при программировании гнезд в среде Windows CE придется прибегать к услугам более простой Беркли-версии протокола sockets. Для Windows-программистов это означает необходимость освоения процедур применения базовых блокирующих и неблокирующих гнезд без таких полезных функций, как WSAAsync, которые в Windows 9x и NT отвечают за уведомление прикладных программ о событиях, происходящих с гнездом. Другое важное различие между Windows CE и ее крупномасштабными родственницами состоит в том, что ее структура заранее предусматривает для OEM возможность изменения конфигурации, с тем чтобы система максимально соответствовала конкретным аппаратным платформам. Например, требования к профессиональным ручным ПК, которые представляют собой миниатюрные блокнотные ПК, работающие под управлением Windows CE, существенно отличаются от требований к ПК класса Palm-size. Поэтому Windows CE допускает разбиение на компоненты, чтобы изымать те части этой операционной системы, которые не понадобятся на целевой платформе. Подобная процедура вовсе не означает только исключение ряда DLL из состава ОС для конкретной платформы, варианты изменения конфигурации Windows CE гораздо разнообразнее. Например, API курсора, управляющий внешним видом указателя на экране, или даже компонент, отвечающий за работу с буфером обмена, вполне могут быть изъяты. Задачу выбора компонента Windows CE решает производитель оборудования для платформ вертикального рынка или компания Microsoft для платформ горизонтального рынка. При разных сочетаниях компонентов образуются и соответствующие интерфейсы API. Следовательно, интерфейс API для РПК фирмы Casio идентичен API для РПК компании NEC, поскольку в обеих системах применяется одна и та же конфигурация Windows CE, подготовленная Microsoft для устройств класса РПК. С другой стороны, интерфейсы API устройств РПК и КПК несколько отличаются, поскольку конкретные компоненты Windows CE для этих двух платформ не совсем одинаковы. Однако не стоит придавать большое значение этим отличиям. Если не касаться специфических функций API, рассчитанных только на устройства одного класса, никаких проблем с разработкой программ для обеих платформ не будет. Всегда есть возможность предотвратить возникновение проблем, связанных со спецификой платформ, для этого достаточно явно подключить функции, ориентированные на конкретную платформу, с помощью команд LoadLibrary и GetProcAddress. На самом деле самая серьезная проблема разработки программ, предназначенных для выполнения на обеих платформах, связана с разницей в размерах экранов, которыми оснащаются устройства этих классов. Например, вытянутый по горизонтали экран РПК (640Ч240 пиксел) требует иного расположения диалоговых окон, чем на вертикальном экране КПК (240Ч320). Разумное решение в этом случае - подготовить отдельную процедуру для работы с диалоговыми окнами, содержащую разные шаблоны окон для этих двух экранов, отличающихся габаритами. При таком подходе надлежащий шаблон может определять прикладная программа в ходе выполнения. Еще одну проблему при программировании для устройств Windows CE создает вечно малый объем памяти рабочей среды, в которой приходится "существовать" программе. При том, что Windows CE предусматривает механизм подкачки страниц по мере надобности, она не позволяет применять файл подкачки для сохранения данных чтения-записи на вторичном устройстве памяти, например жестком диске. Другими словами, недоступные для записи страницы, например с программными кодами и постоянными данными, переносятся в память, как только в них возникает необходимость. Однако данные для чтения-записи никогда не заносятся в файл подкачки на жестком диске. Благодаря таким ограничениям быстрее происходит запуск программ в Windows CE, поскольку в память загружаются только те части программы, которые нужны на момент запуска. Но, поскольку Windows CE не позволяет сохранять в файле подкачки переменные данные, в распоряжении прикладных программ находится весьма ограниченное в объеме физическое ОЗУ устройства. По этой причине, вполне возможно, временами в ходе выполнения программа будет испытывать острый недостаток памяти. Следовательно, программы для Windows CE должны быть предельно "экономны" в потреблении оперативной памяти и снабжены средствами для "мягкого" выхода из возникающих в связи с этим аварийных ситуаций. Инструменты Как известно, Windows CE рассчитана на самые разные устройства, это серьезно осложняет жизнь создателям средств разработки. Поскольку Windows CE совместима с различными ЦП и предусматривает множество вариантов настройки, причем для каждого из них применяется свой API, необходим какой-то способ передачи конкретной среде разработки информации о целевой платформе. Для решения этой задачи Microsoft подготовила целый набор пакетов разработки для Windows CE, некоторые из них совместимы со всеми платформами, а другие ориентированы только на обычные и профессиональные ручные ПК. TCHAR szAppName[] = TEXT ("TinyCE"); HINSTANCE hInst; //----------------------------------- // Точка входа в программу // int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, LPWSTR lpCmdLine, int nCmdShow) { WNDCLASS wc; HWND hWnd; MSG msg; hInst = hInstance; // Регистрируется класс App Main Window memset (&wc, 0, sizeof (wc)); wc.lpfnWndProc = MainWndProc; // Внешний вызов wc.hInstance = hInstance; // Дескриптор владельца wc.hbrBackground = (HBRUSH) GetStockObject(WHITE_BRUSH); wc.lpszClassName = szAppName; // Имя класса окна if (RegisterClass(&wc) == 0) return -1; // Построение главного окна hWnd = CreateWindow (szAppName, // Класс окна szAppName, // Заголовок окна WS_VISIBLE, // Флаги стилей CW_USEDEFAULT, // Позиция по X CW_USEDEFAULT, // Позиция по Y CW_USEDEFAULT, // Исходная ширина CW_USEDEFAULT, // Исходная высота NULL, // Предок NULL, // Меню, должен иметь // значение NULL hInstance, // Экземпляр программы NULL); // Указатель для // создания параметров // В качестве return-значения передается код ошибки, // если окно не построено if (!IsWindow (hWnd)) return -2; // Стандартные вызовы отображения и обновления ShowWindow (hWnd, nCmdShow); UpdateWindow (hWnd); // Цикл обработки сообщений в программе while (GetMessage (&msg, NULL, 0, 0)) { TranslateMessage(&msg); DispatchMessage(&msg); } return 0; } //----------------------------------- // Основная оконная процедура // LRESULT CALLBACK MainWndProc(HWND hWnd, UINT wMsg, WPARAM wParam, LPARAM lParam) { HWND hwndCB; PAINTSTRUCT ps; RECT rect; HDC hdc; switch (wMsg) { case WM_CREATE: // Создание минимальной панели команд, содержащей только // кнопку Exit. hwndCB = CommandBar_Create (hInst, hWnd, 0x10); CommandBar_AddAdornments (hwndCB, 0, 0); break; case WM_PAINT: // Настройка размера прямоугольника клиентского окна // с учетом высоты панели команд. GetClientRect (hWnd, &rect); rect.top += CommandBar_Height (GetDlgItem (hWnd, 0x10)); hdc = BeginPaint (hWnd, &ps); DrawText (hdc, TEXT ("Hello Windows CE!"), -1, &rect, DT_CENTER | DT_VCENTER | DT_SINGLELINE); EndPaint (hWnd, &ps); break; case WM_DESTROY: break; } return DefWindowProc(hWnd, wMsg, wParam, lParam); } Достаточно взглянуть на этот текст, чтобы увидеть, как похожи приложения Windows CE на обычные Windows-программы. А теперь, не упуская из виду все перечисленные соображения, рассмотрим элементарную программу для Windows CE. На рис. 1 показан исходный текст простой программы TinyCE, которая лишь выводит на экран строку текста в главном окне. При беглом взгляде программисты, сроднившиеся с функциями Win32, вряд ли обнаружат едва уловимые различия между этой программой и ее "кузинам" для Windows 98 или NT. Она так же регистрирует класс окна, конструирует окно, выполняет цикл обработки сообщений и работает с окнами, как и любая другая Windows-программа. В отличиях, наблюдающихся в данном примере, повинны уже упоминавшиеся расхождения в интерфейсах API. Например, для размещения кнопки закрытия программы используется панель команд. После набора текста программы для ее компиляции и запуска применяются точно такие же методы, как и для приложений на настольных ПК. Процедура компиляции предусматривает дополнительную операцию автоматической загрузки полученного EXE- или DLL-модуля в подключенное к настольному ПК Windows CE-устройство. Для запуска программы на выполнение в среде Windows CE выбирается тот же пункт меню Program | Run (Программа | Запуск либо [Ctrl] + [F5]), что и при запуске программы, подготовленной для Windows NT. И конечно, с помощью интегрированного отладчика можно выполнять программу в пошаговом режиме. Основное различие между отладкой программ для Windows CE и Windows NT вызвано влиянием скорости последовательного соединения между ПК разработчика и удаленной Windows CE-системой. Из-за низкой скорости такого соединения пошаговая отладка превращается в раздражающе медленный процесс. Что касается меня, я обычно применяю отладчик только для поиска самых трудноуловимых ошибок. Вместо дистанционного отладчика можно применять другой вариант. Все SDK для платформ РПК, КПК и автомобильных ПК (Auto PC) оснащены программными эмуляторами, которые пытаются имитировать удаленное Windows CE-устройство в среде Windows NT. Такой эмулятор запускает скомпилированную специальным образом версию подготовленной программы. Он эмулирует интерфейс API Windows CE, в том числе такие его расширения, как API СУБД. Но и здесь не обходится без проблем: модель среды Windows CE, обеспечиваемая эмулятором, далека от идеала. Иногда после целого дня работы вдруг понимаешь, что проблема, над решением которой бьешся, - проблема эмулятора, а не ошибка в программе. Но выход из создавшейся ситуации все же есть: программы для Windows CE следует составлять таким образом, чтобы они компилировались как для Windows CE, так и для Windows NT. В результате общие для обеих систем фрагменты приложения можно отлаживать локально в среде Windows NT, а затем, выбрав иную целевую среду, провести компиляцию для Windows CE. Нужно только помнить, что многократные компиляции на любой из платформ чреваты сложностями. После бесконечных повторов компиляции для Windows NT придется потратить массу времени, чтобы путем внесения изменений добиться надлежащего функционирования программы в среде Windows CE. Разработать программу, которая будет компилироваться и для Windows NT, и для Windows CE, не так уж и трудно. Чтобы выделить фрагменты программы, характерные для конкретной операционной системы, следует применять выражения define компилятора, и тогда они будут выбираться при компиляции для заданной ОС. В приведенном ниже фрагменте программы функции формирования панели команд размещены в предложениях условной компиляции (#), поэтому будут охвачены процедурой компиляции только для Windows CE. #ifdef _WIN32_WCE // Если выполняется // компиляция для CE