Утечка исходного кода Windows XP

В идеале надо вообще всякие потусторонние звуки да буквы в чистом виде и заимствовать, а не коверкать. Вот что с ѳитой сделали, почему она то т, то ф? (а как [θ] вроде и не произносилась никогда)

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

Да ещё и на мёртвую систему, для которой драйверы больше не выпускают.

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

Ну так забили же ;)

Легально получить большую часть бинарников драйверов без лицензии Windows нельзя. Драйверы теперь не скачиваются с сайта производителя, а распространяются через систему обновления Windows.

Реактоськапец подкрался незаметно?

Теперь в ней совсем нет смысла, можно спокойно идти пилить wine?

Ты самое главное скажи. Свежий OpenSSL прикрутили?

Не помним. Кодеки какие-то точно прикручивали.

Ну кагбэ наличие лицензии на винду не мешает тому, что впихнуть эту винду на железо нельзя. В итоге придётся покупать и винду, и реактось ;)

Ну H264/H265 Опера не умела. Только WebP из коробки. И то довольно тормозно. А сейчас без этих кодеков никуда.
Операвцы довольно странно поступили. Обрезали gstreamer. Не использовали DirectShow(тогда на формат видео вообще пофиг, и аппаратное ускорение возможно)

Я сейчас ютуб смотрю в Опере 12 через MediaPlayer NPAPI плагин https://github.com/bga/userjs/blob/master/youtube.js

Ну кагбэ наличие лицензии на винду не мешает тому, что впихнуть эту винду на железо нельзя.

Тут выше писали, что лицензия Windows позволяет легально использовать старые версии.

У мелкомягких же индусы одни. В коде небось непаханое поле для рефакторинга

Если говорить про фундаментальный системный код, то его писали лучшие мировые сишники, так что нет, про рефакторинг только мечтай. Из тех сорцов, что я читал (файлы и синхронизация), докопаться не до чего.

В реакте особого смысла не было с самого его начала

Есть одна большая причина, почему альтернативные реализации винды не составляют конкуренцию, и эта причина была изначально заложена при разработке. Примерно потому же тяжело составить конкуренцию IBM/360, выпустив аналог — потому что сам IBM на этот проект потратило больше, чем бюджет проекта Манхеттен. Или СУБД оракл, которую сам оракл с большим трудом может разрабатывать. Во времена анального копирайта на ПО каждый разраб понимал, что для устранения конкуренции код должен быть максимально запутанным, тяжелым для воспроизведения, с тщательно поддерживаемыми неподдерживаемыми фичами. Этот прием очень хорошо видно по IE, который показательно нарушал стандарты, делая свое поведение особенным и неповторимым. Мне недавно приходилось почитавать доки по OpenXML — рекомендую мазохистам для развлечения.

Короче говоря — не сможет реакт повторить винду. А тогда смысл в нем исчезает.

А латать эти версии кто будет?

По скорости венды эт заметно.

А латать эти версии кто будет?

Умельцы могут и без исходников систему пропатчить.

отлично, ждем сливов семерочки через десять лет

По скорости венды эт заметно

А скорость современных популярных дистров линя тебя не смущает?

и да, тот самый наконец настал.

А скорость современных популярных дистров линя тебя не смущает?

Ничего не способно сравниться с тормозами GDI и Проводника в Windows 10. В Windows создание процессов и потоков значительно медленнее чем в UNIX-подобных системах.

Ничего не способно сравниться с тормозами GDI и Проводника в Windows 10.

Потому я сижу на семерке.

В Windows создание процессов и потоков значительно медленнее чем в UNIX-подобных системах

Про потоки 4.2. В ядре NT создание процесса ничего не стоит, цена начинается при инициализации win32 процессов, когда нужно грузить либы через side-to-side и регистрироваться в менеджере сессий. И тут мы машем ручкой systemd и dbus.

цена начинается при инициализации win32 процессов, когда нужно грузить либы через side-to-side и регистрироваться в менеджере сессий.

Этого нельзя избежать документированным способом, так что нет никакого значения насколько быстро запускаются нативные процессы NT.

И тут мы машем ручкой systemd и dbus.

Каждый созданный процесс/поток не обязан в них регистрироваться.

