Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Какие могут быть объяснения такому поведению системы?

А вроде бы ни кто и не обещал для WinMobile и WinCE обязательной возможности запуска одних и тех-же бинарников несмотря на всю их родственность. По всей видимости некоторые приложения хотят наличия каких либо библиотек, специфичых для другой платформы, ну вот так по незнанию или с умылом сделали разработчики этих приложений. К тому же, если склероз не изменяет, WinMobile это WinCE5.x, а WinCE6.0 это до некоторой степени немного другое.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ> Вот и хочется практических идей, чтобы не заниматься углубленным изучением особенностей WinCE/WinMobile и не открывать в сотый раз велосипед. Может, есть какие-то сводные списки различий.

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

ЕМ>Ну и обычная винда, ежели приложение требует несуществующей DLL или несуществующей функции, об этом сообщает. Можно ли в CE как-то увидеть причину отказа в создании/загрузке процесса?

Для начала попробуйте Dependency Walker и посмотрите, все ли библиотеки есть. Например, аygshell с большой долей вероятности может отсутствовать на CE.

Если все библиотеки на месте -- запускайте под отладчиком.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Библиотеки все есть, в том числе aygshell, но я не могу посмотреть, все ли функции она экспортирует — система не дает читать файлы из ROM. Есть ли обходной путь?

ЕМ>А есть на свете отладчики, работающие без ActiveSync, через COM-порт или, на худой конец, через TCP? У этой балалайки не выведен USB Client, только USB Host. У процессора (TeleChips TCC890x) он есть, но процессор в BGA-корпусе, подпаяться нереально.

А там случайно не USB On-The-Go? Вроде-бы тогда достаточно правильного кабеля, чтобы хост превратился в клиент. Если, конечно, в прошивке есть драйвера.

А последовательный порт есть? Что в него валится?
Если вендор не отключил отладку, то может оказаться достаточно послушать системный отладочный вывод в момент запуска приложения (скорость по умолчанию — 19200, если мне склероз не изменяет. Или 38400?)

Есть отладчик в Platform Builder. Но это-то скорее всего отключено в прошивке. Если не жалко времени и есть лишних 10 гигов места -- можно поставить PB (он интегрируется с вижуалкой) и попробовать.

Если есть Bluetooth, можно поднять на девайсе ActiveSync поверх BT serial (если там конечно есть сам ActiveSync — ищите repllog.exe).

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Однако, не может быть также и ситуации, в которой каждый вендор независимо от других включает в систему свой уникальный набор функциональности. Большинство вендоров пользуется готовыми шаблонами — хоть кем-то рекомендованными, хоть у кого-то спертыми. И многие программы существуют в версиях "просто под WinCE такой-то версии", практически нигде не конкретизируются системные требования. Значит, обязаны быть и некие стандарты де-факто, о них я и спрашиваю.

Ну не знаю. Когда я с этим последний раз имел дело, получили мы от вендора SDK в котором практически ничего не было. Потыкались-потыкались, потом наконец упёрлись. Пишем, мол, вы уверены что хотите релизить продукт в таком виде? Включите хотя-бы поддержку COM, а то половина затребованной функциональности работать не будет (не говоря о сторонних приложениях). А те в ответ: мы ничего в этом не понимаем, у нас прошивками занимается один человек со стороны. Вы нам напишите чего вам не хватает. Когда он в следующий раз заедет, мы ему передадим.

Здравствуйте, Евгений Музыченко, Вы писали:

Q>>А последовательный порт есть? Что в него валится?

ЕМ>Физически у процессора порт есть, и даже виден в системе, а вот где его искать на плате — ума не приложу. Могу подключить USB-RS232, но как указать конкретный порт?

Не уверен, что отладочный вывод может работать через USB-COM. В CE5 не мог.

Q>>Если вендор не отключил отладку, то может оказаться достаточно послушать системный отладочный вывод в момент запуска приложения

ЕМ>А в какой порт оно валит по умолчанию — всегда COM1, или по выбору?

По умолчанию -- первый, но это конфигурируется в PB при создании прошивки и может переназначаться загрузчиком при запуске.

ЕМ>Удивительно только, отчего нет обычного сообщения для юзера на случай отсутствия нужных ресурсов. Этому есть какое-то разумное объяснение, или, как обычно, левая пятка MS так захотела?

Наверно решили, что во встроенной системе надо экономить ресурсы, а приложения должен ставить вендор, а не пользователь
Или, может быть, оно просто падает из-за какой-то несовместимости, а не завершается с ошибкой.

Копирую mfcce300.dll из MioPocket в каталог Windows

И вы вправду думаете что это поможет ?

Могу сразу сказать это не поможет — WinCE и WM — почти разные системы.
Грубо можно сказать что WM это частный случай CE с некоторой надстройкой (даже если архитектуры CPU одинаковы).
Некоторые CE программы могут работать под WM, но не наоборот.

Для вашего пылесоса надо пересобирать все программы с использованием родного SDK.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Вот у меня программа собирается со стандартным SDK для PocketPC 2003 от VS 2005 — по-Вашему, это "программа для WM". С чего ж она тогда работает под любой CE4/5/6, построенной для любого устройства с экраном, и имеющей COREDLL.DLL и COMMCTRL.DLL?

Работают даже на устрайствах WinCE x86 и MIPS? Или всё таки они работают лишь на части устройств WinCE, построенных на некоторых процессорах семейства ARM? Win Mobile это лишь частный случай абстрактной вещи под названием Windows CE с жёсткими требованиями к типу применяемых процессоров, устройств ввода, свойств дисплея и применяемых библиотек. Если абстрактное устройство с WinCE подпадает под эти условия, то некая программа от WindowsMobile конечно будет работать, иначе уже лотерея с шансами 50 на 50 ((с) бородатый анекдот).

ЕМ>Спасибо, я это знаю без Вас.
Если написали об этом здесь, значит не знаете, либо не знали.

ЕМ>Не делайте настолько глупых и непродуманных утверждений, смешно.
Впрочем я не собираюсь в чем либо убеждать Вас. Я просто высказал свою экспертную точку зрения .

ЕМ>С такими категоричными заявлениями вряд ли стоит намекать на "экспертность". Ну а коли намекнули — не поленитесь уж "экспертно" объяснить, каким боком к данной теме относится SDK? Вот у меня программа собирается со стандартным SDK для PocketPC 2003 от VS 2005 — по-Вашему, это "программа для WM".
Да.

ЕМ>С чего ж она тогда работает под любой CE4/5/6, построенной для любого устройства с экраном, и имеющей COREDLL.DLL и COMMCTRL.DLL?
Как вам уже обьяснили, она не работает, или работает не правильно, но в некоторых частных случаях может быть будут работать — если не используют фишки WM, и если WinCE собрана с теме же модулями (а она модульная) что и WM, на том же самом типе процессора (даже внутри ARM есть несколько семейств). Да и еще на WinCE кроме вами перечисленого нету aygshell.dll и много чего другого специфичного для WM — про это вы забыли.

ЕМ>Как, собственно, туча других программ, собранных под WM аж в начале 2000-х.
Даже для WinCE.NET (на основе WCE200) ?, не говоря уже о том что ARM — он разный, есть ARM, есть StrongARM, есть еще куча всего...

ЕМ>И чем программе, не работающей под определенной платформой CE, может помочь пересборка с SDK от этой платформы?
Помочь начать работать.

ЕМ>Боюсь, Вам имеет смысл более тщательно изучить процесс компиляции и связывания программы, дабы не делать столь глупых заявлений.
Вы и вправду меня умиляете. Давайте ка я послушаю об компиляции и линковке...


ЕМ>>>С чего ж она тогда работает под любой CE4/5/6, построенной для любого устройства с экраном, и имеющей COREDLL.DLL и COMMCTRL.DLL?
Не работает под любой. Почему то вы это не хотите понять.

ЕМ>Прямо чудеса какие-то. У меня программа работает, и совершенно правильно, и вдруг мне кто-то "объясняет", что на самом-то деле она не работает, или работает неправильно. А мне почему-то кажется, что "объясняющий" чего-то недопонимает.
Это вы не понимаете. Причем азы того, что из частного совсем не следует общее. Фундаментальный пробел.

ЕМ>Она работает не "в некоторых частных случаях", а во всех случаях, когда аппаратная и программная конфигурация платформы удовлетворяет потребностям программы. Забавно, но почему-то исключительно в отношении CE/WM наблюдается эта никому не нужная скрупулезность.
Это не только в отношении WM и WCE, но и в аналогичных вещах — почувствуйте разницу между arm-linux, arm-linux-gnueabi и arm-none-linux-eabi .

