Своя ос на основе windows

Создание собственной операционной системы — это захватывающий процесс, который позволяет вам полностью контролировать функциональность и внешний вид вашего компьютера. Операционная система Windows является одной из самых популярных и широко используемых в мире, поэтому многие люди мечтают создать свою ОС на ее основе. В этой статье мы расскажем вам, как начать создание своей операционной системы на основе Windows.

Первым шагом в создании собственной операционной системы является определение ее основных функций и характеристик. Вы должны решить, какие приложения и сервисы вы хотите предоставить пользователям, а также учесть различные требования к безопасности и совместимости.

После определения основных функций вашей ОС, вы можете начать разрабатывать ее архитектуру и дизайн. В этом шаге вы будете принимать решения о структуре файловой системы, интерфейсе пользователя и многих других аспектах ОС. Также полезно изучить существующие операционные системы и использовать их как основу для создания своей собственной ОС на основе Windows.

Не забудьте, что создание операционной системы требует глубоких знаний программирования и разработки. Вы должны быть готовым изучать новые технологии и языки программирования, такие как C++ или C#, а также изучить документацию и учебники о разработке ОС на базе Windows.

Когда ваша операционная система будет разработана и протестирована, вы можете начать ее установку и настройку на целевых компьютерах. Убедитесь, что вы следуете инструкциям для установки операционной системы и подготовьте все необходимые драйверы и программы для полноценной работы ОС. После этого вы можете начать распространение и поддержку вашей собственной ОС на основе Windows.

В заключение, создание своей операционной системы на основе Windows — это сложный, но увлекательный процесс. Он требует множества усилий, но может принести много удовлетворения и успеха. Удачи в воплощении ваших идей и создании собственной операционной системы!

Как разработать собственную операционную систему на базе Windows

Создание собственной операционной системы на базе Windows может быть сложным, но увлекательным проектом для программистов и разработчиков. В этой статье мы рассмотрим основные шаги, необходимые для разработки такой системы.

1. Определение функций и требований операционной системы:

Первый и самый важный шаг – определение функций и требований вашей операционной системы. Необходимо решить, какие функции и возможности должна иметь ваша ОС, чтобы она могла успешно конкурировать с существующими системами.

2. Создание ядра операционной системы:

Ядро операционной системы – это основная часть, которая управляет ресурсами компьютера и обеспечивает работу приложений. Необходимо разработать ядро, которое будет подходить под заданные требования и функции вашей операционной системы.

3. Разработка пользовательского интерфейса:

Пользовательский интерфейс (UI) – это то, с чем будет взаимодействовать пользователь. Разработайте удобный и интуитивно понятный интерфейс, чтобы пользователи могли легко находить и использовать необходимые функции операционной системы.

4. Разработка приложений и драйверов:

Для того чтобы ваша операционная система была полезна и функциональна, вам потребуется разработать приложения и драйверы. Это могут быть текстовые редакторы, браузеры, мультимедийные плееры и другие приложения, а также драйверы, необходимые для поддержки аппаратуры.

5. Тестирование и отладка:

Перед выпуском своей операционной системы необходимо провести тестирование и отладку для обнаружения и исправления проблем и ошибок. Обязательно проверьте все функции и приложения вашей ОС, чтобы убедиться, что они работают корректно и стабильно.

6. Дистрибуция и обновления:

Когда ваша операционная система готова к использованию, необходимо разработать стратегию дистрибуции и предоставить пользователям возможность установки и обновления системы. Разработайте механизмы автоматических обновлений, чтобы обеспечить безопасность и стабильность вашей ОС.

В заключение, создание собственной операционной системы на базе Windows – это сложный и трудоемкий процесс, который требует знаний и навыков программирования и разработки. Однако, такой проект может быть наградой для тех, кто увлечен созданием собственного продукта и хочет принести что-то новое и инновационное на рынок операционных систем.

Подготовка к разработке системы

Перед началом разработки операционной системы на основе Windows необходимо провести ряд подготовительных этапов:

1. Ознакомиться с архитектурой Windows: изучить основные компоненты системы, понять, как они взаимодействуют между собой.
2. Изучить программные средства разработки для операционных систем Windows: Microsoft Visual Studio, Windows Driver Kit и т.д. Они позволят создавать драйвера и приложения для новой системы.
3. Определить требования и функциональность будущей операционной системы. Разработать детальное техническое задание, в котором прописать все необходимые функции и возможности.
4. Изучить документацию и ресурсы по разработке операционных систем Windows. Microsoft предоставляет разнообразные руководства и материалы для разработчиков, которые помогут в реализации проекта.
5. Подготовить рабочее окружение: установить необходимые программные средства разработки, настроить компьютер для работы с разработкой операционных систем.
6. Проанализировать и выбрать желаемые компоненты для новой операционной системы, такие как пользовательский интерфейс, файловая система, поддержка сети и т.д.
7. Создать план разработки операционной системы, разбив его на этапы и задачи для удобного управления процессом.

Подготовка к разработке системы является важным шагом, который обеспечит успешное и эффективное создание операционной системы на основе Windows.

Разработка ядра операционной системы

Процесс разработки ядра ОС обычно состоит из нескольких этапов:

1. Анализ требований — определение основных функций и возможностей, которые должен обеспечивать ядро ОС.
2. Проектирование архитектуры — разработка структуры и организация компонентов ядра ОС.
3. Написание кода — создание программного кода, реализующего функциональность ядра ОС.
4. Тестирование и отладка — проверка работоспособности и исправление ошибок в ядре ОС.

При разработке ядра ОС на основе Windows можно использовать специальные инструменты и фреймворки, такие как Windows Driver Kit (WDK) и Windows Internals. WDK предоставляет набор инструментов и библиотек для разработки драйверов и ядерных компонентов ОС. Windows Internals предлагает информацию о внутреннем устройстве Windows и помогает разработчикам понять, как работает операционная система.

Разработка ядра операционной системы — это сложный процесс, который требует углубленных знаний и опыта в программировании и операционных системах. Однако, с правильным подходом и использованием соответствующих инструментов, можно создать собственное ядро ОС на базе Windows.

Создание графического интерфейса и приложений

Одним из основных инструментов для создания графического интерфейса в операционной системе Windows является Windows Presentation Foundation (WPF). WPF предоставляет разработчикам широкий набор инструментов и возможностей для создания интерактивных и стильных пользовательских интерфейсов.

Для создания приложений на основе WPF необходимо знание языка программирования C# и платформы .NET. C# является одним из основных языков программирования в Windows и обладает широким набором библиотек и фреймворков для разработки приложений.

1. Первым шагом при создании графического интерфейса является определение структуры приложения. Это включает в себя создание различных элементов интерфейса, таких как окна, кнопки, текстовые поля и многое другое.
2. Затем необходимо настроить взаимодействие между элементами интерфейса и функциональностью приложения. Например, при нажатии на кнопку должно выполняться определенное действие.
3. Для стилизации интерфейса можно использовать различные техники, такие как использование графических ресурсов, шаблонов и стилей. Это помогает создать красивый и современный внешний вид приложения.
4. Для улучшения опыта пользователя можно использовать анимацию и переходы между различными экранами. Это добавляет интерактивности и делает приложение более привлекательным для пользователей.
5. После создания графического интерфейса необходимо связать его с функциональностью приложения. Для этого можно использовать обработчики событий и вызывать соответствующие методы при взаимодействии пользователя с интерфейсом.

Создание графического интерфейса и приложений в операционной системе Windows требует определенных навыков и понимания основных принципов разработки приложений. Однако, с помощью правильных инструментов и подхода вы сможете создать интерфейс, который будет удобен и привлекателен для пользователей.

