Время на прочтение
4 мин
Количество просмотров 20K
Этот пост для настоящих программистов, которые вместо букваря учили алфавит по третьему изданию справочника по C++. Программировать под Windows CE будем на C++ с помощью Embedded Visual C++.
Итак, нам понадобятся:
1. eMbedded Visual C++ 4.0 (TRT7H-KD36T-FRH8D-6QH8P-VFJHQ)
2. eMbedded Visual C++ 4.0 service pack 4
3. ritti.exe
4. Microsoft Pocket PC 2003 SDK.msi
5. Microsoft ActiveSync
6. StandAlone Emulator
Данный комплект позволяет разрабатывать программы, которые запускаются на всех Windows Mobile, начиная с 2003. Забудьте про нововведения в Windows Mobile 5 и 6 (если только они вам не нужны :). Все эти продукты находятся через Гугл, но установить их немного тягомотно. Особенно надоедает Emulator, который требует установки следующих вещей в следующем порядке:
1. netsvwrap.msi
2. standalone_emulator_V1.exe
3. efp.msi
4. emulator_2_0.msi
Если Вы все еще здесь – продолжаем!
Вкратце отличия WinCE API от Win32 API таковы: только Unicode, отсутствие текущего каталога (только абсолютные пути), урезаны громоздкие вещи, наличие особенностей со вводом.
Я создавал кросс-платформенный продукт (под WinCE и Win32). Вот как это делается в двух словах. С помощью UNDER_CE различить платформу:
#ifdef UNDER_CE
// здесь код для только для Windows CE
#else
// здесь код для только для Windows 32
#endif
WinMain немного различается:
#ifdef UNDER_CE
int WINAPI WinMain(HINSTANCE h, HINSTANCE prev, LPTSTR line, int cmd)
#else
int WINAPI WinMain(HINSTANCE h, HINSTANCE prev, LPSTR line, int cmd)
#endif
Проще всего делать оба проекта UNICODE. Это упростит код. В STL для работы с UNICODE-строкой есть замечательный класс wstring. Литералы строковые выглядеть должны так:
_T(«Goodbye, world!»)
_T() есть макрос, которые превратит строковый литерал в UNICODE или ASCII по надобности. Вместо char используем TCHAR.
Чтобы сделать проект UNICODE в Win32 задайте два preprocessor definitions: _UNICODE и UNICODE. В Embedded C++ это будет сделано по умолчанию.
Поскольку нет текущего каталога, все пути абсолютные и самому приходится заботится о добавлении нужного префикса. Вот так найдем откуда нас запустили:
wstring ApplicationPath()
{
TCHAR Path[MAX_PATH + 1] = {0};
int n = GetModuleFileName(0, Path, MAX_PATH);
while (—n > 0 && Path[n] != _T(‘\’) && Path[n] != _T(‘/’))
Path[n] = 0;
return Path;
}
Вот так вот извращаемся, если нужно что-то только под Windows 32:
typedef DWORD (WINAPI *FUNC_GetGuiResources)(HANDLE, DWORD);
FUNC_GetGuiResources f_GetGuiResources = 0;
struct Win2000_Linkage { Win2000_Linkage() {
#ifndef UNDER_CE
f_GetGuiResources = (FUNC_GetGuiResources) GetProcAddress(GetModuleHandle(_T(«user32.dll»)), «GetGuiResources»);
#endif
} } Win2000_linkage;
int GetGuiResource(DWORD which)
{
#ifndef UNDER_CE
if (f_GetGuiResources == 0) return 0;
HANDLE h = OpenProcess(PROCESS_QUERY_INFORMATION, false, GetCurrentProcessId());
int n = f_GetGuiResources (h, which);
CloseHandle(h);
return n;
#else
return 0;
#endif
}
Вот еще странный кусок кода, который видимо появился из-за отсутствия прерывистой линии типа, составленной из точек на Win CE:
#ifdef UNDER_CE
#define DASH_STYLE PS_DASH
#else
#define DASH_STYLE PS_DOT
#endif
Под Win CE у нас как бы нету текущей позиции курсора, потому как сами понимаете. Следовательно, если она нужна, то запоминайте сами последнее событие от мыши и считайте эту позицию позицией курсора. Типа:
#ifdef UNDER_CE
POINT mouse = mouse_at;
#else
POINT mouse = WhereIsCursor();
#endif
Под Win CE отсутствует примитив Arc() (см. GDI).
Зато! Зато под Win CE есть все-таки что-то хорошее. Это хорошее – это встроенный в ОС браузер Chro…, то есть Oper.., то есть Inernet Explorer! Фуу, вспомнил название-таки! Он конечно немного попроще своего старшего брата, но ведь нам много и не нужно – просто красиво нам текст HTML нарисуй и все!
Вначале делаем:
BOOL InitHTMLControl(
HINSTANCE hinst );
Теперича на окно можно добавить контрол с классом WC_HTML.
И заслать в него какой-нибудь HTML для отображения:
SendMessage(hwndHTML, WM_SETTEXT, 0, (LPARAM)»»);
SendMessage(hwndHTML, DTM_ADDTEXTW, FALSE, (LPARAM)TEXT(«Hello»));
SendMessage(hwndHTML, DTM_ADDTEXTW, FALSE, (LPARAM)TEXT(«World!»));
SendMessage(hwndHTML, DTM_ENDOFSOURCE, 0, (LPARAM)NULL);
Под Win 32 для схожих целей можно использовать контрол richedit.
Под Win CE нету GetPrivateProfileString, так что чтение и разбор INI-файлов ваша прерогатива.
При загрузке DLL под Win32 имя функции должно быть в ANSI. Хотя проект и под UNICODE. Почему? Потому что!
#ifndef UNDER_CE
string f_name = ANSI(func_name);
FARPROC f = GetProcAddress(h, f_name.data());
#else
FARPROC f = GetProcAddress(h, func_name);
#endif
Заодно держите и вот эти функции:
string ANSI(wstring w)
{
int l = WideCharToMultiByte(CP_ACP, 0, w.data(), w.size(), NULL, 0, NULL, NULL);
if (l)
{
char* buffer = new char[l + 1];
l = WideCharToMultiByte(CP_ACP, 0, w.data(), w.size(), buffer, l, NULL, NULL);
buffer[l] = 0;
string s(buffer);
delete[] buffer;
return s;
}
return «»;
}
wstring UniCODE(string w)
{
int l = MultiByteToWideChar(CP_ACP, 0, w.data(), w.size(), NULL, 0);
if (l)
{
TCHAR* buffer = new TCHAR[l + 1];
l = MultiByteToWideChar(CP_ACP, 0, w.data(), w.size(), buffer, l);
buffer[l] = 0;
wstring s(buffer);
delete[] buffer;
return s;
}
return _T(«»);
}
Вот как у меня выглядит начало h-файла, который включается в каждый компилируемый файл первым:
#pragma warning(disable: 4786)
#pragma once
#ifndef UNICODE
#error You must define UNICODE
#endif
#ifndef _UNICODE
#error You must define _UNICODE
#endif
#ifndef WINVER
#define _WIN32_WINNT 0x0400
#define WINVER 0x0400
#endif
#ifndef UNDER_CE
#include <tchar.h>
#include <crtdbg.h>
#define ASSERT(expr) _ASSERT(expr)
#define IDC_HAND MAKEINTRESOURCE(32649)
#define GR_GDIOBJECTS 0 /* Count of GDI objects */
#define GR_USEROBJECTS 1 /* Count of USER objects */
#define WS_NONAVDONEBUTTON 0
#include <math.h>
#endif
#include «windows.h»
#include #include #include #include #include #include using namespace std;
Как видите я плотно использую STL и поэтому подгружаю ее классы в пространство имен по умолчанию.
Пока все, если понравилось в следующей части расскажу про всплывающую клавиатуру (SIP), определение ориентации экрана и его поворот, подстройка под размеры экрана, определение DPI и подстройка под него, магические пассы для появления в правом верхнем углу крестика закрывающего приложение (а не убирающего его неизвестно куда), всплывание напоминаний и пр.
|
2000 г Программирование для Windows CEДуглас Боулинг, PC Magazine/RE #10/1999 Содержание
Инструменты Базовый цикл разработки программ Platform Builder Введение«Третья» 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, некоторые из них совместимы со всеми платформами, а другие ориентированы только на обычные и профессиональные ручные ПК. Эти инструменты предназначены для применения в среде Windows NT. Разработка программ происходит в среде Developer Studio с помощью одного из упомянутых ниже языков. Готовая программа выполняется на Windows CE-устройстве, подключенном к ПК разработчика либо через последовательный порт, либо через локальную сеть. Соединение через последовательный порт — стандартный способ подключения в Windows CE, применяемый для синхронизации данных между ними и ПК. Сетевые соединения обеспечивают гораздо более высокую скорость загрузки, чем первый способ, но, к сожалению, некоторые инструменты отладки отказываются работать, если Windows CE-устройство подключено таким образом. Microsoft предлагает версии языков Visual C++, Visual Basic и Visual J++ для одной или нескольких платформ Windows CE. Имеющиеся ныне версии Visual Basic и Visual J++ для Windows CE ориентированы только на обычные и профессиональные ручные ПК. В настоящее время для подготовки программ, рассчитанных на другие платформы, пригодна лишь версия Visual C++, совместимая с любой из них. Поэтому в нашей статье мы рассмотрим только среду программирования Visual C++, хотя не исключено, по множеству причин читатель предпочтет какой-то другой из языков. Прежде чем приступить к разработке программы для Windows CE на языке Си или Си++, нужно установить стандартную версию Visual C++ (5.0 или 6.0) для настольных ПК, а затем расширение Visual C++ для Windows CE, которое поставляет Microsoft. Оно содержит компиляторы для всех возможных ЦП, с которыми работает Windows CE, а также версии MFC и ATL, рассчитанные на устройства РПК. Это расширение позволяет составлять программы и для ПК, просто благодаря ему увеличивается перечень целевых платформ и появляется возможность разработки приложений для Windows CE. Кроме того, для компиляции Windows CE-программы, ориентированной на конкретную платформу, по-прежнему необходимы include- и lib-файлы, поэтому, если программа предназначена для стандартной горизонтальной платформы, следующим шагом будет установка конкретного комплекта SDK для нее. Такие SDK для разных платформ бесплатно предоставляет Microsoft, и их можно переписать с Web-узла компании (www.microsoft.com/windowsce/downloads/pccompanions/default.asp). В комплект поставки пакета Visual C++ для Windows CE обычно входит компакт-диск с SDK для РПК, но все же стоит проверить, нет ли на Web-узле компании более свежей версии. Для переноса Windows CE на новую аппаратную платформу Microsoft предлагает еще один инструмент — Windows CE Platform Builder — преемник набора Embedded Toolkit, который применялся в более ранних версиях Windows CE. С помощью данного инструмента можно представить операционную систему в формате библиотеки объектов, с тем чтобы разработчик разбил ее на компоненты и подготовил версию этой ОС для конкретной платформы. В состав Platform Builder входят также инструменты для формирования SDK, рассчитанного на конкретную платформу, для которой подготавливается разбитая на компоненты операционная система. Те программисты, которые разрабатывают программы для РПК или других горизонтальных платформ, вполне обойдутся без Platform Builder, но его, несомненно, стоит порекомендовать серьезным авторам Windows CE-приложений. Этот сложный набор инструментов обеспечивает бесценную информацию об архитектуре Windows CE. Позднее мы поговорим о Platform Builder подробнее. Базовый цикл разработки программА теперь приступим к разработке настоящей Windows CE-программы. Последовательность необходимых для этого шагов здесь такая же, как и при подготовке программы для Windows настольных систем. Для начала организуем новую рабочую область в окне Visual C++. Можно прибегнуть к услугам одного из множества «мастеров», призванных помочь в составлении Windows CE-программ, либо заняться этим самостоятельно, выбрав тип приложения Win32 application и установив флажки для тех процессоров, на которые, как предполагается, будет рассчитана программа. По завершении разработки проекта следует просто набрать текст программы и подготовить ресурсы, в том числе меню, пиктограммы и шаблоны диалоговых окон, почти так же, как в ходе аналогичных процедур в среде Windows 98 или Windows NT, исключение составляют вышеупомянутые отличия в API. Как было отмечено ранее, отличия эти не слишком значительны; тем не менее некоторые особенности модели программирования для Windows CE все же заслуживают внимания. Первая, и, на поверхностный взгляд, наиболее удивительная из них, — отсутствие в Windows CE меню для окон верхнего уровня. Это не означает, что Windows CE-программы не могут иметь меню, просто управление ими организуется через панель команд. Элемент управления «панель команд» и ее более сложные «сестры» — «командные полосы» — обеспечивают доступ к меню и инструментальным панелям, кроме того, предусматривают место для размещения кнопок вызова справочной системы программ Windows CE и их закрытия. Благодаря своей конструкции эти элементы управления предельно просты в программировании. На деле незамысловатая панель команд, которая обеспечивает доступ к меню и кнопкам закрытия программы, может быть представлена всего тремя строчками в тексте программы. В элементе управления «командная полоса» получила дальнейшее развитие концепция панели команд, компоненты которой, т. е. меню, кнопки и другие элементы, группируются в отдельные полосы, размещаемые на экране пользователем. Основой данного элемента служит элемент управления rebar (повторно используемая панель), разработанный для Internet Explorer 3. Еще одно отличие Windows CE-программ состоит в том, что в масштабах отдельной программы пиктограммы назначаются классам, а не экземплярам окна. Следовательно, два окна одного и того же оконного класса будут иметь одну и ту же пиктограмму. Это не играет особой роли, поскольку пиктограмма окна отображается только на соответствующей кнопке панели задач. Большинство остальных отличий, не считая уже перечисленных, касается соглашений по программированию, а не ограничений для программ или различий в реализации. Например, окна верхнего уровня в Windows CE могут содержать строки заголовка, в то время как по имеющимся соглашениям это недопустимо. Подобный запрет вызван необходимостью экономии места на крохотных экранах устройств Windows CE. В версиях Windows для настольных систем строка заголовка применяется для перемещения окна по экрану. Такой функции в Windows CE-системах чаще всего нет, так как по умолчанию окна верхнего уровня в Windows CE занимают весь экран. Здесь уместно упомянуть одну из новинок Windows CE. Начиная с версии Windows CE 2.1 диспетчер окон обзавелся средствами для работы со стандартными окнами переменного размера. Операционная система всегда обеспечивала возможность формирования окон любого фиксированного размера, однако теперь диспетчер окон позволяет окаймлять перекрывающиеся окна рамками, в результате пользователь может менять их размеры. Тем не менее даже на новых профессиональных РПК такое увидишь не часто, поскольку по умолчанию окна верхнего уровня занимают всю площадь экрана, несмотря на его относительно немалые размеры. //============================================================
// TinyCE - Небольшая программа для Windows CE
//
#include <windows.h>
#include <commctrl.h> // подключение линейки команд
LRESULT CALLBACK MainWndProc(HWND, UINT, WPARAM,LPARAM);
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
HWND hwndCB;
// Формирование панели команд.
hwndCB = CommandBar_Create (hInst, hWnd,
IDC_CMDBAR);
// Добавление кнопки закрытия программы
// в панель команд.
CommandBar_AddAdornments (hwndCB, 0, 0);
#endif // _WIN32_WCE
Конечно, подготовка текста программы составляет только часть процесса разработки. Жизненно необходим набор инструментов для отладки и тестирования программы. В ходе установки Visual C++ для Windows CE инсталлируется комплект инструментов для работы в дистанционном режиме, который поможет при отладке Windows CE-программ. В комплект входят большей частью инструменты, аналогичные своим собратьям, ориентированным на отладку Windows-программ для настольных ПК. Среди них имеются Windows CE-версии программы Regedit для редактирования системного реестра на Windows CE-устройствах; Spy для отслеживания сообщений, поступающих для окон Windows CE, и ZoomIn для проверки прорисовки изображений при их увеличении. Кроме того, комплект содержит модуль мониторинга, который позволяет отслеживать состояние процессов, исполняющихся на устройстве. Программа обеспечивает информацию о текущих потоках каждого процесса, а также о том, какие DLL загружены в ходе выполнения этого процесса. И последний инструмент — программа просмотра памяти, с помощью которой можно проверять содержимое динамических областей памяти программы (хипов). Все эти инструменты запускаются на настольном ПК и взаимодействуют с ПО удаленного клиента подключенного к нему Windows CE-устройства. Platform BuilderПодготовка программ для Windows CE — только одна сторона работы с этой операционной системой. Известно, что версии Windows для настольных машин можно переносить на другие совместимые ПК, однако права на поставку комплектов инструментов, необходимых для этих целей, принадлежат компании Microsoft и ее уполномоченным OEM-партнерам. Напротив, аналогичный набор Platform Builder для Windows CE, несмотря на его дороговизну, распространяется через розничные каналы. Таким образом, разработчики программ для Windows CE могут не только составлять программы, но и подготавливать различные версии самой операционной системы. В состав Platform Builder входят тексты образцов программ для слоя абстракции OEM (OEM abstraction layer, OAL), который представляет собой слой программ, разработанных производителем оборудования для адаптации Windows CE к конкретной аппаратуре. OAL содержит ПО слоя аппаратной абстракции (Hardware Abstraction Layer, HAL), предназначенное для обслуживания ядра Windows CE, а также драйверы для встроенных аппаратных компонентов, например клавиатуры, сенсорного экрана и дисплея. Кроме того, имеются тексты программ для образцов драйверов аудиоустройств и последовательного порта, а также драйвера контроллера PCMCIA. Комплект Platform Builder предусматривает и средства низкоуровневой отладки. Эти инструменты предназначены прежде всего для содействия в переносе Windows CE на новые аппаратные платформы, но они вполне пригодны и для диагностирования трудноустранимых проблем прикладного ПО. В новейших версиях Windows CE есть специальные программные процедуры для работы со встроенным профилировщиком Монте-Карло — весьма удобным средством оптимизации производительности программ. Наконец, Platform Builder сопровождает обширная, с точки зрения производителя оборудования, документация по эксплуатации Windows CE. Программирование в среде Windows CE — занятие довольно интересное. Интерфейс API Win32 придает этому процессу сходство с программированием для Windows 98 или NT, однако при разработке программ приходится учитывать аппаратные ограничения. Менее быстродействующие ЦП и ограниченный объем памяти большинства Windows CE-устройств заставляют тщательно продумывать подходы к программированию, чтобы повысить эффективность своих творений. На самом деле довольно забавно в наше время, т. е. в эпоху многомегабайтных программ для ПК, увидеть программистов, всерьез озабоченных быстродействием ЦП и объемами программ. |
Автор: Чиченин Александр
Источник: www.freepascal.ru/
30 августа 2007 года.
Программирование под Windows Mobile на Free Pascal
I. Введение
Портативные компьютеры становятся всё популярнее, а применяемые в них технологии всё совершеннее. Да и цена на такие устройства заметно упала. Особенно интересен факт появления таких устройств на рынке мобильной связи. Наличие доступа в Интернет делает возможным создание очень широкого круга приложений, от telnet клиента до полноценных многопользовательских игр.
Следующий раздел поможет определиться, для каких мобильных платформ возможно и для каких стоит разрабатывать софт на FPC. В разделе много информации, не имеющей прямого отношения к FPC, и много моих собственных мыслей. Если Вас не интересует техническая сторона вопроса и мои мысли — смело переходите к разделу II, посвящённому непосредственной разработке.
Версии ОС
Windows Mobile
Для начала мне бы хотелось пояснить, о чём вообще идёт речь и устранить некоторую неразбериху в терминологии.
Платформа Windows CE (WinCE или просто CE) — это операционная системная платформа для широкого круга носимых устройств, таких как КПК, коммуникаторы и смартфоны.
На базе этой платформы созданы три основных разновидности операционной системы Windows Monbile:
Windows Mobile for PocketPC — для КПК.
Windows Mobile for PocketPC Phone Edition — для коммуникаторов.
Windows Mobile for Smartphone — для смартфонов.
Кроме этого, можно встретить упоминания о Windows CE for Handheld PC (эти устройства были вытеснены гораздо более мощными ноутбуками, поэтому заострять внимание на них я не буду).
Неразбериха с версиями Windows Mobile
На сайте Microsoft в разделе для разработчиков очень часто термины Windows Mobile 6 и Embedded WinCE 6.0 встречаются не только в рамках одного раздела, но и в рамках одной статьи. Между двумя этими названиями установлено много перекрёстных ссылок и, на первый взгляд, действительно кажется, что Windows Mobile 6 построена на базе WinCE 6.0. Эффект усиливается и тем, что в предыдущей версии ОС индексы ядра и системы совпадали. Естественно, что эта информация была ошибочно трактована многими людьми, и в документации к порту FPC для WinCE содержится данная ошибка, которая, надеюсь, вскоре будет исправлена.
Факты таковы:
На данный момент (лето 2007 года), последней версией ядра дейтсвительно является Embedded WinCE 6.0 (Yamazaki), на его базе создаётся Windows Mobile 7 (Photon) — версия, начиная с которой разделения на смартфоны и коммуникаторы больше не будет.
Хотя Windows Mobile 6 и называют порой Windows Mobile Vista, на самом деле сходство у этой системы с настоящей Vista лишь внешнее, так как она базируется на обновлённом ядре пятой версии — CE 5.2. Если проводить аналогию с десктопными системами, то Windows Mobile 6 несёт на себе примерно те же маркетинговые функции, что и XP в своё время — привлечь пользователей красивым, настраиваемым интерфейсом и новыми информационными сервисами. Кроме того, даже названия версий ОС стали подобны названиям версий Windows Vista.
Windows Mobile for Smartphone = Windows Mobile 6 Standard
Windows Mobile for Pocket PC Phone Edition = Windows Mobile 6 Professional
Windows Mobile for Pocket PC = Windows Mobile 6 Classic
Платформа Embedded Windows CE 6.0 довольно сильно отличается от 5.0, но система на этой платформе пока не выпущена, поэтому обсуждать её не будем.
А как же Symbian, Embedded Linux и другие системы?
Так как темой данной статьи является Windows Mobile, я не буду долго останавливаться на этих системах, но кое-что сказать нужно.
Последней версией Symbian OS является v9.5,анонсированная в Марте 2007 года. Системой Symbian в основном оснащаются смартфоны. На официальном сайте приводится, таблица, в которой говорится, что 71.7% рынка занимает Symbian, 14.3% Embedded Linux и лишь 6.9% у Microsoft.
Но не всё на самом деле так гладко. Один крупный российский сервис предложил мне среди 73 смартфонов и коммуникаторов 40 устройств, с различными версиями Windows Mobile, 32 устройства с Symbian, и одно устройство под управлением Mizi Linux 2.5 (поэтому на Linux и остальных системах больше останавливаться не буду).
Основной проблемой Symbian является наличие четырёх основных веток развития, причём это разделение произошло уже довольно давно. В результате этого существуют различные версии SDK, да ещё и выпущенные разными производителями. Портированием такого объёма заголовочных файлов на Free Pascal пока не занимались. Хотя никто не мешает создать и порт FPC под Symbian с процессором ARM.
На чём же остановиться?
Сейчас большинство устройств (имеются в виду устройства на платформе Windows CE) оснащено Windows Mobile 5 (на базе CE 5.0). Кроме того, Windows Mobile 6 естественно очень хорошо совместима с предшественницей (платформа то почти та же). Поэтому ориентироваться при разработке, на мой взгляд, следует именно на платформу CE 5.0. Хотя встречаются и устройства с Windows Mobile 2003 (SE), и, если есть возможность, не плохо бы обеспечить совместимость и с этой системой.
Железо
Теперь поговорим об оборудовании, с которым предстоит работать.
Этот вопрос на самом деле довольно сложен: рынок портативных устройств развивается очень бурно. Количество производителей и устройств устрашающе велико и постоянно растёт. Порой производители создают и себе и другим проблемы, например меняя индексы виброзвонка и индикаторов.
Основной же проблемой для разработчика на FPC является то, что ядро Windows CE одновременно поддерживает процессоры с различной микроархитектурой: x86, ARM, MIPS, SH а теперь и Xscale.
Архитектура x86 на современных мобильных устройствах (на ядре WinCE) мне не встречалась и интереса особенного не представляет, хотя RTL и FCL собираются и под платформу WinCE.
С MIPS дело обстоит хуже: на данный момент существуют модули компилятора, но RTL, а значит и всё остальное, пока не портированы. Правда устройства с этим процессором и Windows Mobile встречаются всё реже.
SH пока не поддерживается FPC вообще. Однако на современном рынке, по крайней мере российском, данный процессор не распостранён.
А вот ARM — поддерживается FPC хорошо, и именно о нём далее пойдёт речь. Благо устройств, использующих этот процессор очень много, и разрабатывать что-либо для них на FPC — не пустая трата времени.
Разумеется, в связи с обширностью версий ARM, пока далеко не все возможности новых архитектур используются FPC в полной мере. Сказать, какую старшую версию микроядра ARM поддерживает FPC на данный момент, я не берусь — файлы компилятора, в основном, датированы 2002 и 2003 годами. В файлах компилятора упоминаний о процессорах старше ARMv5 я не обнаружил. Однако вполне вероятно, что на сегодняшний день были добавлены инструкции и из современных архитектур… но это тема уже другой статьи. В защиту компилятора, замечу только, что в SDK Windows Mobile 6 папка с заголовками API по-прежнему называется Armv4i.
Нельзя не упомянуть мощную архитектуру Intel Xscale.
Всё больше устройств на рынке используют этот процессор и, судя по всему, постепенно вытесняют устройства с ARM. Пока данный процессор не упоминается в документации к Free Pascal, однако конструкторы Xscale сделали программистам подарок: его микроархитектура использует программную модель ARMv5 TE. В результате этого Xscale обратно совместим с ARM, и разрабатывать софт для него можно и нужно на Free Pascal уже сейчас. Никаких дополнительных настроек для этого делать не нужно.
Обратите внимание, часто в описаниях указывается название Intel PXA — это тоже Xscale.
II. Разработка программ под платформу ARM-WinCE на Free Pascal
Инструментарий для сборки приложения
Замечу, что поддержку данной платформы в компилятор добавил Юрий Сидоров, часть заголовков к WinAPI добавил Oliver (Oro06), часть добавил я, а часть добавит ещё кто-то, может даже Вы.
Разрабатывать программу для Windows удобнее всего именно в Windows, поэтому дальнейшее описание касается разработки именно в этой системе.
Итак, чтобы разрабатывать софт для Windows Mobile нам потребуются следующие инструменты:
Обратите внимание, что, например, вместо записи вида:
<путь к компилятору>bini386-win32.
в Вашем случае может быть:
c:ppbini386-win32.
А) В случае если хочется иметь удобный и легко обновляемый компилятор (рекомендуемый и рабочий вариант):
1. Компилятор FPC 2.1.x или более новый, у меня, например, прекрасно работает 2.3.1 собранный прямо из SVN. Если SVN не используется, то последнюю версию исходников можно найти на http://www.freepascal.org/develop.html
После установки компилятора необходимо проверить, что в переменной окружения PATH прописан путь:
<путь к компилятору>bini386-win32;
Причём, он должен там быть раньше, чем пути к остальным FPC, если их в системе несколько. Кроме того, если в системе установлен, например, MinGW, то, если, в PATH путь к нему прописан раньше, чем к FPC, то будет использован не ld из FPC, а ld из MinGW и ничего собрать не удастся.
Поправить PATH в Windows XP можно тут:
Мой компьютер, Свойства, вкладка Дополнительно, Переменные среды, Системные переменные.
Проверить настройки, да и вообще выполнять сборку компилятора или его частей удобно через FAR, либо любой файл-менеджер с поддержкой командной строки.
2. Пакет утилит для кросс-компиляции. В него входят ld, as, ar, strip и т.д. Можно эти утилиты собрать и потом, но лично я пользуюсь уже готовым набором, взятым вот тут: ftp://ftp.freepascal.org/pub/fpc/contrib/cross/arm-wince-binutils.zip
Содержимое архива нужно распаковать в директорию с компилятором, например:
<путь к компилятору>bini386-win32.
3. Кросс-компилятор для arm. Его нужно собрать самостоятельно, но сначала соберём обычный компилятор и установим его. Для этого переходим в корневую директорию дистрибутива с исходниками, или SVN репозитория, и, если до этого, уже проводилась сборка, выполняем: make clean.
Исходники чисты, и можно собирать компилятор для i386-win32. Для этого, не долго думая, выполняем:make all и, теперь уже думая долго, ждём результатов. Если всё нормально, то последняя строка в логе будет:
echo Build > build-stamp.i386-win32.
В результате мы получаем: компилятор ppc386.exe в папке <путь к исходникам>compiler, утилиты для него, в папке <путь к исходникам>compilerutils, откомпилированные модули RTL в папке <путь к исходникам>rtlunitsi386-win32, откомпилированные модули FCL в папке <путь к исходникам>packages и различных субдиректориях.
Необходимо установить компилятор, для этого в корневой директории исходников или репозитория SVN выполним: make install. Компилятор будет установлен в директорию pp, находящуюся в корне диска, на котором лежали исходники. Однако если директория была не пуста, то инсталляция может завершиться с ошибкой, поэтому сначала удалим из директории <Ваш диск>pp все лишние папки, кроме папки bin, если в ней находится основной компилятор.
После завершения копирования всех файлов нужно снова поправить PATH, если раньше компилятор находился в другом месте.
Настала очередь кросс-компилятора, действия по сборке почти повторяют действия при сборке обычного компилятора. Сначала: make clean,
а затем: make all CPU_TARGET=arm OS_TARGET=wince. Снова долго думаем, и ждём:
echo Build > build-stamp.arm-wince.
Если ошибок нет, и лог на этом сообщении закончится — значит кросс-компилятор, RTL и FCL успешно собраны. Установка производится выполнением:
make crossinstall CPU_TARGET=arm OS_TARGET=wince
, либо
make install PP=ppcrossarm TARGET=arm-wince.
После чего сам кросс-компилятор будет размещён в той же директории что и основной, а откомпилированные модули в директории
<Ваш диск>ppunitsarm-wince.
Называться кросс-компилятор будет ppcrossarm.exe.
Если в будущем потребуется отдельно собрать установить RTL, FCL, или любой другой пакет, то можно перейти в нужную директорию дистрибутива исходников или SVN и выполнить следующие шаги:
- make clean, для очистки модулей обычного компилятора.
- make clean PP=ppcrossarm TARGET=arm-wince, для очистки модулей кросс-компилятора.
- make all, для сборки модулей обычного компилятора.
- make all PP=ppcrossarm TARGET=arm-wince, для сборки модулей кросс-компилятора.
- make install, для установки модулей обычного компилятора.
- make install PP=ppcrossarm TARGET=arm-wince, для установки модулей кросс-компилятора.
Конечно, в любой момент файлы Makefile и Makefile.fpc могут быть изменены, поэтому, в случае проблем можно их открыть и почитать. Всегда можно найти какие параметры поддерживаются и что делают.
Б) Если у Вас установлен Lazarus, и не хочется скачивать исходники компилятора:
Ранее существовало готовое дополнение, устанавливаемое поверх рабочей версии Lazarus.
Оно располагалось по адресам:
ftp://ftp.hu.freepascal.org/pub/lazarus/cross/,
http://michael-ep3.physik.uni-halle.de/Lazarus/cross/.
Но, видимо факт того, что компилятор, поставляемый в комплекте, устарел, эти автоматические установщики были удалены. Однако я решил привести здесь данные ссылки, потому что возможно через некоторое время появятся сборки с новым компилятором. Если это произойдёт — учтите, что версии используемого обычного компилятора, и кросс-компилятора из дополнения должны совпадать.
Хотя я в любом случае рекомендую воспользоваться первым вариантом и собрать компилятор самостоятельно, так как в случае возникновения проблем будет намного проще их исправить.
В независимости от варианта:
Обратите внимание, что в файле <Ваш диск>ppbini386-win32fpc.cfg должны быть строки:
# binutils prefix for cross compiling #IFDEF FPC_CROSSCOMPILING -XP$FPCTARGET- #ENDIF
Если их там нет — добавьте вручную.
Инструментарий для тестирования приложения
Разумеется, любую программу необходимо отлаживать, но отладка в Free Pascal остаётся пока вопросом скорее теоретическим, чем практическим, поэтому об этом поговорим чуть позже, а сначала я опишу шаги, которые необходимо осуществить перед началом разработки программы:
Подготовка к тестированию
Если Вы стали счастливым обладателем устройства под управлением Windows Mobile, недавно, то наверняка уже обзавелись диспетчером задач, чтобы в любое время можно было завершить сбоящую программу. Если нет — скорее обзаведитесь, без этого тестирование превратится в сущую муку, так как придётся каждый раз перезагружать устройство, а это процесс совсем не быстрый. Обязательно найдите удобный способ синхронизации с ПК через Active Sync.
Если устройства под рукой не оказалось или хочется протестировать программу под другой системой, то можно воспользоваться эмулятором.
Сам эмулятор можно скачать с сайта Microsoft по адресу:
http://www.microsoft.com/downloads/details.aspx?familyid=C62D54A5-183A-4A1E-A7E2-CC500ED1F19A&displaylang=en он называется V1Emulator.zip (867 Кб).
На этой же странице можно скачать образ Windows Mobile 5.
Кроме этого в данный момент ведётся работа над второй версией, и бету можно скачать от суда: http://www.microsoft.com/downloads/details.aspx?familyid=13F5DE85-30CD-4506-9C5B-A2068FA1EE9E&displaylang=en, называется CTP_Setup_NoNetFX.msi (1.1 Мб).
Однако загрузить в него какой либо образ системы мне на момент написания статьи не удалось. Сами образа занимают достаточно много. Локализованная на русский язык Windows Mobile 6 есть тут:
http://www.microsoft.com/downloads/details.aspx?FamilyID=38c46aa8-1dd7-426f-a913-4f370a65a582&DisplayLang=en.
Кроме этого, если на эмуляторе планируется тестировать сетевые приложения, необходимо скачать
Microsoft Virtual PC 2007, в комплекте с которым установится необходимый сетевой драйвер: http://www.microsoft.com/downloads/details.aspx?FamilyID=04d26402-3199-48a3-afa2-2dc0b40a73b6&DisplayLang=en, правда замечу, что тестирование таких приложений необходимо и в реальных условиях.
Вообще желательно скачать SDK от Microsoft, эмулятор и образа будут прилагаться в комплекте, кроме того, там много примеров и хорошая документация. Замечу, что если появятся проблемы при установке — можно воспользоваться утилитами, подобными MsiEx, для извлечения содержимого из дистрибутива.
Отладка
В данный момент Free Pascal использует для отладки GDB. Существует специальная сборка GDB именно для отладки через ActiveSync. Скачать её можно по этой ссылке: ftp://ftp.freepascal.org/pub/fpc/contrib/cross/gdb-6.4-win32-arm-wince.zip.
В архиве три файла:
- readme.txt — краткое руководство по использованию.
- gdb.exe — сам отладчик, его удобно скопировать в одну папку с компилятором.
- arm-wince-pe-stub.exe — клиентская часть, которая при отладке будет автоматически скопирована в папку gdb, в корневой директории смартфона, вместе с отлаживаемой программой.
Содержимое архива, за исключением readme.txt, рекомендую скопировать в директорию <Ваш диск>ppbini386-win32.
Среда разработки
Компилятор собран, уже сейчас можно откомпилировать программу под arm-wince и запустить на эмуляторе, но, разумеется, для серьёзного проекта одного компилятора и командной строки маловато.
Рассмотрим два основных инструмента, наверняка уже Вам знакомые:
Free Pascal IDE 1.0.10, которая установилась автоматически вместе с компилятором в папку <Ваш диск>ppbini386-win32.
При попытке сохранения нового проекта, данная среда разработки выдала Runtime Error, но проект сохранила, после чего закрылась. При втором запуске она действительно показала сохранённый проект и, после выбора платформы, успешно его собрала. А вот платформы arm-wince данная среда, судя по всему, не знает, поэтому откомпилировать ничего не получилось. Можно конечно попробовать поменять настройки в файле fpc.cfg , но я не стал тратить на это время, и Вам тратить не советую.
Lazarus 0.9.23, хотя разумеется должны будут подойти и более поздние версии. Но версии, младше 0.9.17, скорее всего не подойдут.
Итак, Lazarus. Постепенно данная среда разработки становится мощнее и стабильнее, и её использование перестало доставлять постоянные проблемы. Хотя ежедневные автоматические сборки и содержат компилятор (на данный момент FPC 2.1.5), я всё же предпочитаю использовать внешний. А если собирать Lazarus из SVN или из архива, то без внешнего компилятора вовсе не обойтись. Настроить Lazarus на работу с внешним компилятором довольно просто, для этого в меню Окружение, Настройки окружения указываем необходимый нам компилятор. В нашем случае:
<Ваш диск>ppbini386-win32ppc386.exe.
А за одно и путь к make:
<Ваш диск>ppbini386-win32make.exe.
В качестве пути к исходникам FPC, разумеется, указываем <путь к исходникам>, из которых собран компилятор.
Если планируется разрабатывать оконные приложения, используя визуальное проектирование, то сразу пересоберём LCL, а в случае использования пакетов придётся пересобрать их и, как следствие, потом и весь Lazarus. Для этого откроем меню Инструменты, Настройка сборки Lazarus.
В списке выберем необходимые компоненты и нажмём на кнопку Собрать.
Для начала достаточно пересобрать LCL.
Но это касается обычного компилятора, с кросс-компилятором есть некоторые особенности:
Во-первых, в меню Окружение, Настройки окружения указываем: <Ваш диск>ppbini386-win32ppcrossarm.exe.
Во-вторых, если используется LCL, необходимо её собрать для платформы arm-wince, для этого открываем меню Инструменты, Настройка сборки Lazarus, указываем в качестве целевой ОС — wince, а в качестве процессора — arm. Дальнейшие действия такие же, как и при обычной пересборке.
В-третьих, для каждого нового проекта необходимо открывать меню Проект, Опции компилятора и выбрать целевую платформу на вкладке Код, т.е.:
для какой ОС = WinCE,
для ЦП> = arm.
При использовании LCL необходимо так же выбрать wince на вкладке Пути в поле Тип элемента управления LCL.
Тестирование и отладка
Чтобы каждый раз после сборки не тратить много времени на ручное копирование и запуск программы на устройстве, достаточно в меню Окружение, Настройки отладчика выбрать кросс-отладчик для arm-wince, в нашем случае:
<Ваш диск>ppbini386-win32make.exe.
Теперь программа автоматически будет копироваться на устройство и запускаться.
Если отладка не требуется, и программы были небольшого размера — выключим опцию выдавать номера строк в ошибках времени выполнения, на вкладке Связывание. При этом автоматическое копирование и запуск не перестанут работать. Такой вариант обычно предпочтительнее, чем последующая обработка полученного файла утилитой arm-wince-strip.exe.
Первое приложение для Windows Mobile
Если планируется писать не визуальный сервис (даже без консоли), или использовать для вывода графики только средства WinAPI — ничего больше настраивать не нужно, можно в Lazarus создать проект Программа, выбрать целевую систему как описано выше, и подключить к нему юнит Windows.
Пример приложения, выводящего на экран стандартное окно сообщения Windows с надписью
program Project1;
{$mode objfpc}{$H+}
uses
Windows;
begin
MessageBox(0, 'Hello Mobile World', '', MB_OK);
end.
С консольными приложениями дело обстоит хуже, но FPC тут не при чём — Windows Mobile вообще не поддерживает консоль по умолчанию. На данный момент мне не известно средств, для добавления поддержки консоли на смартфон. Для КПК и коммуникаторов существует несколько разработок, например http://www.symbolictools.de/public/pocketconsole/applications/PocketCMD/
Однако я не советую тратить на это время: для того чтобы у пользователя заработала Ваша консольная программа, ему также нужно будет установить эти библиотеки. Кроме того, реализовать подобие консоли можно и в оконном приложении.
Сделаю небольшое отступление, и честно признаюсь, что пока не всё заголовочные файлы WinAPI портированы для FPC (особенно это касается в основном Смартфонов и Коммуникаторов), но работа над этим активно ведётся, и в скором времени таких проблем возникать, надеюсь, не будет.
В случае если Вами не обнаружено необходимых заголовков, вы можете сами их добавить и выслать в Мантиссу патч, либо, если не знаете, что это такое можете связаться со мной или Юрием Сидоровым.
Разработка оконных приложений вообще, и оконных приложений для Windows Mobile в частности является очень обширной темой, которую невозможно полностью осветить в рамках одной статьи, поэтому данная тема вынесена в отдельный раздел.
III. Разработка оконных приложений для Windows Mobile в Lazarus.
Программирование без визуального проектирования и LCL
WinAPI
Если Вы планируете не использовать визуальное проектирование, то никаких дальнейших действий по настройке Lazarus не требуется. Создадим не визуальный проект, подключим Windows, и, используя WinAPI, начнём создавать формы самостоятельно. API WinCE, кстати, во многом схож с API Win32.
Но в 2007 году такой подход применять не слишком выгодно, поэтому рассмотрим альтернативный вариант:
Библиотека KOL (Key Objects Library)
Библиотека KOL написана Владимиром Кладовым и портирована для Windows Mobile Юрием Сидоровым и позволяет создавать легковесные, но вполне функциональные приложения для Win32 и WinCE.
Существует сайт http://kolmck.net/rindex.htm, это сайт Владимира Кладова, на котором можно найти массу информации и документации, так же все последние новости, касающиеся Win32 версии KOL.
Ещё один сайт http://www.kolnmck.ru/start.shtml, это сайт, судя по всему поддерживаемый Мастерами Delphi, в разделе <файлы> можно скачать KOL, портированый под Windows Mobile, кроме того неплохой набор статей, применимых к KOL для Windows Mobile.
Однако скачать последнюю версию портированого KOL удобнее всего, используя SVN: http://sourceforge.net/svn/?group_id=188451. Сам проект находится по адресу http://sourceforge.net/projects/kol-ce. Если SVN отсутствует — можно воспользоваться ссылкой https://kol-ce.svn.sourceforge.net/svnroot/kol-ce/trunk/ и скачать последнюю версию KOL. Для этого удобно использовать менеджеры закачек, способные закачать сразу все файлы, находящиеся по ссылкам на странице. Я, например, использую бесплатный Download Master: http://www.westbyte.com/dm/?source=dm1.
Итак, для того чтобы использовать KOL, достаточно в Lazarus создать проект <Программа>, а затем просто добавить путь к этой библиотеке в путях поиска. В Lazarus, напомню, это делается в меню Проект, Опции компилятора, на вкладке Пути (в поле ввода Другие модули). Можно конечно один раз добавить строку -Fu<Путь к KOL> в файл <путь к компилятору>bini386-win32fpc.cfg.
Ниже приводится пример простого оконного приложения KOL.
program KOLHelloWorld;
uses Windows, KOL;
{$mode objfpc}{$H+}
var Form: PControl;
begin
Form:=NewForm(Applet,'Hello World');
Run(Form);
end.
Программирование с использованием визуального проектирования
Визуальное проектирование, разумеется, имеет очевидные преимущества, такие как высокая скорость разработки проекта и простота. Lazarus изначально создавался именно в этих целях. Вместо того чтобы, используя WinAPI или KOL, практически вслепую создавать графический интерфейс — можно конструктировать его наглядно, размещая компоненты на форме и настраивая их свойства.
LCL (Lazarus Component Library)
В силу того, что Lazarus является кроссплатформенной средой разработки, то в зависимости от используемой в системе GUI библиотеки можно выбрать соответственный набор визуальных компонентов — WidgetSet.
Этот набор реализуется LCL, и должен быть откомпилирован для целевой платформы. Как это сделать было описано в статье ранее.
Теперь просто создаём в Lazarus проект Приложение и настраиваем его для ARM и WinCE. После компиляции получаем рабочую программу, но её размер даже без отладочной информации слишком велик для использования. У меня, например, получилась программа размером 1.28 Мб. Аналогичное приложение, написанное при помощи KOL, имеет размер порядка 55 Кб.
KOL MCK (Mirror Classes Kit)
Чем больше KOL набирал свою популярность, тем больше людей хотели иметь средства, для визуального проектирования проектов, использующих KOL.
В результате был создана библиотека зеркальных классов, которые используются только на этапе конструктирования интерфейса и не попадают в конечную программу. Эта библиотека также была портирована на FPC и её можно установить в Lazarus в качестве пакета.
MCK входит в дистрибутив KOL. В портированной для WinCE версии есть пакет MirrorKOLPackage.lpk, который устанавливается в Lazarus следующим образом:
Сначала в качестве текущего компилятора выберем ppc386.exe и настроим пересборку Lazarus на платформу i386-win32.
Затем откроем пакет в меню Компоненты, Открыть файл пакета (.lpk).
Затем нажимаем на кнопку Настройки и в открывшемся диалоге, на вкладке Встраивание в IDE включаем ручную компиляцию.
После чего сохраняем пакет, и нажимаем на кнопку Установить.
Наконец в файле fpc.cfg добавляем следующие строки:
-Fu<Путь к KOL>/trunk/mck/lib/$FPCTARGET/ -Fi<Путь к KOL>/trunk/kol/
При следующем запуске Lazarus на панели компонентов появится вкладка KOL.
Теперь можно создать простое графическое приложение Lazarus и сразу сохранить его в удобную директорию. После этого на форму необходимо добавить компонент TKOLProject и в инспекторе объектов заполнить поле projectDest(имя генерируемого проекта).
Затем размещаем на форме компоненты TKOLApplet и TKOLForm и сохраняем проект. В директории проекта появится ещё один, с ним и будем работать. Откроем его и настроим Lazarus на кросс-компиляцию для ARM и WinCE. Кроме этого в путях поиска включаемых файлов добавим путь <Путь к KOL>/trunk/kol/.
Замечу, однако, что, на мой взгляд, MCK на данный момент слишком привередлив для использования, наряду с некоторой нестабильностью самого Lazarus. Поэтому работать пока не очень удобно. Так как на смартфонах у меня возникли с ним проблемы, я вообще отказался от его использования. Надеюсь, что в дальнейшем эти проблемы будут решены, а пока довольствуюсь чистым KOL.
IV. Заключение
Надеюсь, что, дочитав до этого момента, Вы имеете представление, как разрабатывать приложения для WindowsMobile. Замечу, что при разработке могут возникнуть некоторые проблемы, но общими усилиями мы сможем их решить.
Хочу сказать спасибо всем, кто помогал мне при написании данной статьи и привести ссылки на статьи других авторов, из которых Вы сможете почерпнуть дополнительную информацию:
http://wiki.freepascal.org/index.php/WinCE_port
Что может Windows CE?
Средства разработки для Windows CE
Microsoft Windows CE Toolkit for Visual Basic 6.0 и Microsoft Windows CE Toolkit for Visual C++ 6.0
Microsoft eMbedded Visual Tools
СУБД и механизмы доступа к данным
Как создать свою конфигурацию Windows CE
Несколько слов о других платформах
Заключение
Не секрет, что разнообразные мобильные устройства и «интеллектуальные»
бытовые приборы постепенно становятся частью нашей повседневной жизни, косвенным
свидетельством чему являются материалы данного спецвыпуска, да и других номеров
нашего журнала. О чем только мы не писали в последнее время — и о цифровых камерах,
и о разнообразных «обучаемых» игрушках типа Furby, и о различных электронных
органайзерах, и о роботах… Похоже, настало время рассказать о том, откуда
же берется программное обеспечение для всех этих замечательных устройств.
Обсуждение вопросов программирования мобильных устройств — тема весьма обширная,
и осветить ее полностью в рамках одной статьи невозможно. Поэтому сейчас мы
поговорим только о решениях Microsoft для мобильных устройств, а именно: об
операционной системе Windows CE, средствах разработки для этой платформы, средствах
создания различных конфигураций Windows CE и соответствующих SDK для разных
мобильных устройств, а также кратко остановимся на других платформах Microsoft,
предназначенных для встраивания в специализированные устройства. О средствах
создания приложений для мобильных устройств других производителей мы расскажем
в последующих статьях, посвященных этой теме.
Что может Windows CE?
Первая версия Windows CE, появившаяся в 1996 году, представляет собой специальную
версию Windows, предназначенную главным образом для «пользовательских» мобильных
устройств. В настоящее время существует множество типов устройств, управляемых
этой операционной системой (и еще немало их будет создано в ближайшее время),
включая игровые компьютеры типа Sega Dreamcast, различные устройства управления
и измерительные приборы, применяемые в разных отраслях промышленности и в научных
исследованиях, некоторые модели сотовых телефонов, устройства считывания штрих-кода,
цифровые камеры. Однако наиболее популярными устройствами, использующими Windows
CE, на сегодняшний день являются Pocket PC и Handheld PC (HPC).
Прежде чем говорить о создании приложений для той или иной платформы, нужно
знать, что «умеет» делать эта платформа, а именно: какие технологии она поддерживает,
как устроено в ней управление памятью, что представляет собой ее API и объекты,
какова ее графическая подсистема. Хотя в нашем журнале уже были публикации,
посвященные этой платформе, кратко рассмотрим наиболее характерные ее особенности.
Windows CE содержит набор функций и возможностей, типичных для «обычных» версий
Windows и специально подобранных так, чтобы удовлетворить требованиям, в определенной
степени противоречащим друг другу: с одной стороны, эта платформа должна предоставлять
сервисы, наиболее часто применяемые в настольных версиях Windows, а с другой
— использовать при этом как можно меньше ресурсов. Именно поэтому Windows CE
не поддерживает некоторые из редко используемых или ресурсоемких технологий
(например, выполнение 16-разрядных приложений, применение INI-файлов, использование
Messaging API, некоторые классы MFC, некоторые функции Win32, некоторые элементы
управления ActiveX).
Существенной особенностью Windows CE с точки зрения программирования является
то, что эта платформа может в общем случае использовать текстовые данные только
в виде Unicode-строк, поэтому любые внешние данные, содержащие ANSI-строки,
следует преобразовывать в формат Unicode. Из этого правила есть исключения:
во-первых, данные, передаваемые с помощью сокетов, должны содержать ANSI-строки
(причина этого заключается в том, что Winsock API не является частью Win32 API);
во-вторых, при использовании WinInet API можно пользоваться как ANSI-, так и
Unicode-строками, а также функциями WinInet API, оперирующими и тем и другим
типом данных. И наконец, третье исключение связано с файловым вводом-выводом
в приложениях, созданных с помощью Visual Basic, — в случае Windows CE соответствующие
функции Win32 API не поддерживаются, а вместо них используются вызовы метода
специально созданного для этой цели компонента ActiveX; последний же позволяет
читать и ANSI- и Unicode-данные, но записывать с его помощью можно только ANSI-строки.
Будучи в целом многозадачной операционной системой, Windows CE имеет некоторые
ограничения на число одновременно запущенных процессов (не более 32), при этом
виртуальное адресное пространство для каждого процесса составляет не 2 Гбайт,
а 32 Мбайт. Что касается поддержки многопоточности, то в Windows CE поддерживаются
все объекты синхронизации потоков — мьютексы, семафоры (только в Windows CE
3.0), события, критические секции.
Следует отметить, что способы хранения данных в Windows CE несколько отличаются
от обычных: эта операционная система позволяет хранить данные в реестре, в файловой
системе и в базах данных, при этом все три типа таких хранилищ данных (называемых
общим термином object store) содержатся в оперативной памяти и в случае Windows
CE 3.0 могут занимать до 256 Мбайт (в случае Windows CE 2.0 — только 16 Мбайт).
Структура каталогов файловой системы подобна структуре файловых систем настольных
версий Windows, за исключением того, что не поддерживаются имена дисков (A:,
C:, D:…). Отметим, однако, что Windows CE может поддерживать и обычные устройства
хранения данных, такие как гибкие диски, CD-ROM, жесткие диски, флэш-память.
Внутренние (in-process) серверы (то есть COM-серверы, выполненные в виде DLL
и выполняющиеся в адресном пространстве клиентского приложения) поддерживаются
Windows CE 2.0 и Windows CE 3.0, тогда как локальные и удаленные (out-of-process)
серверы — только Windows CE 3.0.
Как и версии Windows для настольных компьютеров, Windows CE поддерживает графический
экран, набор наиболее часто применяемых элементов пользовательского интерфейса
(кнопки, флажки и т.д.), минимальный набор диалоговых панелей общего назначения.
Однако размер графического экрана в Windows CE может быть существенно меньше,
чем у «обычных» версий Windows; так, размер экрана PocketPC составляет всего
240Ѕ350 пикселов. Что касается графических библиотек, то в этой операционной
системе поддерживается примерно 1/4 функций GDI, а начиная с версии Windows
CE 2.01 поддерживается и библиотека DirectDraw. Поддержки OpenGL в Windows CE
пока нет.
Из особенностей организации пользовательского интерфейса следует отметить поддержку
этой платформой некоторых специфических устройств ввода, характерных для мобильных
устройств, например «чувствительных» экранов (touch screens), интерпретируемых
с точки зрения программирования как обычная мышь.
И наконец, несколько слов о поддержке Internet. Все версии Windows CE поддерживают
обмен данными с помощью сокетов (и соответственно Winsock API) и по протоколам
HTTP и FTP (и соответственно WinInet API). Для Windows CE 3.0 существует Web-сервер,
поддерживающий ASP. Что касается применения Windows CE в качестве платформы
для Web-браузера, то в качестве пользовательских инструментов применяются Microsoft
Pocket Internet Explorer, созданный специально для этой платформы и поддерживающий
лишь минимально необходимый набор функций для просмотра Web-содержимого, и Internet
Explorer for Windows CE, представляющий собой адаптированную версию Microsoft
Internet Explorer 4.0 и поддерживающий фреймы, CSS, DHTML, но не поддерживающий
интерпретацию кода на скриптовых языках. Для создания собственных приложений,
позволяющих осуществлять просмотр Web-содержимого, имеется элемент управления
HTML Viewer (используемый самой Windows CE для отображения файлов справочной
системы), который можно применять в приложениях, созданных с помощью C/C++.
Завершив этот более чем краткий обзор возможностей Windows CE и поддерживаемых
этой платформой технологий, перейдем к рассмотрению вопросов, связанных с применением
средств разработки при создании приложений для нее.
Средства разработки для Windows CE
Поставив перед собой целью создание приложения для Windows CE с помощью визуальных
средств, следует отдавать себе отчет в том, что выбор подобных средств ограничен.
Многие инструментальные средства, применяемые при создании Windows-приложений,
для этой цели не годятся — они не предназначены для создания приложений, функционирующих
в условиях перечисленных выше ограничений, накладываемых на Windows API. Исключение
здесь составляют средства разработки, созданные производителем платформы, в
данном случае Visual C++ и Visual Basic.
Создавать приложения для Windows CE 2.0 можно с помощью Visual C++ 6.0 и Visual
Basic 6.0, применяя SDK для соответствующего мобильного устройства. SDK для
наиболее популярных устройств, а именно Palm-size PC, Handheld PC и Handheld
PC Pro, содержатся в продуктах Microsoft Windows CE Toolkit for Visual Basic
6.0 и Microsoft Windows CE Toolkit for Visual C++ 6.0. Для Windows CE 3.0 можно
создавать приложения как с помощью указанных выше инструментов, так и посредством
eMbedded Visual Tools 3.0 — версий Visual Basic и Visual C++, предназначенных
специально для создания таких приложений. Начнем с рассмотрения Microsoft Windows
CE Toolkit for Visual Basic 6.0, а затем перейдем к созданию приложений с помощью
eMbedded Visual Tools 3.0.
Microsoft Windows CE Toolkit for Visual Basic 6.0 и Microsoft Windows CE Toolkit for Visual C++ 6.0
Продукты Microsoft Windows CE Toolkit for Visual Basic 6.0 и Microsoft Windows
CE Toolkit for Visual C++ 6.0 доступны на рынке программного обеспечения; стоимость
каждого из них составляет примерно 200 долл. Эти продукты содержат SDK для наиболее
популярных мобильных устройств и набор утилит для управления ими (последние
доступны из сред разработки Visual C++ и Visual Basic после установки данных
продуктов).
После установки Microsoft Windows CE Toolkit for Visual Basic 6.0 и запуска
Visual Basic в диалоговой панели New Project появятся дополнительные пиктограммы
для создания проектов приложений, предназначенных для выполнения в Windows CE
2.0 (рис. 1).
При создании одного из таких проектов на экране появится диалоговая панель,
позволяющая определить параметры создаваемого приложения, в частности размеры
его главной формы и устройство, на котором будет запускаться приложение при
отладке — на эмуляторе мобильного устройства или на самом мобильном устройстве,
подключенном с помощью USB-порта, локальной сети или параллельного порта к компьютеру,
на котором ведется разработка (рис. 2).
Отметим, что, хотя разрабатывать приложения для Windows CE можно в Windows 98,
Windows NT и в Windows 2000, эмуляторы мобильных устройств в Windows 98 неработоспособны
и просто не будут установлены вместе с соответствующими SDK.
Далее можно создавать приложение примерно так же, как и обычное Windows-приложение.
Однако при использовании интерфейсных элементов и объектов, не поддерживаемых
Windows CE, поместить их на форму не удастся — в этом случае появится соответствующее
диагностическое сообщение.
Создав главную форму приложения и написав код, можно нажать кнопку Start. После
этого приложение будет загружено в мобильное устройство или в его эмулятор (который
в случае необходимости будет запущен автоматически), где его можно протестировать
(рис. 3).
Отметим, что при создании приложений, использующих внешние данные, их также
следует переносить на мобильное устройство. Более подробно о способах хранения
внешних данных и средствах их использования в приложениях для Windows CE будет
рассказано чуть позже.
В комплект Microsoft Windows CE Toolkit for Visual Basic 6.0 и Microsoft Windows
CE Toolkit for Visual С++ 6.0 входит несколько утилит, назначением которых является
манипуляция операционными системами для мобильных устройств и создаваемыми для
них приложениями:
- Heap Walker — средство просмотра областей памяти для динамически размещаемых
структур данных («куч»); - Process Viewer — средство просмотра запущенных процессов на подключенном
мобильном устройстве, позволяющее остановить любой из процессов; - Remote Registry Editor — утилита для редактирования реестров мобильного
компьютера и компьютера, на котором производится разработка приложения; - Spy — средство для слежения за окнами и сообщениями Windows CE на подключенном
мобильном устройстве; - Zoom — утилита для получения «снимков» с экрана мобильного устройства в
виде графических файлов; - Application Install Wizard — средство создания дистрибутивов созданных
приложений Visual Basic для переноса их на мобильное устройство; - Control Manager — средство для установки и конфигурации элементов управления
ActiveX для мобильных устройств.
Более подробно о применении Microsoft Windows CE Toolkit for Visual Basic 6.0
можно прочесть в статье «Microsoft Windows CE Toolkit for Visual Basic 6.0 Guided
Tour» (msdn.Microsoft.com/library/techart/vbcetour.htm или на нашем CD-ROM).
Microsoft eMbedded Visual Tools
Наиболее часто для создания приложений для Windows CE в настоящее время применяются
Microsoft eMbedded Visual Tools 3.0, представляющие собой не дополнение к Visual
Studio, а отдельный продукт, в состав которого входят eMbedded Visual C++ 3.0
и eMbedded Visual Basic 3.0, а также утилита API Text Viewer для просмотра объявлений
констант, функций и переменных и для копирования их в среду разработки eMbedded
Visual Basic.
Оба средства разработки, eMbedded Visual C++ 3.0 и eMbedded Visual Basic 3.0,
по своей функциональности сходны с соответствующими средствами разработки из
Visual Studio. В частности, eMbedded Visual C++ 3.0 позволяет создавать несколько
различных типов приложений, в том числе с использованием MFC и ATL; eMbedded
Visual Basic 3.0 дает возможность создать четыре типа приложений: приложения
без графического пользовательского интерфейса, а также приложения для трех наиболее
популярных типов мобильных устройств (Palm-size PC, Pocket PC, Handheld PC Pro
— рис. 4).
В комплект поставки eMbedded Visual Tools 3.0 входят и их эмуляторы, отладка
создаваемых приложений с помощью которых нередко оказывается более удобной даже
при наличии подключенного мобильного устройства. Напомним, что эмуляторы мобильных
устройств работоспособны только в Windows NT и Windows 2000.
Сам процесс создания приложения для одного из перечисленных выше мобильных
устройств с помощью eMbedded Visual Basic практически аналогичен созданию обычных
VB-приложений — основное различие заключается в том, что готовое приложение
запускается на выполнение на мобильном устройстве или его эмуляторе (рис.
5).
Наиболее важной особенностью eMbedded Visual Basic является, пожалуй, то, что
это средство разработки, в отличие от Visual Basic 6, не содержит компилятора
— приложения, созданные с его помощью, выполняются посредством интерпретатора,
загружаемого с помощью Pocket Visual Basic Loader (PBLoad.exe). Само интерпретируемое
приложение оказывается не зависящим от типа процессора, используемого в мобильном
устройстве, и содержится в файле с расширением *.VB. Для его выполнения требуются
библиотеки времени выполнения и другие файлы, уже зависящие от конкретного типа
устройства.
Отметим, однако, что среда времени выполнения eMbedded Visual Basic не поддерживает
некоторые синтаксические конструкции VB, в частности предложение Type. Это затрудняет
доступ к некоторым функциям API, оперирующим указателями на структуры Windows.
Решить эту проблему можно только создав DLL, реализующую нужную функциональность,
с помощью eMbedded Visual C++.
В комплект поставки Microsoft eMbedded Visual Tools 3.0 входят те же утилиты
для удаленного управления операционной системой и приложениями, что и в Microsoft
Windows CE Toolkit for Visual Basic 6.0 и Microsoft Windows CE Toolkit for Visual
C++ 6.0 — Heap Walker, Process Viewer, Remote Registry, Spy, Zoom, Application
Install Wizard, Control Manager.
СУБД и механизмы доступа к данным
Выше мы уже упоминали, что Windows CE может хранить данные в файлах, в реестре
и в базах данных, располагающихся в оперативной памяти мобильного устройства.
Если говорить об аналоге настольных СУБД (подобных Microsoft Access), то таковой
уже встроен в Windows CE. Для доступа к этой встроенной СУБД из приложений,
созданных с помощью Visual C++ и Visual Basic, применяется специальный механизм
доступа к данным — ADOCE, отличающийся от всем известного механизма ADO ограниченным
набором поддерживаемых объектов. В частности, этим механизмом не поддерживается
объект Connection, содержащий сведения о базе данных, с которой взаимодействует
данное приложение, — в случае ADOCE база данных представляет собой ту самую
встроенную СУБД. Кроме того, не поддерживается объект Command (вместо этого
для выполнения SQL-запросов следует применять метод Open), а также объект Error
и коллекция Errors — вместо них следует использовать объект Visual Basic Err.
Что касается коллекции Properties и объекта Property, то ADOCE не поддерживает
никаких дополнительных свойств своих объектов. Объекты Recordset и Field, равно
как и коллекция Fields, полностью поддерживаются ADOCE.
Отметим, что при необходимости с помощью ADOCE можно обращаться и к другим СУБД,
в частности к SQL Server for Windows CE, входящему в состав SQL Server 2000
Developer Edition. Эта серверная СУБД поддерживает широкий набор типов данных,
в частности текстовые данные в формате Unicode, Image, Money, Identity, позволяет
создавать до 32 индексов для одной таблицы, осуществлять вложенные транзакции,
вычислять агрегатные данные. Особенностью данной версии SQL Server является
то, что она позволяет одновременно обновлять данные, содержащиеся и в локальной
базе данных на мобильном устройстве, и в удаленной базе данных, управляемой
SQL Server 6.5, 7.0 или 2000 и расположенной на настольном компьютере, при этом
возможна отложенная синхронизация данных в случае, если связь с удаленным сервером
баз данных не всегда доступна. Из механизмов репликации эта СУБД поддерживает
репликацию путем слияния и удаленный доступ (Remote Data Access, RDA). Последний
позволяет приложению, использующему SQL Server для Windows CE, выполнять SQL-запросы
на удаленном сервере, а также получать в результате запросов наборы данных,
которые сохраняются в таблице на локальном сервере. Взаимодействие с удаленным
сервером может осуществляться с помощью локальной сети или через Internet по
протоколу HTTP.
SQL Server 2000 для Windows CE может выполняться под управлением Windows CE
2.11 и выше на следующих мобильных устройствах: Pocket PC, Palm-size PC, Handheld
PC Pro. Клиентские приложения для этой серверной СУБД рекомендуется создавать
с помощью eMbedded Visual Tools.
Как создать свою конфигурацию Windows CE
Выше мы говорили в основном о приложениях для HPC, HPC Pro и Pocket PC. А как
быть, если нам нужно оснастить нашими приложениями (а возможно, и операционной
системой) нестандартное устройство, например бытовой прибор собственного производства?
Очевидно, что операционная система для подобного устройства не должна содержать
ничего лишнего. Если у устройства нет клавиатуры, не нужен и ее драйвер; если
не поддерживается звук, не нужны драйверы звуковых карт и т.д. В принципе и
процессор для нестандартного мобильного устройства не обязан быть именно x86-совместимым.
Иными словами, для нестандартного устройства нужна и «нестандартная» Windows
CE.
Создание «нестандартной» Windows CE хотя и кажется на первый взгляд сложной
задачей, в действительности вполне осуществимо. Имеется продукт, специально
предназначенный для этой цели, — Windows CE Platform Builder (рис.
6). В состав последней версии этого продукта (3.0) входят eMbedded Visual
Tools, о которых уже говорилось выше.
С помощью Windows CE Platform Builder можно создать «свою» версию Windows CE
для нестандартного мобильного устройства. Этот инструмент поддерживает около
двух десятков типов процессоров (их список может быть расширен по мере выпуска
новых типов процессоров) и позволяет выбирать, будет ли включена поддержка различных
внешних устройств и тех или иных технологий, характерных для Windows (рис.
7).
После выбора состава будущей операционной системы и списка поддерживаемых процессоров
можно сразу же создать «образ» операционной системы, определить способ его переноса
на мобильное устройство, перенести его туда и загрузить.
Помимо операционной системы и ее загрузки, с помощью Platform Builder можно
создать несколько типовых проектов, позволяющих произвести их отладку, просмотреть
список процессов и потоков, исследовать эффективность работы операционной системы
(для этой цели можно применять утилиты Kernel Trcker, Remote System Information,
Remote Performance Monitor) и, при необходимости, произвести изменения в созданной
операционной системе (при этом можно вносить частичные изменения, не перенося
заново на мобильное устройство всю операционную систему). Кроме того, можно
добавить в состав операционной системы приложения, созданные с помощью eMbedded
Visual Tools.
И наконец, после создания операционной системы Platform Builder позволяет экспортировать
SDK для Visual C++ или Visual Basic. Для этой цели также имеется соответствующий
инструмент (при работе с ним, похоже, самое сложное — это написать текст лицензионного
соглашения). Полученный SDK (например, для Visual Basic) можно установить в
операционную систему, в которой ведется разработка, после чего в Visual Basic
6.0 и eMbedded Visual Basic появятся соответствующие шаблоны (рис.
8).
Более подробно на этом инструменте мы останавливаться не будем — детали его
применения интересны главным образом производителям нестандартных устройств.
Несколько слов о других платформах
Windows CE в настоящее время является отнюдь не единственной платформой Microsoft
для мобильных устройств. Из имеющихся на рынке операционных систем следует также
отметить Microsoft Windows NT Embedded 4.0. Будучи более требовательной к ресурсам,
чем Windows CE, эта операционная система предназначена для решений, требующих
большей масштабируемости, надежности и безопасности, нежели может предоставить
Windows CE. Наиболее характерные области применения этой операционной системы
— различные специализированные «интеллектуальные» устройства с повышенными требованиями
к надежности, например сетевые маршрутизаторы. По существу, эта операционная
система представляет собой Windows NT Workstation Service Pack 5, разбитую на
компоненты с целью создания различных конфигураций, в том числе конфигураций
для устройств без монитора, мыши или клавиатуры, с загрузкой с CD-ROM или из
флэш-памяти, и др.
Как и в случае Windows CE, создание конфигураций Windows NT Embedded 4.0 для
нестандартных устройств также может быть осуществлено с помощью специального
инструмента — Target Designer (рис. 9).
Помимо Target Designer, предназначенного для создания различных конфигураций
Windows NT Embedded из готовых компонентов, имеется еще один инструмент — Component
Designer, предназначенный для создания собственных компонентов, например драйверов
устройств, сервисов операционной системы, каких-либо специфических приложений.
Эти компоненты в дальнейшем могут быть интегрированы в Target Designer и включены
в создаваемые конфигурации Windows NT Embedded.
Разработку приложений для Microsoft Windows NT Embedded 4.0 рекомендуется осуществлять
с помощью Visual C++ 6.0 или Visual Basic 6.0.
И наконец, несколько слов о Windows 2000 with the Server Appliance Kit. Термин
server appliance означает сервер или иное устройство, выполняющее строго определенную
задачу (например, Web-хостинг, управление сетевым принтером и др.). Server Appliance
Kit позволяет с помощью выбора и настройки необходимых компонентов создать для
подобного устройства специальную конфигурацию Windows 2000, реализующую специфические
потребности данного устройства и минимизирующую требования к ресурсам. В частности,
с его помощью также можно создавать версии Windows 2000 для устройств без мыши,
клавиатуры и монитора. Используется Server Appliance Kit главным образом поставщиками
различного оборудования, которое оснащается встроенной операционной системой.
Заключение
В настоящей статье мы рассмотрели некоторые решения Microsoft для мобильных
устройств с точки зрения использующих их разработчиков решений. В частности,
мы рассказали о возможностях операционной системы Windows CE и степени поддержки
ею различных технологий, характерных для Windows.
Мы также рассмотрели возможные средства разработки приложений и СУБД для этой
платформы, а именно:
- Visual C++ 6.0 и Visual Basic 6.0 совместно со специализированными SDK;
- eMbedded Visual Tools 3.0;
- механизм ADOCE доступа к данным, а также СУБД, с которыми он применяется,
включая SQL Server для Windows CE.
Кроме того, мы представили вашему вниманию Windows CE Platform Builder — средство
создания различных конфигураций Windows CE и соответствующих SDK для нестандартных
мобильных устройств. Наконец, мы кратко остановились на других платформах Microsoft
для мобильных устройств и средствах их конфигурации.
О платформах и средствах создания приложений для мобильных устройств других
производителей мы расскажем в последующих статьях на эту тему.
Дополнительные материалы о продуктах и технологиях, рассмотренных в этой
статье, вы можете найти на нашем CD-ROM.
КомпьютерПресс 3’2001