Этого нельзя избежать документированным способом, так что нет никакого значения насколько быстро запускаются нативные процессы NT

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

Каждый созданный процесс/поток не обязан в них регистрироваться

А куда ты денешься? Сейчас софт уже к ним гвоздями потихоньку прибивают.

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

Зачем извращаться, если есть настоящие UNIX-подобные системы? Оригинальная POSIX подсистема была весьма специфична и требовала доработки программ напильником. Сейчас WSL2 работает через виртуальную машину без NT процессов/потоков.

На нативных API никто не пишет, потому что они зависят от версии системы.

Вообще непонятно зачем они этот native API выдумали. В остальных системах программы обращаются напрямую к ОС безо всяких тормозных обёрток.

А куда ты денешься? Сейчас софт уже к ним гвоздями потихоньку прибивают.

Компилятор и система сборки нигде не регистрируются и быстро запускаются. В Windows даже консольные программы в win32k.sys регистрируются.

Могут, но васянские патчи нарушают EULA.

В Windows даже консольные программы в win32k.sys регистрируются.

А .COM?

А .COM?

Они вообще через виртуальную машину ntvdm.exe работают. ntvdm.exe естественно регистрируется в win32k.sys, это обычный win32 процесс.

Зачем извращаться, если есть настоящие UNIX-подобные системы? Оригинальная POSIX подсистема была весьма специфична и требовала доработки программ напильником

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

Сейчас WSL2 работает через виртуальную машину без NT процессов/потоков

Потому что на ней гоняют единственный докер, а виртуалка со своей ФС и вообще своим окружением работает лучше, чем с виндовым. Если же нужно работать никсовыми инструментами над виндовой средой, то используется WSL1.

Компилятор и система сборки нигде не регистрируются и быстро запускаются. В Windows даже консольные программы в win32k.sys регистрируются

CMake, SCons прекрасно работают под виндой. Башеговно под виндой просто не нужно. Оно не нужно и под никсами, но его просто как наследие тянут.

Вообще непонятно зачем они этот native API выдумали. В остальных системах программы обращаются напрямую к ОС безо всяких тормозных обёрток

Native API — это системные вызовы. Ты для вызова open дергаешь сишную либу. которая уже дергает системные вызовы платформы. Так же приложуха дергает kernel32.dll, которая уже превращает вызов в системный вызов. Что системные вызовы представляют собой дополнительный вызов функции? По сравнению со стоимостью системного вызова это плюс-минус ничего.

CMake, SCons прекрасно работают под виндой.

Запуск компилятора для каждого исходного файла в Windows медленнее чем в UNIX-подобных системах. При компиляции проекта с большим числом небольших исходников время компиляции может существенно отличаться. Работать компилятор в режиме сервера без постоянного перезапуска процесса пока не научили.

Оно не нужно и под никсами, но его просто как наследие тянут.

Сторонники UNIX-скреп будут несогласны.

Native API — это системные вызовы.

Не только. Это ещё отсутствие принудительного тормозного взаимодействия с win32k.sys.

Так же приложуха дергает kernel32.dll, которая уже превращает вызов в системный вызов.

…и выполняет трансляцию Win32 путей в NT пути. kernel32.dll - это не просто обёртка над ntdll.dll, она выполняет преобразование Win32 <-> Native с накладными расходами. Это что-то по типу Wine.

Вообще непонятно зачем они этот native API выдумали. В остальных системах программы обращаются напрямую к ОС безо всяких тормозных обёрток.

Потому что задача Катлера была делать хорошее ядро. А существующую winapi прикручивать к нему изолентой – извините. Прикрутили как могли.

А ядро 30 лет эволюции пережило без существенных переделок, это не linux со stable api is nonsense и не bsd с её историей наконец-то-выкидывания-global-lock.

Запуск компилятора для каждого исходного файла в Windows медленнее чем в UNIX-подобных системах. При компиляции проекта с большим числом небольших исходников время компиляции может существенно отличаться

Проблема наблюдается ровно потому, что CMake по умолчанию комплирует на одном ядре, а C\C++ софт обычно любит долго компилироваться. В остальном cl.exe прекрасно себе запускается с несколькими файлами в аргументах.

Работать компилятор в режиме сервера без постоянного перезапуска процесса пока не научили