ЕМ>Зачем она — для придания себе умного вида? Внутри x86 тоже есть множество семейств, однако в отношении программы для DOS, использующей особенности i486, никому в голову не придет рассуждать о том, что это якобы "не совсем программа для DOS", равно как и в отношении программы, собранной с SDK от Win7, но в полном объеме работающей под Win95.
Простой пример — защищенный режим 386 (который также есть в 4ке и выше), программа использующая его есть "не совсем программа для DOS", хотя можно собрать такую программу, и она не всегда будет работать под ДОС. Странно что вы этого не знаете, неужели слова qemm.386, himem.sys ни о чем не говорят ?

ЕМ>"Программа для системы XXX" — это программа, реально использующая особенности именно системы XXX. С каким SDK/DDK собрана эта программа — совершенно неважно, лишь бы готовый машинный код был способен исполняться на целевой платформе. Макросов, раскрывающихся в системно-зависимые конструкции, в SDK очень мало — в подавляющем большинстве они раскрываются либо в конечный код, либо в вызов функции из DLL. Если в какой-то системе поддерживаются вся функциональность, потребная для программы — программа будет работать в этой системе.
Программа зависит от 3х вещей — это архитектура процессора, тип ОСи (WCE и WM — это разные ОСи) и ABI (соглашения о размерах типов, вызовах, способа передачи параметров и прочего). Поскольку WCE — это фактически модульный конструктор, который каждый производитель собирает как хочет, то для создания программы под эту конкретную сборку WCE необходимо использовать SDK (к этой конкретной сборке WCE). Поскольку даже содержимое coredll зависит от того какие модули были включены или убраны при сборки оси.

ЕМ>И после этого Вы претендуете на "экспертную" точку зрения?
Да. Причем, не просто претендую, а именно заявляю её.

ЕМ>"На WinCE", да будет Вам известно, бывают и aygshell, и mfccexxx, и bthutil, и winsock/ws2, и iphlpapi, и "много чего другого". А вот, скажем, Pocket Word или Pocket Excel — не бывает, ибо они уже не входят в исполняющую подсистему ОС, а идут лишь в качестве дополнительных компонент.
Спасибо кеп, если хотите список, я могу вам высласть список содержимого прошивок для WM, начиная с 2002 по 2005 системы, причем даже по некоторым конкретным моделям девайсов.

ЕМ>В тех CE, что стоят на моих устройствах, есть и aygshell, и даже IE. Что совершенно неудивительно.
IE так или иначе есть в большистве, а вот того aygshell (что WM) на вашем паровозе скорее всего нету, либо он другой.

ЕМ>Конечно. Если .NET не интегрирован в систему — ставится Compact .NET Framework, и вперед. Не работают только программы, испольющие (умышленно или нечаянно) какие-то особенности WM, присущие только ей — например, DLL поддержки тех самых дополнительных компонент, не входящих в исполняющую подсистему.
Пусть вас не смущает слово NET, оно присутвовало в названии той системы вовсе не из за дот нета (которого ЕМНИП там и не было). Я говорю про нативные приложения.

E>>не говоря уже о том что ARM — он разный, есть ARM, есть StrongARM, есть еще куча всего...

ЕМ>Ага, и x86 — он тоже разный: есть 8086, есть 80186/80286, есть 80386/80486, есть еще куча пентиумов, у каждого из которых свои особенности. И при всем этом, изрядное количество программ, собранных в 2011 году под Win7, преспокойно работает на первопне под Win95, а если совсем чуть-чуть постараться — то и на 386. И это, как ни странно, мало кого удивляет.
Есть crt внутри msvc от микрософт довольно забавная — она тестируют имеющиеся в налиции фичи с помощью cpuid "на лету". Это можно сделать только на x86 x64 архитектурах. На RISC архитектурах такого нету, поэтому есть соберете для ARM9 то на ARM5 работать не будет.

ЕМ>Очередная глупость. Не поможет ей это начать работать — поможет лишь увидеть, какие из используемых функций в целевой системе не поддерживаются. Если, конечно, требуется лишь наличие определенной функции, а не какая-либо особенность ее работы.
Может быть так что все нужные функции поддерживаются, но программа не работает или неправильно работает. Пример — лет 6 назад была ошибка в прошивке крокодила, подобного вашему, а именно delete NULL, (экспортируется coredll) ронял всю систему. В SDK был work-around, который определял обертку — свой оператор delete но уже с проверкой на NULL.

ЕМ>Я где-то утверждал, что из частного следует общее? Покажите пальцем.
Утверждали. Из того что работает конкретно у Вас, на Вашем девайсе, почему то должно работать везде. Дословно, Ваши цитаты, я думаю, найти не составляет труда.

ЕМ>С унихами я сколько-нибудь систематически не общался, за них говорить не готов. И что, там простенькая командно-строковая утилитка, не выходящая за рамки stlib/stdio, требует перекомпиляции под каждую целевую систему?
Например, потому что номера системных вызовов могут отличаться, потому что разные размеры типов у "утилитки" и glibc, разные размеры enum-ов, вообще разный используемый endianes (ARM могут быть как big-, так и little- endian. — это определяется при старте процессора), разный тип передачи параметров — только через стек или же еще и регистрами... Это касается не только мобильных/встраиваемых вещей, а также и больших систем. Причем иногда исполняемый образ даже запускается на не-целевой системе, но это не значит что он работает и работает правильно. Все те же мелочи что и с WCE (но в случае с WCE их поменьше).

ЕМ>"Программой для ОС XXX" во все времена называлась программа, предназначенная для работы под управлением ОС XXX. Если ОС XXX существует в различных конфигурациях — в документации к программе должны оговариваться необходимые свойства. Если, помимо собственно ОС, программе требуется стороннее ПО — это опять-таки оговаривается. Если программа для DOS использует защищенный режим, при этом либо сама им управляет, либо изменяет свое поведение в зависимости от наличия EMM — от этого она не перестает быть "программой для DOS".
MS-DOS по своей сути ориентирована на одну аппаратную платформу, поэтому сравнение несколько некорректно. Давайте сравним с семейством DOS-систем (не только от микрософт, напомню, что DOS — это Disk Operating System, и их было великое множество от разных производителей).

ЕМ>Не следует вводить собственной терминологии, когда есть устоявшаяся.
Покажите пальцем.

ЕМ>Если Вы вдруг забыли, то эти himem и emm386 с определенных версий являются обязательными компонентами DOS. Если программе нужен QEMM — это оговаривается отдельно, и называется "программа для DOS, требующая наличия QEMM".
Обязательными компонентами MS-DOS, а не DOS. Скажем в PTS-DOS не было emm386.

ЕМ>Коли уж Вы взяли менторский тон, то неплохо бы знать, что WM — это не ОС. Это платформа на основе ОС Windows CE, отличающася от "чистой" CE главным образом пользователькой оболочкой (тот самый shell) и конфигурацией предустановленных программ. Впрочем, с некоторых пор стало модным называть "ОС" все, что находится на компьютере "искаропки", так что я уже и не удивляюсь.
Коли Вам уже нечего стали придираться к словам, повторю — WM — это вполне конкретная OS, с конкретно заданным набором модулей, а WCE — это то, что вы называете "платформа", конструктор из которого можно собирать различные ОСи.

ЕМ>Не затруднит привести пример, какие именно размеры типов и способы передачи параметров меняются от сборки к сборке CE? Мне это реально интересно — вдруг я чего упустил, и линкер уже научился перекомпилировать функции?
Например, __int64 (middle endian) для WCE200 и __int64 (little endian) для WCE >= 300

ЕМ>Если Вы вдруг не в курсе — .dll в CE собираются из готовых .lib, а не компилируются из исходников.
Я поражен вашими откровениями. Скажите, а lib-ы откуда беруться ?

ЕМ>Замените "необходимо" на "рекомендуется", "желательно", "удобнее" и т.п., и утверждение из ложного станет истинным.
_необходимо_. И никак иначе.

ЕМ>Угу, зависит. А Вы давно интересовались, как именно и от чего именно зависит? Например, может ли существовать coredll без поддержки динамической памяти, потоков, примитивов синхронизации?
То что вы перечислили входит в core api. Это едино и неделимо.

ЕМ>Может ли в системе, допускающей запуск внешних (по отношению к прошивке) программ, не быть монтируемой файловой системы?
Легко. Программа не обязательно должна лежать на файловой системе, можно заставить ОСь считываеть ее прямо из сырой памяти. Собственно загрузчик (то что щас именуюется IPL1) так и работает — он может получить программу инициализации по serial девайсу.

ЕМ>Может ли система, поддерживающая экран, обходиться без Device Manager или Memory Mapped Files?
Опять же может, при специфичном драйвере экрана. Кстати MemoryMapped — Это опять же неотделяемая часть ядра.

ЕМ>Я вижу, что теоретизировать Вы умеете хорошо. Только, знаете ли, теория хороша для чтения лекций и приема экзаменов.
Вы реально меня веселите.

