Открытая операционная система с нуля.

Phantom-84 Очевидно прочли невнимательно. Где мной приведено о проблемах описателей с распределением памяти. Вообще-то описатели и решают проблему распределения логических устройств в памяти. На счет символьных и блочных устройств, ознакомьтесь с работой dma и портов. Про Java – прочитайте внимательнее мой и предыдущий топики. Вообще интересно про ring3 для большинства сервисов и прикладных программ. Отсюда вопрос – что по вашему представляет из себя ядро?
Ладно, задам вопрос: Чем отличается вызов Zw функций от вызова Nt функций. Если , ответите , пойду вскрывать систему дальше, что-то основное там мной упущено.
Можно вопрос , вы в своей практике программирования глубже прикладного api были? У вас представления о системе только те , которые она дает прикладному уровню , извините. Но все равно интересно узнать про загрузчик на fat32.
Pavia Скорее всего мелкомягкие задвинули дрова в кольцо ядра по причине использования изначально для перехода на следующий ring механизм шлюзов, оные суть – вектора. (intel сообщает о дополнительном механизме – ищу о нем информацию), а теперь представьте , пишите в файл и нажали кнопку , или пришло что по сети – потеряли.

JhuSS, твоя оценка моей компетентности в обсуждаемой нами теме меня сильно повеселила. В связи с этим спешу тебя обрадовать, я не знаком с теми видами вызовов функций, о которых ты упоминаешь, правда, это может быть связано с тем, что мы используем разную терминологию :) К твом обширным выкладкам я действительно сильно не приглядывался, но про Java там написано вполне конкретно, а до пояснений (или оправданий :) я видимо не дошел. Кстати, на то есть своя причина: по твоему научению решил перечеркнуть мечту о реально работающей системе, которую знаю изнутри, и продолжать изучать api уже существующих систем, но в Windows так много функций, а моя память справляется только с одной - TerminateProcess - это итог нашего диалога. Я был настроен на конструктивный диалог, а обмениваться взаимными оскорблениями я могу и со своей подругой :)

Кстати, использование шлюзов, которые предлагает Intel в своих х86-х, - это лучший способ смены уровня привилегий для данной архитектуры. А если их еще и поместить в дескрипторную таблицу прерываний (вспомним Linux), то получится самый компактный способ обращения к системным функциям, который хорош еще и тем, что при его использовании происходит автоматический запрет прерываний, что часто бывает весьма полезным.

JhuSS, по поводу загрузчика для fat32... Могу предоставить его со всеми комментариями, но только за несимволическую плату или, если ты мне перешлешь скан-копию сертификата Майкрософт о том, что помещая этот загрузчик в загрузочный сектор раздела с установленной в нем Windows-системой, ты отдаешь отчет в том, что ты делаешь :) В противном случае, как это обычно бывает, могу лишь предоставить самый простой дискетный загрузчик для fat12, но зато абсолютно бесплатно :)

JhuSS, да, забыл сказать, в этом загрузчике я api практически не использовал, места было маловато :)

Phantom-84 Все-таки поглядите на топик от captain cobalt и проследите за моими ответами на каждое его высказывание , очень прошу вас. Я их приводил после “/” по каждому высказыванию. Это про внимательность и как раз на тему нововведений и плагиата..
Теперь про знание системы.
1. Шлюзы – один из возможных способов обращения к странице памяти с более высоким приоритетом, но отнюдь не единственный и отнюдь не самый лучший (по крайне мере по скорости отработки).
2. Как я понял у вас шлюзы могут находится где-то еще кроме idt, так спешу вас обрадовать , шлюз – это вектор синхронно задаваемого прерывания (ядро nt в основном на 2Eh) и нигде кроме находится не может. Это уже железная архитектура процессора.
3. Теперь дам вам базовые понятия ядра ОС (очень упрощенно). Представьте, где-то в оперативной памяти по разным адресам находятся массивы кода и данных. Далее где-то находятся таблицы из структур , элементы которых описывают параметры этих массивов (объектов), положение структуры объекта в сей таблице – описатель объекта. Далее где-то находится библиотека функций для работы с этими объектами через элементы структур данной таблицы (сервис – вы его хотели , если я правильно понял , разместить вместе с прикладными программами). В совокупности сервис и таблица называются диспетчером данных объектов. Доступ к функциям сих сервисов осуществляется двояко: из r3 – через функции динамических библиотек перехода (для nt – ntdll.dll) через описатели ZwXXX – функций, из r0 – через точки входа по описателям NtXXX-функций. Это , блин , АЗЫ. Вы ничего работающего в r0 не писали. (кстати, графический интерфейс работает другим путем). Все остальные dll прикладного уровня – лишь удобный api интерфейс.
4. fat – таблица доступа к файлам. Вторичный загрузчик может видеть только порты контроллера жесткого диска и его dma. Файлы он может различать только находящиеся в корне диска.(например ini , где указано “железное” размещение файлов системы) , а api вы не могли использовать просто потому что ее еще НЕТ!(смысл загрузчика с уже висящим в памяти api ?)
p.s. Желаю вам успехов в освоении api, а так-же написании системы , которая будет грузится и под винды.

Дискуссия улет, учень долго угарал:
1. Загрузчик юзающий апи
2. Вторичный загрузчик работающий с аппаратурой через порты и видящий только корневой каталог
3. 4 кольца защиты, которые никому нахрен не нужны и на которые все забили

PS: Что ж, истина совсем близко - еще чуть чуть, еще немного...............

>что при его использовании происходит автоматический запрет прерываний, что часто бывает весьма полезным.
Улыбнуло =)

Ramon, привет дружище, в этот форум я попал только благодаря одному из твоих сообщений, правда, по другой теме. Не поленись прочитать мое первое послание, так вот на самом деле оно начиналось со слов: "Самое стоящее, что я здесь прочитал, это сообщение Ramona..." У большинства местной публики явные проблемы с чувством юмора :)

