Форум: Культурный флейм, слухи
Тема: Чем объяснить тормоза и ненадёжность платформы Windows CE?
Страницы: 1 2 3 4 [5] 6 7
[Ответить]
ВадимП [19.05.2007 00:09] :
Естественно.
Управляемые событиями оконные системы нестабильны по своей природе. В этом отношении гораздо надежнее вообще ее не иметь, а писать игру на манер игр под ms-dos при помощи, скажем, SDL (simple direct media layer). У этой библиотеки нет необходимости в графической среде - она может работать напрямую с кадровым буфером или вообще с ascii графикой.
Но много ли Вы найдете готовых отказаться от графического интерфейса пользователя?
const_mech [21.05.2007 10:29] :
- ВадимП писал(а):
Управляемые событиями оконные системы нестабильны по своей природе.
alien8 [22.05.2007 01:23] :
Data_Link
>>ну процессоры же использует..
Смотря кто и где. Помнится, смеялись, когда был массовый развод на "ошибку 2000 года" и в новостях заявили ,что нашему МинОбороны выделили N-ную сумму для того "чтобы ракеты не взлетели".
Для обывателя, видимо, все естественно.
Если не знать, что в системе управления ракетным оружием (как, впрочем, и в ряде других мест) запрещено использовать не только "буржуйский" софт, но и "железо". Для исключения всяких закладок и прочих гадостей.
ВадимП [22.05.2007 02:07] :
- const_mech писал(а):
Источник НЕстабильности заключен в принципе "управляемые событиями" или именно в "оконные системы"?
В результате все мои сообщения такого рода получаются крайне длинными.
Вот и сейчас, я хотел было написать о том, какие были проблемы с обработкой событий в операционных системах MS и как они постепенно устранялись, но это получилось настолько длинно, нудно и неинтересно....
Потому что сначала я начал было с windows 95: написал о системной очереди сообщений, об очередях сообщений приложения, потом я сообразил, что нужно еще немножко пояснить, что такое сообщение и стал писать, что каждому событию соответствуют данные в виде записи определенной структуры именуемые сообщением, и что сообщение из системной очереди попадает в очередь сообщений приложения, и зачем это нужно.... Потом вспомнил, что надо упомянуть о том, что есть еще внеочередные сообщения.....
В результате я понял, что пока я дойду по Vista текст разрастется до невероятных размеров, причем окажется никому не нужен - windows-программисты над таким бездарным пересказом на популярном уровне в лучшем случае посмеются, а все остальные просто читать не будут.
Поэтому я плюнул, всё написанное стер и очень длинно объяснил, что я не буду ничего объяснять, потому что получается очень длинно.
const_mech [22.05.2007 09:38] :
Ну тогда я коротенько поясню, почему задал вопрос: От вас я уже НЕоднократно слышал тезис о принципиальной НЕстабильности графических оболочек, но из "НЕзависимых источников" такую информацию НЕ получал ни разу.
А тут вроде как и причина НЕстабильности обрисовалась: управляемость событиями. Но цикл обработки событий можно и БЕЗ графической оболочки реализовать. Tcl может обрабатывать файловые события и отслеживать изменения значений глобальных переменных. Будут ли такие техники также принципиально НЕстабильны?
ps. Если где-то сохранилась копия наброска первоначального ответа, то её можно в личку запостить.
ВадимП [22.05.2007 20:41] :
Если в двух словах, то причина в том, что до сих пор не удалось достаточно надежно изолировать одно приложение от возможного влияния другого.
Теоретические подобные ситуации возможны и без графической оболочки (одно приложение захватило в монопольный доступ ресурс, необходимый другому приложению) но там эти проблемы упрощаются намного мЕньшей степенью взаимодейтсвия между процессами и отсутствием критически важных ресурсов, которые можно было бы захватить, заблокировав тем самым всю систему (все блокировки устанавливаемые процедурами ядра ими же и снимаются до выхода из режима супервизора).
Изза чего одна программа может заблокировать всю систему? Вариантов сотни и по мере совершенствования графических оболочек потенциальные "узкие места" последовательно убирались. Но поскольку, как уже было сказано, все графические программы разделяют доступ к ресурсам одной и той же оконной системы (и активно взаимодействуют между собой - чтобы одно приложение было вынуждено предпринимать какие-то действия изза операций с другим приложением, может оказать достаточным одного того, что окно первого окажется частично закрыто окном второго).
Давайте посмотрим на эволюцию оконных систем MS:
Возьмем самую первую реализацию графической оболочки управляемой событиями - ту windows, которая запускалась поверх MS-DOS (независимо от версии).
У неё была единственная очередь событий (в 16-разрядной подсистеме windows 9х сохранилась та же ситуация). Безотносительно к тому, как была бы реализована многозадачность в оболочке (кооперативная или истинная) одно повисшее приложение могло заблокировать все остальные, потому что блокировалась выборка событий из очереди.
В win95 сделали очереди приложений, куда можно было запихнуть событие из системной очереди, чтобы остальные приложения могли продолжать выборку. Но это проблему тоже не решило и плюс возникла еще проблема с глобальными блокировками - многие модули содержали нереентерабельный код (скажем, GDI или user), т.е. их могло одновременно использовать только одно приложение, поэтому повисшее 16-разрядное приложение вешало не тольку всю подсистему win16, но могло завесить и всю win32, которая не могла получить доступ....
Ну и т.д.
Продолжение:
Как можно понять, количество проблем было огромно, поэтому проще было написать новое ядро, чем латать дыры в старом.
Поэтому в Win NT указанные выше проблемы (за исключением проблем с очередями сообщений) были устранены: весь код стал реентерабельным, исполнение "унаследованных" 16-разрядных приложений производилось в обособленном адресном пространстве, ограничен доступ к разделяемой памяти процессов, полностью закрыт доступ к памяти системы со стороны процессов пользователя.
Тем не менее, множество проблем со стабильностью так и не было решено и причиной опять-таки стали очереди сообщений.... (потом допишу, если не лень будет)
const_mech [24.05.2007 10:35] :
ВадимП, очень познавательно. Если будете дописывать, X-Window помяните.
А касательно топика, значит WinCE оттого особенно глючная, что работает НЕ на новом движке WinXP, а на НЕдолатанном движке Win95.
Вопрос: А тот факт, что в WinMob окна частично НЕ перекрываются, но всегда полностью. Это, потенциально, серьёзное упрощение? В плане влияния на стабильность.
sshd [24.05.2007 10:56] :
- const_mech писал(а):
А касательно топика, значит WinCE оттого особенно глючная, что работает НЕ на новом движке WinXP, а на НЕдолатанном движке Win95
- const_mech писал(а):
Вопрос: А тот факт, что в WinMob окна частично НЕ перекрываются, но всегда полностью
никто не запрещает создать неполноэкранное окно.
ВадимП [24.05.2007 11:39] :
Да ничего познавательного нет, а X-window ничуть не лучше (а в определенных отношениях даже хуже, чем оболочка windows).
Просто проблема в том, что как тут было справедливо замечено, более сложные системы менее надежны. Никакого закона природы запрещающего создавать стабильные графические оболочки мне неизвестно.
Поэтому как-то проиллюстрировать свои слова я могу единственным образом: взять эволюцию любой оболочки и начать приводить примеры, что как только затыкали одну дырку, тут же обнаружмвалась следующая....
И что эти дырки появлялись не вследствие случайных ошибок в программировании, а были изначально присущи данной архитектуре.
И опять получится, что для того чтобы проиллюстрировать нехитрую в общем-то мысль у меня уйдет две страницы печатного текста (как это было в "оффтопиках", где я спорил с уважаемым Дартом по вопросу о том, насколько быстро может развиться лекарственная зависимость - я даже не уверен, что хоть кто-то нашел в себе силы прочитать там мою аргументацию до конца).
const_mech [24.05.2007 16:04] :
- sshd писал(а):
WinCE работает на "движке" WinCE, и не имеет никакого отношения к Win95
::::::::::::::::::::::::::::
ВадимП, тогда без доказательств и пояснений, только ваше мнение:
- В этом отношении гораздо надежнее вообще ее не иметь, а писать игру на манер игр под ms-dos при помощи, скажем, SDL (simple direct media layer). У этой библиотеки нет необходимости в графической среде - она может работать напрямую с кадровым буфером или вообще с ascii графикой. Но много ли Вы найдете готовых отказаться от графического интерфейса пользователя?
Трудозатраты на создание приложений при этом сильно увеличатся?
[Ответить]
[< Назад] [Вперед >]