ЕМ>Если электрик ни за что не возьмется за провод без перчаток и резинового коврика — это электрик-теоретик. Электрик-практик надобность коврика и перчаток определяет по ситуации.
Казалось бы, при чем здесь WINCE ?

ЕМ>Я разве где-то говорил, что он в точности такой же? Разумеется, он там другой — этим и определяется WM-образие WM. За что, кстати, "дизайнерам" из MS нужно лишний раз оторвать руки. Они должны быть неимоверной кривизны, чтобы сделать разную обработку оконных меню в CE и WM.
Менюшки WCE и WM еще тот цветочек. Впрочем самый безобидный.

ЕМ>Люди с мало-мальски прямыми руками сделали бы в WM базовую поддержку техник работы с меню, идущих еще с 80-х годов, отображая ее на свой любимый нижний Menu Bar, чтобы универсальным программам не приходилось корячиться с обеими техниками.
Popup — там так и сделано, просто достучаться до них можно тока через черный ход. Ну есть еще куча гемороя с именно с самим нижним MenuBar, причем этот геморой зависит от версии WM.

ЕМ>Именно. И если соберу для SHx или MIPS — на ARM5 тоже работать не будет. Поэтому, когда требуется переносимая программа, ее собирают для ARM4, и она работает на ARM5 и ARM9. Это элементарно — удивительно, что Вы зачем-то заострили на этом внимание.
Если уж мы придираемся к словам, то давайте уточним что "бинарно переносимая". Потому что есть еще переносимость на уровне исходников, когда Вы можете одни и те же исходные тексты без изменения собрать как для ARM5, так и для ARM9. Очевидно, что второй вариант работать будет более оптимально, но бинарно не переносим (либо плохо переносим). Причем не факт что имеется переносимость на уровне исходников для бинарно переносимой программы.

ЕМ>Интересно, каким образом возникла эта ошибка — кто-то правил .lib от coredll? Если так — зачем? Или ошибка была в дистрибутиве CE от MS? В этом случае она должна наблюдаться во всех прошивках, сделанных из того дистрибутива.
Ошибка возникла потому после вмешательства криворуких узкоглазов при сборки прошивки. Это бывает довольно часто с такими девайсами. Потом они ее быстро фиксили заплатками в SDK, что-бы не выпускать новую прошивку.

ЕМ>В любом случае, подобный workaround в SDK — кривое решение наспех, и имеет смысл исключительно для внутренного употребления, когда на устройстве используется специальный софт, разрабатываемый узким кругом своих людей. В остальных случаях принято исправлять и обновлять прошивку.
Это суровая реальность. Практически все корейско-китайские железки — они такие по софтовой начинке.

ЕМ>Это Вы так вольно поняли данное утверждение в смысле "из частного следует общее". А смысл утверждения был в том, что программа, рассчитанная на использование только обязательных системных компонент, будет работать в любой подразумеваемой конфигурации системы. Какие именно конфигурации подразумеваются в данной дискуссии — я уже не раз упоминал.
Не будет она работать в _любой_ подразумеваемой конфигурации.

ЕМ>В отношении *nix'ов это неудивительно — они, как изначально любительские системы, закладывались на распространение программ в исходниках и пересборку под каждую целевую систему. В коммерческих системах это, слава богу, не используется. Соответственно, в виндах одной "вертикальной линии" и номера системных вызовов постоянны, и размеры типов одинаковы, и соглашения о связях тоже.
Как ни странно в виндах номера системных вызовов тоже отличаются от версии к версии. Просто винды не позволяют собирать полностью статически слинкованые программы (со статической линковкой kernel.dll или coredll.dll) — поэтому все номера системных вызовов как были внутри специальных динамических библиотек предоставляющих API так и остаются. *nix в этом плане просто предоставляет больше возможностей.

ЕМ>Ага — давайте, например, сравним с DOS от IBM для System/360. Обсудим множество подробностей, получим массу чисто риторического удовольствия. А на кой хрен, скажите на милость? Вам настолько нечем заняться, что тянет поговорить хоть о чем-то, имеющем отдаленное отношение к обсуждаемой теме?
Вы сами начали говорить о совместимости программ для DOS. Я показал что это не так.

ЕМ>Даже если и говорить о семействе DOS-систем, то лишь в рамках MS-DOS, PC-DOS и DR-DOS. Только они имели достаточно серьезное распространение, все остальные не вышли из стадии любительских поделок. А то, что большинство простых пользователей, запускавших типовые для пользователя программы (а это миллионы человек по всему миру), чаще всего даже не знало, какая из трех систем установлена на компьютере, лишний раз подтверждает их достаточно хорошую совместимость. Именно это и позволило говорить о "программах для DOS", а не о "программах для PC-DOS" (которых, безусловно, было немало, но следа в истории они не оставили).
Ошибаетесь, MS-DOS имел конечно большое распространение, но и прочии DOS системы тоже были довольно сильно распространены.

ЕМ>Ну давайте, вспомините еще пару наколенных поделок. Откуда у Вас такая стойкая тяга к ненужной мелочности? Поберегите эту мелочность для тех, кто станет провозглашать совместимость своих программ со всеми без исключения системами, когда-либо созданными для определенной аппаратной платформы.
Если я бы стал вспоминать еще и наколенные поделки — понадобилось бы написать целый том. Я пока что говорю об коммерческих системах.

ЕМ>Еще раз — не изобретайте собственной терминологии. Вот здесь WM недвусмысленно называется "платформой", а "operating system" вообще ни разу не упоминается. Вот здесь совершенно конкретно показано отношение WM, как "product", к CE, как "operating system". "Operating system" в отношении WM MS употребляет лишь в тех случаях, когда информация предназначена для тупого юзера, чтобы не смущать его различием в терминах, а CE в ней не упоминается вообще. В тех случаях, когда идет речь и о WM, и о CE, MS всегда подчеркивает, что OS — это CE.

ЕМ>Далее, поглядите, как в CE-разделах MSDN описываются многие функции:

ЕМ>Pocket PC: Windows Mobile 2000 and later
ЕМ>Smartphone: Windows Mobile 2002 and later
ЕМ>OS Versions: Windows CE 3.0 and later

ЕМ>В большинстве упоминается только "OS Versions" с "Windows CE". Тоже очень характерный штрих.
Ну вообщем микрософт всегда славилась противоречивой, неполной или искаженной документацией. Некоторые вещи в разных версиях msdn описаны прямо противоположено. Так что почему то я не удивлен.

ЕМ>Википедия того же мнения: Windows Mobile is best described as a subset of platforms based on a Windows CE.
Википедия — это продукт народного творчества. Его можно читать, но ставить в абсолют не надо.

ЕМ>Это Вы, наверное, термин "платформа" понимаете по-обывательски, как "фундамент", "основание" или что-то вроде того. А у него есть вполне определенное значение — посмотрите хоть в википедии.
Слово платформа имеет множество значений. Для того что бы мы корректно понимали друг-друга приведите пожалуйста свои определения для платформы (аппаратной, софтверной и операционной) и операционной системы.

ЕМ>Вы мне напоминаете того математика, который для прогнозирования результатов скачек разработал теорию движения сферической лошади в вакууме. Еще раз — у нас с Вами не абстрактная дискуссия обо всех теоретически возможных сборках и конфигурациях, а только о вполне определенных, которые были упомянуты ранее — типовой ARM, распространенный на пользовательских устройствах в обозримое время (скажем, 5-7 лет). В говнах мамонтов, пардон, копаться не имею никакого желания. Если Вы считаете, что middle endian и/или CE 2.0 нынче заслуживают хоть сколько-нибудь пристального внимания — приведите, пожалуйста, ссылки на сайты, где можно найти достаточное количество софта для этих платформ. Кстати, в том моем утверждении "работает под любой", к которому Вы так охотно прицепились, была оговорка — "под CE 4/5/6".
Я просто пытаюсь вам помочь исходя из своего немалого опыта разработки под WCE. И если я о чем то говорю, то это наверно имело место быть, и на этом месте получено много геммороя.

ЕМ>А lib-ы для user-mode DLLs берутся непосредственно из дистрибутива CE/PB. Я сильно подозреваю, что Вы считаете, будто PB каждую системную DLL компилирует прямо из сишных исходников. Не путайте их с модулями ядра и драйверами.
Некоторая часть WM в PB отсутсвует в исходниках, но представлена либами. Это практически большая часть шела для WM. Но это не значит что PB использует для сборки только либы. А так все _системные_ dll PB может собирать из исходников.

ЕМ>У Вас, похоже, и в области логики терминология своя. "Необходимо" означает, что для достижения работоспособности программы под определенной сборкой CE никак не обойтись без перекомпиляции с SDK от этой определенной сборки. Либо обойтись можно, но ценой таких усилий, что добывание десятков-сотен SDK и распространение аналогичного количества сборок программы окажется дешевле, чем предусмотреть в программе возможные вариации.
Для достижения работоспособности программы под определенной сборкой CE никак не обойтись без перекомпиляции с SDK от этой определенной сборки.