JhuSS, на будущее... все сообщения, которые я заканчиваю смайликом, я пишу с улыбкой на лице и к ним нужно относиться серьезно только наполовину. С тобой отныне постараюсь держаться посерьезнее :) По поводу сервисов: тогда я имел в виду прикладные программы, работающие в фоновом режиме. По поводу шлюзов: не знаю о какой архитектуре вы нам рассказываете, но я имел в виду Intel-архитектуру 32-разрядных х-86-ых процессоров, в которой шлюз может находиться и в LDT, и в GDT, ну и в IDT. Теперь по поводу местоположения шлюза для обращения к системным функциям со стороны приложений: как известно, в Linux он находится в IDT в позиции 80h, у меня же в IDT в позиции 60h, что в принципе неважно, если конечно не пытаться его поместить, например, в позицию 08h :)

JhuSS, как бы мы не конфликтовали, но ты все-таки мой самый любимый собеседник в этом форуме... Твой третий пункт, а для меня это настоящий постулат, открывший глаза на истинную природу вещей, поразил своей нравоучительностью. Все, что там сказано, сказано по существу и с ноткой значительности в голосе :) Но даже это превзошел твой четвертый пункт. Робко хочу вам возразить, мой учитель... А как же сервис BIOS, который обычно используют загрузчики (кстати, исключительно ради уточнения терминологии: у вас вторичный загрузчик - это загрузчик, находящийся в загрузочном секторе раздела ж/диска или код, загруженный из файла?). Вы гений, раз можете разместить код работы с портами (в том числе и DMA) в одном физическом секторе или в нескольких таких секторах, которые "украдены" загрузчиком за счет размещения первого раздела начиная со след. поверхности диска или за счет того, что ФС имеет дисковые блоки, состоящие из нескольких физических секторов. Кстати, если в вашем распоряжении такой "необъятный" простор в виде нескольких лишних секторов, то загрузчик можно сделать и поинтеллектуальнее, чтобы он мог читатать не только содержимое корневого каталога, правда, это никому не нужно быть может кроме некоторых Unix-систем :)

JhuSS, я действительно невнимателен, раз начал разбор твоих эпохальных пунктов с третьего номера :) Вы там говорите о страницах памяти, как будто страничный механизм работает поверх сегментного, а не наоборот (но это я придираюсь). Размещение шлюза в IDT обеспечит нам действительно не самый быстрый способ системного вызова, но зато какой элегантный! У меня плечи передергивает, когда я вижу Unix-овское обращение к системным функциям (опять-таки через шлюз, вентель и под.) с помощью инструкции "lcall $7, $0". Так и хочется вместо нулевого смещения в этой инструкции вписать строчку "COOL", жаль только что кавычки не поместятся, потому что именно Cool "в кавычках" я и имел в виду :)

Ramon Phantom-84 Обычно вторичный загрузчик сидит на всей 0-дорожке загрузочного диска, а порты получает по опросу первичного после теста системы. Можно воткнуть туда все , но курсач делал по дубовику снятого загрузчика pdp-11 (предтеча nix-ов). + опыт работы с boot – заразой. По поводу портов – а как можно еще работать с устройством , пока никакие его дрова не сидят ? Просветите , ПЛИЗ.
А кольца защиты MS применяют все в случаях повышения критичности системы, когда дрова должны иметь приоритет выше ядра.
Phantom-84 LDT и GDT таблицы размещения страниц памяти оного диспетчера. Сделать (собрать) ее ты можешь где угодно , но чтобы она заработала , ее нужно загрузить в кэш проца (lgdt , lldt) – также как и IDT (lidt) , и делается это только со страниц памяти r0. Шлюзы – железно те же прерывания, и могут быть только IDT. (это то , что в msdos называется таблицей векторов , и основной шлюз системы на векторе 21h. Int 21h – помните?) Так можно разрешить доступ к dma устройства для приложений , достаточно слепить свою ldt , где отображение сей страницы памяти ниже 80000000h , что по GDT автоматом ей ставит r3. И будешь работать с устройством напрямую из приложения в контексте данной задачи (это уже диспетчер задач и его TSS)
Страничный механизм работает глубже сегментного, ничего не мешает загрузить в сегментный регистр , допустим не 10h а 14h, дабы задавал сей сегмент совершенно другой набор страниц памяти, описанный в последней загруженной LDT (для данной задачи) со смещением 14h. А говорил упрощенно , не вникая в работу диспетчера памяти.
А по поводу последнего – разберитесь , чем отличается ret от iret , и по работе стека в int и call . Сразу разберетесь как можно использовать сии сервисы обходя шлюз, т.е. использование их из r0 и r3 . И сразу будет понятно и почему дрова поместили в r0 и чем Zw – вызов отличается от Nt - вызова.

Обращаюсь ко всем!
Я, конечно, понимаю благодаря своему университетскому образованию, что именно в споре рождается истина, но что-то никак не могу понять, зачем во время спора опускать друг друга ниже уровня рядового пользователя :) Чтобы ты, JhuSS, да и другие тоже особо в дальнейшем не изощрялись в том, к какой именно категории ламеров меня причислить, я сам расскажу о себе всю правду. Я параноик. У меня синдромы Наполеона и Пуаро вместе взятые. После того, как я «подсел» на ассемблер, я не могу вернуться ни к одному из высокоуровневых языков программирования. Я два года писал графическую библиотеку под Windows только ради того, чтобы в своих приложениях не видеть даже стандартных оконных фреймов Windows, не говоря уже об элементах управления. Я до сих пор не освоил инструкции для работы с вещественными числами, а также MMX- и тому подобные расширения. И это так сказать еще самые слабые из моих недостатков. Но я хочу сказать вам, или мы говорим по делу, или я умываю руки. Если вы выбираете первое, то я хочу знать, кто готов принять активное участие в обсуждении, т.е. говорить по существу, а кто лишь снабжать нашу беседу пусть и не лишенными юмора, но совершенно пустыми сообщениями. Отныне предлагаю действовать по следующей схеме: ставим вопрос – обсуждаем его – приходим к какому-то общему мнению по данному вопросу или переносим его обсуждение на потом и переходим к рассмотрению нового вопроса. Я все сказал. Жду ваших ответов!

