Время на прочтение4 мин
Количество просмотров22K
Этот пост для настоящих программистов, которые вместо букваря учили алфавит по третьему изданию справочника по 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-устройств заставляют тщательно продумывать подходы к программированию, чтобы повысить эффективность своих творений. На самом деле довольно забавно в наше время, т. е. в эпоху многомегабайтных программ для ПК, увидеть программистов, всерьез озабоченных быстродействием ЦП и объемами программ. |
Что может 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
Программирование Windows CE
- Подписаться на тему
- Сообщить другу
- Скачать/распечатать тему
|
|
|
|
Какие языки и среды разработки есть для программирования под Windows CE? |
|
ASMerg |
|
|
>Какие языки и среды разработки есть для программирования под Windows CE? >Чем вообще отличается программирование под Windows CE от программирования под Windows? >Можно ли запускать виндовые приложения на Windows CE? |
|
EL[michlen] |
|
|
Цитата Vit @ Какие языки и среды разработки есть для программирования под Windows CE? C, C++, C#, VB, Assembler (обычно ARM, зависит от процессора устройства) и т.д. Из интерфейсов: WinAPI, MFC, WinSock и т.д. Цитата Vit @ Чем вообще отличается программирование под Windows CE от программирования под Windows? Нет некоторых API функций (правда кое-что добавлено). Ещё нужно учитывать размеры экрана (не разгуляешься ) и объём программы. Цитата Vit @ Можно ли запускать виндовые приложения на Windows CE? Нет. Цитата ASMerg @ Например, функций для работы с клавиатурой и мышью нет, т.к. в WCE они не имеют смысла. Это не так. Всё там есть. Даже hotkeys. |
|
Fester |
|
|
Цитата Можно ли запускать виндовые приложения на Windows CE? Почит твои посты и увидел, что у тебя один из последних Dell’ов. На нем, скоре всего, установлен PocketPC 4.2 .NET (или 4.1), так что можно писать на C# В этом случае некоторые программы можно будет запускать и на PC и на КПК. Опять же полной совместимости не будет так как Compact Framework отличается от простого Framework. Среды разработки eVC++ 4.0 (можно слить на заляму с microsoft.com) или MS Visual Studion 2003 (С#). Можешь еще скачать и установить OpenNETCF (тоже бесплатно). Цитата Чем вообще отличается программирование под Windows CE от программирования под Windows? Я бы скачал, что принципиально не отличаются. Надо просто больше внимания удилять ресурсам девайса. Не злоупотреблять потоками, итд. Есть некоторые ограничения на API, есть кое что новое… |
|
Strannic |
|
|
Full Member Рейтинг (т): 1 |
Подскажите, я так понял что MS Visual Studion 2005 за деньги, а еVC вроде как бесплатно? Что из них дружелюбнее? Стоит ли отдавать дань моде и писать на C# или все же остаться на родимом С++? |
|
EL[michlen] |
|
|
Цитата Strannic @ я так понял что MS Visual Studion 2005 за деньги, а еVC вроде как бесплатно? Да. Цитата Strannic @ Стоит ли отдавать дань моде и писать на C# или все же остаться на родимом С++? Смотря что. С одной стороны, в рамках .NET C# удобнее и писать на нём быстрее. С другой — у С++ больше возможностей, и он не ограничен платформой .NET. Это вопрос скорее о языках, чем о Windows CE в частности. Вот такое у меня мнение |
|
Fester |
|
|
Strannic, Visual Studio 6.0 видел? Так вот eVC — тоже самое Вообще, если пишешь для себя, то попробуй и то и другое, если же по работе, то пусть шеф думает о языке программирования (или ты и есть шеф? ) |
|
Strannic |
|
|
Full Member Рейтинг (т): 1 |
Visual Studio вообще не видел. Читая слово «Visual» решаю, что интерфейсы можно рисовать мышкой что-ли? Дело в том, что планирую посмотреть на программирования для покетов (до этого уже 2года пишу под PalmOS), т.е. переносимость проектов с одной платформы на другую меня вроде как не очень пока заботит, одно беспокоит — будет ли прога написанная для PPC2002 работать на 2005. И помнится раньше у покетов была проблема с тем что проги должны были быть откомпилены под конкретные типы процессоров, щас как с этим? Или также — что дано HP не видать Dell? |
|
bugger |
|
|
когда будешь делать инсталляшки для покетов, то увидишь, как эта проблема решается. в инсталляшку будешь ложить несколько версий бинарника, откомпиллированные под разные типы процессоров (по моему там 4, если мне не изменяет мой склероз). когда программа будет инсталлироваться на покет, то там автоматом определяется тип процессора и забирается своя версия бинарника. |
|
Strannic |
|
|
Full Member Рейтинг (т): 1 |
Не очень в курсе, поэтому такой вопрос. |
|
EL[michlen] |
|
|
Шарп для КПК работает с .NET Compact Framework. В качестве среды разработки можно использовать MS Visual Studio 2003 или 2005. Также нужен SDK. |
|
bugger |
|
|
чисто теоретически, если компакт фрэймворк будет сделан для пальмы, то программу тебе переписывать не придется. |
|
Strannic |
|
|
Full Member Рейтинг (т): 1 |
т.е. это оно http://lab.msdn.microsoft.com/express/vcsharp/default.aspx з.ы.:если у кого есть то, что нужно каждому, и кто догодался о чем я — кинь те плиз в личку. |
|
EL[michlen] |
|
|
Цитата Strannic @ т.е. это оно http://lab.msdn.microsoft.com/express/vcsharp/default.aspx Нет, нужна именно полная версия VS 2005, т.к. Express Editions не работают с CF и Windows CE. |
0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
0 пользователей:
- Предыдущая тема
- Windows CE/Mobile/Phone
- Следующая тема
[ Script execution time: 0,0363 ] [ 15 queries used ] [ Generated: 13.05.25, 23:04 GMT ]
Contents
- 1 Installing CompuLab’s SDK
- 2 Creating an Application
- 2.1 C# Application (VS2005)
- 2.1.1 Deploy a C# Application to your device
- 2.1.2 VS2005 .Net CF 2.0 Update
- 2.2 Embedded Silverlight Application (VS2005)
- 2.3 MFC Application (VS2005)
- 2.1 C# Application (VS2005)
Installing CompuLab’s SDK
In order to develop applications for Compulab’s modules, using Visual Studio 2005 (VS2005), Compulab’s SDK must be installed.
The SDK installation file is located in the Software Package.
To install the SDK, follow these steps:
- Run the <Platform name>_SDK.msi file – this will install the SDK into the Add/Remove programs within control panel and also make the platform available to Visual Studio 2005.
| The SDK installer is a wizard based installer, you can click through the default settings to install the SDK |
- On the first page of the SDK installer – Click Next
- On the second page of the SDK installer – Accept the EULA and Click Next
- On the third page (customer information) of the SDK Installer – Click Next
- On the fourth page (setup type) of the SDK Installer – Click Complete
- On the fifth page (destination folders) of the SDK Installer – Click Next
- On the Final page of the SDK installer – Click Install
- To complete the installation of the SDK – Click Finish
Creating an Application
To Deploy an application to the device an ActiveSync connection is necessary between the device and the desktop machine.
C# Application (VS2005)
- Start a new instance of Visual Studio 2005
- – you will use the new instance of Visual Studio 2005 to write and deploy your application.
- Within Visual Studio 2005 select File->New->Project
- Select Project type: Other Languages | Visual C# | Smart Device | Windows CE 5.0
- To develop an application choose Device Application
- Click OK to create the Smart Device application
- You are now ready to add controls and functionality to your form.
| Applications developed using VS2005 target the .Net Compact-Framework 2.0
To target .Net Compact-Framework 3.5 develop the application using VS2008 |
Deploy a C# Application to your device
- Press the Green play button to deploy and run the program
- From the list of available devices choose either Windows CE 5.0 device or the SDK of the device you work with
- Press Deploy
VS2005 .Net CF 2.0 Update
When deploying a C# application your breakpoints may not be hit.
To fix this, install the .Net CF 2.0 SP2 on your desktop machine
Embedded Silverlight Application (VS2005)
With the new Windows CE 6.0 R3 release, it is now possible to develop Silverlight applications for Windows CE.
Silverlight for embedded devices is based on Silverlight 2 core engine, only ported to native code.
To read more on Silverlight for Windows CE please refer to:
- Silverlight for Windows CE
- Embedded Silverlight Documentation
- Silverlight Tutorial
With Compulab’s SDK, it is possible to develop Silverlight application without the use of Platform Builder.
To build a Silverlight applications follow the steps described in MFC Application VS2005, and make sure you add the library “xamlruntime.lib” to the project’s input property under linker
MFC Application (VS2005)
After installing the SDK, you can write and deploy an MFC Smart Device application.
- Minimize the current instance of Visual Studio/Platform Builder
- Start a new instance of Visual Studio 2005
- – you will use the new instance of Visual Studio 2005 to write and deploy your application.
- Within Visual Studio 2005 select File->New->Project
- Select Project type: Visual C++ | Smart Device
- Change the Project name to MFCApp
- Click OK to create the Smart Device application.
The MFC application wizard requires that you provide information about the application you want to build, this includes the platform you want to build for, whether the application is Doc/View based etc…
| The default settings are to build an application for Pocket PC 2003 as a single document interface (SDI) application |
- Select the Platforms option on the left side of the wizard or press Next
- — The Platforms page of the wizard allows you to select which platform (SDK) the application will be built against
- – The default option is to build for Pocket PC 2003, you will need to remove Pocket PC 2003 and add the SDK you installed in the first step
-
Now that the Platform has been configured you can review/set some of the application specific options:
- Click on Application Type on the left side of the dialog.
The default option for an MFC application is to build a single document interface (Multiple Document Interface applications [MDI] are not supported on CE based devices) and to have MFC statically linked to your application. This is fine if you only have one MFC application running on a device. For this example you will change the default option to use MFC dynamically linked (ideal for supporting multiple MFC applications on the same device).
- Change use of MFC from Use MFC in a Static Library to Use MFC in a Shared DLL
Feel free to explore some of the other wizard settings for the MFC application, at this point you have configured the basic options for the application.
- Click Finish to allow the MFC application source to be generated