OSDev

Хммм. Об этом я как-то не подумал. Просто поддержал и всё. А что, там нет проблем с установкой/загрузкой?


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

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Cool

Все-таки убедил Кстати помнишь разговор про битое поле FATSize32 на флешках. Я тогда предлагал перечитывать его из backup-копии или дублировать в отдельной ячейке бутсектора. Перечитывать можно и из оригинальной копии бутсектора на диске. Идея с дублированием в отдельной ячейке тоже вполне ничего.

Почти как у меня Только смущает один момент (не о себе забочусь, а о юзерах), а именно ты написал, что при сохранении номера доп. загрузочного раздела в EBR доп. разделы нумеруются, начиная с 1. Или я тебя неправильно понял, или ты предлагаешь при сохранении использовать независимую нумерацию доп. разделов, внося тем самым путаницу в обозначение доп. разделов. Преимущества от такого подхода весьма облачные, а вот путаница на лицо. Почему бы не сделать, как у меня, т.е. сохранять номера доп. разделов на диске в единой форме. Я в EBR-коде сохраняю и использую нумерацию доп. разделов, начиная с номера 5.

Теперь что касается альтернативной загрузки. Не понял, возможно ли у тебя одновременно иметь разные активный и альтернативный доп. разделы? Из того, что я прочитал, я сделал вывод, что нет. Кстати ты решил проблему невозможности детекта удерживания клавиши на нек. компах при использовании однократного теста на нажатие без задержки? Если ты видел, я делаю две редакции MBR-загрузчиков (поддерживающих dual booting) - с однократным тестированием без задержки и с многократным тестированием с задержкой в 1 сек.

Ну, насколько я знаю, таких, как в GRUB'е и SYSLINUX'е, нет.

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

Я уже пытаюсь использовать. Я вроде бы тебе рассказывал, что идентификатор раздела в виде номера его начального сектора был бы хорош, если бы можно было с течением времени расширять разрядность номера. Data Run (в исходниках M$ видел термин Mapping Pair; я всю цепочку называю DataChain, если ты планируешь следить за моей веткой форума, посвященной NTFS) как раз для этого подходит - номер начального сектора раздела/размер раздела в секторах (размер может и отсутствовать). Концепция не слишком сложна, поэтому, надеюсь, в M$ сидят не такие м-даки, чтобы вставлять всем палки в колеса по таким мелочам. Кстати, в AML похожая концепция используется. Да, много еще где.

Я поизучал и понял, что всё-таки можно сделать один файл исходника, который будет нормально компилироваться в любом из трёх режимов. Раньше мне казалось, что для получения двухсекторного универсального варианта придётся завести отдельный исходник, чего делать очень не хотелось.


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


Мне кажется, это не принципиальный момент. Мои соображения были следующими:

• Пользователь ручками туда вбивать скорей всего, ничего не будет.
• А если будет, то обязательно сначала прочтёт документацию.
• А по уму, это поле должно модифицироваться программными средствами, которые сами должны следить за корректностью вписываемых полей.
• Цифра 5 означает какое-то знание а-приори со стороны EBR о том, что количество основных разделов 4. Однако, это может быть совсем не так. Варианты разбиения на разделы очень разнообразны и в ряде схем используется количество основных разделов, отличное от 4. Например, бывает 6 или 8.
• Начало отсчёта с 5 означает, что значения 1-4 не валидны и надо вводить доп. проверку.
• Также, начало отсчёта с 5 уменьшает суммарное количество логических дисков, с которых может производится альтернативная загрузка.
• Всё же, есть какая-то нелогичность в цифре 5. Вот мы передали управление коду EBR. С этого момента для него не существует ничего (из внешнего мира), кроме логических дисков внутри него. С его собственной точки зрения вполне нормально считать с 1, а не с какого-то другого значения.

Не понял. А какой смысл в альтернативном разделе, если он совпадает с активным? Или ты имеешь ввиду логические диски расширенного раздела? Да, одновременно могут быть разные активный и альтернативный логические диски.


Я не в курсе этой проблемы. А как она проявляется? В чём её источник?


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