JhuSS, как не странно, но я действительно еще помню про "int 21h", а также про все остальные "int", относящиеся к DOS. Кроме того, не особо желая блистать перед тобой своей эрудицией, я также помню, что такое UMB, HMA, XMS, EMS, PSP, FCB, DTA, EPB и в чем разница между сигнатурами 4Dh и 5Ah в MCB. Вот только одного я не помню, а именно, чтобы в DOS присутствовало понятие шлюза... То была счастливая пора, когда существовали обычные векторы 16+16, а приложения по качеству и объему кода нередко превосходили саму систему :)

Уважаемый Phantom-84. Очень рад найти кого-то , кто не считает асм чем-то страшным и принципиально не нужным. Всего лишь чего я хочу, это поделится с вами тем что знаю и думаю , исходя из ваших топиков , что этих знаний не хватает вам. И если задавал вам вопросы , то только потому что в ответах на них может быть какое либо ключевое понимание работы всей системы. Извините , если чем вас обидел. Заканчивал я отделение ВКСиС кафедры ВТ. Изучали архитектуру вычислительных машин как цифровых автоматов с программной логикой управления, понятие шлюза там присутствовало всегда. Далее микропрограммный код управления алу и регистрами процессора (или без оного) , и только потом машинный код и его мнемоническое представление в языке ассемблера. Аналогично сопроцессор и все остальные контроллеры машины. Примерно так я и познакомился с ассмом. Единственное .чего я никогда не буду изучать , так это сленги. Кстати , кто такие ламмеры ?
Как понято , цель - писать свою ось. Но нельзя прыгать ниначто не опираясь. Пока попробую заложить основные понятия:
Все про однопроцессорную систему.
Сии диспетчера в своей работе опираются на железную архитектуру процессора. Их точно никак не объедешь.
Диспетчер памяти – создание глобального непрерывного страничного адресного пространства , размещение страниц в физической памяти , наделение страниц уровнями доступа. (gdt)
Диспетчер задач - механизм переключения задач (tss) , выделение каждой задаче своего адресного пространства (ldt) (через сервисы диспетчера памяти), причем адреса страниц системы для всех дескрипторов совпадают и имеют r0 , также как и адреса dll api с r3, но адреса загруженного приложения , его данных и выделяемых ему локальных блоков памяти – разные. Это карты памяти процессов. Процессор выполняет задачу определенный квант времени, далее переключается на следующую (переключается на другой tss).
В основном концепция nt – независимость системы от оборудования, роль сей подушки выполняют дрова шинных интерфейсов системы , мостов , рейд контроллеров и контроллеров прерываний, в общем всех внутримамкиных контроллеров. Система имеет стандартные дрова на все случаи жизни. Контроллеры устройств должны знать стандартный интерфейс шин , на которых сидят. Все в куче это называется hal. Даже родные дрова устройства не работают с ним напрямую, а через hal - дровину , отвечающую за шину на которой сие устройство сидит.
….
Если вас сие заинтересовало , то продолжение следует . Если на ваш взгляд сие сообщение пустое , то можете и дальше создавать свои классы окон в gdi среде винды (win32k вы не переписывали ).

JhuSS, я считаю, что обсуждение следует начать не с "железа", а с общей концепции системы, поэтому первое, о чем я предлагаю поговорить, так это о назначении и основных свойствах будущей системы (многозадачная, защищенная и т.п.).

Phantom-84 Если приглядеться, то можно рассмотреть что описывалось 1.защищенность , 2. многозадачность , 3.абстрагирование от железа. Тогда далее , дабы не нудеть вам о структуре и работе последних реальных систем. Здесь уже от железа почти ничего не зависит , потому полный полет фантазии. Опишите , что система должна обеспечивать работающим в ней приложениям, далее блок схему и графы состояния системы для реализации сих требований. Далее поблочная более детальная проработка модулей и методы и протоколы обмена информацией между ними. Размещение сего на карте памяти и процесс ее загрузки.
Можно ознакомиться , на каком этапе вы сейчас находитесь, или можете привести полный список требований к системе ?

JhuSS, я предупреждаю тебя в последний раз относительно "нудеть" и тому подобных высказываний! Если ты и впредь будешь позволять себе подобные выходки, то ты рискуешь потерять последнего из твоих собеседников, т.е. меня. Ну а теперь попробую объяснить тебе, что система никогда не создается исключительно ради системы, даже если потом ее авторы и пытаются убедить в этом всех окружающих. Поэтому прежде всего необходимо ответить на один единственный вопрос: "Зачем?" После этого можно уже переходить к перечислению всех базовых свойств системы, причем наличие некоторых из них будет напрямую зависеть от ответа на предыдущий вопрос. Теперь отвечу на твой последний вопрос: я обязательно выскажу свое мнение о требованиях, предъявляемых к системе, но как ты уже наверно понял немного позже. Далее по поводу того, на каком этапе я нахожусь: в настоящее время я не занимаюсь подобными работами вообще, но у меня есть опыт в проектировании ОС, именно поэтому я и участвую в данном форуме. Если я увижу, что есть основание вернуться к дальнейшей разработке своей системы, я это сделаю. Если я увижу, что есть основание принять участие в разработке новой системы, я это сделаю. Правда, судя по всему, подобные основания могут появиться еще очень не скоро. Возвращаюсь к вопросу о назначении системы: понятно, что миллионы благодарных пользователей, это явно не наш контингент, поэтому можно создать систему исключительно ради ее открытости, чтобы все желающие могли с ней ознакомиться. Можно найти и практическое применение. Например, известно, что вузы нашей страны постоянно сталкиваются с проблемой выбора рабочей операционной системы для обучения студентов основам программирования, что связано с широким распространением в России операционных систем с высокоразвитым пользовательским интерфейсом. Нередко приходится видеть, когда в качестве рабочей ОС используется Windows, но студенты создают программы средствами DOS и для DOS, а потом запускают их на выполнение в консольном режиме, когда следовало бы сразу писать 32-разрядные консольные приложения. Если же здесь проблемы не возникает, то она возникает при разделении данных отдельных людей на компьютерах общего пользования, потому как далеко не везде стоят системы линии Windows NT. Еще одно применение – это зондирование других систем с целью устранения неполадок или просто "для души" :)