Привет, друзья. Мы продолжаем обзор возможностей одной примечательной программы, Mast Have для системщиков и энтузиастов — Dism++. Эта статья будет своего рода кульминацией всего цикла публикаций об этой программе: в ней мы рассмотрим, как с помощью Dism++ создать свою сборку Windows. А свою сборку Windows с помощью этой программы можно создать легко и просто. Нам не нужно будет никаких виртуальных машин для создания эталонного образа системы, никаких установочных или Live-дисков для захвата образа, никаких командных строк. Мы с помощью Dism++ создадим эталонный образ Windows для сборки в файле VHD, настроим его. С помощью той же Dism++ очистим его, применим к нему твики, внедрим обновления. И, опять же, с помощью Dism++ мы захватим образ в файл WIM или ESD и потом запакуем его в установочный ISO.

Примечание: друзья, если вы являетесь истинным гурманом в сфере создания собственных сборок Windows и ищите свой идеальный способ их создания, загляните сюда — в раздел публикаций, где собрано воедино множество различных способов создания собственного настроенного дистрибутива. Или можете юзать тег «Своя сборка Windows».

Итак, мы хотим создать свою сборку Windows 7, 8.1 или 10. Нам для этого понадобятся:

•    Установочный ISO-образ нужной версии и редакции Windows,

•    Программа Dism++,

•    Штатное управление дисками.

Чтобы создать свою сборку Windows, нам нужно установить новую операционную систему. И на её базе сформировать эталонный образ Windows – систему без пользовательских профилей, но с внесёнными необходимыми настройками, установленными системными компонентами, обновлениями и программами. И такой вот эталонный образ мы создадим на виртуальном диске VHD. Жмём клавиши Win+R, вводим:

diskmgmt.msc 

И запускаем системное управление дисками. В нём жмём «Действие», затем – «Создать виртуальный жёсткий диск».

Указываем расположение файла VHD виртуального диска, его размер и тип. Я укажу небольшой размер – 30 Гб и выберу тип динамический. После создания своей сборки мы удалим виртуальный диск, так что все эти параметры особого значения не имеют.

После создания виртуального диска инициализируем его.

Выбираем стиль разделов диска такой, как и у физических дисков компьютера, у меня это GPT.

Из пустого места проинициализированного виртуального диска создаём обычный NTFS-раздел.

И вот итог: у нас должен получиться в системе лишний диск с единственным разделом под эталонную Windows.

Теперь нам нужно установить на этот VHD-диск Windows, которую мы настроим под эталонный образ своей сборки. Запускаем программу Dism++. Жмём «Файл», потом — «Применить образ».

В графе «Введите путь к файлу образа» с помощью кнопки обзора указываем путь к установочному ISO-образу Windows. Я, например, буду использовать установочный ISO Windows 8.1 сборки AIO by Sergei Strelec, это сборка на базе чистого образа Microsoft с вырезанными Modern UI приложениями. В графе «Система» указываем редакцию устанавливаемой Windows.

Далее в последней графе указываем тот раздел, который мы создали на виртуальном диске. ставим галочку «Доб.загр.». И жмём «Ок». Важно: друзья, если вы, возможно, выберете вариант с установкой эталонного образа Windows не в файл VHD, а на другой раздел диска, то, если такой раздел имеет данные, ставьте ещё галочку «Формат».

Далее соглашаемся с внесением новой системы в меню загрузки. Если у вас несколько дисков с загрузчиками, тогда жмите кнопку «Больше» и укажите программе Dism++ правильный диск и раздел загрузчика.

Далее ждём завершения процесса копирования файлов новой Windows. Прогресс можем отслеживать вверху окна, в блоке с новой системой.

По завершении жмём «Ок».

Эталонный образ установлен, далее можем перезагружаться, проходить этап установки драйверов и входить в учётную запись администратора для внесения изменений в систему. Но, друзья, я предлагаю немного задержаться и опробовать оптимизирующие возможности Dism++. Некоторые настройки эталонного образа мы можем провести с помощью программы в пару кликов, в едином интерфейсе, не запуская даже новую Windows.

Dism++ — это комплексный чистильщик, оптимизатор и твикер любых системных образов – как развёрнутых на диске, т.е. установленных рабочих систем, так и смонтированных для редактирования дистрибутивов. Как мы можем настроить нашу эталонную Windows с помощью программы?

Примечание: друзья, обращаю ваше внимание — при проведении операций с эталонным образом Windows в программе Dism++ не забывайте первично переключаться вверху окна на нужный образ. Это должен быть синий блок с установленной на диск VHD системой, а не система, установленная на диске С. Не упустите этот нюанс.

И первым делом мы заглянем в раздел Dism++ «Управление загрузкой». Здесь при необходимости можем сделать предустановки для запуска системных служб. Если вы хотите, чтобы ваша сборка была с выключенными некоторыми службами, можете отключить их запуск.

Далее можем зайти в раздел «Оптимизация». Здесь собраны твики по настройке отдельных параметров Windows. Я воспользуюсь этой удобной возможностью Dism++ и внесу пару корректировок в оформление системы и отключу Защитник. Если у вас есть свои твики в виде Reg-файлов реестра, вы можете импортировать их.

Если вы хотите пакетно удалить современные приложения из Windows 8.1 или 10, убрать или, наоборот, добавить какие-то системные компоненты, загляните в раздел программы «Приложения и возможности».

Для интеграции обновлений в эталонный образ Windows, заходим в раздел «Обновления». Жмём кнопку «Анализ», дожидаемся появления перечня обновлений. Галочками отмечаем обновления, которые хотим установить. И жмём кнопку «Установить».

После предварительной настройки эталонного образа Windows с помощью Dism++ можем приступать к работе по настройке образа внутри самой системы. Перезагружаем компьютер и в меню выбора Windows выбираем ту, что установлена в VHD-файле. В моём случае на компьютере теперь установлено две Windows 8.1, и эталонная значится как Windows 8.1 на томе 6.

Наша эталонная Windows запустится, установит себе драйверы, затем на этапе создания пользовательского профиля мы должны войти во встроенную учётную запись администратора. Жмём клавиши Ctrl+Shift+F3.

Входим.И настраиваем эталонную Windows – вносим настройки, устанавливаем сторонний софт. При входе в учётную запись администратора у нас по умолчанию будет запущено окно программы подготовки системы, она же утилита Sysprep для сброса привязки эталонной Windows к комплектующим компьютера, на котором сейчас она установлена. Если надо установить какие-то программы, которые требуют перезагрузки Windows, то такую перезагрузку необходимо проводить только через окно Sysprep. С выставлением в качестве действия «Переход в режим аудита системы», а в качестве завершения работы – соответственно, «Перезагрузка».

По завершении всех настроек Windows в окне Sysprep в качестве действия указываем «Переход в окно приветствия (OOBE)». Ниже отмечаем галочкой «Подготовка к использованию». В качестве действия оставляем «Перезагрузка». Жмём «Ок».

После перезагрузки в меню загрузки выбираем нашу рабочую систему, в моём случае это Windows 8.1 на томе 3.

Далее будем проводить чистку эталонного образа, это уменьшит размер файла образа сборки Windows. Запускаем Dism++. Идём в раздел «Очистка». Жмём кнопку «Анализ». Ждём, пока программой будут выявлены данные для очистки. Потом жмём кнопку «Очистка».

В моём случае при очистке был высвобожден значительный вес данных.

Теперь можем упаковывать эталонную Windows — делать её захват в файл WIM или ESD. В окне Dism++ жмём «Файл», далее – «Сохранить образ как». Жмём кнопку обзора.

