Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[18.226.169.94] |
|
Страницы: (2) 1 [2] все ( Перейти к последнему сообщению ) |
Сообщ.
#16
,
|
|
|
Цитата 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. |
Сообщ.
#17
,
|
|
|
Цитата rivitna, 10.03.02, 21:24:41 Я поправлюсь, тем не менее экономия есть, так как обработчик с точки зрения ОС (хотя она и подозревать об этом блоке не будет) будет занимать полное число параграфов без дополнительной информации. Почему "с точки зрения ОС", потому что ОС выделяет память параграфами. Чем ближе код обработчика к краю, тем меньше вероятность его затирания. Экономия ценою экстремальной работы! Но тем не менее... Я не увидел в коде ни одного обращения к функции выделения памяти. Также я не увидел никакого выравнивания по параграфам. Поэтому блок в памяти будет занимать полное число слов, т.к. перемещение "резидентной" части идет по словам. А DOS действительно не будет подозревать о существовании резидента. Поэтому с точки зрения OS блока существовать не будет. А вот насчет видимости или невидимости, то любой резидентный антивирусный сторож (для DOS) выдаст большое красное окно, о наличии непонятного куска кода в свободной памяти... --- Ну, вот, мы и договорились до горячей темы... |
Сообщ.
#18
,
|
|
|
Цитата 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. Поэтому я и предложил использовать относительные смещения... (см. мою первую мессагу) |
Сообщ.
#19
,
|
|
|
Цитата Я не увидел в коде ни одного обращения к функции выделения памяти. Также я не увидел никакого выравнивания по параграфам. Поэтому блок в памяти будет занимать полное число слов, т.к. перемещение "резидентной" части идет по словам. Вчера милиция разогнала демонстрацию коммунистов до 75 км, а ты, Андруишка все тормозишь. Допустим такую гипотетическую ситуацию, обработчик занимает в памяти 17 байт и лежит начиная с параграфа 3456h Так как ОС выделяет память параграфами, а не байтами и словами, какой-то программе понадобилось 3 байта и ОС выделит, допустим параграф 3457h (блоки-то свободные), а там последний байт обработчика, вот и покумекай, на деле сколько обработчик занимает в памяти. Хоть и обработчик и занимает сколько-то слов (причем слова, не пойму, байты уж тогда), опасность исходит от ОС в виде затирания параграфа, на который он наложился. Поэтому и следует говорить, что надо округлять до параграфа |
Сообщ.
#20
,
|
|
|
Цитата 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 вместе с резидентной частью? |
Сообщ.
#21
,
|
|
|
Цитата Andruishka, 10.03.02, 22:02:06 А почему бы в связи с этим не копировать поле ORIG вместе с резидентной частью? Так и я про то же! Мы с тобой квиты, а в целом разговор очень даже ничего получился! |
Сообщ.
#22
,
|
|
|
Слона-то я и не приметил, упустил две строчки:
Цитата SUB word ptr DS:[03h],5h SUB word ptr DS:[12h],5h Одна корректирует поле MCB 03h (количество параграфов в блоке) на количество занятых обработчиком, другая - поле PSP 02h (номер последнего параграфа, доступного программе). Благодаря этим строчкам параграфы, занятые обработчиком, исключаются из дальнейшего. Так что мои разговоры о вероятности затирания были излишни. В этом плане все чинно и благородно! |
Сообщ.
#23
,
|
|
|
Слушайте, ну вы прямо как Шерлок Холмс и доктор Ватсон разговорились
тут пока меня не было. Увлекательное и познавательное чтиво для меня. :) А на счёт "jmp dword ptr es:[orig]" - я это исправил, просто забыл править сообщение № 5. |
Сообщ.
#24
,
|
|
|
Цитата rivitna, 10.03.02, 22:13:50 Мы с тобой квиты, а в целом разговор очень даже ничего получился! Ok, я тоже так считаю... Сообщения были разделены в тему "TSR без PSP" |