Pull to refresh

Comments 223

Интересная задумка, буду следить :)

А ОС 16-бит будет?
Первые шаги точно будем делать в реальном режиме. А дальше хотелось бы перейти к 32-битам и защищённому.
а тяжело перейти на 64? просто интересно
Про 64 мы пока не думали. Подумаем :)
буду ждать продолжения
UFO just landed and posted this here
Надеюсь, Чип и Дейл быстро примут меры.
UFO just landed and posted this here
Надо же, уже своя рабочая ось в школе, молодец парень! Ему небось нравилась девочка по имени Вика? :)
Нет, у меня тогда не было знакомых по имени Вика. Просто имя красивое :)
Суровый будет цикл статей
Радует, что на хабре снова появились интересные авторские материалы.
Сам никогда не буду писать свою ОС и вообще вряд ли буду программировать, но читать интересно, жду продолжения.
UFO just landed and posted this here
UFO just landed and posted this here
Эх, такой замечательный вечер, стайки девушек на улице, хотел погулять, но тут Вы все обломали… придется писать :)
Спасибо!
(задумчиво) Какая ахинея…

Нет, я не возражаю, что на некоторых компьютерах именно так. Но нафига в _основах_ работы операционных систем изучать устройство диска (которое ещё и не правда к тому же, где вы видели дорожки у рейда или SSD, цеплюящегося по SAS через экстендер?)

Начинать нужно с другого. ЧТО должна делать ОС. Поскольку все современные ОС сильно… м… заняты всякой второстепенной ерундой, то либо mach, либо какой-нибудь гипервизор вроде xen'а. Там куда в более общем виде описано что происходит при включении компьютера и в чём состоит задача ОС.
от простого — к сложному. майкрософт тоже не с вин7 и ссд начинал…
Именно! А начиная с тонкостей реализации драйверов блочных устройств под специфичный вид BIOS'а специфичной платформы, получается очень сложно. Потому что вместо простого представления о драйвере блочного уровня, мы получаем простыню с несуществующими секторами.
Изначально и была простыня, зато все очень просто и прозрачно. Потому в детском саду и начинают со счетных палочек а не с общей непонятной теории.

Авторы правильно сделали что начали с «Hello World!», а не с многозадачности и всякого там IO.
А теперь вопрос: сколько раз приходится переучивать дитя, освоившее счёт на палочках до момента, когда это дитя освоит теорию вычетов или начнёт решать дифуры в частных производных?

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

А то, что вы делаете — это обучение ребёнка в детском саду считать на калькуляторе. Слишком много знаний о кнопочках «М», «С/СЕ» и слишком мало теории счёта.
Переучиваться придется всегда. Сначала нужно давать материал так, чтобы это было интересно, а уже потом — систематизировать его, потому что таблицы и справочники не прививают интереса к изучаемому предмету, а без него никуда
От простого — к сложному!
Врачей тоже не сразу учат операцию на мозг делать.
Как мы уже писали в тексте статьи, мы не стараемся дать исчерпывающие теоретические данные, это не наша основная цель. Мы же хотим показать непосредственно процесс разработки и дать читателю самому поучаствовать. А о том, какие общие задачи решает ОС, написано много хороших книг (некоторые мы перечислили в конце статьи).
Невозможно описать работу ОС просто без теории. С теорией — просто. Можно набросать минимальную ОС с минимальным функционалом, но реализующую, например, многозадачность и управление памятью. А вот набросать простенькую ОС, которая умеет делать diskIO и сама себя умеет загружать — нет. Она не будет простенькой, и уж тем паче, по ней трудно будет понять что зачем.
Возможно, вы правы, и теории надо уделять больше внимания. Мы постараемся учесть это в следующих выпусках.
Про дисковод тут написано для того, чтобы было понятно почему именно 512 байт. Дорожки и сектора сейчас виртуальные и эмулируются для совместимости и единообразия.

Начало цикла статей очень хорошее, все очень хорошо понятно, да еще можно самому попробовать не отходя от кассы.
UFO just landed and posted this here
Ну, критиковать и писать своё — это две большие разницы. Если бы я мог с высоты птичьего полёта обсуждать ядро линукса, то у меня бы зарплата на нолик больше была.

Впрочем, я как раз сейчас внутренними потрохами зена занимаюсь, возможно, по совокупности можно будет сделать обзор. А из литературы рекомендую Prentice Hall — The Defenitive Guide to the Xen Hypervisor. Оно хоть и протухшее (2007), но лучше книги по гипервизорам (в общем) и зену (в частности) я не видел.
Критиковать просто. Вы напишите свой цикл статей. Если он будет умный, интересный и познавательный — вас будет читать больше народу, чем статьи про классический подход. Ждём статьи!

Автору этой заметки — отдельное спасибо за то что свёл знания в одну статью. Обязательно жду продолжения. Кстати, про прикладные грамматики тоже бы было интересно почитать.
amarao подходит с стороны потребителя. И ведь не так важно будет ли дефрагментирован диск или нет, а вот если будет «подвисать» пользовательская программа — плохо! Наверное это должен прочувствовать каждый: когда от дефрагментации не успеет затормозить его машина(когда будет от этой ерунды зависеть чья-то жизнь) или от «свопинга» вы встрянете в лифте на пол часика между этажами. Ребята вы забываете, что платят в конечном счете за коробку, интерфейсы и скорость работы (то есть за готовый продукт который способен совершать полезную работу, а что вы наблюдаете сейчас — камень в сторону навигаторов и смартфонов)