По поводу палок в колёса. Вообще-то M$ - гигантская корпорация, которой нужно кормить свой разжиревший штат сотрутников и выколачивать деньги они умеют. Вспомни про массовые проверки лицензионности ПО, инициированные в первую очередь M$. А долго думать, какую сумму тебе вчинить, они не будут. Вот, например, exFAT мало отличается от обычных FAT, а тем не менее ухитрились запатентовать её так, что любая её реализация, в отличие от NTFS, уже стоит вне закона, а лицензия даже для простых устройств, типа фотоаппаратов, стоит 300k$

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Тут ещё надо смотреть, ИМХО, а распространяются ли все эти патенты на Россию. У нас же патентное законодательство отличается, причём в лучшую сторону: нельзя патентовать внешний вид изделий, алгоритмы как таковые и т.д. (Могу, конечно, ошибаться, я не еврист, но вроде так)

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

Естественно, ни о каком стандарте речь не идет. Но параметр практически неизменный (Resizing тома и др. подобные издевательства в расчет не беру) - можно вписать один раз при установке загрузчика или даже при форматировании и забыть.

Серьезно? Ты проверял? Я не думал, что разработчики BIOS докатились до такого идиотизма, чтобы портить данное поле при выполнении обычной операции чтения этого сектора. Что-то я сильно сомневаюсь, что это действительно так.

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

Не, ну ты же не учитываешь в своем коде различные "нестандартные" расширения таблицы разделов. Подход вполне простой: используется географическая (геометрическая) нумерация разделов и традиционное разбиение диска на разделы. Ты же в EBR-коде придерживаешься именно этого способа нумерации и наверняка пересчитываешь 1 в 5, 2 в 6 для передачи номера дальше по цепочки. Видно, что ты придерживаешься не только этого подхода, как единственно возможного, что также совпадает и с моими взглядами, т.к. присутствует и другая нумерация/разметка (GPT). Сделаешь EBR-код, основанный на другом подходе, можешь и доп. разделы нумеровать не с 5, а к примеру с 7.

По-моему, это мелочь. Я сохраняемые в EBR значения 1-4 по смыслу приравнял к нулю и обхожусь по-прежнему одной проверкой.

Когда я в пред. посте писал про облачные преимущества, я подразумевал именно указанное соображение.

Не, ну ты же все равно пересчитываешь 1 в 5 и т.д., о чем я говорил выше, или я ошибаюсь?

Все, я сообразил. Просто прежде прикинул на свой лад и забыл, что ты "активный" доп. раздел маркируешь флагом активности. Получается, что по смещению 445 в EBR ты хранишь номер альтернативного загрузочного раздела? А как ты тогда определяешь в EBR-коде, с какого загрузочного раздела грузиться, активного или альтернативного?

У меня в EBR по смещению 445 хранится номер активного доп. раздела, а номер альтернативного доп. раздела передается MBR-загрузчиком. Флаг активности для доп. разделов не используется вообще.

На нек. компах, особенно ноутбуках, недостаточно однократного тестирования клавиатурных флагов BIOS для отлавливания факта удерживания клавиши. Момент не постоянный или короткий, а предварительное нажатие и удерживание видимо не отражается на состоянии флагов. Жалко, что wasm прикрыли, я там это проблему описывал. Может, в каких-нибудь кэшах осталось. Тема вроде бы называлась "Загрузка первого байта первого сектора".

Ты не поверишь (я сам не поверил своим глазам), ЕСТЬ BIOSы, которые патчат это поле при ЛЮБОМ чтении сектора через Int 13h! Я потратил уйму времени, просто потому что не мог в это поверить. В конце концов написал прямолинейный тест - сырое перечитывание сектора уже из загруженного в память загрузчика. Все байты на месте, а этот байт запорчен.


Это сейчас не учитываю. Но я не могу гарантировать, что не поддержу в будущем .


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


Я бы с удовольствием придумал какой-нибудь простой механизм, позволяющий вводить корректный сдвиг, но пока ничего красивого на ум не приходит. Можно расширить интерфейс и задействовать ещё один регистр, но это будет уже некрасиво.