ЕМ>А на практике строго наоборот: мало-мальски аккуратно написанная программа, разработчик которой не просто тупо вставляет вызовы библиотечных функций в соответствии с описанием, но еще и немного представляет себе, как это все устроено, нормально работает на подавляющем большинстве пользовательских устройств, не имеющих явных косяков вроде описанного Вами (и созданного кривыми руками, а не штатным процессом сборки).
На подавляющем большинстве как раз не работает. Подавляющее большинство — это китайско-корейский вариант кастрированой WCE да еще и большей частью под mips.

ЕМ>Впрочем, для тупого кодера, пищущего программу строго по готовой спецификации, Ваше "необходимо" вполне применимо. Оговори Вы четко сферу его действия — возможно, я бы не возражал.
Программисты под windows обычно такими и являются. Хотя не все, но встретить толкового разработчика под windows довольно сложно. А с массовым приходом C# и .NET уровень еще сильнее упал.

ЕМ>Вы снова и снова проявляете чрезмерную мелочность. Коли так — хорошо: дайте, пожалуйста, ссылочку на спецификацию протокола, позволяющего передать в загрузчик WinCE по последовательному интерфейсу программу для машины Тьюринга. Ну и исполнить ее, разумеется. Только безо всяких там хитростей вроде предкомпиляции: Вы утверждали, что загрузчик может получить "программу" — вот пусть ее и получает.
Я где то говорил про программы для машины Тьюринга ? Я очень удивлен.

ЕМ>Я сказал "система, поддерживающая экран", а не "система, выполняющая программу, самостоятельно поддерживающую экран". Опишите, пожалуйста, как это сделать в PB. Его не интересует специфичность драйвера, поскольку упомянутые выше компоненты используются системными компонентами, работающими с экраном поверх сколь угодно специфичного драйвера. Выбрав в параметрах сборки "Display Support", Вы подключаете кучу других необходимых компонент, отказаться от которых сможете, лишь изрядно покопавшись ручками в конфигурации и зарезав какую-то часть функциональности.
Система, поддерживающая экран содержит в себе драйвер экрана. Мне кажется это очевидно. Вы можете добавлять в систему любые драйвера, в том числе и специфические для специфического экрана. PB даже помогает это делать. Почему Вы решили перевести разговор на "программу, самостоятельно поддерживающую экран" я не знаю. Драйвера вообще то для того и нужны, что разделить функциональность ОС от специфической переферии.


E>>Кстати MemoryMapped — Это опять же неотделяемая часть ядра.
ЕМ>Кто Вам это сказал? Уберите из сборки компоненты, нуждающиеся в них — и их не будет.
Не будет части coredll.dll которая занимается шлюзованием соотвествующих функций в вызовы ядра. В ядре все ЕМНИМ останется, там даже API c вызовами ProcExtMthds единый.

E>>Вы реально меня веселите.
ЕМ>Спасибо, Вы меня тоже умиляете.
Но все же меня веселите сильнее.

E>>Если уж мы придираемся к словам, то давайте уточним что "бинарно переносимая".
ЕМ>Именно это и подразумевалось в самом начале. В сфере программ для винды — хоть настольной, хоть карманной — изначально не ставилось требования переноса в исходниках, а вот для бинарной совместимости сделана вся необходимая поддержка. Это стандарт как де-юре, так и де-факто, и глупо лишний раз уточнять очевидное.
Дело в том что в виндах бинарная переносимость гарантируется только между одним типом платформы. Вы же почему то экстраполируете это на целое подмножество семейства платформ.

ЕМ>Впрочем, я подозреваю, что на вопрос "какая сейчас погода в Москве?" Вы непременно поучительным тоном попросите уточнить, какая именно Москва имеется в виду — то ли Московской области, то ли Псковской, то ли Тверской, а то и одна из полутора десятков штатовских Moscow.
Я сегодня был в трех районах Москвы — в одном шел дождь, в другом было солнечно, в третьем пасмурно. И есть подозрение что в Московской области погода сильно отличается от погоды в центре. Поэтому даже и незнаю что ответить.

E>> Потому что есть еще переносимость на уровне исходников, когда Вы можете одни и те же исходные тексты без изменения собрать как для ARM5, так и для ARM9. Очевидно, что второй вариант работать будет более оптимально, но бинарно не переносим (либо плохо переносим).

ЕМ>Он может работать более оптимально, но не обязан. Если оптимизатор не сможет придумать для ARM9 более эффективного кода, чем для ARM5 — с чего бы программе стать более оптимальной? А может оказаться и так, что компилятор, знающий только ARM5, генерит хороший код, а компилятор, знающий только ARM9 — отвратительный. Догадайтесь, какой вариант в этом случае будет оптимальнее.
Оптимизатор обычно работает на более высоком уровне и у него задача — оптимизация промежуточного кода, а не генерация машинного кода.

А так, в качестве примера, в последних версиях ARM-а появился векторный сопроцессор для плавающей точки. Но нашему железобетонному msvc на него как всегда по барабану — он честно делает вызов соответсвующей функции из coredll, которая по идее должна бы его задействовать, но вот не задача собрана она тем же самым компилятором и на векторный сопроцессор ей по прежнему начхать.

ЕМ>Чего они добились этим вмешательством?
Добавили новых багов, очевидно же.

Приехала от китайцев такая вот балалайка. С доступом к родному интерфейсу винды проблем не возникло — там даже с экранной клавиатуры через Win можно открыть Start Menu, а ежели подключить внешнюю, то через Alt-Tab/Alt-Esc доступны и быстрое переключение, и Task Manager.

Затык обнаружился совсем с другой стороны: некоторые приложения (2gis, AlReader, QIP, Advanced Lines), успешно работавшие у меня на Loox 720 (Pocket PC/Win Mobile 2003), под CE6 тупо не запускаются — даже экран не дергается в момент запуска, не появляется нового процесса, вообще никаких следов. Ряд других приложений (Total Commander, GPSInfo, PHM Device Manager, PHM Task Manager, PuTTY, Yandex Maps, TCPMP) работают без каких-либо нареканий. Все перечисленное скомпилировано под ARM.

Каким образом можно определить, что мешает системе запустить приложение, не выкидывая каких-либо сообщений?

Еще непонятно себя ведет CabInstl. Внешне работает совершенно нормально — позволяет выбрать исходный CAB и путь установки, показывает диалог прогресса, в котором даже что-то на доли секунды проскакивает, не выдает никаких предупреждений/ошибок ("Do not show warnings" отключено), но после этого в указанном каталоге по-прежнему пусто.

У меня было подозрение на размер системного устройства — изначально для Storage Memory был лимит в несколько сотен килобайт, но после того, как я его увеличил до 32 Мб, ничего не изменилось.

Какие могут быть объяснения такому поведению системы?

Здравствуйте, stele, Вы писали:

S>А вроде бы ни кто и не обещал для WinMobile и WinCE обязательной возможности запуска одних и тех-же бинарников несмотря на всю их родственность. По всей видимости некоторые приложения хотят наличия каких либо библиотек, специфичых для другой платформы, ну вот так по незнанию или с умылом сделали разработчики этих приложений.

Теоретически, я это сам знаю. Точно так же можно сказать, что приложение, писаное под Win95, не обязано работать в Win7, однако подавляющее большинство таки работает. Вот и хочется практических идей, чтобы не заниматься углубленным изучением особенностей WinCE/WinMobile и не открывать в сотый раз велосипед. Может, есть какие-то сводные списки различий.

Ну и обычная винда, ежели приложение требует несуществующей DLL или несуществующей функции, об этом сообщает. Можно ли в CE как-то увидеть причину отказа в создании/загрузке процесса?

S> К тому же, если склероз не изменяет, WinMobile это WinCE5.x, а WinCE6.0 это до некоторой степени немного другое.

Верно. Но оно ж декларируется, как достаточно совместимое снизу вверх, вот я и в непонятках.

Здравствуйте, quodum, Вы писали:

Q>Для начала попробуйте Dependency Walker и посмотрите, все ли библиотеки есть. Например, аygshell с большой долей вероятности может отсутствовать на CE.

Библиотеки все есть, в том числе aygshell, но я не могу посмотреть, все ли функции она экспортирует — система не дает читать файлы из ROM. Есть ли обходной путь?

Q>Если все библиотеки на месте -- запускайте под отладчиком.

А есть на свете отладчики, работающие без ActiveSync, через COM-порт или, на худой конец, через TCP? У этой балалайки не выведен USB Client, только USB Host. У процессора (TeleChips TCC890x) он есть, но процессор в BGA-корпусе, подпаяться нереально.