Указываем путь сохранения, имя файла – install. И выбираем тип файла из числа предлагаемых нам вариантов: несжатый, сжатый образ, быстрое сжатие – всё это файлы разного уровня сжатия формата WIM, а ультрасжатие – это формат ESD. Я выберу последний, чтобы он занимал как можно меньше места. Но, друзья, знайте, что при выборе ультрасжатия в файл ESD процесс захвата образа будет длиться в разы дольше, чем при выборе сжатого файла WIM.

Путь, имя и тип файла захвата определены, жмём «Ок».

И дожидаемся завершения процесса захвата, т.е. создания файла install.wim или install.esd. У меня последний, кстати, вышел весом всего лишь 2,34 Гб. При этом в эталонный образ я внедрил четыре сторонние программы.

Наконец, последний этап всего этого действа – упаковка файла WIM или ESD назад в установочный ISO. И этот процесс мы также поручим программе Dism++. Но прежде нам нужно извлечь содержимое исходного установочного ISO, который мы использовали для установки эталонной Windows, в папку. В обычную папку с любым названием. Подключаем ISO для отображения в системе.

Друзья, если вы работаете в среде Windows 7, для подключения ISO вам нужно использовать сторонние программы типа UltraISO или Daemon Tools. Далее заходим на подключённый ISO. И копируем на нём все папки, кроме «sources».

Вставляем всё это в созданной папке с любым названием. В этой папке создаём новую папку с названием «sources».

Возвращаемся на подключённый ISO, заходим в папку «sources», делаем в проводнике вид данных таблицей, сортируем по размеру. И копируем все файлы, кроме install.wim или install.esd.

Вставляем эти файлы в пустой папке «sources» внутри папки с любым названием.

И теперь сюда же, в папку «sources» внутри папки с любым названием помещаем файл install.wim или install.esd, который мы на предыдущем этапе создали в процессе захвата образа эталонной Windows.

Теперь в программе Dism++ идём в раздел «Дополнительно». Кликаем «Создание ISO». Указываем в первой графе ту самую папку с любым названием, во второй – путь и имя файла ISO на выходе, в третьей – метку ISO (метку диска). Жмём «Ок».

Дожидаемся завершения.

И всё – наша собственная сборка Windows создана. Папку с любым названием можем удалить.

Теперь, друзья, нам осталось, так сказать, убрать своё рабочее место – удалить нашу эталонную Windows, установленную на VHD-диске. Если она, конечно, не нужна вам, скажем, для экспериментов. Жмём клавиши Win+R, вводим:

msconfig

Идём в раздел «Загрузка» в окне запустившейся конфигурации системы. Кликаем запись о загрузке Windows на VHD-диске. Жмём «Удалить», потом – «Применить», потом – «Ок». На предложение о перезагрузке можем отказаться.

Далее идём в управление дисками Windows и отсоединяем виртуальный диск.

Последний шаг – удаление его файла VHD.

Здравствуйте!
В последнее время читаю новости вижу заголовки: «Гугл и эпл объединились для сознания новой ос на Unix», «Nokia и Intel объединились для создания ос Meego OS на базе ядра Linux», «андроид одна из лучших мобильных ос на ядре Linux», «дистрибутив linux». А почему нет фраз: «дистрибутив Windows», «»многие производители ноутбуков пытаются кастомизировать Windows», хотя «многие производители телефонов пытаются кастомизировать android для уникального внешнего вида»»?! Как можно написать свою ос на базе ядра DOS, Windows или на ОС Windows?! Как установить другую графическую оболочку на Windows?
Помогите, пожалуйста, без игнора!
Всем спасибо за ваши ответы заранее!!!

• 
  Вопрос задан
  
  более трёх лет назад
  

• 1075 просмотров

Многие пользователи компьютеров, особенно разработчики и энтузиасты, мечтают создать собственную операционную систему на основе Windows. При этом они хотят иметь полный контроль над процессом разработки и настройки ОС, чтобы она полностью соответствовала их потребностям и предпочтениям.

Создание собственной ОС на основе Windows может показаться сложной задачей, но с правильным подходом и инструкцией это становится возможным. В этой статье мы предлагаем вам подробную инструкцию, которая поможет вам создать собственную ОС на основе Windows.

Шаг 1: Подготовка

Перед тем как приступить к созданию ОС, вам потребуется подготовить несколько вещей. Во-первых, вам нужно будет установить необходимые программы и инструменты для разработки операционной системы. Во-вторых, вам понадобятся знания программирования и архитектуры операционных систем.

Важно помнить, что создание собственной ОС требует определенных навыков и понимания технологий. Если у вас нет опыта в программировании или разработке операционных систем, вам, возможно, придется потратить дополнительное время и усилия на изучение этих тем.

Также стоит отметить, что создание ОС на основе Windows не является официальным способом сделать собственную версию Windows. Официальное разработчики разрешение от Microsoft требуется для создания и распространения операционной системы, основанной на Windows.

В следующей статье мы рассмотрим основные шаги для создания ОС на основе Windows и предоставим дополнительные советы и рекомендации для успешного развития проекта.

Создание собственной операционной системы на базе Windows предоставляет широкие возможности для разработчиков. Это позволяет адаптировать ОС под свои нужды, добавлять нужные компоненты, устанавливать индивидуальные настройки и многое другое.

Среди основных возможностей создания собственной ОС на базе Windows можно выделить:

1. Индивидуальная настройка. Вы можете настроить операционную систему под собственные потребности и предпочтения. Это включает в себя установку нужных программ, настройку параметров работы системы, добавление и удаление компонентов и многое другое.

2. Добавление компонентов. Вы можете расширить функциональность ОС путем добавления собственных компонентов. Это может быть программное обеспечение, драйверы для устройств, расширения интерфейса и другие компоненты, которые помогут вам реализовать требуемый функционал.

3. Создание собственных инсталляторов. Вы можете создавать свои собственные инсталляторы для установки ОС на другие компьютеры. Это позволит вам устанавливать вашу ОС на различные устройства и распространять ее среди других пользователей.

4. Адаптация под разные платформы. Создавая собственную операционную систему на базе Windows, вы можете адаптировать ее под различные платформы. Это позволяет использовать вашу ОС на разных устройствах – от персональных компьютеров до мобильных устройств и других встраиваемых систем.

Данные возможности позволяют разработчикам полностью контролировать и адаптировать операционную систему под собственные потребности и задачи. Создание собственной ОС на базе Windows требует определенных знаний и навыков, но с помощью документации и различных инструментов это становится возможным.

Необходимые навыки и инструменты для разработки ОС

Необходимые навыки

1. Знание языка программирования. Для разработки операционной системы на основе Windows необходимо обладать хорошими навыками программирования. Самыми распространенными языками программирования для разработки ОС являются C и C++. Знание этих языков позволит вам писать системные программы и взаимодействовать с ядром операционной системы.

2. Понимание архитектуры компьютера. Для успешной разработки ОС необходимо иметь представление об архитектуре компьютера и уметь работать с регистрами, памятью и драйверами устройств. Также полезно знать основы сетевых протоколов и файловых систем, которые используются в операционной системе Windows.

3. Навыки отладки программ. Разработка операционной системы — это сложный процесс, который часто включает в себя отладку и исправление ошибок. Поэтому необходимо обладать навыками отладки программ на низком уровне, уметь пользоваться отладчиками и анализаторами кода.

4. Знание системного программирования. Разработка ОС на основе Windows требует понимания основ системного программирования, таких как работа с процессами, потоками, синхронизации, памятью и файлами. Особое внимание следует уделить работе с драйверами устройств, так как они являются важным компонентом ОС.

Необходимые инструменты

1. Компилятор C/C++. Для разработки ОС на основе Windows необходимо иметь компилятор, поддерживающий языки C и C++. Рекомендуется использовать Microsoft Visual Studio, так как он предоставляет богатые возможности и инструменты для разработки под Windows.

2. Отладчик. Отладчик — это инструмент, который позволяет отслеживать выполнение программы и искать ошибки. В качестве отладчика можно использовать встроенные средства разработки, такие как отладчик Visual Studio или WinDbg.

3. Документация Windows API. Windows API — это набор функций и интерфейсов, предоставляемых операционной системой Windows. Документация Windows API содержит информацию о доступных функциях и их использовании. Рекомендуется ознакомиться с документацией Microsoft Developer Network (MSDN).

4. Виртуальная машина. Для тестирования разработанной ОС рекомендуется использование виртуальной машины, такой как VMware или VirtualBox. Виртуальная машина позволяет создать виртуальное окружение, на котором можно запустить и тестировать разработанную ОС без воздействия на основную операционную систему.

5. Редактор кода. Для написания и редактирования кода операционной системы рекомендуется использовать редактор кода с подсветкой синтаксиса и другими функциями, облегчающими написание кода. Популярными редакторами кода являются Visual Studio Code, Sublime Text и Notepad++.

Используя указанные навыки и инструменты, вы сможете разработать операционную систему на основе Windows и продвинуться в данной области IT-разработки.

Выбор подходящей версии Windows для создания операционной системы

При создании операционной системы на базе Windows необходим выбор подходящей версии данной ОС. Каждая версия Windows имеет свои особенности, возможности и ограничения, поэтому важно выбрать версию, которая наилучшим образом соответствует требованиям и целям создания вашей операционной системы.

Существует несколько версий Windows, которые могут быть использованы для создания операционной системы:

1. Windows 10 – самая современная и распространенная версия операционной системы от Microsoft. Она обладает широким набором функций и возможностей, таких как поддержка DirectX 12, расширенные возможности безопасности, а также интеграция с облачными сервисами. Однако Windows 10 может потребовать больше системных ресурсов, чем предыдущие версии.

2. Windows 8.1 – предшественник Windows 10, который также обладает некоторыми современными функциями и возможностями, но не настолько распространен, как его последняя версия. Если ваша операционная система будет предназначена для использования на устройствах с ограниченными ресурсами, Windows 8.1 может быть более подходящим вариантом.

3. Windows 7 – классическая версия Windows, которая до сих пор широко используется многими организациями и пользователями. Windows 7 имеет надежную стабильность и совместимость с различным программным обеспечением, но не может предложить все новые функции и возможности, доступные в Windows 10.

Выбор версии Windows для создания операционной системы зависит от ваших потребностей, целей и ограничений, поэтому рекомендуется внимательно изучить каждую версию и выбрать ту, которая наилучшим образом соответствует вашим требованиям.

Данный цикл статей посвящён низкоуровневому программированию, то есть архитектуре компьютера, устройству операционных систем, программированию на языке ассемблера и смежным областям. Пока что написанием занимаются два хабраюзера — iley и pehat. Для многих старшеклассников, студентов, да и профессиональных программистов эти темы оказываются весьма сложными при обучении. Существует много литературы и курсов, посвящённых низкоуровневому программированию, но по ним сложно составить полную и всеохватывающую картину. Сложно, прочитав одну-две книги по ассемблеру и операционным системам, хотя бы в общих чертах представить, как же на самом деле работает эта сложная система из железа, кремния и множества программ — компьютер.

Каждый решает проблему обучения по-своему. Кто-то читает много литературы, кто-то старается поскорее перейти к практике и разбираться по ходу дела, кто-то пытается объяснять друзьям всё, что сам изучает. А мы решили совместить эти подходы. Итак, в этом курсе статей мы будем шаг за шагом демонстрировать, как пишется простая операционная система. Статьи будут носить обзорный характер, то есть в них не будет исчерпывающих теоретических сведений, однако мы будем всегда стараться предоставить ссылки на хорошие теоретические материалы и ответить на все возникающие вопросы. Чёткого плана у нас нет, так что многие важные решения будут приниматься по ходу дела, с учётом ваших отзывов.

Возможно, мы умышленно будем заводить процесс разработки в тупик, чтобы позволить вам и себе полностью осознать все последствия неверно принятого решения, а также отточить на нем некоторые технические навыки. Так что не стоит воспринимать наши решения как единственно верные и слепо нам верить. Еще раз подчеркнём, что мы ожидаем от читателей активности в обсуждении статей, которая должна сильно влиять на общий процесс разработки и написания последующих статей. В идеале хотелось бы, чтобы со временем некоторые из читателей присоединились к разработке системы.

Мы будем предполагать, что читатель уже знаком с основами языков ассемблер и Си, а также элементарными понятиями архитектуры ЭВМ. То есть, мы не будем объяснять, что такое регистр или, скажем, оперативная память. Если вам не будет хватать знаний, вы всегда можете обратиться к дополнительной литературе. Краткий список литературы и ссылки на сайты с хорошими статьями есть в конце статьи. Также желательно уметь пользоваться Linux, так как все инструкции по компиляции будут приводиться именно для этой системы.

А теперь — ближе к делу. В оставшейся части статьи мы с вами напишем классическую программу «Hello World». Наш хеллоуворлд получится немного специфическим. Он будет запускаться не из какой-либо операционной системы, а напрямую, так сказать «на голом железе». Перед тем, как приступить непосредственно к написанию кода, давайте разберёмся, как же конкретно мы пытаемся это сделать. А для этого надо рассмотреть процесс загрузки компьютера.

Итак, берем свой любимый компьютер и нажимаем самую большую кнопочку на системном блоке. Видим веселую заставку, системный блок радостно пищит спикером и через какое-то время загружается операционная система. Как вы понимаете, операционная система хранится на жёстком диске, и вот тут возникает вопрос: а каким же волшебным образом операционная система загрузилась в ОЗУ и начала выполняться?

На картинке изображена поверхность дискового накопителя. У дискеты 2 поверхности. На каждой поверхности есть кольцеобразные дорожки (треки). Каждый трек делится на маленькие дугообразные кусочки, называемые секторами. Так вот, исторически сложилось, что сектор дискеты имеет размер 512 байт. Самый первый сектор на диске, загрузочный сектор, читается BIOS’ом в нулевой сегмент памяти по смещению 0x7С00, и дальше по этому адресу передается управление. Начальный загрузчик обычно загружает в память не саму ОС, а другую программу-загрузчик, хранящуюся на диске, но по каким-то причинам (скорее всего, эта причина — размер) не влезающую в один сектор. А поскольку пока что роль нашей ОС выполняет банальный хеллоуворлд, наша главная цель — заставить компьютер поверить в существование нашей ОС, пусть даже и на одном секторе, и запустить её.

Как устроен загрузочный сектор? На PC единственное требование к загрузочному сектору — это содержание в двух его последних байтах значений 0x55 и 0xAA — сигнатуры загрузочного сектора. Итак, уже более-менее понятно, что нам нужно делать. Давайте же писать код! Приведённый код написан для ассемблера yasm.

Эта короткая программа требует ряда важных пояснений. Строка org 0x7C00 нужна для того, чтобы ассемблер (имеется в виду программа, а не язык) правильно рассчитал адреса для меток и переменных ( puts_loop, puts_loop_exit, message ). Вот мы ему и сообщаем, что программа будет загружена в память по адресу 0x7C00.
В строках

происходит установка сегмента данных ( ds ) равным сегменту кода ( cs ), поскольку в нашей программе и данные, и код хранятся в одном сегменте.

