CD-ROM access via "\\\\.\\Cdrom0"
proski at gnu.org
Fri Nov 17 16:34:44 CST 2006
On Fri, 2006-11-17 at 10:20 +0100, Hans Leidekker wrote:
> On Friday 17 November 2006 09:01, Pavel Roskin wrote:
> > trace:file:CreateFileW L"\\\\.\\Cdrom0" GENERIC_READ GENERIC_WRITE FILE_SHARE_READ FILE_SHARE_WR
> On NT based systems drive letters are aliases for device names
> in what is called the NT object manager namespace. It looks like
> DVDDecrypter knows that.
At least it knows that there are devices called CdromN. On the other
hand, if the list of the devices can be obtained, it would make sense to
only try the devices from that list instead of going from Cdrom0 to
I don't know why letters are used on WinNT. Most likely, the "Cdrom"
names don't exist on WinNT. And the reason to use them on Win2k would
be to support even the devices without a letter allocated for them.
> I remember looking into this when writing tape support. There you also
> need to manually create a symlink from .wine/dosdevices/tape0 to /dev/st0
> to make it work.
You are totally right. My "proof of concept" patch turns out to be
totally useless. It's sufficient to create a link
from .wine/dosdevices/cdrom0 to the device (e.g. /dev/cdrom).
I'm getting an "Unable to disable media change notification" warning,
but it can be ignored. It should be easy to fix.
> The issue also comes up with newer installers from MS
> that use QueryDosDevice to find a real harddisk among the available
> drives; they do so by looking for a specific substring in the object name.
> Furthermore, the volume APIs also expose parts of the object namespace;
> volume names are in fact symlinks to device names.
OK, this confirms that the object namespace is an important feature.
Search for "object namespace" shows that the issue is known to wine
> So Wine needs to emulate more of the object namespace, possibly by
> extending the current concept of storing dos devices as symlinks
> in the host filesystem. I.e. we could have a directory under .wine
> that represents the root of the object namespace and use subdirectories
> and symlinks to mimic the very filesystem like structure of the
> object namespace.
I actually think that complete Wine configuration should be in the
registry. As soon as parts of Wine configuration can be changed using
UNIX file operation, we have a problem of consistency. File managers
won't check consistency for us. But I realize that this issue is
arguable and that some people users to be in control.
> We could then extend winecfg to detect Unix device files for cdrom,
> floppy, tape etc, and create appropriate symlinks in there.
Indeed, that would be the simplest short-term solution. No changes in
Wine DLLs are actually needed.
> BTW, Sysinternals' WinObj is a handy little tool that visualizes the
> object namespace.
Yes. And it's completely empty under Wine.
By the way, I don't see Cdrom0 on WinXP. Maybe DVDDecrypter is right to
scan through all numbers.
More information about the wine-devel