Здравствуйте, quodum, Вы писали:

Q>Общих списков различий не может быть хотя бы потому, что CE -- это конструктор, а WM -- это конкретная поделка, собранная из этого конструктора. Вендор волен выбирать, какие части системы будут присутствовать (включая куски WinAPI).

Однако, не может быть также и ситуации, в которой каждый вендор независимо от других включает в систему свой уникальный набор функциональности. Большинство вендоров пользуется готовыми шаблонами — хоть кем-то рекомендованными, хоть у кого-то спертыми. И многие программы существуют в версиях "просто под WinCE такой-то версии", практически нигде не конкретизируются системные требования. Значит, обязаны быть и некие стандарты де-факто, о них я и спрашиваю.

Здравствуйте, quodum, Вы писали:

Q>А там случайно не USB On-The-Go? Вроде-бы тогда достаточно правильного кабеля, чтобы хост превратился в клиент. Если, конечно, в прошивке есть драйвера.

Драйверы — меньшая проблема, их можно подсунуть и с карточки. Беда в том, что у самого процессора интерфейс OTG, но наружу торчит только 4-контактная A-розетка, поэтому, боюсь, прошивка конфигурирует контроллер в режим Host-Only.

Q>А последовательный порт есть? Что в него валится?

Физически у процессора порт есть, и даже виден в системе, а вот где его искать на плате — ума не приложу. Могу подключить USB-RS232, но как указать конкретный порт?

Q>Если вендор не отключил отладку, то может оказаться достаточно послушать системный отладочный вывод в момент запуска приложения

А в какой порт оно валит по умолчанию — всегда COM1, или по выбору?

Q>Есть отладчик в Platform Builder. Но это-то скорее всего отключено в прошивке. Если не жалко времени и есть лишних 10 гигов места -- можно поставить PB (он интегрируется с вижуалкой) и попробовать.

PB у меня стоит, но не помню, в какой конфигурации я его ставил. Я оттуда брал только заголовки и библиотеки, когда возился с драйвером от CE5.

Q>Если есть Bluetooth, можно поднять на девайсе ActiveSync поверх BT serial (если там конечно есть сам ActiveSync — ищите repllog.exe).

repllog есть, и BT есть. Спасибо за идею, попробую.

Удивительно только, отчего нет обычного сообщения для юзера на случай отсутствия нужных ресурсов. Этому есть какое-то разумное объяснение, или, как обычно, левая пятка MS так захотела?

Здравствуйте, quodum, Вы писали:

ЕМ>>А в какой порт оно валит по умолчанию — всегда COM1, или по выбору?

Q>По умолчанию -- первый, но это конфигурируется в PB при создании прошивки и может переназначаться загрузчиком при запуске.

Из реестра не управляется?

Q>Наверно решили, что во встроенной системе надо экономить ресурсы

Да, целый килобайт сэкономили.

Здравствуйте, quodum, Вы писали:

Q>Когда я с этим последний раз имел дело, получили мы от вендора SDK в котором практически ничего не было.

"Ничего не было" — это в каком смысле? Не было каких-то DLL, или сами DLL были, но не было некоторых функций, или в ядре не было каких-то модулей?

Вот, например, пытаюсь запустить игрушку Advanced Lines — вообще никакой реакции. Смотрю ее в PeInfo — говорит "mfcce300.dll not accessible". Действительно, этой DLL в системе нет. Копирую mfcce300.dll из MioPocket в каталог Windows — она там видна (до перезагрузки), но программа по-прежнему не запускается, PeInfo продолжает сообщать "mfcce300.dll not accessible". Копирую вдобавок mfcce300.dll еще и в каталог Advanced Lines рядом с его EXE — то же самое. За счет чего DLL может быть недоступна, если сам файл доступен?

С установкой CAB тоже полные непонятки. Кликаю на CAB — появляется диалог "Installing application" с progress bar'ом, через долю секунды шапка меняется на "Installing <имя приложения>", еще через долю секунды диалог закрывается. Progress bar не движется. Никакого эффекта после этого не видно — нигде не появляется новых файлов, записей в реестре, в системном списке установленных программ (там вообще пусто).

CabInstl ведет себя аналогично — отображает диалог на долю секунды, после чего тихо закрывается.

Перебрав несколько десятков CAB'ов, обнаружил, что старая оболочка ДубльГИС для WM2003 (2gisPPC_10_04_2007.cab) ведет себя иначе: выдается предупреждение о несовместимости, после принятия которого progress bar движется, и вся установка выглядит совершенно корректной (файлы скопированы, записи в реестре есть, программа в системном списке есть). Разумеется, сама программа не запускается. Удаление программы системными средствами тоже выполняется без проблем.

Получается, что совместимые программы тихо уходят в никуда, зато несовместимая ставится внешне корректно. Отчего это может быть?

Здравствуйте, eskimo82, Вы писали:

E>Могу сразу сказать это не поможет — WinCE и WM — почти разные системы.

Спасибо, я это знаю без Вас.

E>Некоторые CE программы могут работать под WM, но не наоборот.
E>Для вашего пылесоса надо пересобирать все программы с использованием родного SDK.

Не делайте настолько глупых и непродуманных утверждений, смешно.

Здравствуйте, eskimo82, Вы писали:

E>Если написали об этом здесь, значит не знаете, либо не знали.

Если обратите внимание, то первый пост на эту тему был написан два месяца назад. С тех пор я несколько расширил свои познания в области CE.

E>Я просто высказал свою экспертную точку зрения .

С такими категоричными заявлениями вряд ли стоит намекать на "экспертность". Ну а коли намекнули — не поленитесь уж "экспертно" объяснить, каким боком к данной теме относится SDK? Вот у меня программа собирается со стандартным SDK для PocketPC 2003 от VS 2005 — по-Вашему, это "программа для WM". С чего ж она тогда работает под любой CE4/5/6, построенной для любого устройства с экраном, и имеющей COREDLL.DLL и COMMCTRL.DLL? Как, собственно, туча других программ, собранных под WM аж в начале 2000-х. И чем программе, не работающей под определенной платформой CE, может помочь пересборка с SDK от этой платформы?

Здравствуйте, stele, Вы писали:

S>Работают даже на устрайствах WinCE x86 и MIPS? Или всё таки они работают лишь на части устройств WinCE, построенных на некоторых процессорах семейства ARM?

Разумеется, только на ARM — про разные системы команд здесь даже речи не заводилось.

А утверждение о том, что программа, написанная для работы под Win7, работает под Win9x/ME, NT4, 2k/XP/2003 и Vista, тоже вызовет у Вас вопрос, работает ли она на процессорах Alpha и IA64?

S>Win Mobile это лишь частный случай абстрактной вещи под названием Windows CE с жёсткими требованиями к типу применяемых процессоров, устройств ввода, свойств дисплея и применяемых библиотек. Если абстрактное устройство с WinCE подпадает под эти условия, то некая программа от WindowsMobile конечно будет работать, иначе уже лотерея с шансами 50 на 50 ((с) бородатый анекдот).

Да-да — "с точки зрения банальной эрудиции, каждый здравомыслящий индивидуум...". Зачем в сотый раз повторять формальные определения, от которых в рамках обсуждаемого вопроса нет никакого толку? Если Вам кто-то сообщает, что заедет за Вами "на машине" — Вы с равной долей вероятности ожидаете появления как легкового автомобиля, так и карьерного самосвала или седельного тягача?

WinCE для SH4, MIPS и x86 — это все-таки экзотика, как и Windows для IA64. Поэтому их можно смело опускать, подразумевая ARM. Далее, говоря об устройствах на WinCE для конечного пользователя, нет смысла подразумевать устройства, не имеющие экрана, не имеющие типового устройства ввода — тачскрина и/или клавиатуры, не имеющие базового набора компонент, обеспечивающих работу хоть каких-то программ, кроме специально разработанных для данного конкретного устройства.

Да и вообще нет смысла говорить о том, что программа, собранная обычным образом (в exe-файле), "будет" или "не будет" работать на устройстве, система в котором неспособна ее обычным образом загрузить. А про встраивание программы в прошивку я ничего не говорил.

Здравствуйте, eskimo82, Вы писали:

ЕМ>>Вот у меня программа собирается со стандартным SDK для PocketPC 2003 от VS 2005 — по-Вашему, это "программа для WM".

E>Да.

Боюсь, Вам имеет смысл более тщательно изучить процесс компиляции и связывания программы, дабы не делать столь глупых заявлений.

ЕМ>>С чего ж она тогда работает под любой CE4/5/6, построенной для любого устройства с экраном, и имеющей COREDLL.DLL и COMMCTRL.DLL?

E>Как вам уже обьяснили, она не работает, или работает не правильно