P.S. За что минусовали господина amarao?
В статье речь идёт не о создании ОС для реальной работы. Главная цель ОС, которую мы пишем, — быть наглядным пособием. Поэтому нам в общем-то всё равно, за что «платят в конечном счете».
В таком случае вы непойми к чему прийдете. Получите очередной MS-DOS 6.22 и на этом навероне успокоитесь. Наверное нужно всетаки поставить цель. Хотя бы что бы под вашей системой в конечном итоге собрался какой-нить UNIX проект вроде Samba. Мне кажеться это будет не очень сложно и все же показательно.

P.S. Обратите внимание на MINIX целью проекта является тоже ОС для изучения.
UFO just landed and posted this here
Лиха беда начало.
Позновательно, интересно и… интригующе)
Удачи вам в написании дальнейших статей цикла!
ftp.linux.org.ua/pub/docs/mirrors/gazette.linux.ru.net/rus/articles/toy-os/toy-os.html
linuxgazette.net/77/krishnakumar.html

Очень хотелось бы чтобы авторы цикла не погрязли в подробностях чтения с диска и загрузки русских шрифтов. Могу посоветовать реализовать Multiboot specification [1] и грузиться сразу GRUB'ом. А также побыстрее избавиться от чисто-ассемблерной реализации и показать, как смешивать Си с ассемблером в строго необходимых пропорциях.

[1] www.gnu.org/software/grub/manual/multiboot/
Именно! Про это я и говорю. Меньше возни с локальной спецификой, больше обзора с высоты птичьего полёта.
Вся теория должна подкрепляться практическими занятиями.

«Высота птичьего полета» без азов не позволит сделать «лабораторную работу» самостоятельно и сознательно без тупого copy-paste из статьи.
Я ж и говорю: нужно взять готовые компоненты, переложить на них второстепенные детали и начать делать систему. Операционную. А не программу, которая живёт в MBR.

Возьмите XEN или другой PV-гипервизор (вроде, vmware умеет с pvops работать тоже), напишите свою ОС. Не на ассемблере. На Си. Компактную. Чтобы ВСЯ ос укладывалась в 10-20кб исходного кода. Вот это будет действительно хорошим обучающим примером.

