Создание TSR программ в операционной, страница 3

Следующим требованием является корректное использование сервиса DOS в резидентном модуле. Вообще говоря. использовать функций DOS в TSR-программах можно только тогда, когда прерывается выполнение прикладной программы. Если же в момент активизации резидентной программы управление находится у операционной системы, то сервис DOS использовать нельзя. Это объясняется нереентерабельностью функций DOS. Таким образом, к основным требованиям на TSR-программы, необходимо также отнести обязательную проверку, можем ли мы в данной ситуации пользоваться теми или иными системными средствами. Как правило, в резидентных программах или вообще отказываются от использования "сомнительных" функций и заменяют их своими, или проверяют состояние флага "нахождения в DOS" (InDOS флаг). Если InDOS флаг не равен О, то в резидентных программах нельзя пользоваться сервисом DOS. Если все же необходимо использовать какую либо функцию DOS, то прибегают к отложенному вызову этих функций. Проверка состояния InDOS флага осуществляется с помощью функции DOS 34h (или через BIOS). Естественно, эта функция может быть использована вне зависимости от состояния InDOS флага, иначе она была бы бессмысленной. Эта функция существовала уже в ранних версиях DOS, однако, вплоть до версии 5.0 она относилась к числу недокументированных функций. В версии 5.0 она была раскрыта. Кроме того, вследствие недокументированности этой функции, она не работает в популярной операционной системе DRDOS (зарегистрированная торговая марка фирмы DIGITAL RESEARCH).

Функция 34h. Получить адрес InDOS флага (Get InDOS Flag Adress)

MOV AH,34h    ; заносим номер функции DOS в регистр АН

INT 2lh              ; вызов диспетчера DOS

После выполнения этой функции в паре регистров ES:BX находится адрес InDOS флага.

При создании TSR-программ обычно приходиться решать вопрос об условиях ее активизации. Заметно выделяется группа программ, активизирующаяся при нажатии горячей клавиши (комбинации клавиш). Часто используются способы активизации по показаниям системного таймера, по обращению к перехваченному прерыванию, по вызову пользовательского прерывания определенного при инсталляции (установке) резидентной программы, которое обслуживается резидентной частью этой программы, и по другим событиям, определенным при разработке программы.

Для предотвращения многократной загрузки TSR-программа должна при запуске проверить наличие себя в памяти. Для этого рекомендуется использовать мультиплексное прерывание 2Fh:

Вход      AH      номер мультиплексного процесса

01H = резидентная порция команды DOS 'PRINT'

02H = резидентная порция команды DOS 'ASSIGN'

10H = резидентная порция команды DOS 'SHARE'

03H-7fH (зарезервировано)

80H-0ffH (доступно для программистов)

AL      номер подфункции

Выход           AX      код ошибки, если взведен флаг CF  (для процессов DOS)

AL      статус установки (для процессов DOS)

00H = не установлен. Можно устанавливать

01H = не установлен. Нельзя устанавливать

ffH = установлен

Этот вектор (0000:00bc) предоставляет средства управления процессами, доступные всей системе из любого приложения. Каждый процесс должен включить себя в цепочку прерываний с этим кодом, и каждый процесс в цепочке должен проверять AH на свой мультиплексный номер процесса. Если запрос относится к другому процессу, активный процесс должен передать управление по первоначальному адресу прерывания 2fH (по адресу, который был в векторе (0000:00bc) перед тем, как текущий процесс установил себя). INT 2fH не определено для более ранних версий, чем DOS_3.0.

Можно использовать INT 2fH как вход для установки и доступа к вашему собственному резидентному процессу. Идея состоит в следующем: Если вы произвольно используете вектор прерывания для вашего собственного доступа, то вы подвергаетесь определенному риску, особенно в мультизадачной системе. Если же вы используете предлагаемую мультиплексную "цепочку", то DOS знает о вас, и ваш вектор не будет перекрыт другим обработчиком. Одна возможная проблема: нет предопределенного способа определить мультиплексный номер вашего процесса (регистр AH). Плохо привязываться к конкретному числу, ибо нет гарантии, что другой процесс не будет использовать этот же номер. Вы должны предусмотреть какую-то логику, гарантирующую вам четкое опознание вашего процесса. Ваш процесс должен по меньшей мере использовать подфункцию AL=0, чтобы вы могли выяснить, не был ли процесс уже установлен ранее.