Phantom-84 Ну ладно , рискну. Термин “приложение”(aplication) на данном этапе эволюции ПО применяется к пользовательским программам. Про сервисы уже говорил. Драйвер – кусок программного кода , оный создает в системе объекты – устройства (device). Устройства , которые дрова , умеют ловить прерывания и обмениваться данными с железом через дрова hal , а также ставить сообщения (irp пакеты) в очередь вышестоящим устройствам (устройствам протоколов , FS , слежения и защиты) или еще выше – сервису своего диспетчера , оный имеет связь с приложениями через dll api , или шлет его навскидку (msg) – как правило активной в текущий момент задаче. Само приложение может взять описатель любого устройства (OpenFile) и кинуть ему в очередь любой irp пакет (DeviceIOcontrol) , юзая advapi. А вообще на эту тему очень просвещает утелитка от ddk - Device Tree. Устройства протоколов , слежения и защиты в системе называются службами. Отключить службу – вынуть ее из дерева распространения пакетов. Удалить службу – вышить устройство из памяти. Про то какие устройства (дрова) и службы запустить при загрузке – знает (еще много чего попутно знает) база данных , именуемая – реестр.
Простой двойной щелчок на ярлыке (ссылке , указатели пути) – запуск приложения , приводит к тому , что создается новая задача (через диспетчер задач) , под которую создается процесс (через диспетчер памяти) , который может создать фоновые задачи (нити) (опять через api на диспетчер задач) в рамках самого себя, причем все это в рамках сеанса текущего (или сетевого) пользователя.
Возможность работы с тем или иным ресурсом приложению определяется – видно или нет его процессу страницы памяти оного ресурса (там могут прятаться отладчики и boot зараза) и совпадают или ниже ring страниц с ресурсом по отношению к страницам с приложением для прямого обращения. Т.е. приложения r3 с локальными картами процессов на ldt не то что помешать друг другу , даже если очень захотят они увидеть дру друга не смогут. Диспетчер задач имеет “шапочку” – taskmanager. Загруз “сервисов” пользователя (если это про динамические библиотек dll) это уже через диспетчер памяти на gdt (глобально) , она уже доступна всем приложениям (отображается в карте памяти всех процессов).
Ну сие про системные потроха , теперь про интерфейс пользователя.
Здесь хозяин – сервис win32k. Все окошки – это его объекты. Дрова карты работают с ним вне hal (для скорости). Библиотеки gdi работают с ним почти исключительно на irp, шлюз для него слишком медленный. Вид окошка и его свойства задаются регистрацией класса сего окошка (есть куча стандартных dib структур для задания их внешнего вида , но легко можно создать и зарегистрировать для использования свои ). Когда сие окошко открываешь, для него создается его контекст (dc) – тот кусок видео памяти (region) оный будет отображать его клиентскую область на мониторе. Можно применить к сему контексту различные свойства (по классу окна) но реально оно имеет dib структуру bmp32 не сжатого файла. Свойства класса окна (например edit, buttom) – это функции прослойки сервисов , через которые ты работаешь с оной dib структурой (консоль win – тоже самое) . Если регионы окон пересекаются , то требуется создавать кусок памяти , наделять его структурой dc (mdc) и по нему восстанавливать содержимое dc. По активизации окна ему шел paint с указанием региона отсечки, оный требовал восстановления. Все кнопки, надписи , ползунки и прочее - все его дочерни окошки , которым предок пошлет paint уже само (вернее сервис) всем по порядку старшинства и положения. Отслеживает положение на рабочем столе сервис сам, может изменить и перерисовать уже все больше сам , но по старой привычке шлет в приложение все соответствующие изменениям сообщения.
Не рекламирую ms , просто сообщаю что знаю. Есть отладочные версии сих ос (checked build - версии) , где сохранена вся отладочная информация при компиляции системы. Они тяжелые и неповоротливые . но помогают разбираться что там к чему. Есть туева хуча сборок сих систем для кучи выч.комплексов различного назначения, народ знаком в основном с коммерческими однопроцессорными персоналками и возмущен на тему – почему не работает то или не используется это. Хочу напомнить , что dos – это тоже ms. Nix-ми уже 5 лет не занимаюсь , посему отстал от жизни в них.
Теперь сообщу на чем сие держится – на четких и однозначно направленных протоколах обмена информацией между компонентами системы. Эти стандарты необходимо выработать и придерживаться их всегда. Компонент будет обрабатывать и перерабатывать информацию так как будет угодно его создателю, но принять и отдать он должен ее в понятном для всех виде. И пляшут сии протоколы , для скорости работы , от железа. Это при разработке операционной среды – задача № 1.

JhuSS, не спорю, что при разработке системы нам в основном придется заниматься "железом", но то, что я говорил, тоже имеет определенный смысл. Мне хотелось таким способом подвести нашу беседу к перечислению основных характеристик системы. То, что она должна быть защищенной и многозадачной, обсуждать мы даже не будем. Кстати по поводу многозадачности: ты упомянул нити (потоки), действующие в рамках одного процесса. Должны ли они присутствовать в нашей системе или нет? Я также говорил о защите данных отдельных пользователей. Как обеспечить подобную защиту? На мой взгляд создавать сетевую ОС в обычном понимании этого слова не следует. Поддержка доступа через терминалы в настоящее время уже неактуальна, т.к. рабочие места всегда оснащаются полноценными ПК. А распределенное выполнение приложений (на практике используется редко), доступ к разделяемым ресурсам можно обеспечить и по-другому. Мне кажется, что лучшим вариантом обеспечения разделения данных было бы включение в систему механизма профилирования, но не на верхнем уровне, как мы обычно это наблюдаем в некоторых системах, а значительно глубже. Говоря об ОС с высокоразвитым пользовательским интерфейсом, я имел в виду следующее: при реализации учебных алгоритмов проще всего использовать простейший ввод-вывод, чтобы разработчики этих алгоритмов сосредоточили все свое внимание на самой решаемой задаче, а не на ее красочной оболочке. Использование дополнительных библиотек, в код которых "заворачивалось" бы решение задачи, тоже нежелательно, потому что это сильно дезориентирует начинающих программистов – писал мало и самую суть, а получилось много и с картинками :) По-моему, графический интерфейс следует вывести из кода системы, заранее подумав, как он сможет существовать отдельно от нее в многозадачной среде. Хотелось бы услышать твое мнение по этому и другим вопросам, которые я здесь затронул.

