Нет, уж это Вы определяйтесь, коллега, что такое Матрикс. Пока что видно только нечто размытое, конкретизированное только в части интерфейса с прикладняком (и написанное с позиции прикладного программиста). Какие там функции будут в Матриксе для графики или файловой системы - дело десятое, тем более похоже совместимостью по вызовам с *nix-ами, CPM или VNC тут и не пахнет.
Главное, совершенно не понятно - "за чей счет банкет", т.е. за счет чего вообще что-то будет работать (как будет работать ядро), как все будет увязано в общую систему, а не набор программ, которые работают как хотят (хотят - пишут/читают в/из "ящик", хотят - нет, хотят - сами инициируют переключение диспетчера для работы с другими страницами памяти)
Да было уже. Года три наза в этом же разделе перетирали, и в теме про SymbOS тоже. И опять повторение распространенной ошибки (я бы даже сказал, ярлыка) - "все тормоза из-за C". Ничуть не бывало, 50% разницы - это не разница, не та цена за кросплатформенную совместимость на уровне исходников, чтобы так просто от нее отказаться ради ассемблерной самодеятельности. Все тормоза из-за больших накладных расходов, алгоритмических, которые как раз в ядре. Я и SymbOS привел в пример исключительно как образец колоссального квалифицированного труда автора, и в целом симпатичную систему, но программ в которой будет ровно столько, сколько успеет написать сам автор. Т.е. катастрофически мало, "поставил-посмотрел-снёс".
32М ограничение на размер FS в юзиксе оттого, что это 16-битная FS - у разработчика UZI в мхомпоросших 80-х годах прошлого века компилятор не умел 32 бит int, а при переводе на Hitech C (т.е. в UZIX) ничего кардинально не переписывалось. Но можно монтировать несколько FS, а еще лучше - переписать в 32 бита. Зато это СИСТЕМА. Мне вот не нужена еще одна прога-запускалка игр, таких уже имеется в наличии - запускают и с винта в сотню гигов (насчет 160 - этого конечно нет, а у вас что, и LBA48 в планах?), и с CD-привода.






Ответить с цитированием