Прямо чудеса какие-то. У меня программа работает, и совершенно правильно, и вдруг мне кто-то "объясняет", что на самом-то деле она не работает, или работает неправильно. А мне почему-то кажется, что "объясняющий" чего-то недопонимает.

E>но в некоторых частных случаях может быть будут работать — если не используют фишки WM, и если WinCE собрана с теме же модулями (а она модульная) что и WM, на том же самом типе процессора (даже внутри ARM есть несколько семейств).

Она работает не "в некоторых частных случаях", а во всех случаях, когда аппаратная и программная конфигурация платформы удовлетворяет потребностям программы. Забавно, но почему-то исключительно в отношении CE/WM наблюдается эта никому не нужная скрупулезность. Зачем она — для придания себе умного вида? Внутри x86 тоже есть множество семейств, однако в отношении программы для DOS, использующей особенности i486, никому в голову не придет рассуждать о том, что это якобы "не совсем программа для DOS", равно как и в отношении программы, собранной с SDK от Win7, но в полном объеме работающей под Win95.

"Программа для системы XXX" — это программа, реально использующая особенности именно системы XXX. С каким SDK/DDK собрана эта программа — совершенно неважно, лишь бы готовый машинный код был способен исполняться на целевой платформе. Макросов, раскрывающихся в системно-зависимые конструкции, в SDK очень мало — в подавляющем большинстве они раскрываются либо в конечный код, либо в вызов функции из DLL. Если в какой-то системе поддерживаются вся функциональность, потребная для программы — программа будет работать в этой системе.

E> Да и еще на WinCE кроме вами перечисленого нету aygshell.dll и много чего другого специфичного для WM — про это вы забыли.

И после этого Вы претендуете на "экспертную" точку зрения? "На WinCE", да будет Вам известно, бывают и aygshell, и mfccexxx, и bthutil, и winsock/ws2, и iphlpapi, и "много чего другого". А вот, скажем, Pocket Word или Pocket Excel — не бывает, ибо они уже не входят в исполняющую подсистему ОС, а идут лишь в качестве дополнительных компонент.

В тех CE, что стоят на моих устройствах, есть и aygshell, и даже IE. Что совершенно неудивительно.

ЕМ>>Как, собственно, туча других программ, собранных под WM аж в начале 2000-х.

E>Даже для WinCE.NET (на основе WCE200)?

Конечно. Если .NET не интегрирован в систему — ставится Compact .NET Framework, и вперед. Не работают только программы, испольющие (умышленно или нечаянно) какие-то особенности WM, присущие только ей — например, DLL поддержки тех самых дополнительных компонент, не входящих в исполняющую подсистему.

E>не говоря уже о том что ARM — он разный, есть ARM, есть StrongARM, есть еще куча всего...

Ага, и x86 — он тоже разный: есть 8086, есть 80186/80286, есть 80386/80486, есть еще куча пентиумов, у каждого из которых свои особенности. И при всем этом, изрядное количество программ, собранных в 2011 году под Win7, преспокойно работает на первопне под Win95, а если совсем чуть-чуть постараться — то и на 386. И это, как ни странно, мало кого удивляет.

ЕМ>>И чем программе, не работающей под определенной платформой CE, может помочь пересборка с SDK от этой платформы?

E>Помочь начать работать.

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

Здравствуйте, eskimo82, Вы писали:

E>Это вы не понимаете. Причем азы того, что из частного совсем не следует общее.

Я где-то утверждал, что из частного следует общее? Покажите пальцем.

ЕМ>>Забавно, но почему-то исключительно в отношении CE/WM наблюдается эта никому не нужная скрупулезность.

E>Это не только в отношении WM и WCE, но и в аналогичных вещах — почувствуйте разницу между arm-linux, arm-linux-gnueabi и arm-none-linux-eabi .

С унихами я сколько-нибудь систематически не общался, за них говорить не готов. И что, там простенькая командно-строковая утилитка, не выходящая за рамки stlib/stdio, требует перекомпиляции под каждую целевую систему?

E>Простой пример — защищенный режим 386 (который также есть в 4ке и выше), программа использующая его есть "не совсем программа для DOS", хотя можно собрать такую программу, и она не всегда будет работать под ДОС.

"Программой для ОС XXX" во все времена называлась программа, предназначенная для работы под управлением ОС XXX. Если ОС XXX существует в различных конфигурациях — в документации к программе должны оговариваться необходимые свойства. Если, помимо собственно ОС, программе требуется стороннее ПО — это опять-таки оговаривается. Если программа для DOS использует защищенный режим, при этом либо сама им управляет, либо изменяет свое поведение в зависимости от наличия EMM — от этого она не перестает быть "программой для DOS".

Не следует вводить собственной терминологии, когда есть устоявшаяся.

E>Странно что вы этого не знаете, неужели слова qemm.386, himem.sys ни о чем не говорят ?

Если Вы вдруг забыли, то эти himem и emm386 с определенных версий являются обязательными компонентами DOS. Если программе нужен QEMM — это оговаривается отдельно, и называется "программа для DOS, требующая наличия QEMM".

E>тип ОСи (WCE и WM — это разные ОСи)

Коли уж Вы взяли менторский тон, то неплохо бы знать, что WM — это не ОС. Это платформа на основе ОС Windows CE, отличающася от "чистой" CE главным образом пользователькой оболочкой (тот самый shell) и конфигурацией предустановленных программ. Впрочем, с некоторых пор стало модным называть "ОС" все, что находится на компьютере "искаропки", так что я уже и не удивляюсь.

E>(соглашения о размерах типов, вызовах, способа передачи параметров и прочего).

Не затруднит привести пример, какие именно размеры типов и способы передачи параметров меняются от сборки к сборке CE? Мне это реально интересно — вдруг я чего упустил, и линкер уже научился перекомпилировать функции? Если Вы вдруг не в курсе — .dll в CE собираются из готовых .lib, а не компилируются из исходников.

E>Поскольку WCE — это фактически модульный конструктор, который каждый производитель собирает как хочет, то для создания программы под эту конкретную сборку WCE необходимо использовать SDK (к этой конкретной сборке WCE).

Замените "необходимо" на "рекомендуется", "желательно", "удобнее" и т.п., и утверждение из ложного станет истинным.

A>Поскольку даже содержимое coredll зависит от того какие модули были включены или убраны при сборки оси.

Угу, зависит. А Вы давно интересовались, как именно и от чего именно зависит? Например, может ли существовать coredll без поддержки динамической памяти, потоков, примитивов синхронизации? Может ли в системе, допускающей запуск внешних (по отношению к прошивке) программ, не быть монтируемой файловой системы? Может ли система, поддерживающая экран, обходиться без Device Manager или Memory Mapped Files?

ЕМ>>И после этого Вы претендуете на "экспертную" точку зрения?

E>Да. Причем, не просто претендую, а именно заявляю её.

Я вижу, что теоретизировать Вы умеете хорошо. Только, знаете ли, теория хороша для чтения лекций и приема экзаменов. Если электрик ни за что не возьмется за провод без перчаток и резинового коврика — это электрик-теоретик. Электрик-практик надобность коврика и перчаток определяет по ситуации.

E>того aygshell (что WM) на вашем паровозе скорее всего нету, либо он другой.

Я разве где-то говорил, что он в точности такой же? Разумеется, он там другой — этим и определяется WM-образие WM. За что, кстати, "дизайнерам" из MS нужно лишний раз оторвать руки. Они должны быть неимоверной кривизны, чтобы сделать разную обработку оконных меню в CE и WM. Люди с мало-мальски прямыми руками сделали бы в WM базовую поддержку техник работы с меню, идущих еще с 80-х годов, отображая ее на свой любимый нижний Menu Bar, чтобы универсальным программам не приходилось корячиться с обеими техниками.

E>соберете для ARM9 то на ARM5 работать не будет.

Именно. И если соберу для SHx или MIPS — на ARM5 тоже работать не будет. Поэтому, когда требуется переносимая программа, ее собирают для ARM4, и она работает на ARM5 и ARM9. Это элементарно — удивительно, что Вы зачем-то заострили на этом внимание.

E>Может быть так что все нужные функции поддерживаются, но программа не работает или неправильно работает. Пример — лет 6 назад была ошибка в прошивке крокодила, подобного вашему, а именно delete NULL, (экспортируется coredll) ронял всю систему. В SDK был work-around, который определял обертку — свой оператор delete но уже с проверкой на NULL.

Интересно, каким образом возникла эта ошибка — кто-то правил .lib от coredll? Если так — зачем? Или ошибка была в дистрибутиве CE от MS? В этом случае она должна наблюдаться во всех прошивках, сделанных из того дистрибутива.

В любом случае, подобный workaround в SDK — кривое решение наспех, и имеет смысл исключительно для внутренного употребления, когда на устройстве используется специальный софт, разрабатываемый узким кругом своих людей. В остальных случаях принято исправлять и обновлять прошивку.

