Как сделать свою операционную систему без навыков программирования
Александр Полеванов Просветленный (23926) Влад Косинский, а это будет работать самостоятельно, есть свое ядро и т. д.?
Александр Полеванов Просветленный (23926) Влад Косинский, т. е. есть возможность закатать на носитель дистрибутив и развернуть, скажем, на жесткий диск?
Мы постоянно добавляем новый функционал в основной интерфейс проекта. К сожалению, старые браузеры не в состоянии качественно работать с современными программными продуктами. Для корректной работы используйте последние версии браузеров Chrome, Mozilla Firefox, Opera, Microsoft Edge или установите браузер Atom.
В платформу Microsoft Power Apps будет встроена поддержка инструментов с искусственным интеллектом, которые позволят создавать бизнес-приложения без глубоких навыков программирования, используя лишь диалоговые команды.
Искусственый интеллект поможет разработчикам
Microsoft интегрирует технологии искусственного интеллекта со своим языком программирования Power Fx, который применяется в разработке приложений на платформе Power Platform. Это позволит клиентам компании создавать программы практически без необходимости написания кода. Об этом компания сообщила в рамках своей технологической конференции Microsoft Build 2021.
Новые функции будут доступны в рамках публичного предварительного тестирования к концу июня. 2021 г. на территории Северной Америки. В будущем Microsoft также планирует интегрировать язык Power Fx в другие инструменты Power Platform.
Программирование на естественном языке
Модель GPT-3 предложит варианты преобразования запроса в формулу Microsoft Power Fx, языка программирования Power Platform. Пользователю же останется только выбрать наиболее подходящий вариант, например "Filter('BC Orders' Left('Product Name', 4)="Kids")".
Несмотря на простоту языка Power Fx, формирование, к примеру, сложных запросов к данным все еще может требовать достаточно глубоких технических знаний – по крайней мере, понимания логики написания формул. Использование естественного языка в процессе создания приложений, по мнению специалистов Microsoft, позволит еще больше снизить порог вхождения в разработку приложений.
Тем не мнее, в Microsoft подчеркивают, что нововведение не заменяет необходимость понимания человеком кода, который он внедряет, а нацелено на помощь людям, изучающим язык программирования Power Fx, и упрощение выбора правильных формул для получения нужного результата.
GPT-3 (Generative Pre-trained Transformer) – крупнейшая языковая модель в мире, разработанная OpenAI для решения любых задач на английском языке. OpenAI является некоммерческой исследовательской организацией, основателями которой выступают главный исполнительный директор Tesla Илон Маск (Elon Musk) и Сэм Альтман (Sam Altman).
GPT-3 работает в фирменном облаке Microsoft Azure, а для ее дообучения под задачу был использован сервис Azure Machine Learning.
Осенью 2020 г. Microsoft получила эксклюзивную лицензию на использование модели GPT-3. Интеграция с Power Apps является первым применением модели GPT-3 в продукте, доступном широкому кругу пользователей, утверждают в Microsoft.
Интеграция PROSE
В качестве иллюстрации принципа работы техники PBE Microsoft вновь приводит ситуацию, которая могла бы возникнуть в процессе создания приложения для электронной коммерции. Допустим, разработчику необходимо поменять формат отображения имен клиентов в некоторой таблице данных – вместо имени и фамилии теперь должны отображаться имя и инициал, заканчивающийся точкой.
За реализацию принципа PBE отвечает технология PROSE (Program Synthesis Using Examples), разработанная командой исследовательского подразделения Microsoft Research. PROSE уже используется в таких инструментах как Power BI, Excel и Visual Studio.
Power Fx и Power Automate Desktop
Power Fx – это язык программирования, предназначенный для настройки процессов в Power Platform. Язык основан на синтаксисе функций табличного редактора Microsoft Excel и относится к категории так называемых low-code-инструментов, то есть не требующих от пользователя серьезных навыков программирования для успешного применения.
Код интерпретатора Power Fx открыт и опубликован на хостинге ИТ-проектов Github.
Microsoft впервые объявила о запуске Power Fx в марте 2021 г. Ожидается, что Power Fx поможет снизить порог вхождения в разработку и позволит бизнес-пользователям создавать приложения самостоятельно. Профессиональные же разработчики смогут с его помощью ускорить процесс разработки.
Одновременно с анонсом Power Fx Microsoft также открыла всем пользователям операционной системы Windows 10 бесплатный доступ к инструменту Power Automate Desktop, который позволяет автоматизировать рутинные задачи. Причем для этого не нужно уметь программировать – разработка и отладка осуществляются в интуитивно понятной визуальной среде.
В этой небольшой статье по шагам объяснено, как написать простенькую многозадачную операционную систему. Причем эта ОС будет работать даже на XT(8086). На работоспособную и полезную ОС это не тянет, а вот понят принципы системного программирования поможет.
Если вы ни разу не видели ассемблера, то думаю, что вам здесь делать просто не чего.
-
; ; ; ; ; ;
- x86 компьютер (разумеется)
- Ассемблер NASM
- GCC
- ld (GNU Linker)
- GRUB
- Исходный код
- поле магического числа: содержит магическое число 0x1BADB002, для идентификации заголовка.
- поле флагов: сейчас оно не нужно, просто установим его значение в ноль.
- поле контрольной суммы: когда задано, должно возвращать ноль для суммы с первыми двумя полями.
- Всегда желательно использовать виртуальную машину для всех видов взлома ядра.
- Чтобы запустить это ядро на grub2, который является загрузчиком по умолчанию для более новых дистрибутивов, ваша конфигурация должна выглядеть так:
-
- реализация многозадачности (все прерывания); - команды OS; - просто общие данные; - работа с дискетой без DOS (вот глюк); - аналог int 21h в MS-DOS; - главный модуль - компилить его; - распределение ресурсов (семафоры); - работа с памятью; - всевозможные утилиты; - Загрузчик - размещается в boot-секторе;
Окей это же не fasm а. явно другой ассемблер.Или я ошибаюсь?Если ошибаюсь пожалуйста выложте тоже самое но для фасма.
так ну я немного понял о работе ОС ,но вот вопрос куды всё это писать?и всё что здесь написано это на языке ассемблер верно?для этого языка нужно специальные компоненты скачивать или они есть на компьютере?
я не совсем понял те строчки , может разъяснить , кто-нибудь по-подробнее , как запускать вышеуказанные команды
. статью ещё не читал .. но сейчас прочитаю ..
А насчёт MinuetOS - неплохая ось, и проги легко пишутся (структура программы что то между DOS & WIN). :-)
и документированна неплохо. Есть над чем поработать (кстати ядро можно перекомпилить прям с под неё).
2Neo-bel
А у яндекса исходники на 140 метров :P
2All
Для всяких , типо мол нафига вы пишите и все такое, мол не получите ВинХП ит тд - Мы не пишем коомерческую ось не собираемся писать, чтото похожее на ВинХП или Линукс+КДЕ. Кстати КДЕ абсолютно независимая надстройка :p
Насчет винтукея, посмотрите в инете про ReactOS, они встроили туда почти весь API из Win2k :) Вроде даже вторую кваку портировали =)
Также посмотрите проект MenuetOS, ему вроде 2 года, делает 1 человек, но там СТОКА ВСЕГО 8)
2WINsoft
ИМХО где возмешь подходящюю IDE для написания на Паскале, то что есть - убожество, поверь, на другое язык не поворачивается.
Я пишу на Delphi, Pascal. С ASM очень плохо, но ничё, пробьемся. "С миру по строчке - нам ОС" (моё мнение). Мыло, думаю, потянет. Вот моё: Zhekka@tut.by. А твоё?
Парни, давайте в форум.
Здесь оставляем только комменты к статье.
То что вы тут понаписали, я удалю через пару дней.
ZhekkA, я тебя полностью поддерживаю, только таких интузиастов осталось всего человек двадцать на всю Россию. Как вместе-то собраться?
Всё использует бут-сектор, если БИОС стандартный. Иначе не получится. Просто они там ставят бут-лоадер - специальную программу (GRUB/LILO в Linux), в задачу которой входит инициировать загрузку системы (в Linux - загружает ядро и передает ему управление).
Люди! кто знает, как загружается Windows? BOOT-сектор она НЕ использует (вроде как проверено). Или хотя-бы Linux.
2 INB
Хм. это в смысле - под процессор?
Имеется в виду написать дрова-трансляторы к процессорам, а саму ОС писать на эдакой джаве.
ИМХО, такой метод сильно снизит производительность.
А у меня предложение (не в обиду Neo-bel) сначала написать своё ядро, а потом вставить поддержку софта Windows (по моему так круче и законнее, а то вдруг Дядя Билли в суд пойдет?)
Есть грандиозная идея. Распотрошить Винду, вынуть из нее ядро чтобы совместимость с софтом была, а потом на него навешать собственное. Пошло конечно, но тоже можно реализовать.
А я вообще хотел бы сделать фидо в родном городе, а то программеры в городе есть, а чтобы хоть с кем-то поговорить приходиться далеко ходить, а тут все почти всегда на связи. Ладно, посмотрим что получиться.
В написании собственной ОС много плюсов!
1. Как трениг
2. Для собственного самолюбия
3. Есть возможность сделать что-то отличющееся от изестных ОС
4 Нестандартные методы - двигатель прогресса.
Главное начать. Чем дальше, тем больше будет желающих присоединиться.
А если ОС получится более быстродейственная и удобная, то будующее не такое уж безоблачное. Только не стоит питать илюзий, что за год-два будет готовая ОС. Даже если за эти пару лет оборудование уйдет вперёд, то переписать уже миеюшеюся реализацию гораздо проще, чем начинать с нуля. Если не изобретать велосипед, то до автомобиля бело не дойдёт!
Предлогаю для начала создать проект, где высказать основные положения будующей ОС!
Щас занимаюсь дизайном, а вот был помоложе - увлекался программингом и тоже пытался свою ОС написать)) Попытки были смешными, но тогда только вышла 98я винда, и были ещё щансы что-то сделать)) Сейчас конечно писать что-то похожее на Вин ХП или Линукс бессмыслено, но вот написать что-то концептуально новое, не похожее на уже сужествующее. может быть и получилось бы, но здесь уже нужна команда. Вообще-то было бы интересно поучаствовать :)
Вы еще ничего, на асе собрались ось писать, а вот когда я был маленький. (года два назад) я собрался писать ось на паскале. Я даже много чего написал. Получилось что-то вроде терминала Linux. Но, жаль, софта для нее нигде не нашел :-)
Как я понял эта ОС с дискеты грузится. Интересно будет прописать её в ПЗУ. Если компьютер прошлого века. То в ISA воткнуть, типа сетевой карты с удаленной загрузкой. Если есть USB, то можно с Flash-ки грузиться. Думаю в данном случае можно найти практическое применение. Например, управлять бытовыми приборами.
А я вобше ОС непешу но интересно как же это делается!Жаль! Жаль! Жаль! А я только ели ели тяну на среднего программиста!
И ЗНАЮ ТОЛЬКО (PASCAL,C/C++) И Logo:)
Давно пора написать собственную открытую ОС, с софтом проблем не будет, а правильно написанные драйвера будут работать под процессор, и не зависеть от ОС.
Я тоже занимался изобретением велосипеда, пока не понял, что смысла в этом никакого нет. Интересно только, не более того. А соперничать с современными ОС, (да и не только с современными) - это идиотизм. Что касается написания ОС, подобной WinXP, то с этим и 100 человек вряд ли справятся.
Ну, не знаю. Я, помню, хотел написать свою операционку, когда мне было 14 лет. Детство, амбиции. Был я тогда не более, чем юзверем с фантазией. Даже Асм изучил (не зная ни одного другого языка). Потом, когда подрос и повзрослел я оценил масштабы. Был бы сейчас 1986-й год - тогда ладно. Теоретически можно было сваять приемлимую операционку. А сейчас. Поднимите руку те, кто в состоянии написать за приемлимый промежуток времени (чтобы я был не совсем старый, когда засяду опробовать ее) ОС, сравнимый по возможностям с WinXP, Fedora 4 (я имею в виду Linux + X + KDE и т.д.), софт под нее, дрова под оборудование (не обольщайтесь, производители железа еще Линукс толком не поддержали дровами). Я уже не говорю про то, что к тому моменту это все уже устареет. Кто-то подсчитал, что такую ОС, как WinXP 1 человек не напишет за 1 жизнь. А самое обидное будет - это изобретение велосипеда
Что такое UNIX-подобная операционка? Это ОС, созданная под влиянием UNIX. Но прежде чем заняться написанием ядра для нее, давайте посмотрим, как машина загружается и передает управление ядру.
Большинство регистров x86 процессора имеют четко определенные значения после включения питания. Регистр указателя инструкций (EIP) содержит адрес памяти для команды, выполняемой процессором. EIP жестко закодирован на значение 0xFFFFFFF0. Таким образом, у процессора есть четкие инструкции по физическому адресу 0xFFFFFFF0, что, по сути, – последние 16 байт 32-разрядного адресного пространства. Этот адрес называется вектором сброса.
Теперь карта памяти чипсета гарантирует, что 0xFFFFFFF0 сопоставляется с определенной частью BIOS, а не с ОЗУ. Между тем, BIOS копирует себя в ОЗУ для более быстрого доступа. Это называется затенением (shadowing). Адрес 0xFFFFFFF0 будет содержать только инструкцию перехода к адресу в памяти, где BIOS скопировал себя.
Таким образом, код BIOS начинает свое выполнение. Сначала BIOS ищет загрузочное устройство в соответствии с настроенным порядком загрузочных устройств. Он ищет определенное магическое число, чтобы определить, является устройство загрузочным или нет (байты 511 и 512 первого сектора равны 0xAA55).
После того, как BIOS обнаружил загрузочное устройство, он копирует содержимое первого сектора устройства в оперативную память, начиная с физического адреса 0x7c00; затем переходит по адресу и выполняет только что загруженный код. Этот код называется системным загрузчиком (bootloader).
Затем bootloader загружает ядро по физическому адресу 0x100000. Адрес 0x100000 используется как стартовый адрес для всех больших ядер на x86 машинах.
Все x86 процессоры стартуют в упрощенном 16-битном режиме, называемом режимом реальных адресов. Загрузчик GRUB переключается в 32-битный защищенный режим, устанавливая младший бит регистра CR0 равным 1. Таким образом, ядро загружается в 32-разрядный защищенный режим.
Обратите внимание, что в случае обнаружения ядра Linux, GRUB получит протокол загрузки и загрузит Linux-ядро в реальном режиме. А ядро Linux сделает переключение в защищенный режим.
Что нам понадобится?
Ну и неплохо было бы иметь представление о том, как работает UNIX-подобная ОС. Исходный код можно найти в репозитории на Github.
Для начала напишем небольшой файл в x86 ассемблере, который будет отправной точкой для запуска ядра. Этот файл будет вызывать внешнюю функцию на C, а затем остановит поток программы.
Как убедиться, что этот код послужит отправной точкой для ядра?
Мы будем использовать скрипт компоновщика, который связывает объектные файлы с целью создания окончательного исполняемого файла ядра. В этом скрипте явно укажем, что бинарный файл должен быть загружен по адресу 0x100000. Этот адрес, является тем местом, где должно быть ядро.
Первая инструкция bits 32 не является инструкцией сборки x86. Это директива для ассемблера NASM, которая указывает, что он должен генерировать код для работы на процессоре, работающем в 32-битном режиме. Это не обязательно требуется в нашем примере, однако это хорошая практика – указывать такие вещи явно.
Вторая строка начинается с текстового раздела. Здесь мы разместим весь наш код.
global - еще одна директива NASM, служит для установки символов исходного кода как глобальных.
kmain - это собственная функция, которая будет определена в нашем файле kernel.c. extern объявляет, что функция определена в другом месте.
Функция start вызывает функцию kmain и останавливает CPU с помощью команды hlt. Прерывания могут пробудить CPU из выполнения инструкции hlt. Поэтому мы предварительно отключаем прерывания, используя инструкцию cli.
В идеале необходимо выделить некоторый объем памяти для стека и указать на нее с помощью указателя стека (esp). Однако, GRUB делает это за нас, и указатель стека уже установлен. Тем не менее, для верности, мы выделим некоторое пространство в разделе BSS и поместим указатель стека в начало выделенной памяти. Для этого используем команду resb, которая резервирует память в байтах. После этого остается метка, которая указывает на край зарезервированного фрагмента памяти. Перед вызовом kmain указатель стека (esp) используется для указания этого пространства с помощью команды mov.
В kernel.asm мы сделали вызов функции kmain(). Таким образом, код на C начнет выполнятся в kmain():
Для начала мы создаем указатель vidptr, который указывает на адрес 0xb8000. Этот адрес является началом видеопамяти в защищенном режиме. Текстовая память экрана – это просто кусок памяти в нашем адресном пространстве. Ввод/вывод для экрана на карте памяти начинается с 0xb8000 и поддерживает 25 строк по 80 ascii символов каждая.
Каждый элемент символа в этой текстовой памяти представлен 16 битами (2 байта), а не 8 битами (1 байт), к которым мы привыкли. Первый байт должен иметь представление символа, как в ASCII. Второй байт является атрибутным байтом. Он описывает форматирование символа, включая разные атрибуты, например цвет.
Чтобы напечатать символ с зеленым цветом на черном фоне, мы сохраним символ s в первом байте адреса видеопамяти и значение 0x02 во втором байте.
0 - черный фон, а 2 - зеленый.
Ниже приведена таблица кодов для разных цветов:
В нашем ядре мы будем использовать светло-серые символы на черном фоне. Поэтому наш байт атрибутов должен иметь значение 0x07.
В первом цикле while программа записывает пустой символ с атрибутом 0x07 по всем 80 столбцам из 25 строк. Таким образом, экран очищается.
Таким образом, строка отобразится на экране.
Мы собираем kernel.asm и NASM в объектный файл, а затем с помощью GCC компилируем kernel.c в другой объектный файл. Теперь наша задача – связать эти объекты с исполняемым загрузочным ядром.
Для этого мы используем явный скрипт компоновщика, который можно передать как аргумент ld (наш компоновщик).
Во-первых, мы устанавливаем выходной формат исполняемого файла как 32-битный исполняемый (ELF). ELF – стандартный формат двоичного файла для Unix-подобных систем на архитектуре x86.
ENTRY принимает один аргумент. Он указывает имя символа, которое должно быть точкой входа нашего исполняемого файла.
SECTIONS – самая важная часть, где мы определяем разметку исполняемого файла. Здесь указывается, как должны быть объединены различные разделы и в каком месте они будут размещаться.
В фигурных скобках, следующих за инструкцией SECTIONS, символ периода (.) – представляет собой счетчик местоположения.
Счетчик местоположения всегда инициализируется до 0x0 в начале блока SECTIONS. Его можно изменить, присвоив ему новое значение.
Как уже говорилось, код ядра должен начинаться с адреса 0x100000. Таким образом, мы установили счетчик местоположения в 0x100000.
Посмотрите на следующую строку .text:
Звездочка (*) является спецсимволом, который будет соответствовать любому имени файла. То есть, выражение *(.text) означает все секции ввода .text из всех входных файлов.
Таким образом, компоновщик объединяет все текстовые разделы объектных файлов в текстовый раздел исполняемого файла по адресу, хранящемуся в счетчике местоположения. Раздел кода исполняемого файла начинается с 0x100000.
После того, как компоновщик разместит секцию вывода текста, значение счетчика местоположения установится в 0x1000000 + размер раздела вывода текста.
Аналогично, разделы данных и bss объединяются и помещаются на значения счетчика местоположения.
Теперь все файлы, необходимые для сборки ядра, готовы. Но, поскольку мы намеренны загружать ядро с помощью GRUB, нужно еще кое-что.
Существует стандарт для загрузки различных x86 ядер с использованием загрузчика, называемый спецификацией Multiboot.
GRUB загрузит ядро только в том случае, если оно соответствует Multiboot-спецификации.
Согласно ей, ядро должно содержать заголовок в пределах его первых 8 килобайт.
Кроме того, этот заголовок должен содержать дополнительно 3 поля:
Итак, kernel.asm будет выглядеть таким образом:
Теперь создадим объектные файлы из kernel.asm и kernel.c, а затем свяжем их с помощью скрипта компоновщика.
запустит ассемблер для создания объектного файла kasm.o в формате 32-битного ELF.
запустит компоновщик с нашим скриптом и сгенерирует исполняемое именованное ядро.
UNIX-подобная ОС с ее ядром почти поддалась. GRUB требует, чтобы ядро имело имя вида kernel- . Переименуйте ядро, к примеру, в kernel-701.
Теперь поместите его в каталог /boot. Для этого вам потребуются права суперпользователя.
В конфигурационном файле GRUB grub.cfg вы должны добавить запись такого вида:
Не забудьте удалить директиву hiddenmenu, если она существует.
Перезагрузите компьютер, и вы сможете наблюдать список с именем вашего ядра. Выберите его, и вы увидите:
Это ваше ядро! Оказывается, UNIX-подобная операционная система и ее составляющие не так уж сложны, верно?
Если вы хотите запустить ядро на эмуляторе qemu вместо загрузки с помощью GRUB, вы можете сделать так:
Теперь вы имеете представление о том, как устроены UNIX-подобная ОС и ее ядро, а также сможете без труда написать последнее.
Приветствую всех своих читателей!
Предыдущие выпуски могли быть несколько запутанными. Начальная загрузка, Assembler, BIOS. Сегодня мы наконец переходим к более интересной и понятной части - мы начинаем писать ядро. И писать мы его будем на языке высокого уровня Си.
В начальный загрузчик осталось внести всего пару дополнений и он будет полностью готов грузить любые 32-битные ядра.
Определение объёма оперативной памяти
Конечно, можно подсчитать объём памяти вручную в ядре - перебирать адреса от 0x100000 и пытаться записать туда значение отличное от нуля и 0xFF. Если при чтении мы получаем полученное значение, то всё хорошо, иначе память кончилась - запоминаем адрес последнего удачного чтения, это и будет объёмом оперативной памяти. Однако такой способ имеет два недостатка:
1) Его следует использовать до включения страничной адресации, чтобы иметь доступ ко всей физической памяти, либо устраивать запись через "окно" временной страницы. Лишняя трата времени, при условии, что тестирование памяти BIOS и так выполняет при начальной инициализации, а мы делаем двойную работу.
2) Всё хорошо пока память представляет собой непрерывный участок адресов, но на современных системах с большим объёмом памяти это правило может быть нарушено. К тому же BIOS пишет в самую обычную память таблицы ACPI, которые пригодятся операционной системе и не стоит их затирать до прочтения.
Из этого следует, что лучше спросить про объём оперативной памяти у BIOS, благо он предоставляет все необходимые функции.
Исторически первой функцией определения объёма оперативной памяти было прерывание 0x12. Оно не принимает никаких входных параметров, в на выходе в регистре AX содержится размер базовой памяти в килобайтах. Базовая память - те самые 640 КБ доступные в реальном режиме. Сейчас вы уже не сможете найти компьютер, где бы было менее 640 КБ памяти, но мало ли. Использовать её нам смысла нет - если процессор поддерживает защищённый режим, то вряд ли у него будет меньше нескольких мегабайт памяти.
Объёмы памяти росли и 640 КБ стало мало. Тогда появилась новая функция - прерывание 0x15 AH=0x88. Она возвращает в AX размер расширенной памяти (свыше 1 МБ) в килобайтах в AX. Эта функция не может возвращать значения больше 15 МБ (15 + 1 итого 16 МБ).
Когда и 16 МБ стало недостаточно появилась новая функция - прерывание 0x15, AX=0xE801. Она возвращает результаты аж в 4 регистрах:
AX - размер расширенной памяти до 16 МБ в килобайтах
BX - размер расширенной памяти сверх 16 МБ к блоках по 64 КБ
CX - размер сконфигурированной расширенной памяти до 16 МБ в килобайтах
DX - размер сконфигурированной расширенной памяти сверх 16 МБ в блоках по 64 КБ
Что такое "сконфигурированная" память производители BIOS судя по всему не договорились, поэтому надо просто, если в AX и BX нули, брать значение из CX и DX.
EAX=0xE820
EDX=0x 534D4150 ("SMAP")
EBX - смещение от начала карты памяти (для начала 0)
ECX - размер буфера (как правило 24 байта - размер одного элемента)
ES:DI - адрес буфера, куда надо записать очередной элемент
EAX=0x 534D4150 ("SMAP")
EBX - новое смещение для следующего вызова функции. Если 0, то вся карта памяти прочитана
ECX - количество реально возвращённых байт (20 или 24 байта)
В указанном буфере содержится очередной элемент карты памяти.
Каждый элемент карты памяти имеет следующую структуру (напишу в синтаксисе Си, потому что разбор данных мы будем делать уже в ядре):
Последний элемент структуры не обязателен. Ещё в одном источнике видел, что перед запросом элемента стоит поместить туда единичку. Конечно, сейчас мы не поддерживаем ACPI, но лучше заранее позаботится о том, чтобы получить как можно больше данных. В отличии от параметров памяти, всё остальное можно легко узнать и из защищённого режима напрямую, без BIOS.
Регионы памяти, описываемые картой, могут быть нескольких типов:
1 - Обычная память. Может быть свободно использована ОС для своих целей. Пока мы только к ней и будем обращаться, а всё остальное пропускать.
2 - Зарезервировано (например, код BIOS). Эта память может быть как физически недоступна для записи, так и просто запись туда нежелательна. Такую память лучше не трогать.
3 - Доступно после прочтения таблиц ACPI. Вероятно, именно в этих блоках эти таблицы и хранятся. Пока драйвер ACPI не прочитает таблицы, эту память лучше не трогать. Потом можно использовать так же, как и память типа 1.
4 - Эту память следует сохранять между NVS сессиями. Такую память мы трогать не будем, пока не узнаем, что такое NVS сессии :-)
Не все BIOS могут поддерживать эту функцию. Если какая-то функция не поддерживается, то при выходе из неё установлен флаг переполнения и следует обращаться к более старой. Мы будем использовать формат карты памяти функции 0xE820. Если саму эту функцию вызвать не получилось - получать объём памяти обычными средствами и создавать свою собственную карту памяти из одного элемента. Поскольку определение объёма памяти задача нужная и для запуска 32-битного и для запуска 64-битного ядра, лучше оформить её в виде подпрограммы. Карту памяти разместим по адресу 0x7000. Не думаю, что она может быть больше пары килобайт. Последний элемент вручную сделаем типа 0 - такого типа не возвращает BIOS и это и будет признаком конца.
Ну вот и готов наш начальный загрузчик для 32-битных ядер. В заключение привожу его полный код и мы перейдём к ядру.
Первое ядро
Ядро пока у нас будет состоять из двух файлов - startup.asm и main.c. startup.asm нужен для того, чтобы быть уверенными, что управление попадёт на функцию kernel_main. Ведь она может быть не в начале файла, а содержимое startup.o мы полностью контролируем и если укажем его первым линкеру, то будем управлять и первыми байтами двоичного файла.
Ну вот и последний наш код на чистом Assembler :-). Он выполняет простейшую задачу - уложить в стек три аргумента для функции kernel_main и передать на неё управление. После возврата из неё ядро уходит в бесконечный цикл. По соглашению вызова функций Си параметры следует пихать в стек в образом порядке. Также этот код инициализации загружает новое значение в GDTR - теперь таблица дескрипторов сегментов находится в пространстве ядра и даже если мы отмонтируем первый мегабайт не произойдёт никаких ошибок.
А теперь самое вкусное - простейшее ядро на языке высокого уровня:
Это ядро не делает ничего особенного - просто выводит строку "Hello world!" на последнюю строчку текстового экрана. Структура описанная в начале будет нужна для доступа к списку загруженных модулей.
Важно помнить, что никакой стандартной библиотеки у нас нет - нам доступны только те функции, которые мы сделаем сами. Все printf, strcpy, memcpy и т. п. придётся реализовывать самостоятельно, не пытайтесь обратиться к ним. В следующем выпуске мы займёмся созданием нашего собственного жутко урезанного аналога libc, чтобы программировать было удобнее. Тут начинается самая интересная часть, а принятые решения во многом повлияют на всю структуру системы.
Сборка ядра
Исполняемые файлы собираются в два этапа - компиляция, а потом линковка. На первом этапе компилятор преобразует исходный код в команды процессора и сохраняет всё это в объектный файл. Каждый модуль системы сохраняется в отдельном файле. В этом файле так же содержится информация о функциях, описанных в модули, поэтому из одного файла можно свободно вызывать функцию из другого. Весь код в объектных файлах не привязан к конкретным адресам. На втором этапе линкер собирает все объектные файлы в один бинарный. При этом код привязывается к конкретным адресам (если, конечно, мы не собираем динамически загружаемую библиотеку), вместо ссылок на функции подставляются нужные адреса. Нам нужно получить на выходе особый двоичный файл. Это просто код и данные, без каких-либо заголовков (то есть это не PE и не ELF). В качестве базового адреса используется адрес 0xFFC00000. Для упрощения этого мы опишем всё, что нам нужно в специальном формате скрипта ld:
Этот скрипт говорит, что наш файл будет лежать в памяти непрерывным блоком начиная с адреса 0xFFC00000. В самом начале будет идти секция кода, потом секция read-only данных, затем обычных данных, потом неинициализированных. Все секции выровнены на размер страницы 4 КБ (вдруг мы потом захотим защитить на уровне таблицы страниц код от записи). Последнее описание секции .empty необходимо для того, чтобы даже неинициаилизорованные переменные занимали место в файле (там будут нули). Ведь начальный загрузчик выделяет память для ядра руководствуясь размером файла.
Собрать всё ядро можно следующими командами:
Параметр GCC -ffreestanding указывает ему отключить все стандартные библиотеки. Ведь они привязаны к конкретной операционной системе, а мы пишем новую.
Сборка образа диска
Обойдусь без лишних комментариев и просто приведу линуксовый скрипт сборки образа:
Он предполагает, что все скомпилированные файлы лежат в bin в текущем каталоге, а ещё имеется каталог disk, в котором лежит boot.cfg следующего содержания:
Если вы всё сделали правильно, полученный образ можно запустить в эмуляторе или даже на реальном железе и вы получите подобную картину:
Загрузчик считывает конфигурационный файл, загружает ядро, переходит в защищённый режим и передаёт ему управление. Получив его, наше ядро выводит последнюю строку на экран. Это лишь начало долгого пути, мы переходим к самой интересной части разработки. Теперь выпуски будут гораздо более простым для восприятия, благодаря использованию языка высокого уровня, который как я надеюсь все и так знают. Если вы не хотите разбираться с Assembler, можете просто взять мой готовый загрузчик и startup.asm и изменять уже только содержимое main.c, поскольку весь код до этого не диктует жёстко какие-либо параметры ядра (кроме ФС с которой мы загружаемся) и позволяет построить на своей базе что угодно.
Автоматизация сборки или Makefile
Вы могли заметить, что вручную набивать столько команд достаточно утомительно. К тому же не всегда есть необходимость перекомпилировать все файлы. Например, если startup.asm не был изменён, можно не вызывать fasm. Специально для упрощения компиляции приложений была придумана утилита make, которая входит в стандартную поставку GCC и MinGW.
Любой Makefile стоит из набора правил с такой структурой:
Первое правило, которое должно быть в любом Makefile - цель all. make смотрит на зависимости цели all и компилирует их, а затем выполняет команды и этой цели. Для каждой другой цели сначала собираются её зависимости. При этом имя цели и имя зависимостей могут совпадать с именами реальных файлов. В таком случае пересборка цели произойдёт только если исходники были изменены.
Ещё одна цель, которая часто используется в Makefile - clean. Её задача удалить все бинарные файлы, чтобы начать сборку "с чистого листа". Вот так может выглядеть Makefile для ядра:
А вот так я собираю загрузчик:
Ну и наконец расскажу про вызов других Makefile из одного. Я достаточно ленив, чтобы даже заходить в каталоги с каждым компонентом системы, поэтому создал 1 Makefile, который собирает сразу всю систему. У меня есть папка src, в ней подкаталоги: boot, kernel, make_listfs. В самой src находится вот такой Makefile:
Теперь, находясь в каталоге src я просто пишу make и получаю полностью собранную систему, а если написать make clean, то все двоичные файлы будут удалены и останутся только исходники.
Ну и в довершение последний скрипт, который выполняет полную компиляцию и сборку всех компонентов и образа диска. В одном каталоге с ним надо разместить src, пустой каталог bin и каталог disk с файлом boot.cfg.
С таким набором скриптов сборка система становится предельно простой, особенно если учесть, что последний скрипт можно запускать двойным кликом из файлового менеджера. Различные команды вроде dd, cp, rm не существуют под Windows, поэтому её пользователям пригодится пакет MSYS или Cygwin. Однако простая сборка всех компонентов будет работать даже если у вас есть только GCC и fasm (make_listfs легко скомпилируется и запустится в виде Windows-приложения).
Примечание для пользователей ОС Windows
Заодно уберите строку OUTPUT_FORMAT("binary") из script.ld. Теперь и под Windows получится собрать ядро системы.
Загрузка системы на реальной машине
После таких успехов у некоторых может возникнуть желание опробовать новую ОС на реальном железе. Это не представляет проблем. С помощью HxD в Windows откройте дискету или флешку, выбрав вариант "Открыть диск". При открытии флешки важно открыть именно саму флешку, а не её раздел. В другой вкладке откройте disk.img, выделите его содержимое полностью и скопируйте на диск с его самого начала. После этого можно нажать "Сохранить" и дождаться окончания записи. Все данные на флешке или дискете при этом будут уничтожены, а для того, чтобы её использовать снова по назначению, её придётся заново отформатировать!
Пользователи Linux могут поступить проще - выполнить специальную команду в терминале. Для дискеты:
Вместо sdX надо подставить настоящее имя устройства (sda, sdb, sdc, sdd и т. д.). Главное при этом не перепутать и не записать образ на системный диск, уничтожив все данные. Разумеется, обе команды должны выполняться от имени root или с помощью sudo.
После этого надо настроить в BIOS загрузку с дискеты или флешки (старые BIOS не поддерживают флешки) и наслаждаться видом "Hello world".
Читайте также: