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