Ранее я уже писал, что в разделе электронники имею две мечты: Собственный процессор и собственная операционная система...
Итак, как это не будет выглядить странным, но с Linux'ом я ознакомился месяц назад.
Мне, как пользователю Windows, Linux представляется очень чуждой. Но это отдельный разговор.
Эту тему я хочу начать заново и описать собственную операционную систему так, как я её представляю в идеале...
Базовые принципы
#1: Никакой консоли.
Все операции должны иметь возможность запускаться удалённо. Через какой-нибудь протокол файл-сервера. Допустим, FTP(FXP) или POP3(SMTP).
...
#2: Иное древо файловой системы.
Файловая система не должна иметь тупиковых директорий, куда невозможно попасть без определённых прав. И суть не в том, чтобы пометить их как скрытые. Ведь набрав в строке путь к директории, туда всё равно есть шанс попасть.
Думаю, каждый файл или папка должны иметь в свойствах ссылку на файл (или раздел файла) разметки, где будет описан шаблон представления или поведения этого файла.
#3: Неявный интерфейс приложений.
Все элементы управления (Прогресс-бары, Радио-баттоны, Списки и Комбо-боксы) интерфейса доступны через служебные ячейки (пример).
...
Необходимо очень сильно задуматься и конкретизировать множество мелочей...
Так вот, консоль - как средство управление и введение команд... Хорошо, от него не избавишься. Но...
Сейчас в HTML5 внедряется WebGL. Многие его критикуют за тупое портирование с OpenGL. Я вообще удивляюсь, что за последние десятилетия было столько разработок, как VRML и 3DML, где сцена описывалась разметкой. А в итоге всё свалилось к алгоритмизации. Т.е. если новичку при изучении HTML достаточно заучить базовый набор тэгов, а в VRML - правила иерархии сцены и объектов. То с WebGL нужно учиться быть программистом. И ещё каким!
В Visual Studio интерфейс программы можно организовать в редакторе диалога, визуально распределив все элементы и меню. А можно и через WinAPI с кучей CreateWindow и SendMessage... Windows попыталась завизуализировать консоль. Но, видно, неудачно, так как я без неё не всегда могу обойтись.
Поэтому на ум и пришла мысль, чтобы подменить консоль - графами. Просто в разметке (не в сценарии) как бы расставляешь тэги ресурсов, вкладываешь в друг друга, например...
Позже продолжу...
С принципом #1 как то странно. Я с Linux'ом уже 5 лет на домашней и рабочей машине. Консоль это очень удобный инструмент. В том числе и для удалённого управления по ssh.
Levha С принципом #1 как то странно. Я с Linux'ом уже 5 лет на домашней и рабочей машине. Консоль это очень удобный инструмент. В том числе и для удалённого управления по ssh.
Это понятно. Но принципы всех ОС формировались чуть ли ни 50 лет тому назад.
В моей концепции всё заменяется т.н. "Полимерными ячейками"...
Космическая Одиссея 2001 - позиция 111 минут 55 секунд. (из "мозгов" компьютера на-горячую вынимаются модули). Что и перешло в мою идею ОС...
А именно, как
Полимерная память
У меня это не физический термин, а сугубо виртуальный.
Суть моей полимерной памяти заключается в том, что она просто имеет дополнительное измерение.
Когда приложением запрашивается у ОС объявить некоторый регион памяти полимерным, этот регион, всего навсего, резервируется. Любое обращение к нему провоцирует исключение.
Однако, позвольте! Я не такой дурак, чтобы тупо объявить в своей идее ОС полимерностью флажок MEM_RESERVE функции VirtualAlloc Win-API, так как суть несколько в ином.
Дело в том, что в среде ОС предусматривается возможность объявления региона служебных ячеек. Всякий доступ к которым всегда генерирует исключение, чтобы ОС знала, что программа хочет считать текущее состояние операционной среды, либо внести свои коррективы. Но, с одной маленькой особенностью...
Каждая ячейка региона полимерной памяти имеет совершенно независимое собственное измерение.
Т.е. когда мы запрашиваем у ОС минимальный полимерный регион размером в 4Кб, это вовсе не значит, что его размер - 4Кб...
Да, в памяти приложения он займёт ровно 4096 ячеек от 4Гб. Но это не 4096 байта.
Каждая из 4096 ячеек является неким хэндлом в "иное измерение".
mov edi,PolyDump ; Указатель на "полимерный" регион
lea edi,[edi+56] ; Позиционируем указатель на "портал" №56
stosd ; Пишем туда данные в "проекцию D - Data", регистр edi не изменяется, так как это не обычная логическая память
stosw ; Пишем туда код режима в "проекцию W - Workspace", не изменяя регистр edi
stosb ; Пишем туда информацию в "проекцию B - Bus", не изменяя регистр edi
rep movsd ; Отправляем туда пакет в "проекцию D", регистры edi esi ecx не изменяются
rep scasw ; Сканируем "проекцию W", регистры edi ecx не изменяются
rep cmpsb ; Сверяемся с "проекцией B", регистры edi esi ecx не изменяютсяКак видно, организуется некий API взаимодействия с ОС. Таким образом, в одну полимерную ячейку можно отправить:
Как я уже сказал, если Windows выделяет одному приложению до 2Гб памяти (или до 3Гб, не важно), а верхние 2Гб занимает сама. То в идеологии концепции моей ОС лежит принцип полностью скрытого API.
Допустим, приложению нужен "картридж" с mp3-файлом. Говоря "русским" языком, нужно открыть файл с музыкой через диалог с пользователем.
mov edi,PolyDump ; Указатель на "полимерный" регион
lea edi,[edi+77] ; Позиционируем указатель на "портал" №77: 77 - код буквы 'M' (4D)
mov esi,Mp3Files ; Указатель на описатель режима
rep movsw ; Записываем в "проекцию Workspace" "магическое заклинание"
jo No_devices ; Если ОС установила флаг переполнения OF, значит "устройство не готово"
mov esi,Mp3Stream; Указатель на строку управления
rep movsb ; Отсылаем в "проекцию Bus" команды подготовки потока к воспроизведению
jo No_streams ; Если ОС установила флаг переполнения, значит поток не готов
...
Mp3Files db "/dev/media/*.mp3",0
Mp3Stream db "mode:MP3_OPEN | MP3_STOP",0Тем самым, если изначально полимерная ячейка №77 была пуста, то после приклепления её к "/dev/media/*.mp3" любой доступ к ячейке будет контролироваться mp3-библиотекой.
А установка режима ячейки "mode:MP3_OPEN | MP3_STOP" (подобно специфической командной строке) пошлёт библиотеке команду на вызов диалога с выбором файла и подготовку потока к воспроизведению.
Тем самым, как видим, никаких явных инкладов, никаких call и ничего привычного.
Просто, постоянно генерируем исключения, а ОС сама "угадывает", что мы хотим от неё...
Если мы полимерную ячейку объявим OpenGL-средой, то туда загрузится соответствующая библиотека. Причём, в памяти приложения библиотека уместится ровно в 1 ячейку, отнимет 1 байт пространства (можно запросить миллиард хэндлов на различные нужды. это займёт всего миллиард байт). И работать с этой библиотекой нельзя через обычные call...
[size=85](Хотя, если очень "приспичит", можно в описатель режима ячейки добавить указатель на проекцию в память, где библиотека будет доступна как в "традиционных операционках". Но тогда 4Гб общей памяти может приложению не хватить, если оно будет запрашивать проекции на тысячи библиотек. Но, это отдельная тема.)[/size]
Потому что ОС так и задумывается мною: Не быть простым нагромождением библиотек и кучей функций, а имитировать виртуальную ЭВМ с "аппаратно" вставляемыми картриджами определённого назначения. Вписал в "полимерную ячейку" нужное "магическое" слово, в неё воткнулся картридж (виртуально-аппаратный) и будет в ней "торчать", пока ячейку не обнулим...
Эту мысль всюду критиковали за то, что такие ячейки, генерирующие исключения при каждом доступе, предстанут самым медленным API в мире!
Потому, хочу снова повторить: Эта операцинная система придумывалась концептуально не как очередная операционка, и не как эмулятор некоей ЭВМ.
Операционная система с самого начала задумывалась как эмулятор супер-ЭВМ. (почему "супер"? с самого начала концепция ОС предполагала, что клавиатура может быть в Канаде, мышь - в Австралии, а принтер - на Луне. т.е. любая программа в данной ОС может даже изначально не подозревать, где находятся её оборудование. тупо "втыкаем" в программу "шнур" клавиатуры с любой точки планеты и всё. включая и зеркала проекции файла для одновременного доступа. сама ОС напоминает "облако")
Т.е. если в Windows в кольце 3 инструкции CLI/STI/IN/OUT/INS/OUTS запрещены и вызывают крах приложения, то в задуманной ОС они доступны для обращения к устройствам этой виртуальной ЭВМ. Причём, in/out команды никак не дадут доступа к реальным портам IBM-PC или к симуляции портов IBM-PC (DMA, SoundBlaster, Keyboard etc.). Здесь in/out будут работать как ещё один уровень взаимодействия с аппаратурой (наряду с полимерными ячейками). Т.е. можно объявить порт №54 (EDX=54) IRC-протоколом и отправлять туда сообщения или команды (REP OUTSD).
Можно построить совершенно любую ЭВМ со своими портами и своими девайсами.
А главное: Не смотря на то, что полимерные ячейки и порты в таком случае - крайне медленный API, концепция ОС базируется на том, что (идеализируя) можно пойти к "Китайцу" и заказать материнскую плату на базе x86, но с чипсетом "моей разработки". Т.е. сам чипсет будет контролировать аппаратно ширину слова при доступе к памяти (B, W или D) и "полимерно" воспринимать доступ к ней.
И если программно ОС будет жутко тормозить с моей "полимерностью". То, имея такой "чудо-чипсет", машина будет просто летать (конечно, распаковка mp3-файла - аппаратная, OpenGL - аппаратный)!
Вы скажете, я отстал от жизни, так как OpenGL и DirectX - давно аппаратные.
Но, доступны же из приложения не напрямую, а сквозь уйму программных "костылей": Библиотеки - HEL - HAL...
Как ни крути, без API никак не обойтись.
А в моей концепции ОС имеется ввиду, что любое аппаратное устройство - картридж. И как в DOS - программа может его напрямую программировать через порты и память, будто система - однозадачная.
(раньше в Windows'XP если в программе открыт захват с карты аналогового ТВ-тюнера, в других приложениях доступа к нему уже не было. а вот в Vista и в последующих - можно открыть кучу сеансов работы с тюнером. если где-то переключить канал, во всех программах канал тоже переключится: нет конфликта единоличного управления тюнером. т.е. частично реализована концепция моей ОС. напоминаю, я её задумал в 1996-1998, ещё до знакомства с DOS 3.11, сидя за РАДИО-86РК)...
Тема в архиве.