В строке « times 0x1FE-finish+start db 0 » производится заполнение остатка кода программы (за исключением последних двух байт) нулями. Делается это для того, чтобы после компиляции в последних двух байтах программы оказалась сигнатура загрузочного сектора.

С кодом программы вроде разобрались, давайте теперь попробуем скомпилировать это счастье. Для компиляции нам понадобится, собственно говоря, ассемблер — выше упомянутый yasm. Он есть в большинстве репозиториев Linux. Программу можно откомпилировать следующим образом:

Полученный файл hello.bin нужно записать в зарузочный сектор дискеты. Делается это примерно так (разумеется, вместо fd нужно подставить имя своего дисковода).

Поскольку далеко не у всех остались дисководы и дискеты, можно воспользоваться виртуальной машиной, например, qemu или VirtualBox. Для этого придётся сделать образ дискеты с нашим загрузчиком и вставить его в «виртуальный дисковод».
Создаём образ диска и заполняем его нулями:

Записываем в самое начало образа нашу программу:

Запускаем полученный образ в qemu:

После запуска вы должны увидеть окошко qemu с радостной строчкой «Hello World!». На этом первая статья заканчивается. Будем рады увидеть ваши отзывы и пожелания.

Создаем новую OS. Действительно новую, реально операционную, и правда – систему

Общие характеристики системы

Основные принципы, лежащие в основе работы ОС

▍Знакомьтесь, Resource-Owner-Service (ROS) модель

Назовем экземпляры этих объектов «каналами». Канал – это разделяемый объект, содержащий как код, так и данные и предназначенный для передачи данных и управления между задачами. Заметьте, что здесь намеренно отсутствует разграничение на провайдера и потребителя услуг (то есть, сервер и клиент), так как каждая задача может и предоставлять, и потреблять определенный набор сервисов. Из исключительности каналов как средства взаимодействия задач следует еще одно свойство ROS-модели: коммуникационная синхронизация. Любая передача управления между задачами по определению может осуществляться только в связке с получением\предоставлением услуги, то есть, каналы становятся синхронизационными объектами, однозначно определяющими место и назначение синхронизации задач.

ОС не имеет никакой информации и не делает никаких предположений о предназначении каждого канала. Так что каналы должны предоставлять идентификаторы, однозначно определяющие тип, цель или иную информацию, необходимую для конкретного взаимодействия.
Для обеспечения исполнения задач система создает для каждой задачи специальный системный канал.

Дизайн ОС включает в себя два вида каналов: дуальные и мульти. Как видно из названия, у первых число присоединенных задач не может превышать 2, а у последних ограничения по количеству подключенных задач отсутствуют (определяются исключительно объемом доступной памяти и особенностями конкретной реализации ОС). Каждый канал имеет два «противоположных» конца. Задачи, присоединенные к ним, называются экспортерами и импортерами канала, соответственно. Разница между этими двумя типами задач несущественна – оба должны создать экземпляр канала, то есть, выделить память и таким образом поместить канал в свое адресное пространство. Единственная цель разделения на экспортеров и импортеров – поддержка задач с традиционной семантикой клиент-сервер, т.е. производитель и потребитель услуг.

На рисунке ниже представлена принципиальная схема ROS OS:

Все крайне просто. Серо-голубым цветом помечены физические компоненты системы – процессоры (CPU), память (memory). Dev (Device) – это физическое устройство хранения данных.
Ядро ОС владеет ресурсами процессоров и памяти. Остальными ресурсами системы могут владеть привилегированные задачи (P-task), предоставляющие в свою очередь сервисы задачам пользовательского уровня (U-task) посредством коммуникационных каналов (channel).
ROS OS реализует: Менеджер Памяти (ME-M), Менеджер Каналов (CH-M), Менеджер Системных Каналов (SC-M), Менеджер Задач (TA-M), и Диспетчер Задач (TA-D). Ядро идентифицирует задачи и запросы на сервисы посредством системных каналов (syschan).

Управление задачами

▍Скоординированное вытеснение (cooperative preemption)

В отличие от Windows и Linux, которые сохраняют контекст задач при их переключении, потребляя при этом значительное количество памяти на размещение стека, а также теряя производительность на инструкциях сохранения регистров, предлагаемая OS дает возможность каждой задаче сообщить ядру, что сохранять ее контекст не требуется.

Вместо этого, задачи предоставляют окружение исполнения, состоящее из четырех указателей в форме , так что ядро может очистить стек задачи, а затем, непосредственно перед активацией, выделить задаче новый (или предоставить существующий пустой) стек, после чего позвать функцию func с данными параметрами. При этом, значения остальных, не используемых в передаче этого окружения регистров остаются неопределенными или обнуляются, что быстрее сохранения\восстановления корректного значения.
Непосредственно перед активацией задачи система очищает окружение из 4-ех указателей, чтобы исключить ошибочное преждевременное вытеснение задачи.
Заметим, что скоординированное вытеснение (при условии, что все задачи в системе ему следуют) означает, что при идеальных условиях исполнения для каждого ядра CPU будет существовать только один стек. Дополнительные стеки будут выделяться, только если задача будет вытеснена преждевременно, перед тем, как она инициализирует контекст из 4-ех указателей.

▍Модель передачи управления для потоков (Yield-To)

Дизайн ОС не предполагает явных функций ожидания (wait) или взаимного исключения для потоков. Вместо этого межпотоковая синхронизация достигается явной передачей управления другим задачам, идентифицируемым при помощи указателя на канал и номера задачи в канале. То есть, управление передается не конкретной задаче, а любому агенту, который предоставляет соответствующий сервис и проиндексирован в своем сервисном канале. При этом, за конкретную эффективную внутреннюю реализацию протокола для синхронизации отвечают сами коммуникационные агенты.
Операционная система может поддерживать множественные стратегии передачи управления задачами, такие как «уступить любой», «уступить заданной» и «разрешить исполнение заданной». Последняя стратегия подразумевает, что уступающая задача не намеревается отдавать контроль на «своем» CPU, так что новая задача должна быть активирована в параллель с текущей на другом CPU.

▍Детерминированное планирование задач

Каждая задача активируется системным таймером (как и в существующих ОС), но, с учетом применимости ROS OS к системам реального времени, каждая задача должна задать требования к планировщику задач в виде двух параметров: частоты и продолжительности активации. Помимо своего основного назначения, эти параметры используются для оценки предполагаемой загрузки системы, количества ожидаемых конфликтов задач и выделения в соответствии с этим необходимых ресурсов (тех же стеков)
В идеале, суммарная продолжительность активаций всех задач должна быть меньше или равна минимальному заданному периоду активации, а периоды должны быть кратны минимальному. Выполнение этих условий будет гарантировать отсутствие конфликтов планировки.
Но в нашем несовершенном мире некоторые задачи могут превысить свою заявленную продолжительность, в таком случае они могут быть вытеснены другими, готовыми к исполнению задачами и помещены в список «на будущее исполнение» в ближайшие свободные слоты.

▍Производительность

Так как в ROS модели может существовать несколько провайдеров одного и того же сервиса (по сети или даже локально), единственным критерием выбора между различными провайдерами будет их производительность в данных конкретных условиях.
Для управления производительностью программ системный канал имеет счетчики-таймеры активного времени и времени ожидания, предоставляющие информацию о состоянии текущей задачи. Так как обычно известно, какой задаче (каналу) было передано управление, производительность может быть оценена просто по значению соответствующего таймера по возвращении в вызывающую задачу.
Сравнив производительности нескольких каналов, задача может переключиться на использование более быстрых из них, что может оказаться особенно полезным в условиях динамической адаптации к меняющимся условиям (обширные сети, физически нестабильные окружения и т.д.).

▍Упрощение структуры кода

