Win-совместимая ОС на основе DOS32-расширителя
1. Если, к примеру, в ТМТ создать ехе-шник который переводит досовскую программу в защищеный режим будут ли доступный функции ДОСа? Имеется ввиду, как тем временем сосуществует сама ОС? Что происходит с уже запущенными драйверами? Доступны ли драйвера мыши, клавиатуры, DosLNF, NTFSdos? Прийдется писать 32-х разрядные или ОС переключается в виртуальный х86-режим?
2. Возможно ли из этого ехе-шника в том же самом DOS32 загрузить (реализовать загрузку) WinPE-файл (exe, dll)?
3. Если возможно 2-е, возможно ли пока выполняется уже загруженный WinPE-файл подгрузить (реализовать подрузку) еще один (допустим приостановив первое) и переключатся между ними? (да, я намекаю на многозадачность).
Писать ОС с нуля - ИМХО, для меня сей час вопрос очень сложный... на данный момент я бы лучше приступил к воссозданию WinAPI (Функции ядра, пользовательский интерфес...) Просто для начала хочется опустить некоторые проблемы с поддержкой железа и файловых систем, т.е. как бы оставить их на потом. Из нереального режима, на сколько я понял, напрямую связь с функциями BIOS'а невозможна. Но процессоры поддерживают виртуальный реальный режим. Вот к примеру как делает Windows 9x:
А вот выдержка из доков по ТМТ:
ПРОГРАММНЫЙ ИНТЕРФЕЙС WDOSX (API)
WDOSX API можно разделить на 3 функциональные части:
Интерфейс DPMI 0.9
Расширенный интерфейс DOS INT 21H
Прочие функции
В настоящее время WDOSX поддерживает практически все DPMI функции, описанные в спецификации DPMI0.9. Кроме того, "по просьбам телезрителей" специально добавлена функция 801h.
Поддержка расширенного INT 21H осуществляется аналогично любому другому DOS экстендеру, поддерживающему расширенный INT 21H DOS API. Отвечая на часто задаваемый вопрос, отметим, что функции DOS, не требующие передачи сегментного регистра (в любую сторону), могут вызываться в программе напрямую, поскольку WDOSX поддерживает их "в живую"! Для многих это очевидно, но, все-таки, не для всех.
Где можно найти более подробные доки по DPMI? Может есть примеры его использования? И вообще, есть знающие люди? Отговорите меня, чтоли :)
А вот зачем писать вин-совместимую ОС, тут много причин. Во-первых, никто ничего нормального в этом смысле не сделал. ReactOS начали делать сразу NT-подобную систему... она у них кое-как на виртуальном железе запускается, а у меня на ноутбуке написала только версию ядра и заглохла. Ну куда это годится? А вообще надо, очень надо... столько умных людей вокруг, а майкрософт до сих пор монополист.
Вот очень интересные статейки, читать обязательно!
Гвоздь в гроб Windows
Читать далее...
Технологический Шантаж
Чтобы предотвратить вмешательство во внутренние коммуникации системы, все сообщения должны быть шифрованы и авторизованы. Например, поток на видеокарту должен быть шифрован кодом AES-128. Требования к криптографии простираются за шифрование данных и охватывают команды и управление между компонентами программ. Например, коммуникации между user-mode и kernel-mode должны буть авторизованы OMAC-метками, со значительной нагрузкой на вычисления на обоих концах канала.
Встроенная графика создает дополнительные проблемы в том, что блоки драгоценного охраняемого "материала люкс" хранятся в памяти, откуда они могут быть paged на диск. Чтобы этого избежать, Виста помечает такие страницы специальным битом защиты, который значит, что они должны быть зашифрованы прежде чем быть скопированы на диск и дешифрованы после попадания в память.
Однако Виста не предписывает никакого другого шифрования памяти, и с довольным видом оставит открытыми ваши банковские пароли, данные счетов и кредитных карт, личные данные и т.е. Механизм защиты, встроенный Майкрософтом ясно дает понять, что в их глазах является "материалом люкс" и стоит гораздо больше, чем .. банковские пароли пользователя
Читать далее...
Если вы думаете, что это бред(так все думают), зачем тогда вообще писать ОС, тем более ни с чем не совместимую?... это ли не больший бред?
2. Реализовать загрузку, естественно, можно, но сложно, а просто загрузить нельзя, т.к. у тебя все-таки работает DOS+расширитель, а не Windows - при попытке запустить PE-файл будет запущена DOS-заглушка из PE-файла.
3. Реализовать, естественно, можно, но стандартными средствами добиться многозадачности нельзя, хотя можно загрузить и оставить в памяти, например, к тому же расширители бывают разные, возможно, некоторые и дают возможность работать в многозадачном режиме.
Уверен, в сети не сложно найти доки по DPMI. А если у тебя имеется "Ассемблер" Зубкова, то там вроде бы есть краткий справочник по этим функциям.
2. Загрузить и запустить можно, но трудно и все ручками придеться делать. Чтобы запустить win приложение потребуется как минимум загрузить еще системные библеотеки. Да еще и работать в виндоусе надо.
3. Даже и не знаю как. Нужен таймер. Вопрос как к нему подобраться. И то это будет не очень хорошо работать. Так как у тебя будет одно адрестное пространство. Придеться выгружать одну программу запускать другую. Тормоза будут еще те.
От дос расширителя я бы отказался. Ничего он тебе не даст.
Либы писать все с нуля. Либы брать виндоус и подменять часть его сервисов.
Для запуска виндовой проги нужно разбирать сам ехешник и реализовывать обработку апи-функций, или их перенаправление какой-либо библиотеке (как делает WINE).
В защищённом режиме функции DOS не работают, их обрабатывает либо расширитель, либо DOS работающая в V86. Классический пример - EMM386. Всё зависит от расширителя. Некоторые драйвера могут иметь специальную точку входа для защищённого режима, имеет её PCI BIOS и VBE.
Многозадачность она само собой будет в защищённом режиме, но нужно реализовывать управление этими задачами. В своё время была популярна программка DesqView, реализовывавшая вытесняющую многозадачность (то есть были фоновые, спящие программы и одна активная). Но с ней естественно не работали некоторые расширители, программы, использующие порты в/в и другие программы, выходящие за рамки функций DOS\BIOS. Проблема в том, что изменив решим процессора в DOS, мы получим фактически самописную ОС, в которой кроме самописного же софта будет работать очень немногое.
Нереальный режим хорош тем, что сносит предел сегмента в 64 кб и таким образом даёт доступ ко всей памяти, но если убрать этот предел для сегментных регистров общего назначения (а не только FS и GS) то может возникнуть много проблем.
По теме советую посмотреть "Ralph Brown's interrupt list", погуглить "DOS extender", почитать статьи BrokenSword'а как введение в защищённый режим.
Но речь вообще о другом. Думаю, Pavia был прав, когда сказал что для целей автора не сильно подходит использование расширителя/какого-либо стандартного интерфейса защищенного режима. Проще минимальный набор функций реализовать самому, я для обращения к аппаратуре самостоятельно осуществлять переключение в v86 или в RM. Я знаю, что некоторые делают именно так.
Я тут много чего начитался, и даже сам наверное могу теперь ответить:
1. Как я понял в виртуальном реальном режиме связь с биосом один фиг теряется... Эмулируюся только команды процессора, а не дос целиком. WinNT наоборот для функционирования липовой дос эмулирует биос, поэтому воспользоваться драйверами ДОС не получится, а если я неправ, это всеравно пахнет извращенством. Оказывается написать свои обрабочики клавиатуры, мыши, видео итп... особой сложности не составляет, документации и книг по этой теме куча. Сижу изучаю ))
2. WDOSX умеет и ехе и длл грузить, но не реализует многозадачность. Так что о пункте третьем в рамках экстендера можно забыть.
Вообще многозадачность уже реализована аппаратно (с 286), надо просто в этом разобраться.
А по поводу DosLNF и NtfsDOS - это наверное 32-х разрядные приложения склеенные с расширителем или своими силами переводящие проц в нереальный режим, иного объяснения появления длинных файлов в рамках х86 не вижу.
Phantom-84 wrote:
Дак всетаки, дос в защищенном режиме отдыхает или нет? Ведь функции доса (INT 21H) эмулирует DPMI-хост, как правило встроенный в сам расширитель, или это встроено от делать нечего?
Pavia wrote:
Неее, я все сам хочу! Я имел ввиду как загрузить минимальное PE-приложение в котором таблица импорта была бы пустой. А апи... каждый вечер после работы по фунции ))) тем более все, что есть в виндовсе и не обязательно переписывать.
Я уже написал выше.... все уже реализовано до нас. Я сам в шоке был)) Наверное можно как то и в паскале (ТМТ) изловчится... но это как раз такой случай, когда на асме проще всего.
Vov4ick wrote:
ага скачал, порассматривал, WDOSX называется. Эмулирует не мало WinAPI но страдает хронической однозадачностью. Зато много исходного кода кторый может быть полезен.
Как бы все это сделать, что бы все динамически происходило. Сначала нужно научится работать с многозадачностью, инфа есть с примерами, даже на русском! В каждом PE-файле есть таблица импорта, не соврать бы, в которой содержится список необходымых ей библиотек + точки входа в эти библиотеки. Есть два варианта, писать эти библиотеки так, что бы точки входа совпадали, либо придумать таблицу транслиции их (буржуйских) точек в свои советские. Если в проге написано kernel.dll - Main st. 9-75, а у нас по таблице эта функция находится по адресу WinAPI.dll - проспект Победы 122-45, то и... дальше пока плохо представляю...
З.Ы. Тему не закрывайте... вопросов будет еще много =)
К аппаратуре можно и из защищенного, это будет проще, но не всегда.
Допустим при выводе пиксела на эран по средствам прерывания BIOS или тупо записью в видеопамять, на сколько я понимаю, особой разницы в сложности/объмности/совместимости кода для этих 2-х вариантов нет.
А вот как быть с там устройством как мышь? Оная может быть подцеплена к трем разным портам - COM, ps/2 или как у меня через USB, что затрудняет написание собственных обработчиков для каждого варианта, особонно для последнего :wacko: . Тоже самое может быть с клавиатурой и не только. В этом случае было бы не плохо воспользоваться прерываниями биваса, которые дают возможность не парится об этом куда бы он не была б подключена...
НО!! Как указывает один источник - "Защищеный режим процессоров Intel 80xxx" автора Александра Фролова и брата его Григория (Том 6.: Диалог-МИФИ,1993, 234 стр.), цитирую:
ОС может виртуализировать ресурсы компьютера - память, порты ввода-вывода, систему обработки прерываний. При этом программа, ориентированная на реальный режим MS-DOS получает в свое распоряжение ресурсы, которые она воспринимает как физические.
Внимание вопрос, имеет ли автор ввиду, что эмуляция функций MS-DOS и железа, представленого BIOS'ом столь необходима, Ведь BIOS - это такой же набор таких же 16-ти разрядных подпрограмм... неужели его нет в v86?
Просветите плз.
BIOS есть. Ты сможешь вызывать его.
MS-DOS отдельно, BIOS отдельно. Bios не предостовляет функций MS-Dos. И функций железа тоже.
Мы можем создать виртуальное железо, с которым будет работать BIOS. А можем оставить и реальное. А можем и свой BIOS сделать, который будет вызывать сервисы нашей ОС.
Насчет, мыши. Написать, не такая уж большая проблема. PS/2 и COM мыши описанны. Клавиотура PS/2 тоже описанна.
Насчет USB. В большенстве случаев, такие устройства могут эмулировать себя как PS/2. Собственно настраевается в BIOS'e.
Это большая разность. Вопервых в защищенном режиме функции BIOS'а не работают на прямую. Ты можешь их вызвать из виртуального режима. Есть специальные сервисы BIOS'а которые работают в защищенном режиме. Но вывод пикселя к ним не относится. А вот записать пиксель ввидео память это самое простое.
Зато установить видео режим, это сделать трудно. Поэтому тут проще вызвать прерывание BIOS'а.
переходит в RM, выхывает нужные функции DOS/BIOS, сохраняет результат, переходит в PM
А весь остальной код можно вынести в остальное пространство (или вообще за пределы первого мегабайта). При этом реально можно подгружать любые драйвера DOSа, которые не перепишут нашу "верхнюю" память, т.к. при этом проц будет находится в RM, а сама ОС будет знать как перейти в PM и куда вернуть управление.
Многозадачность... Можно все проги спроецировать в общую память если это будет хорошо )) Для начала пойдет, потом можно и страничную память подключить.
Обработка прерываний может быть построена следующим образом: если это прерывание устройства, то вызвать наш "нижний" обработчик, а он пусть сам программно вызовет это прерывание еще раз, таким образом оно обработается в DOSе.
переходит в RM, выхывает нужные функции DOS/BIOS, сохраняет результат, переходит в PM
Лучше VM86, так как переход RM,PM медленный. Да и под колпаком будут все функции.
Во времена win3.11 так и было. Одно DOS приложение работало а все остальное зависало.
Лучше сделать каждой задаче свое адрестное пространство VM86 позволяет. И о повторном вхождении можно забыть. Правда тут могут возникнуть проблемы при одновременной работе с железом..
DOSLFN - DOS Long File Names.
Длинные имена файлов никак не связаны с защищённым режимом. Есть (не)документированные функции DOS 7.0, по неизвестным причинам, не реализованные в реальном режиме. DOSLFN восполняет этот пробел. Почитай в справке DOSLFN. С NTFSDOS ситуация несколько другая.
Как-как?
Лучше сделать каждой задаче свое адрестное пространство VM86 позволяет. И о повторном вхождении можно забыть. Правда тут могут возникнуть проблемы при одновременной работе с железом..
Вот и я о том же, к драйверам дос лучше не прибегать.
А по поводу многозадачности...
Приоритеты процессов постоянно пересчитываются. Например, если бы системе надо было выбирать между двумя процессами, у одного из которых приоритет больше, а у другого меньше, процесс, обладающий низким приоритетом никогда бы не смог выполняться, если бы планировщик динамически не изменял значения приоритетов. При расчете приоритетов также играет роль длительность квантов времени. Нет никакого смысла в том, чтобы последовательно выделять процессор некоторому процессу, а затем вытеснять его после того, как он выполнит всего несколько команд. При этом будет работать только код операционной системы, а вовсе не ваша электронная таблица или компилятор.
Учет загруженных в данный момент модулей необходим, потому что он служит основой поддерживаемого Windows совместного использования ресурсов. Так, например, когда вы вторично запускаете программу WordPad (урожденная Notepad), Windows способна заметить, что сегменты кода и формирующий значок этой программы - битовый массив - уже загружены, и вместо того, чтобы загружать еще одну копию, которая только отнимет память, она попросту заводит дополнительные ссылки на уже используемые ресурсы.
Драйвера устройств для работы в многозадачном режиме переписать все же придется..
Если использовать функции BIOS/DOS через VM86 то будут зависания. Многозадачность тут не поможет т.к. если другому процессу захочется в это время обратиться к DOS то ему придется подождать ровно столько времени, сколько обрабатывается предыдущий запрос.
Отсюда вывод что функции DOS нужно заменять на свои. А можно эти тормоза проигнорировать и писать простую ОС ))
DOS не отдыхает, потому что DPMI-хост не эмулирует работу самих функции (реально расширенный функционал вроде бы появляется только у нескольких функций, например, у функции 4Ch), а эмулирует обращение к этим функциям из защищенного режима путем переключения в v86.
Ты же сам говорил, что все это затеял, чтобы поначалу не работать с аппаратурой напрямую. Естественно, лучше реализовать работу с аппаратурой самостоятельно, тем более что у DOS имеется достаточно много ограничений в этом плане (у DOS-сессий Windows ограничений поменьше, но они все-таки есть).
Работа с графикой низкого разрешения и в DOS-то редко когда выполнялась с помощью сервиса BIOS (уж слишком медленно поточечно формировать изображение таким способом), но, например, функции установки видеорежимов активно применялись даже при использовании DOS-расширителей, если конечно эти расширители одновременно не являлись и графическими расширителями. Потом, как уже было здесь сказано, за вполне традиционными сервисами BIOS может быть скрыто взаимодействие с самым современным оборудованием, работа с которым самостоятельно может быть реализована лишь комплексно, т.е. затрагивать совершенно разные технологии управления аппаратурой, а это уже не такая простая задача, как самостоятельно реализовать простейший ввод с клавиатуры и вывод на экран. Отдельный вопрос - это работа с разными типами дисков - современные версии BIOS позволяют работать в том числе и с флэш-накопителями, CD/DVD и т.п. Все это сделать самостоятельно вполне возможно, но это уже весьма большой объем работы. Я, например, до прямого программного управления этими носителями так и не добрался, хотя начал программировать аппаратуру уже достаточно давно. Лучше уж сосредоточиться на программировании логики самой ОС, файловых систем (тех же FAT, поддержки LFN и т.п.) и др.
Вариант disasm'а тоже ничего - можно написать собственный DOS-расширитель под свои конкретные нужды и держать DOS-сессию со всем сопутствующим драйверным добром как компонент взаимодействия с аппаратурой (причем уже не только на физическом уровне, но в ряде случаев и на логическом), а от лица собственного ядра управлять своими приложениями и поддерживать как можно лучший контроль над этой DOS-сессией. Правда, с вытесняющей многозадачностью могут возникнуть некоторые проблеммы, т.к. связка DOS/BIOS имеет явно однозадачную природу.
А можно вообще отбросить дос и забыть про расширители, а в v86-режим входить только по необходимости послать/принять что-то в/из BIOS?
Имею ввиду написать загрузчик и ядро, которые изначально будут работать в защищеном режиме (допустим сам загрузчик будет переводить проц в PE), а отдельный поток запустить в v86, т.е. сделать его мостом м/у ОС и BIOS. Просто полноценная поддержка DOS, думаю это ни к чему.
И вообще нужен ли этот мост? Просто шарясь инете на некоторых форумах натыкаюсь на инфу, что с BIOS'ом можно прекрасно общаться и из PE-режима!
Еще вопрос. Современные Win32-приложения пользуются сервисом DPMI?
1. вызов функций из v86
2. переход PM<>RM для вызова функций
В последнем способе возможна полноценная поддержка как BIOS так и DOS в том числе всех драйверов, которые не испортят нашу память
А можно вообще отбросить дос и забыть про расширители, а в v86-режим входить только по необходимости послать/принять что-то в/из BIOS?
Имею ввиду написать загрузчик и ядро, которые изначально будут работать в защищеном режиме (допустим сам загрузчик будет переводить проц в PE), а отдельный поток запустить в v86, т.е. сделать его мостом м/у ОС и BIOS. Просто полноценная поддержка DOS, думаю это ни к чему.
И вообще нужен ли этот мост? Просто шарясь инете на некоторых форумах натыкаюсь на инфу, что с BIOS'ом можно прекрасно общаться и из PE-режима!
Еще вопрос. Современные Win32-приложения пользуются сервисом DPMI?
Да, можно оставить VM как мост между BIOS и OS.
PE - это формат файла. PM - Protected Mode защищенный режим
Нет, это не так. Есть некоторые сервисы биоса которые работают в защищенном режиме, но не все и их меньшинство.
WIN32 не используют DPMI.
Ага, знаю, просто машинально очипятался =)
Забыть про расширители можно однозначно. Про DOS тоже можно забыть, если тебя не напрягает необходимость реализовывать то, что уже есть в DOS (поддержка файловых систем, драйверы устройств). Да в v86 можно входить для взаимодействия с BIOS и для обработки прерываний, которые обслуживает BIOS.
Вот, Win3.11 (нерабочий труп) - Там как раз работа с файловой системой идет через DOS. Чет, как то не нравятся мне такие тормоза, особенно если файлов в папке много. + ограничение вложенности каталогов. + отсутствие DMA
А в DOS работа идет в основном через BIOS, так что особой гибкости при использовании исключительно BIOS ты, естественно, также не получишь. Поэтому спокойно вливайся в ряды осдевщиков и начинай воплощать свои замыслы с нуля, чтобы твое будущее творение действительно могло быть эффективным. Кстати, если тебе удастся к твоему проекту и Win-дрова прикрутить (это моя давняя задумка, но я постепенно начинаю от нее отходить), то ты одним махом сможешь решить практически все аппаратные проблемы. А можешь пойти радикальным путем - попытаться открутить от каких-либо виндов GUI - и считай, что твоя система уже готова... останется лишь доказать, что ты это сделал законно :)))))))
Чуваки из ReactOS, по их словам, уже продвинулись в этом смысле.
Жаль без исходников (
Ага, я тоже об этом думаю. Всеравно никто специльно для тебя писать дрова не будет. А это очень сложно? добиться совместимости на уровне дров? хотябы дров для 9х.
Вот GUI меня пугает меньше всего, как раз таки его я хочу сам написать с нуля (есть очень много идей, которые так и хочется по быстрей реализовать)
Один фиг все на асме... я уже пару недель пытаюсь вникнуться в этот язык... но как то ничего особо не получается. Есть статьи, аля "пишем ОС". Ну переписываю я код из этой статьи, вроде понимаю на уровне коментарив, как и че происходит. Но когда хочу сам что-то долелать.. просто теряюсь, и не знаю как.
Ну написал я загрузчик, который грузит в память весь последующий код, назовем этот код ядром. А дальше? Наверное надо писать обработчики клавиатуры, функции консолии и файловой системы. (Кстати, я по FAT32 ничего на руском найти не могу). А надо ли сей час? Ведь это же просто драйвера. Может лучше сразу начать с многозадачности? Но там вообще темный лес. А нормальной, доходчивой литературы по lowlevel-програмированию нет.
в общем, я сразу взялся за самое сложное, и теперь голову ломаю. Я привык думать IF'ами циклами, case'ами.
вот допустим как будет на асме следующее:
for ($i=1;$i<100;$i++) { echo($i);}
В обычном языке программирования я могу создать много переменных, каких захочу. И они могут иметь разный тип (текстовые, числовые, целые, дробные). А тут какие-то регистры, которых кот наплакал. И че попало в них не запишешь. Люди, подскажите какой-нибудь учебник типа "ассемблер для дебилов". Что бы не просто объяснялось как писать на нем, а было сравнение с языками высшего уровня, с привычными логическими операторами, математическими. Я допустим еще массивы люблю. А здесь где че хранить?
Лично я пишу на асме все, даже приложения, но это исключительно благодаря любви к fasm'у, для тебя же лучшим решением скорее всего будет связка асм/си.