OSDev

Немного не в тему, но ArcaOS 5.1, о которой было на позапрошлой странице - таки вышла ...
Полуось на EFI, с доссессиями и Win16, число кодеров по пальцам одной руки, однако оно грузится с NVME и как-то, местами, умудряется работать с новым железом
Средний возраст юзеров колеблется где-то >=60-ти
На форуме os2world.com даже был забавный вопрос - "вот мне 85, объясните мне зачем мне эта новая версия"

В общем, весьма любопытный артефакт для нынешнего времени

Нда, я всё ещё здесь - люблю отмечаться в пятницу, 13-го, хоть в этом году и промахнулись на один день

За год ничего особо интересного - ну только если зоркий сокол в какой-то момент заметил, что большинство поддерживаемых файловых систем работают в юникоде и перетащил в юникод всё системное файловое API со всеми таблицами файлов итд.

Попутно и команды шелла удостоились того же и copy *.* будет реально копировать юникодные имена, даже если кодовой страницы для них в QSINIT нет в принципе.

Ещё починена работа на 80486 Племя некрофилов оказалось довольно активным и поступил вот такой запрос. В итоге - диапазон поддерживаемого железа от 486sx25 с 8Mb, загруженного с дискеты до скольких там сейчас можно найти для EFI версии?

Ну и куча всякой мелочи, сборка EFI версии на GCC, итд, итп ... попутно выяснилось, что команда SUBST - не самая простая вещь для написания Может, конечно, стоило подсмотреть в виндовые исходники, но смысл-то - склепать всё это на основе собственной логики

А 80386 слабо?

80386 - это мазохизм, учитывая все его забагованные ревижны ...
Как бы, 486 не требует особых усилий - ну только, если, мявкнуть юзеру, что FPU нет и пристрелить приложение в случае SX.

Да и с памятью - можно представить себе 486 с 8ю и даже 16ю метрами, а 386 уже потребует полноценного свопа
Нафиг - эпоха, когда бились за каждую страницу памяти - эти тяжко и лучше не вспоминать и забыть

Ну, потребности в памяти определяются задачами, если ось не совсем уж пыхтон-стайл Скажем, RSX-11M летала на 248 Кбайтах оперативы, обеспечивая работу нескольких пользователей -- но, есно, никакой графики, так что 80386 с парой метров был бы просто суперкомпутером при таком же подходе к использованию.

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

248k уже не получится банально из-за разрядности ... не говоря, уж, о накопленной сложности вещей.
Даже и 16-битный код - ну, вот, фильтр для поддержки GPT разделов для той полуоси выше - 30k чистых 16-ти бит ... А это одна небольшая задача из тысяч

А это изделие - проверил, на 8 метрах (реально 7) - остаётся где-то 3 свободных.
Конечно, на 8-ми вполне себе жили когда-то и было "нормально" Но сколько в этом было подсчётов каждого байта в ядре, который может или не может быть свопируем и сколько оно в итоге свопило ...

Таки, когда памяти много - это хорошо

Другой вопрос, что да - масса навешенного мусора в современных системах, порождённого симуляцией бурной деятельности, съест всё что есть и попросит ещё ...

Ну, из 248 кил оперативы сама ось под себя жрала меньше сотни, если в полной конфигурации и включая драйверы режима ядра (но не включая драйверы файловых систем, которые всегда были задачами режима пользователя; впрочем, они были мелкими). Правда, ось написана полностью на ассемблере, т.е. раза в три компактнее, чем можно слепить на тех же сях. Ну и, ядро полностью резидентно, никаких тебе загрузок-выгрузок ядерного кода.

А в чём состоит задача этого самого фильтра, что он аж 30 кил требует? (GPT-разделы не изучал, хотя надо б как-нибудь осилить)

Всё на ассемблере - это компактно и быстро, но требовательно к авторам
То же самое полуосевое ядро в большом проценте на ассемблере и это сделало его куда более нестабильным в сравнении с той же NT 4.0, например. Но и расходы памяти пропорционально различались, конечно ...

А фильтр представляет смонтированные GPT разделы как отдельные MBR диски в системе - так куда проще встроиться в полуосевую реальность прошлого тысячелетия. При этом он GPT разбивку и проверяет и апдейтит и раздаёт всякое через IOCTL. Учитывая, что в GPT все поля 64-битные, можно представить сколько там кода генерится на обычное сложение. Ватком справляется, конечно - но набегает 30k.