http://bugs.winehq.org/show_bug.cgi?id=23355
Summary: Ring-Protech CD/DVD Protection fails Product: Wine Version: 1.1.21 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 AssignedTo: wine-bugs@winehq.org ReportedBy: hoehle@users.sourceforge.net CC: galberte@neo.rr.com
Past 1.1.20 commit f7e6777e6e19ca3be4b84f98baf22ef53ab19f96 Autor: Guy Albertelli galberte@neo.rr.com 2009-04-29 03:08:22 kernel32: Fix GetVolumeInformation[AW] to require trailing . causes KERNEL32.GetVolumeInformationA() to return an error, which apparently causes the copy protection to proceed to test the next drive. As a result, the protected app will either exit silently or ask for its CD-ROM.
A trace in broken wine-1.1.21, 1.1.31 and 1.2rc4 reads: Call KERNEL32.GetVolumeInformationA(0033f4e8 "D:",00556798,6,0,0,0,0,0) ret=1000118f Ret KERNEL32.GetVolumeInformationA() retval=00000000 ret=1000118f Call KERNEL32.GetDriveTypeA(0033f4e8 "E:") ret=10001176 [next drive]
A trace in working wine-1.0, 1.1.16 and .18 yields: trace:volume:GetVolumeInformationW L"\\.\D:": found fs type 4 Ret KERNEL32.GetVolumeInformationA() retval=00000001 ret=1000c1ff Call user32.CharUpperA(0032f37e "D:\SYSTEM\Iofile.x64") ret=1000c210
The files iofile.x64 and mov_io.x64 have read errors on the CD-ROM and are symptoms of that protection. Note that Gnome mounts both an audio and a data CD on the desktop: 2 icons appear (after seeking around for half a minute because of the voluntary errors -- what a nuisance).
Perhaps the tests in kernel32/tests/volume.c are not discriminating enough? Judging by the traces, the CurrentDir seems to the the app's one on HD, i.e. not a root.
I own 4 titles with the visible ring CD-ROM protection. I verified that the first 3 are affected by this regression. Revert the commit and they work in 1.2rc4. "Ronja Räubertochter" (no AppDB yet, deserves platinum or gold) "Fritz und Fertig" Schach / chess (no AppDB, gold) "Rund um die Welt mit Felix / abenteuerliche Reise" (no AppDB, platinum) "die Pfefferkörner - Cem unter Verdacht" (no AppDB, garbage) I'm angry that AppDB refuses entries about old Wine versions.
http://bugs.winehq.org/show_bug.cgi?id=23355
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
http://bugs.winehq.org/show_bug.cgi?id=23355
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |obfuscation
http://bugs.winehq.org/show_bug.cgi?id=23355
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
--- Comment #1 from Jörg Höhle hoehle@users.sourceforge.net 2010-07-08 09:26:08 --- Patch sent http://www.winehq.org/pipermail/wine-patches/2010-July/090334.html but rejected because the only merit of reverting the offending commit is to make Ring-Protech work, without implementing correct behaviour for Wine.
See discussion in http://www.winehq.org/pipermail/wine-devel/2010-July/084949.html about how to implement a correct GetVolumeInformation. Any volunteers?
http://bugs.winehq.org/show_bug.cgi?id=23355
--- Comment #2 from Jörg Höhle hoehle@users.sourceforge.net 2010-07-26 11:56:50 --- Bug #20887 also involves GetVolumeInformation. What controls whether GetVolumeInformationA("X:") succeeds or not is not GetCurrentDirectory(). It is the queried drive's default directory.
MS-Windows maintains one default directory per drive letter (and per process) in the environment variable "=X:". You can see that by typing set " (including this double quote) in a DOS shell. It is only when the drive to be queried corresponds with the unique GetCurrentDirectory that the latter comes into play.
http://bugs.winehq.org/show_bug.cgi?id=23355
--- Comment #3 from Jörg Höhle hoehle@users.sourceforge.net 2010-08-08 10:53:47 --- This regression also affects Playmobil - Gefangen in der Drachenfestung (no AppDB) a 2005 children game similarly protected, as can by recognized by the optgraph.dll, ZDATA\IOFILE.X64, SOUND.X64 and GOV_IO.X64 files (not mov_io.x64 this time).
http://www.winehq.org/pipermail/wine-patches/2010-August/091732.html contains the testcases that prove the relationship between GetVolumeInformationA and the per-drive default directory. For unknown reasons, it was not committed. I'd appreciate if more users would run the test, because Wintestbot skips the relevant ones, having only one drive.
http://bugs.winehq.org/show_bug.cgi?id=23355
Chris Parker cparke@parkerfamily.name changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #4 from Chris Parker cparke@parkerfamily.name 2010-09-28 12:24:51 CDT --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=23355
Chris Parker cparke@parkerfamily.name changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cparke@parkerfamily.name
--- Comment #5 from Chris Parker cparke@parkerfamily.name 2010-09-28 12:47:06 CDT --- (In reply to comment #1)
Patch sent http://www.winehq.org/pipermail/wine-patches/2010-July/090334.html but rejected because the only merit of reverting the offending commit is to make Ring-Protech work, without implementing correct behaviour for Wine. See discussion in http://www.winehq.org/pipermail/wine-devel/2010-July/084949.html about how to implement a correct GetVolumeInformation. Any volunteers?
The fix to volume.c by Guy Albertelli in 2009 was definitely misguided. I know he did it like the documentation asks, but that isn't how Windows actually operates.
Windows documentation says the trailing backslash is required, but it only enforces that rule for fixed hard drives. Floppy drives, CD-ROM drives, USB flash drives, SUBST aliases (junction mounts), network drive shares don't need the trailing backslash after the letter. In most cases, it is not required, and WINE is certainly broken on a lot of installers as long as that so-called "fix" remains. Many installers must be failing for odd reasons under WINE because of our incompatibility on this function. This is a very important function to get correct, it's not a joke!
In my case, I have an setup installer failing because it can't validate a copy protection routine involving a key floppy diskette using GetVolumeInformation(). WINE fails the request for retrieving the serial number for "A:", but Windows returns it just fine. Consequently, WINE causes the copy protection routine to decide to reject my otherwise valid license serial number. Now I find out someone intentionally put this requirement in! It took me many hours last night with WinDbg to find out this was where the real problem is (after all, I have to crack the copy protection to figure out the problem).
Please key this PATCH into the next release!
http://bugs.winehq.org/show_bug.cgi?id=23355
--- Comment #6 from Chris Parker cparke@parkerfamily.name 2010-09-28 12:51:56 CDT --- (In reply to comment #2)
Bug #20887 also involves GetVolumeInformation. What controls whether GetVolumeInformationA("X:") succeeds or not is not GetCurrentDirectory(). It is the queried drive's default directory. MS-Windows maintains one default directory per drive letter (and per process) in the environment variable "=X:". You can see that by typing set " (including this double quote) in a DOS shell. It is only when the drive to be queried corresponds with the unique GetCurrentDirectory that the latter comes into play.
Not the case for a network drive share, any way. I'm in X:\ and run the Windows routine with just X: and it succeeds. I think all removable drive and media types don't require the trailing backslash. Why do we ever need to require the trailing backslash? (to validate a hard drive is real and fixed?)
http://bugs.winehq.org/show_bug.cgi?id=23355
--- Comment #7 from Chris Parker cparke@parkerfamily.name 2010-09-28 15:28:10 CDT --- Created an attachment (id=31004) --> (http://bugs.winehq.org/attachment.cgi?id=31004) Testapp to show what GetVolumeInformation returns on Windows vs. Wine
Try it on Windows on various types of drives, with and without the trailing backslash, then try it on WINE and see the differences in behavior.
This bug will cause many installers to crash or fail for inexplicable reasons. Most people will just give up if the bug isn't fixed.
http://bugs.winehq.org/show_bug.cgi?id=23355
--- Comment #8 from Jörg Höhle hoehle@users.sourceforge.net 2010-09-29 09:40:58 CDT ---
Windows documentation says the trailing backslash is required, but it only enforces that rule for fixed hard drives.
This is wrong. It depends on the drive's default directory. Tests are now in kernel32/volume.c and are known to pass from win95 to winXY to prove it (part of my comment #3 is obsolete: the tests are included since July this year). See http://www.winehq.org/pipermail/wine-devel/2010-July/thread.html as well as bug #20887, comment #15
Testapp to show what GetVolumeInformation
I don't know what it's doing, but you are welcome to extract kernel32_test.exe out of test.winehq's wintest.exe and start that from any directory other than your boot directory (C:).
cd X: kernel_test.exe volume
Please post results for network drives, floppies, SUBST (I tested CD-ROM, USB and Samba). Do you get different results than what I described?
I agree with you that the best thing to do IMHO is to revert that patch until somebody writes the correct code that looks up the drive's default directory when applicable. Fixing this bug would be especially welcome for Wine-1.2.1. I've listed in earlier comments half a dozen apps that fail to start because of this sole issue and merited platinum in the past.
http://bugs.winehq.org/show_bug.cgi?id=23355
--- Comment #9 from Chris Parker cparke@parkerfamily.name 2010-09-29 12:52:51 CDT --- I'm not sure where to get wintest.exe or kernel32_test.exe, but the app. I attached is a simple C test apply that exercises this specific API function only by passing the command line argument as the "root" argument to the API and printing out the values upon the function's , including the return value and GetLastError() value if the return value is FALSE. If you call with no command line argument, it passed NULL as the root argument (which according to MS documentation is to return the information for the volume of the current directory).
Regarding X:, yes, I see now what you were saying; only if the current directory for the drive is not the root directory does the trailing backslash seem to be needed. Incidentally, this function works in Windows even for UNC paths also, even if the remote share isn't mapped to any drive letter. However, when the current directory is a UNC share path, a trailing backslash is always needed regardless.
http://bugs.winehq.org/show_bug.cgi?id=23355
--- Comment #10 from Chris Parker cparke@parkerfamily.name 2010-09-29 13:02:49 CDT --- (From update of attachment 31004) This is a Win32 command line application. Pass a command-line argument for the root to pass to the API, or use no command line arguments to pass NULL. Output is written to console, together with GetLastError() code if FALSE is returned.
http://bugs.winehq.org/show_bug.cgi?id=23355
--- Comment #11 from Chris Parker cparke@parkerfamily.name 2010-09-29 13:03:20 CDT --- (From update of attachment 31004) This is a Win32 command line application. Pass a command-line argument for the root to pass to the API, or use no command line arguments to pass NULL. Output is written to console, together with GetLastError() code if FALSE is returned.
http://bugs.winehq.org/show_bug.cgi?id=23355
--- Comment #12 from Yuriy M. Kaminskiy bugztime.f.yukam@antichef.net 2010-10-06 23:17:49 CDT --- Created an attachment (id=31160) --> (http://bugs.winehq.org/attachment.cgi?id=31160) accept "X:" when cwd is "X:"
Something like this? Writing tests and pushing upstream left as exercise to reader.
http://bugs.winehq.org/show_bug.cgi?id=23355
--- Comment #13 from Yuriy M. Kaminskiy bugztime.f.yukam@antichef.net 2010-10-06 23:20:47 CDT --- Created an attachment (id=31161) --> (http://bugs.winehq.org/attachment.cgi?id=31161) accept "X:" when cwd is "X:" (alternative)
http://bugs.winehq.org/show_bug.cgi?id=23355
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #14 from Alexandre Julliard julliard@winehq.org 2010-10-20 13:55:24 CDT --- Should be fixed by ee0f0da69b3a99ce6b682b38fc6910a253ca23f8.
http://bugs.winehq.org/show_bug.cgi?id=23355
--- Comment #15 from Jörg Höhle hoehle@users.sourceforge.net 2010-10-22 23:49:13 CDT --- Confirming. That commit atop 1.3.3 is enough to make "Ronja Räubertochter" (one sample protected by Ring Protech/optgraph.dll) start again. Too bad 1.2.1 is out already. Nominating for 1.2.2, should that ever happen.
http://bugs.winehq.org/show_bug.cgi?id=23355
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |1.2.x
--- Comment #16 from Austin English austinenglish@gmail.com 2010-10-23 03:15:35 CDT --- Nominating for 1.2.2.
http://bugs.winehq.org/show_bug.cgi?id=23355
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #17 from Alexandre Julliard julliard@winehq.org 2010-10-29 12:56:13 CDT --- Closing bugs fixed in 1.3.6.
http://bugs.winehq.org/show_bug.cgi?id=23355
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|1.2.x |---
--- Comment #18 from Alexandre Julliard julliard@winehq.org 2010-12-03 12:51:47 CST --- Removing 1.2.x milestone from bugs included in 1.2.2.
http://bugs.winehq.org/show_bug.cgi?id=23355
Saulius K. saulius2@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |saulius2@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=23355
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |ee0f0da69b3a99ce6b682b38fc6 | |910a253ca23f8 CC| |focht@gmx.net Regression SHA1| |f7e6777e6e19ca3be4b84f98baf | |22ef53ab19f96
-
wine-bugs＠winehq.org