OSDev

для всех
Текущее время: 17 окт 2018, 06:55

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 81 ]  На страницу Пред.  1, 2, 3, 4, 5 ... 9  След.
Автор Сообщение
 Заголовок сообщения: Re: PlutOS
СообщениеДобавлено: 28 апр 2012, 09:04 

Зарегистрирован: 22 май 2007, 15:29
Сообщения: 290
Для размышления: на современных процессорах нет способа быстрее вызвать ядро, чем инструкции sysenter/syscall. Ваша штука с исключениями будет просто медленнее обычных вызовов.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: PlutOS
СообщениеДобавлено: 28 апр 2012, 11:17 
Аватара пользователя

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 945
Откуда: Дагоба
Станислав,
в собственной архитектуре нет ничего необычного. Многие программные платформы ориентируются на виртуальные архитектуры, - Java Byte Code (если не считать расширение Jazelle на ARM), Dalvik на Android, CIL bytecode для платформы Microsoft .NET и т.д. Вопрос производительности таких машин решается просто, - компиляция из байт-кода в нативный перед исполнением. Чтобы избежать накладных затрат на компиляцию перед каждым запуском, результат компиляции обычно кэшируется.

AlikberOFF,
Я понимаю, конечно, желание изобрести новую платформу, но зачем изобретать что-то весьма близкое к существующей, да к тому же чрезвычайно кривой архитектуре? Даже Intel/AMD в итоге отказались от использования сегментов. Кроме того, прежде чем изобретать велосипед, стоит ознакомиться с лучшими образцами современного велосипедного искусства, причём, желательно, на более достойных образцах, нежели горбатая архитектура x86.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.

<<< OS Boot Tools. >>>


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: PlutOS
СообщениеДобавлено: 28 апр 2012, 19:47 
Аватара пользователя

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 945
Откуда: Дагоба
Yoda писал(а):
Вопрос производительности таких машин решается просто, - компиляция из байт-кода в нативный перед исполнением.

Да, ещё. Если нет сильного желания связываться с JIT Compilation, то можно и интерпретировать. Всё дело в том, что основные виртуальные машины разработаны как раз с упором на максимально возможную скорость интерпретации байт-кода. В отличие от традиционных архитектур.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.

<<< OS Boot Tools. >>>


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Poly-Layered Utilization Twisting Operating System
СообщениеДобавлено: 29 апр 2012, 16:45 
Аватара пользователя

Зарегистрирован: 27 апр 2012, 00:27
Сообщения: 22
Откуда: Узбекистан, Ташкент
Понимаю, что с Вашей точки зрения всё выглядит примерно так: Человек решил написать очередную ОСь, но в силу некомпетентности ли, неопытности ли или невежественности, делает всё как-то не так, не по-человечески.
Замечу, что я это понимаю. Дело в том, что я именно не хочу пополнять пухлый список существующих операционнок своей собственной.
Практически все операционки, начиная с (де-факто) UNIX, приложениям всегда представляются набором библиотек функций и прерываний. Т.е. для приложений они (операционки) видимы. Всё выглядит как типичное: Пришло частное лицо (приложение) в государственную инстанцию (операционное окружение) и начало делать запрос у чиновников на получение доступа к архивам или документам.
В моём случае plutOS должна быть операционкой-невидимкой, чтобы приложения её не видели. Выглядит это как сказочный дворец из сказки "Аленький цветочек": Хлопнул в ладоши и невидимая сила что-то да сделала.
Понимаете, у человека (меня) есть голубая мечта построить такой "сказочный дворец" в исполнении операционной среды. Подчёркиваю, Операционной Среды (ОС), а не Операционной Системы.

По поводу использования портов ввода-вывода и сегментов, о которых нужно забыть и забить, как о рудиментах DOS. Да, я знаю, что всё проецируется в память. У процессора 6802 в Dendy не было никаких портов. Насколько я помню, порты - ноухау Intel при разработке ещё первых i4004 из-за недостатка адресного пространства. Не обижайтесь, но я в курсе на счёт всего этого. Это, как Вы предполагаете, не моя дремучесть на счёт положения вещей. Это моё упрямство!