Научили. Даже больше — это единственный способ быстро перекомпилировать кресты на любой ОС-и.

Потому что задача Катлера была делать хорошее ядро.

Хорошее ядро само по себе никому не нужно. К тому же Microsoft не распространяет его отдельно. Оно находится в комплексе с Windows и рассматривать надо весь комплекс. К тому же я не вижу в нём ничего хорошего, оно сильно переусложнено. Писать под него драйверы - это ужас. Для сравнения драйвер null в NT и Haiku.

А существующую winapi прикручивать к нему изолентой – извините. Прикрутили как могли.

Не надо было выдумывать никакого Native API. Вместо этого надо было использовать Win32 в качестве основного API и kernel32.dll вместо ntdll.dll.

Хорошее ядро само по себе никому не нужно.

Предлагаю поставить W95, чтобы убедиться в этом лично :-D

оно сильно переусложнено

Лучше один раз изучить сложный предмет, чем постоянно изучать «простой» без стабильного API.

Для сравнения драйвер null в NT и Haiku.

NT оперирует IRP, это хоть и сложно, но даёт внятную асинхронную модель IO. А чем оперирует Haiku, не имею представления.

В любом случае сравнивать серверную ОС и наколенную поделку без модели защиты, мультиюзерности, прав доступа, квот и т.п. - предельно некорректно.

У меня вон в самописном ядре планировщик работает за O(1), т.к. это проще реализовать, но гордиться этим я не буду.

а C\C++ софт обычно любит долго компилироваться

"C" тут лишнее. Тьюринг-полный язык шаблонов C++ даёт прикурить любой железяке. Cи компилируется в десятки раз быстрее.

«C» тут лишнее. Тьюринг-полный язык шаблонов C++ даёт прикурить любой железяке. Cи компилируется в десятки раз быстрее.

современный С++ компилируется очень быстро. На уровне C#, +-, гораздо быстрее, чем например Rust.

Модули и extern template творят чудеса.

А легаси куда деть?)

Предлагаю поставить W95, чтобы убедиться в этом лично :-D

Ядро Windows 9x VMM.VXD вполне можно было эволюционно развивать вплоть до полного выпиливания 16 битных компонент.

Лучше один раз изучить сложный предмет, чем постоянно изучать «простой» без стабильного API.

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

В любом случае сравнивать серверную ОС

Это вы Windows называете серверной ОС, которая даже без GUI работать не умеет? Большая часть серверов на Линуксе работают.

без модели защиты, мультиюзерности, прав доступа, квот

Значительная часть этого - переусложнение и не нужно.

Ядро Windows 9x VMM.VXD вполне можно было эволюционно развивать вплоть до полного выпиливания 16 битных компонент.

Можно, но не нужно.

Там нет никакой перспективы, хотя работа инженеров, кто построил рабочую систему на куче легаси, завораживающая.

В ядро лезть обычно нет необходимости.

Ну и зачем тогда жаловаться на его сложность?

Это вы Windows называете серверной ОС, которая даже без GUI работать не умеет?

Я NT называю серверной. Она делалась под стать веяниям того времени и сразу имела всё нужное в себе для работы как на серверах, так и рабочих станциях. То, что MS не смогла продвинуться на сервер, и NT по большей части осталась сложной пускалкой для драйвера нвидии снизу и игрушек / офисных пакетов сверху, не вина команды разработки.

Про то, что NT лучше обрабатывает ситуацию нехватки ресурсов, чем современный linux, лучше вообще на ЛОРе не вспоминать…

Кстати, нет ли у вас каких-нибудь залежей документации по ядру Windows 9x? Сейчас в инете их отыскать довольно сложно.

У меня вон в самописном ядре планировщик работает за O(1), т.к. это проще реализовать, но гордиться этим я не буду.

За, O(N), разумеется.

Думаю одно, пишу другое.

Кстати, нет ли у вас каких-нибудь залежей документации по ядру Windows 9x?

