A я уж подумал, что мы закрыли этот вопрос! Если писать православный драйвер, то от моей задумки толку будет мало, так как необходимо именно парсить код инструкции! Изначально у меня всё базировалось на сегментах, вернее, на сегментных префиксах. Вот видео, как вступление, чтобы проникнуться идеей: Spoiler Перемотать на позицию 11:30 Так как в x86 количество префиксов перед инструкцией не ограничивается, то перед той же «insb» можно влепить цепочку «cs:»+«ds:»+«es:»+«fs:»+«gs:»+«ss:». Естественно, это бессмысленно. Но для моего парсера эти сегменты служат не для манипуляции со страницами памяти, а как директивы к продвижению «внутри порта»… То есть, как на видео, шесть сегментов - шесть направлений движения. Так как у меня порт - объект, то он превращается в некое «эзотерическое пространство», где, аналогично языку LOGO, можно перемещаться в шести направлениях… Это, наверное, Вас сильно смутит. Но если подсчитать, то комбинациями из шести префиксов (включая их повтор и отсутствие) получаем 7⁶ порядка 117649 комбинаций. То есть, вместо использования именованных членов структур, мы просто «рисуем кренделя» сегментными префиксами при доступе к порту, чтобы добраться до нужной функции внутри… Нормальный драйвер вряд ли получит от системы доступ к абракадабре машинного кода в этом случае, так как система ему тупо выдаст индекс порта, ширину слова доступа и направление - ввод/вывод. Мой код парсера накапливает до семи префиксов в переменной «sel» как видите… То есть, инструкция «rep insb ds:ds:es:fs:[edi]» буквально может интерпретироваться как «down+down+east+forward» и рисовать «трек» или «граф» функциональной доступности… Да, Вы в праве назвать мою идею бредом и послать меня! Но, я же говорил, что моя Система изначально задумывалась как Объектно-Ориентированная и где всё иначе, чем у всей парадигмы систем 70-х, так как и CP/M-80, и UNIX, и DOS, и Windows являются прямыми наследниками этой парадигмы. Если в *nix'ах функция fopen принимается вместо битовых флажков целую символьную строку типа "w+", то у меня - почти то же самое, но механизмами префиксов процессора. (У каждой системы - свои тараканы в ядре!) P.S.: Меня сейчас больше заботит вопрос выделения частному процессу всех 4 Гб пространства (не ОЗУ) с удалением доступа ко всем API, так как производительность и оптимизация сейчас у меня стоит на самом последнем месте. А в сети предлагается лишь через реестр увеличить объём памяти под все программы до 3 Гб с потерей стабильности. Главное - запустить всю эту портовую парадигму и ею продемонстрировать общий план в целом, а оптимизировать что-то будем уже потом… И, к тому же, в XXI веке на первый план выходит безопасность, а не производительность. Тем самым, мне надо понять, насколько безопасно можно будет запускать абсолютно любой код.
Paguo_86PK, Руслан, а что именно тебя привлекает в Колибри (да, вещь интересная, но вечно сырая)? почему не попробовать линь, бсд иль тот же андроид (ядро линя, но с доп плюшками)?
Размeр исходника эмулятора! Ещё на своём первом Pentium-90 MHz 48 Mb RAM на дискетах я пробовал и «MenuetOS», и «QNX», и «Arachne»… A так как сидел под Windows'98, то первое, чему я поразился, это - наличию тени под курсором в MenuetOS: Я такого ещё не видел И так пошло-поехало, что именно в ней я написал свою версию игры «Жизнь» и убедился, что под ассемблером система та достаточно приятна… Сама концепция «ОС на ассемблере» - привлекательна, так как нет ничего лишнего и не спрашиваешь себя, под что затрачены десятки мегабайтов у того или иного драйвера: всегда можно заглянуть в исходники… Сенсорные телефоны всегда раздражали своими проблемами сенсора и я к ним относился равнодушно, так как пользовался ими у друзей и смеялся, что я - конченный пользователь ПК. И хоть однокнопочная мышь Apple и против мыши Microsoft вечно вела войну, всё было относительно спокойно. И вот именно с приходом эры Андроид я органически невзлюбил его из-за отказа правой кнопки мышки в Windows'8 в рамках рыночного движения к Смартфонам, так как с сенсорными технологиями более-менее разобрались и он стал набирать популярность. Графический интерфейс стал продуманнее и на этом фоне у Windows'8 проявилось очень много косяков, так как у Microsoft сменилась политика и сырость попёрла из всех щелей, как из склепа! KolibriOS - «вечно сырая» и нет опасности её стандартизации. Нету и сумасшедшего обилия дистрибутивов, как у Linux. Уже в этом плане - она стабильна и не «плодится мутациями» с необходимостью придерживаться капризов рынка! А Андроид - есть продукт мутаций Linux и обязан поддерживать рынок игрового ПО… У Windows уйма концептуальных косяков из-за совместимости с POSIX (верхние 2 Гб) и DOS (я про «\» и «/» в путях каталогов, если что), но в целом она меня устраивает… В общем, у меня довольно сложные отношения со всеми системами. И если что-то и пилить «портовое-сегментное» из моей идеи Операционки, то будет однозначный провал на первой же строчке странички скачивания с предупреждением, что нет никакой совместимости со всем стандартным ПО и бесконечных комментариев типа «а совместимость запилят в ближайшем времени?» и т.д… P.S.: В общем, всё очень сложно…
Paguo_86PK, пожалуй, ты прав == во всяком случае, акь дёмка твоей концепции, симпотней будет на Колибри.
Нa одном из форумов в вопросе пошёл на хитрость и попросил помощи в создании «клеточного автомата» из x86-процессов, которые не должны иметь доступа ни к какому API, запускаться с рандомных EIP-адресов с динамической подстановкой страниц памяти по всем 4 Гб адресного пространства и обменом данными через in/out-инструкции… Причём, процессы, якобы, генерируются рандомизатором и живут не более минуты с генерацией чудовищного количества исключений лишь для построения деревьев и графов из портов. Надо было и здесь такую байку сочинить… Не додумался! Дaли таки заклинание из четырёх строчек (из ReactOS?): Code (Text): NtOpenFile(&hFile, FILE_GENERIC_ALL_ACCESS, &ObjAttr, &StatusBlock, FILE_SHARE_ALL_ACCESS, FILE_SEQUENTIAL_ONLY); NtCreateSectionEx(&hSection, SECTION_ALL_ACCESS, NULL, NULL, PAGE_EXECUTE_READWRITE, SEC_IMAGE, hFile, NULL, 0); NtMapViewOfSectionEx(hSection, NtCurrentProcess(), &ImageBaseAddr, NULL, &ViewSize, 0, PAGE_EXECUTE_READWRITE, NULL, 0); NtCreateProcessEx(&hProcess, PROCESS_ALL_ACCESS, NULL, NtCurrentProcess(), PROCESS_CREATE_FLAGS_BREAKAWAY, hSection, NULL, NULL, 0); Но на моём MS-VC-6 никак не заводится, так как сотни ошибок из-за отсутствия нужных заголовочных файлов. Скачиваю их, компилятор ругается на невозможность поддержки из-за несовместимостей компилятора версий. Приходится обдирать все объявления структур и функций, чтобы скомпилировалось. Теперь ругается линковщик и приходится подгружать всё из dll. Кстати… Если ReactOS - тот же Windows с открытыми исходниками, вполне можно было бы именно его подогнать под мою затею и собрать дистрибутив моей портовой Системы! Любопытная мысль, но мне жизни не хватит браться за такое… P.S.: Ощущение, будто в заросли крапивы вошёл… Очень устал. Завтра продолжу. P.P.S.: Файл «main.cpp» обновил, чтобы оперативно могли видеть весь мой срам… Авось, какое-нибудь любопытное решение подкинете… (Всё-таки, эмбрион новой OS зарождается! )
Тебе надо не заголовки скачивать, а виндовс сдк установить. Чтоб меньше всего мучаться установи студию 2019 комьюнити.
Пoд VMware с Windows'XP и всё варится. Несколько лет назад в виртуалке установил всё по минимуму (HDD - 3 Gb, RAM - 256 Mb) с MS-VC-6 + SP5 для поддержки SSE. Как-то не хочется всё это бросать и переходить на современное.
В стандарте ATA-8 так и подразумевается. НЖМД должен реализовать все запросы WFS. Но судя по скорости внедрения, ждать нам ещё долго. --- Сообщение объединено, Nov 19, 2019 --- Есть несколько подходов к реализации. И объекты это одна из них. Но можно остановится на ней как ни более известной, а потому понятной. Хочется что-бы объекты могли решать как можно более широкий круг задач. Следовательно они должны повторное использоваться в разных задачах. Как известно тесное связывание мешает этому. Поэтому была разработана метрика Деметера. Которая послужила толчком к создания сигналов и слотов в Qt. Дальнейшее развитие пошло по пути функциональных языков с их лямдами и прочим. Конкретнее чего вы хотите? Может и поведую свой концепт... Новый OpenGL? Так Batch-список в формате JSON, видушка его парсит и строит картингу по шейдеру. Можно OpenGL с инверсией управления сделать. REP засылать строчки в порты терминировать их нулем или по длине. Реестр? У вас, что WinXP досихпор? Поставьте Win7 там уже из коробке. Сегментом ограните до 2-х гб, а всё что больше эмулируйте через исключения.
Pavia, O, давно мои темы ты не посещал! Вся горилка перебродила уж! Что я и представил примерами выше. Правда, вместо текстовых строчек возможно и сам x86-код инжектить прямо в системные процессы. То есть, например, произвести инжект инструкции «not» прямо в драйвер графики и весь рабочий стол с видео - всё будет в негативе. Кто-то сказал, что этим я изобрёл x86-шейдеры во внутрь API. И был где-то демо-код… (Там инкапсуляция достигалась тем, что все инструкции ветвления не работали по назначению, а ESP не указывал на стек. Тем самым, push/pop тоже не работали. Инжектился чисто линейный код. А в операциях доступа к памяти индекс относительного смещения через imm32 просто кодировал ascii-буквы имени переменной. Короче говоря, сам x86-код парсился/фильтровался и транслировался снова в x86-код, якобы, в память процесса самого ядра как опциональная пользовательская подпрограмма.) Это вообще к делу не имеет никакого отношения, так как совет - совершенно перпендикулярен базовой идеи данной темы. Кстати, код пока так и не завёлся, так как не хотят грузиться функции из dll ни под Win'XP, ни под Win'8 и в гугле всё глухо. Пока, чисто ради эстетики, выкладываю картинку с направлением векторов сегментными префиксами… P.S.: Надо глубже угугляться…
Кaк ни крути, а от себя не убежишь! Тот самый Пассивный процессор помните? И здесь, и в FantasmOS я по-сути не отхожу от своего изначального плана. А именно… Вот Вы (ребята, мужики, товарищи!) пытаетесь мне объяснить, что сама концепция моей операционной системы - тупиковая в принципе. В первую очередь - проигрывает по скорости из-за громадной кучи генерируемых исключений. Некоторые могут подумать, мол «вот тупой баран же» или «вот ведь упёртый, как осёл»… Только сегодня я понял (когда решил выполнить «регенерацию мозга»), что «Пассивный Процессор» и «Операционка Моей Мечты» (ОММ) - это одно и то же! Ведь в этой «ОММ» весь API реализован именно пассивно! Прежде чем что-то аргументировать, просто только вдумайтесь… Практически 25 лет тому назад я задумался про «Пассивный Процессор»… Где-то около 20 лет назад задумался о подобной ОС. Примерно 10 лет назад в эмуляторе кое-что кое-как сделал и зашёл в тупик… То есть, я одну и ту же идею пытался разрисовать как аппаратно в процессоре, так и программно - в операционке. Под «Пассивный» требуется большое количество больших ПЛИС… Под «ООМ» требуется уйму тактов отдавать под исключения… В принципе, именно потому меня и не пугают жуткие просадки производительности, если подобную «Пассивную ОС» реализовать… По-сути, «Пассивный Процессор» - это и есть «Объектный Процессор»… И данная «Пассивная ОС» - тоже та самая «Объектная ОС»… Нету в их базе императивной парадигмы. P.S.: Не удивительно, что меня никто не понимает… Я и сам себя только что еле осознал и понял! Осталось лишь сделать одно из двух: Либо это реализовать хоть как-то, либо забрать в гроб!
