Ove Kaaven ovehk@ping.uio.no writes:
I know of two Wine architecture issues that must be resolved before the anti-debugger check can succeed in win95 mode.
- it checks that teb->debug_context (TEB offset 0x20) is zero. In Wine,
it isn't (the NT pid is stored there), so this check fails.
Is it possible to change Wine's TEB structure to fix this?
It would probably break some of the NT native dlls.
- it messes with the IDT. It uses the sidt instruction and tries to
change the INT5 vector (BOUND exception vector), later to try to execute a BOUND and expect this vector to be branched to, all protected with exception handlers. Now, this would actually be possible for Wine to emulate, even though sidt is not a privileged instruction. The idea is that sidt returns an address to kernel space, where all access is prohibited, hence causing page faults. Wine could trap these, and then emulate the faulting instruction by operating on a fake IDT instead. And then the segfault caused by BOUND could then look up the fake IDT entry, and call the vector therein.
But to emulate an instruction from Wine's pre-exception page fault handler (VIRTUAL_HandleFault()), the current context must be passed along to it, so VIRTUAL_HandleFault and all Wine handlers that can be registered with VIRTUAL_SetFaultHandler must get an extra parameter. Is this too objectionable to do?
The extra parameter is not that bad, but having to do full emulation of all instructions accessing memory, plus the complete IDT handling, is going to lead to major ugliness.
Wouldn't it be possible to somehow emulate the kernel driver to make the NT version work? That would be much cleaner.
On 18 Oct 2001, Alexandre Julliard wrote:
Ove Kaaven ovehk@ping.uio.no writes:
I know of two Wine architecture issues that must be resolved before the anti-debugger check can succeed in win95 mode.
- it checks that teb->debug_context (TEB offset 0x20) is zero. In Wine,
it isn't (the NT pid is stored there), so this check fails.
Is it possible to change Wine's TEB structure to fix this?
It would probably break some of the NT native dlls.
Well, perhaps it could depend on the windows version somehow...
But to emulate an instruction from Wine's pre-exception page fault handler (VIRTUAL_HandleFault()), the current context must be passed along to it, so VIRTUAL_HandleFault and all Wine handlers that can be registered with VIRTUAL_SetFaultHandler must get an extra parameter. Is this too objectionable to do?
The extra parameter is not that bad, but having to do full emulation of all instructions accessing memory, plus the complete IDT handling, is going to lead to major ugliness.
Well, I already have some code that basically does this and works, so it can't be that bad (though it's kinda proof-of-concept-quality)
Wouldn't it be possible to somehow emulate the kernel driver to make the NT version work? That would be much cleaner.
Maybe... I was just concerned whether you'd like Wine to be subject to lawsuits or something (reverse engineering, trade secrets, DMCA, whatever... not that the kernel driver is really complex, though). Also, I was afraid some games might refuse to work with --winver nt40