Какое всё-таки конченое говно этот ваш linux.

Основное ядро 32-битное?

Драйвер VBox сам переходит в 64-битный режим проца что ли?

Не знаю, как оно там устроено, но думал, что такое не катит.

Ядро чисто 32 бит. Не как в Solaris, где ядро 64 бит, а софт 32 бит. Если совсем конкретно, версия ядра 3.16.7-ckt7. Виртуалбокс 4.3.12. Знаю что всё старое.

Сам удивился. Это как вообще? Процесср в 32-битном защищённом режиме, и в 64-битный режим не переключался. А гостевая система 64 бит работает...

Я просто сторонник СПО. Не фанатичный, мне пара блобов в ядре по ночам спать не мешает, проприетарные видео кодеки в кошмарах не снятся. Ты видимо реальных фанатиков не видел, есть такие, кто может с человеком общатся перестать только из-за того, что тот использует неправильынй дистр. Реально,встречал таких. Недавно в очередной раз попробовал освбодиться как следует, поставил parabola linux, жестко. Половина видео не проигрывается, mpv не работает, все не-свободные протоколы из местного libpurple убраны (процентов 80), wine формально работает,но… Грустно,на самом деле

СПО никак бизнесу RH не противоречит.

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

Win 1-3, никогда не были осями. Это графическая оболочка. Запускали это хозяйство при помощи win.com емнип. В вин95 дос запихали в подвал. В миллениуме вход в подвал замаскировали ковром. На этом линейка окон завершилась. Винхп - это уже виннт ядро. Оно корчится в агонии по сей день.

Это блюдо в единой поставке. Всё взаимосвязано. Что касается поздних Windows (3.11, 9x, Me), там DOS выполнял только роль загрузчика.

Linux запускается через grub, вот прямая аналогия.

В ранних можно рассматривать DOS и Windows как две подсистемы одной ОС. DOS отвечала только за файловую систему. Основные задачи ядра выполняла Windows. Управление памятью, планирование задач. Ну и графический стек в ней же был реализован, разумеется.

Когда все стали обновляться до 10, то ко мне только пришли 2 человека с проблемами: После установки 10 перестал включаться бук(сгорел контроллер питания от натуги), сломался АКБ на ноуте.

«После» не значит «вследствие»

Потом стали чаще приходить с битыми хардами через 1-2 месяца после обновления до 10.

Тоже самое.

на ext3 ты ничего не потеряешь

Опять закинулся непойми чем? :))

Linux запускается через grub, вот прямая аналогия.

Прошу прощения, но это ни разу ни аналогия. ДОС - самостоятельная и законченная ось. Окошки, вплоть до вин95 - просто графическая надстройка над дос, расширяющая его возможности.

Прошу прощения, но это ни разу ни аналогия. ДОС - самостоятельная и законченная ось.

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

А кода в ней в десятки раз больше, чем в DOS.

Прошу прощения

Не простим незнакомства с матчастью. :) Потому что:

Окошки, вплоть до вин95 - просто графическая надстройка над дос, расширяющая его возможности.

Если беретёсь о чем-то рассуждать, матчасть надо знать.

Win9x (а по большей части, её ядро — VMM32) — это именно что полноценная ОС, которая занимается управлением памятью, в том числе виртуальной, подкачкой, созданием процессов и потоков и их планированием, парсингом исполняемых файлов и их запуском, перечислением физических устройств на шинах, загрузкой драйверов и их управлением, доступом к реестру, TCP/IP-сетью, эмуляцией функций 16-разрядного DOS-а для досовых приложений и еще десятками функций. В том числе, и работой с драйверами видеокарты, да.

Нихера ж себе «графическая надстройка».

Аналогия с grub абсолютно верна. grub не содержит даже такой простой функции ОС как многозадачность. И DOS её не содержит.

DOS — это просто несколько десятков килобайт 16-разрядного кода из ранних 80-х, которые обеспечивали запуск приложений фактически на голом железе.

DOS умела в аппаратную многозадачность, обеспечиваемую режимами защиты памяти на I286 и виртуализации адресных пространств, начиная с I386. Что обеспечило сначало кооперативную многозадачность во всяких оболочках типа GeOS, а затем и вытесняющую многозадачность в BeOS, WinNT3.5, Win95, NT4.0.