Итак, попытаюсь сейчас быть предельно краток и с нуля описать задумку:
1. Мне не нравится, что в x86 деление на ноль оформлено как прерывание с вылетом программы. (Если утрировать, получается Голливуд: комп сделал ошибку и всё кругом начало взрываться!). Деление на ноль не такая критическая ситуация. Так же, как и в инструкции BOUND. Поэтому менеджер в первую очередь при всех исключениях от делении на ноль и bound должен просто установить флаг OF-приложения и возобновить его работу со следующей инструкции. В моём понимании - устранить рудиментальный баг процессора;
2. Так-как вся память (страницы по 4Гб) не виртуальная, а формальная. Тем самым, в Windows мне надо добиться, чтобы все четыре сегмента (DS/ES/FS/GS) указывали только на один регион формальной памяти 4Гб. Чтобы чтение/запись по любому адресу сразу вызвало исключение с передачей управления моему менеджеру. Мой менеджер сам разбирётся по префиксу, куда формальные 4Гб обращены;
3. Таблица прерываний для обработки событий имеется, но не стандартные 256 от INT. Существует формальный контролер прерываний - регион памяти в 4Гб разделённый на 256 параграфов по 16Мб.
Тем самым, INT 0x21 - не вызов прерывания DOS, а исключение с проверкой наличия события в потоке #33. Т.е. если поток #33 настроен как буфер консоли (клавиатуры), то он среди тех 4Гб займёт параграф 0x21000000..0x21FFFFFF.
И INT 0x21 вернёт флаг OF, если события консоли имелись. Тем самым приложение сможет сразу прочитать до 8Mb (unicode) текста. А чтобы преодолеть ограничение в 16Mb, можно просто настроить следующие параграфы на консоль.
Тогда INT 0x21..0x22 будут дублировать одно. И вопреки логике, на те 256 векторов нельзя повесить свои обработчики событий. Приложение обязано само вызывать INT. Чтобы периодические INT команды оповещали мой менеджер, что тот процесс не завис. Предположите, что INTO примерно как Ping-Pong работает;
4. Операции LOCK/CLI/STI работают как и INT - не по назначению. LOCK служит для доступа к настройкам сегмента.
Так mov al,gs:[0] и lock mov al,gs[0] - совершенно разные команды. Первая - вернёт (после исключения) в AL байт из формальной памяти (девайса). Т.е. код клавиши и т.п. Вторая же - вернёт в EAX (помните, ширина слова - опция) служебную информацию из структуры с настройками сегмента GS.
Поэтому так же и mov es,ax и lock mov es,ax - тоже разные. Первое выбирает один из 4млрд сегментов. А второе - указывает, что EAX - ссылка на строку с именем девайса, который должен теперь обслуживать тот сегмент;
5. Операции CLI и STI - операторные скобки. Внутри которых машинный код превращается в скрипт. С помощью динамической компиляции такой x86-скрипт адаптируется и внедряется в системный процесс. Да, хоть на уровне ядра! Тем самым, можно вешать глобальные хуки на что угодно. Правда, подчеркну слово адаптируется.
Что означает, что вся работа с памятью (lods или mov dx,es:[ebp]) транслируется в call-вызовы. Тем самым, ограничивая мятежный код. И если es указывал на GDI, то все stosd-инструкции заменятся на SetPixel(hdc, x ++, y, eax) и т.д. Причём, Jcond переходы в скрипте тоже корректируются.
Какрас по этому пункту я не голословен и на моей страничке можно скачать исходный архив проекта на Си с рабочей демонстрацией. А также html-dom дизассемблер этих x86-скриптов;
6. Как я писал выше, чтобы воспроизвести видео, нужно построить из сегментов цепочку. То же самое можно сказать про всё остальное. Например, если WinRAR-девайс назначается на сегмент как монитор над другим сегментом, то при попытке читать данные из WinRAR-сегмента запустится архивирование данных из приклеплённого сегмента, прежде чем в WinRAR-сегменте появится содержимое архива. Если же на сегмент назначается FASM- или Pascal-девайс, то, как уже понятно, чтение из этого сегмента запустит компиляцию до появления готового к исполнению кода;
7. Допустим, plutOS запущена в Windows и доступна через диск B:, как описывал выше. Чтобы все эти WinRAR-, Pascal-, FASM- и XVID-, OpenGL- и GDI-девайсы заработали, необходимо иметь их в виде dll-плагинов в папке менеджера. А также ini-прописку в конфигурации симулятора plutOS. Без этого приложению при попытке закрепить сегмент за девайсом будет возвращаться флаг OF и всё.

