[Bug 16592] New: Ford service manual viewer fails to detect CD (fix attached)
http://bugs.winehq.org/show_bug.cgi?id=16592 Summary: Ford service manual viewer fails to detect CD (fix attached) Product: Wine Version: unspecified Platform: PC OS/Version: FreeBSD Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: p-wine-bugs(a)ziemba.us Created an attachment (id=18120) --> (http://bugs.winehq.org/attachment.cgi?id=18120) patch to handle null-rootpath equivalent in GetVolumeInformationW wine-1.1.10 I installed the Ford 1993-1994 truck service manual viewer from CD. The viewer application requires that the CD be present in a drive before it will show service data. The viewer application c:/FORD/PUBS/programs/VIEW16.EXE complains that there is no CD present, even though there is. (yes, links for d: and d:: were made correctly in .wine/dosdevices). It turns out that the application calls GetVolumeInformationW with a "root" argument of "\\:". In this case, GetCurrentDirectoryW returns the desired root path, but since root is not null, the code in GetVolumeInformationW uses "\\" as the drive letter instead (and fails). Patching GetVolumeInformationW to treat root == "\\:" the same as the null case results in the application successfully detecting the CD and operating properly. Documentation of GetVolumeInformationW on MSDN seems to indicate that there is a broader range of possible formats for the root parameter than the wine implementation currently handles, so perhaps a more extensive fix is needed for the general case. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16592 Vitaliy Margolen <vitaliy(a)kievinfo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch Version|unspecified |1.1.10 --- Comment #1 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2008-12-22 08:43:11 --- If you can add a test (to Wine's test suite) this will be great. And send it with this patch to wine-patches ML. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16592 --- Comment #2 from G. Paul Ziemba <p-wine-bugs(a)ziemba.us> 2008-12-24 12:52:19 --- I will try to write a test for this fix, but I need to think carefully about it because it depends on the contents of the dosdevices directory. It might be possible to test it with just the default .wine/dosdevices/c: link, but I am not certain (is that link even present when the tests are run?) Maybe the test can construct a private version of the dosdevices directory and use that. I am new to wine development, so any pointers to "the right way to do it" are welcome. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16592 --- Comment #3 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2008-12-24 21:56:09 --- What does GetVolumeInformationW() return now with when passed "\\:" as root? An error or something valid? if an error, then that's all you need to test - if call with root == "\\:" succeeds. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16592 --- Comment #4 from G. Paul Ziemba <p-wine-bugs(a)ziemba.us> 2009-01-06 12:05:06 --- Created an attachment (id=18528) --> (http://bugs.winehq.org/attachment.cgi?id=18528) patch to dlls/kernel32/tests/volume.c to cover this case -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16592 Nikolay Sivov <bunglehead(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bunglehead(a)gmail.com --- Comment #5 from Nikolay Sivov <bunglehead(a)gmail.com> 2009-01-12 17:06:45 --- (In reply to comment #4)
Created an attachment (id=18528) --> (http://bugs.winehq.org/attachment.cgi?id=18528) [details] patch to dlls/kernel32/tests/volume.c to cover this case
This fails on WinXP. P.S. No c++ features accepted here. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16592 --- Comment #6 from G. Paul Ziemba <p-wine-bugs(a)ziemba.us> 2009-01-14 10:56:17 --- (In reply to comment #5)
This fails on WinXP.
P.S. No c++ features accepted here.
Hmm. I suspect this case (root = "\\:") is undocumented and/or old, but I can't prove it. The application came out in the mid-to-late 90's so it's probably intended for Win 95 or 98, although I know it also works on Win2K. What if I made the test run only on Win 95/98/2K? (I assume there is a way to code for that - will check wine docs). I'll also fix the C++ comments (actually fixed in my post of 6 Jan to wine-patches, but I neglected to also update in the bug database). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16592 --- Comment #7 from Nikolay Sivov <bunglehead(a)gmail.com> 2009-01-14 11:06:44 --- (In reply to comment #6)
(In reply to comment #5)
This fails on WinXP.
P.S. No c++ features accepted here.
Hmm. I suspect this case (root = "\\:") is undocumented and/or old, but I can't prove it. The application came out in the mid-to-late 90's so it's probably intended for Win 95 or 98, although I know it also works on Win2K.
Maybe it's so but I don't know how could you push a proposed patch for that in future since no version checking accepted in wine modules as far as I know.
What if I made the test run only on Win 95/98/2K? (I assume there is a way to code for that - will check wine docs). I'll also fix the C++ comments (actually fixed in my post of 6 Jan to wine-patches, but I neglected to also update in the bug database).
You could add it of course possibly marking it broken for WinXP (if I tested properly of course and it really fails on it). In any case post a patch for tests for documentation purpose at least. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16592 --- Comment #8 from Austin English <austinenglish(a)gmail.com> 2009-01-14 12:01:33 --- (In reply to comment #6)
(In reply to comment #5)
This fails on WinXP.
P.S. No c++ features accepted here.
Hmm. I suspect this case (root = "\\:") is undocumented and/or old, but I can't prove it. The application came out in the mid-to-late 90's so it's probably intended for Win 95 or 98, although I know it also works on Win2K.
What if I made the test run only on Win 95/98/2K? (I assume there is a way to code for that - will check wine docs). I'll also fix the C++ comments (actually fixed in my post of 6 Jan to wine-patches, but I neglected to also update in the bug database).
No, tests must pass on all windows versions. If the test works on 2k & below, but not XP+, test for the 2k- behavior, then mark XP+ behavior with the broken() or win_skip() macro as appropriate. For wine, if not fixed there, use todo_wine(). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16592 Paul Vriens <Paul.Vriens.Wine(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Vriens.Wine(a)gmail.com --- Comment #9 from Paul Vriens <Paul.Vriens.Wine(a)gmail.com> 2009-01-14 12:44:07 --- While we are it. GetVolumeInformationW will not be present on a win9x box. You have to use GetVolumeInformationA instead. (Wine forwards A to W). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16592 --- Comment #10 from G. Paul Ziemba <p-wine-bugs(a)ziemba.us> 2009-01-14 21:20:38 --- (In reply to comment #9)
While we are it. GetVolumeInformationW will not be present on a win9x box. You have to use GetVolumeInformationA instead. (Wine forwards A to W).
Interesting. That means that the Ford viewer application must be coded to call GetVolumeInformationA since it is so old. I wonder if this peculiarity (support for root == "\\:") should be only in A. Has anyone run the new GetVolumeInformationW test as it stands today on W2K? (I am not set up to do it myself, unfortunately) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16592 --- Comment #11 from Paul Vriens <Paul.Vriens.Wine(a)gmail.com> 2009-01-15 08:23:25 --- GetVolumeInformationW is available on Win95/Win98 but calling it will set the last error to ERROR_CALL_NOT_IMPLEMENTED. I ran your testcase on 95/98/NT4/W2K3 and in all cases it failed (tried both A and W-calls where possible). Maybe it's better to attach some logging to the bug: WINEDEBUG=+volume wine <your exe> > log 2>&1 (Remember to attach and not paste). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16592 --- Comment #12 from Paul Vriens <Paul.Vriens.Wine(a)gmail.com> 2009-01-15 08:25:11 --- Oh, and btw your patch sets root to \: not to \\: -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16592 --- Comment #13 from Paul Vriens <Paul.Vriens.Wine(a)gmail.com> 2009-01-15 09:51:58 --- Forget my last remark. I did some more tests on 95, W2K3 and Wine. We definitely needs some logs to be able to see the issue. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16592 --- Comment #14 from G. Paul Ziemba <p-wine-bugs(a)ziemba.us> 2009-01-17 01:08:17 --- Created an attachment (id=18747) --> (http://bugs.winehq.org/attachment.cgi?id=18747) debug log Here is the output with WINEDEBUG set to "volume,file" from wine-1.1.10 without my change to GetVolumeInformationW(). (I don't think anything related to this issue has changed between 1.1.10 and 1.1.12, but can rebuild 1.1.12 and rerun if necessary). ~/.wine/dosdevices is set up like this: 42:paul(a)hairball% lls ~/.wine/dosdevices/ total 4 2 drwxr-xr-x 2 paul sw 512 Dec 24 22:49 ./ 2 drwxr-xr-x 4 paul sw 512 Jan 16 22:42 ../ 0 lrwxr-xr-x 1 paul sw 10 Dec 16 08:23 c:@ -> ../drive_c 0 lrwxr-xr-x 1 paul sw 10 Dec 16 09:34 com1@ -> /dev/cuad0 0 lrwxr-xr-x 1 paul sw 10 Dec 16 08:36 com3@ -> /dev/cuau0 0 lrwxr-xr-x 1 paul sw 13 Dec 21 21:44 d:@ -> /mnt/93-truck 0 lrwxr-xr-x 1 paul sw 8 Dec 21 21:57 d::@ -> /dev/md1 0 lrwxr-xr-x 1 paul sw 6 Dec 24 22:48 e:@ -> /cdrom 0 lrwxr-xr-x 1 paul sw 8 Dec 24 22:48 e::@ -> /dev/cd0 0 lrwxr-xr-x 1 paul sw 1 Dec 16 08:23 z:@ -> / The "D" drive is a (virtual) CDROM drive (results are the same with a real CDROM drive). What's going on is that the application is looking for its CD in any "REMOVABLE" drive. If you grep for GetVolumeInformationW in the debug trace, you will see the failed attempt to look up information about D:. When I was debugging this problem initially, I added some printfs to GetVolumeInformationW and found that the else clause of the first test in that function was copying the backslash from root[0] to device[4]. I had not turned on "file" tracing in my earlier debugging, but I now notice that before the call to GetVolumeInformationW there seems to be some attempt to create a file L"\\\\.\\\\:". I don't understand the significance of this attempt - I expect it would fail on Windows because the CDROM is readonly, but maybe there is some strange magic going on. I don't have experience with the Windows API so maybe it's some idiom familar to Win programmers. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16592 --- Comment #15 from Paul Vriens <Paul.Vriens.Wine(a)gmail.com> 2009-01-17 07:32:45 --- The tracing for GetVolumeInformationW() doesn't show the passed parameters. I'm interested in what 'root' looks like. The only difference I've found so far between Windows and Wine is that Wine doesn't cope correctly with '.' and '\.' (single backslash). Those 2 are valid on Windows but fail on Wine. I will attach a simple patch to add an extra trace. Please apply and attach the new logs. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16592 --- Comment #16 from Paul Vriens <Paul.Vriens.Wine(a)gmail.com> 2009-01-17 07:33:50 --- Created an attachment (id=18759) --> (http://bugs.winehq.org/attachment.cgi?id=18759) Patch to add a trace to GetVolumeInformationW -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16592 --- Comment #17 from G. Paul Ziemba <p-wine-bugs(a)ziemba.us> 2009-01-17 09:30:40 --- Created an attachment (id=18763) --> (http://bugs.winehq.org/attachment.cgi?id=18763) debug trace output Here's a snippet of the trace output with the additional information (root arg to GetVolumeInformationW) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16592 --- Comment #18 from Paul Vriens <Paul.Vriens.Wine(a)gmail.com> 2009-01-17 10:01:48 --- Passing "\\:" to GetVolumeInformationA behaves the same on Windows (tested on W95 and W2K3) and Wine. So using your patch solves your problem but it's not correct. Maybe the app creates some strings and one of them turns out to be "\\:" (from an error/bug before)? One strange piece I see in your first log file is: trace:file:RtlDosPathNameToNtPathName_U (L"[:\\",0xbf9fdbf4,0x0,0x0) trace:file:RtlGetFullPathName_U (L"[:\\" 520 0xbf9fd994 0x0) That square bracket doesn't make sense (me thinks). For now the only thing I can think off is doing a full '+all' or maybe a '+relay,+file,+volume' or worst case '+all,+relay' trace. If you decide to do this please zip the resulting logfiles before attaching as they will become big/huge. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16592 --- Comment #19 from G. Paul Ziemba <p-wine-bugs(a)ziemba.us> 2009-01-17 12:29:49 --- Created an attachment (id=18765) --> (http://bugs.winehq.org/attachment.cgi?id=18765) debug trace with WINEDEBUG='+relay,+file,+volume' App died prematurely with WINEDEBUG='+all", so I tried it with WINEDEBUG='+relay,+file,+volume'. Here's the result. That lookup on '[:' certainly does look odd. If I understand the trace correctly, it occurs when the app is enumerating the drives. On the other hand, I'm not sure I see a connection between that and the weird GetVolumeInformation call. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16592 --- Comment #20 from Paul Vriens <Paul.Vriens.Wine(a)gmail.com> 2009-01-17 14:42:27 --- If you look through the sequences of GetDriveTypeA's you will see that it always looks for A:,B:,C:,D:,E: and another letter. This other letter goes from 'F' to 'Z' and guess what comes after ascii 'Z', yep '['. We return '1', maybe we shouldn't? Not sure if this is an issue but I will write a test for this (tomorrow though). And guess what comes after '[', yes '\' indeed, which gives us '\:'. Don't know if this is a longshot but it sure looks suspicious. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16592 --- Comment #21 from Paul Vriens <Paul.Vriens.Wine(a)gmail.com> 2009-01-18 03:30:50 --- Returning '1' for GetDriveTypeA("[:") is fine so no issue here. I guess the viewer starts up a dialog with a text like: Please insert volume %s\n into %s.\n\nPress OK to continue, Cancel to abort. or Please insert volume 1993-1994 Truck CD-ROM - Revision 11.0\n into any CD-ROM Drive.\n\nPress OK to continue, Cancel to abort. Correct? What is the exact text? Could you search the registry (and .ini files) for any reference to "\:" ? Some applications write the install CD location to some place to use it later for verifying that same location. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16592 --- Comment #22 from G. Paul Ziemba <p-wine-bugs(a)ziemba.us> 2009-01-23 11:22:56 --- I looked in the registry and the installed files but did not find any references to a drive "\". I looked over that big debug trace again and I agree that the application looking up drive "\" is probably an artifact of some problem that occurs earlier, especially since it also tries to look up drive "[". My current hypothesis is that the application has somewhat buggy code such as the following, and after a loop over drive letters it calls GetVolumeInfo on whatever value the loop exited with, e.g. (I hope my indentation doesn't get mangled): int drivenum = 3; /* start at "C:" */ for (i = 0; i < 26; ++i) { ++drivenum; type = GetDriveType(drivenum); /* we see these calls in trace */ if ((type = THE_RIGHT_VALUE) && (other stuff??)) { break; } } root[0] = 'A' -1 + drivenum; GetVolumeInfo(root, ...); /* we see this in trace, too */ If this is the case, it would explain why the application tries to look up the drive type on "[" and "\", and would imply that within the loop it is not obtaining exactly the right values it expects to find for a CDROM on drive D. I think the application uses the 16-bit API but I'm not sure how to get a better look at args/return values across that boundary. I wonder if WINE is not returning what it should for this older API. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16592 --- Comment #23 from Paul Vriens <Paul.Vriens.Wine(a)gmail.com> 2009-01-26 03:32:57 --- One other thing I found (but that's actually the opposite of what we are trying to show/fix) is that Wine gives DRIVE_NO_ROOT_DIR with GetDriveType if we have an unmounted CD whereas Windows returns DRIVE_CDROM regardless whether there is a CD mounted or not. I'm trying to come up with a test for our test suite that shows the above behavior (and maybe even a fix). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16592 --- Comment #24 from Austin English <austinenglish(a)gmail.com> 2009-07-30 12:14:43 --- Is this still an issue in current (1.1.26 or newer) wine? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16592 --- Comment #25 from Nikolay Sivov <bunglehead(a)gmail.com> 2010-01-09 09:24:04 --- Looks like it might be fixed already with f7e6777e6e19ca3be4b84f98baf22ef53ab19f96. Please retest with 1.1.36. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16592 Nikolay Sivov <bunglehead(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Ford service manual viewer |Ford service manual viewer |fails to detect CD (fix |fails to detect CD |attached) | -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16592 HQ <cs.tech(a)comcast.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cs.tech(a)comcast.net --- Comment #26 from HQ <cs.tech(a)comcast.net> 2010-05-15 03:44:21 ---
Looks like it might be fixed already with f7e6777e6e19ca3be4b84f98baf22ef53ab19f96. Please retest with 1.1.36.
Still broken in 1.1.44. Also, this bug affects many of the Ford service apps--not just the version and model-year described here.
Hmm. I suspect this case (root = "\\:") is undocumented and/or old, but I can't prove it. The application came out in the mid-to-late 90's so it's probably intended for Win 95 or 98, although I know it also works on Win2K.
I think the application uses the 16-bit API
The viewer is a 16-bit application which (in 32-bit Windows) runs on the 16-bit virtual machine (NTVDM.EXE).
I guess the viewer starts up a dialog with a text like: Please insert volume 1993-1994 Truck CD-ROM - Revision 11.0\n into any CD-ROM Drive.\n\nPress OK to continue, Cancel to abort. Correct? What is the exact text?
Correct. But the message only appears after you choose a chapter from the index (which is copied to the HD by the installer). The viewer application (VIEW16.EXE) does not check for the CD immediately at launch.
Could you search the registry (and .ini files) for any reference to "\:" ?
My Windows box does not have this string in the registry and I see no evidence that the Ford application directly depends on registry access. The viewer can be configured by editing the INFO1.INI file in C:\FORD\PUBS\PROGRAMS. The default behavior is to search for the service library files on any removable drive, as indicated by this section of the INI file: [dealer_env] reader=4 *=REMOVEABLE,*,any CD-ROM Drive Though not normally necessary, it is possible to specify a unique DOS device by replacing the leading asterisk with the device letter. For example: D=REMOVEABLE,*,any CD-ROM Drive I think the syntax here is application-specific, not a global standard (and again, it works in Windows but not in Wine). It's also possible to browse the CD through the Wine alias "d/" and the Wine file manager (which confirms that the CD is mounted properly and recognized by the host operating system).
I had not turned on "file" tracing in my earlier debugging, but I now notice that before the call to GetVolumeInformationW there seems to be some attempt to create a file L"\\\\.\\\\:". I don't understand the significance of this attempt - I expect it would fail on Windows because the CDROM is readonly, but maybe there is some strange magic going on. I don't have experience with the Windows API so maybe it's some idiom familar to Win programmers.
CreateFile and GetVolumeInformation are Win32 functions, so I guess they are translated from the original 16-bit equivalent by Wine's own VDM. Maybe this CD-ROM access bug is a function call translation error in the Wine VDM. I dont know anything about Wine's 16-bit virtual machine. For the sake of compatibility testing, can I copy the Microsoft virtual machine from my Windows installation disc and make Wine use that instead? For reference: "CreateFile Function creates or opens a file or I/O device. The most commonly used I/O devices are as follows: file, file stream, directory, physical disk, volume, console buffer, tape drive, communications resource, mailslot, and pipe. The function returns a handle that can be used to access the file or device for various types of I/O depending on the file or device and the flags and attributes specified. To perform this operation as a transacted operation, which results in a handle that can be used for transacted I/O, use the CreateFileTransacted function." http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx Some other posts which may be related (or inspirational): __________ For review... CD interfaces in wine not ready yet for cvs inclusion (yet), this patch implements two things: - it replaces the wine internal & proprietary cdrom interface (used in MCICDA and MSCDEX/int2F) with the proper win32 ioctl:s calls - it allows opening any device with CreateFile (using the name "\\.\E:") (this is still very hackish, but not worse than what already existed) http://www.winehq.org/pipermail/wine-devel/2001-December/003037.html ___________ [PATCH] ntdll: Implement CDROM_GetDeviceNumber() on Mac OS. http://marc.info/?l=wine-patches&m=125616565804390&w=2 ___________ kernel32: Fix GetVolumeInformation[AW] to require trailing \. http://www.winehq.org/pipermail/wine-cvs/2009-April/055027.html -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16592 Chris Parker <cparke(a)parkerfamily.name> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cparke(a)parkerfamily.name -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16592 Chris Parker <cparke(a)parkerfamily.name> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|cparke(a)parkerfamily.name | -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16592 Dan Kegel <dank(a)kegel.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dank(a)kegel.com --- Comment #27 from Dan Kegel <dank(a)kegel.com> 2010-10-20 14:11:01 CDT --- Does http://www.winehq.org/pipermail/wine-cvs/2010-October/071623.html affect this? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16592 Nikolay Sivov <bunglehead(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|bunglehead(a)gmail.com | -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16592 --- Comment #28 from butraxz(a)gmail.com 2013-04-23 15:17:03 CDT --- No update for 900 days. Is this still an issue in 1.5.28 or higher or should this be closed as abandoned ? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16592 Tom <fordoldfart(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fordoldfart(a)gmail.com --- Comment #29 from Tom <fordoldfart(a)gmail.com> --- Created attachment 48386 --> http://bugs.winehq.org/attachment.cgi?id=48386 This is winedebug log of the install.exe for Ford service publications The install runs and says it has completed. It creats folder c:Ford and sub folder pubs. It does not move any files or data into the folders. Of course Because of this behavior -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16592 --- Comment #30 from Tom <fordoldfart(a)gmail.com> --- Thanks for your help trying to get off ox win-XP and this app I need to work. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16592 --- Comment #31 from Tom <fordoldfart(a)gmail.com> --- Sorry very new to this Wine version 1.7.17 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16592 --- Comment #32 from Tom <fordoldfart(a)gmail.com> --- Ok Appears there are a couple of versions of this software. The 1992 version I cannot get to even load the files. That is what the bzip file is about. The later version will load and execute but does not find the cdrom. Below is what I get from executing from command line. wine c:/FORD/PUBS/programs/view16.exe err:ntdll:RtlpWaitForCriticalSection section 0x7ea73780 "syslevel.c: Win16Mutex" wait timed out in thread 0023, blocked by 0024, retrying (60 sec) fixme:winhelp:WINHELP_HandleCommand Unhandled command (101) for remote winhelp control -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=16592 --- Comment #33 from Austin English <austinenglish(a)gmail.com> --- This is your friendly reminder that there has been no bug activity for over a year. Is this still an issue in current (1.7.51 or newer) wine? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=16592 --- Comment #34 from Tom <fordoldfart(a)gmail.com> --- I still would like to see this fixed. It would save me a lot of steps and paper. If a fix has been applied what version of wine do I need to be at. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=16592 grouser53(a)yahoo.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |grouser53(a)yahoo.com --- Comment #35 from grouser53(a)yahoo.com --- This appears to still be a problem in wine v1.6.2. I have Ford Information Viewer 2.7 and have crafted a workaround by changing the line in the .wine/drive_c/FORD/PUBS/programs/info1.ini (after running INSTALL.EXE from the CD with wine) from *=REMOVEABLE,*,any CD-ROM Drive to D=FIXED,*,any CD-ROM Drive (use the appropriate drive letter from dosdevices that points to your CD/DVD drive) This allows the program to read my DVD drive. Here's my dosdevices directory: drwxrwxr-x 2 mike mike 4096 Mar 12 10:04 . drwxrwxr-x 4 mike mike 4096 Mar 12 10:04 .. lrwxrwxrwx 1 mike mike 10 Mar 11 17:31 c: -> ../drive_c lrwxrwxrwx 1 mike mike 19 Mar 12 10:04 d: -> /media/mike/00TRK19 lrwxrwxrwx 1 mike mike 8 Mar 11 17:32 d:: -> /dev/sr0 lrwxrwxrwx 1 mike mike 1 Mar 11 17:31 z: -> / This is not a fix, but will allow one to read the service information for one's vehicle. I am running this on Ubuntu 14.04.4 LTS with kernel 3.13 on x86_64. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=16592 super_man(a)post.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |super_man(a)post.com --- Comment #36 from super_man(a)post.com --- (In reply to grouser53 from comment #35)
This appears to still be a problem in wine v1.6.2. I have Ford Information Viewer 2.7 and have crafted a workaround by changing the line in the .wine/drive_c/FORD/PUBS/programs/info1.ini (after running INSTALL.EXE from the CD with wine) from *=REMOVEABLE,*,any CD-ROM Drive to D=FIXED,*,any CD-ROM Drive (use the appropriate drive letter from dosdevices that points to your CD/DVD drive)
This allows the program to read my DVD drive. Here's my dosdevices directory:
drwxrwxr-x 2 mike mike 4096 Mar 12 10:04 . drwxrwxr-x 4 mike mike 4096 Mar 12 10:04 .. lrwxrwxrwx 1 mike mike 10 Mar 11 17:31 c: -> ../drive_c lrwxrwxrwx 1 mike mike 19 Mar 12 10:04 d: -> /media/mike/00TRK19 lrwxrwxrwx 1 mike mike 8 Mar 11 17:32 d:: -> /dev/sr0 lrwxrwxrwx 1 mike mike 1 Mar 11 17:31 z: -> /
This is not a fix, but will allow one to read the service information for one's vehicle. I am running this on Ubuntu 14.04.4 LTS with kernel 3.13 on x86_64.
The problem is that you are using wine version that hasnt received updates around 2 years. You need to upgrade wine 1.8 or 1.9 series and stop using so oudated software. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=16592 joaopa <jeremielapuree(a)yahoo.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree(a)yahoo.fr --- Comment #37 from joaopa <jeremielapuree(a)yahoo.fr> --- Does the bug still occur with vanilla wine-6.21? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla