Jukka Heinonen wrote:
Robert Shearman:
This patch disables DPMI. If sti has been executed beforehand and an instruction (such as an interrupt) must be emulated then it can cause an infinite loop around the enumation of the iret instruction in the DPMI call. Even after (probably rather poorly) hacking around this issue I still got unprivileged instruction exceptions from the iret instruction. Without more expert eyes being cast on this code the only thing I can suggest to fix non-DPMI applications with the above case is to disable DPMI event checking.
Well, your patch actually just disables checking for asynchronous events in DPMI mode, not the DPMI mode itself, which leaves open whether you are trying to run a Win16 program or a DOS program that does not need working IRQ handling in DPMI mode.
It is a Win16 program and I don't think it uses DPMI at all.
I'm sure DPMI asynchronous event handling still has bugs and I guess disabling it is acceptable if it looks like it causes problems and fixing the bugs seems to require too much work.
I have tried to fix it in a sane way, but I don't have any more time to work on it.
However, the patch comment and the quote above tell me next to nothing about the bug you are seeing, more information would be required in order to have any hope of fixing the bug. And I'm probably going to be quite busy, anyway, so I'm not sure when I have time to look at this bug.
I think the program does this: sti int 1a cli
This seems to cause the problem after the "int 1a" has been emulated as it inserts an event check and then tries to emulate the iret instruction which then seems to cause another event check and so on. I would like to fix this in a sane way, but I don't really know what is going on in this area.
Rob