P.S.:
А что такое plutOS вообще?
Poly-Layered Utilization Twisting Operating System - Операционная Система с Использованием Искривлений Полислоя.
Иначе говоря, использование многослойной памяти через искривление операционки. Типо так.
Короче, говоря по-русски, смысл в том, что операционку колбасит.
Как видите, само название говорит само за себя! Оправдывая и тормоза, и сегменты, и порты!

А если серъёзнее, то нужно разобраться с Poly-Layer.
Ещё на самом первом шаге, описанном постом выше, разработки концепции я ввёл термин полимерной ячейки памяти.
Ввёл, когда понял, что при исключении ширину операнда можно интерпретировать опционально.
Т.е. movsd и movsb уже не будут переносить двойное слово или байт соответственно. И в той ещё первой структуре первые 64кб адресовали бы не 16384 rgba-пиксела, как ожидалось, а все 65536. Каким образом - читайте в конце.
В полимерной памяти d->(d)ata, а b->(b)ase. Т.е. movsd копирует данные из одного сегмента в другой. Причём ширина слова данных не определена. Под d может скрываться и byte, и word и, и dword, и qword, и структуры POINT или RECT. Короче, что угодно!
А вот чтобы определить тип (класс) переносимых данных, нужно переключить эти ячейки памяти на нужный слой. Отсуда и термин Polylayered Cell.
Так, если стандартно byte[2] и byte[3] являются соседними половинками, которые объединяются в word[1]. То в полимерной памяти, как Вы уже догадались, это не так. И lodsd может вернуть значение в eax, если это видеопамять (rgba). А может и просто в ax, если это unicode буфера клавиатуры.
Причём, в видеопамяти mov eax,[4] и mov eax,[8] - это не чтение пиксела #1 и #2 соответственно как ожидалось бы. А чтение пиксела #4 и #8 соответственно. Т.е. во время исключения адресация на пиксел автоматически выравнивается! Пусть хоть видеорежим - 24bpp, хоть 16bpp. Хоть даже CGA режим 320x200, где 4 пиксела на байт. Вектор адреса всегда ссылается на определёёный пиксел.
То же самое и с outsb или outsw. Нету никаких составляющих байтов одного слова.
Но, зачем же я использовал ширину операнда лишь как опциональный ключ? Неужели префиксов сегментов и lock мне мало?
Просто я в концепции заранее подчеркнул, что само приложение, а вернее, сам разработчик этого приложения уже знает, что это не ширина операнда, а некий постфикс. Вот такая префиксно-постфиксная организация программирования.

P.P.S.:
Как уже сказано, я лишь хочу посмотреть, оправдано ли меня критикуют остальные (все) разработчики операционнок за такую свистопляску? Действительно ли будут жутчайщие тормоза? Или...
Или, как я упрямо и расчитываю, можно всё таки умело устроить алгоритм приложений так, что исключения будут генерироваться значительно реже.
Просто мне (невежде) любопытно! Любопытно и всё...

