Затыкаются прерывания при вызове int 10h п/у DOS32/A в WinNT5 DOS-окне

Здравствуйте!

Пишу прогу в защищенном режиме под управлением DOS-расширителя DOS32/A. При запуске из-под DOS (виртуальная машина или же чистый DOS) все в порядке - прерывания работают (мне необходимы прерывания таймера и клавиатуры, а также Sound Blaster, если определится) и до работы с простым графическим режимом или VESA, и после.
При запуске этого хозяйства под Windows 2k/XP/2k3 прерывания сначала работают, а затем даже после проверки наличия VBE/VESA прерывания глохнут. Убирал проверку VBE/VESA, делал просто mov ax, 013h/int 10h - та же фигня. Если делать mov ax, 003h/int 10h - то прерывания работают как и должны, но нужного экрана нет .
Пробовал после работы с VBE/VESA и установки видеорежима инициализировать прерывания заново - маски для обоих PIC, обработчики прерываний - все глухо. Прерывания как будто пропадают с концами.
Отсюда вопрос - как это побороть? Возникло ощущение, что винда, думая, раз я переключаюсь в графические режимы, значит, мне нужна более современная периферийная база, - выключает PIC и включает APIC. Но я не умею с ним работать, судя по докам, геморрой там еще тот (ну или не очень, просто моя лень утрирует )... Хотелось бы в таком случае его отключить, чтобы вернуть на место PIC. Как это делается, учитывая, что выполнение происходит под виндой?

Да, кстати, когда я использую dos4g.exe вместо dos32a.exe, результат тот же. Однако некоторые старые, но навороченные DOS-овские игрушки вполне продолжают работают в тех же условиях. Там и графический режим, и прерывания работают...

Спасибо!

 

Может я что-то не так описал или случай странный, что никто не отвечает? Надо ли что-нибудь уточнить?

 

Вот налабал простой пример для демонстрации. Если убрать строчки

Код (Text):

1.                 mov V86regs._AX,13h
2.                 intx 10h

или просто поменять значение 13h на, например, 3 (обычный текстовый экран), тогда прерывания не пропадают и все работает. Есть ли какие соображения?

 

Просто случай действительно странный.
Ну должно всё работать... Ошибка не в коде.
Это проблемы с экстендером.
Попробуй другую версию DOS32/A, а лучше другой экстендер.
PMODE например. Просто 99% что ошибка в самом расширителе.

 

Спасибо за ответ
Так в том-то и дело, что я специально проверил без расширителя - та же фигня. Приложенный выше пример (за основу я взял тестовую прогу, так что там половина лишнего) компилится связкой tasm/tlink в DOS-овый exe-шник. Который под чистым DOS'ом или эмулятором работает, а из-под DOS-окна WinNT - нет. Пример я для того и выложил, чтобы можно было легко проверить. В нем на экран выводятся скан-коды нажимаемых и отпускаемых клавиш. Для этого, естественно, нужно, чтобы работали прерывания, в частности, от клавы. И они пропадают (при запуске из-под Win2k/XP/2k3, другие не пробовал) при переходе в графический режим, более подробные условия я описывал выше.
В моей другой основной программе в том числе нужны еще прерывания от таймера. Они также глохнут, так что вроде дело не в клавиатуре. Главный вопрос - что с этим делать: как-то вернуть на место PIC'овские прерывания, либо запрограммировать APIC? Или дело вовсе не в том? :'(

P.S. Пытался я другой экстендер подсунуть, например, DOS4G. То же самое. Но ведь старая DOS-овая игрушка BLOOD, написанная под этот расширитель, нормально работает при запуске напрямую из-под WinNT.
Еще я пытался после всех махинаций с int 10h разрешать прерывания явно - sti, косвенно - mov ax, 00901h/int 31h, методом тыка - вызывал "древние" прерывания BIOS int 11h, int 12h и т.д.. Естественно, пробовал все сразу + заново перенастраивал прерывания/обработчики.
Но пока ничего не помогло. Два exe-шника могу накомпилить и выложить, чтобы посмотреть на спецэффект было совсем просто .
Есть еще идеи?

 

Не забывай что в WinXP используется модифицированная версия Доса чем Win98/WinMe, может поэтому и не работает.

 

Гы, а теперь прикол - всё ведь работает
Довод первый - ты Esc жмёш прога закрывается?
У меня да. А сканкод тем же обработчиком читается.
Значит есть прерывания.
Просто вывод на экран в графическом режиме не работал.
Попробуй модификацию из аттача, у меня работает (WinXP SP2).

 

Это да, но почему сначала все работает?

Я щас заплачу. Так и не заработало.

В том-то и дело, что нет. Вывод на экран как раз наоборот, у меня работал. Собственно, у меня вывод на экран работает в обоих случаях. По Esc ни фига не закрывается )).
Я запускал под Win2k на 4-й целке и под Win2k3 на Sempron. Результат один... А какой у тебя проц-то? Даже не знаю, куда копать, о чем спрашивать...

 

Pentium(R) 4 CPU 3.00GHz и Intel(R) Celeron(TM) CPU 1100GHz.
И там и там WinXP SP2, и там и там работает.
На всякий случай бинарник в аттаче.

 