Phantom-84 На счет нитей. Это очень удобный механизм для того , что бы создать фоновую задачу и забыть о ней. Так скажем, локальные службы приложения. Например тот-же word юзает сие при поиске ошибок орфографии. И вообще очень полезная вещь для мультимедии и сети.
ОС должна быть сетевой уже в проекте. Это не только терминалы. Потом навязывать сетевые функции поверх целостной системы гораздо проблематичнее и делает ее более беззащитной. Сужу по своим машинам с 98 в домене. В самой доменной политике приходится делать “дыры” для работы сих машин в сети.
Профилирование по пользователям сделать глубже не имеет смысла , если производители железа не обеспечат сих функций на железном уровне. Занимается сим диспетчер сеансов (winlogon – его шапка). Он сидит глубже диспетчера подсистемы.
В/в по всем типам устройств на уровне системы однотипен – “поток”, OpenFile (любое устройство потокового в/в) и через полученный описатель ReadFile() WriteFile() что куда угодно.
Основная задача каждой ос (кроме всего прочего) – обеспечить стабильный и легкий интерфейс приложений с устройствами в/в. Все остальные функции по скорости разработки приложений – уже внутреннее дело среды разработки (визуализация). Дополнительные библиотеки – это наверно про классы. Все сие служит для отвязки приложений на уровне исходного кода от архитектуры машины. Смотря что эти разработчики будут разрабатывать. Математические и физические законы меняются гораздо реже , чем архитектура машин. Эта зависимость только от среды разработки ПО.
Графический интерфейс win32k и так отдельным модулем, существует отдельно в многозадачной среде. Хочешь выводить пиксели на экране (рабочем столе), открой окно класса Null, его dc – регион рабочего стола.

JhuSS, я полагаю, что вопрос о поддержке нитей можно считать решенным. А вот про ОС, которая должна быть сетевой только ради защищенности, могу поспорить. Правда, это может быть опять связано с расхождением в терминологии (вспомним вторичный загрузчик, представление о котором у меня явно не согласуется с твоим: с моем точки зрения это первичный загрузчик). В моем понимании основной характеристикой сетевой ОС является возможность одновременной работы сразу нескольких пользователей. Естественно в такой ситуации для стабильной совместной работы данные одного пользователя должны быть полностью защищены от воздействия со стороны других пользователей. Но нужно ли нам поддерживать возможность такой работы в системе, которая в принципе ориентирована на использование в ПК? Отрицательный ответ вовсе не ограничивает способность компьютера, работающего под управлением подобной системы, эффективно взаимодействовать с другими компьютерами сети. Кстати, я абсолютно с тобой согласен в том, что возможность сетевой работы нужно заложить в систему еще на этапе ее проектирования. Например, можно на уровне файловой подсистемы ОС ввести поддержку сетевого "корня" вида "//", который на один уровень выше локального "корня" вида "/", обозначаемого в этом случае еще и так: "//machine/" (machine – имя компьютера в сети). Затем связать сетевой «корень» с драйвером NFS и разработать простой и надежный механизм защиты доступа к локальным данным извне. Профилирование же нам поможет разделить данные, находящиеся на одном компьютере, между отдельными его пользователями. Кстати, говоря о профилировании, я имел в виду именно механизм поддержки нескольких профилей пользователей на одном совместно используемом ими компьютере. Основательно же интегрировать этот механизм в систему я хотел исключительно для того, чтобы повысить надежность разделения данных. У меня есть определенные наработки по этому вопросу. Обязательно про них расскажу, если мои идеи о профилировании окажутся все-таки востребованными в нашей системе. Но а вопрос о сетевой многопользовательской системе считаю пока еще открытым и хочу увидеть твои комментарии к тому, что я здесь написал по этому поводу. Теперь насчет графического интерфейса: в Windows он может быть и выведен из ядра системы в отдельные модули, но при этом все равно остается неотъемлемой ее частью. Ты хоть раз видел Windows с каким-нибудь оригинальным GUI? Я, например, никогда, хотя и слышал, что нашлись умельцы, перекроившие "обертку" этой системы от и до. Не хочу в очередной раз показаться тебе нудным ;), но мне опять приходит на ум подход, примененный в UNIX-системах, т.е. основанный на использовании оконных менеджеров совместно с различными графическими оболочками. Главный плюс этого подхода – появление очередного уровня модульности и как следствие – существование в системе различных графических оболочек, что для конечного пользователя, если конечно он нормальный, является немаловажным фактором свободы. Это же и главный минус – потенциальное понижение уровня совместимости отдельно взятого приложения с различными оболочками, в которых ему придется работать. Последнее, впрочем, легко решается путем ввода общих стандартов по программному интерфейсу и окружению. И пусть никого не пугает текстовый режим экрана, как один из вариантов работы системы. Самое "сладкое" здесь – это опять возможность выбора! Ну а кто выберет графический интерфейс, пусть сразу позаботится о том, чтобы получить в свое распоряжение установочный пакет ОС с любимой графической оболочкой, автоматически конфигурируемой в качестве основной оболочки еще на этапе установки системы. И в заключение... Я участвую в этом форуме еще и потому, чтобы немного отвлечься от своих "проблем насущных", а именно от программирования под Windows. В связи с этим прошу тебя не упоминать общеизвестные факты из данной области, если конечно ты не проводишь сравнительный анализ и не предлагаешь включить аналогичные структуры, методы, компоненты в новую систему.