P.P.P.S.:
Есть несколько отличных примеров, вдохновляющих меня.
Это известная карманная игра [url=http://ru.wikipedia.org/wiki/Ну,_погоди!_(электронная_игра)]Ну, Погоди![/url] и canvas cycle (не сочтите за рекламу).
В первом - на ЖК-дисплее заранее вытравлены все спрайты, а процессор лишь управляет их отображением или гашением.
Во втором - каждый элемент картины зависим от своего цветового регистра палитры. Меняя один цвет в палитре - изменяем общую картину в целом.
PlutOS - эксперимент. Можно ли после сотен исключений (при инициализации приложения с настройкой сегментов) добиться, чтобы число исключений снизилось к минимуму. И потом одно-два исключения уже меняло всю схему приложения и вырабатывало целый поток данных.

Кстати, у меня есть план на FPGA спроектировать свой микрокомпьютер. Там обращение к видеопамяти должно здорово тормозить процессор. Т.е. при записи в какой-то пиксел процессор остановится, пока схема видеопамяти не дойдёт до этого же пиксела. Короче, без мультиплексеров всё.
Зачем?
Во-первых, если картину рисовать не пиксел за пикселом, а прыгая через строки, можно добиться, что процессор не будет простаивать в ожидании весь кадр;
Во-вторых, динамическую анимацию в такой системе никак не организуешь. А значит, можно лишь делать только пейжажи или подобные "Ну, Погоди!" игры.
Смысл? Исследование. Кто-то мне сказал, что значительный ряд моих идей не имеют практического применение. Только теоретическое, для исследований.
Как известный клеточный автомат Жизнь.

З.Ы.:
К сожалению, предугадывая Вашу реакцию (типо "ах вон оно что! ну тогда фиг с тобой. майся сам, не жди помощи"), скажу, что от задумки не откажусь. Я прошёл уже некоторую закалку: Столько лет скитаюсь по форумам, описываю одно и то же, выслушиваю одно и тоже...
Увы, Ваши аргументы и доказательства для меня не открытие. А очередное эхо. Как в хоре программистов...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: PlutOS
СообщениеДобавлено: 29 апр 2012, 20:09 
Аватара пользователя

Зарегистрирован: 16 апр 2010, 10:10
Сообщения: 319
Откуда: Псковская обл.
Нормально. Времена меняются - меняются технологии и люди приходят новые с новыми идеями. А главное на базе всех достижений возникают и новые требования к ОС. Что бы проделать огромную работу и сделать что-то нужно мотивировать себя - а здесь это можно. Пиши ещё.
Да ещё попробуй систематизировано изложить всё в одном документе - где максимально подробно по пунктам опиши всё.
Найти здесь единомышленников - утопия.
Чем-то похоже на мою H2O.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: PlutOS
СообщениеДобавлено: 29 апр 2012, 21:23 
Аватара пользователя

Зарегистрирован: 16 май 2007, 23:46
Сообщения: 1089
Про плуто ОС я уже читал на коком то форуме. Что могу сказать, дерзайте делайте.

Теперь по существу. Зачем конспирироваться? Это я про то, что свои понятия вы пытаетесь обозвать знакомыми всем словами используя их в своём смысле.

Раз уж решили делать процессор так почему бы не сделать его полноценным? Взяли вы x86 код, но вы его до неузнаваемости переделываете. Так зачем говорить что это x86?


Цитата:
1. Мне не нравится, что в x86 деление на ноль оформлено как прерывание с вылетом программы. (Если утрировать, получается Голливуд: комп сделал ошибку и всё кругом начало взрываться!). Деление на ноль не такая критическая ситуация. Так же, как и в инструкции BOUND. Поэтому менеджер в первую очередь при всех исключениях от делении на ноль и bound должен просто установить флаг OF-приложения и возобновить его работу со следующей инструкции. В моём понимании - устранить рудиментальный баг процессора;

Вообще-то не с вылетом программы. Управление передаётся на системный обработчик. Который по хорошему должен отдать управление программному пользовательскому обработчику, а тот уже может сделать как хочет. Может и на следующую инструкцию передать.

2. 3. "формальный" формальный это заданный формулой в символьном виде. Покажите мне формулу контроллера прерываний.
3. А почему исключение, а не прерывание?

Цитата:
И INT 0x21 вернёт флаг OF, если события консоли имелись. Тем самым приложение сможет сразу прочитать до 8Mb (unicode) текста. А чтобы преодолеть ограничение в 16Mb, можно просто настроить следующие параграфы на консоль.

у вот значит вы все-таки возврат планируете, так это прерывание значит, а не исключение.
Интернет 10ПБайт HDD 1ТБайт память 1ГБайт. Тут вы не обошли ограничения памяти вы просто поменяли один придел на другой. Т.е затык по любому будет.

4. в x86 LOCK это не операция.

Честно концепция вашей ОС мне непонятны. Чем она отличается от java машины? Или NET машины?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: PlutOS
СообщениеДобавлено: 29 апр 2012, 21:50 
Аватара пользователя

Зарегистрирован: 16 апр 2010, 10:10
Сообщения: 319
Откуда: Псковская обл.
Насчёт концепта моей ос например - главное отличие от .NET ,java - моя vm56 и операционная система для неё - это единое целое. Я их разрабатываю параллельно и одновременно. А в вышеозначенных цель вообще другая.
Насчёт обсуждаемой ос - я понимаю примерно какую задачу ставит автор. А решений всегда много - путей много.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: PlutOS
СообщениеДобавлено: 30 апр 2012, 18:29 
Аватара пользователя

Зарегистрирован: 27 апр 2012, 00:27
Сообщения: 22
Откуда: Узбекистан, Ташкент
pavia писал(а):
Раз уж решили делать процессор так почему бы не сделать его полноценным?
Сделать свой процессор - одно.
Написать свою операционку - второе.
То, что я здесь описываю - третье.
1) Свой проц сделать и, главное, продемонстрировать - сложно. Юзер должен быть достаточно продвинутым, чтобы скачать vhdl, прошить его в fpga и протестить.
2) Свою операционку продемонстрировать - тоже требование к юзеру, чтобы тот поставил её образ в Bochs, иное - на CD прожёг.
3) Если мою задумку сделать как службу Windows, для демонстрации юзеру достаточно тупо скачать инсталляшку и запустить демку...
Хм, знаю, Вы подумаете, я играю на публику. Точнее, стремлюсь написать нечто так, чтобы любой юзер тупо смог кликом скачать, установить, запустить, увидеть и удалить!
Тогда как пункты 1 и 2 - гарантируют, что народ, качающий это, компетентен и может подключиться к разработке, если заинтересуется.
Я это понимаю...
Тут дело в другом. Не буду сейчас объяснять.
pavia писал(а):
свои понятия вы пытаетесь обозвать знакомыми всем словами используя их в своём смысле. Взяли вы x86 код, но вы его до неузнаваемости переделываете. Так зачем говорить что это x86?
Как Вами сказано, я всё пытаюсь обозвать словами своего смысла.
Да, не буду скрывать, у многих инструкций процессора я переименовал смысл.
Я выше, кажется, писал. Или нет? Не помню. Короче, в моей концепции:
Инструкция - любая нормальная инструкция процессора;
Операция - префиксы lock/rep, т.к. lock провоцирует вызов операционной среды. Потому префикс lock операцией назвал.
А вот cli/sti - вообще операторы. Вернее, операторные скобки x86-скрипта.
Точнее вот список ключевых операций:
CLI - Clean Lading Image
INT - Invade Note Tape
LEA - Load Extended Access (например, ошибочный lea eax,edx вместо lea eax,[edx])
LOCK - Linking Over Carrier Keeper
L?S - Load ... Stream
STI - Script Translation Implement
pavia писал(а):
формальный это заданный формулой в символьном виде. Покажите мне формулу контроллера прерываний.
Формальный - потому что имеется формально. Символичный. И только.
pavia писал(а):
А почему исключение, а не прерывание
Потом, int хоть и возвращает OF, это не прерывание. Так-как int запрещены и провоцируют исключения.
pavia писал(а):
Вообще-то не с вылетом программы. Управление передаётся на системный обработчик. Который по хорошему должен отдать управление программному пользовательскому обработчику
Обработчик повесить можно. Но, лишний раз после деления поставить jo (лучше вообще перед делением проверять делитель) - дисциплина / хороший тон.

