LINUX.ORG.RU

История изменений

Исправление X512, (текущая версия) :

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

По архитектуре 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.

Исправление X512, :

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

По архитектуре 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. Есть открытая реализация ntvdm на основе Wine с поддержкой 64 битных Windows: winevdm.

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

Исходная версия X512, :

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

По архитектуре 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. Есть открытая реализация ntvdm на основе Wine с поддержкой 64 битных Windows: winevdm.

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