> > > what I'd do is: > > > - simulate (as for DR?) the IDTR read/write (memory/instr) > > > - provide our own interrupt table > > > - then hook the signal catches to this table (dlls/ntdll/ > > > - in your case, especially the divide by 0 signal to entry 1 of this > > > table > > > > > > however, I don't think this is the best way to go. It will add lots of > > > code to Wine (mainly i386 virtualization), and let programs modify > > > things > > > they shouldn't normally need to touch. > > > > Even if you did this, it probably wouldn't help much, as the > > interrupt routine is supposed to be executed in ring 0 (which > > presumably is the very *reason* the program does this nonsense). > > > > So you'll fail immediately afterwards due to privilege > > violations as the app does whatever it wants to do in ring 0 ... > > > > Of course, you could add virtualization for all the ring 0 stuff, > > but this is quite open-ended :-( > > The copy-protection support in WineX does some of this stuff. If the stuff > the application in question does is just another copy protection (sounds > like it), then the additional ring 0 stuff you need to virtualize is > probably just access to the debug registers.
The application tries to execute some (trivial) code in ring 0 mode by modifying the IDTR when run in win95/win98 mode. The problem doesn't occur in winNT mode, so I don't think we should implement a complete ring 0 virtualization. In winNT mode the debugger detection is done by calling int 0x01 and checking a 'side effect' (probably an exception handler effect). I'll check if the detection fails or not. Laurent Pinchart
