Строим дискеты в фасме. Вдруг кому-то пригодится.

Phantom_84

Эм... Признать, может быть. А осознать? У jmp word имеется своя проблема, до которой я ещё не дошёл. Пусть он даже делает то, что от него требуется. А что после прыжка должно быть? Не замечаете, что весь образ съезжает на байт?
P.S. Ах-да. Извиняюсь. Не совсем понял Ваше замечание. Думаю, Вы путаете jmp word и jmp near.

Что значит "даже"? Я пока ни от чего не отказывался. Ладно... Видимо наводку Вы также не осознали. Предалагаю сравнить поле BPB_RootEntCnt в Вашем и моём образе.

 

В общем один раз мне уже приходилось перелопачивать все свои исходники, заменяя byte на short. Теперь, видимо, придется тоже самое проделывать с word и near. Надеюсь, до дальних переходов не дойдет.

 

Phantom_84
Не торопитесь менять с word на near. По крайней мере здесь. Я ведь упомянул об отдельной проблеме. И она касается как jmp word, так и jmp near. Возможно, Вы заметили, что у меня jmp near в соответствующем месте закомментировано. Представьте, что Ваш образ будет создаваться в окружении use32.

 

Не тороплюсь. Это предсказуемо и это можно контролировать. История с заменой byte на short приводила к ошибкам компиляции. С word и near все сложнее. Это источник появления скрытых ошибок, завязанный исключительно на версии компилятора. Т.к. я на fasm'е пишу уже очень давно, для меня это может стать проблемой. Почему бы для прямых переходов во избежание подобных ошибок не сделать использование word таким же некорректным, как это сделано для byte! Исправил так.

Код (Text):

1. if bootimage eq
2. db 0E9h
3. dw 0FFFDh
4. ...

 

Phantom_84

Наверное, потому что word имеет смысл и для прямых переходов. word указывает не на вид инструкции перехода (как short/near/far), а на размер операнда. В случае прямого перехода это размер адреса назначения.
Например,

Код (Text):

1. org 10000h
2. jmp word $

не скомпилируется. А так скомпилируется:

Код (Text):

1. org 0FFFFh
2. jmp word $

Особенно полезными модификаторы размера операнда могут быть в таком случае:

Код (Text):

1. use16
2. org 10000h
3. jmp $

не скомпилируется, т.к. ожидаемый EB FE (равно как и E9 FD FF, кстати) не может прыгнуть по адресу 10000h в 16-битном режиме. А вот так можно достичь желаемого:

Код (Text):

1. use16
2. org 10000h
3. jmp dword $

А можно и так:

Код (Text):

1. use16
2. org 10000h
3. jmp near dword $

 

Как оказалось, это тоже специфично для версии. Раньше таких нюансов не было. "jmp word" кодировал ближний переход в пределах первых 64 кб. В 32-разрядном коде просто появлялся префикс. Сейчас чтобы реализовать ту же функциональность для инструкций прямого перехода, нужно писать "jmp near word". "Окружение use32" конечно опять испортит команду, сделав ее 4-байтовой (3 байта + префикс), но как я уже сказал это предсказуемо и можно контролировать - не использовать use32 или использовать use16, тем более что в "окружении use32" код загрузчика все-равно будет кодироваться неправильно.

P.S. Зачем сбивать с толку народ и делать нетипичные по формату флоппики? Думаю, для флоппика вполне достаточно 224 корневых входа.

 

Phantom_84

Ну что ж, Вам виднее. Мне эти нюансы известны сравнительно недавно, но они соответствуют документации и ИМХО вполне разумны.

Если Вы о моих макросах, то в них за код загрузчика всегда ответственен пользователь. Поэтому это не моя проблема.
Если о своих, то... у Вас либо дефолтный загрузчик (который Вы в последствии описали опкодом), либо он прекомпилирован ответственным за правильность кода пользователем. Если оставите jmp near, то да... будет кодироваться неправильно. И вина будет на Вас. Или Вы эту проблему документируете, лишний раз нагружая мозг пользователя Ваших макросов.

Простой пример:
Я пишу программу, хранящую в себе образ и записывающую его на дискету. Программа под винду. Для этого использую Ваши макросы. Образ храню в секции данных своего PE. И ведь как нарочно забываю перед описанием образа вставить use16. Ну или после описания вернуть use32.

Контролировать нужно со стороны макрописателя. А также минимизировать побочные эффекты. Т.е. упрощённо необходимо нечто в таком духе (без учёта use64):

Код (Text):

1. virtual at 0
2.     xchg eax,eax
3.     detected_32bit = 2-$
4. end virtual
5.  
6. use16
7. ;код, генерирующийся макросами описания образа
8.  
9. if detected_32bit
10.     use32
11. end if

В моём случае проще было написать так:

Код (Text):

1. db 0E9h
2. dw jmpDest - ($+2)

Для себя Вы решаете, разумеется, сами. А пользователю макросов не важно, как именно это реализовано, но важно, чтобы было.

Это какой ещё народ? В документации не сказано, что 224 — типично, а 512 — нетипично. Поэтому на усмотрение автора. В моём случае автор посчитал, что 512 достаточнее.

 

А ты еще забудь org 0 вставить перед образом и после образа скорректировать смещение, увидишь, что получилось, сразу вспомнишь ))) Я не рассчитывал, что образ будет куда-либо вставляться в виде исходника.

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

 

Phantom_84

Подзавязка подзавязке рознь. Отличие моего "типичного формата" от "типичного формата" "популярной ОС" всего 9 kb (полпроцента объёма дискеты). В качестве встречного аргумента могу привести вариант, когда "народ" захочет около трёхсот файлопапок в корневой директории.