А чему вы научите людей с загрузкой? Тому, что на PC всю жизнь биосы страдали шизофренией, пытаясь засунуть в позапрошлые стандарты стандарты новые? Даже попытка думать о всех этих LBA, ECH и ещё десятку прочих костылей по эмуляции числа головок и цилиндров у меня головную боль вызывает (к вопросу о костылях:
http://ru.wikipedia.org/wiki/Ограничения_на_размер_жёстких_дисков_персональных_компьютеров, вы действительно хотите людей знакомить с ЭТИМ?)
Судя по всему — вы знакомы со всем этим. Я — нет. Мне будет совершенно непонятно что делают всякие там готовые гипервизоры и т.п.
Без понимания принципов работы я не смогу написать эффективную операционную систему.

Операционная система — это не какая-нибудь прога на высокоуровневом языке, где натаскал кнопок на форму, и готово.
Я обязан иметь низкоуровневое представление о железе, о BIOS или, там, EFI, который тоже является Basic IO Sistem, и т.п.

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

Для того, чтобы предоставить возможность ОС работать с железом уже давно придумали уровень абстракции — драйверы/модули. Ядро не знает, как именно программируется указанный контроллер. Ему пофигу, как именно нужно обрабатывать кнопки с очередной мегамышки с сенсорным управлением. Её дело — передать прерывание в нужный драйвер. И вызвать интерфейс этого драйвера, когда потребуется функционал устройства.

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

ОС — это управление памятью и процессорным временем (процессами), а не ковырение в БИОСе.
До уровня абстракции мне далеко, мне проще работать с железом напрямую. Да и до железа мне далеко.
Для того чтобы пощупать все это на практике — нужно начинать с простого и самописного. Считаю что «Hello World» — лучшее начало.

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

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

Я не понимаю вашу позицию. Точнее, я её могу понять в режиме «о, гляньте какую я программу написал с использованием только вызовов биоса», но каким образом это относится к ОС — не понимаю совершенно.
Я не пользуюсь функциями BIOS, также как и, почти, не пишу программы для PC.

BIOS я упомянул как почти неизбежного посредника для загрузки ОС, а также из-за простейшей реализации вывода текста на экран. (это я знаю из ВУЗ-овской теории)

Про железо — вы меня неправильно поняли. С ним на PC я дело не имел. Разве что только с UART через стандартный API.

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

Но это совсем другое железо и серьезные ОС для PC я представляю слишком издалека. Мне неведома виртуальная память и ее менеджеры и т.п. Мне проще начинать почти с нуля.
Потому, как для новичка, мне очень нравится статья, т.к. лично мне пока все понятно.
Ну как вы не поймёте — это статья поможет людям разобраться в основах. Да, на низком уровне. Но, имхо, стыдно быть программистом, и не знать именно вот этих основ, которые уже потом обросли интерфейсами.
Возьмите XEN или другой PV-гипервизор (вроде, vmware умеет с pvops работать тоже), напишите свою ОС. Не на ассемблере. На Си. Компактную. Чтобы ВСЯ ос укладывалась в 10-20кб исходного кода. Вот это будет действительно хорошим обучающим примером.
А можно поподробнее? И про другие готовые компоненты.
Можно. У меня в черновиках уже копятся статьи по зену, там, в частности, примеры простейших PV-ядер на Си.

«Другие готовые компоненты» — это возможность в коде ядра использовать примитивный код frontend'ов, перекладывая разбирательство с регистрами контроллеров и прочей мелочью на ядро в dom0.
Надеюсь, что вы эти статьи опубликуете на Хабре, было бы очень интересно.
Совершенно согласен, штука черезвычайно удобная.
Сам недавно пытался написать ОСь, дошел до хелоу ворда, стал разбираться с таблицей дескрипторов, да и забросил как-то… 8(
поддерживаю в том, чтобы поменьше ассемблера! учил раньше ассемблер, но что-то мне он не по нутру пришелся, скучен. Гораздо интересней на мой взгляд реализация функций самой ОС.
Кстати пытался купить этого таненбаума, а именно «Операционные системы: Разработка и реализация», вот нет нигде в продаже.
Могу в привате сылкой кинуть.
Я хочу видеть ваш сотый выпуск. С первым вы справились. Тема очень интересна. Я бы предложил вам пока не думать о защищенном режиме, он очень сложен. Поставьте себе цель — написать ОС реального режима, пусть она будет псевдо-клоном ДОС, это не имеет значения, т.к. статьи будут нести сугубо обучающую цель. Придумайте формат исполняемых файлов, формат драйверов. И не бойтесь ошибиться, еще раз повторюсь, ваша цель — показать в каком-то очень примитивном приближении как устроены и функционируют ОС и не более.

И пусть будет много примеров, как все компилируется, как отлаживается, такой туториал чтоб получился. Успехов.
> Поставьте себе цель — написать ОС реального режима

Какой в этом смысл? Пройтись по всем граблям слоя совместимости в современном BIOS (разных производителей!) и в современном железе? У реального режима сейчас только одна функция — дать возможность прыгнуть в защищённый. Даже BIOS в процессе POST, насколько я знаю, временно переходит в защищённый.
Грабли слоя совместимости в современном BIOS? Я не имею о них ни малейшего понятия. Для таких как я и будет полезен этот цикл статей. Я занимался низкоуровневым программированием в течение года, и могу сказать, что реальный и защищенный режимы — это как небо и земля, и сможет ли уважаемый автор начать сразу защищенного (я конечно не знаю уровня его подготовки), и поймут ли эти статьи те, на кого они расчитаны. Я бы написал ОС реального режима, а потом бы начал второй цикл статей об ОС защищенного режима. Задачи-то надо ставить реальные, которые можно осуществить. Если автор сможет сразу начать с защищенного режима и объяснить в свох текстах это так, чтобы другие поняли, было бы замечательно.
Чтобы научиться ездить на автомобиле, нужно знать, каково это — падать с лошади?
Да, чтобы научится работать с защищенным режимом нужно сначала научится работать с реальным. Абсолютно верно.
Я бы сначала научился трогаться и тормозить, но никак не учиться ездить на велосипеде до поездки на машине. Это разные вещи.
Как знание (и даже понимание) 64-килобайтных перекрывающихся сегментов поможет в написании кода работы с дескрипторами? Каким образом знание номеров портов и адресов страниц видеопамяти поможет написать драйвер для современной видеокарты Intel? Как знание портов ввода/вывода COM-портов поможет программировать EHCI?
Своя ОС реального режима у нас уже есть :) Хотелось бы пойти дальше. А вообще вы вполне правильно говорите, наша основная цель — чисто образовательная. Спасибо.
Так вы себя образовываете или кого-то еще? Если себя, то почему-ю не начать с Таненбаума и MINIX? Третий миникс — вполне достойная вещь для изучения, маленькая, простая, грамотная.
И то, и другое. Что такое миникс и с чем его едят, мы знаем.
О, ностальгия :) Было инетересно почитать.
> как же на самом деле работает эта сложная система из железа, кремния и множества программ
На самом деле не так уж сложно. Кроме общей архитектуры ЭВМ читаем еще теорию автоматов и схемотехнику по триггерам и прочим мультиплексорам. И вот уже в общем-то понятно зачем вашей машине тактовый генератор и что же на самом деле происходит внутри процессора :).

> Создаём образ диска и заполняем его нулями
Не могу молчать ибо вырвиглазное решение. Не проще dd'ой из /dev/zero писать сколько надо?
UFO just landed and posted this here
Кстати, если кому интересно поковырять машину так сказать с нуля, есть замечательный комплекс Proteus — тут вам и эмуляция схемотехники, и возможность программировать и запускать полученные программы. Правда она больше ориентирована на микроконтроллеры, но вроде в последних версиях добавили 8086.
UFO just landed and posted this here
писал я курсовиком операционку реального режима на асме. суровое все-таки занятие… Если будете развивать дальше — молодцы!
Было бы интересно увидеть написанное + комментарии отдельными статьями.
статей увы не могу — маленькая *то, о чем нельзя говорить на этом сайте*, а написанное попробую отыскать, уверен, что должно остаться на винтах
Спасибо за статью! Буду следить. А рассылку не планируете делать?
О рассылке не думали, потому как есть RSS. Но если будет много желающих — сделаем.
А мне вот интересно, это сейчас у нас есть виртуальные машины, в которых мы можем проводить любые самые садистские эксперименты. А как же тестировали подобные программы лет 15-20 назад?
15 лет назад не знаю, а чуть раньше у компьютеров были средства аппаратной отладки. Выполнить одну операцию, посмотреть состояние регистров, поменять регистры — и всё это кнопками на панели управления ЭВМ… В каком-то смысле lowlevel там было отлаживать даже проще.
У нас в институте были учебные стенды, на которых память писалась / читалась вручную побитово. Светодиодная индикация состояний, тактирование вручную (дергаешь рычажок и представляешь себя тактовым генератором :)). Честно говоря, доводило до полуистерического состояния :).
В более серьёзных машинах можно было ставить breakpoint'ы на флаги условий и инструкции.
У нас в универе была программка BasePC, написанная на делфях студентами же (есть и стенды, но они уже в музее). Тоже всякие программки в 16-ричных кодах писали и потактово выполняли. Было весело.
Они и сейчас есть. JTAG, например, очень распространен. Почти уверен, что какой-либо отладочный интерфейс есть и у современных x86. Скорее всего тот же JTAG.
JTAG, да, но я не совсем представляю как он выглядит для LGA'шных процессоров. Вроде бы, на P2 это был аппаратный переходник между сокетом и процессором с подсоединением к определённым ногам процессора внешнего управления (давно читал, детали не помню). Но в любом случае, это менее удобно, чем встроенный отладчик, показывающий всё состояние компьютера (включая периферию).

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