DOS умела в аппаратную многозадачность, обеспечиваемую режимами защиты памяти на I286 и виртуализации адресных пространств, начиная с I386.

Виртуальную память умел. Многозадачность — нет.

Проекты были такие. Массового внедрения — не было.

Массовое внедрение многозадачности от MS шло через ядро VMM, то есть винды.

Что обеспечило сначало кооперативную многозадачность во всяких оболочках типа GeOS, а затем и вытесняющую многозадачность в BeOS, WinNT3.5, Win95, NT4.0.

Какой-то бессвязный набор слов. Ничего не понял. В одной куче BeOS, NT, 95.

В Borland Pascal 7.0 был режим компиляции программ «для защищённого режима DOS». Что это, как не готовность к работе в режиме многозадачности?

Ссылка: https://www.helloworld.ru/texts/comp/lang/pascal/bp70_lr/lr17.html

Уже ночь на дворе и я от усталости не совсем понимаю, что это:

Не простим незнакомства с матчастью.

Если беретёсь о чем-то рассуждать, матчасть надо знать.

Я написал, что

Окошки, вплоть до вин95 - просто графическая надстройка над дос, расширяющая его возможности.

На это вы мне рассказываете про Вин95. Вы уверены, что правильно понимаете значение предлога «до»?

Повторю еще раз, но более развернуто. Версии Windows, начиная с 1.0 и заканчивая 3.11, не являлись операционными системами. Первая Windows, имеющая собственное ядро, была Вин95. Тут вы смогли в педивикию, хвалю.

Между прочим, мне приходилось работать с этим всем,когда оно еще не было копролитом. И даже переводить парк машин с 3.11 на офигенную и крутую вин95. Которая хоть и тормозила безбожно, но была верхом совершенства в наших юных глазах.

Вы ошибаетесь, так как не вникали в тему. Между 3.11 и 9x нет принципиальной разницы. Там одно и то же ядро.

Если не ошибаюсь, ядро для работы в защищенном режиме 80386 оформилось еще в Windows 2.1, но было очень сырым. Окончательно стек драйверов устоялся как раз к концу линейки 3.1х.

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

Различных вариантов реализации рантайма защищенного режима поверх DOS было много. Но чаще всего они не ставили целью создавать какую-то ОС-подобную концепцию. Это был просто рантайм для выполнения однозадачного приложения.

Ты не путаешь RHEL с федорой? красношапка - это суровый ынтырпрайз для сирисли бузинес.

Вообще-то бОльшинство софта опакечено именно под дебиан/убунту - я имею ввиду всякие там вайберы, слаки, стимы, и прочее проприетарное, гарантируется какая-никакая работа в этом окружении.

Когда я говорю «нормальная работа» подразумевая дистрибутив - это значит что можно без особого секаса поставить non-free софт.

прям ностальджи :-D

самое интересное - ТС - ГДЕ СКРИНЫ WHDD? где выхлоп fsck? ну давай, раз уж обэтосамое, хотя бы покажи, прав ли был я по поводу мертвого винта - самое забавное что за n страниц срача никто не догадался попросить детали об железе и ОС. ЛОР, стареешь.

Какой человек в своём уме вообще поставит 32-битную десятку в 2021?

Для 64 бит есть WineVDM. Проверял, работает. Также как и NTVDM он реализует ядро Win16 и транслирует вызовы Win16 в Win32 но там свой эмулятор процессора не зависящий от 16 битного режима процессора. Есть умельцы, которые портировали NTVDM из утёкших исходников на 64 бит.

самое интересное - ТС - ГДЕ СКРИНЫ WHDD? где выхлоп fsck?

Диагностика? Зачем? ТСу это не нужно. Он решил, что 146% виновато ядро и хочет, чтобы его поддержали.

Если у тебя что-то гадит в страничный кэш или в страницы, выделенные под данные для выполнения IRP, то хрен какие проверки это найдут.

