Разработка ОС
Кому-нить это интересно?
Я вот тут полазил по инету в поисках интересных наработок у различных людей. И в основном встречал всякого рода ненужности. У кого нибудь есть интересные (новые) идеи в плане архитектур систем. Лично я встречал в основном разработки, которые не имеют будущего. Да и вообще встретить хоть что-нить рабочее не представилось возможности. Единственное что работало это MenuetOS. Но это, извините, полный бред. У такой ОС (если ее можно так назвать) вообще будущего нет. Остальные странички по этой тематике находятся либо только на начальной садии, либо уже не обновлялись очень долго (хотя по сути находятся тоже только на начальной стадии).
Если кто-то считает себя очень умным в данном вопросе, поделитесь своими идеями, приведите стоящие ссылки и т.п.
Лично у меня идей по архитектуре не так уж много. Все мои идеи касаются только микроядерных систем.
Главные постулаты моих идей :) :
1. Ядро должно быть абстрогировано от всей аппаратной части компьютера, кроме конечно самого процессора и памяти :)
2. Всем процессам обязательно предоставляется полная плоская модель памяти в 4ГБ.
3. Должны быть все необходимые механизмы взаимодействия процессов с системой и между собой.
4. Система обязательно должна предусматривать механизмы распределения ресурсов между процессами.
Мне бы хотелось увидеть ваши взгляды на то, как можно было бы реализовать вышеуказанные пункты.
Самая главная ошибка, которую я встречал почти везде - попытка написания ОС без детального проектирования ее структуры (поэтому часто и встречается один загрузчик - его написали а что дальше делать неизвестно, вот все странички и находятся на начальной стадии). Нужно сначала понять что ты хочешь сделать, как, разработать алгоритмы, а уж потом кодить. Конечно, многие предпочитают пропускать разработку алгоритмов, скажем, на бумаге. Я тоже так делал в институте - сначала напишу прогу, а потом рисую по ней блок-схему для отчета. Это, ваше право, но что и как должно быть придумано заранее, а не потом - по ходу. Поэтому я и хочу услышать ваши предложения.
Самое главное, как можно меньше стараться изобретать велосипед. Например, не нужно писать свой загрузчих - их и так море. Но только не говорите, что разработка ОС - это тоже велосипед, я это и сам знаю :)
Также интересный вопрос по поводу инструментальных средств. Самая главная проблема - это то, что все они заточены под какую-нить ОС. Отсюда встает проблема написания программ для нашей ОС, и самое главное - их отладки. Интересно, что вы думаете по этому поводу?
В плане инструментальных средств из ассемблеров стоящими я считаю только TASM (пока придерживаюсь его), MASM, NASM (был бы лучшим если бы мог поддерживать нормально структуры и что-то типа режима Ideal TASM-a). Я не привожу здесь компиляторы языков ЯВУ, потому что считаю, что для разработки ядра нужен в первую очередь хороший ассемблер. ЯВУ использовать нужно только для разработки интерфейсных и прикладных программ разрабатываемой ОС. Поэтому необходим компилятор с открытым кодом, чтобы потом попробывать заточить его под новую Ось, ведь свой собственный писать ух как не охота!
Я вот тут полазил по инету в поисках интересных наработок у различных людей. И в основном встречал всякого рода ненужности. У кого нибудь есть интересные (новые) идеи в плане архитектур систем. Лично я встречал в основном разработки, которые не имеют будущего. Да и вообще встретить хоть что-нить рабочее не представилось возможности. Единственное что работало это MenuetOS. Но это, извините, полный бред. У такой ОС (если ее можно так назвать) вообще будущего нет. Остальные странички по этой тематике находятся либо только на начальной садии, либо уже не обновлялись очень долго (хотя по сути находятся тоже только на начальной стадии).
Если кто-то считает себя очень умным в данном вопросе, поделитесь своими идеями, приведите стоящие ссылки и т.п.
Лично у меня идей по архитектуре не так уж много. Все мои идеи касаются только микроядерных систем.
Главные постулаты моих идей :) :
1. Ядро должно быть абстрогировано от всей аппаратной части компьютера, кроме конечно самого процессора и памяти :)
2. Всем процессам обязательно предоставляется полная плоская модель памяти в 4ГБ.
3. Должны быть все необходимые механизмы взаимодействия процессов с системой и между собой.
4. Система обязательно должна предусматривать механизмы распределения ресурсов между процессами.
Мне бы хотелось увидеть ваши взгляды на то, как можно было бы реализовать вышеуказанные пункты.
Самая главная ошибка, которую я встречал почти везде - попытка написания ОС без детального проектирования ее структуры (поэтому часто и встречается один загрузчик - его написали а что дальше делать неизвестно, вот все странички и находятся на начальной стадии). Нужно сначала понять что ты хочешь сделать, как, разработать алгоритмы, а уж потом кодить. Конечно, многие предпочитают пропускать разработку алгоритмов, скажем, на бумаге. Я тоже так делал в институте - сначала напишу прогу, а потом рисую по ней блок-схему для отчета. Это, ваше право, но что и как должно быть придумано заранее, а не потом - по ходу. Поэтому я и хочу услышать ваши предложения.
Самое главное, как можно меньше стараться изобретать велосипед. Например, не нужно писать свой загрузчих - их и так море. Но только не говорите, что разработка ОС - это тоже велосипед, я это и сам знаю :)
Также интересный вопрос по поводу инструментальных средств. Самая главная проблема - это то, что все они заточены под какую-нить ОС. Отсюда встает проблема написания программ для нашей ОС, и самое главное - их отладки. Интересно, что вы думаете по этому поводу?
В плане инструментальных средств из ассемблеров стоящими я считаю только TASM (пока придерживаюсь его), MASM, NASM (был бы лучшим если бы мог поддерживать нормально структуры и что-то типа режима Ideal TASM-a). Я не привожу здесь компиляторы языков ЯВУ, потому что считаю, что для разработки ядра нужен в первую очередь хороший ассемблер. ЯВУ использовать нужно только для разработки интерфейсных и прикладных программ разрабатываемой ОС. Поэтому необходим компилятор с открытым кодом, чтобы потом попробывать заточить его под новую Ось, ведь свой собственный писать ух как не охота!
> Кому-нить это интересно?
Научно доказано и эксперементально проверено, что программирование в нулевом кольце программирование в нулевом кольце повышает уровень адреналина в крови. Это привлекает экстремалов. Эту бы энергию, да на направить против империализма!
> Я вот тут полазил по инету в поисках интересных наработок у различных людей.
Написание OS имеет несколько особенных черт. Во-первых, пока не написан более или менее рабочий вариант, это никому не нужно. Второе, даже если написан рабочий вариант, он тоже зачастую никому не нужен. И в третьих, в качестве оплаты за труд, разработчик получает в лечшем случае недоумение окружающих. Исключениями можно смело пренебречь.
> 1. Ядро должно быть абстрогировано от всей аппаратной части компьютера, кроме конечно самого процессора и памяти
Мое мнение --- должно быть микроядро, привязанное к конкретной программно--аппаратной реализации, а остальное на языках высокого
уровня.
> 2. Всем процессам обязательно предоставляется полная плоская модель памяти в 4ГБ.
Твой выбор. В принципе это не обязательно. 4 Гб --- тоже ограничение. Для чего-то же вводились функции поддержки AWE в W2k? Но плоская модель проще.
> 3. Должны быть все необходимые механизмы взаимодействия процессов с системой и между собой.
4. Система обязательно должна предусматривать механизмы распределения ресурсов между процессами.
Перечислять, что должно быть, не хватит места.
> Мне бы хотелось увидеть ваши взгляды на то, как можно было бы реализовать
вышеуказанные пункты.
Вообще Ваше описание довольно общно, а поэтому лишено содержания. Что-либо обсуждать трудно. Но все-же
Попытаюсь пофантазировать:
~~~~~~~~~~~~~~~~~~~~~~~~~~
Требования к OS:
Windows compatible. Не 100%, но хоть сколько-то. Можно предоставить свой ООП интерфейс, а Windows API реализовать как надстройку над ним.
Сразу отпадет проблема написания софта под OS. Те же 4 Гб плоской модели. По похожему пути пошла фирма On time, написав RTOS-32 для системм реального времени и встраиваемых приложений. RTOS-32 предоставляет достаточные средства для поддержки кода загрузки многих компиляторов. Полученный EXE-файл может быть преобразован в двоичный и прошит в ПЗУ.
Средство разработки:
Windows компиляторы. Писать все на ASM-е утомительно. Мне, например, нравиться Delphi. В этом случае можно порекомендовать следующий план:
I. Пишется загрузчик, способный загрузить DOS EXE-файл. Если таковой имеется, то воспользуемся ним.
II. Создается DOS EXE-файл, переходящий в защищенный режим и передающий управление DLL (Win PE). Для случая программ на Pascal необходимо пропустить код загрузчика, и настроть сегмент DS. Для кода BC++ 3.1 необходимо написать собственный загрузчик, который бы вызывал функцию main(), не производя при этом никаких посторонних действий. Подобная программы могла бы быть отлажена под управением MS--DOS (за исключением перехода в защищенный режим). Специфична только работа с памятью, что лекго может быть обойдено при помощи средств условной компиляции. Например, для Pascal:
{$IFDEF DOS}
GetMem(P, 4096);
{$ELSE}
P := Ptr(TopSegment, 0);
TopSegment := TopSegment + 4096 div 16
{$ENDIF}
III. Для передачи параметров DLL можно использовать список экспорта. Скажеи GDT лучше организовать в сегменте данных DLL, чтобы облегчить впоследствии к ней доступ. Туда же можно скопировать блок параметров Bios, указания того, какие страницы из 1-го мегабайта заняты, ... В список экспорта лучше поместить также точку входа, чтобы прыгнуть на нее миновав стандартный загрузчик.
IV. В DLL я бы первым делом реализовал функции ввода/вывода на экран, для просмотра регистров. Вообще, тут лучше заранее думать о том, как впоследствии производить отладку, посему оформлять кроме низкоуровневой, также и Windows реализацию специфичных процедур,
V. Обработка прерываний и вывод lиагностических ошибок для исключений. Клавиатура. Таймер пока не нужен.
VI. Менеджер памяти. В первую очередь, конечно, виртуальной. Но нисколько не помешает и менеджер кучи, особенно, если предоставлять пользователю интерфейсы объектов.
VII. В качестве интерфейсов я бы выбрал COM (на уровне IUnknown + свои интерфейсы). Программировать в терминах объектов приятнее.
Далее: обработка исключительных ситуаций, работа с FAT, загрузка процесса и передача ему управление, написание простейшего обработчика команд (shell), выставление исходнгиков продукта на всеобщий попуск, поиск собратьев по несчастью.
Недавно я, после тяжелой и продолжительной болезни, не приходя в сознание, по-приколу, реализовал пункты I-III этого плана (ориентируясь больше на Delphi). Кому интересно --- шлите на e-mail.
Научно доказано и эксперементально проверено, что программирование в нулевом кольце программирование в нулевом кольце повышает уровень адреналина в крови. Это привлекает экстремалов. Эту бы энергию, да на направить против империализма!
> Я вот тут полазил по инету в поисках интересных наработок у различных людей.
Написание OS имеет несколько особенных черт. Во-первых, пока не написан более или менее рабочий вариант, это никому не нужно. Второе, даже если написан рабочий вариант, он тоже зачастую никому не нужен. И в третьих, в качестве оплаты за труд, разработчик получает в лечшем случае недоумение окружающих. Исключениями можно смело пренебречь.
> 1. Ядро должно быть абстрогировано от всей аппаратной части компьютера, кроме конечно самого процессора и памяти
Мое мнение --- должно быть микроядро, привязанное к конкретной программно--аппаратной реализации, а остальное на языках высокого
уровня.
> 2. Всем процессам обязательно предоставляется полная плоская модель памяти в 4ГБ.
Твой выбор. В принципе это не обязательно. 4 Гб --- тоже ограничение. Для чего-то же вводились функции поддержки AWE в W2k? Но плоская модель проще.
> 3. Должны быть все необходимые механизмы взаимодействия процессов с системой и между собой.
4. Система обязательно должна предусматривать механизмы распределения ресурсов между процессами.
Перечислять, что должно быть, не хватит места.
> Мне бы хотелось увидеть ваши взгляды на то, как можно было бы реализовать
вышеуказанные пункты.
Вообще Ваше описание довольно общно, а поэтому лишено содержания. Что-либо обсуждать трудно. Но все-же
Попытаюсь пофантазировать:
~~~~~~~~~~~~~~~~~~~~~~~~~~
Требования к OS:
Windows compatible. Не 100%, но хоть сколько-то. Можно предоставить свой ООП интерфейс, а Windows API реализовать как надстройку над ним.
Сразу отпадет проблема написания софта под OS. Те же 4 Гб плоской модели. По похожему пути пошла фирма On time, написав RTOS-32 для системм реального времени и встраиваемых приложений. RTOS-32 предоставляет достаточные средства для поддержки кода загрузки многих компиляторов. Полученный EXE-файл может быть преобразован в двоичный и прошит в ПЗУ.
Средство разработки:
Windows компиляторы. Писать все на ASM-е утомительно. Мне, например, нравиться Delphi. В этом случае можно порекомендовать следующий план:
I. Пишется загрузчик, способный загрузить DOS EXE-файл. Если таковой имеется, то воспользуемся ним.
II. Создается DOS EXE-файл, переходящий в защищенный режим и передающий управление DLL (Win PE). Для случая программ на Pascal необходимо пропустить код загрузчика, и настроть сегмент DS. Для кода BC++ 3.1 необходимо написать собственный загрузчик, который бы вызывал функцию main(), не производя при этом никаких посторонних действий. Подобная программы могла бы быть отлажена под управением MS--DOS (за исключением перехода в защищенный режим). Специфична только работа с памятью, что лекго может быть обойдено при помощи средств условной компиляции. Например, для Pascal:
{$IFDEF DOS}
GetMem(P, 4096);
{$ELSE}
P := Ptr(TopSegment, 0);
TopSegment := TopSegment + 4096 div 16
{$ENDIF}
III. Для передачи параметров DLL можно использовать список экспорта. Скажеи GDT лучше организовать в сегменте данных DLL, чтобы облегчить впоследствии к ней доступ. Туда же можно скопировать блок параметров Bios, указания того, какие страницы из 1-го мегабайта заняты, ... В список экспорта лучше поместить также точку входа, чтобы прыгнуть на нее миновав стандартный загрузчик.
IV. В DLL я бы первым делом реализовал функции ввода/вывода на экран, для просмотра регистров. Вообще, тут лучше заранее думать о том, как впоследствии производить отладку, посему оформлять кроме низкоуровневой, также и Windows реализацию специфичных процедур,
V. Обработка прерываний и вывод lиагностических ошибок для исключений. Клавиатура. Таймер пока не нужен.
VI. Менеджер памяти. В первую очередь, конечно, виртуальной. Но нисколько не помешает и менеджер кучи, особенно, если предоставлять пользователю интерфейсы объектов.
VII. В качестве интерфейсов я бы выбрал COM (на уровне IUnknown + свои интерфейсы). Программировать в терминах объектов приятнее.
Далее: обработка исключительных ситуаций, работа с FAT, загрузка процесса и передача ему управление, написание простейшего обработчика команд (shell), выставление исходнгиков продукта на всеобщий попуск, поиск собратьев по несчастью.
Недавно я, после тяжелой и продолжительной болезни, не приходя в сознание, по-приколу, реализовал пункты I-III этого плана (ориентируясь больше на Delphi). Кому интересно --- шлите на e-mail.
Ссори мужи, что в вашу дискуссию. Мыслей у меня по поводу ваших вопросов нет. Но я пришел к вам с
просьбой. Не могли бы вы посоветовать ресурсы, где со всем этим, что вы обсуждаете можно было бы
в деталях ознакомиться.
Очень бы хотелось ближе познакомиться
с кем-нить такими как вы, с большим опытом - в качестве Гуру.
Ну просто поймите разобраться со всем этим очень
хочеться, а жизнь коротка, литературы нема, да и
наворочено щас оченно уж много. Да и обиднно
больно ... писать вроде бы на С/C++ научился, в цифровой электронике, что-то понимаю ...
а простых вещей типа того, почему в W2k нельзя
к портам обращаться , и как действуют dll или so не понимаю и такого набирается в обыденной жизни очень много. Ну просто потому что не знаю, где прочитать или как подойти к изучению данного вопроса.
Вообщем если, чем то могете помочь плз mail to me
[email]malyshev_d@mail.ru[/email] or ICQ #38919178
Заране спасибо и прошу относиться без иронии ...
в конце то концов - учиться никогда не поздно.
просьбой. Не могли бы вы посоветовать ресурсы, где со всем этим, что вы обсуждаете можно было бы
в деталях ознакомиться.
Очень бы хотелось ближе познакомиться
с кем-нить такими как вы, с большим опытом - в качестве Гуру.
Ну просто поймите разобраться со всем этим очень
хочеться, а жизнь коротка, литературы нема, да и
наворочено щас оченно уж много. Да и обиднно
больно ... писать вроде бы на С/C++ научился, в цифровой электронике, что-то понимаю ...
а простых вещей типа того, почему в W2k нельзя
к портам обращаться , и как действуют dll или so не понимаю и такого набирается в обыденной жизни очень много. Ну просто потому что не знаю, где прочитать или как подойти к изучению данного вопроса.
Вообщем если, чем то могете помочь плз mail to me
[email]malyshev_d@mail.ru[/email] or ICQ #38919178
Заране спасибо и прошу относиться без иронии ...
в конце то концов - учиться никогда не поздно.
>Кому-нить это интересно?
Это интересно всякому программисту в определённый период времени...
>Я вот тут полазил по инету в поисках интересных >наработок у различных людей. И в основном >встречал всякого рода ненужности.
Может приведёте пример? Где полазили и какие ненужности...?
>У кого нибудь есть интересные (новые) идеи в >плане архитектур систем.
Может и есть... но найти способ их реализовать не всегда...
>Лично я встречал в основном разработки, которые >не имеют будущего. Да и вообще встретить хоть >что-нить рабочее не представилось возможности. >Единственное что работало это MenuetOS. Но это, >извините, полный бред.
???
К сожалению этот форум не читаю разработчики Менуэт....
Во всяком случае давно их не видел :)))
> У такой ОС (если ее можно так назвать) вообще >будущего нет.
Я понял ваш постинг. Вы имеете ввиду, что следует создать ОС на новых принципах и тогда поехали...
:_)))
> Остальные странички по этой тематике находятся >либо только на начальной садии, либо уже не >обновлялись очень долго (хотя по сути находятся >тоже только на начальной стадии).
>Если кто-то считает себя очень умным в данном >вопросе, поделитесь своими идеями, приведите >стоящие ссылки и т.п.
Это значит примерно следующее:
"Вы поделитесь своими идеями..., а ..."
А вас Билли не зовут, случайно :)))
>Лично у меня идей по архитектуре не так уж >много.
Интересно в чём их консистенция?
>Все мои идеи касаются только микроядерных >систем.
Гм.... а что значить просто ядерная система ? :)
>Главные постулаты моих идей :) :
>1. Ядро должно быть абстрогировано от всей >аппаратной части компьютера, кроме конечно >самого процессора и памяти :)
Нууууу, по моему вас точно зовут Билли...
Признавайтесь... неужели выучили русский :)))
>2. Всем процессам обязательно предоставляется >полная плоская модель памяти в 4ГБ.
Как вы это хотите реализовать???
>3. Должны быть все необходимые механизмы >взаимодействия процессов с системой и между >собой.
>4. Система обязательно должна предусматривать >механизмы распределения ресурсов между >процессами.
>Мне бы хотелось увидеть ваши взгляды на то, как >можно было бы реализовать вышеуказанные пункты.
>Самая главная ошибка, которую я встречал почти >везде - попытка написания ОС без детального >проектирования ее структуры (поэтому часто и >встречается один загрузчик - его написали а что >дальше делать неизвестно, вот все странички и >находятся на начальной стадии). Нужно сначала >понять что ты хочешь сделать, как, разработать >алгоритмы, а уж потом кодить. Конечно, многие >предпочитают пропускать разработку алгоритмов, >скажем, на бумаге. Я тоже так делал в институте -> сначала напишу прогу, а потом рисую по ней блок->схему для отчета. Это, ваше право, но что и как >должно быть придумано заранее, а не потом - по >ходу.
Вопрос: "А разве возможно что-то сделать, если не знаешь что???"
>Поэтому я и хочу услышать ваши предложения.
>Самое главное, как можно меньше стараться >изобретать велосипед. Например, не нужно писать >свой загрузчих - их и так море. Но только не >говорите, что разработка ОС - это тоже >велосипед, я это и сам знаю :)
Это как посмотреть...
>Также интересный вопрос по поводу >инструментальных средств. Самая главная >проблема - это то, что все они заточены под >какую-нить ОС. Отсюда встает проблема написания >программ для нашей ОС, и самое главное - их >отладки. Интересно, что вы думаете по этому >поводу?
По моему тебе стоит связатся с одним человеком..
Адреса так я не вспомню...., но напиши мне: [email]EdmondXASM@mail.ru[/email]
Это интересно всякому программисту в определённый период времени...
>Я вот тут полазил по инету в поисках интересных >наработок у различных людей. И в основном >встречал всякого рода ненужности.
Может приведёте пример? Где полазили и какие ненужности...?
>У кого нибудь есть интересные (новые) идеи в >плане архитектур систем.
Может и есть... но найти способ их реализовать не всегда...
>Лично я встречал в основном разработки, которые >не имеют будущего. Да и вообще встретить хоть >что-нить рабочее не представилось возможности. >Единственное что работало это MenuetOS. Но это, >извините, полный бред.
???
К сожалению этот форум не читаю разработчики Менуэт....
Во всяком случае давно их не видел :)))
> У такой ОС (если ее можно так назвать) вообще >будущего нет.
Я понял ваш постинг. Вы имеете ввиду, что следует создать ОС на новых принципах и тогда поехали...
:_)))
> Остальные странички по этой тематике находятся >либо только на начальной садии, либо уже не >обновлялись очень долго (хотя по сути находятся >тоже только на начальной стадии).
>Если кто-то считает себя очень умным в данном >вопросе, поделитесь своими идеями, приведите >стоящие ссылки и т.п.
Это значит примерно следующее:
"Вы поделитесь своими идеями..., а ..."
А вас Билли не зовут, случайно :)))
>Лично у меня идей по архитектуре не так уж >много.
Интересно в чём их консистенция?
>Все мои идеи касаются только микроядерных >систем.
Гм.... а что значить просто ядерная система ? :)
>Главные постулаты моих идей :) :
>1. Ядро должно быть абстрогировано от всей >аппаратной части компьютера, кроме конечно >самого процессора и памяти :)
Нууууу, по моему вас точно зовут Билли...
Признавайтесь... неужели выучили русский :)))
>2. Всем процессам обязательно предоставляется >полная плоская модель памяти в 4ГБ.
Как вы это хотите реализовать???
>3. Должны быть все необходимые механизмы >взаимодействия процессов с системой и между >собой.
>4. Система обязательно должна предусматривать >механизмы распределения ресурсов между >процессами.
>Мне бы хотелось увидеть ваши взгляды на то, как >можно было бы реализовать вышеуказанные пункты.
>Самая главная ошибка, которую я встречал почти >везде - попытка написания ОС без детального >проектирования ее структуры (поэтому часто и >встречается один загрузчик - его написали а что >дальше делать неизвестно, вот все странички и >находятся на начальной стадии). Нужно сначала >понять что ты хочешь сделать, как, разработать >алгоритмы, а уж потом кодить. Конечно, многие >предпочитают пропускать разработку алгоритмов, >скажем, на бумаге. Я тоже так делал в институте -> сначала напишу прогу, а потом рисую по ней блок->схему для отчета. Это, ваше право, но что и как >должно быть придумано заранее, а не потом - по >ходу.
Вопрос: "А разве возможно что-то сделать, если не знаешь что???"
>Поэтому я и хочу услышать ваши предложения.
>Самое главное, как можно меньше стараться >изобретать велосипед. Например, не нужно писать >свой загрузчих - их и так море. Но только не >говорите, что разработка ОС - это тоже >велосипед, я это и сам знаю :)
Это как посмотреть...
>Также интересный вопрос по поводу >инструментальных средств. Самая главная >проблема - это то, что все они заточены под >какую-нить ОС. Отсюда встает проблема написания >программ для нашей ОС, и самое главное - их >отладки. Интересно, что вы думаете по этому >поводу?
По моему тебе стоит связатся с одним человеком..
Адреса так я не вспомню...., но напиши мне: [email]EdmondXASM@mail.ru[/email]
Originally posted by Mystic
аппаратной части компьютера, кроме конечно самого процессора и памяти
>Мое мнение --- должно быть микроядро, >привязанное к конкретной программно--аппаратной >реализации, а остальное на языках высокого
>уровня.
Проблемма в том, что именно вы понимаете под ядром, а что понимают собеседники...
Я не говорю что Ваше мнение ошибочно, это просто проблема терминологий....
И всё таки... то ядро -- которое представляет собой совокупность сервисов обеспечивающих работоспособность системы -- обязаны быть аппаратно независимой... (понятно что не от процессора :))
>> 2. Всем процессам обязательно предоставляется >>полная плоская модель памяти в 4ГБ.
>Твой выбор. В принципе это не обязательно. 4 >Гб --- тоже ограничение.
> Для чего-то же >вводились функции поддержки AWE >в W2k? Но >плоская модель проще.
Момент.. причём тут AWE?
Она что позваляет обратиться к всей виртуальной памяти?
:)
Этот механизм вообще создан для иных целей...
>Попытаюсь пофантазировать:
>~~~~~~~~~~~~~~~~~~~~~~~~~~
>Требования к OS:
> Windows compatible. Не 100%, но хоть сколько->то. Можно предоставить свой ООП интерфейс, а >Windows API реализовать как надстройку над ним.
Ага и использовать библиотеки майкросовт :)))
У меня уже была такая мысль..... можно сказать мечта...
Впрочем посмотрите на QNX.... :)
[+] Добавлю... или Юникс...
> Сразу отпадет проблема написания софта под OS. >Те же 4 Гб плоской модели. По похожему пути >пошла фирма On time, написав RTOS-32 для системм >реального времени и встраиваемых приложений. >RTOS-32 предоставляет достаточные средства для >поддержки кода загрузки многих компиляторов. >Полученный EXE-файл может быть преобразован в >двоичный и прошит в ПЗУ.
>Средство разработки:
> Windows компиляторы. Писать все на ASM-е >утомительно.
Мне, например, нравиться Delphi.
Только я б его немного переработал :) (полностью...)
аппаратной части компьютера, кроме конечно самого процессора и памяти
>Мое мнение --- должно быть микроядро, >привязанное к конкретной программно--аппаратной >реализации, а остальное на языках высокого
>уровня.
Проблемма в том, что именно вы понимаете под ядром, а что понимают собеседники...
Я не говорю что Ваше мнение ошибочно, это просто проблема терминологий....
И всё таки... то ядро -- которое представляет собой совокупность сервисов обеспечивающих работоспособность системы -- обязаны быть аппаратно независимой... (понятно что не от процессора :))
>> 2. Всем процессам обязательно предоставляется >>полная плоская модель памяти в 4ГБ.
>Твой выбор. В принципе это не обязательно. 4 >Гб --- тоже ограничение.
> Для чего-то же >вводились функции поддержки AWE >в W2k? Но >плоская модель проще.
Момент.. причём тут AWE?
Она что позваляет обратиться к всей виртуальной памяти?
:)
Этот механизм вообще создан для иных целей...
>Попытаюсь пофантазировать:
>~~~~~~~~~~~~~~~~~~~~~~~~~~
>Требования к OS:
> Windows compatible. Не 100%, но хоть сколько->то. Можно предоставить свой ООП интерфейс, а >Windows API реализовать как надстройку над ним.
Ага и использовать библиотеки майкросовт :)))
У меня уже была такая мысль..... можно сказать мечта...
Впрочем посмотрите на QNX.... :)
[+] Добавлю... или Юникс...
> Сразу отпадет проблема написания софта под OS. >Те же 4 Гб плоской модели. По похожему пути >пошла фирма On time, написав RTOS-32 для системм >реального времени и встраиваемых приложений. >RTOS-32 предоставляет достаточные средства для >поддержки кода загрузки многих компиляторов. >Полученный EXE-файл может быть преобразован в >двоичный и прошит в ПЗУ.
>Средство разработки:
> Windows компиляторы. Писать все на ASM-е >утомительно.
Мне, например, нравиться Delphi.
Только я б его немного переработал :) (полностью...)
Цитата:
Originally posted by Edmond
Может приведёте пример? Где полазили и какие ненужности...?
Может приведёте пример? Где полазили и какие ненужности...?
я уж не помню :), полно их...
Цитата:
Originally posted by Edmond
По моему тебе стоит связатся с одним человеком..
Адреса так я не вспомню...., но напиши мне: [email]EdmondXASM@mail.ru[/email]
По моему тебе стоит связатся с одним человеком..
Адреса так я не вспомню...., но напиши мне: [email]EdmondXASM@mail.ru[/email]
Спасибо, но не надо, я что-то поостыл, да и некогда сейчас.
Цитата:
Originally posted by RelB
я уж не помню :), полно их...
Спасибо, но не надо, я что-то поостыл, да и некогда сейчас.
я уж не помню :), полно их...
Спасибо, но не надо, я что-то поостыл, да и некогда сейчас.
А всем неогда....
У всех завал....
Это я серьёзно.
Но если желаете... жду...
Цитата:
Проблемма в том, что именно вы понимаете под ядром, а что понимают собеседники...
Я не говорю что Ваше мнение ошибочно, это просто проблема терминологий....
Я не говорю что Ваше мнение ошибочно, это просто проблема терминологий....
Хорошо, HAL (Hardware Abstraction Layer).
Цитата:
>>> 2. Всем процессам обязательно предоставляется
>>>полная плоская модель памяти в 4ГБ.
>>Твой выбор. В принципе это не обязательно. 4 >>Гб --- тоже ограничение.
>> Для чего-то же вводились функции поддержки
>> AWE в W2k? Но плоская модель проще.
>Момент.. причём тут AWE?
>Она что позваляет обратиться к всей виртуальной
>памяти?
>>>полная плоская модель памяти в 4ГБ.
>>Твой выбор. В принципе это не обязательно. 4 >>Гб --- тоже ограничение.
>> Для чего-то же вводились функции поддержки
>> AWE в W2k? Но плоская модель проще.
>Момент.. причём тут AWE?
>Она что позваляет обратиться к всей виртуальной
>памяти?
Она позволяет проецировать физическую память на виртуальное адресное пространство, а также производить выделение физической памяти. Количество выделенной физической памяти может превышать 4 Гб. Выделенная физическая память не сбрасыватся в файл подкачки. Процессом проецирования на виртуальную память управляет только приолжение.
Одна из причин для чего были введены эти функции ---чтобы предоставить приложениям оперировать с памятью, превышающей 4 Гб. Например, поставить на машину более 4 Гб технически возможно, но если 99% из нее должны использоваться одним процессом (БД, научные расчеты и т. д.), то никакого выигрыша это не даст.
Цитата:
>Ага и использовать библиотеки майкросовт :)))
Предпочитаю Inprise. Почти все в исходниках + хороший менеджер памяти, который можно спортировать. Кроме того, переписывать библиотеки --- занятие не из благодарных.
Цитата:
>Впрочем посмотрите на QNX.... :)
>Добавлю... или Юникс...
>Добавлю... или Юникс...
Это что ближе по душе. ИМХО надо брать что-то за основу. Если придумать свой формат выполняемого файла, то ПО на него в лучшем случае появиться через пять лет. А на 99% так вообще никогда.
Цитата:
>>Средство разработки:
>>Windows компиляторы. Писать все на ASM-е >>утомительно.
>>Мне, например, нравиться Delphi.
>Только я б его немного переработал :)
>(полностью...)
>>Windows компиляторы. Писать все на ASM-е >>утомительно.
>>Мне, например, нравиться Delphi.
>Только я б его немного переработал :)
>(полностью...)
План работ могли бы накидать?
>Это что ближе по душе. ИМХО надо брать что-то за >основу. Если придумать свой формат выполняемого >файла, то ПО на него в лучшем случае появиться >через пять лет. А на 99% так вообще никогда.
Ну, допустим, можно написать прогу, которая переделывает какой-нибудь формат(лучше PE) а в свой формат. Тогда можно спокойно пользоваться Windows-компиляторами.
Ну, допустим, можно написать прогу, которая переделывает какой-нибудь формат(лучше PE) а в свой формат. Тогда можно спокойно пользоваться Windows-компиляторами.