Правда, «тогда» и периферия попроще была.
Кстати, я сейчас подумал… Xen в PV режиме обеспечивает идеальную инфраструктуру для «полигонных ОС».

По списку:

1) Загрузка начинается гипервизором. Гипервизор читает файл ядра и выполняет его. Файл — обычный elf.
2) Запуск идёт сразу же в родном режиме процессора, без какого-либо 16-битного мучения.
3) Оборудование абстрагировано, реализация xen'овского драйвера блочного и сетевого устройства настолько примтивна, насколько это возможно.

Зато можно сразу же сфокусироваться на задачах ОС, а не на задачах груба/коде иницизализации защищённого режима.
Grub тоже должен кто-то написать ;)
Конечно. И libc тоже кто-то должен написать. И скедулер процессов, и ld и всё остальное кто-то должен писать. Но мы же про ОС? Каким образом оказывается код ОС в памяти — это system specific. Например, в одной системе нас читают из MBR и далее по списку, а в другой — и у нас есть функции для подгрузки кода по PXE, а то и с NFS-шары.

А в третьем случае нам вообще не надо ничего грузить, и весь код уже находится в ROM'е embedded железки.

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

Только потребует это много времени и немного шизофрении.

Может, лучше сфокусироваться на более стройных вопросах, чем гадости в области IO на PC?
Куда же без гадостей-то? При всей стройности высокоуровневых языков, как только залезаешь на нижний уровень обязательно их словишь. Идеальной архитектуры не существует, имхо.
Именно! Так зачем, обучая теории тыкать во всякие локальные неурядицы? Чтобы жизнь мёдом не казалась? Это не много не тот путь обучения, который ведёт к стройным знаниям.
Потому, что на низком уровне низком уровне без этого никак. Хотя если создавать сферическую ОС в вакууме чисто для обучения, то возможно вы и правы.
Если вы хотите писать реальную ОС (т.е. ОС для работы), то тем паче, нужно начинать не с биосов и воображаемой топологии диска для совместимости с биосами 1984 года производства, а с представления об архитектуре ОС. Монолитная или микроядро? Драйвера на ring1 или на ring0? Модель работы с процессами (треды это отдельные процессы или сущности внутри процесса?), продумывание SMP архитектуры (при каких условиях приложение будет мигрировать очереди одного ядра на другое?), разработкой терминологической модели (файлы+процессы или другая модель?).

А код MBR — это уж никак не имеет отношения к ОС. Ни к продакту (где эта мелочь отдаётся на откуп бутлоадеру), ни тем паче, к обучающей модели, где нужно акцентироваться на существенных вопросах.
Жаль что вы для классической архитектуры пишите, иначе могли бы сотрудничать =)
Правда мне еще ассемблер нужно написать…
А у вас архитектура BLOHA?
//простите, не смог удержаться
Здорово. А если хабрасообществом написать ядро ОС? Со временем можно дописать и прочее. И получится отечественная ОС. ))
UFO just landed and posted this here
Главное — чтобы с применением нанотехнологий
Вы на распакованный размер сырцов линукса смотрели?
Собственно нет… )) Я далек от этой темы))) Энтузиазм))
Ну так они и запакованные не слабо весят
linux-2.6.35.1.tar.gz — 84.2Mb
В распакованном это удручает куда сильнее. Особенно, когда начинаешь это всё глазами смотреть.
Был тут один. Принципиально новую ОС уже написал. Надеюсь меня в минуса не загонят за упоминание нечистого всуе.
UFO just landed and posted this here
Особенно упоминание не в тему.
Написать ОС — сложное и трудное занятие. Но это чепуха по сравнению с написанием драйверов. Нет, драйвера то писать как раз легко(если спеки открыты), проблема в том, что их нужно МНОГО. Очень много.
Ведь без драйверов ОС просто не будет иметь никакого смысла…

Пожалуй единственный способ сейчас выпустить на рынок новую ОС — идти по пути эппла, используя ограниченный набор железок.
Вы правы, выпустить на рынок новую ОС, которая станет реальным конкурентам существующим, — это очень и очень сложное дело. Но это и не входит в наши планы — мы пишем, можно сказать, «игрушечную» ОС. И основная цель этой ОС и цикла статей — чисто образовательная.
А… Ну как же… Баловался конечно в детстве. Был довольно неплохой загрузчик, который мог грузить MS-DOS, PC-DOS, DR-DOS, PTS-DOS, и собственно саму мою «операционку». Можно взглянуть на него в файле LOADER_S.ASM (LOADER_S.BIN — скомпилированный). А так-же можно поиграться в дос-боксе с 5-ю командами, запустив HBIOS.COM. Если нужно грузить с дискеты — надо заремарить первый джамп в HBIOS.ASM (jmp dos_start).



