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

9x завязана на концепцию виртуальных машин vm86

Ничего там не завязано, просто графика работала в 16 битной виртуальной машине (System VM). Переписать на 32-х битный GUI сервер пользовательского режима и System VM можно выпиливать. Виртуальные машины - это процессы в терминологии Windows9x. Соответственно VMM (virtual machine manager) - это менеджер процессов.

Windows NT был изначально не нужный проект от космонавтов архитектуры.

Ну и где высоконагруженные сервера на Windows за пять лет до Nginx? И до этого большая часть серверов работала на UNIX-подобных системах

Ну хоть укажи на что-то более конкретное, что ты считаешь истинным высоконагруженным unix-сервером. Oracle пришлось пройти через ад и горы костылей для того, чтобы обойти недостатки юниксов. В том числе реализовывать кооперативную многозадачность в процессе сервера. А логика с базой у них связывалась пулом соединений, как правило.

BIND/named? У него цикл запрос-ответ достаточно короткий, чтобы проблема синхронности не всплывала. Роутеры Cisco делало на самопальной монолитной ОС-и. где бизнес-логика крутилась в режиме ядра.

Причина номер один, почему linux и bsd-подобные системы победили на серверах — это их опенсорсность. Эта та причина, почему вообще юникс победил многих конкурентов. Это многоуровневый конструктор, который существует и в виде готовых решений, и в виде отдельных блоков, и в виде исходных кодов, которые можно патчить для разных целей. MS принципиально отказался приводить свою ОС к такому виду. И проиграл. Как проиграли юниксу многие создатели ранних ОС с закрытыми сорцами. Гугл практически сразу линукс для своих серверов модифицировал. Те же контейнеры у гугла были еще в начале нулевых — естественно, никакая винда такое бы не позволила сделать. Винда нужна была для мелких фирм, которых в любом случае будут пользоваться готовым решением — и таки в этом секторе она задержалась аж до наших дней.

Помимо всего прочего в Windows очень тормозная файловая система NTFS совершенно не пригодная для серверов. EXT работает в разы быстрее

Спорное утверждение. Вот бенчи фороникса на лине, где NTFS бегала через FUSE, а остальные — через драйвера в ядре:

https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.7-FS-5-Way
https://openbenchmarking.org/result/1608041-LO-LINUX44BT99

И что-то я не вижу однозначной победы ext4. Да, ntfs3g заваливает тест BlogBench — потому что оно генерирует огромное число мелких операций, от которых FUSE становится плохо. Да, NTFS старовата и можно было бы сделать лучше в 2020. Что прям-таки плоха и тормозна? Ну нет.

Просто частный пример.

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

В условиях хронической lack of manpower писать, что мол всего и всех хватает, это сильный ход.

Там где надо бизнесу, там всё есть. А у сообщества всегда будет «lack of manpower». Архитектурой драйверов эту проблему не исправить. Основное «lack of manpower» в Линукс-экосистеме находится в программах и библиотеках пользовательского режима.

файловых систем, особенно переусложнённой NTFS

Не смеши мои тапки. Если бы она была переусложнена, то под нее бы не сделали драйверов. Кастомные атрибуты не поддерживаются, да. Но, пардон, если в 2020 году не поддерживаете кастомные атрибуты, то ваша ОС из прошлого века.

Вот бенчи фороникса на лине, где NTFS бегала через FUSE, а остальные — через драйвера в ядре:

NTFS надо было тестировать на Windows на том же компьютере, чтобы показать «превосходство» системы ввода-вывода ядра NT. Не исключаю, что NTFS на Linux работает быстрее, чем на Windows.

Например: https://www.reddit.com/r/windows/comments/bndxkz/yet_another_windows_ntfs_vs_linux_ext4_gnu_quick/. Обратить внимание на «Small file copy (2000 files)». NTFS в 5.5 раз медленнее.

Intel i860 / i960?

Кстати на вики интересное предположение есть:

The first implementation of the i860 architecture was the i860 XR microprocessor (code named N10)

Microsoft initially developed what was to become Windows NT on internally designed i860XR-based workstations (codenamed Dazzle), only porting NT to the MIPS (Microsoft Jazz), Intel 80386 and other processors later. Some claim the NT designation was a reference to the «N-Ten» codename of the i860XR.

Например: https://www.reddit.com/r/windows/comments/bndxkz/yet_another_windows_ntfs_vs_.... Обратить внимание на «Small file copy (2000 files)». NTFS в 5.5 раз медленнее