Поскольку каналы представляют собой динамические структуры данных, разделяемые между адресными пространствами задач и подверженные возможным перемещениям в памяти ядром ОС, код каналов, да и задач в общем случае должен быть написан так, чтобы не зависеть от статичного положения данных в памяти (или располагать их относительно вызывающего кода) и позиции самого кода. Отсутствие статичных структур, независимость от позиции и контекст из 4-ех указателей позволяют обойтись без сложных заголовков программ и определяет следующую простейшую структуру программы:
Каждая программа представляется в памяти в виде двух частей: кода и данных (с опциональным разграничением между ними для обеспечения защиты доступа). Начало куска кода – это стартовая функция задачи, принимающая на вход три указателя, как описано выше.

▍Создание и структура задач

Задача может быть создана из любого фрагмента кода. Адрес начала кода будет являться адресом стартовой функции задачи – той самой, с прототипом четырех указателей – func(chan, sys, loc), где chan и loc – опциональные (так, loc – может указывать на локальные данные), а sys – указывает на созданный для задачи системный канал. Заметим, что код задачи копируется на новое место в памяти для упрощения дальнейших операций с каналами – например, если часть кода будет экспортирована в качестве канала.
Внутренняя структура задач выглядит так:

Каждая задача содержит дескриптор, описывающий ее тип (type) – пользовательский или привилегированный, а также указатели на: таблицы страниц адресного пространства (address space), локальную память (heap), стек (stack) и обработчик исключений (exception handler).
Помимо этого, дескриптор задачи включает список отображенных каналов – (task2chan), т.е. список пар: «индекс-дескриптор канала, указатель на код данного канала».
В случае, когда задачи разделяют общее адресное пространство, указатели каналов могут пропускаться с целью оптимизации использования памяти.
Первый элемент списка отображенных каналов – это всегда системный канал задачи. Он хранит контекст исполнения и другие свойства, как описано дальше.

▍Диспетчеризация задач

Дизайн ОС предусматривает два типа активации задач: (а) по системному таймеру согласно запрашиваемому расписанию и (б) по явной передаче управления из другой задачи.
Расписание активации может быть запрошено в виде периода и продолжительности активации. Эти два параметра определяют следующую диаграмму состояния задачи

Граф изменения состояния задач.

Изначально, при активации задачи, она входит в защищенное (active-protected) состояние, то есть, она не подлежит вытеснению. После того, как задача превышает заявленную продолжительность, защита от вытеснения снимается. В случае, когда в листе готовых к исполнению задач (ready list) есть другая задача, система может вытеснить первую задачу, поместить ее дескриптор в ready list и активировать другую задачу. Вновь активированная задача возобновляет исполнение либо в активном состоянии (если она была вытеснена ранее), либо в защищенном состоянии (в случае запланированного исполнения или вообще для всех задач, в зависимости от конкретной реализации)

Важный момент: задание расписания исполнения на основе периода позволяет ядру системы гарантировать задачам реального времени определенную частоту активации, а не предельный срок ее начала. Таким образом, система может сдвигать задачи во времени, если это не нарушает частоту активации. Задание продолжительности позволяет избежать проблем, связанных с приоритетом задач, посредством определения для них предварительно запланированного (запрошенного) отношения активности/ожидания. Конкретные реализации ОС могут ограничить продолжительность максимальной длиной кванта времени, чтобы «жадные» задачи не занимали процессор бесконечно. Все вышесказанное упрощает схему планировщика и обеспечивает его быстрое функционирование.
Планировка на основе заданных периода и продолжительности активации позволяет планировщику определять неизбежные конфликты (см. рисунок ниже) и либо отклонять запрос на активацию, либо смягчать требования планировки реального времени.

Помимо вытесняющей многозадачности, система поддерживает и кооперативную. Явная передача управления может осуществляться с помощью специального системного метода yield(). Вызов этого метода приведет к передаче управления задаче, идентифицируемой при помощи указателя на канал и номера задачи в нем, и исполнению данной задачи на заданном процессоре. Также, как было сказано выше, возможно передать управление не конкретной задаче, а любому агенту, который предоставляет соответствующий сервис и проиндексирован в своем сервисном канале.

Каждый конфликт планировки (включая динамический, когда задачу вытесняют по превышению продолжительности исполнения) в общем случае приводит к выделению ядром ОС дополнительных ресурсов – нового стека для активированной задачи. Поэтому для оптимального использования системных ресурсов каждая задача может сообщить ядру ОС, что она не нуждается в сохранении регистров и данных стека. В этом случае ОС при вызове yield() может освободить стек задачи и сбросить содержимое регистров. При активации такой задачи система вызовет прототип на пустом стеке и неопределенном содержании регистров.
Для обеспечения запланированной или вытесняющей активации задачи диспетчер задач поддерживает список готовых к выполнению задач. Это – кольцевой буфер, содержащий индексы-дескрипторы (или указатели) задач и запланированное время активации, как показано на рисунке ниже. Для вытесненных задач это время будет, конечно, нулевым.

Время может выражаться в абсолютных или относительных единицах (по отношению к максимальному периоду), и обновляться в соответствии с запрошенными периодами активации. Когда задача вытесняется или уступает контроль, ее дескриптор помещается в первый свободный слот кольцевого буфера. Отметим, что так как список упорядочен по времени, задача может быть вставлена в список перед другими, если крайний срок ее активации наступает раньше.
Готовые к исполнению задачи могут выбираться из листа, начиная с конца (хвоста) или с указателей на листы задач (task list pointers), содержащихся в Блоках управления процессорами, которые описаны ниже.

Накладные расходы планировки задач разделяются на статические и динамические. Первые – это постоянное время инициализации процессорного контекста задачи (напомним, что именно это время уменьшает кооперативная многозадачность), а вторые – накладные расходы самого диспетчера задач, пропорциональные количеству операций поиска в листе готовности задач (как для поиска текущей готовой к исполнению задачи, так и для вставки новой). При этом, нет необходимости поиска задачи для активации, так как она всегда будет находиться в «хвосте» списка.
Накладные расходы на вставку задач будут минимальными, если все задачи запросили периоды активации одинаковой продолжительности. Если же периоды разные, то поиск займет логарифмическое число операций, так как лист готовности включает набор следующих друг за другом, по большей мере, сортированных данных, а несортированные элементы могут быть найдены по цепочке ссылок.

▍Управление каналами

Каждому каналу в системе присваивается дескриптор, который хранит информацию о топологии канала (type), его идентификатор (guid), а также указатели: на тело канала (body pointer) в общем адресном пространстве, где размещены все каналы; и на дескрипторы задач (chan2task), которые присоединены к данному каналу. То есть, система хранит таблицу дескрипторов каналов, показанную на рисунке ниже:

Обратные ссылки каналов на задачи необходимы для идентификации задач посредством указателя на канал и внутриканального индекса (для передачи управления между задачами). В этой схеме внутриканальный индекс – это позиция дескриптора задачи (task descidx) в соответствующем листе chan2task.

▍Системные вызовы и управление контекстом

Системные каналы – это комплекс средств для идентификации задач, сохранения их контекста, получения системной информации, генерации системных вызовов и передачи управления другим задачам.
На рисунке ниже показана структура системного канала.

Как видно, аргументы системных вызовов не передаются через стек или регистры, а копируются в соответствующие структуры системного канала.
В системном канале размещается информация о свойствах и возможностях компьютерной платформы, позволяя ее использование без дополнительных накладных расходов на системный вызов.