В BeOS/Haiku в заголовках файловой системы есть несколько magic-чисел со случайным значением, если их значение будет неправильным при попытке обращения к ФС, то можно вызывать kernel panic.

Хорошо спроектирована для системы, работающей в сегментном режиме на процессоре, который изобрёл кривую архитектуру специально чтобы имитировать 16-разрядное адресное пространство i8080

Я про проектирование API, внутренности Windows много раз менялись. Основное API не связанное с 16 битной сегментной памятью одинаковое в Win16 и Win32. Можно было так писать чтобы один код компилировался в Win16 и Win32. В Watcom C++ можно посмотреть примеры, там почти всё компилируется в Win16 и Win32, а также свою реализацию 32 бит поверх Win16. Примеры из Windows 1.0-3.1 SDK компилируются и запускаются на Windows 10 с минимальной доработкой напильником. Было много программ, у которых были 16 и 32 битные версии и они не сильно отличались друг от друга (дизайн кнопок и диалогов немного другой и всё). Я сам до сих пор пользуюсь одной программой у которой есть Win16 версия.

Аналог Windows 1.0 для 32 или 64-битного режима сейчас на Си напишет любой умный студент за 3-4 месяца.

Не напишет. Основная сложность не реализация, а проектирование API. В Линуксе до сих пор нормальное API спроектировать не могут. Win16 программы даже HiDPI на современных мониторах поддерживают.

Да-да, улетели именно те директории, которые были открыты на момент сбоя

Да. Папка у тебя была открыта и все файлы оттуда выпали, когда свет погас. Какую же херню ты несёшь.

Между 3.11 и 9x нет принципиальной разницы. Там одно и то же ядро

Давайте на этом остановимся.

Ничего не понял. Остановимся на вашем незнании предмета? Хорошо.

Перескочил на сорцовую совместимость.

Хотя о чем я, первый раз что ли.

Перескочил на сорцовую совместимость.

Я изначально под проектированием имел в виду проектирование API. Особенности реализации можно потом менять так что никто не заметит.

Что касается проектирования реализации, это было вероятно лучшим решением, возможным на том железе.

Уже обсуждали ведь, какие костыли были в API для выделения памяти. Лень по второму кругу.

См. выше моё замечание о сумрачных инженерах Интел.

Современный студент не смог бы адаптировать костыли для древней сегментной модели? Ну и слава Богу. Я так и сказал, что для 32 бит он бы написал.

Уже обсуждали ведь, какие костыли были в API для выделения памяти.

Это особенность платформы/железа. В Win32 Global/LocalAlloc — это обёртка над HeapAlloc. На железе тех времён и не так извращались, меняли банки памяти и т.п.. В Windows было сделано наиболее адекватное и портируемое решение из возможных. В Mac OS Classic был более убогий менеджер памяти с фиксированным объёмом памяти на программу и который невозможно было портировать на новое железо. И это на 32 битном процессоре.

Я так и сказал, что для 32 бит он бы написал.

Что-то не видно нормальных проектов студенческих тулкитов и оконных систем. Единственное достойное — Serenity OS. Даже в Линуксе до сих пор не могут нормально сделать.

Современный студент не смог бы адаптировать костыли для древней сегментной модели? Ну и слава Богу.

Там ничего сложного нет, я специально изучал. Даже баг в WineVDM писал.

В чем особая «нормальность» виндового?

Надо просто не ломать совместимость без необходимости, вот и вся нормальность.

А так под линукс пакуем приложения в portable сборки с нужными либами, и всё тоже будет работать десятилетиями.

Сложность в том, что нужно вообще в это всё вникать, чтобы понимать, как запроектировать API для сегментной модели памяти.

А так особой сложности нет, когда можно подсмотреть в готовые решения.

Опять ничего не понимаю: то студент не смог бы, то сложности нет. Ну хз.

Опять ничего не понимаю: то студент не смог бы, то сложности нет. Ну хз.

Я про графическую подсистему и тулкит, а не про ядро. Любительских UNIX-подобных ядер много клепают.

Есть такой крутейший rvm, который позволяет для кода на ruby создавать произвольное количество изолированных от влияния других пакетов программных сред. Можно для каждого приложения держать свою среду.

