Евгений Музыченко

Previous Entry Share Next Entry
WinCE и WinMobile
emuzychenko

Имея КПК на WM2003, обзаведясь автокомбайном на CE6, и подарив Алечке планшетку на CE6, повадился я пописывать для ARM. :) Опыт многолетнего программирования для Win3/9x/ME/NT/2k/XP/2k3/Vista/Win7, а также опыт по созданию не совсем тривиальных программ, работающих от Win95 до Win7, имеется, опыт копания в кривой и туповатой документации от MS тоже имеется. Исходя из этого, я оптимистично полагал, что никаких особых затруднений возникнуть не должно.

Во-первых, выяснилось, что, если документация по настольным Windows - это ужас, то документация по встроенным - это ужас-ужас-ужас. Если из основной документации явные ошибки обычно вычищают через 3-5 лет, то из этой - явно не раньше, чем через 10. Например, открываем описание функции CreateWindow:

WS_OVERLAPPEDWINDOW
Creates an overlapped window with the WS_OVERLAPPED, WS_CAPTION, WS_SYSMENU, WS_THICKFRAME, WS_MINIMIZEBOX, and WS_MAXIMIZEBOX styles.
Note:
Although WS_OVERLAPPEDWINDOW is not supported in Windows Embedded CE, the functionality can still be achieved by obtaining a bitwise OR of the style flags WS_OVERLAPPED, WS_CAPTION, WS_SYSMENU, WS_THICKFRAME, WS_MINIMIZEBOX, and WS_MAXIMIZEBOX.

Интересно, какому идиоту могло прийти в голову убрать определение WS_OVERLAPPEDWINDOW, чтобы тут же предложить определить его самостоятельно в том же самом виде?

hMenu
Handle to a menu, or specifies a child-window identifier depending on the window style. For an overlapped or pop-up window, hMenu identifies the menu to be used with the window; it can be NULL if the class menu is to be used. For a child window, hMenu specifies the child-window identifier, an integer value used by a dialog box control to notify its parent about events. The application determines the child-window identifier; it must be unique for all child windows with the same parent window.

То есть, все в порядке - меню работают, как и в самых ранних виндах 80-х годов. Пишем код, компилируем, запускаем. А хрен. Никаких ошибок - просто не работает. Пробуем так и этак - не работает. Тогда начинаем читать все подряд, и ниже находим:

Remarks
Menu bars are not supported. The hMenu parameter must be NULL, unless it is used as a child-window identifier.

Прелестно. Какого ж хера выше написано, что этот параметр что-то там identifies? Тут только одно объяснение - тупой индийский планктон, будучи уверен, что его никто никогда не проверит, скопировал описание из настольной версии, а потом, когда кто-то увидел и спохватился - добавил примечаньице.

Далее, начинаем искать способ создания оконного меню. Выясняется, что для этого есть функции и макросы CommandBar_xxx - сначала создается тулбар, потом на него вызовом CommandBar_InsertMenuBar вешается меню, либо через HMENU, либо через прямое указание ресурса. Мой мозг отказывается понимать причины, по которым они не стали поддерживать указание HMENU при создании окна - там можно было неявно создавать тулбар, обошлось бы в сотню байтов кода, зато была бы снята серьезная проблема с переносом настольных программ.

Ладно, черт с вами - создаем меню через CommandBar. В WinCE оно видно, а в WinMobile виден только пустой тулбар. На вопрос, какого черта, в MSDN уже ответов не находится. Тогда лезем в гугл, и опаньки - оказывается, они и это не поддерживали вплоть до WM5. Причем, не просто не поддерживали, а делали это тихо и по-свински - ничего не делали, а предусмотренный код ошибки не возвращали. Для создания тулбара с меню под WM придумали другую функцию - SHCreateMenuBar, которая загружает тулбар из ресурсов, а заодно может повесить на него и меню из HMENU.

