Yoda писал(а):
Вопрос: а зачем всё это, если удалось всё нормально разместить в 512 байтах?
Раз ты сделал две версии загрузчика для FAT32, значит не удалось. Кроме того, возможно, "удалось" только путем выбрасывания полезного кода. Те же дополнительные проверки размера памяти и т.п. могут стать критическими для текущего размера загрузчика.
phantom-84 писал(а):
Интересные спецификации. Однако, в свете VolID я рассматриваю это только как потенциальный бонус. Тем более, что после перехода в защищённый режим Int13 перестаёт быть доступным (или же надо делать отдельный Virtual 86 модуль специально для функций BIOS) и что такое Drive 80h - уже остаётся только гадать. VolID в целом более надёжный метод, т.к. предоставляет информацию, не зависящую от BIOS.
Ты видимо хочешь сказать, что VolID можно использовать для идентификации раздела не только в пределах одного диска. Но мой BDI конвертируется ядром в структуру размером 32 байта (минимум) еще в реальном режиме, при этом в ней не остается номера диска BIOS, только - физическое местоположение диска и номер раздела на диске.
Цитата:
Вообще говоря, ОС в любом случае должна просмотреть все разделы всех дисков для их монтирования. Так что ничего плохого в этом нет.
Вообще говоря, это все специфично для системы. У меня к примеру ядро выступает инициатором монтирования только загрузочного раздела, причем сама операция монтирования не имеет никакого отношения к появлению загрузочного раздела в списке "виртуальных устройств" (за это отвечает менеджер разделов), а для появления раздела в списке нет необходимости обращаться к его содержимому. Т.е. твой VolID связан с ФС этого раздела, у меня же раздел - это просто область диска, которая может быть вообще не связана с ФС/не содержать ФС.
Цитата:
Не, базовую память под завязку заполнять нет никакого смысла, потому что в таком случае мы получим загрузку зависящую от множества факторов. Будет очень плохо, если мы столкнёмся с пограничной ситуацией - вот здесь грузится, а здесь нет. С этого носителя работает, а с этого - нет. Более правильный путь - заранее очертить границы применимости. Так я и делаю. До 608к включительно - ок. Больше - разбивайте или сжимайте.
OK. Если я правильно понял, ты считаешь память размером 600h+608 кб гарантированно присутствующей (это приемлемо, хотя лично я без проверки иногда еще могу заюзать участок 7E00h-7FFFh, но не выше), тогда ты должен проверять доступность лежащей выше этой отметки памяти для ее использования в служебных целях (или для загрузки еще немного более крупного образа). Но если ты не делаешь проверки, как понять, доступна она или нет? А если даже станешь делать проверку и окажется, что эта память недоступна или доступна в недостаточном количестве, тогда какую память использовать для служебных целей?
Цитата:
:))) а с чего бы в корне лежал 100-метровый файл ядра, если чётко сказано - 608к? Только если 1) файловая система попорчена или 2) пользователь вышел за рамки спецификаций. И то, и другое - однозначно Achtung!
Какой нехороший пользователь :))) Не делает то, что ему предписано! От этого программы и работают с глюками! Ты хотя бы загружай только первые 608 кб файла (уже нужна проверка его размера), если уж не выдаешь сообщение об ошибке.
Цитата:
32к сверху. Я релокирую бут-код вверх. А что EBDA? EBDA мне не мешает. Я эту область не трогаю :)
Понятно, что "вверх" (у тебя перед адресом загрузки образа только 256 байт свободных остается), но тут возвращаемся к тому, о чем я уже говорил. Чтобы что-то не трогать, нужно знать где это что-то находится, а ты проверку размера доступной (базовой) памяти не выполняешь. И как ты не трогаешь EBDA, если считаешь 32 кб доступными для служебных целей? (1,5+608+32=641,5 кб!!!)
phantom-84 писал(а):
Если всю, то переходи в защищённый режим и используй остальную память. Если не всю, то и базовую память можно нормально использовать. В любом случае, зачем терять кусок памяти, ниже базы загрузки? Его надо впоследствии криво мапировать, либо накладывать на него какие-то переменные (тоже криво). 600h - это первый реально свободный байт, и то, что туда помещается начало пользовательской ОС, выглядит вполне естественным.
Даже у простого загрузчика могут быть потребности в памяти для служебных целей (примеры я уже приводил: стек, буферы для кэширования секторов CD/DVD, FAT и т.п.). Ты вроде бы не возражал против этого. Я оставил для этих целей 30,75 кб. Даже если ты откажешься от твоих гарантированных 608 кб для загрузки образа при сохранении такого маленького адреса загрузки, то тебе придется делать адрес области памяти для служебных целей плавающим, что менее удобно, чем иметь фиксированную область для этих целей.
Цитата:
Нормально перемещается. Нет проблем.
OK. А я загрузчики, не превосходящие по размеру 1 кб могу не перемещать вообще, а превосходящие перемещать частично или даже сделать так, чтобы лежащий выше отметки 8000h код отработал до выполнения загрузки образа. Как понимаешь, проблем еще меньше.
Цитата:
1. Посмотрел на файл NTLDR на одном из дисков. Размер - 297072. Ничему не кратен.
2. Не вижу серьёзной причины для введения кратности. Но если уж так хочется, не пойму, чем база 600h помешала? Да хоть и 123h :)
Я не говорил, что кратность сильно нужна. А сказал, что от нее тоже может быть определенная польза.
Цитата:
3. Если кратность размера файла по каким-то необъяснимым причинам завязана с кратностью памяти, то в чём принципиальное отличие кратности 1024 от 512? Магия чисел? А по мне, так лучше 512. В размер сектора.
Не вопрос, хотя некоторая связь все-таки есть. BIOS возвращает размер доступной базовой памяти в килобайтах. Адрес загрузки ядра кратен 1 кб (8000h=32 кб). Размер ядра кратен 1 кб. Можно вести подсчет доступной базовой памяти в килобайтах:
количество_памяти_для_обоих_файлов_кб = количество_доступной_памяти_кб-32;
количество_памяти_для_драйвера_кб = количество_доступной_памяти_кб-32-размер_ядра_кб.
У тебя файл только один, поэтому кратность размера тебе не нужна (если ты не собираешься хоть как-то проверять корректность загружаемого файла; неужели ты его даже на нулевой размер не проверяешь?). А кратность адреса загрузки не помешает.
Цитата:
4. Не дело это первичного загрузчика, проверять кратность и сигнатуры. Его задача - загрузить файл и передать на него управление. В конце концов, ИМХО, лучше будет, если стартап-код в начале образа сам проверить свою контрольную сумму и полноту загрузки.
Так и происходит, но это не лучше. Если код может быть некорректным, то его лучше вообще не запускать.