Столкнулся с неработоспособностью DOSLFN на Хароне...
Столкнулся с неработоспособностью DOSLFN на Хароне-386: программы с поддержкой длинных имён файлов либо не видели их, либо (если запущен EMM) падали с сообщением об ошибке. Сначала грешил на проблемную CF-карту, на битую память, на ошибку в схеме по части подключения CF, но в итоге стало понятно что проблема, скорее всего, программная. Я долго не хотел лезть в эту проблему т.к. совершенно ничего не знаю ни об отладке в MSDOS, ни даже ассемблера x86 (спойлер: если бы знал, проблема бы решилась спустя 30 минут после прочтения сообщения об ошибке). В общем, пришлось погрузиться в этот мир на пару вечеров. В обнимку с debug.exe (а позднее уже и Turbo Debugger) и документацией по DOS API, скачанной с самых задворков интернета, написал небольшую программку, которая всё что делает - это простое обращение к LFN API для поиска файла по длинному имени. Ожидаемо, на Хароне это обращение проваливалось - с ошибкой “файл не найден”, в то время как на любой другой машине проходило.
Долго ли, коротко ли - трассировка привела к замечательной функции в исходниках DOSLFN:
proc GlobbingEx
mov di,[CurPathComp]
xchg si,di
call Globbing
xchg si,di
db 0D6h ;setalc
or al,al
_glob_ret:
ret
endp
Эта функция вызывается для каждого файла в каталоге и сопоставляет его длинное имя с искомым. И трассировка показала, что именно в этой функции есть странная инструкция “db 0D6h ;setalc”, которая на Хароне выполняется не так, как на других машинах! Оказалось, это недокументированная инструкция, которая по факту есть во всех процессорах начиная с 8086. Во всех, но, не в M6117D, который используется в Хароне! И который вроде как заявляется как полностью 386SX-совместимый. После замены этой инструкции на стандартную “sbb al,al”, которая делает то же самое, но занимает на 1 байт больше места (вот так “экономия”!), DOSLFN прекрасно заработал. Вот такой мини-детектив. Письмо мейнтейнеру DOSLFN я написал, надеюсь, это исправление войдёт в следующую версию.