Phantom-84 Позволю себе прокомментировать. Вы когда читали про организацию учетных записей сетевой машины, что то недопоняли (извините), и вот что именно. Диспетчер сеансов , ответственный за защиту приложений различных пользователей друг от друга более глубоко при всем желании разместить невозможно, он ниже уровня подсистемы. Например , подсистема Win32 обеспечивает создание родных процессов системы, а подсистема POSIX – юниксовых процессов. Она может выполнять приложения сразу нескольких вполне даже локальных пользователей. А имя локальных пользователей в системе \\имя_машины\имя_ползователя. Если сеть локальная , то доступ можно открыть другому пользователю другой машины \\имя_другой_машины\имя_другого пользователя. При доменной организации \\имя_домена\имя_пользователя. Войти в машину они могут только в одном случае – если они прописаны в машине (имеют свои ключи в реестре). Если в системе нет встроенных сетевых средств контроля за сетевыми пользователями (не сетевая ос), то проблему безопасности можно решить только полным отсутствием доступа через сеть. Оставь только себя как локального пользователя (остальных ликвидируй), и никто ни по сети , ни локально , в сию машину не войдет. Все что можно узнать про разграничение доступа к файлам на диске для различных пользователей – можно почерпнуть из описания ntfs, не самая удачная fs , но с этой функцией справляется (данные о сей fs общедоступны). Профилирование – это немного не то о чем вы думаете.
По поводу интерфейса пользователя системы – дело вкуса.
Извини , но все-таки приведу один общеизвестный факт. Как правило , при шлюзовом обращении к странице памяти вышестоящего кольца, происходит перегруз параметров в стек диспетчера из стека текущего в настоящий момент контекста задачи. Это главный тормоз. Как всем известно , страничный механизм процессора х86 позволяет осуществлять дублированную привязку страниц к одному участку физической памяти. Сие следует из корневого задания адреса страниц при их создании. Система при загрузке создает выделенную область r0 страниц, где по определенному описателю процесса , наделяющего ему диспетчером подсистемы (проблема в том , что железно tss это держать не может) , создается отображение страницы по вполне конкретному адресу процесса (так некоторые сервисы дают доступ к системной памяти приложениям в обход страничным переключениям). И именно в этой области организовать стек процесса. Дабы организовать сервис с подобной передачей параметров, пройдется осторожно , но бить gdt. Но в своей системе можно слепить сей протокол в ядре изначально. Можно , дабы не изобретать велосипед , узнать , может кто проектировал сие уже. Можете ненамного отвлечься от проблем насущных и помочь мне разобраться с сим общеизвестным , возможным системным протоколом.

JhuSS, я все прекрасно понял, просто я предлагаю выполнять приложения отдельно взятого пользователя сети на той машине, за которой он сейчас находится, и чтобы это выполнение поддерживала исключительно ОС, установленная на его собственной машине. Убирая возможность одновременного выполнения приложений разных пользователей на одной машине, мы можем существенно упростить механизм защиты данных от воздействия со стороны других компьютеров сети. Естественно при этом одновременно с выполнением приложений одного единственного пользователя на машине должна функционировать серверная часть NFS, чтобы обеспечивать доступ к локальным данным со стороны других пользователей сети. От надежности механизма защиты во время такого доступа и будет зависеть защищенность данных в целом. По поводу профилирования я ничего не думаю, просто я это так называю, хотя и допускаю, что это может быть не совсем правильно. Против того, что графический интерфейс следует отделить от системы, ты по-видимому не возражаешь. Кстати, я вообще считаю, что имя оболочки должно быть прописано в конфигурационном файле системы и следовательно оболочкой может быть любое приложение, вот только в полной мере его можно будет так назвать, если из него возможно запустить любое другое приложение. Эта оболочка может быть как графической, так и текстовой. Более того, она может даже иметь интерфейс командной строки. Но это из моей концепции построения ОС, если в дальнейшем у тебя появятся какие-либо возражения по этому поводу, ты мне сообщи. Далее насчет передачи параметров при системных вызовах: я по-прежнему предлагаю использовать не обычный шлюз вызова, а шлюз прерывания, расположенный в IDT. Естественно в этом случае исключается возможность перегрузки параметров из стека приложения в стек ядра, о которой ты говорил. И естественно я предлагаю альтернативный вариант – регистровую передачу параметров. Ну а если приложениям необходим более традиционный метод обращения к системному сервису, то каждую системную функцию можно обернуть в обычную по способу вызова подпрограмму и все эти "обертки" поместить в DLL. Хорошо, что ты затронул проблему совместного использования памяти приложением и ядром. Об этом нам предстоит еще много говорить. Не менее интересная проблема – это совместное использование памяти несколькими процессами, например, для реализации работы DLL или для обмена большими массивами данных между процессами.

Phantom-84 Все понятно , только опишите , ПЛИЗ, как работает “обычный” шлюз вызова, не использующий idt. И почему исключается возможность при idt перегрузка параметров из стека в стек. Никогда с подобным не сталкивался.

JhuSS, обычный шлюз вызова – это call gate в терминологии Intel, который может размещаться как в GDT, так и в LDT, но не в IDT. Шлюз прерывания (interrupt gate) наоборот может находиться только в IDT. У этого шлюза отсутствует аппаратная поддержка перегрузки параметров (не используется поле word count в дескрипторе), но это вовсе не означает, что нельзя реализовать программную перегрузку, правда я считаю, что этого не следует делать. Если тебе необходима более подробная информация, обратись к документации по процессорам Intel.

Phantom-84 Ну если точку входа назвать шлюзом… А что , можно использовать точки входа (обычные шлюзы) для вызова функций сервисов ядра? Судя по вашим предложениям , кто-то уже так делал.
Еще один общеизвестный факт. На шлюзе , который 2Eh , висит небольшой обработчик , оный перекачивает параметры из стека в стек , находящийся на странице ядра , по еах определяет номер функции ядра , ищет по таблице адрес (точку входа) сей функции и дальше обычный jmp. Синхронное прерывание с вектором 2Eh работает лишь как переключатель кольца защиты. Еще , по выходу она не чистит стек режима пользователя , посему после int 2Eh необходимо сие сделать самому.
Если сей обработчик организовать в отображаемых в режиме пользователя страницах, то дабы стороннему производителю написать свой системный сервис , ему пройдется очень аккуратно бить gdt системы , задавать адреса отображаемых страниц. У тебя никогда проблем с устройствами c dma не было , когда дрова обоих задают одни адреса страниц. Но теперь с дровами система разбирается (wdm). А теперь представь , сим будут страдать сами сервисы (суть , само ядро).
А так можно написать любой системный сервис и повесить его на любой свободный шлюз.
По поводу перезаписи стека. Для скорости работы приложения тот код , оный ушел в систему уже идет своим потоком (выход ядра из контекста приложения), а код приложения отпускается дальше , особенно если есть несколько нитей в процессе. А стек для процесса приложения один. Теперь представь – где нибудь попадается команда push. Перекачивая параметры , тебе освобождают стек.
Если видишь , что где-то сделано длинно и нудно , задавай вопрос – а почему так сделано.

