Hi,
the last years have seen individual patches by K. Thomases and C. Davis to Mac OSX' CD handling, but I don't see the big picture.
Mixed CDs occur in some games, but some audio CDs contain "bonus content" as well.
On MacOS, mixed CDs are mounted as two volumes - the audio part, - the data/binary section not unlike Gnome which also displays 2 disc icons on the desktop.
On Linux, Wine manages to map both to a single CD-ROM drive letter like D:, such that - D:\data\foo.exe works as well as - MCICDA: open D: type cdaudio alias D; play D work (but see bug 20555), which mimics native's behaviour.
On MacOS, we're not there yet. I've no idea how that can be made to work. How would Wine on MacOS join the pieces?
Regards, Jörg Höhle
On Feb 11, 2011, at 10:23 AM, Joerg-Cyril.Hoehle@t-systems.com Joerg-Cyril.Hoehle@t-systems.com wrote:
Mixed CDs occur in some games, but some audio CDs contain "bonus content" as well.
On MacOS, mixed CDs are mounted as two volumes
- the audio part,
- the data/binary section
not unlike Gnome which also displays 2 disc icons on the desktop.
On Linux, Wine manages to map both to a single CD-ROM drive letter like D:, such that
- D:\data\foo.exe works as well as
- MCICDA: open D: type cdaudio alias D; play D work (but see bug 20555),
which mimics native's behaviour.
On MacOS, we're not there yet. I've no idea how that can be made to work. How would Wine on MacOS join the pieces?
I guess I'd say that Wine should create a drive letter only for the data/binary section. I suspect that that's already the case due to the logic in mountmgr.sys/diskarb.c.
Then, if some code needs to find the whole-media device that contains that section, it could use something like the get_parent_device() function in dlls/ntdll/cdrom.c. From there, it might have to enumerate the child entries to find the audio part. I don't know how one checks for that. Playing with such a mixed CD and /Developer/Applications/Utilities/IORegistryExplorer.app might be helpful in figuring that out.
Cheers, Ken