Здравствуйте, eskimo82, Вы писали:

E>Утверждали. Из того что работает конкретно у Вас, на Вашем девайсе, почему то должно работать везде.

Это Вы так вольно поняли данное утверждение в смысле "из частного следует общее". А смысл утверждения был в том, что программа, рассчитанная на использование только обязательных системных компонент, будет работать в любой подразумеваемой конфигурации системы. Какие именно конфигурации подразумеваются в данной дискуссии — я уже не раз упоминал.

ЕМ>>И что, там простенькая командно-строковая утилитка, не выходящая за рамки stlib/stdio, требует перекомпиляции под каждую целевую систему?

E>Например, потому что номера системных вызовов могут отличаться, потому что разные размеры типов у "утилитки" и glibc, разные размеры enum-ов, вообще разный используемый endianes

В отношении *nix'ов это неудивительно — они, как изначально любительские системы, закладывались на распространение программ в исходниках и пересборку под каждую целевую систему. В коммерческих системах это, слава богу, не используется. Соответственно, в виндах одной "вертикальной линии" и номера системных вызовов постоянны, и размеры типов одинаковы, и соглашения о связях тоже.

Какой смысл теоретизировать и приводить в пример системы, не имеющие к обсуждаемой теме никакого отношения?

E>MS-DOS по своей сути ориентирована на одну аппаратную платформу, поэтому сравнение несколько некорректно. Давайте сравним с семейством DOS-систем (не только от микрософт, напомню, что DOS — это Disk Operating System, и их было великое множество от разных производителей).

Ага — давайте, например, сравним с DOS от IBM для System/360. Обсудим множество подробностей, получим массу чисто риторического удовольствия. А на кой хрен, скажите на милость? Вам настолько нечем заняться, что тянет поговорить хоть о чем-то, имеющем отдаленное отношение к обсуждаемой теме?

Даже если и говорить о семействе DOS-систем, то лишь в рамках MS-DOS, PC-DOS и DR-DOS. Только они имели достаточно серьезное распространение, все остальные не вышли из стадии любительских поделок. А то, что большинство простых пользователей, запускавших типовые для пользователя программы (а это миллионы человек по всему миру), чаще всего даже не знало, какая из трех систем установлена на компьютере, лишний раз подтверждает их достаточно хорошую совместимость. Именно это и позволило говорить о "программах для DOS", а не о "программах для PC-DOS" (которых, безусловно, было немало, но следа в истории они не оставили).

E>Обязательными компонентами MS-DOS, а не DOS. Скажем в PTS-DOS не было emm386.

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

E>Коли Вам уже нечего стали придираться к словам, повторю — WM — это вполне конкретная OS, с конкретно заданным набором модулей

Еще раз — не изобретайте собственной терминологии. Вот здесь WM недвусмысленно называется "платформой", а "operating system" вообще ни разу не упоминается. Вот здесь совершенно конкретно показано отношение WM, как "product", к CE, как "operating system". "Operating system" в отношении WM MS употребляет лишь в тех случаях, когда информация предназначена для тупого юзера, чтобы не смущать его различием в терминах, а CE в ней не упоминается вообще. В тех случаях, когда идет речь и о WM, и о CE, MS всегда подчеркивает, что OS — это CE.

Далее, поглядите, как в CE-разделах MSDN описываются многие функции:

Pocket PC: Windows Mobile 2000 and later
Smartphone: Windows Mobile 2002 and later
OS Versions: Windows CE 3.0 and later

В большинстве упоминается только "OS Versions" с "Windows CE". Тоже очень характерный штрих.

Википедия того же мнения: Windows Mobile is best described as a subset of platforms based on a Windows CE.

А если говорить о WM, как о продукте "в себе" — разумеется, он представляет собой ОС. Но здесь мы говорим о нем исключительно в свете его отношения к CE.

E>а WCE — это то, что вы называете "платформа", конструктор из которого можно собирать различные ОСи.

Это Вы, наверное, термин "платформа" понимаете по-обывательски, как "фундамент", "основание" или что-то вроде того. А у него есть вполне определенное значение — посмотрите хоть в википедии.

ЕМ>>Не затруднит привести пример, какие именно размеры типов и способы передачи параметров меняются от сборки к сборке CE?

E>Например, __int64 (middle endian) для WCE200 и __int64 (little endian) для WCE >= 300

Вы мне напоминаете того математика, который для прогнозирования результатов скачек разработал теорию движения сферической лошади в вакууме. Еще раз — у нас с Вами не абстрактная дискуссия обо всех теоретически возможных сборках и конфигурациях, а только о вполне определенных, которые были упомянуты ранее — типовой ARM, распространенный на пользовательских устройствах в обозримое время (скажем, 5-7 лет). В говнах мамонтов, пардон, копаться не имею никакого желания. Если Вы считаете, что middle endian и/или CE 2.0 нынче заслуживают хоть сколько-нибудь пристального внимания — приведите, пожалуйста, ссылки на сайты, где можно найти достаточное количество софта для этих платформ. Кстати, в том моем утверждении "работает под любой", к которому Вы так охотно прицепились, была оговорка — "под CE 4/5/6".

ЕМ>>Если Вы вдруг не в курсе — .dll в CE собираются из готовых .lib, а не компилируются из исходников.

E>Я поражен вашими откровениями. Скажите, а lib-ы откуда беруться ?

А lib-ы для user-mode DLLs берутся непосредственно из дистрибутива CE/PB. Я сильно подозреваю, что Вы считаете, будто PB каждую системную DLL компилирует прямо из сишных исходников. Не путайте их с модулями ядра и драйверами.

ЕМ>>Замените "необходимо" на "рекомендуется", "желательно", "удобнее" и т.п., и утверждение из ложного станет истинным.

E>_необходимо_. И никак иначе.

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

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

Впрочем, для тупого кодера, пищущего программу строго по готовой спецификации, Ваше "необходимо" вполне применимо. Оговори Вы четко сферу его действия — возможно, я бы не возражал.

ЕМ>>Может ли в системе, допускающей запуск внешних (по отношению к прошивке) программ, не быть монтируемой файловой системы?

E>Легко. Программа не обязательно должна лежать на файловой системе, можно заставить ОСь считываеть ее прямо из сырой памяти. Собственно загрузчик (то что щас именуюется IPL1) так и работает — он может получить программу инициализации по serial девайсу.

Вы снова и снова проявляете чрезмерную мелочность. Коли так — хорошо: дайте, пожалуйста, ссылочку на спецификацию протокола, позволяющего передать в загрузчик WinCE по последовательному интерфейсу программу для машины Тьюринга. Ну и исполнить ее, разумеется. Только безо всяких там хитростей вроде предкомпиляции: Вы утверждали, что загрузчик может получить "программу" — вот пусть ее и получает.

ЕМ>>Может ли система, поддерживающая экран, обходиться без Device Manager или Memory Mapped Files?

E>Опять же может, при специфичном драйвере экрана.

Я сказал "система, поддерживающая экран", а не "система, выполняющая программу, самостоятельно поддерживающую экран". Опишите, пожалуйста, как это сделать в PB. Его не интересует специфичность драйвера, поскольку упомянутые выше компоненты используются системными компонентами, работающими с экраном поверх сколь угодно специфичного драйвера. Выбрав в параметрах сборки "Display Support", Вы подключаете кучу других необходимых компонент, отказаться от которых сможете, лишь изрядно покопавшись ручками в конфигурации и зарезав какую-то часть функциональности.

E>Кстати MemoryMapped — Это опять же неотделяемая часть ядра.

Кто Вам это сказал? Уберите из сборки компоненты, нуждающиеся в них — и их не будет.

E>Вы реально меня веселите.

Спасибо, Вы меня тоже умиляете.

E>Если уж мы придираемся к словам, то давайте уточним что "бинарно переносимая".

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

Впрочем, я подозреваю, что на вопрос "какая сейчас погода в Москве?" Вы непременно поучительным тоном попросите уточнить, какая именно Москва имеется в виду — то ли Московской области, то ли Псковской, то ли Тверской, а то и одна из полутора десятков штатовских Moscow.

E> Потому что есть еще переносимость на уровне исходников, когда Вы можете одни и те же исходные тексты без изменения собрать как для ARM5, так и для ARM9. Очевидно, что второй вариант работать будет более оптимально, но бинарно не переносим (либо плохо переносим).

Он может работать более оптимально, но не обязан. Если оптимизатор не сможет придумать для ARM9 более эффективного кода, чем для ARM5 — с чего бы программе стать более оптимальной? А может оказаться и так, что компилятор, знающий только ARM5, генерит хороший код, а компилятор, знающий только ARM9 — отвратительный. Догадайтесь, какой вариант в этом случае будет оптимальнее.