Качнуть этот ужас, если кому интересно, можно здесь: rghost.ru/2352097
Спасибо авторы, прямо ностальгия какая-то )) Пишите еще.
> perl -e 'print "\0" x 1474560' > disk.img

o.O

А $ dd if=/dev/zero of=disk.img bs=1024 count=1440 не поможет? :)
+ размер дискеты, вроде: 1 457 664

** Дюка носил дискетами вот и запомнил размер архивчика **

:)
последние 4 байта должны быть особыми — читайте статью внимательней)
*два >.<
плюс размер кода… забивается только «лишнее» место
У обычной дискеты две стороны, на каждой стороне по 80 дорожек, в дорожке 18 секторов. Размер одного сектора — 512 байт
2 * 80 * 18 * 512 = 1474560
Вроде всё сходится :) Может быть, вы говорите о размере образов диска, в которых была какая-нибудь дополнительная информация, например контрольная сумма.
Для эксперимента:
возмите ДОСовский RAR 2.0
и создайте архив для записи на 3-дюймовку
получите размер файла = 1 457 664
* конечно если размер архива > дискеты :)
А, теперь я понял, в чём ваша ошибка. 1 457 664 — это не ёмкость дискеты. Это максимальный размер файла, который можно записать на дискету, на которой уже есть файловая система (как правило, FAT). В таком случае на дискете кроме самого файла будет ещё таблица блоков и другая служебная информация.

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

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

«программа», которая это делает, называется linker. ld-скрипты и описание секций — вообще отдельная, довольно вредная тема
В данном, простейшем, случае совершенно излишне углубляться в подробности про ассемблер и линкер.
Да, ну начало — это всегда весело. Буду ждать продолжения :)
И, кстати, на мой взгляд, было бы куда веселее купить какой-то ARM-девайс с DX и писать под него и для него. Тогда, глядишь, и сообщество бы подтянулось.
Из тех, кто купил себе такой же? :-/
Да они же похожие друг на друга, и по конфигурациям и по процессорам. Вот что-то типа такого: www.dealextreme.com/details.dx/sku.39448. Да и даже, если из тех, кто купил такой же — чесслово, был бы интересный предлог, так еще и не такое покупают.
А, я не про те девайсы подумал, как слышу ARM-девайс сразу представляю либо промышленный компьютер, либо печатную плату, либо вообе чуть ли не SoC
старые мотороловские телефоны хорошо для такой развлекухи подходят — собрал бинарник, по usb в память загрузил, управление передал и по нему же обратно что-то получил

ну и вообще, 2010 год, вокруг куча всякой электроники, от роутеров до айпадовс и телефонов, с нормальными процессорами и интересной архитектурой (кто знает, сколько ядер в процессоре айфона или дрима/дезайра и как они грузится, а?), а тут рассказывают про какое-то унылое легаси 84-го года и сектора дискет, сто раз обсосанные даже в птушных учебниках.
Для айпада или роутера, конечно, писать интереснее. Но у многих ли под рукой есть лишний айпад, с которым не жалко поэкспериментировать?
>у многих ли под рукой есть лишний айпад, с которым не жалко поэкспериментировать?

а вот плохо быть нищебродом.

старая моторола на нептуне стоит пару сотен рублей и неубиваема, например (начальный бут зашит в ROM проца)

среди роутеров тоже есть относительно дешевые неубиваемые модели (asus wl520 какойто) — если что-то запорол, достаточно загнать в рекавери и по TFTP залить бекап.

AFAIK, даже в айпаде/айфоне тоже начальный бут живет в роме и спокойно восстанавливается.

системщина на x86 уже никому не нужна, а вот свободная риалтаймовая операционка для линейного процессора в 3g телефоне — это нужная сообществу вещь
«системщина на x86» практически у всех под рукой, а вот, нестандартные железки с ARM хоть и есть почти у всех, но единообразного доступа к загрузке своего ПО они не имеют.
Да и аппаратно они сильно отличаются. Просто так «Hello World!» не напишешь — видео ведь разное (если вообще есть).
ЗЫ: Несмотря на то, что 99.9 % мобильников имеют ядро ARM — легального и доступного способа загрузить свое нативное, а тем более низкоуровневое ПО в большинстве случаев нет.
(хотя, судя по постам на хабре, в РФ вполне легально, но также труднодоступно)
UFO just landed and posted this here
хорошая штука, но это покупать надо, еще и заказывать где-то.

поиграться можно и с подручными средствами, тем более, что, например в телефоне есть RF-тракт, который можно приспособить к полезным делам
UFO just landed and posted this here
Например, «IBM PC совместимый» компьютер ;)
UFO just landed and posted this here
спасибо, очень интересно и познавательно. отдельный особый респект за доступность изложения.
ох, все никак на Таненбаума глаза не поднимались почитать, надеюсь вы изложите суть. дарю немного кармы вам обоим, чтоб не забросили это дело. жду продолжения!
Спасибо, будем стараться. Но Таненбаума лучше всё-таки почитайте :)
Замечательная статья, но хочется, действительно, более актуальных знаний. Отчасти комментаторы выше правы: хотелось бы кода на C, загрузки через тот же grub и multiboot, защищенный режим и т.п… Но при этом я категорически не согласен с тем, что надо давать исключительно теорию — практический код, как у Вас, это замечательно, гораздо легче понять то, что можно откомпилировать и сразу посмотреть, как что работает.
UFO just landed and posted this here
Полностью согласен. Любая теория должна закрепляться практикой.
Практика — это возможность обратной связи. Обратная связь позволяет устранить неправильное понимание реальности.

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