Общее описание:
Общее описание:
1: PlutOS представляется симулятором формальной локальной информационной сети:
1.1: Сеть составляют 65536 формальных компьютеров неопределённой конфигурации;
1.1.1: Каждый формальный компьютер имеет порядковый индекс, отзываясь на него;
1.1.2: Компьютер с нулевым индексом представлен ведущим в управлении ведомыми;
1.1.3: Компьютеры с остальными индексами могут изменять конфигурацию и логику;
1.2: Все компьютеры сети подключены параллельно к общим шинам данных и адреса;
1.2.1: Все 65536 компьютеров имеют двунаправленную шину данных полных 32 бита;
1.2.2: Компьютер с нулевым индексом устанавливает все 48 бит по адресной шине;
1.2.3: С остальными индексами считывают статус шин адреса, данных, управления;
1.2.4: В качестве индексации компьютеров прослушивается старшие 16 бит адреса;
1.3: Все 48 бит адреса формируется из младших 32 бит адреса и 16 бит сегмента:
1.3.1: Операциями установки сегментного регистра выбирается индекс компьютера;
1.3.2: Префиксы подмены текущего сегмента обращаются к компьютеру в этой сети;
1.3.3: Префикс захвата шин формирует запрос к конфигурации нужного компьютера;
1.4: Каждый ведомый компьютер может выполнять только определённую ему функцию:
1.4.1: В приложении ведущего компьютера можно менять конфигурацию в остальных;
1.4.2: Приложение ведущего может приостанавливаться в ожидании итога ведомого;
1.4.3: Приложение ведущего может формально сцепить шины у ведомых компьютеров;
1.4.4: Формально у всех ведомых компьютеров установлен единный комплект задач:
1.4.4.1: Сервисы для поддержки устройств терминала: клавиатуры, мыши, дисплея;
1.4.4.2: Сервисы поддержки графической среды: менеджер окон, OpenGL и DirectX;
1.4.4.3: Сервисы мультимедия: захват/запись, проигрывание потоков видео/аудио;
1.4.4.4: Сервисы поддержки средств по кодированию и компрессии: tar, zip, rar;
1.4.4.5: Сервисы разработки программной части: Assembler, C, Fortran, Pascal…;
1.4.4.6: Сервиса поддержки высокоуровневых скриптов: Java/JS, Perl/PHP/Phyton;
1.4.4.7: Сервисы поддержки СУБД и сетевых ресурсов: MySQL, Socket, FTP, HTTP…;
1.5: Симулирование подобной сети в целом подразумевает определённые сложности:
1.5.1: Симуляция аппаратной сети формальных компьютеров генерирует исключения;
1.5.2: Неверное планирование центрального процесса снижает производительность;
2: PlutOS смягчает классические ситуации с ошибками при выполнении инструкций:
2.1: Результат инструкции BOUND смягчён до уровня приложения с возвратом OF=1;
2.2: Критические ситуации деления на ноль смягчены до установления флага OF=1;
2.3: Ошибки доступа к памяти формируют формальный API или смягчаются под OF=1;
3: PlutOS имеет формальный API и организуется инструкциями CPU низкого уровня:
3.1: Операции прерывания INT считывают состояние из указанного потока событий;
3.2: Неверная операция LEA вместо адреса вернёт дескриптор контекста ресурсов;
3.3: Операциями межсегментной пересылки пакетов данных вызывают процедуры API;
4: PlutOS предоставляет доступ к файлам подобно ресурсам локального оснащения:
4.1: Сегментные регистры заменяют хэндлы файлов, префиксы - обращение к файлу;
4.2: Префикс захвата шины LOCK переключает доступ на контекстные данные файла;
4.3: Ширина слова операндов в работе с файлом подобна опциональному постфиксу;
4.4: Префиксы цикличности REP управляют шириной пакета данных доступа к файлу;
5: PlutOS все файлы отображает в формальном контексте посредственного доступа:
5.1: Все проекции файлов имеют формальный предельный размер с покрытием в 4Gb;
5.2: Ширина слова операндов в инструкциях интерпретируется просто опционально;
5...
Пишите вопросы по любым описанным пунктам. Это поможет мне описать концепцию более детально.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: PlutOS
СообщениеДобавлено: 01 май 2012, 21:56 
Аватара пользователя

