Hello!
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 Cdrom63.
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 developers.
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.