Что-то есть, но сомневаюсь, что я могу это легально публиковать. Еще есть декодеры исполняемых файлов PE и NE и прочие утилиты, но они на Обероне (на Обероне проще писать не боясь порчи и утечек памяти, а также undefined behavior и при необходимости иметь возможность легко вызывать API ОС и сторонних библиотек). Когда-нибудь их выложу. Я не настолько стар и когда я начал достаточно разбираться в программировании, Windows 9x уже помер. В одно время заинтересовала архитектура 16 битных Windows, они умудрялись обеспечивать работу GUI при небольшом объёме памяти. Использовались хитрые механизмы загрузки/выгрузки кода и данных с патчингом исполняемого кода для экономии памяти и это работало без виртуальной памяти.

Сейчас в инете их отыскать довольно сложно.

Вот например: https://www-user.tu-chemnitz.de/~heha/vxd/vxd_fra.htm.

О! Благодарю!

к сожалению, wine это слабо поможет. он как глючит десятилетиями, так и будет глючить. так что не видать нам LSW.

К тому же Microsoft не распространяет его отдельно. Оно находится в комплексе с Windows и рассматривать надо весь комплекс

Рассматривай. Рассмотри, например, тот факт, что с винды 95 интерфейсы пользовательских приложений не менялись.

К тому же я не вижу в нём ничего хорошего, оно сильно переусложнено. Писать под него драйверы - это ужас. Для сравнения драйвер null в NT и Haiku

Unified page cache с интерфейсами програмирования как запросов из кэша, так и отложенных запросов ввода-вывода (IRP) был в NT с самого начала. В никсах это возникало стихийно, а в некоторых unified page cache до сих пор не появился. В приведенном примере драйвера null функция обработки IRP, которая составляет большую часть кода драйвера, практически никогда не вызывается — это затычка на случай, если кто-то внезапно создаст IRP из ядра в обход обычных CreateFile/ReadFile/WriteFile.

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

Не надо было выдумывать никакого Native API. Вместо этого надо было использовать Win32 в качестве основного API и kernel32.dll вместо ntdll.dll

Там минимальная трансляция. Я напомню, что помимо NT винда существовала также в виде настройки над DOS, с абсолютно теми же интерфейсами.

Это вы Windows называете серверной ОС, которая даже без GUI работать не умеет? Большая часть серверов на Линуксе работают

Инфа устарела. В винде уже есть интерфейсы администрирования без GUI и без консоли, на прямых запросах к службам через сеть.

Про то, что NT лучше обрабатывает ситуацию нехватки ресурсов, чем современный linux, лучше вообще на ЛОРе не вспоминать

Справедливости ради, делает он это хорошо только для программ без GUI. Потому что GUI, как правило, работает на RPC с вовлечением нескольких служб — любая из них с радостьюзавесит твое приложение.

к сожалению, wine это слабо поможет. он как глючит десятилетиями, так и будет глючить. так что не видать нам LSW

Это проблема криворуких мартыханов, софт которых плохо переносится даже между версиями винды.

Рассмотри, например, тот факт, что с винды 95 интерфейсы пользовательских приложений не менялись.

И это хорошо. Нечего ломать интерфейсы. Они с Windows 1.0 не особо изменились. Можно посмотреть заголовочные файлы из Windows 1.0 SDK.

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

Судя по доле Windows на серверах, этот Unified page cache и IRP не особо то и нужен.

Я напомню, что помимо NT винда существовала также в виде настройки над DOS

Злостное 4.2. Начиная с версии 1.0 Windows - это полноценная операционная система. В ней свой формат исполняемых файлов, реализованы загрузка и выгрузка модулей, выделение памяти, переключение задач и т.д. DOS выполняет функцию boot loader и драйвера файловой системы (которая позже также была реализована непосредственно в Windows). Основные програмные интерфейсы DOS переопределяются ядром Windows.

В винде уже есть интерфейсы администрирования без GUI и без консоли, на прямых запросах к службам через сеть.

Это не отменяет того, что без GUI она работать не умеет. В Windows Server Core GUI тоже есть. Многие компоненты привязаны к GUI, например COM работает через отправку сообщений скрытому окну.

Когда Windows официально научится запускаться без win32k.sys, тогда пусть и заявляют, что она умеет без GUI работать.

Это проблема криворуких мартыханов, софт которых плохо переносится даже между версиями винды.

+1. Софт написанный в соответствии с документацией работает везде, а криворукий софт опирающийся на недокументированное поведение заставить работать в общем случае невозможно в принципе.