А для обучения пользованием такими инструментами как grub все-равно нужно рассказать про принцип его работы и показать простейшие практические примеры.
Собственно, здесь рассказано как запускается загрузчик, ну и приведен пример простейшей заглушки вместо загрузчика.
в школьные годы тоже ос из-за интереса писал, сделал текстовый реактор на 4 или 6 секторов. в 1 секторе была команда подгрузки остальных секторов к 0x7C00 + 200 по 13 прерыванию. но более 6 секторов не грузилось я предполагал что где-то с 0х8000 продолжается системная память и ос нужно грузить в адреса 0х10000 и туда джампить.
конечно все это интересно, но мне до сих пор не пригодилось…
Никогда не знаешь, что пригодится в жизни. Например, мне на нынешней работе очень пригодились знания, полученные при создании своей первой ОС.
Лет пять назад то же самое было на каком-то сайте в рунете. Тоже то ли по выпускам, то ли по урокам разбито было.
Если найдёте ссылочку — будем благодарны. Всегда полезно посмотреть на опыт других людей.
Спасибо, почитаем :)
Очень много про диск, а по-моему важнее написать про прерывания, порты, защищенный режим и тд
Про прерывания, порты и защищённый режим будет сказано ещё очень много. Это же только первая статья.
Если есть возможность, то писать и с историей вопроса.
Т.е.: почему именно такое смещение, почему возникли таймеры, прерывания, что такое страница видео памяти. и почему сообственно страница.

Просто легче будет пониматься почему ОС надо писать так, а не иначе, а то есть вероятность, что получится просто хороший сборник статей с зубрёжкой о том, что надо писать, а не почему так.
UFO just landed and posted this here
Рад, что услышали комментарий :)
Спасибо.
Спасибо за статью, буду ждать продолжения. Как-то тоже пробовал написать свою ОС, чтобы пописать на языке С. Дошел до того, что она писала «Hello world!» и вешала компьютер. :)
UFO just landed and posted this here
Продолжайте, главное не забрасывайте. Очень интересно почитать.
не хочется читать то чего в интернете полным полно.
Очень интересно прочитать про новые подходы в разработки ОС
Например про проект микрософта en.wikipedia.org/wiki/Singularity_(operating_system)
Вы правы, Singularity — это очень интересная система, мы сейчас с ней знакомимся. Спешу вас заверить, что мы не собираемся замыкаться на классических архитектурах ОС и будем стараться изучать новые подходы. Вполне возможно, наша система будет включать какие-нибудь новые, современные идеи.
Ждем желтую прессу в топике и завтра увидим в новостях «Сенсация: Харб пишет свою русскую ОС!» =)
UFO just landed and posted this here
Вы правы, Singularity — это очень интересная разработка. Мы сейчас активно изучаем это направление.
Полагаю, что авторам нужно було указать, что бут сектор — это не что иное, как обычный файл COM под старый ДОС, который имеет 2 принципиальных отличия:
1. Смещение 0x07C0 вместо 0x100
2. Специвичный размер с обязательным окончанием

И написать, что прерывания ОС (> 0x20) использовать НЕЛЬЗЯ

Посему полагаю, что можно было писать и тестить COM под DOSBOX, а потом, когда настанет ппц (Размер нашего чуда перевалит за волшевные 510 байт) нужно будет учиться либо оптимизировать код, либо грузить код из файла (т.е. научиться понимать файловые системы).

Предлагаю Авторам таким образом создать лоадер для ОС, т.к. варианту osfrofscratch посвящена ОС FreeDOS, а написать толковое врядли получится.

На «продакшн» будет залит только перекомпиленный COM и всё будет в шоколаде.

Сознаюсь, что самому написать лоадер не хватило усидчивости.
ДОС грузиться после бут сектора!
Никакой это не «COM под старый DOS». В DOS, как минимум, память размечена была и сегмент описания программы был перед загруженной программой. Не говоря уже о стеках и прочих «мелочах».
Лабы в универе писал в виде COM, только не
ORG 100h писал, а 7C0h и линуксом писал в бут (с помощью dd), а на саму дискету (сдавать на ней нужно было) записывал только исходник.

И проблем не было, т.к. размеры лаб не превышали 300 байт :)

UFO just landed and posted this here
> Полагаю, что вам следует знать, что COM — это Copy Of Memory, обычный бинарный файл, который DOS (по причине наличия расширения из 3 букв) считает исполняемым

Да, это так

> Кроме того, файлы — это абстракция более высокого уровня, чем излагаемый материал (у нас пока и файловой системы-то нет), и поэтому неуместно сравнивать программу начальной загрузки с COM-файлом. То, что прерывания ОС использовать нельзя, должно быть очевидно — никакой ОС пока ведь и нету :) В общем, обратите внимание, что реальный режим и DOS — не одно и то же, хоть во многом и похоже.

Надеюсь, что со мной не будут спорить о том, что при запуске первый физический сектор бут девайса копируется в память и ему передается управление? отлично!
Поэтому ДЛЯ ДЕБАГА нам достаточно использовать COM, но учитывать, что некоторыми вещами МЫ не можем пользоваться (т.к. их нам предоставляет ОС). А для работы потребуется пересборка з корректировкой 1-й строки :)

Опробовал сам на лабах. Работает.

