проблема с tsr

Цитата rivitna, 10.03.02, 21:16:18

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

Повторяюсь, при компиляции этого текста в .com файл результат неизвестен, т.к. cs:[02] попадает в область PSP. Насчет того, что затирание кода маловероятно, я вижу в этом коде малопредсказуемую чепуху и соответственно вероятность затирания предсказать не могу...

Цитата

В том виде, в котором изложена программа, это не верно и вызовет ошибки.

Не согласен, в тексте написано ORG 100h, это признак того, что программа компилится в .com, соответственно программа будет загружена по адресу CS:100h, и обращение CS:[02] попадет в область PSP. Если программа компилится в .exe, то директива ORG 100h вызовет смещение адресов на 100h и опять же CS:[02] не попадет на данные ORIG.

Цитата rivitna, 10.03.02, 21:24:41

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

Я не увидел в коде ни одного обращения к функции выделения памяти. Также я не увидел никакого выравнивания по параграфам. Поэтому блок в памяти будет занимать полное число слов, т.к. перемещение "резидентной" части идет по словам. А DOS действительно не будет подозревать о существовании резидента. Поэтому с точки зрения OS блока существовать не будет.
А вот насчет видимости или невидимости, то любой резидентный антивирусный сторож (для DOS) выдаст большое красное окно, о наличии непонятного куска кода в свободной памяти...

---
Ну, вот, мы и договорились до горячей темы...

Сообщение отредактировано: Andruishka - 10.03.02, 18:48

Цитата Andruishka, 10.03.02, 21:34:41

Повторяюсь, при компиляции этого текста в .com файл результат неизвестен, т.к. cs:[02] попадает в область PSP. Насчет того, что затирание кода маловероятно, я вижу в этом коде малопредсказуемую чепуху и соответственно вероятность затирания предсказать не могу...

Упоминание про компиляцию некорректно, когда ОС запускает com-файл, готовит для него PSP, заполняя поля, в частности [02], который является номером последнего параграфа доступного программе.
Так как com-программме выделяет всю доступную память (а именно самый большой единый кусок), то [02] содержит в принцпе номер последнего параграфа 640кб.
Данный эффект часто используется для определения свободной основной памяти:
(cs:[02]-cs)*16
Повторяюсь, это весьма жизнеспособно, но не стоит второй раз запускать данную программу.

Цитата

Не согласен, в тексте написано ORG 100h, это признак того, что программа компилится в .com, соответственно программа будет загружена по адресу CS:100h, и обращение CS:[02] попадет в область PSP. Если программа компилится в .exe, то директива ORG 100h вызовет смещение адресов на 100h и опять же CS:[02] не попадет на данные ORIG.

Все дело в том, что Ilyia, сначала копирует обработчик, правда почему-то оставляет ORIG в старом сегменте, а потом обращаясь к нему, как es:[ORIG], как это работает (по его словам) ума не приложу.
Так вот, подразумевается копирование и адреса старого обработчика ORIG, который входит в состав обработчика.
А уж потом в ORIG записывает адрес старого обработчика (уже на новом месте).
А на новом месте, у ORIG будет новое смещение, но никак не 102h, смещения в изложенном коде начинаются с 0. Поэтому я и предложил использовать относительные смещения... (см. мою первую мессагу)

Цитата

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

Вчера милиция разогнала демонстрацию коммунистов до 75 км, а ты, Андруишка все тормозишь.

Допустим такую гипотетическую ситуацию, обработчик занимает в памяти 17 байт и лежит начиная с параграфа 3456h
Так как ОС выделяет память параграфами, а не байтами и словами, какой-то программе понадобилось 3 байта и ОС выделит, допустим параграф 3457h (блоки-то свободные), а там последний байт обработчика, вот и покумекай, на деле сколько обработчик занимает в памяти. Хоть и обработчик и занимает сколько-то слов (причем слова, не пойму, байты уж тогда), опасность исходит от ОС в виде затирания параграфа, на который он наложился. Поэтому и следует говорить, что надо округлять до параграфа

Цитата rivitna, 10.03.02, 21:51:05

Упоминание про компиляцию некорректно, когда ОС запускает com-файл, готовит для него PSP, заполняя поля, в частности [02], который является номером последнего параграфа доступного программе.
Так как com-программме выделяет всю доступную память (а именно самый большой единый кусок), то [02] содержит в принцпе номер последнего параграфа 640кб.
Данный эффект часто используется для определения свободной основной памяти:
(cs:[02]-cs)*16
Повторяюсь, это весьма жизнеспособно, но не стоит второй раз запускать данную программу.

Признаю ошибку, я не знал про поле cs:[02];

Цитата

Все дело в том, что Ilyia, сначала копирует обработчик, правда почему-то оставляет ORIG в старом сегменте, а потом обращаясь к нему, как es:[ORIG], как это работает (по его словам) ума не приложу.
Так вот, подразумевается копирование и адреса старого обработчика ORIG, который входит в состав обработчика.

А почему бы в связи с этим не копировать поле ORIG вместе с резидентной частью?

Сообщение отредактировано: Andruishka - 10.03.02, 19:02

Цитата Andruishka, 10.03.02, 22:02:06

А почему бы в связи с этим не копировать поле ORIG вместе с резидентной частью?

Так и я про то же!

Мы с тобой квиты, а в целом разговор очень даже ничего получился!

Слона-то я и не приметил, упустил две строчки:

Цитата

            SUB  word ptr DS:[03h],5h    
                                       
            SUB  word ptr DS:[12h],5h  

Одна корректирует поле MCB 03h (количество параграфов в блоке) на количество занятых обработчиком, другая - поле PSP 02h (номер последнего параграфа, доступного программе). Благодаря этим строчкам параграфы, занятые обработчиком, исключаются из дальнейшего. Так что мои разговоры о вероятности затирания были излишни. В этом плане все чинно и благородно!

Слушайте, ну вы прямо как Шерлок Холмс и доктор Ватсон разговорились
тут пока меня не было.  
Увлекательное и познавательное чтиво для меня.  :)

А на счёт "jmp dword ptr es:[orig]" - я это исправил, просто забыл
править сообщение № 5.  

Сообщение отредактировано: Ilyia - 10.03.02, 20:47

Цитата rivitna, 10.03.02, 22:13:50

Мы с тобой квиты, а в целом разговор очень даже ничего получился!

Ok, я тоже так считаю...

Сообщения были разделены в тему "TSR без PSP"