NedoOS

[Sayman]

БИОС и БДОС это CP/M-ная чушь.

на сегодняшний день CP/M и его клоны пока единственные адекватные системы для z80 и рядом стоящих процессоров (вроде 6502 и иже с ними). массовей систем для подобных процессоров пока никто не придумал. будешь первым?

Строго говоря и DOS и CP/M это не ОС, а запускалки прог с драйвером диска.

пускалка это tr-dos, которая по сути своей есть расширение для бейсика. про дос:

DOS управляет памятью с помощью блоков MCB (Memory Control Block). Память разбивается на блоки; каждому блоку предшествует MCB, в котором записаны характеристики блока памяти. Для каждой вновь запускаемой программы DOS создает определенное количество блоков MCB. При освобождении памяти или при выполнении запросов на получение дополнительной памяти DOS также использует блоки MCB, проверяя при этом правильность их содержимого.

так что дос умеет управлять памятью (это если про ms-dos говорить). про cp/m: реализаций этой системы вагон и малая телега. среди разных клонов есть и такие, где есть управление памятью. примером является profi-dos/pq-dos для Profi.

Никакой программист не станет писать константы числами.

причём тут константы? я разве про это говорил? почитай мануал на издос. много ли ты там поймёшь? особенно когда "номера" функций гуляют по разным "модулям" и уровням. глаза сразу кровоточат, а в голове возникает каша.

Многозадачные ОС по-другому не работают.

а что если мне плевать на многозадачную ОС и у меня простая ДОС?

но при этом использовать готовые библиотеки той же FAT, которые едят в 1000 раз больше времени

я не являюсь поклонником сабжа и меня самого жутко бесит вкаряченный fatfs. он медленный и не поворотливый и сожрал там почти 16кб памяти (байт 500 примерно осталось свободно).
и вот теперь давай считать:
ты предлагаешь всё свалить в одну кучу. как разделять вызовы между bdos (а он 100% должен быть, т.к. отвечает за работу с файлами, каталогами, парсинг строк, переменные окружения, бла бла, много чего там сидит (не конкретно в сабже, я вообще)) и, скажем, логическими драйверами? пишу я fdisk с форматилкой. мне надо делать разбор переданных аргументов (функционал bdos), мне надо прочитать 0й сектор с винта (bios), мне надо делать вывод на экран, мне надо делать ещё 512 разных манипуляций. при этом имей в виду, что вывод на экран тут будет самым прожорливым, т.к. местами придётся буквально побайтно делать вывод некоторых элементов. и вот есть две системы - твоя и ещё какая-то. но в твоей сисстеме ты не стал заморачиваться на производительности и всё свалил в кучу. а в другой наоборот автор озаботился об 1% оптимизации. как думаешь, где будет приятнее работать, в твоей оси или где то ещё? ответ очевиден.
в сабже та же проблемма - рестартов много, но они используются глупо, не рационально. когда начинаешь читать файло с каким-то разбором, парсингом, то приходится часто обращаться к системе за очередной порцией данных. и как всё это будет тупить, когда А - у тебя fatfs, Б - у тебя ничего не оптимизированно, длинные вызова которые не умеют различать куда идёт вызов (точнее умеют, но делают это дольше, чем если бы были на отдельном рестарте). кстати, ты сам там жаловался на монолитность, но сам же за неё топишь.

Например, предоставление экрана как фреймбуфера определённого формата.

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