Написание операционной системы
1 вопрос свяязан с самой структурой исполняемго файла (не нашёл книжки в которой рассматривалось бы что компилятор записывает в исполняемый файл), в винде это exe/com в linux просто файл так вот что именно компилятор заносит в исполняемый файл? я так понимаю там тупо команды переведённые в 1001101... ? если это так то второй вопрос отпадает сам собой... в чём разница между exe и исполняемыми файлами линухи? (предполагаю что только в используемой API)
2 я читал статьи по написанию операционок и там мы сначала компилируем в иcполняемый файл причём не важно под linux/win и записываем в boot сектр далее как я понимаю bios читает boot сектр и тупо выполняет его содержимое но если между исполняемыми файлами lin/win есть разница то как он вообще это делает?
3 что есть ФАЙЛОВАЯ СИСТЕМА? т е я не спащиваю как она устроена (понятно что это способ распределения и хранения информации о используемой памяти) мне интересно другое - что этим занимается?
я так понял что это некоторый моуль операционки который при команде создания файла резервирует необходимое количество ячеек на жёчтком диске записывает в спец таблицу номер первой ячейки(понятно что эти действия зависят от модели ФС) и записывает данные, так?
Пока что всё...коментарии...
Как я выше уже постил. Для конвертации wav->mp3 на достаточно объявить сегменты как wav и как mp3. А затем выполнить, типо REP MOVSD. ОС, видя, что данные в регионах не совместимы и начнёт их конвертирование. А вот в Windows если привести API-пример? Бр-ррр...
А теперь усугубим задачу. В ES - BMP-заголовок, в DS - MP3-заголовок. Выполним REP MOVSD. Что произойдёт? Если это было заранее "оговоренно", ОС декодирует mp3 в графическую спектрограмму...
Знаю. Это похоже на "кота в мешке": Делай то, сам смутно знаю что...
Но, здесь я просто излагаю принципы такой ОС. Представьте, у Вас компьютер со "сверх интеллектуальным" оснащением:
Включили питание, управление получила псевдо-BIOS (она не набор базовых I/O-функций, а самое приложение!). Первая её инструкция - создать окно! Т.е. ESI указывает, например на строку "/dev/window", а инструкция LOCK MOV DS:[0],ESI объявляет сегмент окном. Тем самым, 30 байт не весит код, а на экране уже открыто ОКНО! Дальше? Открываем аудио и запускаем миди-приветствие, а в окне - бегущая строка...
И так, код в ПЗУ вместо BIOS стал приложением благодаря тому, что в материнке стоит очень дорогой контроллер xxx-xxxxx-beta! Не успели комп включить, а вот Вам GUI, музыка и 3D. Фантастика?
Не фантастика, если это не настоящий комп, а моя ОС. Любое приложение запускается как BIOS на очень дорогой материнке. А значит никаких API-подпрограмм вовсе не видно. Т.е. ОС - не ОС, а эмулятор подобного компа...
Надеюсь, всё стало на свои места? ;)
Но вы так и не ответили зачем делать перехват REP MOVSD. ? Когда есть call CopyData
со "сверх интеллектуальным" оснащением:
Включили питание, управление получила псевдо-BIOS (она не набор базовых I/O-функций, а самое приложение!)
Это уже не BIOS а OS.
А зачем что-то эмулировать? Темболее эмулятор какойто не полноценный.
Но вы так и не ответили зачем делать перехват REP MOVSD. ? Когда есть call CopyData
Причём тут Виндовс и Медиаплеер?
REP MOVSx - Вызывает исключение. Равносильно CopyData. Но, Вы не понимаете суть.
Возмём JS в HTML и посмотрим такой пример: <script>var a = "text#", b = 3 / 4; var c = a + b;</script>
Т.е. интерпретатор сам определяет тип данных и к концу строки приписывает строковое представление числа.
CALL операции для этой цели не подойдёт. CALL куда? Если все 4Гб пространства - виртуально выделено только приложению? Доступа к ОС-API никакого.
Возьмём, к примеру, эмуляторы Bochs или даже VMWare. У них есть библиотеки, которые эмулируют контроллер клавиатуры, прерывания, ПДП, винчестера, видеокарты и т.д.
Когда код BIOS обращается к видеокарте (порт/память), эмулятор передаёт данные (вектор, регистр, ширина слова) всё нужной функции эмуляции SVGA. Ну, примерно. Т.е. одна инструкция кода становится уже целым вызовом группы функций библиотек. Коду же нельзя обратиться напрямую к функции Bochs/VMWare через CALL! У него лишь в распоряжении порты и память. И при этом, дорогие эмуляторы (как VMWare) позволяют достигнуть высочайщей скорости эмуляции. Так?
А что, если удалить из эмулятора все(!) библиотеки эмуляции реального(!) железа, а в замен подключить свои библиотеки с функциями эмуляции выдуманного PC?
Т.е. вместо одного порта интерфейса клавиатуры будет порт ClipBoard скажем. А сегмент 0xA000 не видеопамять, а реальное OpenGL пространство. Тогда, мы можем в эмулятор "подсунуть" свой файл BIOS и после запуска он начнёт работать. Например, первая же команда BIOS в окне эмулятора построит Сферу, а вторая - запустит музыку. Т.е. 4 байта кода BIOS уже сделали две огромные работы. Так?
Допустим, я взял VMWare, полностью его перепатчил на своё "железо" и у меня получился дистрибутив моей ОС. Дальше, все приложения под такую псевдо-ОС представляются как прошивки ROM-BIOS. Копируешь прошивку в папки VMWare, запускаешь сам VMWare и наслаждаешься! Какие функции CALL могут быть в таком BIOS, если VMWare - эмулятор портов и памяти? Поэтому, работают только IN/OUT, REP, LOCK и т.д. исключения. Вы меня поняли?
Допустим, я выпускаю такой свой VMWare для Windows, Linux, MacOS или даже X-Box. Это значит, что все приложения-прошивки (BIOS) будут работать одинаково на любых платформах. Получается как Virtual-Java Machine... Только байт-код - код-x86. И тотальная инкапсуляция, пусть хоть там миллион вирусов.
И как можно тому BIOS предложить богатые средства OpenAL/OpenGL и прочие прелести? Только через порты и память.
Порты - это REP INSx/OUTSx, а память - это REP MOVSx/LODSx/SCASx и т.д.
Это - единственные способы инерфейса эмулятор<->эмулируемый код. Не так ли?
Это уже не BIOS а OS.
BIOS - приложение, OS - Материнская плата. Читайте выше.
А зачем что-то эмулировать? Темболее эмулятор какойто не полноценный.
Какрас-таки полноценный. Эмулирует не примитивные порты железа, а все средства DirectX и т.д.
Во-вторых ты определись что ты хочешь. А то в одну секунду ты делаешь проц во вторую эмулятор в третью ОС.
Я так и непонял зачем делать эмулятор и называть это ОС?
Если ты хочешь дать 4ГБ. То это и так возможно. А защищенный режим вы похоже плохо знаете.
Еще раз зачем перхватывать исключеня когда програма и так может обратить к ОС с нужными требованиями?
И второе зачем изолировать ОС от приложения? OpenGL как-раз и занимается тем что сбежает программу и железо. А ты хочешь стенкой отгородиться. ОС она должна налаживать связи и быть приближена к программам. А ты пытаешься отдолить потом будешь изобритать все заново.
Дык если на ассемблере-то писать оно и понятно :))
Я за прошлый месяц наверно нафлудил года на три вперед, и ничо, работает как часы - вот что значит формальный подход.
Складывается впечатление, что Vertecs не совсем понимает тенденций в современных ЯП.
Современные системы программирования имеют тенденцию к абстрагированию от оборудования. Железо должно помогать в этом стремлении, а не предлагать что-то несовсем понятное. Вот например CIL-ориентированный процессор, одна из его фишек - поддержка метаданных программы.
Я совмещаю всё в одном. Зачем определяться и зацикливаться на одном, если циклом можно охватить всё сразу, используя побочные данные одной формулы в качестве вспомогательных для второй? ;)
Если ты хочешь дать 4ГБ. То это и так возможно. А защищенный режим вы похоже плохо знаете.
Когда-то Windows начинался как косметика к DOS и операционкой не пахло.
Стандартно, если мы тупо скопируем bmp в wav поток, услышим шум/треск. Если же wav запишем в дамп bmp, увидим хаос. Так-как системе всё равно.
Но, в предлагаемой ОС, если мы объявили один сегмент - звуком, а другой - сетью, то ОС начнёт вещать аудио-поток в сеть по команде REP MOVSD.
Что примерно можно описать в ЯВУ как:
WAVE str1 = "Tada.wav";
NET str2 = "127.0.0.1:8888";
strcpy(str2, str1);
грубо выражаясь. ;)
И второе зачем изолировать ОС от приложения? OpenGL как-раз и занимается тем что сбежает программу и железо. А ты хочешь стенкой отгородиться. ОС она должна налаживать связи и быть приближена к программам. А ты пытаешься отдолить потом будешь изобритать все заново.
Чтобы ОС стала "невидимой". Контроллер SVGA программе не виден как API, но виден как окно 0xA000 и порты. А ОС у меня - подобие материнки, где например OpenGL - видяха с портом "/dev/opengl".
Говоришь: seg#1 = "/dev/opengl" и этот сегмент ОС назначает сервису графики. Любое обращение к ячейкам сегмента приведёт к исключению и обработке сервисом графики.
Стандартно, если мы тупо скопируем bmp в wav поток, услышим шум/треск. Если же wav запишем в дамп bmp, увидим хаос. Так-как системе всё равно.
Но, в предлагаемой ОС, если мы объявили один сегмент - звуком, а другой - сетью, то ОС начнёт вещать аудио-поток в сеть по команде REP MOVSD.
Что примерно можно описать в ЯВУ как:
WAVE str1 = "Tada.wav";
NET str2 = "127.0.0.1:8888";
strcpy(str2, str1);
грубо выражаясь.
И чем первый вариант лучше второго? Точно также тебе придеться объявлять тип сегмента. Только обращаться будешь через пень-колоду вместо нормального вызова. Зачем это надо? Зачем извращаться?
Чтобы ОС стала "невидимой". Контроллер SVGA программе не виден как API, но виден как окно 0xA000 и порты. А ОС у меня - подобие материнки, где например OpenGL - видяха с портом "/dev/opengl".
Говоришь: seg#1 = "/dev/opengl" и этот сегмент ОС назначает сервису графики. Любое обращение к ячейкам сегмента приведёт к исключению и обработке сервисом графики.
И зачем так надо? Спрячим мы от приложени ОС. И что? Спрячь за высоким забором девченку, выкраду вместе с забором.
Как работать будем? На самом деле никуда он не прячиься вот она на мести где и была.
Обработка исключений очень медленная вещь. Поэтому на пользовательсом уровне есть библеотеки которые скрывают все эти вызовы.
И зачем так надо? Спрячим мы от приложени ОС. И что? Спрячь за высоким забором девченку, выкраду вместе с забором.
Как работать будем? На самом деле никуда он не прячиься вот она на мести где и была.
Обработка исключений очень медленная вещь. Поэтому на пользовательсом уровне есть библеотеки которые скрывают все эти вызовы.
Ребята! ;) Что ж Вы так серъёзно и критически?
Вон, альтернативные MenuetOS, KolibriOS как инструментальные не годятся. Только чтобы посмотреть, как может летать твой компьютер в "чистом ходе". Вот Windows, говорят, нарочно тормозит...
Так у меня в плане построить не мировую ОС, а просто посмотреть, на сколько интересна (в механизмах) такая "исключающая" ОС. Пусть даже тормозит раз в 100 сильнее стандартной. Но, сама идея на словах мало проверяема как хороша/плоха. Не так ли? Покажет всё практика с примерами.
А может завтра разработают механизмы обработок исключений за пару машинных циклов? Тогда моя концепция может встать в один ряд альтернативных ОС...
Вы сами хоть поняли, какой бред написали? Предположим, в "самой примитивной современной ос" работает ровно половина кода - 10 мильярдофф строк или 10 мильёнофф человеколет. Преположим, что писали ее 10 тышш человек. Получается, бедняги писали её аж тышшу лет... Всё-таки правильно люди говорят: "don't hack the world; buy "teach yourself c++ in 21 days"" :)
Vertecs, обратите внимание на такую замечательную штуку, а точнее - на ее концепции: http://ru.wikipedia.org/wiki/Plan_9 Что-то мне подсказывает, что Ваши идеи реализованы уже лет как 10-15. Или я ошибаюсь?
Знаком с этим проектом и концепцией.
Знаете, что мне не нравится во всех OS? Системный "мусор" в памяти. Ведь API по сути "мусор": он во всех приложениях неизменно занимает память. Побочно.
Вот Windows: Верхние 2Гб заняты системой, нижние мегабайты - зарезервированы.
В DOS первые килобайты - служебные.
Т.е. редкая OS даёт приложению всё адресное пространство до байта!
Моя концепция - попытка это сделать.
Служебных ячеек нет, а значит их нельзя "запорот".
Системных функций вызываемых CALL'ом или INT нет, значит нельзя перейти ошибочно на их код и свалить всё кругом...
А помните, мы с Вами говорили о расточительности Вашей концепции в отношении памяти? :) Как-то с этим утверждением, ИМХО, не вяжется...
Помню.
Но, как уже сказал. OS эта - эксперимент, а не конкурент ведущим - Linux и Windows.
Просто хочется тоже заняться подобным проектом, как занялись и MenuetOS. Группа любителей из разных стран, короче, пишут всё, что могут к ней.
Увы, как Вы сами здесь неустанно твердили, я не разбираюсь в x86-Protected Mode... Загрузчик ещё не получается написать. :)
Один приятель, когда я рассказал о своей концепции, сказал, что OS будет отличной для начинающих, как язык Basic. Двумя инструкциями на экране ландшафты выводить понравится очень начинающему изучать ассемблер! Понимаете? ;)
Так что я расчитываю, что эта концепция отличная в роли обучающей. А тормоза - бейсик-интерпретаторам это простительно, не так ли? ;) BasicOS :D
думаю тут ты прав :) но это полноценная операционная система а у меня для конкретных целей... те ничего лишнего.
и откуда у меня такая уверенность что 90- 95% этого кода генирируются автоматически?
интересно, на одном из форумов одил кулпрограммер говорил о нескольких тысячах строк кода в день в его исполнение :)
2Vertecs вы так и будите расказывать чем ваша концепция хороша или в конце концов начнёте её воплощать в жизнь?
ps когда я говорил о работе со аудио/видео я имелл ввиду захват с устройства(web-камера, микрофон).
где нибудь есть материал по работе с usb, вообще как узнать адреса этих портов? гуглил.
Это совет прекратить трепаться?;)
Зависит от многих факторов. В школе за час делал одну олимпиадная задачу или не одну. Там примерно строчек 100 кода в час. А сегодня целый день 4 строчки отладить немогу. А вообще за день писали игруху на бесике в 1000 строк.
Плохо гуглил.
http://forum.sources.ru/index.php?showtopic=131130
Плюс есть пару книг.
Так у меня в плане построить не мировую ОС, а просто посмотреть, на сколько интересна (в механизмах) такая "исключающая" ОС. Пусть даже тормозит раз в 100 сильнее стандартной. Но, сама идея на словах мало проверяема как хороша/плоха. Не так ли? Покажет всё практика с примерами.
А может завтра разработают механизмы обработок исключений за пару машинных циклов? Тогда моя концепция может встать в один ряд альтернативных ОС...
давай все вместе начнём чесать спину через живот . может завтра введут моду на такое почёсывание ?
никто вам ничего не запрешает делать . хоть новый процессор , хоть новую ось . но не надо расхваливать всё это раньше чем вы сделаете хотябы прототип/демку .
ЗЫ : я вообще-то буду сильно удивлён еслы вы сможете работоспособные дрова для IDE контроллера наваять для своей оси . ;)
Как раз-то это - элементарная вещь. Есть специализированные книги как раз по этой теме, где описываются соответствующие вызовы.
так я в смысле "попробовал бы" .
для этого драйвера ему надо будет загрузчик , ядро и демонстрашку взаимодействия с драйвером написать . пусть попробует . )
уж если ты делаешь драва под конкретную ось , то эта ось должна быть в наличии . и демонстрашка должна быть отдельной прогой .
Автор???
Извиняюсь, но я не автор этой темы... :)
А так, изложу здесь чистую теорию:
/task/tetris/1
где 1 (единица) - номер экземпляра задачи.
Чтобы закрыть это приложение, посылаем
/task/tetris/1:close
Если процесс повис, можно попросить OS:
/task/tetris/1/stop - преостановить
/task/tetris/1/close - закрыть
/task/tetris/1/info - получить сведения о процессе
Допустим, нам нужен полноэкранный сегмент графики:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
mov ax, 0xA000 ; Сегмент графики у нас
mov es, ax ; будет "традиционным"
lea esi, devName ; Название устройства
xor edi,edi ; Сообщаем контроллеру шины
.wait: lock ; наши намерения исключением,
movsd ; указывая ему имя девайса
jo .error ; OF=1(off) если устройство не откликнулось
jp .wait ; PF=1(pause) если требует подождать
lea esi, setRes ; Внимание! edi уже не 0
mov ebx, edi ; поэтому запоминаем значение
lock ; Указывать на начало не обязательно
movsd ; посылаем команду установки режима
jo .error ; Ошибка?
lea esi, setFull ; Теперь переключимся в FullScreen
mov edi, ebx ; посылая соответствующую команду
lock movsd ; контроллеру дисплея
jo .error ; Ошибка?
lea esi, setHook ; Устанавливаем кое-какие хуки
mov ax, 0xFFF0 ; на выбранный сегмент
push es ; У нас будет несколько таких,
mov es, ax ; чтобы обрабатывать внешние
xor edi, edi ; события.
lock movsd ; Если мы не успеем их обработать,
pop es ; система сделает это сама
.mc:mov ecx, 320*200 ; Сначала отчистим экран
mov al, 0x00 ; заполнив его нужным цветом
xor edi, edi ; палитры с самого начала
rep ; Внимание! Так-как мы запросили прямой
stosb ; доступ к видео, исключений не будет
jo .error ; Просто узнаем, были ли исключения?
.pc:... ; Здесь можем рисовать графику, не беспокоя
... ; систему разными исключениями
lock ; Стоп. Здесь проверим свой стек событий
je .pc ; Пуст? Переходим в paint cycle
cmp al, 0 ; Иначе аккумулятор содержит первое событие
jne .mc ; А ECX - их число. Если AL не 0, идём в main cycle
lock mov [es:0],al ; Иначе, в сегменте 0xA000 стираем описание
hlt ; освобождаем контроллер дисплея и выходим
devName db '/dev/graphics',0 ; Имя устройства
setRes db ':flat,320,200,8',0 ; Команда установки режима. FLAT - 64000 пикселей
setFull db ':private,75',0 ; Частота 75Гц и индивидуальный режим (полный экран)
setHook db '/dev/events' ; Контроллер событий среды
db ':close,0' ; Событие CLOSE вернёт индекс 0
db ':mouse,0' ; Любое событие мышки вернёт 0
db ':task,0' ; Запуск/закрытие/ошибка любой задачи вернёт 0
db ':keyboard,0',0 ; И 0 вернёт любое событие клавиатуры
lea esi,devName ; Имя устройства
xor edi,edi ; Указывает на начало сегмента
lock movsd ; Стоп! Здесь следует разглядеть всё под "лупой"...
; OS проверяет, свободен ли данный сегмент задачи?
; Если свободен, разбирается строка, на которую указывает регистр ESI задачи
; (адрес TSS+0x40) с попыткой найти в среде сервер, который откликнится. Иначе
; говоря, все задачи и серверы в среде получают свой дескриптор:
; /dev/mouse - сервер мыши
; /dev/con - сервер спикера, клавиатуры и текстового дисплея
; /dev/xd - сервер дисков rd, hd, fd и cd
; Например, при старте OS запускается несколько драйверов, которые загружаются
; в память и пополняют таблицу доступных девайсов для приложений. Когда задача
; генерирует исключение префиксом LOCK, OS анализирует, куда указывает регистр
; ESI и EDI. Если EDI == 0, значит, возможно, задача желает иницировать сегмент
; под какое-либо устройство. Если сегмент уже обслуживается каким-то сервером,
; OS пошлёт ему уведомление, что сегмент освобождается. В своё время сервер
; восстановит режимы среды и уничтожит все временные файлы, относящиеся к этой
; задаче.
; Если это операция MOVSD, то начнётся сканирование таблицы активных серверов.
; Если имени не найдено, устанавливается флаг OF (TSS+0x24) и записывается код
; ошибки в EAX (TSS+0x28), чтобы прерванная задача могла быть в курсе событий.
; Если имена совпадают, в директории сервера создаётся новая папка с идентификатором
; задачи. Так, если программа Tetris имела идентификатор 0x15E31030, создаётся папка
; /dev/opengl/15E31030 куда помещаются сведения о задаче Tetris, а сама OS
; пополняет файл статуса задачи ссылкой на /dev/opengl
; Если EDI != 0 или строка из ESI полностью совпадает с именем сервера, который
; обслуживает этот сегмент, то OS просто передаёт параметры тому серверу в
; расширенном виде: ( ######## - id задачи)
; Запрос от задачи: Действия OS:
; /dev/graphics В директории /rd/bin/task/dev/graphics
; создать директорию ######## с файлом конфигурации,
; в котором опишется сегмент
; Затем, файл конфигурации сервера графики пополнится
; ссылкой на директорию ########
; /dev/graphics:flat,320,240,8 Здесь OS передаст серверу графики строку
; flat,320,240,8 и всю TSS. Задача тем временем
; будет либо продолжать работать, либо преостановится.
; Всё зависит от того, следуют ли за LOCK MOVSD любые
; из Jcc/JxCXZ операций или что-то ещё.
Как видите, сама теория очень сыра и требует доработки.
А эмулятор этой OS очень запутанный и я еле еле, кое-как туда внедрил OpenGL сферу и кнопку. Без VirtualAlloc по каждому поводу не обошлось...
А зачем в MenuetOS/KolibriOS используется команда INT 0x40?
А зачем в DOS используется команда INT 0x21? ;)
Похоже, Вы не поняли суть... ;)
Как известно, процессор имеет вывод, который активируются командой LOCK и уведомляет контроллер шины о монопольном доступе к ней в мультипроцессорных системах.
В операционных системах префикс LOCK - привелегированный и из приложений, выполняющихся на 3-ем кольце никак не доступен, вырабатывая исключение.
Таким образом, допустим, пользовательская задача, работающая на третьем кольце, префиксом LOCK будет не переводить электронную часть шины в соответствующий режим, а просто прервёт исполнение кода и через исключение передаст управление OS. Тем временем, OS является "невидимкой" и эмулирует тот самый "умный" контроллер шины. Эмулирует прозрачно на уровне кода, но не машинного времени. Как тут было подмечено...
И что мы получаем?
С одной стороны - OS с эмуляцией абсолютно вымышленного контроллера и хорошими тормозами из-за генераций исключений.
С другой стороны - интересную возможность в разработках HardWare. Допустим, разрабатываем реальную карточку и подключаем её в слот материнки. И эта карточка - реальная модель "умного" контроллера шины и в ней установлен RISC-процессор со сложной программой...
Выкидываем из панельки материнки ROM-BIOS, которая, как пишут, уже морально устарела сотню раз как концепция. Вместо неё вставляем ROM с ядром нашей OS и всё. Включаем компьютер...
Так-как у нас имеется та карточка, её процессор будет следить за состоянием вывода захвата шины Pentium'ом. BIOS'а уже нет как такового, но есть ядро нашей OS. Первыми командами ядра будут команды связи с той карточкой и код будет примерно таким:
xor edi,edi ; "умному" контроллеру шины,
mov ax,0xFFFF ; который реализован как
mov es, ax ; карточка в нашей материнке
mov ecx, 22 ; и команда эта уведомит его
lock rep movsb ; о необходимости произвести
... ; полную само-диагностику всего
initAll: db "/SMARTbus/WIZARD:init",0
И вместо логотипа, как "GENX", при старте компьютера на экране будет вращаться 3D-логотип этой OS и играть музыка. Хотя центральный процессор выполнил пока ещё 20 инструкций!!! Всё делает процессор той карточки! Вы поняли? ;)
Далее, ядро загружает в память все сервисы и приложения простой посылкой "умной" карточке команд, типо найти такой-то файл, загрузить такой-то файл. Процессор просто посылает запросы той карточке. Скорость, как Вы понимаете уже, просто огромная!
Но, карточка эта будет стоить дороже самого компьютера, как Вы уже наверно сообразили. По-этому, моя концепция OS с API через исключения и эмуляцией той "умной" карточки контроллера будет медленной. Но, она может стать новой почвой для разработки программного обеспечения, где OS - не среда с набором библиотек, а простенький загрузчик приложений...
Утопия? Может быть...
Шизофрения? Согласен...
Но, согласитесь, сама концепция имеет что-то привлекательное... Или Вам она омерзительна?
Согласен. Компьютерная среда на низком уровне порт/память уже морально устарела.
Что мы имеем?
Контроллер клавиатуры в реальном режиме - порт 0x60. В среде моей OS - 4Гб страницы виртуальной клавиатуры здесь или через сеть.
Контроллер диска в реальном режиме - порты 0x1F0..0x1F7 и 0x170..0x177. В среде моей OS - 4Гб страницы-зеркала на любой файл или сетевой ресурс.
Контроллер дисплея в реальном режиме - ячейки 0xA0000..0xAFFFF. В среде моей OS - 4Гб страницы 3D-средств OpenGL или DirectX...
Иными словами, моя OS - эмулирует сверх-мамку, а все приложения работают с графикой/звуком/файлами не через API, а будто это реальные крутые девайсы.
Ведь на дворе XXI век. В UNIX-времена, когда были ещё 70-ые, единственный интерфейс приложение-OS был доступен через явные процедуры. В 80-ых, когда на стол уселся i8086 дедушка "Мазай" и появились DOS и Мастдай, никаких исключений ещё не было и INT/CALL были единственной связью с OS. Но ведь начиная с 386-го мы получаем мощные средства защиты и виртуализации! Не грех ли не сделать не просто очередную OS, а 100% новый компьютер съэмулировать не в эмуляторах, а прям начиная с Boot-Sect? Неужели с 1985 года небыло таких идей?
Тормоза? Ну и пусть. Вон, IA-64 не выдержила из-за нехватки ПО под неё. А если поступить так: Сначала разработать и испытать сотню разного ПО под OS предлагаемой концепции, чтобы лет через 5-20 уже знать все плюсы и минусы, когда реально можно будет выпустить в свет материнку с "умным" контроллером и всё ПО с подобной OS будет просто летать...
Да... Увлёкся что-то я... В моём городе два человека поняли эту идею на первом же дыхании и с радостью (один из них и раньше задавался подобным вопросом). А вот программист в нашем коллективе - один я. И к практике (пусть даже кривой) приступил лишь я...
P.S.
А затем, ещё добавлю, что в Вашем понимании "эмуляция" - это максимальная к 100% симуляция примитивных портов, регистров, триггеров и счётчиков на программном уровне.
Тогда как в моём случае такая OS эмулирует один, но "продвинутый" контроллер.
Или пасти тысячу дюжин блох и дрессироваться под них, или завести одну собаку и дрессировать её с ошейником от блох... ;)
Идеи они витают в воздухе. Насчет эмулятора тоже приходила идея. Идея не плохая. Но я считаю что это не лучший вариант. Я считаю что тебе еще далеко до моих идей. А ты напротив думаешь, что ты впереди.
Я думаю что твой друг, так как он не программист считает что все само с собой произойдет. Эту тему думаю развивать не стоит. Пока не будет то что можно показать и заинтересовать других.
Намеков не понимаешь! Я говорил это к тому что от эмуляции можно уйти. А если эмулировать, то то что нужно.
А затем, ещё добавлю, что в Вашем понимании "эмуляция" - это максимальная к 100% симуляция примитивных портов, регистров, триггеров и счётчиков на программном уровне.
Заметьте не я это предложил. Ты же берешь что-то среднее и делаешь костыли.
Научись видать недостатки. Но учти, что вся физика на костылях построена.
Идеи они витают в воздухе. Насчет эмулятора тоже приходила идея. Идея не плохая. Но я считаю что это не лучший вариант. Я считаю что тебе еще далеко до моих идей. А ты напротив думаешь, что ты впереди.
Верю, верю. А чего мне не верить? :)
Ну, он Линуксоист. Идея абстрактного оборудования его тоже когда-то посещала.
С одной стороны, эмулировать реальный комп вплоть до портика - эмуляция хлама. Ещё в начале 90-ых рекламировали Sparc-станции, в противовес IBM-PC.
Ну, эмуляция Apple или Commodore - куда благороднее, чем эмуляция IBM-PC. На карту портов посмотришь - хаос! Куда пальцем тыкали, там и разворачивали контроллеры всевозможные.
Я пытаюсь "выдумать" максимально оптимальную схему, а OS её будет эмулировать. Помните, Windows'98 - красивый Desktop скрывал отстойник?..
Короче, разговор тупиковый.
Сдаю свои позиции. Здесь Вы специалисты. Не я. ;)
Просто, продолжил разговор "коллеги" автора темы.
Думаю, пора мне тихонечко повернуться к бару. :D