Иными словами, программа для CE должна пользоваться CommandBar_xxx, а программа для WM - SHCreateMenuBar. Какого ж лешего они талдычат о совместимости на фоне такого издевательства? :) Ведь не фиг делать построить систему управления так, чтобы основные функции совпадали, а исполняющая система CE нехай создает тулбар сверху, WM - снизу, кому надо тонкостей - те либо скомпилируют под конкретную систему, либо озаботятся уточнением типа и версии системы.

Впрочем, судя по тому, что в WM5 таки добавили поддержку CommandBar_InsertMenuBar, немного мозгов в MS таки нашлось. И десяти лет не прошло, да.

Вообще, при чтении документации возникает ощущение, что писатели от MS сами давно запутались, и с трудом понимают, где идет речь о CE, а где - о Mobile... :)


  • 1
Думаю, всё проще - программисты меняются раз в год, а писатели инструкций с ними никогда не общаются...

Чтобы наворотить такое в виндовых меню - нужно менять программистов раз в неделю, причем сразу всех. :)

imho, достаточно просто аврально перебрасывать их с прожекта на прожект.

хихикс.

Да, в (мобильных) линупсах с документацией и портабельностью всё заметно лучше.

Кстати, в WM2002 некоторые вещи еще кривее сделаны. Из самого поразившего - нельзя повернуть экран без перезагрузки и нет посиксных FILE*. (про отсутствие текущего каталога промолчу)

Когда что-то не делается без перезапуска (в случае ОС - перезагрузки) - это часто объясняется необходимостью перелопачивать множество сложносвязанных данных и рассылать множество уведомлений. В ранних версиях, не рассчитанных на такие перемены, это могло оказаться неоправданно сложно - проще потребовать перезагрузки. А тут, собственно, и делать-то особо ничего не пришлось бы, там нет нужды в развесистых правках кода.

А что значит "нет FILE*"? FILE - это чисто сишный тип, на уровне системы он ни в DOS, ни в Windows никогда не существовал. А в любом сишном рантайме, где есть поддержка файлов, он, наоборот, быть обязан.

Там этого рантайма не было. Точнее, в рантайме были только винапишные CreateFile, CloseHandle и прочие из того же семейства.

перелопачивать кучу данных --- считается, что систему "тщательно писали с нуля", "аццки оптимизировали" итп. Ну и выкинули практически всё.

Кстати, FILE* в досе вполне был. Там было два способа работы с файлами - один почти аналог "FILE*", второй - open/close/write и прочее для работы с "маленькими положительными числами".

Ничего не понял. "Рантайм", в который входят функции, работающие с FILE - это CRT. Он ни к одной системе, кроме *nix'ов, прямого отношения не имеет, и в состав системы (на уровне спецификации) не входит. То, что в некоторых виндах валяется msvcrtxxx.dll, говорит исключительно о том, что он используется во внутрисистемных целях, и не более того. Никаких гарантий его наличия, как и внутреннего состава и функциональности, MS никогда не давала.

A CreateFile/CloseHandle и т.п. - это WinAPI, куда без него?

Насколько я знаю, CE изначально позиционировали для устройств "в себе", вроде банкоматов, справочных терминалов, измерительных приборов и т.п., где функции пользователя жестко ограничены. В том, что кому-то захочется поворачивать экран или менять его разрешение в произвольный момент времени, сообразили только после ее применения в компактных личных устройствах.

FILE в досе не было. Был несколько похожий интерфейс, частично слизанный с униха, но не более того.

вот я говорил про бортовой компьютер: http://www.multitronics.ru/products/univers/tc750/

да, у праворульных тойот до 2006 протокол свой собственный.

В инете пишут, что именно у праворульных, независимо от года. Ну, или, может, года с 2008 что-то совместимое пошло. А про более ранние пишут, что протокол до сих пор никто не расхакал. :(

Придется свой ELM327 брату в гараж отдавать. :)

Хотя нет, вру - таки расхакали. Надо попробовать с ELM327 и K-Line, который у меня тоже где-то без дела валялся.

мультитрониксы вскрыли его года два назад.

клево! если на твоей пойдет, можно будет и на моей попробовать.

У меня в ближайшие неделю-две все равно времени не будет - можешь взять и пробовать сам. :)

  • 1
?

Log in

No account? Create an account