JhuSS, в переводной литературе шлюзами или вентилями называют все дескрипторы, которые не предназначены для описания какого-либо участка памяти, а используются исключительно для косвенной передачи управления. Кстати, точками входа их тоже называют, просто я привык этим словосочетанием называть не весь дескриптор, а только ту его часть, которая задает непосредственно адрес, по которому передается управление. Про использование шлюзов в других системах я уже писал: большинство UNIX-систем, работающих на PC, для обращения к ядру системы используют самый первый дескриптор в LDT. Не думаю, что это дескриптор подчиненного кодового сегмента или кодового сегмента с все тем же низшим уровнем привилегий; скорее всего это шлюз. Про программную перегрузку параметров из одного стека в другой я уже высказал свое мнение – с моей точки зрения это усложнение системы там, где этого можно избежать. Кстати, а почему тебе не нравится мой вариант передачи параметров через регистры или ты просто хочешь рассмотреть все возможные варианты? У меня тоже номер системной функции является индексом в таблице, содержащей внутрисегментные точки входа для всех функций. А если, как ты говоришь, необходимо написать системный сервис "стороннему разработчику", то пусть он использует способ, аналогичный способу, применяемому системой. Кстати первоначально у меня обращение к функциям драйверов происходило через "int 61h", а для вызова системного сервиса использовалась инструкция "int 60h". Про предоставление памяти драйверам устройств, использующих DMA, могу сказать следующее: это все легко решается, если об этом подумать заранее. Ну какие проблемы там могут возникнуть – выделить непрерывный участок памяти; выделить участок памяти в начале физического адресного пространства; выделить участок памяти, находящийся по одному из конкретных адресов; выделить участок памяти, не пересекающий отметку, кратную 64 Кб. У меня память, лежащая до одномегабайтной и 16-мегабайтной отметок считалась дорогим системным ресурсом, кстати именно поэтому я после перехода в защищенный режим переносил микроядро и драйвер загрузочного устройства/загрузочной ФС из первого мегабайта повыше, а менеджмент этой памяти выполнял блоками не по 4 Кб, а по 16 байт, да в добавок при страничном управлении для этой области памяти использовал флажки "непереносимая", "невыгружаемая". По поводу кода, который "ушел своим потоком" в режиме ядра, я практически с тобой согласен, но запуск такого потока, если это действительно необходимо, должна выполнять сама выбранная системная функция и естественно за минимальный, заранее предопределенный промежуток времени. Я однажды, также во время разговора, сталкивался с подобной проблемой. Мне твердили: зачем откладывать системную обработку, если функция работает с нольтерминальной строкой, находящейся в памяти. Я ответил только одно: а ты представь, что эта строка занимает 4 гигабайта. Убойный аргумент :) Продолжаю комментировать: код приложения отпускается дальше, если есть чему отпускаться :) В противном случае, чтобы не стоять на месте, можно активизировать другой процесс, уже заждавшийся своей очереди. По поводу стека для нескольких потоков: тут все просто – сколько потоков действует в рамках одного процесса, столько же стеков прикладного уровня в рамках этого процесса должно существовать.

JhuSS, у меня тут каникулы закончились, поэтому я буду заглядывать на форум только по выходным... Может еще кого-нибудь попробуем привлечь к нашей дискуссии! Я теперь уже жалею, что распугал своими речями всех комментаторов :)

Phantom-84 Команды передачи управления call и jmp могут передать управление только страницам памяти в аналогичном кольце. Для передачи на кольцо выше, обработчик сего должен лежать на физической памяти, на которой пересекаются страницы с разными кольцами. И это должны быть невыгружаемые страницы. Иначе сии “простые шлюзы” просто не будут работать. У меня один студент обработчик сего исключения сделал “знающим наших”, но исключение – архитектурно тот же шлюз + офигенная дыра в защите системы от сбоев. Основная задача коммерческих систем – защита их от сбоев. Любые дрова , любой сервис , любое по , написанное любым производителем и всеми в куче , должно встать и работать. Не организовывая дыр в безопасности. Развей в себе сознание хакера , потому как испытание системы – сидят несколько хаков , ищут дыры и пишут по , бьющее по ним . А далее смотрят как система держится. Представь , на сию страницу любое пользовательское приложение заносит свой код и передает ему управление. А создавать быструю систему , но для тепличных условий? Или для образования студентов , или для узкоспециализированных выч. комплексов, где сторонних производителей в проекте не заложено. Мне интересно узнать , какие средства защиты предусмотрены в вашей системе.

JhuSS, при обращении к дескрипторам с любого уровня привилегий осуществляется защита исключительно через DPL. Страничный механизм защиты все подобные обращения расценивает как происходящие на нулевом уровне привилегий (CPL игнорируется). Это тонкости архитектуры, рассчитанные как раз на то, чтобы не возникало ошибок при смене уровня привилегий, когда задействован страничный механизм защиты. При вызове системной функции через шлюз обращение к страницам памяти, содержащим код ядра, происходит уже после обновления текущего уровня привилегий, поэтому ошибки в этой ситуации не происходит. Твоя фраза по поводу того, чтобы развить в себе сознание хакера, меня сильно развеселила. Вот видишь, тебе все-таки знакомы кое-какие жаргонизмы, плюс рискну предположить, что в тебе начинает пробуждаться чувство юмора, а значит еще не все потеряно для нашей совместной работы. Предоставляю тебе неограниченное право наблюдать за тем, как держится наша система. Так уж и быть, станешь нашим первым альфа-тестером :) Про мои средства защиты ничего не скажу по той простой причине, что они мои, а мы в соответствии с темой обсуждения должны «изобретать велосипед»... Ведь это так интересно!