UFO just landed and posted this here
т.к. в защищенный режим проц. переведет ядро ОС при инициализации, то на стадии загрузчика нет смысла о нем сейчас и разговаривать. Считаю режимы проца темой отдельной, требующей внимательного рассмотрения для аудитории. Также считаю Необходимой ее рассмотрение до проектирования подсистемы управления / распределения памяти. + нужно учесть, что желательно для данной ОС иметь с какой-либо другой ОС совместимость (бинарную), хотя бы с ДОСом. т.к. Это достаточно важно. А имея ОС и не имея софта под нее она становится бесполезной. Вариант совместимости могу предложить в виде виртуальной машины ДОСа (рассмотрим заодно и режим аппаратной виртуализации).
Вопрос совместимости с существующими ОС мы считаем второстепенным. Для нас самое важное — наглядность процесса разработки. Добавление совместимости только усложнит и так непростое дело и запутает читателей (по крайней мере, на первых этапах).

Не забывайте, что мы делаем систему в первую очередь не ради пользы от конечного продукта, а ради самого процесса разработки.
Спасибо за материал, познавательно и интересно. Жду продолжения.
Очень удачный день на хабре. Три поста об ИИ, а теперь еще и этот… Спасибо авторам.
> Power On Self Test – самотестирование при нажатии ВКЛ
Выглядит неуклюже. Не лучше ли «самотестирование при подаче питания»?
Лучше — самотестирование при запуске. Ведь в реальности — POST происходит и при перезагрузке.
Но это мелочи.
в статье, насколько я понимаю, это был перевод, а power on — это всё-таки немного другое.
Ну, тогда уж «Power On» можно заменить на «включение». Смысл во всех случаях одинаковый, и всем понятен.

По мне, так вполне нормально в статье написано, без лишней сухости.
То, как в статье, звучит как-то не по-русски. И у меня на кнопке включения компьютера не написано «ВКЛ».
UFO just landed and posted this here
UFO just landed and posted this here
Да еще и веткой ошиблись.
UFO just landed and posted this here
Извините, а вы чего хотели в первой статье цикла?
UFO just landed and posted this here
Статья, можно сказать, пробная. В первую очередь мы хотели в ней показать, какой характер будет носить наша работа и посмотреть на реакцию сообщества, узнать уровень интереса людей к теме. Спасибо за замечание, будем стараться раскрыть эти темы в следующих статьях.
У меня года три назад тоже была попытка написать свою ОС. Вспоминая те вопросы которые возникали у меня по ходу написания системы, могу сказать что помимо общих принципов построения операционных систем и архитектуры ПК, встал вопрос об удобных средствах разработки и отладки. Как только система станет чуть больше чем Hello World умещающийся в одном секторе, станет очень не просто писать это все в текстовом редакторе, компилировать командной строкой, а потом запускать и смотреть что же получилось. Не имея возможности посмотреть как это все работает внутри будет сложно понять некоторые моменты. Поэтому может имеет смысл посветить одну статью, или хотя бы часть статьи инструментарию для разработки. Например можно использовать eclipse + gdb + vmware чтобы отлаживать ОС было почти также просто как обычную программу.
Отладке будет посвящён отдельный разговор. Мы планируем использовать qemu а не vmware из-за его открытости и бесплатности.
мои пять копеек. не сочтите за критику, воспринимайте как совет.
если вы хотите сделать что то дейстительно рабочее, начинать нада с дизайна, пускай и грубого. в первую очередь нужно определится какая целевая платформа у вашей будущей ОС. из текста стало ясно что это минимум 8086. с попыткой прекрутить защищенные режими и возможно ia32 ваш код обрастет костылями и непонятками. просто для саморазвития и удовольствия что то вроде mips значительно облегчило бы жизнь. во вторых, необходимо определится с архитектурой ядра. любая из 3 будет существенно влиять на дизайн следующих компонентов. исходя из этого и целевой платформы разобраться с памятью. решить, будет ли многозадачность, продумать механизмы ipc, синхронизации, шедулер, прерывания, опять же память. вобщем нужно составить проект и начинать закладывать фундамент. а пока это выглядит как постройка дома начиная с окна мансарды.
Спасибо за совет. Мы сейчас думаем над всеми этими вопросами, в следующих статьях будем стараться исправиться :)
А загрузочную флэшку таким образом можно сделать? Каким образом?
Начало интересное. А потом я как-то не понял. Сюсюканье и очевидные вещи, сразу после обещания этого не делать.
Кому очевидные, а кому и не очень. Почитайте комментарии, даже по нынешнему содержанию статьи у многих возникли вопросы.
Нормальная статья, в тему, автор обещал не писать что такое регистры, зачем они и почему, вот и не пишет. Все четко кратко и по существу, кому непонятно в целом литература есть и причем ее просто вагон, кому маловато, пусть поучаствует в написании данного цикла и дополнит его своим бесценным материалом, орать «да что ж вы мать вашу растудыть то делаете, а вот я бы то, оно то конечно даааа», это конечно первое дело когда хочется показать какой ты на самом деле умный.
Я не понимаю нескольких вещей: неужели вы сумеете удержаться в заданном формате, при таком сложном и объемном материале?
И не понимаю это сколько времени пройдет при написании такими шагами, пока получится что то, что будет хотя бы приблизительно напоминать ОС? 50, 100, 250 статей? До нового года уложимся?
неужели вы сумеете удержаться в заданном формате, при таком сложном и объемном материале?
Будем стараться изо всех сил.
сколько времени пройдет при написании такими шагами
Много. Мы в общем-то никуда не торопимся и пока что никаких сроков не ставим. Если понадобится — можем и год и два писать понемногу. К слову сказать, если дело хорошо пойдёт, — через какое-то время можно будет ещё несколько человек привлечь к разработке кода и написанию статей, тогда быстрее управимся.
там где многозадачность, там и проблема управления памятью, и планировщик ядра и много чего ещё. Ну и живём мы уже в 21 веке, можно и многопоточности подумать с самого начала.
Погоди пусть хотя бы первые пару тройку статей напишут про реальный режим что бы с ним раз и навсегда покончить. Как правило после этого любая инициатива с ОС заканчивается…
>На PC единственное требование к загрузочному сектору — это содержание в двух его последних байтах значений 0x55 и 0xAA

