Roderick Colenbrander wrote:
Hi,
I don't know much about the cd-rom stuff on osx but I expect there are much more issues of which some are more severe than this (and the solution might fix all the issues). I believe that on osx there is no such thing as direct cd-rom access (anymore) and due to this I think wine can't read audio tracks, neither can we write CDs from Wine or read special data tracks needed for e.g. copy protections.
There is this CFPlugIn object called the "SCSITaskDevice" that lets us get raw SCSI access to devices like CD-ROM drives. But there are a number of issues with it. For one thing, all the descriptors to all the device files have to be closed (because the files go away when using the object), and the disk has to be unmounted (same reason). I have a patch that uses this object, but it's useless right now because wineserver holds an FD to the device file which must be closed. Guess I'll have to take that up with AJ.
As far as I remember Transgaming wrote their own cd-rom driver for this, so perhaps that's the direction we should head into as well else we will never get copy protections working on OSX.
You mean they wrote a kernel extension that replaced Apple's? I've thought about doing that, and I even have one that does drive locking. (The key is the IOMediaBSDClient class family, which provides the device files themselves. They can be extended to support almost anything.) Not sure if AJ will accept it, though. The fact that it's a KEXT and the fact that you have to write IOKit KEXTs in C++ are definite blockers.
Or did you mean something else entirely?
Roderick
On Wed, Oct 14, 2009 at 5:02 PM, Joerg-Cyril.Hoehle@t-systems.com wrote:
Chip,
I had hoped that your patch would allow mcicda to work, cf. bug #20323, alas it is not so. Instead I get to see
ERR("This version of Mac OS X does not support IOCDAudioControl" on Leopard.
I googled slightly and found a message from 2004: http://lists.apple.com/archives/darwin-drivers/2004/Jul/msg00049.html
IOCDAudioControl is deprecated if not obsolete.
Therefore I believe the user should not be bothered with a reference to something deprecated half a decade ago and unavailable. A subsequent patch to a simple FIXME("NIY\n") would be enough. Please leave IOCDAudioControl in a comment in the code at most.
Reading further, it looks like there's nothing to read audio CDs anymore. Instead, developers are recommended to take advantage of the cddafs, which mounts all audio tracks as "/Volumes/Audio-CD/01 Titel 1.aiff" and to play those files with CoreAudio instead. I've checked that mixed CDs with both data files and audio tracks let 2 CD icons appear on the Finder's desktop, e.g. /Volumes/ABC/ and /Volumes/Audio-CD/
So I wonder whether mcicda on Mac OS should forward calls to waveaudio and play .aiff files instead. I don't know how ntdll and the mountmgr etc. could be changed to accomodate the separation in two volumes, i.e. how to map both /Volumes/ABC and /Volumes/Audio-CD/ to D:\
Regards, Jörg Höhle.
Chip