При вызове прерывания int 2F в обработчике прерывания 21h (резидент под Дос) просиходит что-то мне непонятное. Т.Е. вызов то идет, то нет. Ну почему?

В чем выражается то нет ?
Не помешает уточнить функции int 21h и int 2Fh.

В том и выражается, что не вызывается.

Все в принципе просто.

Написан свой обработчик записи строки в файл, т.е. все что пытаются записать в файл, пренаправляется в буфер обмена,
т.е.


cmp ah,40h
jne OutLabel
Otsuda:
mov ax,OPEN_CLIPBOARD
int 2Fh
.
.
.

OutLabel:


И вот код между Jtsuda и OutLabel в Доссессии выполняется как хочет.
Может есть какая бяка здесь которую я не вижу?

Перефразирую вопрос.
не вызывается - это означает, что процессор останавливается или срабатывает jne OutLabel?
выполняется как хочет - это означает, что процессор выполняет код не придерживаясь запрограммированной Вами последовательности команд?

Прежде чем открыть Буфер обмена, надо проверить его доступность int 2Fh fn AX=1700h.
Вы уверены, что запись в файл идет через int 21h fn AH=40h, как насчет fn AH=15h, 22H, 28H?

не вызывается означает что непонятно по каким причинам не выполняется даже cmp ah,40h. Точнее при каких-то условиях все отрабатывает как и должно, а при каких-то нет. Проверка на доступность кармана есть.
а запись идет действительно с использованием fn 40h.

по каким причинам не выполняется даже cmp ah,40h
Вот с этого и надо было начинать.
Чтобы судить о причинах недостаточно информации:
1. Когда Вы запускаете TSR?
2. За какой (своей или чужой) программой Вы следите?
3. Как Вы определяете, что Ваш обработчик int 21h вообще получает управление?

Почитайте книгу Эндрю Шульмана (Andrew Schulman) "Неофициальная Windows 95". В ней есть исследование взаимоотношений DOS-TSR и windows, с выводом, что не всякий int дойдет до DOS-TSR. Правда там он исследует "Chicago", но с тех пор windows пошла дальше.

Блин так тяжело напрягать память...

I.ТЕОРИЯ.

1.Начиная с PII што ли появился новый масив битовых флажков в TSS Который указывает должно ли прерывание отрабатывать в VM или нет.
2.Эта особенность используется нынче и в windows, то есть если вы шагнёте в Soft-ICE в int nn вы не замедлительно попадёте отладчиком в защщищённый режим.
3.ТЕОРЕТИЧЕСКИ - для целей повышения производительности Windows может не возвращать управление в некоторых "очевидных" случаях в ДОС.
4.Для проверки этого факта вставьте в свой обработчик INT 3 и установить в Soft-ICE I3HERE, если вы всё-таки получаете управление и вываливаетесь в отладчик, то значит проблема во внутенних флажках СИСТЕМЫ.

II.ПРАКТИКА.

1.Существует доступная вместе с исходниками утилита Filemon от SysInternals, если мне не изменяет память, возьмите её за основу и просто перепишите для своих задач не изобретая велосипеда.

С уважением ко всем ищущим Андрей Бертыш г.Брянск.