BIOS в Virtual Box плюёт на сигнатуру, загружает сектор даже без неё.

Есть ещё несколько нюансов в работе загрузчика. Могут быть по-разному инициализированы CS:IP, что повлечет проблемы с абсолютными переходами. Большинство BISOов их выставляют в 0x0000:0x7c00, некоторые — в 0x7c0:0x0000.

Желательно подстраховаться в самом начале программы, принудительно задав CS:

ORG 0x7C00
jmp 0x0000:start
start:

Ещё может быть сюрприз с дефолтным размещением стека — на одних системах он попадает в 0500-7BFF, на других в 07E00-7FFFF. Когда будем подгружать дополнительные модули, желательно с расположением стека уже определиться.

Если есть желание работать с аппаратурой на низком уровне, стоит изучить спецификацию ACPI. Согласно ей, алгоритмы работы железками записываются на абстрактном языке и помещаются в специальные области памяти. Операционка должна иметь транслятор с ACPI-языка в язык платформы. Этот подход позиционируется как альтернатива системно-зависимым драйверам. Насколько мне известно, на русский эту спецификацию не переводил никто.
Большинство BISOов их выставляют в 0x0000:0x7c00, некоторые — в 0x7c0:0x0000
А вот об этом мы не знали. Спасибо.
UFO just landed and posted this here
UFO just landed and posted this here
Адрес-то один, но представить его парой сегмент/смещение можно по-разному. Так-то.
Спасибо, жутко интересно, продолжайте дальше. :)
Помнится в школе тоже с этим всем баловался, вообще хочу сказать что идеальной средой для изучения низкоуровнего программирования является DOS, там есть все средства ввиду отладчика и самого ассемблера, DOS работает в не защищенном режиме поэтому там можно делать с компьютером абсолютно все!
Спасибо! всем отделом искали дискету )) Работает!!! :D
Самый первый сектор на диске, загрузочный сектор, читается BIOS'ом в нулевой сегмент памяти по смещению 0x7С00, и дальше по этому адресу передается управление.

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

Подробно об этом можно почитать в книге Михаила Гука «Аппаратные средства IBM PC».
В институте писал свою операционку, первая веха состоялась, когда в реальном режиме заработала многозадачность и командная строка, вторая веха — когда удалось запуститься в защищенном режиме.

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

Сейчас жалею, что убил кучу времени на примитивные вещи вроде кода загрузки с дискеты, поддержки защищенного режима итд. Лучше бы сразу взял что-то вроде GRUB, написал поддержку примитивов POSIX и попытался создать пусть и не на 100% собственную систему, но более функциональную.

А, самый большой прокол был, что я решил все писать, применяя ООП :-)
Спасибо, что делитесь опытом. Вы абсолютно правы, с точки зрения конечного результата использовать существующие наработки, такие как GRUB, при разработке своей ОС полезно и нужно. У нас немного другой случай, мы эти вопросы (загрузку с различных носителей, переход в защищённый режим) хотим осветить в статьях и потому собираемся писать всё с нуля (благо, опыт уже есть). Короче, наглядность для нас важнее функциональности.
А как все эти вопросы связаны с разработкой ОС? Еще лет 10-15 назад появились книжки, которые достаточно подробно освещают вопросы работы в защищенном режиме и пр. Еще 10 лет назад в профильных листах рассылки энтузиастов такие вопросы стали моветоном…

Честно говоря, просто очень обидно за отечество: в то время, как финны еще 20 лет назад начали работу над Linux, а еще через 10 лет над Menuet OS (вроде как финны тоже), у нас до сих пор никто не умудрился написать хотя бы примитивного настоящего ядра с минимальным оконным интерфейсом :-(

Из года в год только загрузка с дискеты да переход в защищенный режим остаются самыми зубастыми вопросами российского осдева…
А каким образом осуществлялась многозадачность? В двух словах
Статья — супер!

Помню в институте чисто из любопытства накатал программу на ассемблере для 580ИК80 для копирования и проверки микросхем ПЗУ (были такие, Рф2/РФ5 с кварцевыми окошечками для облучения, чтобы стереть информацию).

Показал преподу, он как парень :) зачел мне этот проект как курсовик!

Ну мне это дело так понравилось, что тему диплома я предложил уже сам — систему тестирования цифровых микросхем. Это была плата с двумя портами 580ВВ55, которые посылают тестовые сгналы и принимают ответ с тестируемой микросхемы, плюс несколько регистров. Плата подключалась через LPT порт к компьютеру на котором была программа написанная под DOS на Паскале с UI библиотекой TurboVision. К этой программе накатал библиотеку с тестами для штук 20 разных микросхем. Прикольно то, что все это реально работало и на защите я сначала рассказал по схеме, алгоритмам, а потом все показал на компе.

Из этого диплома потом сделали стенд на кафедру для лабораторных работ.

Эх, блин, было время! 93-й год…
А вот интересно, насколько жизнеспособен будет этот цикл. Уже не первый раз вижу на хабре «Циклы статей» состоящие из одного, ну максимум трех выпусков. А дальше все забивают.
Видимо, и здесь дальше загрузчика дело не пойдёт.
С чего вы так решили? Вторая статья цикла уже на подходе.
UFO just landed and posted this here
Мы подумаем над этим. Пока не знаем.
UFO just landed and posted this here
Было бы здорово :)
Sign up to leave a comment.

Articles

Change theme settings