Phantom-84 , не понял , ты пишешь свою систему , или пытаешься бомбить nt. Задавать общие для системного потока и потока пользователя страницы памяти система будет сама. Лезть в уже готовую , заданную для процесса ldt , нет необходимости. Сам факт того , что можно напрямую менять из кода приложения код создаваемого системного потока. Причем , суда по назначению страницы – стартовый код системного потока. Обход защиты потоков проще чем защиты страниц. Пойми , страницы будет две , но физически участок памяти - один. Работая с одной страницей памяти ты параллельно меняешь другую страницу памяти. Понятие “хакер” известно с 60х годов, это уже не сленг а классика. Понятие “вирус” тогда считалось фантастикой.
DPL и CPL это у тебя dispatch и passive irql ? Судя про контексту.

JhuSS, мне казалось абсолютно понятным для всех, что я не «бомблю» ни NT, ни какую-либо другую систему, а пытаюсь себе представить, как может выглядеть архитектура ОС, основанная исключительно на принципах целесообразности, компактности, эффективности и в то же время универсальности, а самое главное новизны :) Меня абсолютно не интересуют полностью законченные решения, реализованные в других системах, с точки зрения их переноса в новую ОС. Мне конечно приятно, если то, до чего я дохожу своим и немного коллективным умом, во многом аналогично тому, что уже существует и общепризнанно эффективным. Но мне еще приятнее, когда у меня получается эффективное решение, которое не похоже на другие. Теперь поясню то, о чем я говорил в предыдущем сообщении. При передаче управления, когда текущий уровень привилегий меняется на более высокий, нет необходимости в пересечении страниц. Более того, трудно вообще представить, как это может положительно повлиять на казалось бы неразрешимую проблему. Именно из-за невозможности программно разрешить данную проблему и было применено ее аппаратное решение. А именно при обращении к дескрипторам во всех таблицах, сегментам состояния задачи, а также стеку на уровне ядра страничный механизм защиты, даже если он включен, бездействует. А чтобы при этом прикладная задача не могла обращаться к произвольным дескрипторам, действует механизм защиты самих дескрипторов, основанный на использовании поля DPL в дескрипторе. Аббревиатуры DPL и CPL введены Intel. О том, что они означают, ты можешь прочитать в любой документации по процессорам или другой литературе.

Phantom-84 Вы про это http://zeus.sai.msu.ru:7000/operating_systems/sos/contents.shtml
Есть средство поднять приоритет текущей страницы , главное дабы в gdt привязка к сей странице на определенную физ память была. А шлюз - точка входа , железная , и очень защищенная. И обратится из user mode (passive level) система позволит только к шлюзам 2ah - 2eh(nt).

JhuSS, там, куда вы меня отослали :), много всего (кстати у меня эти доки есть). Раз ты "бомбишь" NT, то конечно ты можешь сказать, что "система позволит обратиться только к указанным шлюзам". У меня, как ты понимаешь, дела обстоят немного иначе :) То что ты "разбомбил" NT, это хорошо. У меня к тебе будет несколько вопросов по этому поводу. Но прежде мне хотелось бы узнать, ты и впредь собираешься заниматься этим делом или все-таки начнешь что-то не "бомбить", а строить? Теперь вопросы... Насколько мне известно, HAL – это NT-шный модуль аппаратной абстракции, только я не знаю, он эмулирует AT-архитектуру на базе конкретного чипсета или наоборот включает лишь взаимодействие с аппаратурой на основе этого стандарта за счет того, что современные чипсеты должны на аппаратном уровне поддерживать совместимость с AT-архитектурой. Это не провокационный вопрос, как может на первый взгляд показаться. Просто я тут размышлял, можно ли не включать поддержку разных типов шин, PNP-конфигурирование и т.п. непосредственно в микроядро современной системы, а реализовать все это в виде отдельных драйверов. В моей системе все базировалось на AT-архитектуре и все прекрасно работало. Вот только на некоторых чипсетах системный таймер на нулевом канале считал в два раза быстрее, чем это было запрограммировано. Следующий вопрос... Насколько я знаю, в NT реализовано аппаратное переключение задач. Мне же кажется, что в системах с виртуальной памятью вполне можно остановиться на программном переключении. Как минимум не придется перегружать LDTR, если LDT вообще используется. И еще один вопрос, раз уж я упомянул таймер. Как ты считаешь, в новой системе нужно использовать постоянный квант времени для планирования по таймеру или высчитанный исходя из производительности процессора. У меня квант был равен 1/100 секунды. Но я не смог нормально протестировать свою систему с большим количеством одновременно работающих процессов, у которых был бы приоритет real time.

Hal – по вопросу , ради интереса вскрыл на нескольких платформах , функции работы с портами , dma , cmos. Для разных платформ – разные. Вроде как пакет шинных дров , из входов оных формируется сервис hal.dll. Не рассматривал процесс установки системы, но ощущение , что система формирует набор функций при первой загрузке системы, когда пишет что ставит дрова шин , мостов (кстати рэйдов тоже) , и кмос. Программирует контроллер прерываний. Сам dll как правило один на всех, просто на неиспользуемых функциях стоит одна на всех заглушка.

JhuSS, как я понял, NT лучше всего ставить на намертво зашитый в системном блоке диск :) У меня имеется большое подозрение на то, что NT использует свои широкие возможности по автоконфигурированию только на этапе установки системы. Короче говоря, все системы от Майкрософт, быть может кроме DOS имеют один существенный недостаток - они не очень мобильны :) Мне бы хотелось создать абсолютно мобильную и компактную систему, поэтому меня и интересует вопрос о том, существуют ли более современные стандарты по совместимости чипсетов, чем AT-стандарт, и вообще есть ли такой стандарт или это только мое предположение!

херня все это. нужно ждать когда наконец появятся объектно-ориентрованные процесора.... только тогда можно говорить о новом поколении операционных систем....