Продолжается работа над OS System 6 (ранее Systemicus). Немного разобрался с GUI – кроме некоторых недочетов, она уже близка к рабочему варианту. О чем эта краткая статья.
Забегая вперед, выкладываю ( github.com/omegicus/System6 ) образ HDD для тестирования на QEMU (экспериментировать с мин. значением памяти рано – задайте от 64 Мб, хотя должно работать и на меньших значениях). Если кто захочет открыть образ – вот ссылка на GitHub с кратким описанием файловой системы и Windows-tool для его монтирования. github.com/omegicus/OMFS3
Итак, просто поделюсь своим опытом (еще далеко не окончательным) создания GUI для операционной среды. За всё отвечают по-сути два файла – explorer.exe ( 9 килобайт) и user32.dll (31 Кб).
Собственно, мы уже должны уметь выводить графические примитивы и описывать данную тему не буду, более интересна на мой взгляд именно «подноготная».
Основной структурой оконного менеджера является страктура окон. Каждая запись представлена следующей структурой (в моей реализации):
WNDLIST_ITEM:
.handle dd 0 ; +00
.x dd 0 ; +04
.y dd 0 ; +08
.width dd 0 ; +12
.height dd 0 ; +16
.flags dd 0 ; +20
.rsrc dd 0 ; +24
.parent dd 0 ; +28
.wbmp dd 0 ; +32
.caption dd 0 ; +36
;
.clickx dw 0 ; +40
.clicky dw 0 ; +42
.winstyle dd 0 ; +44
.icon dd 0 ; +48
;
.message dd 0 ; +52
.processid dd 0 ; +56
.res dd 0 ; +60
WNDLIST_ITEM_SZ = 64
Интерес представляет .rsrc содержащий .gui секцию PE-исполняемого файла (некоторая аналогия rsrc Windows PE-файла). При загрузке PE в память под секцию .gui выделяется стандартный блок памяти в 64Кб и туда копируется указанная секция.
.parent указывает на родительское окно (обычно = 0, т.е. родитель это рабочий стол)
.wbmp указывает на память, где содержится 8-битное изображение окна. 256 цветов может показаться мало, но для моей реализации этого вполне хватает. Т.е. окно прорисовуется в данном буфере и только потом выводится на экран. Т.е. это теневой буфер.
.clickx, .clicky – содержат координаты окна, где сейчас находится курсор (даже если клавиша не нажата).
Чтобы отследить события (в т.ч. нажатия на клавиатуру или мышь) существует поле .message – сюда помещается указатель на запись в структуре сообщений. Сама структура сообщений и их реализация у всех может быть разной, поэтому тут о ней не пишу.
Пример отправки сообщения активному приложению:
invoke SendMessage, [activeHndlr], WM_LBUTTONDOWN, param1, param2
Отдельная история с некоем подобием Ddraw. Не стал ограничиваться обычным выведением картинки. Программа должна инициировать создание DDraw области и писать туда напрямую. Пока это реализовано через промежуточный буфер, но тру-подход заключается, конечно же, в ремаппинге виртуальной памяти, дабы буфер указывал напрямую в видеопамять. Это впереди. А пока используется структура Ddraw-окон, в которую записываются координаты и размеры окна вывода, адрес видеопамяти (точнее смещения в ней с которого начинается вывод) и адрес буфера, куда пишет приложения. Адрес смещения видеопамяти – вещь необязательная, т.е. его может вычислить и система, но сделано это для ускорения, чтобы при каждом выводе кадра на экран не вычислять данное смещение.
Теперь о композиции. В принципе, самая большая проблема, с которой столкнулся при создании графического окружения – это клиппинг пикселей при перекрытии окон друг другом. В данной демонстрации всего одно окно, но рабочую реализацию можно увидеть в одном из предыдущих моих постов. В остальном принцип работы такой:
1) отрисовка фона
2) отрисовка окон в теневых буферах (в т.ч. элементов окна)
3) вывод данных буферов на экран.
Далее отслеживаем изменения, а именно клавиатуру и клики мышкой, передаем эти сообщения соответствующим окнам. Происходит некоторые изменения в теневых буферах (либо само приложение что-то отрисовало, либо мы изменили состояние кнопок (этим занимается система)) и после этого рабочий стол обновляется, т.е. идет перерисовка всего. Это происходит достаточно быстро, потому как просто копируются скрытые буферы на экран.
Всё достаточно просто и очевидно, но это на первый взгляд. Документации вменяемой по данной теме очень мало и для тех, кто пишет что-то с нуля (как я) многие вещи открываются путем проб и ошибок.
Комментарии (12)
Pinsky
05.03.2016 08:23+2Когда я читаю название System 6 я вспоминаю сразу Macintosh System.
До сих пор помню, что когда я был мелкий и сидел за спектрумом дядьки хвастались, что кто то на свой мак систем 7 поставил и теперь доволен.
mwizard
А какие были предпосылки для создания OMFS3, если она, мягко говоря, повторяет FAT?
omegicus
там задел для шифрования (пока реализовано только для Windows-монтера) + другая система адресации последующих кластеров (они хранятся непосредственно вконце текущего кластера), в FAT нужно при чтении иметь ввиду (и в памяти) всю FAT с указателями на кластеры. + некоторые мелочи (широкие атрибуты, 64 бит timestamp и др.)
mwizard
Я заметил, но это «не в лоб, так по лбу» — разницы никакой, ведь все равно хранятся цепочки кластеров.
Нет, с чего вы решили? Посмотрите спецификацию, саму FAT можно без каких-либо проблем читать on-demand. Просто держать ее в памяти удобнее, т.к. размер небольшой, а профиты в виде read ahead очевидны. В вашей же схеме read ahead сделать не получится.
ExFAT? ;)
И да, если вы делаете упор на безопасность, подумайте о следующей ситуации — подлое ЦРУФБР уничтожило один кластер, который находится как раз посреди вашего файла. Что случится с FAT? В FAT файл будет с дыркой, но остальное прочитается. У вас, если же это был не самый последний кластер файла, хвост будет невозможно прочитать. Что будет, если повреждение придется на саму FAT? Ничего, т.к. в FAT есть возможность создавать теоретически неограниченное количество копий FAT (на практике, как правило, используются две). Т.е. при одинаковых условиях ваша ФС не сможет ни задетектить ошибку, ни исправить ее, ни предотвратить дальнейшую утерю данных.
omegicus
Что мешает хранить в FAT шифрованные данные? — алгоритм, сжатие, вид шифрования, степень секретности — это всё нужно либо в файле хранить либо ОС должна думать. Тут это на уровне ФС атрибутов.
«Я заметил, но это «не в лоб, так по лбу» — разницы никакой, ведь все равно хранятся цепочки кластеров.» — не совсем, это нужно для реального времени работы, нету лагов по чтению и поиску неизветно где находящегося в FAT кластера. Тут время предсказуемо, т.к. сразу получаем №след. кластера. Идея кстати не моя, где-то видел давно статью о подобном методе для ФС под ОСРВ.
ExFAT — лицензия + всё же не все атрибуты…
mwizard
Почему же «неизвестно где»? Смещение записи в FAT всегда известно с точностью до байта, а работа с жестким диском и реалтаймовость в принципе не совместимы, т.к. обычный жесткий диск не дает абсолютно никаких гарантий по поводу того, сколько будет длиться чтение отдельно взятого кластера.
NCQ? Недостатки я описал выше — необратимая утеря данных и отсутствие возможности восстановления даже в теории.
Произвольные расширенные аттрибуты, как и ADS, можно хранить и в обычном FAT, используя зарезервированные комбинации битовых аттрибутов — заодно это сохранит обратную совместимость с другими ОС.
omegicus
1) внимательнее) — там алгоритм шифрования определяется атрибутом
2) Утеря данных. Если в OMFS3 потеряется несколько файлов (при порче диска), то FAT32 при порче обеих копий FAT потеряются ВСЕ файлы…
mwizard
1) нет, вы не поняли. Вот у вас есть поддержка ГОСТ А и ГОСТ Б, реализованная в ядре ОС. Тут приходит к вам подлое ЦРУФСБ, протягивает мульярд долларов и говорит проникновенно "прифет, малшик, реализуй нам, пашалста, поддершку AES256CTR". Если бы у вас шифрование было отделено от ФС, то вы бы просто сделали еще одну, полностью независимую шифровалку, которая регистрирует себя, как прозрачный обработчик файлов определенного типа, связанного с AES256CTR. Т.е. для определенных конфигураций у вас идет только ГОСТ, а для других — и ГОСТ, и AES256CTR, а ФС одна и та же, и реализации ФС глубоко плевать на данные — ей главное их хранить, а что внутри — не ФСное это дело.
А вот если же у вас шифрование является частью ФС, а то и вообще ядра, то просто добавить шифрование уже не выйдет — придется выпускать новую версию драйвера или ядра, а это простой системы, перезагрузки, ошибки внедрения, ошибки обратной совместимости, и всякие прочие проблемы, о которых начинаешь думать, когда они уже произошли, все потерялось и поздно пить ???????. А оно вам надо? Вы ж вроде надежностью занимаетесь.
2) Нет, вы все еще не поняли. Повреждение FAT — это, конечно, неприятно, но давайте лучше посмотрим на примере.
Согласно документации MS, максимальное количество безопасно адресуемых кластеров в FAT32 не может превышать 4177918, что при максимально разрешенном официальном размере кластера в 32 KiB дает нам чуть меньше 128 GiB данных. На самом деле, спецификация FAT32 позволяет использовать разделы размером до 16ТиБ, но далеко не все реализации смогут себе это позволить — так что считаем, что у нас винт в 128 GiB. Примем размер сектора за 512, т.е. итого у нас 268435456 секторов (v). Для раздела такого размера FAT займет почти 16 MiB, или же 32768 секторов (f).
Теперь оценим вероятности. Вероятность того, что один сбойный сектор попадет на FAT — f/v ? 2-13.
Вероятность того, что два сбойных сектора окажутся в двух копиях FAT — f2/v2 ? 2-26.
Вероятность того, что оба сбойных сектора окажутся в двух копиях FAT с одинаковым смещением — f/v2 ? 2-41.
Вероятность того, что три сбойных сектора окажутся в трех копиях FAT с одинаковым смещением — f/v3 ? 2-69.
Последствия одновременного сбоя одного сектора во всех копиях FAT — временная недоступность 128 записей, при этом сами данные остаются на диске и их можно восстановить с большой долей достоверности путем поиска потерянных цепочек кластеров. 128 записей соответствуют 4 MiB данных. Последствия сбоя одного сектора в области данных — утеря 512 байт данных.
——
Теперь берем OMFS3. Раздел в 128 GiB содержит 2097152 кластеров по 64 KiB каждый. "Битовая карта" занимает 2 MiB, или 4096 секторов (b).
Вероятность того, что один сбойный сектор окажется в "битовой карте" — b/v ? 2-16. Последствия утери 512 байт в битовой карте — потеря 512 записей о состоянии кластеров без возможности восстановления, т.е. 32 MiB данных.
Вероятность того, что один сбойный сектор окажется в "FAT" — 1-b/v ? 99.9985%. Любое повреждение почти всегда будет попадать на область данных. Последствия одного сбойного сектора в области данных — необратимая утеря второй половины файла, т.к. в ФС нет механизмов, которые бы позволили обнаружить ошибку или исправить ее.
——————
Вы все еще уверены, что ваша ФС может называться "надежной", если она проигрывает даже такому говну, как FAT?
omegicus
всё верно, но тем не менее. вторую копию FAT сейчас используют РЕАЛЬНО очень редко (особенно посторонние реализации). Соотв. остается именно одна копия.
И тут опа — произвольное повреждение диска (причина на важна), в т.ч. затерта часть FAT. — если затерта 20% FAT — то в реальности количество утерянных файлов будет больше (понятно почему). Восстановлению не подлежит в принципе (то что указано в FAT), т.к. неизвестно даже начального кластера. Грубая сила (т.е. поиск заголовков файлов ничего не дает, кроме первого кластера данных.)
Теперь OMFS. Аналогичная ситуация — затерта битовая карта. Не беда) — берем в каталогах начальные сектора — переходим на него (или грубой силой ищем заголовки файлов) — в конце кластера находится след. кластер. И по цепочке восстанавливаем файл.
Да, я уверен что такой принцип (пусть даже не моя OMFS, я о принципе) более надежен, по крайней мере для восстановления файлов — однозначно…
mwizard