Это известная «фича» NTFS. Она растыкивает файлы по пустым местам вместо того, чтобы группировать их по типовым сценариям доступа. По этой причине доступ к одиночным файлам на NTFS такой же, как на ext4, но ext4 значительно быстрее работает на сценариях «скопировать много мелких файлов из одного каталога в другой», и «внести небольшие изменения в кучу файлов».

То, что ты почему-то не замечаешь — это что сама ext4 в разы проигрывает другим ФС. Это более актуальная проблема, потому что ни одна ФС не подойдет подо все задачи, а выбор ФС под линь намного шире.

То, что ты почему-то не замечаешь — это что сама ext4 в разы проигрывает другим ФС.

Тут обсуждают великую асинхронную систему ввода-вывода NT. Кроме FAT и NTFS файловые системы под Windows официально не доступны.

Кроме FAT и NTFS файловые системы под Windows официально не доступны

Никто официально не запрещает писать драйвера под винду:

http://www.ext2fsd.com/

http://www.ext2fsd.com/

Не пригодно для промышленного использования:

Ext2Fsd 0.69

1, FIXME: superblock corruption of EXT4 volumes with 64BIT mode enabled

2, FIXME: possible corruption by race conditions in buffer-head reapering

3, FIXME: possible deadlock issues (when flushing) caused by BCB locks

4, FIXME: miscellaneous minor updates of Ext2Fsd code base

Есть ещё Btrfs, но она тоже ещё не пригодна. Последний раз когда проверял неожиданно исчезали файлы и блокировалась запись.

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

Я тоже тыкал ext2fsd не так давно. Их драйвер мне загружал на 100% одно из ядер CPU после монтирования диска с ext4 и так и продолжал грузить его даже после размонтирования и завершения работы программы самой программы. Лечился только ребутом.

ext2fsd у меня тоже глючил, не размонтировал SD карту. Можно либо выключить компьютер, либо вытаскивать без размонтирования…

А btrfs вроде норм, я ReactOS устанавливал в виртуалку на btrfs раздел, вроде норм работает. Правда я редко запускаю ReactOS, но раздел уже пережил 3 обновления ReactOS…

Точно.

Ничего там не завязано, просто графика работала в 16 битной виртуальной машине (System VM). Переписать на 32-х битный GUI сервер пользовательского режима и System VM можно выпиливать. Виртуальные машины - это процессы в терминологии Windows9x. Соответственно VMM (virtual machine manager) - это менеджер процессов.

Если я ничего не путаю, это процессы Win16 (и DOS) в терминологии Windows 9x. Не процессы Win32.

Собственно, VMM – это вещь в себе, отдельная операционная система, примерно как NT является отдельной системой, только устроенная проще раз в 5, а может и в 20. И если опять же ничего не напутал, «ядро Windows» в узком смысле – это KRNL386.EXE, процесс, который предоставляет сервисы WinApi.

Насчёт переписать. Мне кажется, если там начать последовательно переписывать всё, где тянется 16-битное легаси, то от Windows останется, условно говоря, «BeOS». Только такая хреновая BeOS, на порядок хуже настоящей – с сильной связностью компонент и странными решениями в API, некоторые из которых еще со времён Windows 1.0 остались.

Windows NT был изначально не нужный проект от космонавтов архитектуры.

Ну тут ты не прав. Я с тобой категорически не согласен.

Я не вижу ничего плохого использовать FUSE для файловых систем, особенно переусложнённой NTFS, драйвер которой вполне может положить ядро.

Не «драйвер NTFS» может положить ядро, а «написанная на коленке затычка драйвера NTFS» может положить ядро.

А когда драйвер extfs не работает под NT – это, получается, другое? В обратную сторону стрелка не поворачивается?

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

переусложнённой NTFS

Переусложнённой NTFS? Современные ФС на порядок сложнее. А «простая» ext4 тащит наследие нескольких редизайнов, и одно только описание структур данных на диске читается как детективный роман.

И единственный.

А не было бы FUSE, вы бы сейчас написали, что «вообще нет таких примеров, всё нужное есть, а чего нет – то ненужно».

Сколько полезного кода мы не имеем просто потому, что у нас нет ddk – никто никогда не расскажет, ведь его нет.

Я не вижу ничего плохого использовать FUSE

Ага, особенно прикольно было на Pentium 4, когда при копировании файлов на NTFS загрузка CPU была 100% в драйвере, а скорость – как у черепахи.