Плюс есть замечательный bundler примерно для той же задачи в другом разрезе.

Что применительно к целой ОС будет неким заменителем rvm?

Правильно, Bedrock Linux.

Всерьез рассматриваю возможность накатить его на основную ОС.

Линуксу нужны не стоны о кривых апи, а метадистрибутивный менеджер.

Ну и что там особенного в тулките? Тулкит и тулкит.

В чем особая «нормальность» виндового?

В X11 много мелких недочётов (планировка перерисовки, состояния и управление окнами, обработка закрытия окон, неэффективная обработка протокола в xlib и т.п.) и копролит вместо серверной графики (в Windows нативные программы на серверной графике выглядят вполне современно). Недочёты исправлялись кучей подпорок-расширений, а в WinApi всё было спроектировано сразу правильно без расширений. В Wayland ещё и сломали оконную логику и взаимодействие между окнами под предлогом безопасности, хотя мне ещё никто не показал кого взломали через «кейлоггер» X11 и прочие «уязвимости».

Какая еще серверная графика в винде??

Уж кейлоггеры-то под винду мы помним, кстати.

Какая еще серверная графика в винде??

GDI. Работает в win32k.sys в ядре, что является функциональным аналогом X-сервера.

И как? Передает всё через сокет?

win32k.sys

Я аж не сразу сообразил от неожиданности.

Какой еще win32k.sys в Windows 1.0??

Передает всё через сокет?

Через системные вызовы, которые устанавливает win32k.sys через свою отдельную таблицу системных вызовов. В Windows NT 3.5 вроде бы был настоящий отдельный процесс GUI-сервера и данные передавались через IPC-порт.

Какой еще win32k.sys в Windows 1.0??

В Windows 1.0 вообще процессов не было, только библиотеки с прямым импортом функций. Так что там архитектуры клиент-сервер в GUI просто не могло быть. GUI-сервером с натяжкой можно назвать USER.EXE.

Но суть в другом: серверная графика подразумевает возможность рисовать напрямую на фреймбуфер без композитора.

мне ещё никто не показал кого взломали через «кейлоггер» X11 и прочие «уязвимости».

Я помню, как в 98/99м году в институте написал програмку, которая делала скриншот других X11 сессий на сервере. Думал будет прикольно посмотреть, что там делают коллеги. Но они ничего интересного не делали :(.

В этом разговоре у тебя вообще много натяжек 😸

Но суть в другом: серверная графика подразумевает возможность рисовать напрямую на фреймбуфер без композитора.

https://youtu.be/fwBEAX8sL24

Но суть в другом: серверная графика подразумевает возможность рисовать напрямую на фреймбуфер без композитора.

Если что, я под этим понимал возможность рисовать нескольким программам на одном фреймбуфере без композитора. Без глобальной GUI системы, принимающей запросы на отрисовку примитивов, так сделать нельзя. USER/GDI.EXE, win32k.sys, X.Org, app_server (BeOS/Haiku) так умеют.

Понятнее не стало.

Это называется оконная система в частном случае, либо мультиплексор в случае произвольного ресурса. Мультиплексирование одна из главных задач ОС.

Какой еще сервер?

Это называется оконная система в частном случае

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

Мультиплексирование одна из главных задач ОС.

X11 с этим справляется хуже WinApi на уровне протокола. Тот же тиринг — одно из проявлений кривого механизма планировки перерисовки, в WinApi есть BeginPaint/EndPaint.

Тот же тиринг — одно из проявлений кривого механизма планировки перерисовки, в WinApi есть BeginPaint/EndPaint.

Какой еще BeginPaint/EndPaint для иксов?

Рендеринг в окно выполняется через XRenderComposite() и XCopyArea(). А нехрен выполнять эту операцию так, что начало и конец оказываются в разных кадрах. Все вопросы к внутренностям иксов.

BeginPaint/EndPaint.

И как поможет BeginPaint/EndPaint, если отрисовка не уложилась в один кадр?

Тиринга не видел на Win9x? А как окно кусками рисуется или перетаскивается видел?

Почему у меня ощущение, что ты Win9x только на скриншотах видел?