Ухохоталась-3

[nyurka]

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

char buf[10];
strcpy(buf, "Select path for visualization - click on the path name");

Ни фига не обкурилась - все именно так и было написано.
Спрашиваю - а чего там букв мало?
Вы бы в 10 байт большую советскую энциклопедию попытались уместить - было бы гораздо смешнее.
Обиделись...
На пару...

Comments

[rsx11.livejournal.com]

Ой, а вот очень интересно, что вы вообще скажете про WinCE ?

При моём офигительном опыте работы с самыми разными embedded системами (Linux, pSoS, VxWorks, куча самопальных мониторов и микрокернелов) - ничего не знаю о WinCE. А тут, недавно задумались о системе для следующего продукта - и выяснилось, что при суммарном опыте больше полусотни лет в embedded - с WinCE не знаком никто...

Что интересует:

1. Легкость и гибкость написания драйверов
2. Как это - писать драйвера втёмную (не имея исходников системы, когда любой вопрос решается с помощью grep-а и какой-то матери)? Сильно напрягает?
3. Уровень документированности (учитывая отсутствие сорцов - должен быть на несколько порядков лучше). Так ли это?
4. Latency
5. Overhead (как по памяти, так и по времени)
6. Среда разработки и качество кросс-компайлеров (интересует PPC). Я так понимаю, что о гнусных продуктах и мечтать не приходиться?
7. Всякие побочные BSP-related примочки, типа flash-loader-ов, initrd, rootfs -насколько всё это гибко и настраеваемо?


Спасибо.

[nyurka.livejournal.com]

Смотрите, основные минусы WinCE - это то, что во-первых,не работают даже те основные функции, которые работают всегда и везде, а во-вторых, и это самое дерьмовое, нет хорошо сделанной документации.
MSDN, который с ней поставляется - это песня.
Если там написано, что функция поддерживается с 1-й версии и дальше, это ничего не значит, Вы вполне после пары дней работы можете получить результат ошибки "не поддерживается средой". С другой стороны, если написано, что функция не поддерживается - тоже ничего не значит, я сделала шикарную визуалку для навигации исключительно из функций, которые, согласно MSDN работать не должны по определению.
Плюсы - на чистом С работает все и всегда, есть куча адаптированных библиотек всех сортов, включая нежно мной любимую STL, а главное, системка с бешеным будущим, мне недавно принесли покеты с 8 дюймовым экраном, хорошим процессором, легенькие, тоненькие - сказка.
Так что самый основной совет - ищите человека с хотя бы 2-3 годами опыта в CE, просто потому, что большинство вещей там творящихся, просто надо знать, информации кроме собственного опыта у меня, например, никакой нет.

1. Писать, зная подводные камни - читай имея опыт - очень легко, а с хорошим опытом еще и в чистом С - в чем-то даже легче, чем под стандартный Windows, например тем, что никакого кастинга система сама не делает, посему и сюрпризов по этому поводу не бывает.
2. Опять же нужен человек с опытом, одна из самых дерьмовых проблем этой системы - в большинстве случаев программы не падают, они просто "уходят в себя", и как правило в релизе, и очень сложно понять что именно происходит. См пост - результатом этой дурацкой ошибки не стал ни краш системы, ни краш программы, просто диалог не появляется, но и ошибка тоже.
3-7 см выше

[rsx11.livejournal.com]

Понял, спасибо.

А что за зверь такой, STL на чистом C? Никогда не слышал...

[nyurka.livejournal.com]

Прикол оценила.
Но вообще-то там запятая стоит, если не заметили.

[rsx11.livejournal.com]

На самом деле не такой уж и бред. Бывают ситуации, когда нужно что-то сделать на чистом С (проблема с компайлером, экзотическая архитектура, очень серьёзные ограничения, когда каждый байт считаешь, и т.д.).

Я всегда, в таких случаях, использую GLIB (GTK low level) в качестве STL для бедных :-)

[rsx11.livejournal.com]

То есть, другими словами - без опыта в "обычном" Windows - не суйся, правильно?

[nyurka.livejournal.com]

Не правильно :)
Другое дело, что будет попроще, ибо CE-шное API оно фактически очень сильно урезанное Windows-ное.
Так сильно урезанное, что уже не понятно кто он был вначале:))
Но ничего такого, что не сможет понять нормальный хорошо обученный программер нет.
Фактически и про опыт в CE я написала, исходя из того, что одним из требований как правило является скорость исполнения. Просто очень много времени уйдет на то, чтобы понять откуда начинают валиться сюрпризы.
Небольшая реплика в сторону по теме - когда у меня даже в проекте CE не было, были мы на какой-то конференции, там один из парней работавший с этой пакостью сказал - не пользуйся для работы в CE с большими картинками malloc, используй VirtualAlloc, я как-то случайно запомнила это дело, но, разумеется, использовать не стала - разница в скорости большая, а когда вдруг уже в CE начала без перерыва получать ошибки с памятью - вспомнила - все сразу заработало, так вот - ни в одном месте и ни в одной конференции я этого не нашла.
Это к вопросу об опыте.
Так что гораздо полезней, если все-таки собираетесь с ней работать, собирать вот такую информацию со всех возможных источников, чем опыт, ибо даже самый опытный может конкретно я этой задачей за всю жизнь ни разу не столкнуться.
Повторяюсь - это в том случае, если время не критично.