Hello!
I've tried to figure out why some programs working with CD and DVD drives work only if the emulated version is set to Windows NT 4, but not Windows 2000 or XP.
I used DVDDecrypter 3.5.4.0 with the current Wine from git. DVDDecrypter is configured to use SPTI, which is the default. Fixing ASPI would be a separate topic.
If NT4 is emulated, the program scans all drives by letters and then opens drive H: (which is the DVD drive on my system). Here's an excerpt from the log produced by
WINEDEBUG=+file,+cdrom,+ntdll,+kernel,+aspi wine DVDDecrypter.exe
trace:file:CreateFileW L"\\.\H:" GENERIC_READ GENERIC_WRITE FILE_SHARE_READ FILE_SHARE_WRITE creation 3 attributes 0x0 trace:file:RtlDosPathNameToNtPathName_U (L"\\.\H:",0x7d6b75b0,(nil),(nil)) trace:file:RtlGetFullPathName_U (L"\\.\H:" 520 0x7d6b7314 (nil)) trace:ntdll:NtCreateFile handle=0x7d6b75b8 access=c0000000 name=L"\??\H:" objattr=00000040 roo t=(nil) sec=(nil) io=0x7d6b75a8 alloc_size=(nil) attr=00000000 sharing=00000003 disp=1 options=00000050 ea=(nil).0x00000000 trace:file:get_dos_device L"H:" -> "/dev/scd0" trace:file:CreateFileW returning 0x8c
And that's what the same command would produce with win2k emulation:
trace:file:CreateFileW L"\\.\Cdrom0" GENERIC_READ GENERIC_WRITE FILE_SHARE_READ FILE_SHARE_WR ITE creation 3 attributes 0x0 trace:file:RtlDosPathNameToNtPathName_U (L"\\.\Cdrom0",0x7d6b25b0,(nil),(nil)) trace:file:RtlGetFullPathName_U (L"\\.\Cdrom0" 520 0x7d6b2314 (nil)) trace:ntdll:NtCreateFile handle=0x7d6b25b8 access=c0000000 name=L"\??\Cdrom0" objattr=00000040 root=(nil) sec=(nil) io=0x7d6b25a8 alloc_size=(nil) attr=00000000 sharing=00000003 disp=1 options=00000050 ea=(nil).0x00000000 warn:file:CreateFileW Unable to create file L"\\.\Cdrom0" (status c0000034) trace:file:CreateFileW returning 0xffffffff trace:file:CreateFileW L"\\.\Cdrom1" GENERIC_READ GENERIC_WRITE FILE_SHARE_READ FILE_SHARE_WR ITE creation 3 attributes 0x0 trace:file:RtlDosPathNameToNtPathName_U (L"\\.\Cdrom1",0x7d6b25b0,(nil),(nil))
The program cycles like this to Cdrom63 and then gives up.
I think it would be great if Wine adds supported for opening CD-ROMs by number. Better yet if it enumerated CD-ROMs an other drives automatically.
I have make a proof-of-concept patch that allows DVDDecrypter to find the CD-ROM drive under win2k emulation. I had to create a link from .wine/dosdevices/cdrom0 to /dev/scd0 manually. This is not the right fix, but it shows that it can be done.
diff --git a/dlls/ntdll/path.c b/dlls/ntdll/path.c index e4af89a..2ca5883 100644 --- a/dlls/ntdll/path.c +++ b/dlls/ntdll/path.c @@ -316,6 +316,7 @@ DOS_PATHNAME_TYPE WINAPI RtlDetermineDos ULONG WINAPI RtlIsDosDeviceName_U( PCWSTR dos_name ) { static const WCHAR consoleW[] = {'\','\','.','\','C','O','N',0}; + static const WCHAR cdromW[] = {'\','\','.','\','C','D','R','O','M',0}; static const WCHAR auxW[3] = {'A','U','X'}; static const WCHAR comW[3] = {'C','O','M'}; static const WCHAR conW[3] = {'C','O','N'}; @@ -372,6 +373,12 @@ ULONG WINAPI RtlIsDosDeviceName_U( PCWST if (strncmpiW( start, comW, 3 ) && strncmpiW( start, lptW, 3 )) break; if (*end <= '0' || *end > '9') break; return MAKELONG( 4 * sizeof(WCHAR), (start - dos_name) * sizeof(WCHAR) ); + case 11: + if (*(end - 1) <= '0' || *(end - 1) > '9') break; + case 10: + if (*end <= '0' || *end > '9') break; + if (strncmpiW( start, cdromW, 9 )) break; + return MAKELONG( (end - start + 1) * sizeof(WCHAR), (start - dos_name) * sizeof(WCHAR) ); default: /* can't match anything */ break; }
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.
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. 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.
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.
We could then extend winecfg to detect Unix device files for cdrom, floppy, tape etc, and create appropriate symlinks in there.
BTW, Sysinternals' WinObj is a handy little tool that visualizes the object namespace.
-Hans
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.
On Friday 17 November 2006 23:34, Pavel Roskin wrote:
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
Yes, the registry is the main alternative, although even then you will be pointing to a changing filesystem. And there may be a chicken-and-egg on boot where you need to access a drive before the registry is accessible, I'm not sure.
-Hans
-
Hans Leidekker -
Pavel Roskin