Да, верно. Мы же этот номер и перетираем выше .


По клавиатурным флагам и определяю.


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

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Буду искать такие BIOS'ы.

Я здесь вообще не вижу никакой проблемы. Геометрическая нумерация не нами придумана. При этом нумерация доп. разделов с фиксированного номера 4/5 (в зависимости от выбранной базы) является вполне обоснованной. Можно конечно в EBR-код передавать доп. параметр типа "максимальное количество первичных разделов" или "номер первого доп. раздела" (опять 4 или 5), но я пока не вижу в этом никакой практической пользы. Хочешь универсальности EBR-кода, заведи в нем отдельную ячейку для хранения такого параметра и вычисляй окончательный номер путем сложения "базы" и "смещения". Кстати при таком подходе твоя нумерация доп. разделов, начиная с 1, будет смотреться более логично. Тогда уже понятно, что это относительный номер, т.к. он является элементом пары.

Я же говорю, что стал на свой лад рассуждать и немного запутался.

Ё. Т.е. ты и в MBR-загрузчике тестишь клавиатурные флаги, и в EBR-? Мне кажется, что это как-то неправильно. У меня за dual booting отвечает исключительно MBR-загрузчик. EBR-код только проверяет, требует ли от него MBR-загрузчик загрузки с определенного доп. раздела (обычно это происходит в случае альтернативной загрузки) или он (EBR-код) должен сам определиться, с какого доп. раздела выполнять загрузку (обычная загрузка). Раньше EBR-код даже такой проверки не делал, т.к. при альтернативной загрузке MBR-загрузчик записывал номер альтернативного загрузочного раздела прямо в соответствующую ячейку EBR.

Если пользователь обладает феноменальной реакцией, он может ускорить этот процесс для альтернативной загрузки Как я написал, во время ожидания периодически выполняется тестирование и как только факт нажатия зафиксирован, происходит выход из ожидания. Именно из-за наличия обязательной задержки при обычной загрузке я и не отказался от использования "упрощенных" редакций загрузчиков. Более того, эти редакции считаются основными, а с задержкой - вспомогательными. Правда, в плане объема кода приходится ориентироваться именно на редакции с задержкой, т.к. у них объем больше. Т.е. в основных редакциях всегда остается небольшой незадействованный участок, куда можно вписать копирайт и т.п.

Да я пока тоже не вижу проблемы. Если проблемы возникнут, то не у меня, а у GRUB и у мультибут-совместимых ядрах на альтернативных схемах разбивки на разделы.


Обоснованной, как я уже писал, была бы сквозная нумерация. А так - "Хотели как лучше, а получилось как всегда" (с).


Хорошая идея! Пасиб, так и сделаю.


Криминала в этом не вижу, флаги - вполне себе глобальная переменная. Если я возложу всё на MBR, надо будет расширять интерфейс MBR/EBR. Да, я понимаю, что это волатильная глобальная переменная, но более красивого решения пока на ум не приходит.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

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

По FreeDOS у них проблем нет но только под чистым DOS, а вот из под win32 сделать загрузку нечем кроме всяких FlashBoot и т.п. который по последним данным перехватывая прерывание не дает нормально работать хардовым утилитам которые сами на прямую обращаются к хардам. А в boot еще поддержка hybrid FAT32+ "free copy installation". Как бы плюсов вроде более чем достаточно.

Речь шла о нумерации логически дисков внутри расширенного раздела (дополнительных разделов в моей терминологии), причем "внутри" загрузчика. Эта нумерация хорошо знакома поклонникам линуха и др. GNU-сных продуктов типа GRUB'а. "Обычным пользователям" вникать в подобные обсуждения без надобности. Даже программисты-разработчики первичных загрузчиков под конкретные ФС или "ядер" уже будут получать привычные номера 1-4 для первичных разделов и 5-255 для дополнительных. Я беспокоился о том, что "обычным пользователям", если они все-таки на это натолкнутся, может показаться крайне нелогичным, а точнее сбивающим с толку, когда у них и первичный раздел будет обозначаться номером 1 и доп. раздел будет обозначаться номером 1, когда этот номер сохраняется на диске.