Зарегистрирован: 16 май 2007, 23:46
Сообщения: 1089
Paguo_86PK
Хотел на wasm написать, но отвечу здесь. Не хочу там народ спугнуть, вдруг чего интересного напишут.

Та эмуляция которую вы хотите видеть не реализуется аппаратно в рамках x86. И в том виде как вы задумали.

Есть много путей прийти к одному и тому же.
Думаю для ваших целей подойдет эмулятор аналогичный Bochs или qemu.
Bochs использует программную реализацию каждой команды на С. Что делает его переносимым, даже портирован на javascript.
qemu использует трансляцию команд, поэтому эмулирует код очень быстро.

Графический интерфейс пользователя у обоих этих эмуляторов непривлекателен. Но вот исходный код достаточно красив.

А да, чуть не забыл. Вы писали про диск "B:". Советую прочитать про технологию dragdrop. Думаю это достаточная замена.

По поводу демонстрации пользователю. Это трудная задачка. Но если сделать настройки которые подойдут большинству и сделать инсталятор с этими настройками, то часть задачи будет решена.

Остальное комментировать пока не буду. Слишком много, можно целую книгу написать.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: PlutOS
СообщениеДобавлено: 02 май 2012, 06:39 
Аватара пользователя

Зарегистрирован: 27 апр 2012, 00:27
Сообщения: 22
Откуда: Узбекистан, Ташкент
Уже убеждаюсь :shock:
А ещё интересовались, готов ли загрукзчик? :lol:
Уже сырой наикривейщий код на Си даёт такие результаты, что вообще сводит всю концепцию на нет :(
Как я уже писал с самого начала, писать ОСь по-нормальному, как все - смысла нет. Так-как венец операционок уже разработан - Linux. Не было бы Linux, не было сейчас сотен крошечных (от 20Mb) сборок всяких проигрывателей, студий и т.д. (страшно подумать! QNX и подобные я не учитываю) :roll:

Я просто хотел сделать симбиоз-гибрид операционной системы и эмулятора фантомного компьютера (вернее сети из тысяч компьютеров). Использовать QEmu/Bochs, а уж тем более Java или CIL - вообще не то. Выходит за все рамки концепции. Получится уже виртуальная x86-машина на виртуальной Java-машине. Чем лучше кроссплатформенных Bochs и т.п.?
Ведь я поставил себе задачу совсем иную! Поймите... :?

P.S.: Больше 15 лет назад, когда я только-только начал пытаться разрабатывать свой процессор, параллельно пошла разработка и компьютера на его базе (разрабатывать - читай "концепцию").
Процессор получился такой: 64 бита шины адреса, 32 бита адреса программы. Одна задача имеет до 4Гб оперативной памяти. Но при этом и все 4млрд проекций утройств по 4Гб (остальные старшие 32 бита адреса). Куда входили и проекции общих файлов приложений, и многое другое...
В общем, сидя в редакторе текста DOS и не имея никакого представления даже о Windows 3.1, я набросал все основные концепции операционок!
После перехода на Windows я решил адаптировать свою концепцию под x86 на PC... Так я родилось желание написать свою ОСь. Не без заслуги MenuetOS и QNX, помещающихся на дискетке! :D


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 81 ]  На страницу Пред.  1, 2, 3, 4, 5 ... 9  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB