Как сделать свою операционную систему
Практически все существующие операционные системы общего пользования базируются на малом количестве технологий, развиваемых десятки лет. Сходу на ум приходит лишь два широких направления - "Windows" и "nix". Да, "МакОСЬ" — это тоже "nix", у них и сертификат есть. И "Android - nix", как и любой "Linux".
Конечно, различия между ними уже порой настолько сильны, что о совместимости кода не может идти и речи, и их правомочно считать радикально разными ОС, но можно ли создать и выпустить на рынок, действительно, нечто новое, не имеющее в своём коде ничего из былого?
"MenuetOS" , и отделившаяся от неё позже "KolibriOS" ( Википедия , Голос , сайт ) - написаны с нуля на ассемблере, их живые образы помещаются на одну дискету и не требуют установки. Эти ОС могут быть запущены на любой машине архитектуры x86 и могли бы развиваться до уровня операционных систем общего пользования. Изначально "MenuetOS" разрабатывался с одной целью - уместить на дискету операционную систему с графическим интерфейсом, набором программ и драйверами для стандартного оборудования. Разработчикам это удалось. Эти ОС запускаются и работают практически мгновенно, поскольку полностью находятся в оперативной памяти после запуска, а в современных системах их можно хранить даже в кэше процессора. Запустите "KolibriOS", и ваша жизнь никогда не станет прежней. Под её управлением даже ископаемый компьютер 20-25-летней давности будет работать на порядки быстрее, чем современная игровая станция, которая стоит, как три почки.
Так почему же?
Что самое главное в операционной системе? Нет, не ядро. Ни драйверы, и даже не оптимизация с отсутствием ошибок. По сути ничего. Главное достоинство любой операционной системы в её комплект не входит, потому что самое главное — это парк приложений. Если вы хотите, чтобы ваша ОС жила, то приложения для неё должны, мало того, что охватывать 100% потребностей пользователей (при охвате 99,9% ОС обречена на провал), но ещё и присутствовать в репозиториях в нескольких вариантах для одних и тех же нужд, желательно от нескольких разработчиков.
Если для "KolibriOS" начнут массово разрабатывать приложения, она вместе с ними вынуждена будет обосноваться на медленных накопителях, и тогда о её космических скоростях придётся забыть, поэтому "KolibriOS" вместе с "MenuetOS" так и остаются лишь в качестве развлечения, хотя их и пытались позиционировать, как ОС для разработки программ на ассемблере, но, увы, разработчики не заинтересовались (ещё бы, под другими ОС инструментарий гораздо шире).
В отличие от десктопных операционных систем, мобильные развиваются гораздо меньшее время, но гораздо более стремительно, отчего в их полку больше наглядных примеров, которые и будут рассмотрены в следующей части.
Приветствую всех своих читателей!
Предыдущие выпуски могли быть несколько запутанными. Начальная загрузка, 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".
Чтобы понять, как создать свою операционную систему для телефона, нужно быть основательно подготовленным. Ведь операционная система для смартфона входит в область сложнейших задач по программированию, так как требует довольно обширных знаний, связанных не только с конкретным языком программирования.
Как создать свою операционную систему для телефона
Операционная система для телефона — это комплексное программное обеспечение, работающее непосредственно с системными ресурсами телефона, плю с является связующим звеном между телефоном и его пользователем. ОС полностью контролирует работу устройства, поэтому любая написанная программа пишется не под конкретное устройство, а под конкретную ОС.
Из чего состоит ОС телефона
Что необходимо знать, чтобы создать свою операционную систему для телефона
Основы информатики. Сюда входит понимание таких вещей , как: алгоритмы, структуры данных, сортировка, манипулирование данными, абстрактное программировани е и мн. др.
Английский язык на хорошем уровне. На русском языке очень мало технической документации по созданию операционных систем для телефонов — в основном все на английском. Это же касается и сообществ, которые могут вам помочь — все это только на английском. Помимо английского для общени я важен технический английский, чтобы вы могли понимать о чем идет речь в документации, а также правильно формулировать свои вопросы в сообществах.
Язык программирования. Большинство операционных систем используют язык программирования С или С++, поэтому знать эти языки нужно будет в любом случае. Даже если решите создавать свою ОС на другом языке , примеры в документации и большинство готовых фрагментов кода будут именно на этом языке.
Ассемблер. Даже если вы будете писать свою ОС на языке высокого уровня, то местами вам все равно придется применять Ассемблер, поэтому понимание и основы этого языка обязательны.
Опыт в программировании. Если создание своей операционной системы для телефона — это первый ваш проект, то это довольно плохая идея. Вам кроме самого языка программирования нужно еще понимать как осуществляется контроль версий, отладка, оптимизация кода и мн. др.
Много практики на языке, который хотите применять для создания сво е й операционной системы. Язык не должен быть для вас чем-то новым. Необходимо знать его тонкости и особенности, поэтому на этом языке у вас должно быть реализовано несколько успешных проектов.
Понимание UNIX. Начав работу над свое й операционной системой для телефон а, вы очень быстро осознаете, что основной инструмент создания ОС тянется еще с UNIX-систем, а за основу ОС очень часто берется ядро Linux.
Концепция операционных систем. Вы должны в общем понимать, как с технической стороны работают операционные системы на телефонах.
И др.
Разработка операционной системы для телефона
Заключение
Как разработать свою операционную систему для телефона? Нужно основательно подготовит ь ся и быть готовым к очень продолжительной работе над своим программным продуктом. Разработка собственной ОС для телефона — это очень сложная задача, но даже она посильна, если есть должное желание и упорство для мотивации к работе.
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Привет, друзья. Мы продолжаем обзор возможностей одной примечательной программы, Mast Have для системщиков и энтузиастов - Dism++. Эта статья будет своего рода кульминацией всего цикла публикаций об этой программе: в ней мы рассмотрим, как с помощью Dism++ создать свою сборку Windows. А свою сборку Windows с помощью этой программы можно создать легко и просто. Нам не нужно будет никаких виртуальных машин для создания эталонного образа системы, никаких установочных или Live-дисков для захвата образа, никаких командных строк. Мы с помощью Dism++ создадим эталонный образ Windows для сборки в файле VHD, настроим его. С помощью той же Dism++ очистим его, применим к нему твики, внедрим обновления. И, опять же, с помощью Dism++ мы захватим образ в файл WIM или ESD и потом запакуем его в установочный ISO.
↑ Как создать свою сборку Windows с помощью программы Dism++
Итак, мы хотим создать свою сборку Windows 7, 8.1 или 10. Нам для этого понадобятся:
• Установочный ISO-образ нужной версии и редакции Windows,
• Штатное управление дисками.
↑ Создание виртуального диска VHD
Чтобы создать свою сборку Windows, нам нужно установить новую операционную систему. И на её базе сформировать эталонный образ Windows – систему без пользовательских профилей, но с внесёнными необходимыми настройками, установленными системными компонентами, обновлениями и программами. И такой вот эталонный образ мы создадим на виртуальном диске VHD. Жмём клавиши Win+R, вводим:
Указываем расположение файла VHD виртуального диска, его размер и тип. Я укажу небольшой размер – 30 Гб и выберу тип динамический. После создания своей сборки мы удалим виртуальный диск, так что все эти параметры особого значения не имеют.
После создания виртуального диска инициализируем его.
Выбираем стиль разделов диска такой, как и у физических дисков компьютера, у меня это GPT.
Из пустого места проинициализированного виртуального диска создаём обычный NTFS-раздел.
И вот итог: у нас должен получиться в системе лишний диск с единственным разделом под эталонную Windows.
↑ Установка эталонной Windows на VHD-диск
Далее ждём завершения процесса копирования файлов новой Windows. Прогресс можем отслеживать вверху окна, в блоке с новой системой.
Эталонный образ установлен, далее можем перезагружаться, проходить этап установки драйверов и входить в учётную запись администратора для внесения изменений в систему. Но, друзья, я предлагаю немного задержаться и опробовать оптимизирующие возможности Dism++. Некоторые настройки эталонного образа мы можем провести с помощью программы в пару кликов, в едином интерфейсе, не запуская даже новую Windows.
↑ Настройка эталонной Windows с помощью Dism++
Dism++ - это комплексный чистильщик, оптимизатор и твикер любых системных образов – как развёрнутых на диске, т.е. установленных рабочих систем, так и смонтированных для редактирования дистрибутивов. Как мы можем настроить нашу эталонную Windows с помощью программы?
Примечание: друзья, обращаю ваше внимание - при проведении операций с эталонным образом Windows в программе Dism++ не забывайте первично переключаться вверху окна на нужный образ. Это должен быть синий блок с установленной на диск VHD системой, а не система, установленная на диске С. Не упустите этот нюанс.
↑ Настройка эталонной Windows в среде её самой
После предварительной настройки эталонного образа Windows с помощью Dism++ можем приступать к работе по настройке образа внутри самой системы. Перезагружаем компьютер и в меню выбора Windows выбираем ту, что установлена в VHD-файле. В моём случае на компьютере теперь установлено две Windows 8.1, и эталонная значится как Windows 8.1 на томе 6.
Наша эталонная Windows запустится, установит себе драйверы, затем на этапе создания пользовательского профиля мы должны войти во встроенную учётную запись администратора. Жмём клавиши Ctrl+Shift+F3.
↑ Чистка эталонной Windows
После перезагрузки в меню загрузки выбираем нашу рабочую систему, в моём случае это Windows 8.1 на томе 3.
В моём случае при очистке был высвобожден значительный вес данных.
↑ Захват эталонной Windows в файл WIM или ESD
Указываем путь сохранения, имя файла – install. И выбираем тип файла из числа предлагаемых нам вариантов: несжатый, сжатый образ, быстрое сжатие – всё это файлы разного уровня сжатия формата WIM, а ультрасжатие – это формат ESD. Я выберу последний, чтобы он занимал как можно меньше места. Но, друзья, знайте, что при выборе ультрасжатия в файл ESD процесс захвата образа будет длиться в разы дольше, чем при выборе сжатого файла WIM.
И дожидаемся завершения процесса захвата, т.е. создания файла install.wim или install.esd. У меня последний, кстати, вышел весом всего лишь 2,34 Гб. При этом в эталонный образ я внедрил четыре сторонние программы.
↑ Создание установочного ISO
Наконец, последний этап всего этого действа – упаковка файла WIM или ESD назад в установочный ISO. И этот процесс мы также поручим программе Dism++. Но прежде нам нужно извлечь содержимое исходного установочного ISO, который мы использовали для установки эталонной Windows, в папку. В обычную папку с любым названием. Подключаем ISO для отображения в системе.
Дожидаемся завершения.
И всё – наша собственная сборка Windows создана. Папку с любым названием можем удалить.
↑ Удаление эталонной Windows на VHD-диске
Теперь, друзья, нам осталось, так сказать, убрать своё рабочее место – удалить нашу эталонную Windows, установленную на VHD-диске. Если она, конечно, не нужна вам, скажем, для экспериментов. Жмём клавиши Win+R, вводим:
Далее идём в управление дисками Windows и отсоединяем виртуальный диск.
Последний шаг – удаление его файла VHD.
Хотите улучшить этот вопрос? Переформулируйте вопрос так, чтобы он был сосредоточен только на одной проблеме.
Закрыт 6 лет назад .
Я имею ввиду с нуля. Какие языки программирования нужно знать? В какой программе писать?
И если можно, то поподробнее обо всем этом.
А смысл в создании своей операционной системы? просто такой вопрос - ради опыта или чтоб было? или вообще работать в ней самостоятельно? на это ведь надо убить кучу времени, и не факт что все будет идеально и красиво. вполне много ОС уже существует. Пользовались бы ими
оговорюсь что я не заставляю вас бросить это дело и не называю его гиблым. эо достаточно хороший проект, но смысла как такогого не вижу
Смотря что вы хотите от неё =3 Но, в любом случае, даже если вам нужно простая загрузка и переключение контекста задач (потоков), то читать надо будет много и трудиться тоже .з.
Еще одна ось? Пожалейте подневольных программистов, периодически получающих инструкцию "чтоб работало под виндой, линухом и макосью")
(1) И сколько подневольных программистов стонут под какой-нибудь MenuetOS. (2) Есть область, где новые операционки, хотя и весьма небольшие, появляются достаточно часто - микроконтроллеры.
Если подходить по существу.
Ещё ОС, ежели имеется долговременная память, должна предоставлять доступ к ней: то есть предоставлять все функции для работы с файловой системой. Это минимум.
Далее. Платформа. От неё зависят инструменты, кои понадобятся для разработки ОС. Некоторые платформы: x86, x86-64, ARM, ну и куча других.
Почти везде самый первый загрузочный код должен писаться на ассемблере - там бывает куча правил, где оно должно быть, как должно выглядеть, что должно делать, и какой размер не превышать.
Для РС надо на асме писать бутлоадер, который будет вызываться BIOS и кой должен, не превышая четырёх с копейками сотен байт, что-то сделать и запустить основную ОС - передать управление основному коду, который в ближайшей же перспективе можно писать уже и на С.
Для ARM надо на асме делать таблицу прерываний (сброс, ошибки разные, прерывания IRQ, FIQ и пр.) и передачу управления в основной код. Хотя, во многих средах разработки такой код для почти любого контроллера имеется.
То есть, необходимо для этого:
- Знать ассемблер целевой платформы.
- Знать архитектуру процессора и всякие служебные команды и регистры, чтобы настроить его для работы в нужном режиме. В РС это переход в защищённый режим, например, или в 64битный режим. В ARM - настройка тактирования ядра и периферии.
- Знать, как именно будет запускаться ОС, куда и как нужно пихать свой код.
- Знать язык С - большой код на асме написать затруднительно без опыта, поддерживать его будет ещё труднее. Посему надо ядро писать на С.
- Знать принципы работы ОС. Ну, книжек на русском языке по этой теме много всяких, правда, не знаю, все ли они хорошие.
- Иметь много-много терпения и усидчивости. Ошибки будут и их надо будет искать и исправлять. А ещё надо будет очень много читать.
- Иметь много-много времени.
Далее. Допустим, вы что-то написали. Надо это дело тестировать. Либо надо устройство физическое, на коем будут идти эксперименты (отладочная плата, второй компьютер), либо эмулятор его. Второе обычно использовать и проще, и быстрее. Для PC, например, VMWare.
Статей по этой теме в интернете тоже достаточно, если хорошо поискать. А также есть множество примеров готовых ОС с исходниками.
Даже можно при большом желании посмотреть исходники старого ядра NT-систем (Windows), как отдельно (кое микрософтом выложено, с комментариями и разного рода справочными материалами), так и в совокупности со старыми же ОС (утекло).
Читайте также: