Ребят столкнулся с нелепой ситуацией которую никто не может объяснить. Кто знаком с Паскалем тот знает что есть такой оператор mem[$xxxx:$xxxx], который возвращает значение байта памяти... Возникла необходимость прочтитать таблицу векторов прерывания с помощью этого оператора, произошла маразматическая ситуация...одна из тех когда готово пошатнуться представление о мире)))) Он корректно считывает всё, кроме первых восьми байт, первые восемь считывает, выдавая всегда одни и теже числа, но эти числа не соответствуют данным из Dzebug'a d 0:0.... Помогите разобраться, а то у двоих человек мозг расплавиться.)))
Объясню. Ситуация комичная. При запуске дебаг меняет эти первые байты ))) Иначе работать не сможет )))
Код (Text): asm push ds xor ax,ax push ax push ax pop ds pop si lodsw mov word_0_0,ax pop ds end; попробуйте так
Прерывание 01h на которое указывает соответствующий вектор - отладочное прерывание, вызываемое после КАЖДОЙ инструкции процессора. Дебаг вешает свой обработчик на этот вектор, что позволяет ему пошагово выполнять твой код. Те байты, которые ты видишь под дебагом - вектор его обработчика )))
Абисняю. С установленным флагом TF процессор генерирует прерывание с номером 1 после выполненной инструкции, после этого сбрасывает флаг TF и таким образом выполняет код обработчика (в данном случае дебаггера) в НЕПОШАГОВОМ режиме. После команды iret флаги восстанавливаются из стека и процессор опять в пошаговом режиме.
Кстати, есть еще одна особенность дебага (наткнулся еще когда асм изучал, был в шоке) Код (Text): push CX pop CX ; вызванное здесь прерывание затрет отPOPенное значение СХ sub SP,2 pop DX cmp DX,CX ; под дебагом они не будут равны! ))) З.Ы. Прошу прощения за TF ))) Иногда трудно соотнести то, что в голове с тем, что "на бумаге" )))
это нормальная ситуация за исключением случая, если прерывания запрещены. вместо дебага прерывание в этот момент могли вызвать таймер или клавиатура с тем же эффектом - так нельзя делать в реальной программе.
shoo Во времена ДОС в реальных программах так ДЕЛАЛОСЬ ))) Вероятность того, что именно в этом промежутке возникнет прерывание - довольно мала, если программу не отлаживают. Что и использовалось вирусами и другим кодом для противостояния отладке. Правда более "продвинутые" отладчики просто переключали стек )
Кстати сегодня открыл талмуд Фаронова... абсолютно случайно на станице с ответом почти на мой вопрос, только вопросы остались... Дык там сказано что Паскаль для своих нужд при выполнении проги меняет 16 или 18 векторов прерывания на свои... я аж ох*л от такого счастья... только там из первых был int00,int02...так что вопроса не снимало почему первые 8 байт косячит тем более что int02 совпадало с Dzebug'овским... Вот в туториале для начинающих автор ссылается на некий толмуд, ребят посоветуйте хорошую книгу чтоб там и про прерывания и про всё и много и в электронном виде))))) Ту СТ спасибо... неонатёнок мой уснёт и я попытаюсь всосать, то что ты запостил.)))) FreeManCPM завтра опробую)
MayBe Неужели я так мутно изъясняюсь? Мне надо с собой бороться.... А насчет того, чтобы почитать... ОДНОЗНАЧНО - Питер Абель. Assembler - язык и программирование для IBM PC. Более доходчивого изложения я не встречал.
Ок. Всё понятно объяснил у меня ребёнок клавиатуру отбирает))) и мышь пинает... Абель хорош, но я его волнами читаю.... причём хаотичными... Я так подозреваю, что узнать истинное значение векторов можно только откопав их в BIOS'е в том месте откуда они первоначально грузятся... И просматривая Дамп понял что Винда половину векторов если не больше под себя точит...куева хуча одинаковых векторов))))
MayBe В защищенном режиме, в коем работает винда, таблица векторов прерываний располагается не в начале оперативной памяти, а в так называемой IDT (Interrupt Descriptor Table), физический адрес которой находится в регистре IDTR.... в одном посте все сразу не объяснишь... адресация памяти, вычисление адресов обработчиков и еще_много_чего зависит от режима, в котором в данный момент находится процессор. Турбо Паскаль компилирует программы для реального режима, правила которого к винде не применимы )
