OSDev

Интересно, посмотрю...

Обновил статью с описанием - всё там же.
Из нового - возможность разбить винт/флешку в GPT (и записать туда EFI шелл какой-нибудь).

Делать ли версию самого QSINIT под EFI - пока не знаю... Кривость/убогость оного откровенно напрягает
Да и с чунками 32<->64 будет весело

Сделал пробную версию - с чунками оказалось оч. просто - в сравнении с 16<->32 Всё-таки AMDшники - приверженцы минимализма

Забавных впечатлений масса... Совершенно кошмарная EFI консоль, подмена GDT .
Вообще, кривость и несогласованность EFI API - не то, чтобы удивляет - но не радует - точно. Понятно, что родом с IA64 - поэтому про селекторы мы не слышали. Использовать используем где-то, трапаемся если в ds - неправильный (после смены GDT) - но доступа из API к ним никакого

Видео и консоль - для работы не предназначены. Для показа лого - может быть.
При всей "юникодности" - реально доступных символов меньше, чем в ASCII (и отсутствие некоторых типов блоков реально напрягает - у меня ж турбовижын - хорошо, что есть своя графическая консоль).

Хорошо, опять же - что в 2.0 есть протокол вывода графики, отличный от UGA (и в нём есть указатель на видеопамять) - поскольку родной ->Blt такое ощущение, что каждый бит вслух по телефону диктует.

Хорошо, что аж в 2.1 добавили протокол клавиатуры, где появилась возможность узнать - нажат ли у нас таки shift - это какое достижение в сравнении с биосом 81-го года выпуска! Возможности вставить в буфер клавиатуры для будущего юзера (ну и самого такого понятия) - понятно, нет, кнопки нумпада тоже пали жертвой - отличить невозможно...

В общем - впечатлений масса и большинство выражается только русским устным . Но, тем не менее - 32битный рантайм (вроде бы) оказалось возможно запустить из 64битного EFI и мирно чем-то заниматься - например, играть в тетрис

Вот год пролетел и ага

Собстно, ничего особо интересного - поддержка кодовых страниц, форматирование HPFS, клонирование дисков, возможность сборки под линуксом (всё тем же open watcom 1.9, только линуксовой версией).

Из полезного, пожалуй - можно сделать запасной бутманагер и прописать конкретной строчке меню clock modulation на интеле - т.е. зажатие частоты, для запуска DOS на реальном железе вполне может пригодиться - кое-что даже перестаёт падать (3100 core duo при 1/8 показывает от 400 до 600 мгц в разных досовских измерялках).

Обновлённое статья/описание....

Вот и ещё год пролетел

Собстно, за это время таки добавил в своё поделие треды.

Экранных сессий пока нет, есть только треды и команда detach. Разумеется, не SMP (какой SMP, когда BIOS/EFI в качестве драйверов? ) Всё, по-прежнему, опционально - т.е. стартует в режиме "однозадачности", потом "легким движением руки" (API) можно переключиться в нечто более похожее на OS.

Помимо написания всяческих аналогов WaitForMultipleObjects (у меня, ж, не posix ), масса интересного была с технической частью. Использование APIC таймера при регулярных хождениях в реальный режим (BIOS) или 64-битный режим (EFI), который, в свою очередь, тоже ходит в реальный

Использование TS флага в CR0. Выяснилось, что в EFI оно нереально, по крайней мере, пока активны его обработчики прерываний. При чём, ребята тоже особо не виноваты, они старались Ставим TS бит, приходит прерывание, EFI честно сохраняет CR0 юзера (!) и начинает что-то делать, используя SSE команды. Огребает исключение #NM, ловим, сбрасываем TS в CR0 и возвращаемся в это прерывание. На выходе оно восстанавливает исходный CR0 с взведённым TS. Далее см п.1. В общем, Ы

Кому интересно - и бинарники и код доступны всё там же.

А что, в Open Watcom появился 64-битный режим? Я 3 года назад переходил с него на GCC именно из-за отсутствия. Но и не жалею, при прочих равных, GCC чуть-чуть лучше. В OW чтобы добиться качества, надо было делать много ручной оптимизации.

Ээ, у меня 32-битное изделие

В EFI версии 64-битная часть очень небольшая - собирается консольным MSVC...
А для 32-бит ватком с его прагмами ничем не заменить. Тем более, что у меня не ELF и куча своеобразной линковки (смешанный 16/32 код), с которой мало кто справится.

В GCC тоже есть "прагмы" не хуже чем в OW.
Вот с линковкой да, наверно так не получился. Хотя, если разобраться в ld scripts, то наверно и можно. Но лучше подумать над разделением кода.
https://sourceware.org/binutils/docs/ld/Scripts.html
http://nullprogram.com/blog/2014/12/09/

Дело вкуса.
Даже если отбросить отрицательные симпатии к GNU, не вижу каких-то плюсов от gcc для BIOS-based 32-х бит.

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

Разделение кода потребует больших усилий (с непонятной целью). Я, ж, не ухожу в PM с концами, а работаю с биосом всё время жизни и есть некий объём служебного 16-битного RM кода, фиксапы на него. Плюс, небольшая часть сугубо под полуось, там ещё сложнее с линковкой.

И линковать и, даже, генерить смешанный 16/32 код может очень мало кто. Сделать группу в ассемблере, где будут 16 и 32 сегменты - умеет тока wasm и старый masm. Ну и fasm, наверно, но это за пределами добра и зла Сделать корректный модуль с не-битыми фиксапами из этого могут тоже единичные линкеры, не думаю, что LD в их числе.

В общем, массу приключений себе искать только ради GCC - вещь в моём случае совершенно лишняя

Я думал тебя заинтересует перспектива перехода на 64-битный код. В принципе, у меня система BIOS-based 64-бита, т.к. есть использование дисковых функций из реального режима. И ничего, работает.