If someone can tell me what the low-level access that these protections use is actually called (i.e. what search term to use in MSDN to look for documentation etc) as well as info on whatever the relavent linux low-level access stuff would be, I can look at drawing up some kind of "here is how this could be done" document.
I believe ASPI is a commonly used interface. Certainly on a game I tried last night, ASPI was used to try and do something with SecuROM.
Similar low-level hooks could be used to allow things like AudioCatalyst (program that converts audio-cd tracks to MP3 files) and anything else that does lower level access to CDs/DVDs than the high-level file I/O APIs and etc. (the day its possible to run Nero Burning Rom in WINE with no problems will be a great day indeed for the project :)
If you implemented low level CD routines, that'd be why you did so. But considering the wealth of Linux programs that are available for these tasks, it's not an especially high priority.
If this isnt fesable for copy protection and so on, please explain why (I know nothing about copy protection or how to program the CD-ROM in win32) Basicly, I dont understand why there is a need for "protection-specific" code in WineX when you could emulate whatever the protection uses and appear just like real windows to the game...
Basically, at least some copy protection systems attempt to load the Win32 equivalent of kernel modules. SafeDisc does this for instance in order to detect debuggers and .... well, who knows what else.
If you use google power you can probably find the original analysis of how SafeDisc worked, basically lots of disassembly was required, as well as producing a user mode Wine version of the driver it used.
So, implementing support for copy protection is not so simple. Wine cannot currently run native Win32 VxDs (or .drv files), they must be rewritten for Wine.