Комбинация в одном канале четырех-указательного окружения исполнения и контекста исполнения может быть удобной для целей удаленной отладки\мониторинга.
Информация о хронометраже каждой задачи обновляется ядром ОС в реальном времени. Наличие полей, относящихся к каждому процессору системы, позволяет параллельную активацию задач (идентификация задач происходит на основе таблицы дескриптора канала).
Конкретные реализации системы могут выделить один регистр (доступный для чтения непривилегированным задачам – например, при наличии поддержки в железе, сегментный регистр) для хранения постоянного указателя на текущий системный канал задачи. В этом случае задачам не требуется сохранять указатель на системный канал, вместо этого они могут ссылаться на него через соответствующий макрос.

Системный канал должен обязательно поддерживать следующие функции, которые, фактически, будут являться системным API:

То есть, весь системный API состоит менее, чем из 10 функций!!

▍Управление процессорами

Каждому процессору в системе присваивается Блок Управления Процессором, который содержит некоторые свойства текущей выполняемой задачи, как показано на рисунке ниже.

Также в соответствие процессору ставятся некоторые другие управляющие таблицы – прерываний (включая межпроцессорные) и таблица системных дескрипторов.

Уровни сложности системы

Сложность определенной реализации системы может зависеть от доступного объема памяти, процессорных возможностей и производительности конкретной платформы. Ниже описаны возможности регулировки сложности ядра ОС.

▍Реализация управления каналами

Каналы, являясь основой дизайна ОС, допускают значительную вариативность. Например, разработчики ОС могут выбрать поддержку исключительно дуальных каналов, исключая таким образом необходимость динамического выделения списков членов каналов. Кроме того, система может не поддерживать каналы с кодом (или, по крайней мере, смешанные каналы для кода и данных), вследствие чего упрощается использование традиционных компиляторов и сред разработки, так как пропадает необходимость агрегирования кода и данных.

Каналы могут идентифицироваться уникальными 128-битными идентификаторами либо определенными индексами, валидность которых может контролироваться локальной (масштаба системы или сети) или глобальной службой.
Еще одна возможность – присвоение каналам имен, образованных в виде иерархических путей, подобных системным файловым путям существующих ОС.

▍Реализация управления задачами

Так же, как и в современных ОС, предлагаемый дизайн операционной системы подразумевает возможность реализации задач как в форме процессов, так и в форме потоков, то есть, задачи могут быть как изолированными (логически и физически, если это позволяют возможности процессорной системы), так и разделять одно адресное пространство, а значит, и передавать данные через разделяемые переменные.
Еще одна возможная, но очень важная особенность реализации – это уровень привилегий задач, то есть, доступность задачам определенных системных и процессорных ресурсов (например, межпроцессорных прерываний, таблиц дескрипторов процессоров, входных-выходных портов).
Возможное решение – это поддержка исключительно привилегированных задач, что приведет к экономии усилий по реализации изоляции задач, защите памяти и процессорных ресурсов.

Если же поддерживаются как привилегированные, так и непривилегированные задачи, дизайн ОС предусматривает две возможности для реализации привилегированных операций.

В первом случае, все привилегированные операции могут исполняться только ядром, то есть, все привилегированные программы становятся частью ядра ОС и исполняются в его контексте (или контексте запрашивающей стороны). Назовем это «общей схемой». Достоинства этого подхода – обслуживание привилегированных операций может не требовать переключения контекста задач (операции выполняются в контексте запрашивающей стороны) в случае, когда адресное пространство ядра ОС отображается на адресное пространство каждой задачи. Кроме того, так как системное ядро всегда распараллелено по числу процессоров системы, параллельные задачи, запрашивающие привилегированные операции, не будут простаивать даже при отсутствии возможности исполнения их контекста. Недостаток – запрашивающая задача не сможет продолжить исполнение до тех пор, пока запрос не будет обработан.

Во втором случае все привилегированные задачи могут быть отделены от ядра («раздельная схема»).
Это решает проблему параллельного исполнения запрашивающих и выполняющих запросы задач, но вносит дополнительное переключение контекста по каждому запросу и получению прерывания (так как прерывания, принадлежащие привилегированным задачам, могут произойти во время исполнения любой другой задачи).

Поэтому полезным решением может стать объединение общей и раздельной схем. По умолчанию, все привилегированные операции могут быть выполнены от лица запрашивающих их задач (как часть ядра), но, по мере необходимости, могут создавать другие привилегированные задачи, исполняемые отдельно, и передать им управление и данные с помощью каналов.

Для реализации комбинированного подхода может потребоваться дополнительное расширение к вышеописанной функциональности ядра – системный вызов, соединяющий вектор прерываний и его обработчик – сервисную функцию, вызываемую ядром системы при передаче управления привилегированному каналу, владелец которого – часть ядра, а не отдельная задача.

При вызове этой функции система проверяет привилегии инициатора запроса и текущий индекс задачи. Ядро ОС гарантирует при получении каждого прерывания из указанного вектора переключение контекста на привилегированную задачу – инициатора запроса. Нулевой параметр handler удаляет предварительно установленный обработчик прерываний.
Дескриптор канала в этом случае будет содержать функцию- обработчик прерываний.

Примеры коммуникаций посредством каналов

▍Дуальные каналы

Простейшая модель коммуникации задач – это дуальные каналы. Они гарантируют обслуживание только двух коммуницирующих агентов, хотя каждый из них может соединяться с более чем одним каналом того же ID. То есть, и один провайдер сервиса может предоставлять его нескольким клиентам (каждому – в отдельном канале), и один потребитель получать одну и ту же услугу от разных поставщиков.

Дуальные каналы являются эффективным средством передачи данных в случае, когда присоединенные к ним агенты копируют свои данные в разделяемое внутриканальное хранилище и извещают друг друга о завершении операции копирования\обработки данных (так что ожидающие агенты не тратят попусту вычислительные ресурсы).

Дуальные каналы кода практически эквивалентны каналам с данными, единственное отличие – они предоставляют разделяемый интерфейс, который инкапсулирует операции обработки и передачи данных, что может оказаться более удобным в некоторых случаях объектно-ориентированного дизайна. В этом случае операции передачи управления могут осуществляться внутриканальным кодом по поручению текущей задачи.

Здесь и на последующих рисунках U-Task означает пользовтельскую задачу.

▍Мульти-каналы

Мульти-каналы могут использоваться для обеспечения вычислительного сервиса – то есть, для разделения кода между несколькими задачами (подобно динамическим библиотекам во многих традиционных ОС).
Разделяемый код при этом необязательно должен поддерживаться своей задачей-экспортером.
Задача может первоначально экспортировать канал и завершиться, а внутриканальный код при импорте разместит локальные данные в адресном пространстве импортирующей задачи и, таким образом, будет являться как полностью интегрированным с импортером, так и изолированным от других импортеров (для случаев, когда конкретная реализация ОС поддерживает изоляцию адресных пространств).

Ниже обсуждаются более сложные случаи мульти-канальных конфигураций.

▍Пулы задач

Предназначение пулов задач – поддержка синхронизационных моделей, традиционно используемых в симметричной многопроцессорности (SMP). Каналы данных, к которым присоединены несколько задач, могут быть как контейнером для разделяемых (обрабатываемых параллельно) данных, так и служить средством синхронизации, то есть, включать в себя счетчик числа задач-пользователей канала и, опционально, их индексов в канале.
Пулы задач могут использовать возможности планировки задач ОС и обеспечивать эффективную синхронизацию параллельных задач – в противоположность наиболее примитивным схемам опроса каналов для синхронизации.

Экспортер канала может взять на себя обязанности распределения работы и, так как количество процессоров и распределяемых задач известно, экспортер может передать управление определенным задачам на определенных ЦПУ. Когда задачи-исполнители завершат обработку данных, они могут вернуть управление распределяющей работу задаче.

