Board.KolibriOS.org

похоже иметь свой дситр стало модно? =) может и своё замутим? основное о чем я подумал:
1. Домашнее ручное ядро живущее в теплом винте с фат32
2. Перелапачить ядро: уменьшить кол-во контекстов в функционировании гуи, рисскнуть занятся сексом с выносом дров из ядра
3. Сделать стиль винды =)

твой ход

Домашнее ручное ядро живущее в теплом винте с фат32

Одобряю.Но, чтобы ещё можно было образ на флоп и сд сбросить.Ну и поддержку NTFS, ext 1/2/3 и нового формата файловой системы, придуманной Мелкософт для нового Windows Loghorn .

Перелапачить ядро: уменьшить кол-во контекстов в функционировании гуи, рисскнуть занятся сексом с выносом дров из ядра

Я уже давно ношу идею по подключению дров, как в Линуксе и других *nix, т.е. дрова подгружаются в ядро только по мере обнаружения нужных устройств.
Ну, нужно не только создать Gui, но и должное внимание уделить консоли.Ведь без неё - никуда .

Сделать стиль винды =)

Довольно смелое и рисковое решение .Всетаки не хочется слишком следовать стандартам, нужно продумать и создать собственный стиль .Так будет лучше...
А вот мои идеи:

1) Сделать несколько режимов загрузки ядра: с граф. наворотами и без них(типа безопасный режим ).

2)реализовать поддержку стандартного набора звуковых карт.

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

4)Подключать к ядру специальный модуль с низкоуровневыми API-функциями(а лучше разбить все АПИ по модулям и подгружать отдельно).

Твой ход .

Как раз создание менеджера памяти и направлено на решение всех этих вопросов.

Кстати про твой менеджер, ты писал что маллок даёт байты только в переделах одной страницы. Нафик так?

CodeWorld wrote: Нафик так?

Это позволяет выделять память на много быстрее - за O(1). Для выделения большего куска будет другая (еще не написанная) более сложная функция (она выделит нужное число страниц и отобразит их на какой-либо регион).