Предыстория
Здравствуйте! Всех категорически приветствую, сегодня хотел бы рассказать Вам о своём опыте написание работоспособной ОС под архитектуру x86.
Как-то весенней ночью у меня родилась гениальная идея — попробовать себя в написании собственной ОС, которая может позволить запускать программы, работать с устройствами, да и в общем выжимать всю мощь из Intel'овской архитектуры в своих нуждах: к примеру, для своей фабрики или чего-либо иного. Моей целью было и есть написание такой ОС, которая могла бы позволить максимальную производительность для каких-то конкретных задач, не тратя процессорное время на всяческие излишества. В основном я преследую лишь спортивный интерес, получение опыта для себя в системном программировании и написания драйверов для устройств, которые используются повсеместно. Что из этого вышло — решать вам, сразу говорю, что не надо писать комментарии про создание собственного дистрибутива линукса, и преследовал интерес написать всё «From scratch» — с нуля, дабы хорошо погрузиться в тему ОСдева. Сразу хочу выразить огромную благодарность Бенджамину Лунту и форуму OSDev, так же как их Вики. Бен помог мне разобраться с EHCI, что несомненно внесло огромный вклад в мою ОС — USB устройства, они везде! Так же передо мной стояла задача создать собственную архитектуру, удобную мне, не исключая использование стандартов ELF-файлов. Что же, давайте перейдем к сути.
UPD: всю инфу можно найти в группе тык, так же там есть пост с доками и образом(старым, сейчас дописываю доки для stable-версии)
Что сделано?
Сейчас моя ОС умеет работать с USB-флешками, мышками, клавиатурами, AHCI дисками, PCI IDE контроллером, APIC'ом и ACPI, реализована вытесняющая многозадачность, реализован запуск программ, поточная работа с файлами, SVGA драйвер, который работает на 0x118 режиме VBE, работают DNS, DHCP, TCP, UPD, IPv4, HTTP, полный драйвер FAT32, драйвер RTL8139(69) и Intel Gigabit Ethernet.
Оконная система вместе с моей реализацией SVGA позволяет выдать аж 120 FPS при полной перерисовке экрана. Давайте перейдем к тому, как это всё реализовано и вообще может работать.
Как это работает?
Для начала, я написал бутлоадер, который с FAT32 читает вторичный загрузчик с ядром. Второй загрузчик переходит в защищенный режим и прыгает в ядро, там я загружаю и настраиваю IDT, после чего инициализирую PCI-устройства, запускаю ядра и запускаю CMD.
Кто-то спросит, как же ты добился такого перфоманса с SVGA? Ответ прост: ассемблер, ассемблер и еще раз ассемблер. Не обошлось без SSE инструкций, которые очень ускоряют копирование памяти. К примеру, вот код для копирования видеобуфера в LFB(Linear Frame Buffer):
.byte 0x60#Save registers in stack
mov %2,%%ecx #Repeat count to ecx
mov %0,%%edi #Video memory start to edi
mov %1,%%esi #Video buffer start to esi
ww1sse2:
movaps (%%esi),%%xmm0 #Copy 16 bytes to xmm0 from buffer
movaps %%xmm0,(%%edi) #Copy from xmm0 to video memory
movaps 16(%%esi),%%xmm0 #16 again, but + 16 from current
movaps %%xmm0,16(%%edi) #16 again, but + 16 from current
movaps 32(%%esi),%%xmm0 #16 again, but + 32 from current
movaps %%xmm0,32(%%edi) #16 again, but + 32 from current
movaps 48(%%esi),%%xmm0 #16 again, but + 48 from current
movaps %%xmm0,48(%%edi) #16 again, but + 48 from current
add $64,%%edi #Add 64 bytes to edi
add $64,%%esi #Add 64 bytes to esi
dec%%ecx#Decrement count
#test %%ecx,%%ecx #Compare ecx with zero
jnz ww1sse2 #If not zero, repeat again
.byte 0x61 #Restore registers from stack
Оконная система построена на ООП и, думаю, не нуждается в комментариях, всё почти как в шинде.
Менеджер памяти простейший — «Watermark Allocator». Распределение ресурсов осуществляется за счет того, что в ядре нет функций, которые могли бы нагадить друг другу, всё запросы сделаны через очереди и т.п.
Пока что нет никаких потоков ввода-вывода, но в ближайшее время они будут реализованы.
Система логических дисков аналогична MS-DOSу: одна буква — один диск. Поддерживаются как MBR разделы, так и GPT разделы.
Разработка драйверов устройств
Не обошлось тут и без этого — брать чужой код как-то некультурно и не практично, если раскапывать репозитории линукса — так можно и заблудиться.
Если честно, то я сторонник того, что главное в программе — функционал, но в тоже время считаю, что за графику можно и функционалом немного пожертвовать: к примеру, VIM.
Конечно, это стало самой интересной стадией разработки: прочитать тонны документации, а потом понять, что ты поставил return для отладки, из-за чего часть структуры не заполнялась вовсе. Думаю, что это достаточно хорошо заставляет тебя напрячь мозг, ибо даже после десятого прочтения доков какие-то аспекты всё равно остаются тебе непонятны, и приходиться заниматься долгой отладкой на реальном железе.
Отладка
Отладка ОС занимает огромную кучу времени: скомпилить сорсы, скопировать на виртуальный диск, сохранить образ диска, проверить на эмуляторе, после чего скопировать файлы на флешку и проверить уже на реальном железе. А главное — никаких отладчиков, выводи в текстовый режим, либо в окошечки — повисло — ставь return'ы.
Итоги
Да, ОС всё еще в стадии разработки, хочется под новый год получить стабильную бета-версию, а может в будущем даже продолжить разработку на более серьезном уровне.
Что хочу сказать напоследок — если тема разработки ОС кого-то заинтересовала, или кто-то хочет узнать аспекты работы с какими-либо устройствами и интерфейсами, хитрости реализации, или просто помочь проекту(не деньгами, а кодом) — можете отписать об этом в комментариях, все пожелания будут учтены, и в деталях и красках будут описаны интересующее вас аспекты.
Этичного хакинга!
Комментарии (172)
CodeRush
16.10.2018 02:45+1А главное — никаких отладчиков, выводи в текстовый режим, либо в окошечки — повисло — ставь return'ы.
Для чего так себя мучать?
Сейчас есть DCI, который на современных десктопных платах включается тривиально, и в продаже открытой до сих пор есть Intel Galileo, у которой JTAG доступен через OpenOCD.
Понятно когда приходится прошивку на ранних стадиях через порт 80 отлаживать, потому что вокруг вообще ничего не инициализированно, но писать полноценную ОС без отладчика — это мазохизм и потеря времени.
Автоматизируйте все, что видите — сборку, развертывание, EFI stub напишите, чтобы легаси загрузку не использовать (заодно не придется в защищенный режим переходить, вы и так уже там), тратьте время непосредственно на ОС, а развертывание и тестирование пусть скрипты делают — им не скучно.radiolok
16.10.2018 12:24+2Дополню:
DCI это когда все что требуется — это дебажный A-A USB3.0 кабель и Intel System Studio(Если быть точнее — то его часть Intel System Debugger). В результате есть мощный отладчик, с ассемблером(а можно и C-шные исходники подложить), доступом к памяти и пошаговой отладке.
Еще есть консольный openIPC python cli интерфейс, который позволяет все это делать скриптами(System Studio тоже через OpenIPC ходит).
Даже загрузить в память таргета исполняемый код, настроить регистры и запустить на исполнение получится. Можно даже борду не перезаливать. Все автоматизируется на раз.
Ну и конечно пишите сразу под EFI — меньше геммороя.radiolok
17.10.2018 10:24Кстати, mrlolthe1st у UEFI есть такая фишка, что ОС может использовать драйвера из Uefi, если у нее нет своих. В Uefi как правило большая часть уже проинициализиована (графика, сеть, USB, жесткие диски, fat32, ntfs, ext2,3 и прочее. Даже все процессорные ядра активны), так что остается только дергать API.
Я эту фишку только в документации читал, вероятно CodeRush может рассказать о ней больше.
Krey
16.10.2018 05:07Тэгов в этой статье больше чем смысла. Все время на отладку текстового редактора ушло?
mrlolthe1st Автор
16.10.2018 07:33Нет, Вы, наверное, не поняли, тут даже речи о текстовом редакторе не шло. А основную часть времени заняло чтение документации по железу, реализацию и отладку драйверов по этим докам. Да и вовсе — текстовый режим, который AX=3, из 0x10 прерывания. С выводом не всё так легко, как вы думаете. Прочитайте тут, как организуется вывод на экран: muruganad.com/8086/8086-Assembly-Writing-Directly-to-Video-Memory-B800.html
mavrix
16.10.2018 13:55а причем здесь прерывание DOS (int 21h), когда я так понял через BIOS-ное прерывание (int 10h) нужно выводить
mrlolthe1st Автор
16.10.2018 13:56Нет, Ax=3 прерывания 0x10 устанавливает видеорежим 80x25 текстовый.
mavrix
16.10.2018 14:04сорри, не доглядел, что по ссылке в листинге int 21h используеься ah=4C — выход из программы с кодом
Krey
16.10.2018 14:34Это был сарказм, намекающий на почти полное отсутствие какой либо технической информации в статье и явное злоупотребление тэгами. Например TCP встречается только в тэге и в списке того, что сделано.
Я писал напрямую в видеопамять во времена доса из реального режима процессора. Вот и интересно было бы узнать, как оно в 21 веке делается во времена UEFI и нативных 64 битных режимах, что стало проще, что сложнее.
Вот вы кстати начали с режима совместимости efi, прыгая по режимам, зачем? Использовали ли вы какие то из привилегированных режимов работы проца?
GilevVyacheslav
16.10.2018 07:26Круто!
Если такую ОСь немного доработать, то Вам можно собственные «стораджи» производить и продавать, тем более что сейчас рынок полок с NVMe имхо не достаточно освоен «гигантами»
AlexPancho
16.10.2018 08:28Юсб это круто, но что кроме ФАТ32 читает?
Что с памятью? спокойно адресует до 4ГБ?
Что с сетью? пингует 8.8.8.8?
dmxvlx
16.10.2018 08:53Александр, огромный вам респект! С интересом ждём новостей по данной теме!..
1) не хочу навязывать, сам частенько грешу написанием прототипов в текстовом редакторе (хоть и навороченном), но IDE будет удобнее для подобной разработки (какой-нибудь codeblocks например).
2) посмотрел скрины в ВК, там файл исходников ядра перевалил за 15K строк, — не оч удобно на мой взгляд. Раскидайте функционал по файликам (с соответствующими функционалу именами), продумайте архитектуру для своего проекта: типа в папке drivers — драйвера, в core — ядро ОС, utils — всякие вспомогательные ф-ии…
Вопрос: каким компилятором пользуетесь?
mrlolthe1st Автор
16.10.2018 08:571)Я использую VS 2017 Community для разработки — осень удобно
2)Нет, это я при помощи gcc собираю всё в один файл(cpp.exe ...)
Компилятор, как уже понятно — GCC
dimykus
16.10.2018 09:09А главное — никаких отладчиков, выводи в текстовый режим, либо в окошечки — повисло — ставь return'ы.
В чем проблема прицепиться gdb к qemu?mrlolthe1st Автор
16.10.2018 09:12+1Проблема в дебаге на реальном железе, ведь что-то что работает на эмуляторе может не работать на железе.
ice2heart
16.10.2018 09:47-1Ааа… зачем монтировать диски к буквам… Это же неудобно… Даешь нормальный рут.
Oplkill
16.10.2018 23:50+1Может кто-то сказать почему конкретно «windows-like» монтирование дисков не удобно и только «linux-like» наилучший из существующих?
ZyXI
17.10.2018 01:43+2Потому что слишком ограничено. И либо провоцирует сложности с контролем доступа, если вы, к примеру, хотите в многопользовательской ОС использовать ваш Яндекс.Диск как каталог, но не давать доступа к нему другим пользователям. Либо заставляет создавать отдельные механизмы: вы знаете, что в Windows можно примонтировать диск в пустую NTFS папку? Вопрос: если в Windows с дисками считают необходимым иметь такую функциональность, то зачем реализовывать заведомо слабофункциональную систему в новой ОС?
Кроме того, попробуйте придумать, как выглядел бы тот же chroot с Windows?подобным монтированием? А это ведь неплохой инструмент отладки изменённого окружения при неизменённом ядре.
Ещё вы с linux?подобным монтированием вы можете отправить Program files на отдельный диск, даже если система пока не поддерживает ничего, кроме FAT32, а в FAT32 нет символических ссылок (не говоря уже о жёстких ссылках, которые для каталогов не поддерживаются нигде).
Ещё, кстати, а зачем в новой ОС обратные косые черты в пути? В бо?льшей части языков программирования это символ экранирования и потому нифига не удобен в путях.
Ayahuaska
17.10.2018 11:22Как вообще может быть жёсткая ссылка на каталог? это ж по сути просто ещё одно имя для одних и тех же данных, а каталог — это ж не данные, а просто узел в дереве путей.
netricks
17.10.2018 11:44Строго говоря, возможны разные реализации, но таки обычно директорий представлен специальным типом файла и описан в полноправной inode. Так что жёсткая ссылка на него допустима так же, как и на любой другой файл.
ZyXI
17.10.2018 12:15Как сказали выше, представления разные. Но каталог — это часто по сути просто специальным образом отмеченный файл, в котором в некотором виде хранится таблица соответствия имени файла в каталоге и его inode. «Жёсткая ссылка» на файл означает, что один inode присутствует в двух таких специальных файлах. Т.к. каталог — тоже файл — то с помощью hex редактора по идее можно сделать жёсткую ссылку на каталог. Но тут возникают проблемы целостности: что означает
hardlink/..в таком случае? И это не говоря уже о возможности подсунуть какой?нибудь ничего не подозревающей программе, рекурсивно обходящей каталоги, каталоги с бесконечной вложенностью — а даже сейчас не все такие программы умеют обрабатывать бесконечную вложенность символических ссылок (привет, Vim, как ни странно).khim
17.10.2018 12:28+1На самом деле все эти сложности, вами описанные, «яйца выеденного не стоят». И вообще в ранних версиях Unix жёсткие ссылки на каталог были допустимы. Проблема с ".." решалось тривиально: записи "." и ".." физически присутствали на диске…
Отказались от них по одной, но очень серьёзной причине: подсчёт ссылок. Именно так работает «сборщик мусора» на диске. Вот если жёстких ссылок на каталоги нет — он гарантированно работает. А если есть — то не работает. Всё.mayorovp
17.10.2018 13:01Как раз физическое присутствие на диске записей
.и..мешает делать жесткие ссылки на каталог (да и вообще любые ссылки) — потому чтоfoo/bar/link/..внезапно оказывается не то же самое чтоfoo/bar.khim
18.10.2018 00:39+1Как раз физическое присутствие на диске записей
А этого, внезапно, никто не может гарантировать и сегодня. Потому неясно чем вам помешают записи.и..мешает делать жесткие ссылки на каталог — потому чтоfoo/bar/link/..внезапно оказывается не то же самое чтоfoo/bar..и..на диске и хардлинки — зато ясно, что «виртуальной»..быть никак не может, если хардлинки разрешены.
да и вообще любые ссылки
Тем не менее симлинки на каталоги существуют — несмотря на все изобретённые вами запреты.mayorovp
18.10.2018 06:28> А этого, внезапно, никто не может гарантировать и сегодня.
Так уж и никто? На винде это как раз гарантировано.
daggert
17.10.2018 12:41+1И либо провоцирует сложности с контролем доступа, если вы, к примеру, хотите в многопользовательской ОС использовать ваш Яндекс.Диск как каталог, но не давать доступа к нему другим пользователям.
Проблема с софтом ЯД который по умолчанию не ставится в "Мои Документы" или профиль пользователя, а лезет в корень диска. На убунте если он пойдет в /YandexDisk с правами 777 вы-ж не будете линукс ругать?
ZyXI
18.10.2018 00:16Я не знаю про софт ЯД на Windows, на linux я вполне себе использую davfs2 для доступа к ЯД. В сообщении это просто пример того, что вы не захотите монтировать на букву диска, а не тычок в сторону Windows — как я указал там же, я знаю, что в Windows реально можно монтировать не только на букву, просто это видится отдельным механизмом, тогда как linux вариант выглядит более целостно.
mrguardian
16.10.2018 09:56Очень хотелось бы почитать чуть более подробно и в деталях. Надеюсь на выход следующих статей.
yurisv3
16.10.2018 10:00А главное — никаких отладчиков
Вот это как-то непонятно.
Отладочный интерфейс(ы) уже встроен(ы) в QEMU (на выбор), сервер GDB — легок, протокол прост, на х86 не rocket science подпилить себе готовый. Это ведь колоссальная экономия времени, вообще любой значимый проект должен (и обычно так и есть) начинаться с создания адекватных отладочных и тестировочных средств. Даже самых простейших. Это многократ окупается!mrlolthe1st Автор
16.10.2018 10:24Вы представьте, что мне надо отладить примерно 10000 строк(и это не шутка! Примерно столько занимает драйвер PCI вместе с EHCI)ссемблерного кода, я не думаю, что GDB мне в этом поможет лучше, чем мой метод.
yurisv3
16.10.2018 11:16-110000 строк
но
столько занимает драйвер PCI (вместе с EHCI) ассемблерного кода
это всего лишь 2-3 тысячи строк на С. Пффф…
Вот что я вам скажу.
Долбление даташитов тоже дело нужное в нужное время и в нужном месте, но конкретно то, что вы долбите — окончательно устареет раньше, чем вы реализуете полноценную поддержку, используя лишь ассемблер (при этом асм в критических местах — это годно). Всего лишь года через 3 вы опять окажетесь там, с чего начинали.
So you run and you run to catch up with the sun but it's sinking
Racing around to come up behind you again.
The sun is the same in a relative way but you're older,
Shorter of breath and one day closer to death.
… ©
При этом вы проваливаете овладение инструментарием и методологией разработки, а это и есть собственно квалификация. Архитектурные вопросы ОС я даже не упоминаю — у вас просто руки не дойдут заняться серьезно.
(если что — и ОС писал, успешно — железяки прожили больше 15 лет, и ядро [Linux] портировал на альтернативные SoC [ARM, SH3])
eugenk
16.10.2018 22:28+1Вот это как-то непонятно.
Бывают ситуации, когда отладчики скорее мешают. Например у меня сейчас некий проект для микроконтроллера(pic18f4550), где программа представляет собой практически один большой обработчик прерываний. В частности управляющий мощностью источника питания, питающего некую нагрузку. Ну и как прикажете это отлаживать? Если я где-то стопорну программу, перестанет обрабатываться прерывание. Напряжение источника питания уйдёт. Нагрузка если и не сгорит, то будет работать в совершенно нештатном режиме, выдавая непонятно какую диагностику… Вот и остаются только отладочные сообщения. Мне кажется для низкоуровневого программиста, умение работать без отладчика, навык такой же важный, как знание отладчика.
CodeRush
16.10.2018 23:13Умение пользоваться инструментами, облегчающими жизнь и ускоряющими разработку — намного важнее умения обходиться без них, потому что время — ресурс невосполнимый. Опыт работы без отладчика придет сам, когда придется попасть в ситуацию вроде вашей, и можно даже специально тренировать этот навык иногда, когда время позволяет, но разработка ОС общего назначения на уже работающем оборудовании с доступными (и весьма развитыми) средствами отладки — это мазохизм в чистом виде.
mrlolthe1st Автор
16.10.2018 23:32В основном с вами согласен, но есть некоторые аспекты, которые надо дебажить долго, много и упорно. К середине написание ОС я сам стал как процессор отслеживать ошибки, и это нереально круто: всего лишь взглянул на код — и ты сразу видишь ошибку.
CodeRush
16.10.2018 23:49+1Самая большая проблема в том, что этот подход не масштабируется. Это у вас пока еще ОС маленькая, и ума хватает охватить ее целиком, думать как процессор, и вот это все. Реальные системы давно уже не укладываются целиком в голову одного человека, и потому нужно всеми силами разгружать эту самую голову, автоматизировать всю рутину, изучать инструменты, подходы, заниматься упрощением, декомпозицией, короче — снижением когнитивной нагрузки. Чем проще в вашем коде разобраться — тем этот код лучше, и даже если сейчас вы сами в нем сейчас разбираетесь досконально и «сразу видите ошибку», уже завтра это обязательно изменится.
Ошибки, которые сразу видно, можно даже за ошибки не считать, потому что они тривиально находятся и справляются, и вот после того, как их исправили, начинается самое интересное — ошибки в железе, ошибки, которые не повторяются, ошибки, связанные с взаимодействием нескольких частей системы, и т.п., и чем больше инструментов вы освоите (санитайзеры, статические анализаторы, визуализаторы карты памяти, обработчики точек останова, и все остальное, придуманное для отладки именно «тяжелых случаев») — тем лучше будет и для вас, и для пользователей вашей ОС, если таковые появятся.JerleShannara
17.10.2018 00:18+1Поскольку тут речь идёт о драйверах, то надо вспомнить ещё и «недокументированные» и «неверно документированные» карты регистров и прочее в даташытах. Очень приятно бывает на такое наткнуться.
Что-то типа «end-user software must write 0xBEEFDEAD in D14F9x_411_12b after enable», а на практике там надо 0xFACECAFE записать до enable(всё взято с потолка и от балды). Кушать такие подарки очень вкусно и вредно для клавиатуры и психики.CodeRush
17.10.2018 00:42+1Еррату не забудь еще, которую никто не читает.
«Мы обнаружили, что при определенных условиях у нас процессор намертво зависает. Чинить мы это, конечно, не будем, поэтому вы просто софт с вот такими инструкциями не запускайте».
Или еще лучше, «мы тут после нескольких лет производства обнаружили, что наше замечательное железо с DMA иногда пишет в физическую память по вот этим адресам, и портит там все. Не кладите туда ничего важного больше.»
Тут с отладчиком то не отладишь, а без отладчика можно вообще с ума сдуреть.JerleShannara
17.10.2018 01:38+1Бррр, особенно приятно такое читать, когда у тебя мануал под Rev. F чипа, а начиналось всё ещё на Rev. A
ExplosiveZ
16.10.2018 11:02Будет совместимость с posix?
mrlolthe1st Автор
16.10.2018 11:05Так же передо мной стояла задача создать собственную архитектуру, удобную мне
abondarev
16.10.2018 16:54+5Извините, а при чем тут архитектура?
POSIX это API, то есть программный интервейс приложений. Или я чего то не понимаю?netricks
17.10.2018 10:57+1У меня есть сказать по этому поводу.
В целом posix — это конечно интерфейс. Но этот интерфейс закладывает в своём api определенные черты архитектуры лежащей под ним системы. В posix заложены концепции процессов, многозадачности, примитивов синхронизации, файловой организации данных и ввода вывода и прочее…
Следуя posix, сложно написать что-то кроме unix(в широком смысле)…khim
17.10.2018 12:31+1Следуя posix, сложно написать что-то кроме unix(в широком смысле)…
Windows NT изначально писалась под POSIX (именно потому сделать поддержку Debian/Ubuntu оказалось так просто: всё важное/сложное было в ядре начиная с первой версии, нужно было только кой-какие адаптеры доделать), тем не менее Windows не то, чтоб уж очень сильно на Unix похожа…mayorovp
17.10.2018 13:04То, что Windows NT писалась под POSIX еще не означает что Windows NT POSIX-совместима. А вот если бы была совместима — была бы и правда на Unix похожа.
khim
18.10.2018 00:43То, что Windows NT писалась под POSIX еще не означает что Windows NT POSIX-совместима.
Она реализовывала POSIX.1 (но не POSIX.2) — иначе её нельзя было бы продавать госструктурам.
А вот если бы была совместима — была бы и правда на Unix похожа.
Осталось понять что именно вы этой фразой имеете в виду… она была сертифицирована как POSIX-совместимая начина с самой первой версии… но на Unix не была похожа уже тогда…
abondarev
17.10.2018 12:50«мне кажется, что тут произошла типичная подмена понятий, Вы путаете теплое с мягким»:). Ну, то есть, на мой взгляд, Вы заблуждаетесь.
POSIX имеет 4 раздела, здесь и далее можно проверить пройдя по ссылке. Один из них «Системные интерфейсы (англ. System interfaces) — список системных вызовов языка Си.», под интерфейсом также понимают раздел «Основные определения (англ. Base definitions) — список основных определений и соглашений, используемых в спецификациях, и список заголовочных файлов языка Си, которые должны быть предоставлены соответствующей стандарту системой.».
Также есть много профилей, в одном прямо сказано
Стандарт POSIX 1003.1 подходит не для всех операционных систем. Встраиваемые операционные системы не всегда реализуют поддержку тех или иных функций. Стандарт POSIX 1003.13 описывает подмножество стандарта POSIX 1003.1 для встраиваемых систем, которое разделено на 4 профиля. Профили были разработаны, чтобы обеспечить переносимость программ на уровне исходных кодов для операционных систем с ограниченными возможностями.
Ну и так далее.
И главное в приведенной же ссылке есть раздел "POSIX для Windows", ну не будете же Вы утверждать, что Windows это «UNIX в широком смысле».
Следует отметить, что в списке POSIX совместимых, есть например Minix, а он как известно микроядерный, вот последнее (микроядерность) является архитектруной особенностью.
Извините за занудство!netricks
17.10.2018 13:10+1Спасибо за занудство :).
В качестве показательного примера, разрушающего высказанную мной выше концепцию, можно еще QNX вспомнить… Хотя, если не ошибаюсь, он не полностью posix, но он, во-первых, похож и пытается, а во вторых мало того, что микроядерный, так еще и может использоваться для создания распределенных систем…
Но таки, это все таже процесно-файловая система (как, кстати и виндоус).
QNX, кстати, весьма показателен в том плане, что он для поддержания посиксовских write/read поверх микроядра городит специальный менеджер файловой системы. На мой взгляд, это то что называется противоречащие друг другу параграфы. То есть, мы микроядро и у нас модель сообщений и мы можем в namespace, но мы так же и posix и не умеем в posix без ioservice… (Я передергиваю, конечно. Просто, хочу продемонстрировать, что ради posix приходится идти на жертвы).
…
У меня, кстати, встречный вопрос. Как в embox, который вроде как может в posix, соотносится концепция schedee, который, насколько я понимаю, не всегда процесс с, собственно, posix?abondarev
17.10.2018 14:14По поводу QNX и микроядра, могу только повторить, что уже сказал, это не связанные вещи. Как реализован системный вызов никого не интерисует, важно чтобы он был. То есть берем операцию чтения, в Linux это сискол с таким то номером, выполняется по сути дела на том же потоке, только в ядреной его части. В микроядре, происходит сискол, который отправляет сообщение в другой пользовательский поток (процесс, задачу, ...) и уже этот поток обрабатывает сискол, а потом точно также посылает ответ.
Но, еще раз повторю, с точки зрения интерфейса это вызов open/read/write сигнатура у них стандартная.
По поводу Embox, все тоже самое. Как организован планировщик не важно. Если вопрос про легковесные потоки, то Вы совершенно правы, это не полноценный posix. Но там фишка была в том, что нам удалось объекты синхронизации (те же мьютексы) использовать в этих легких объектах. Ну и да интерфейс pthread -ов остается если нужен. Причем, поскольку мы слегка ученые, мы не могли не сделать все максимально абстрактным, и в одной очереди планирования, могут крутиться все объекты, поскольку они наследованны от schedee.
По поводу процессов отдельная песня, но в большинстве случаев, это опять же одни и те же объекты планирования что и потоки. Например в linux clone создаст некий объект планировния, а его характеристики (процесс или поток) укажутся в качестве параметров. Ну и да, fork очевидно тяжелее чем pthread_createnetricks
17.10.2018 14:29А удалось использовать легковесные потоки с ссылающими друг на друга драйверами устройств? Ну, допустим, когда драйвер block_device флешпамяти использует драйвер spi и так далее?
abondarev
17.10.2018 15:59конкретно про блочкие устройства не скажу, но некоторые вещи (драйвера) были переведены на легкие потоки,
netricks
17.10.2018 16:41Интересна именно ситуация со вложенными драйверами, когда каждый драйвер предоставляет блокирующие операции. Получается, что первый драйвер должен для выполнения блокирующей операции несколько раз вызвать блокирующую операцию следующего драйвера. Чего as is в условии «лёгких потоков» он сделать не может, ибо не помнит, на чем он на прошлой итерации остановился.
Есть решение через предоставление специального апи с запоминанием состояния для таких операций. Мне было интересно, поддерживается ли что-то подобное в embox.abondarev
17.10.2018 17:52Думаю я Вас понял.
Да, легковесные потоки не могут хранить свое состояние. Но они имеют параметр через который обработчику можно передать его из вне. Готового API нет. Мы делали это через внешние объекты или через очереди сообщений
mayorovp
17.10.2018 13:11А вот давайте перейдем по вашей же ссылке.
Часть 1. POSIX.1. Системное API для языка Си
… Стандарт описывал следующие темы:
- файлы с информацией о пользователях и о группах
- форматы архивов tar и cpio
Где находится /etc/passwd на винде? Кто-нибудь вообще хоть раз видел cpio-архив на виндах?
POSIX.2. Командная оболочка и утилиты
- командный интерпретатор (на основе System V Bourne shell)
И давно cmd.exe является sh-совместимым?
abondarev
17.10.2018 13:56давайте.
Где находится /etc/passwd на винде?
Кто Вам сказал, что файлы с информацией должны как то конкретно называться?
Кто-нибудь вообще хоть раз видел cpio-архив на виндах?
Я видел, это просто архивные файлы в них свой формат упаковки информации, но никто не препятствует сделать свою утилиту которая бы понимала данный формат.
И давно cmd.exe является sh-совместимым?
опять же никто не говорит, что cmd.exe это bash, но никто не запрещает запустить программу интерпретатор который превратит командную строку в совместимую с shell -ом
Cygwin предоставляет все перечисленные Вами средства. Хотя я могу и ошибаться, давно не использовал. Есть еще MinGW, если мы говорим именно о совместимости на уровне программных интерфейсов.mayorovp
17.10.2018 14:04Кто Вам сказал, что файлы с информацией должны как то конкретно называться?
Ну так и я спрашиваю как он называется и где лежит.
никто не запрещает запустить программу интерпретатор который превратит командную строку в совместимую с shell -ом
Cygwin предоставляет все перечисленные Вами средства.POSIX именно что требует наличия такого интерпретатора с известным стандартной библиотеке Си именем. Но msvcrt.dll не знает ни про какой Cygwin.
PS Я утверждаю, что голая винда без Cygwin/MinGW/WSL — не POSIX-совместима. Каким образом установка Cygwin может это опровергнуть? :-)
abondarev
17.10.2018 15:58а я утверждаю, что наличие раздела «POSIX для Windows» подразумевает, что Windows можно сделать в достаточной степени соотвествующим стардарту POSIX, а значит наличие интерфейса POSIX не накладывает никаких ограничений на архитектуру ОС.
Лично я не вижу противоречий между нашими утверждениями.khim
18.10.2018 00:50а я утверждаю, что наличие раздела «POSIX для Windows» подразумевает, что Windows можно сделать в достаточной степени соотвествующим стардарту POSIX, а значит наличие интерфейса POSIX не накладывает никаких ограничений на архитектуру ОС.
Накладывает. И довольно серьёзные. Просто поддержка POSIX.1 была в техзадании на Windows NT. А уже POSIX.2 и прочие — можно реальзовать отдельным аддоном если ядро у вас POSIX.1 поддерживает.
khim
18.10.2018 00:49POSIX именно что требует наличия такого интерпретатора с известным стандартной библиотеке Си именем.
POSIX.1 этого не требует, извините. А POSIX.2 не был реализован потому что требования контрактов с правительством требовали только POSIX.1
PS Я утверждаю, что голая винда без Cygwin/MinGW/WSL — не POSIX-совместима.
Только уточните уж — о какой винде речь. Windows NT 3.1 и Windows 3.51 — совместимы. И с POSIX и с OS/2 (только 16 битный API) и даже с HPFS. А вот уже Windows NT 4.0 — нет, потому что требование поддержки POSIX перестало быть обязательным.
Zet_Roy
16.10.2018 11:46-3ОС под архитектуру x86
Почему не под архитектуру x64?
FAT32
Почему не ReFS?
SVGA
Почему не HDMI?
Зачем ты пишешь ОС которая на момент разработки уже не актуальна?
Лучше пиши ОС которая использует новейшие технологии и раскрывает весь потенциал ПК.Extravert34
16.10.2018 11:55+2Подозреваю, в таком случае пост вышел бы через пару лет и назвался "написание собственной ОС за 3 года"
ionicman
16.10.2018 11:59+1Во-первых:
В основном я преследую лишь спортивный интерес, получение опыта для себя в системном программировании и написания драйверов для устройств, которые используются повсеместно.
Во-вторых: если начать сразу подниматься на Эльбрус без подготовки — вероятность дойти до вершины стремится к нулю — надеюсь, аналогия понятна?opckSheff
16.10.2018 14:20О, точно, спасибо что напомнили.
В топку х86, надо было сразу писать ОС, которая раскрывает весь потенциал архитектуры «Эльбрус»!Ad_xname
17.10.2018 17:42Такие есть, и не одна)
Кстати они вроде набирали разработчиков OS под свое железо, правда там все же
банальный Linux, хотя и с серьезной оптимизацией под архитектуру.
mrlolthe1st Автор
16.10.2018 12:05+2SVGA не разъем, а стандарт, HDMI же — разъем. Большинство юзеров пользуется шиндой, а там FAT32.
Архитектуры x64 не существует. x86 подразумевает под собой 386, 486, 586 — а это уже проц с поддержкой 64 битных инструкций.IvaYan
16.10.2018 12:38Большинство юзеров пользуется шиндой, а там FAT32
А разве там не NTFS?
Архитектуры x64 не существует. x86 подразумевает под собой 386, 486, 586 — а это уже проц с поддержкой 64 битных инструкций.
Присоединюсь к вопросу, почему не под систему команд AMD64?
Newbilius
16.10.2018 12:39большинство юзеров пользуется шиндой, а там FAT32.
Информация устарела лет на 10 минимум — по дефолту NTFS. Ну а FAT32 в основном на флешках.mrlolthe1st Автор
16.10.2018 12:48NTFS является закрытой ФС, реверс-инженерить её нет желания.
Paskin
16.10.2018 14:42Спеки опубликованы несколько лет назад
Oplkill
16.10.2018 23:53+1Если всё было так просто, то Реакт ОС поддерживала бы NTFS в обе стороны уже давно, но пока только может чтение, хотя разрабов там больше чем единица…
pathoswithin
18.10.2018 00:07Чем занимаются в ReactOS столько времени — отдельная тема.
У них этот проект был на GSoC, но студенты естественно за них всю работу не сделают…
pathoswithin
18.10.2018 00:02NTFS уже давно отреверс-инженерили, написали книги, написали открытый драйвер для линукса на Сях, а для КолибриОС — на ассемблере, я когда им занимался, даже красивую html документацию обновил. Чего ещё желаете?
JerleShannara
16.10.2018 20:08+1FAT32 умеет 99% всяких утюгов и бетономешалок с USB/SD разъемом + она тупа и проста как пробка. На этом плюсы этой ФС заканчиваются. И выбор поддерживаемой ФС тут становится совершенно ясным.
saboteur_kiev
17.10.2018 00:53Но почему тогда не ext-fat, которая и более открытая, и сняты некоторые ограничения по максимальному размеру файла и диска. А разница вроде невелика…
JerleShannara
17.10.2018 01:40А вот её не каждый утюг умеет, плюс (могу ошибаться), у неё ещё недавно были проблемы с патентами, что не есть хорошо
thedima
16.10.2018 16:19Только за понимание тонкостей построения архитектуры (и там ниже про AMD64), я начинаю верить в перспективы Вашей ОС, желаю успехов, буду следить за проектом
saboteur_kiev
17.10.2018 00:56А что такое «шинда»?
Я не помню современную популярную ОС, где в основном используется FAT32.
euroUK
18.10.2018 01:39Я конечно ОС свою не писал, но помню по спекая Интел, что у x64 адресация памяти отличается от x86. Для x86 вроде бы сегментная адресация и пляски с соответствующем бубном, в x64 сегменты не используются и таблицы соответсвующие не нужны. Или я не прав?
mayorovp
18.10.2018 06:31Вся сегментная адресация в современных ОС сводится к созданию нескольких сегментов на всю память каждый, после чего они игнорируются.
Extravert34
16.10.2018 12:03+1Не собираетесь поучаствовать в разработке опенсорс проектов — ReactOS, Kolibri и тд?
mrlolthe1st Автор
16.10.2018 12:05+1С удовольствием бы поучаствовал.
Papuas64
16.10.2018 16:19ОС Haiku — сейчас вышла в бету. Посмотрите, красивая в части реализации. Нуждается в разработчиках.
barker
16.10.2018 12:21+1Я обычно за велосипеды минусы ставлю, но тут всё как-то без претензий велосипед, прочитал — как будто в ностальгические девяностые-нулевые попал. В хорошем смысле. Однозначно хочется продолжения)
khim
16.10.2018 22:30+3В велосипедах нет ничего страшного, это вообще лучший способ что-либо изучить. Главное — понимать что ты делаешь велосипед для изучения и не планировать перестроить его, со временем, в самолёт.
KES777
16.10.2018 12:53Когда в далёком 2002-2003 тоже баловался написанием ОС. Всё порываюсь в своей файло помойке найти исходники (если найду, то выложу на github)
Функционала совсем мало было реализовано: загрузка с дискеты 3.5" (Помню, как будто вчера было: AA55 =) ), и обработка прерываний от клавиатуры и мыши. USB, помоему, ещё небыло.
dom3d
16.10.2018 13:04Мне кажется, что свою ОС — это даже круче чем свою программа.
Я уже несколько раз говорил, что каждый хороший программист должен иметь свою программу.
Хотя, согласно последним исследованиям британских ученых для рабочих проектов нужны и программисты — простые гребцы.
Часто такие ребята для проекта (устоявшегося) представляют больший интерес чем гении.Whuthering
16.10.2018 15:15+2Как же ловко вы всех, кто по-полной выкладывается на основной работе, а свободное время тратит на отдых, семью и хобби записали в «плохие программисты»…
dom3d
16.10.2018 15:57Не, ну вот прямо в плохие программисты.
Я слишком люблю программирование — это мое хобби и полагаю, что другие тоже должны это делать.
Это мое мнение и не собираюсь казаться объективным.
algotrader2013
16.10.2018 18:38+2Text Generation LSTM тестируете, использую рейтинг коммента, как вектор У?
QtRoS
16.10.2018 19:12Дадите оптимизма взаймы? :)
Боюсь, это не нейронка, а все же мозг...algotrader2013
16.10.2018 19:15+1Да запросто) Ведь это может быть и настолько продвинутая нейронка, что ее путают с мозгом даже после разоблачения…
netricks
16.10.2018 13:19+1У меня вопрос о вашем бэкграунде (в части знаний).
Какими источниками помимо OSDev вы пользовались/пользуетесь?
В частности интересны источники информации по визуальной подсистеме. Какая архитектура в большей степени повлияла на данную разработку?
И, наконец, вопросы для статистики:
— Сколько весит ядро?
— Сколько времени эта весчь загружается?mrlolthe1st Автор
16.10.2018 13:41Грузится по-разному, в зависимости от куда и сколько девайсов у вас имеется, на эмуляторе — 4-7 секунд, на желкзе 3-10
madf
16.10.2018 13:33Ни чо не понял. Где качать образ и какое железо поддерживается? Будет ли работать с винтами не в IDE режиме, а RAID без рэйда?)
amarao
16.10.2018 13:55Очень советую сделать отладчик через последовательный порт. Возможность посмотреть на память в рантайме — бесценно.
linuxdeveloper.blogspot.com/2012/05/debugging-linux-kernel-over-serial-port.html
Aero3511
16.10.2018 14:09Драйвера на ассемблере или на C?
mrlolthe1st Автор
16.10.2018 14:09И на том, и на том
Aero3511
16.10.2018 20:44А есть какое то предпочтение или зависит от типа драйвера? (Просто новичок в этом и поэтому пытаюсь разбираться каждый день)
JerleShannara
16.10.2018 21:33+1Какие-то части работы с девайсами гораздо проще сделать на ассемблерной вставке. К примеру девайс запускает сепулькирование по выводу в порт 0A67h значение 0A53h, об окончании он сигнализирует прерыванием F4h, а результат вычитвается из DS:ESI. На C писать такое может быть неудобным, а на ассемблере это всего несколько строчек.
Aero3511
16.10.2018 23:04Аааа как же много еще предстоит изучить) Ну спасибо за ответ и удачи в написании ОС)
SmithV
16.10.2018 14:20Респект и уважение! Высшее мастерство — отделить нужное от ненужного, которого 99% у любой операционки из-за проблем совместимости или навороченности ненужными или редкоиспользуемыми фичами.
Loki3000
16.10.2018 14:23написание такой ОС, которая могла бы позволить максимальную производительность для каких-то конкретных задач
Так а под какие задачи писалось? И какого прироста производительности удалось добиться по сравнению с существующими решениями?mrlolthe1st Автор
16.10.2018 14:53Я не писал ОС под конкретные задачи, но придерживался того, чтобы ОС выдавала максимальную производительность.
romalik
16.10.2018 16:18А какие архитектурные решения для этого были приняты? Какой алгоритм планировщика был выбран? Как реализован механизм системных вызовов, межпроцессное взаимодействие, переключение контекстов?
qpwoei
16.10.2018 16:01+1увлекательная задача, похожим страдал в 97-99-х годах, сначала Turbo Vision паскалевский на асм переписал, после с защищенным режимом разобрался и так же начал свою ОС пилить на чистом асме. Но, захотелось есть, на рынке платили только прикладникам которые задачи бизнеса решают и скатился по наклонной к жаве. :)
vheinitz
16.10.2018 16:17Это троллинг?
Наверное если написать статью как я сходил по большому соблюдая все формальности, её хабр предложит читателям.
Автор написал 20 сточек на ассемблере, присочинил остальное и решил написать про свои фантазии статью.mrlolthe1st Автор
16.10.2018 16:17Нет, это реальная ОС, расскажу в ближайшее время про все, что реализовано и как я это реализовал
Oplkill
17.10.2018 04:34Это не отменяет того что этот пост ниочем, просто пустой пост...
qpwoei
17.10.2018 14:59-1если парень виртуальную машину Java туда прикрутит и на ней можно будет запустить хотя бы какой Tomcat, а так же покажет увеличение производительности хотя бы на 10-15%, можно будет уверенно сказать что ОС имеет право на жизнь и на нее можно будет выделить десяток млн рублей для реализации нескольких экспериментальных фич которые будут востребованы на рынке частных бэкенд серверов.
Я бы порыл в две стороны Эльбрус и национальные производители бытовой электроники.
Karpion
16.10.2018 16:56+21) Интересно было бы сделать систему модульной. Т.е. чтобы любой желающий мог написать драйвер любой файловой системы и влить в операционку. Если в операционке поддерживается только FAT32 и не заложена возможность расширения — это мёртворождённый уродец.
2) Очень рекомендую использовать модель/API работы с драйверами — как у уже существующей системы, желательно Linux или FreeBSD. Чтобы можно было тащить драйверы оттуда.
3) Желательно отделить юзерский интерфейс (GUI, Shell) от остального — чтобы его можно было заменять. В т.ч. имеет смысл подумать об отказе от окон — как на смартфонах/планшетах.
4) Очень советую делать операционку кросс-платформенной. Вообще, изначально имело смысл закладываться не на 86, а на нормальный процессор типа ARM. Заодно не будет проблем с изучение дико сложной архитектуры 86, набравшей в себя массу исторического дерьма и вынужденной тянуть с собой всё это из-за боязни потерять совместимость со старыми программами.
5) Вы ничего не написали про API для юзерских программ. В идеале — надо бы смотреть в сторону POSIX.
6) Как тут уже верно заметили — не надо мапировать файловые системы на буквы, ведь их всего 26. Есть два хороших варианта:
- Как в Unix — монтирование в единое дерево файлов.
- Явно указывать источник файлов. Например: nfs: сервер:/путь/файл, smb: сервер:/путь/файл, hdd0:slice1:/путь/файл. Этот вариант интересен тем, что через механизм типа символьных линков можно будет подвесить все файловые системы на общее дерево. Также для источников файлов можно назначить однобуквенные псевдонимы/алиасы.
mrlolthe1st Автор
16.10.2018 17:18-2Про первое — это реализовано как драва в шинде. Второе — абсолютно согласен, но для этого нужны программисты и тп. Думаю, будет интересно обсудить все в телеге.
Oplkill
16.10.2018 23:573) да здравствует калькулятор занимающий 100% экрана
Karpion
17.10.2018 01:58Ну, вместо окон можно использовать фреймы.
А зачем Вам во время работы с калькулятором надо иметь на экране ещё что-то другое?Oplkill
17.10.2018 04:37Чтобы смотреть одновременно и на калькулятор и на другое окно. Числа которые я буду считать не из головы ведь буду писать, а брать из другого окна и удобнее будет если мне не нужно будет каждый раз переключаться между ними, а просто глазами взглянуть
dcc0
16.10.2018 19:00Только вчера я сказал себе! «Наступило время, когда уже никто в одиночку не напишет систему или уже не возьмется за это»… И вот, пожалуйста. В карму автору и успехов!
Berkof
16.10.2018 19:34Думаю, что данная ОС в настоящий момент наиболее интересна именно как сорс для знакомства с темой… Т.е. документацию почитали — хорошо, но не сильно понятно и остаётся это обычное «да блин, это профессора пишут, мне не пригодится, можно и забыть», а если потом провести практическое занятие и, например, перевернуть порядок бит в каждом секторе блочного устройства, да так, чтобы оно ещё потом и работало — вот это круто… У меня так знакомый с Ansible разбирался — залез в актуальную версию, сломал мозг, потом выкачал альфу и дошёл до v1.0 потихоньку, понял какие принципы в системе, теперь может эффективно в код лазить.
morgot
16.10.2018 20:01+3Расскажите, как Вы реализовали TCP/IP стек. Вообще, мне очень слабо верится, что это все написано самостоятельно, а не скопипащено откуда-то. Но… может и есть еще гениальные люди.
xcore78
17.10.2018 01:54Автор мог не реализовывать стек полностью, а сделать минимально работающую модель. Например, вообще нет IP options + только один алгоритм в TCP (или что-то вне стандарта, что, однако, будет работать в каких-то наборах условий). Гениальности тут не надо, нужна усидчивость.
s-a-u-r-o-n
16.10.2018 20:29+1К сожалению, работоспособных любительских ОС под desktop сейчас уже довольно много, а вот мобильных почти нет. Не планируете ли осваивать это перспективное направление?
ark_yt
16.10.2018 21:16Крутая статейка, я очень хочу помочь кодом! Как можно с вами связаться? Мне 1110 лет…
theonlymirage
16.10.2018 22:11+2По вашему описанию, за полгода сделано очень многое. Если всё это написано с нуля самостоятельно, то поздравляю вас!
Интересует вопрос лицензии распространения? Будут ли исходные коды Open Source? И если да, то когда (или где уже сейчас) их можно увидеть?mrlolthe1st Автор
16.10.2018 22:22-5Целиком кода не будет. Будет описание что да как с примерами.
Doctor5772
17.10.2018 12:33+2Очень жаль.
Наверняка найдутся желающие помочь в разработке, а так же использовать наработки для своих целей, и тут без OpenSource будет тяжело. К тому же нет образа хотя бы для qemu, что бы посмотреть самому.
RolexStrider
16.10.2018 22:46На той же OSDev вроде как всегда рекомендовали при разработке ОС для x86 не начинать с бутлоадера, а реализовывать ядро изначально с поддержкой Multiboot specification. Загрузчик на современных x86-платформах — довольно такой «острый угол» (инициализация памяти хотя бы), интересно почему вы этот угол не «срезали»? Или идея была именно в «Bare-metal OS»?
MacIn
17.10.2018 00:48В чем сложность инициализации памяти на современных х86? По сравнению с несовременными.
CodeRush
17.10.2018 00:56Смотря откуда начинать, если у вас уже все заведено и есть BIOS и его сервисы (т.е. либо старый интерфейс interrupt call, либо новый UEFI) — никакой разницы нет, память уже работает, карту бери у прошивки и действуй.
Если же ничего нет, даже стека, а вы сами из флеша исполняетесь — заводить современный контролер памяти DDR3/DDR4 (т.е. опросить сам контролер, добраться до SPD через SMBus, считать оттуда конфигурацию, отправить контролеру нужные команды в нужном порядке, выполнить тренировку, отключить неработающие модули, и все остальное) намного сложнее, чем раньше.
MacIn
17.10.2018 00:23Закину в закладки, интересно почитать продолжения.
Когда-то писал свою ОС, со своими API для прикладного слоя и для драйверов, своей файловой системой, все полностью с нуля — от загрузчика до интерпретатора коммандной строки.
Вот только ряд комментариев на хабре отбил желание делиться результатами напрочь.
boblenin
17.10.2018 17:38Сколько времени заняла разработка? Где бы глянуть исходники? Особенно интересует USB стэк. Загрузчик, FAT32, SVGA — это еще ладно, но вот все остальное — это ж куча пота. Снимаю шляпу.
7240
17.10.2018 18:21Советую посмотреть ColibriOS kolibrios.org/ru. Она на чистом ассемблере, там парни тоже над ней трудятся и им тоже нужна помощь, может скооперируетесь.
Xasmeks
17.10.2018 18:21Тоже хотелось бы себе создать ОС только для того чтоб можно было запускать через командную строку игры и не раскидываться всей оставшийся производительностью составляющей на всякие менюшки, уйма настроек которые никогда не трогал и трогать не собирался, непонятные запущеные +100500 службы и svhost которым конца и края нет.
khim
18.10.2018 00:53Тоже хотелось бы себе создать ОС только для того чтоб можно было запускать через командную строку игры
Откуда возьмутся игры под OS, которой никто не пользуется???
CKOPOCTb
18.10.2018 01:05А на чем и в какой среде всё было сделано?
mrlolthe1st Автор
18.10.2018 01:06Использую VS, QEMU, BOCHS, VirtualBox, ImDisk Driver, ручками написанные батники, MakeBootable'ы и т.п. а так же Rufus'ом. Написано на Asm + C.
FlightBlaze
18.10.2018 01:24Было бы лучше написать драйвер например под встроенную видюху intel hd graphics, ведь ваш SVGA в режиме 118h рисует графику через CPU, а это очень не правильный подход. Лучше ознакомьтесь со спецификациями gpu от intel 01.org/linuxgraphics/documentation/hardware-specification-prms
mrlolthe1st Автор
18.10.2018 01:39Да! Думаю, я этим займусь.
FlightBlaze
18.10.2018 07:35Я тоже считаю это отличной и перспективной идеей. Удачи в этом нелегком деле. Если что-то будет не получатся, а оно будет не получаться, советую спокойно к этому относится, работа не бывает легкой.
JerleShannara
18.10.2018 01:44В одиночку лучше сразу застрелиться, чем лезть в эти 5000-10000 страниц описания. 2D ускорение лучше оставить на потом, когда уже всё остальное будет летать, и автор упрётся в производительность видеоподсистемы.
Kwent
Спасибо за статью, интересно почитать подробней. А при чем тут в хабах Brainfuck? Или все-таки есть кусочки на нем?)
mrlolthe1st Автор
Несомненно!