http://bugs.winehq.org/show_bug.cgi?id=6953
Robert Wm Ruedisueli esd45@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |esd45@earthlink.net
--- Comment #21 from Robert Wm Ruedisueli esd45@earthlink.net 2010-07-14 19:57:48 --- Has anyone run a trace on what sections of the Win32 subsystem it's trying to scan for emulation?
Several things can be checked for emulation.
What I've noticed in logs is attempts to directly access the drive through I/O.
This would be my number one suspect without even seeing that. It's only a logical course of action to directly access the drive in manners that would be near impossible to emulate to check if it's real.
Pass through access to the drive is possible in VirtualBox, which can directly pass I/O to a drive. It's virtual drive fails virtual drive tests, and it's physical pass-through passes them. It's a perfect example of how it should be done.
Since Wine doesn't even do any real emulation, this should be even easier on it. If we can get someone with knowledge in that field to write a patch to do so, it would be nice.
I don't know about other systems, but Linux systems grant direct I/O to the CD/DVD drive systems using the group system. The "wine" group should be configured to have access to these groups, if it doesn't already. It then needs the proper routines to forward those I/O requests when sent to the various Wine drivers that handle them in Win32.