Win32 API на Windows 8 ARM: только для белых людей

[waqur]

Mike Pall поясняет, в чём заключаются ограничения Windows 8 для архитектуры ARM:

http://www.freelists.org/post/luajit/FYI-No-JIT-on-Windows-8-for-ARM

На платформе ARM, так же как и на x86, присутствуют обе подсистемы Windows 8: Win32 и WinRT. Однако подсистема Win32 доступна только для встроенных в ОС приложений, таких как Internet Explorer, и недоступна для сторонних приложений, таких как Mozilla Firefox.

Хотя подсистема WinRT доступна для всех приложений, она более урезанная по сравнению с Win32. В частности, в ней нет функции VirtualProtect или другой аналогичной для превращения данных в код; таким образом работа JIT-компиляторов на платформе Windows 8 ARM становится невозможной. За исключением JIT-компилятора в составе Internet Explorer.

Эта ситуация значительно облегчает Internet Explorer'у конкуренцию с Mozilla Firefox и Google Chrome на платформе Windows 8 ARM; т.к. без JIT Firefox и Chrome будут исполнять Javascript медленнее раз в 20.

В следующих версиях Microsoft может сделать недоступным Win32 API и в настольной Windows, если достаточное количество приложений сторонних разработчиков будут портированы под WinRT API. Чтобы это стало возможным, для Microsoft сейчас главное — это убедить разработчиков и пользователей, что WinRT — это хорошо, а Win32 — это плохо. Тогда проблема наличия Mozilla Firefox и Google Chrome будет решена. Ну а далее уже можно будет заняться проблемой наличия Google.


В этой войне Google может выжить одним-единственным способом: пока ещё не поздно, предложить альтернативную реализацию Win32. Не браузерно-облачную Chromium OS, и не телефонную Android, а нормальную операционную систему для настольных ПК, на которой будут работать "прямо из коробки" все приложения и игры, выпущенные после 1995 года.

Comments

[pan-2.livejournal.com]

Я просто оставлю это здесь: http://tirania.org/blog/archive/2012/Aug-29.html

[waqur.livejournal.com]

Да, я уже видел. Автор абсолютно прав - совместимостью заниматься никто не хочет, стабильного юзерлендного API нет и не предвидится, Linux просрал десктоп.

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

Окружение рабочего стола, юзерлендное API и базовый набор приложений может разработать только крупная компания типа MS или Apple или Google, преследуя цель коммерческой прибыли, опираясь на инженерный опыт и организационную дисциплину (особенно в части поддержания обратной совместимости), а не пёстрая компания студентов-недоучек, фриков-выскочек и анархистов-коммунистов от IT.

FreeBSD обладает ядром, которое можно легально пристегнуть к коммерческому рабочему столу и юзерлендному API и в таком виде невозбранно продавать for profit; Linux же в этом смысле обречён - его отравляет лицензия, которая исключает всякую коммерческую мотивацию для разработчиков. К сожалению, Linux практически убил BSD-системы - и сейчас, кто бы за них не взялся, ему ещё долго придётся выводить их из коматозного состояния.

[alexfifer.livejournal.com]

Интересно, а рассматривался ли когда-нибудь вариант смены линцензии линукса с GPL на LGPL? Кажется, это решило бы кучу проблем.

[waqur.livejournal.com]

Это решило бы почти все проблемы, включая также легальную совместимость с сановским наследием (ZFS и т.п.), однако это невозможно - надо получить письменное согласие всех контрибуторов ядра на смену лицензии (включая тех, кто прислал патч на одну строку), либо добиться от них письменного copyright disclaimer (отказ от авторских прав), либо выбросить их код из ядра. Многих из них уже нет в живых.

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

[alexfifer.livejournal.com]

Спасибо, про такие тонкости не знал.