Спасибо, проверил - не работает. Только зазывающая надпись "Press Esc to continue..." и все - никакого экшена... Сегодня вечером попробую проверить на WinXP SP2.

 

Кстати, сейчас проверил на рабочей машине (где win2k sp4 + цел4) Wolf3D и Blood. Оказывается, они так же виснут при переходе в графический режим. При этом когда выходишь в диспетчер задач, видно, что к заголовку MS-DOS окна прибавилось слово "ЗАФИКСИРОВАН". Что бы это значило?

 

Кто его знает...
Задачу наверное заморозили по каким-то причинам...
В общем это скорее всего ограничение NTVDM.
С процессором это никак не связано...

 

Не знаю что за фигня.
Win2k SP4 OEM под Microsoft Virtual PC - работает, Win2k3 на реальном железе - тоже.
Все Win кроме Win2k3 русские, 2k3 - английская.
Так что я даже не знаю как помоч - у меня глюк не воспроизводится...

 

Обидно. А как мне узнать подробнее о работе NTVDM и его замашках? Это где-нибудь документировано?
Попробовал вчера на win2k3 запустить те же Wolf3D и Blood. Результат тот же. Но я помню, что раньше на той же win2k3 они работали. Я в растерянности. Такое ощущение, что причиной может быть также какая-нибудь установленная программа...
Спасибо огромное за содействие и помощь. Картинка немного прояснилась, хотя ответа на вопрос так и нет.
Наверняка кто-нибудь знает, да молчит. По-прежнему, жду любых соображений и идей, как избавиться от сего.

 

Вроде получилось - прерывания заработали. Началось с того, что я решил сообщать системе о перемещении векторов PIC через VCPI, если последний присутствует (AX=0DE0Bh, BX=первый вектор master PIC, CX=первый вектор slave PIC, int 67h). Закончилось тем, что при инициализации PIC'ов я отменил ICW4, зачем лишний геморрой? После этого вдруг все заработало, но пока только на рабочей машине, домой приду проверю.
Что самое интересное - когда я не затрагивал инициализацию через ICW, а изменял только маску прерываний, это тоже было плохо. Так что теперь алгоритм инициализации PIC'ов таков:

1. Получаем через DPMI текущие вектора PIC'ов;
2. Если они отличны от обычных 008h для master и 070h для slave, то пропускаем дальнейшую процедуру инициализации;
3. Инициализируем контроллеры PIC без ICW4 на вектора 050h для master и 070h для slave; если присутствует VCPI, информируем через него систему о том, какие у нас теперь вектора для контроллеров PIC;
4(?). Если переход в DPMI (DOS extender'ом) был выполнен из среды "clean" DOS, то дальнейшие шаги пропускаем;
5. Получаем через DPMI текущие вектора PIC'ов;
6. Если они не равны установленным 050h для master и 070h для slave, тогда инициализируем PIC обратно на вектора 008h и 070h и информируем об этом систему через VCPI (если есть).

Наверное так. У кого какие соображения, может что не так?

 

Гугл-то не в теме, хотя "DOS-машинка" рульная. Проги отлаживать, боле-менее сносно получаеться S-Ice, ставя всплытие по bpint 1, и то лишь после перехода в PM, хотя блуждать по дебрям ntoskrnl/dosx/ntvdm придеться довольно долго.

А так ожидать многого от него не получиться - т.к код работает в ring3, в котором широко используеться эмуляция, в том числе и железа
Например это

Код (Text):

1.  mov al, 20h
2.  out 20h, al

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

 

Мда... На домашнем компе (win2k3) по-прежнему не работает, также по-прежнему там виснут старые досовые игрушки вроде wolf3d/doom/blood. На рабочей же машине это все вдруг стало работать (хотя, см выше, не работало) и, естественно, заработал мой эмулятор. Дело похоже именно в состоянии ОС - установленные программы/настройка.
Подозрение на Visual Studio / Borland C++ Builder. Ибо везде у меня установлен Visual Studio, но на рабочей машине (win2k) недавно понадобилось установить и попользовать сильно нелюбимый мною Borland (предрассудки, предрассудки...), после чего вроде бы прерывания перестали затыкаться. Однако дома я также установил (и попользовался) борланд после вижуал студии, но эффекта никакого - прерывания как затыкались, так и затыкаются. На днях вообще пришлось переставлять ОС дома... спохватился, когда обе отладочных среды были уже установлены. Проверил - то же самое. Облом :'(

 

Так с расстояния точно судить нельзя, но вполне дело может быть в каком-то ПО.
У меня проблемы были со SpeedFun, а точнее с giveio.sys.
Устанавливаю - и всё, в DPMI программах (например Borland C++ 3.11 IDE ) клавиатура вообще не работает
Снёс - опять работает. Так что надо смотреть ещё какое ПО стоит...

 

Нифига этот вариант присоединенный не работает, выдаёт только ошибки

 

Чего за ошибки?? Всё вроди работает, ты под чем запускаеш?
ПС: ещё проверил на WinXP SP2 OEM RU - тоже всё функционирует.