E>Ошибка возникла потому после вмешательства криворуких узкоглазов при сборки прошивки.

Чего они добились этим вмешательством?

Здравствуйте, eskimo82, Вы писали:

E>Не будет она работать в _любой_ подразумеваемой конфигурации.

Хорошо, уважаемый буквоед: в подразумеваемой конфигурации она будет работать ровно в том же смысле, что и программа для Windows, для которой заявлены требования "32-разрядная система Windows версии 4.0 или выше, 64 Кб ОЗУ, 10 Мб свободного дискового пространства, наличие доступа к Интернету". То есть, в любой исправной и корректно работающей конфигурации, удовлетворяющей этому описанию, она работать будет, а на какой-нибудь самопальной сборке, с кривым антивирусом-экраном и самопальной системой учета ресурсов — может и не работать. Устроит?

E>Вы сами начали говорить о совместимости программ для DOS. Я показал что это не так.

"Не так" это ровно в той же мере, в какой ложно утверждение типа "телефон включается нажатием на кнопку". Исправный телефон, имеющий питание, всегда включается при нажатии на кнопку. Если не включается — это авария, сбой, нештатная ситуация, которая у грамотно сделанных телефонов чрезвычайно редка. С программами то же самое — из тысяч грамотно сделанных программ для DOS максимум единицы давали сбои при переносе из MS-DOS в PC-DOS или наоборот.

E>Ошибаетесь, MS-DOS имел конечно большое распространение, но и прочии DOS системы тоже были довольно сильно распространены.

И какое же, по-Вашему, "сильное распространение" имел тот же PTS-DOS?

E>Википедия — это продукт народного творчества. Его можно читать, но ставить в абсолют не надо.

В википедии многие вещи написаны гораздо лучше, чем в той же MSDN. Просто потому, что MSDN давно пишут индусы, а в википедии статьи делаются в основном грамотными людьми. Не следует думать, будто в википедию можно написать любую чушь, и она будет там сколько-нибудь долго существовать.

E>Слово платформа имеет множество значений. Для того что бы мы корректно понимали друг-друга приведите пожалуйста свои определения для платформы (аппаратной, софтверной и операционной) и операционной системы.

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

E>Я просто пытаюсь вам помочь исходя из своего немалого опыта разработки под WCE. И если я о чем то говорю, то это наверно имело место быть, и на этом месте получено много геммороя.

Когда пытаются помочь — указывают на конкретные проблемы и дают рекомендации, позволяющие оптимально эти проблемы обойти. А у Вас я пока вижу исключительно стремление свысока поучать делать "как положено". В точности как те два электрика: пока теоретик будет объяснять, что никоим образом нельзя браться за провод, если не отключен рубильник, а щиток с рубильником заперт на ключ, который находится в конторе, поэтому нужно обязательно написать в контору заявление на получение ключа, дождаться, пока оттуда придет уполномоченный человек, откроет щиток и т.п. А практик тупо прикинет, насколько оправданно работать под током в данной конкретной ситуации, и сделает за пять минут, не подвергая ни себя, ни электросеть сколько-нибудь заметному риску.

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

E>Некоторая часть WM в PB отсутсвует в исходниках, но представлена либами.

"Некоторая часть" — это сильно. Фактически, эта "некоторая часть" — все, за исключением драйверов, загрузчика и некоторых аппаратно-зависимых модулей.

E>Это практически большая часть шела для WM. Но это не значит что PB использует для сборки только либы. А так все _системные_ dll PB может собирать из исходников.

Собирать-то он, возможно, и может, да только где он их возьмет-то? Приведите, пожалуйста, имена каталогов, в которых находится полный комплект исходников для сборки хотя бы coredll, commctrl, commdlg и aygshell. Только не ссылайтесь, ради бога, на исходники, которые впервые стали доступны в CE6, предоставляются в основном для ознакомления, и установка которых сугубо опциональна.

E>Для достижения работоспособности программы под определенной сборкой CE никак не обойтись без перекомпиляции с SDK от этой определенной сборки.

Если под "определенной" понимается достаточно редкая сборка — соглашусь, такое вполне возможно. Если Вы продолжаете утверждать, что такое встречается сплошь и рядом — тогда наверняка не затруднит накидать хотя бы десяток примеров (разных сборок — тысячи, это будет всего один процент). Можно в качестве ссылок на публикации вида "у меня не работало под XXX — нашел SDK, пересобрал, теперь все работает, проблема была в YYY". Если даже десятка примеров не найдется — это значит, что Вы сильно переоцениваете возможную несовместимость.

E>Подавляющее большинство — это китайско-корейский вариант кастрированой WCE да еще и большей частью под mips.

Господи, да где Вы берете такую статистику? Приведите источники, из которых следует, что сколько-нибудь значительная часть имеющихся в обороте интерактивных (с клавиатурой/экраном) пользовательских устройств с WinCE сделана на MIPS. Я вот наблюдаю исключительное и подавляющее господство ARM.

И кастрированы китайско-корейские CE в основном в отношении поддержки Bluetooth, COM/DCOM, Shell API, Internet API и прочих надстроек, без которых рядовая программа легко может обойтись. Ну а ежели у кого даже простейшая программа требует .NET Framework — так это исключительно показатель степени квалификации и лени разработчика.

EM>Вы утверждали, что загрузчик может получить "программу" — вот пусть ее и получает.

E>Я где то говорил про программы для машины Тьюринга? Я очень удивлен.

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

E>Система, поддерживающая экран содержит в себе драйвер экрана. Мне кажется это очевидно.

Это Вам, с Вашей личной терминологией, очевидно. А с точки зрения устоявшейся терминологии очевидно, что наличие в системе драйвера какого-либо устройства означает лишь поддержку этого устройства драйвером, но никак не системой. Поддержка устройства системой означает, что система имеет собственные средства взаимодействия с таким устройством, а чаще — с классом устройств, которые могут опираться на драйверы уже конкретных устройств.

Для Winows CE же очевидно, что "поддержка экрана системой" определяется опцией "Display Support", а не просто наличием в составе системы драйвера какого-то экранного устройства.

E>Почему Вы решили перевести разговор на "программу, самостоятельно поддерживающую экран" я не знаю.

Странно. Каким образом Вы представляете себе работу программы с экраном, если системная поддержка экрана отсутствует? В этих условиях программа может лишь взаимодействовать непосредственно с драйвером, который не знает, что такое "окно", "контекст", "перо", "кисть", "шрифт" и т.п. Это не я перевел — это был единственно возможный вариант работы программы при отсутствии поддержки экрана в системе. Кроме, разумеется, прямого взаимодействия с контроллером.

E>Дело в том что в виндах бинарная переносимость гарантируется только между одним типом платформы.

Меня не интересует то, что гарантируется. Интересует исключительно то, что достижимо реально. А реально нет никаких проблем сделать достаточно сложную программу, которая будет бинарно переносима под любую 32-разрядную настольную винду от Win95 до Win7, и таких программ существует множество.

Опыта программирования под CE/WM у меня мало, поэтому я и начал эту тему с вопросов о том, что реально (а не формально) нужно для обеспечения бинарной переносимости. Поучения в духе "необходимо пересобрать с SDK" меня не интересуют совершенно. Есть, что сказать по делу — с удовольствием выслушаю и приму с благодарностью. В менторстве упражняйтесь с кем-нибудь другим.

E>Я сегодня был в трех районах Москвы — в одном шел дождь, в другом было солнечно, в третьем пасмурно.

И что, ни в одном не было температуры ниже десяти или выше тридцати пяти? Странно.

E>Оптимизатор обычно работает на более высоком уровне и у него задача — оптимизация промежуточного кода, а не генерация машинного кода.

И много Вы знаете компиляторов, в которых оптимизатор и генератор кода независимы и взаимозаменяемы? Например, есть у Вас старый компилятор под ARM5 с хорошим оптимизатором, но Вам горит сделать код под ARM9, который только-только пошел в серию, и кодогенератор под него на данный момент есть только в одном несложном компиляторе, оптимизатор у которого никакой. Как будете изворачиваться?

E>в последних версиях ARM-а появился векторный сопроцессор для плавающей точки. Но нашему железобетонному msvc на него как всегда по барабану — он честно делает вызов соответсвующей функции из coredll, которая по идее должна бы его задействовать, но вот не задача собрана она тем же самым компилятором и на векторный сопроцессор ей по прежнему начхать.

Значит, векторные операции с плавающей точкой пока не получили столь широкого распространения, чтобы MS почесалась добавить их поддержку в компилятор, только и всего.

ЕМ>>Чего они добились этим вмешательством?

E>Добавили новых багов, очевидно же.

То есть, единственной целью было добавление багов? Разработали железку, сделали под нее сборку WinCE, протестировали, увидели, что багов мало, ну и решили покопаться в параметрах, чтоб добавить еще?