▍Пулы запросов

Пулы запросов могут оказаться эффективными в условиях, когда создание отдельного канала для каждого клиента потребовало бы значительных затрат памяти – при разделении больших буферов памяти и\или обслуживании большого числа клиентов.
Эти пулы обеспечивают интерфейсы, которые можно назвать арбитражными. Победитель арбитража может поместить запрос (передать данные), а другие инициаторы запросов могут быть переключены в неактивное состояние (прозрачным образом – с использованием внутриканального кода). Когда обслуживание победителя арбитража завершается, победитель извещается об этом, копирует свои выходные данные, и арбитражный процесс возобновляется – из остальных участников арбитража выбирается победитель, пробуждается операцией yield, и процесс полностью повторяется.

▍Маркеры доступа

Маркеры доступа (Access tokens) позволяют реализовать модель разделения данных (и\или получения одинакового обслуживания ) между несколькими задачами без установки каналов передачи данных. Вместо этого, единственный провайдер сервисов управляет всеми ресурсами или обеспечивает сервисы всем активным агентам в системе. Каждый агент может запросить у него маркер доступа, который и будет являться ключом к разделяемым данным. Затем агенты могут «поделиться» маркером с другими доверенными агентами (посредством специального канала обмена), в результате чего доверенные агенты смогут получить тот же самый тип обслуживания или доступа к данным.

▍Параллельный доступ к устройствам

Прежде чем говорить о работе с физическими устройствами, заметим, что драйвера в ROS OS – это не особые выделенные сущности, а обычные привилегированные задачи, предоставляющие свои сервисы посредством каналов.
Во многих случаях необходимо обеспечить нескольким задачам одновременный доступ к потокам данных, производимым или потребляемым физическим устройством. На рисунке ниже показаны 2 типичных примера параллельной коммуникации с устройством.

Первый будет эффективным, если ядро ОС различает процессы и потоки. В этом случае специальная задача может обрабатывать все операции с устройством и буферизовать входящие\исходящие потоки данных, в то время как фактическое обслуживание задач-потребителей данных будет производиться потоками, имеющими полный доступ ко внутренним буферам и, соответственно, возможности проверить наличие данных и избежать ненужных задержек. На рисунке данная схема показана слева.

Второй вариант реализации может быть использован в случае пакетной обработки данных. В этом случае обслуживающая задача, непосредственно взаимодействующая с устройством, может выделить необходимые буфера в экспортируемых ей каналах (так как размер пакета известен и ограничен – так же, как и размер буферов). Обе стороны, подключенные к каналам, будут сообщать о готовности данных друг для друга – так, что обслуживающая задача сможет по получении одного запроса безотносительно от того, откуда он получен, обслужить все каналы, таким образом облегчая реализацию параллелизма в системе. Эту схему иллюстрирует правая сторона рисунка.

▍Удаленное использование каналов

В соответствии с дизайном ОC – независимостью работы с компонентами от их расположения, каждый агент в локальной системе может соединиться с каналом, экспортируемым удаленно. Для поддержки этого механизма в систему вводятся так называемые репликаторы каналов, которые помимо поддержки обычной функциональности экспорта\импорта каналов опрашивают свои локальные системы на предмет имеющихся каналов, проверяют наличие сетевых запросов на эти каналы, и, при их наличии, поддерживают пары (наборы) удаленно синхронизированных каналов максимально прозрачным образом для удаленных клиентов этих каналов. Иллюстрация описанному механизму – ниже.

Здесь и на последующих рисунках P-Task означает пользовтельскую задачу.

Отметим, что для эффективной поддержки удаленных репликаторов каналов необходим дополнительный системный вызов

Здесь guid[] – массив индексов каналов, size[]предоставляет размеры каналов, а type[] содержит типы\топологию запроса канала (импортированный, экспортированный или мульти).

▍Поддержка со стороны языков программирования

Существующие языки программирования потребуют небольшого расширения для поддержки ROS модели и облегчения разработки для предлагаемой ОС. В случае C++, расширение, затрагивающее семантику языка, это модификатор типа – “channel”, показывающий тип содержимого, которое должно быть объединено в форму, пригодную для межпроцессной коммуникации. Оставшиеся проблемы, связанные с канальной коммуникацией, решаются с использованием функций ROS OS API, как показано ниже.

То есть, сначала требуется объявить тип вашего канала (используя модификатор типа channel), а также выделить стандартным способом области памяти для экспортера и импортера канала. После чего канал, очевидно, должен быть присоединен посредством экспорта с одной стороны и импорта с другой. Для этого используются специальные функции export() и import(), в которые передаются указатели на ваш канал, системный канал и указывается вид канала (мульти или дуальный).
Проверки указателей, приведенные после вызовов этих функций, приведены здесь для сред с разделяемым адресным пространством, где существует вероятность, что ядро ОС передвинет тело канала в памяти с выделенного ранее места.
Каждые агент, подсоединенный к каналу, имеет свой внутриканальный индекс, получаемый функцией self(), который остается неизменным де тех пор, пока агент не отключится от канала (вызовом disconnect()) и не присоединится к нему снова (посредством import() и export()). Остальные связанные с каналами функции в соответствии с дизайном ОС рекомендуется определить так, чтобы они принимали указатель на ваш канал, текущий системный канал, а также указатель на локальное хранилище данных или опциональный параметр.
Ниже приведен прототип функции chanfunc, которая может являться как функцией запуска задачи с семантикой (arg0, sys, arg1), так и функцией инициализации канала (которая выделит локальное хранилище данных и вернет его указатель loc), либо вообще любой служебной внутриканальной функцией

▍Генерация кода

При написании программ для ROS ОС с использованием существующих компиляторов, предназначенных для других ОС, надо соблюдать осторожность. Так, разработчик должен позаботиться о неиспользовании статических переменных и работать только с автоматически (стек) и динамически выделяемыми данными и/или пользоваться возможностями некоторых компиляторов по генерации кода, не зависящего от адреса загрузки. В идеале специальный компилятор для данной ОС должен быть способен обнаружить ссылки на статические данные и сгенерировать вычисление соответствующего адреса в памяти относительно к адресу использующей эти данные функции.
Еще одна проблема, которая не может быть решена традиционными компиляторами (кроме ассемблера) – это поддержание комбинированных каналов кода и данных. Специализированный компилятор данной ОС должен уметь объединять тела канальных функций и данные в единый монолитный объект, который может быть отображен, передвинут и обработан ОС.
Для процессорных архитектур, поддерживающих защиту исполнения данных, агрегация кода и данных должна проходить на базисе раздельных страниц, чтобы не компрометировать безопасность системы.

Выводы

Основа предлагаемой модели ОС – сервисно-ориентированный подход к параллельному исполнению программ реализует новые принципы передачи управления, планировки задач и управления ресурсами, а также новые логические топологии программной коммуникации и синхронизации, которые удовлетворяют потребности современных параллельных и распределенных компьютерных систем, включая как мощные сервера, так и сети беспроводных сенсоров.
При этом, система продумана с точки зрения связывания вместе железных и программных компонентов компьютерной системы, и максимально проста в реализации.

Многие из описанных принципов дизайна ОС были первоначально воплощены ее автором еще в прошлом веке (1999 году) как часть легковесной ОС, служившей предсказуемой и полностью контролируемой средой тестирования для исполняемых файлов Windows NT. И, конечно же, с тех пор многое было добавлено и улучшено.
Как видите, создать свою ОС на базе описанных принципов возможно. Было бы желание. Если оно у вас есть, то автор идеи, несомненно заинтересованный в ее реализации, с удовольствием вам поможет – проконсультирует и поддержит.