Если я ничего не путаю, это процессы Win16 (и DOS) в терминологии Windows 9x. Не процессы Win32.

Там 3 вида процессов: 16 bit protected mode (System VM, для Win16), 16 bit virtual 86 (для DOS), 32 bit protected mode (для Win32). В современных ОС тоже есть разные виды процессов: 32 и 64 бит.

только устроенная проще раз в 5, а может и в 20

И это хорошо. Нечего переусложнять.

И если опять же ничего не напутал, «ядро Windows» в узком смысле – это KRNL386.EXE, процесс, который предоставляет сервисы WinApi.

Напутали. KRNL386.EXE - это рантайм система 16 битного окружения, она загружает модули NE, запускает и переключает 16 битные задачи. Все 16 битные задачи работают в одном 16 битном процессе «System VM» т.к. они могут непосредственно друг с другом взаимодействовать. 16 битные NE модули загружаются только один раз, при повторной загрузке возвращается уже загруженная версия. KERNEL.EXE сам по себе является DLL и обращение к нему происходит через обычные импорты, а не через системные вызовы.

В Windows 1.0 - 3.0 без 386 процессора нет никаких процессов и KERNEL.EXE выполняет функцию ядра.

то от Windows останется, условно говоря, «BeOS».

Вы так говорите как-будто это что-то плохое.

Только такая хреновая BeOS, на порядок хуже настоящей

Не обязательно. Практика Линукса показывает, что переписывать систему можно.

NTFS в 5.5 раз медленнее.

Windows 8.1 X64 … no file system tweaks - running ntfs filesystem

Arch (Linux 4.19.41-1-lts x86_64) … added discard, noatime in fstab

Слабо было defaults в fstab записать?

Там 3 вида процессов: 16 bit protected mode (System VM, для Win16), 16 bit virtual 86 (для DOS), 32 bit protected mode (для Win32). В современных ОС тоже есть разные виды процессов: 32 и 64 бит.

Источники какие-то мутные. Пишут, что «все 32-битные процессы исполняются внутри одной виртуальной машины», а в другом источнике вообще матрёшка, где внутри SYSTEM VM лежат как процессы Win32, так и процессы Win16 отдельной кучкой.

В общем, ничерта непонятно, но очень интересно. Нужно будет подробнее во всём этом разобраться.

Напутали. KRNL386.EXE - это рантайм система 16 битного окружения, она загружает модули NE, запускает и переключает 16 битные задачи.

А собственно «окошки» кто рисовал и очередь сообщений крутил?

GUI был 16-битным и однопоточным – переписать эту часть системы то ли не успели (Windows 95 должна была быть Windows 93, но ничего не было готово), то ли не сочли нужным. Вот такая в голове есть информация, а источник – не помню.

Источники какие-то мутные.

По архитектуре Windows 9x вообще много дезинформации, включая официальную документацию от Microsoft.

где внутри SYSTEM VM лежат как процессы Win32, так и процессы Win16 отдельной кучкой.

Возможно имелось ввиду что 32 битные процессы регистрировались как 16 битные задачи-заглушки, чтобы с ними можно было взаимодействовать из 16 битного кода.

А собственно «окошки» кто рисовал и очередь сообщений крутил?

USER.EXE (который на самом деле DLL) в 16 битном окружении. Возможно очередь сообщений потом перенесли в 32 битный код, но не уверен.

GUI был 16-битным и однопоточным

Да, для графики использовался 16 битный процесс «System VM» с модулем USER.EXE. user32.dll обращался к System VM. При обращении к System VM использовался Win16Mutex, т.к. 16 битное окружение не поддерживает потоки. 32 битные процессы поддерживают полноценные потоки и виртуальную память.

то ли не успели (Windows 95 должна была быть Windows 93, но ничего не было готово), то ли не сочли нужным.

Были подсчёты, что 16 битная графика существенно экономила память и позволяла эффективно работать на тогдашнем железе. Переписывание графики на 32 бита было нецелесообразно пока не появилось достаточно мощное железо.

В Windows NT отношение между 16 битной и 32 битной графикой было инвертировано. System VM перенесли в ntvdm.exe, user.exe, gdi.exe стали обёртками над user32.dll, gdi32.dll. kernel.exe остался на месте, т.к. он обеспечивает окружение выполнения win16. Есть открытая реализация ntvdm на основе Wine с поддержкой 64 битных Windows: winevdm.

В принципе аналогичное инвертирование можно было сделать с Windows 9x.

Тут выше критиковали, что драйвер NTFS не могли для Линукса написать, а в Windows ситуация ничем не лучше

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

Тут выше критиковали, что драйвер NTFS не могли для Линукса написать, а в Windows ситуация ничем не лучше

Как это не могли, если он есть? Ядерный драйвер NTFS. Но поддерживате только чтение. Потому что никому не нужно. Как никому не нужно ext4 для винды.

usb некры закопали??? когда???

Ну дык выньте член изо рта, или дуйте в стан к den73 и Dreamject ;) А то уж больно похоже на UWP.

И некры не закапывают, а откапывают! (А потом могут и опять закопать, но это уже отдельная история)

Кто-нибудь уже собрал?

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

Официальная документация утверждает, что если я хочу собрать её с нуля, то я хочу странного, и всё это на моей ответственности.

Имеется в виду, что хотя большинство программ и написано на fasm, но некоторые написаны на других языках и могут требовать танцев c MSVC-over-wine, CMM-over-wine, GCC, newlib и проч и проч. Особого смысла заводить и настраивать весь этот зоопарк на локальной системе нет.

Одна из мелких деталей: Хорошо, что можно просто запустить ubuntu:14.04 в докере и выдернуть оттуда недостающие so-шки для запуска их сборки gcc 5.4.0, к которой положить нужные so-они не догадались.

Во времена gcc 5.4.0 упомянутые so-шки были в каждом первом дистрибутиве, потому и не положили. С тех пор gcc не обновляли.

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

Прекрасно влезут, если использовать kpack. Настраивается в tup.config.

А грузиться и работать напрямую с iso оно не умеет, под капотом тот же самый древний метод с подсовыванием образа дискеты.

Попробуй образ hdd.

Имеется в виду, что хотя большинство программ и написано на fasm, но некоторые написаны на других языках и могут требовать танцев c MSVC-over-wine, CMM-over-wine, GCC, newlib и проч и проч. Особого смысла заводить и настраивать весь этот зоопарк на локальной системе нет.

Да я тут уже наговнокодил скриптов:

https://github.com/geekless/kolibrios-build-scripts

Всё перечисленное есть под онтопик, кроме MSVC, который не нужен и должен сгореть в аду.

Но правда, тот CMM, который мне предлагает AUR, не может найти пути при сборке из-под tup. Дальше пока не копал. К CMM позже вернусь.

Смысл как раз есть – гонять ПОЛНЫЕ сборочные и интеграционные тесты и повышать качество кода.

Да и вообще, опенсорс, который нечем и негде собрать, – только де-юре опенсорс, но не де-факто.

В идеале: self-hosted. Kolibri должна собирать себя сама.

Во времена gcc 5.4.0 упомянутые so-шки были в каждом первом дистрибутиве, потому и не положили. С тех пор gcc не обновляли.

Там gcc обычный или с каким-то патчами? Хотелось бы и сборку самого тулчейна тоже вытащить из мира магии «собрали 5 лет назад, с тех пор никто не трогал» в область рядовых автоматических процедур.

Прекрасно влезут, если использовать kpack. Настраивается в tup.config.

Ага, уже нашел и пофиксил конфиг.

Попробуй образ hdd.

Видел! Вчера натурально плясал, когда увидел сообщение на форуме.

Еще не успел потестировать.

Но правда, тот CMM, который мне предлагает AUR, не может найти пути при сборке из-под tup. Дальше пока не копал. К CMM позже вернусь.

На C-- написано довольно много программ под колибри, относительно других HLL, поэтому эту сборку имеет смысл настроить. Скорее всего, тебе нужно конфиг рядом с бинарником положить.

Там gcc обычный или с каким-то патчами? Хотелось бы и сборку самого тулчейна тоже вытащить из мира магии «собрали 5 лет назад, с тех пор никто не трогал» в область рядовых автоматических процедур.

Патченный, конечно. В репозитории и на форуме есть какие-то патчи от Serge, но он уже пару лет не заходил на форум. Так что с большой вероятностью даже бинарник никто не соберёт.

В идеале: self-hosted. Kolibri должна собирать себя сама.

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

Потому что IO по своей сути штука асинхронная.

Вот согласен. Особенно в контексте сети. Синхронное чтение TCP или UDP это бред, зачастую вынуждающий создавать отдельный поток для чтения данных в цикле. Хотя на самом деле зачастую нужен вызов callback при приходе данных

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

Жесть