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@winehq.org ReportedBy: p-wine-bugs@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.
http://bugs.winehq.org/show_bug.cgi?id=16592
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch Version|unspecified |1.1.10
--- Comment #1 from Vitaliy Margolen vitaliy@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.
http://bugs.winehq.org/show_bug.cgi?id=16592
--- Comment #2 from G. Paul Ziemba p-wine-bugs@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.
http://bugs.winehq.org/show_bug.cgi?id=16592
--- Comment #3 from Vitaliy Margolen vitaliy@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.
http://bugs.winehq.org/show_bug.cgi?id=16592
--- Comment #4 from G. Paul Ziemba p-wine-bugs@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
http://bugs.winehq.org/show_bug.cgi?id=16592
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bunglehead@gmail.com
--- Comment #5 from Nikolay Sivov bunglehead@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.
http://bugs.winehq.org/show_bug.cgi?id=16592
--- Comment #6 from G. Paul Ziemba p-wine-bugs@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).
http://bugs.winehq.org/show_bug.cgi?id=16592
--- Comment #7 from Nikolay Sivov bunglehead@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.
http://bugs.winehq.org/show_bug.cgi?id=16592
--- Comment #8 from Austin English austinenglish@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().
http://bugs.winehq.org/show_bug.cgi?id=16592
Paul Vriens Paul.Vriens.Wine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Vriens.Wine@gmail.com
--- Comment #9 from Paul Vriens Paul.Vriens.Wine@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).
http://bugs.winehq.org/show_bug.cgi?id=16592
--- Comment #10 from G. Paul Ziemba p-wine-bugs@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)
http://bugs.winehq.org/show_bug.cgi?id=16592
--- Comment #11 from Paul Vriens Paul.Vriens.Wine@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).
http://bugs.winehq.org/show_bug.cgi?id=16592
--- Comment #12 from Paul Vriens Paul.Vriens.Wine@gmail.com 2009-01-15 08:25:11 --- Oh, and btw your patch sets root to : not to \:
http://bugs.winehq.org/show_bug.cgi?id=16592
--- Comment #13 from Paul Vriens Paul.Vriens.Wine@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.
http://bugs.winehq.org/show_bug.cgi?id=16592
--- Comment #14 from G. Paul Ziemba p-wine-bugs@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@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.
http://bugs.winehq.org/show_bug.cgi?id=16592
--- Comment #15 from Paul Vriens Paul.Vriens.Wine@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.
http://bugs.winehq.org/show_bug.cgi?id=16592
--- Comment #16 from Paul Vriens Paul.Vriens.Wine@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
http://bugs.winehq.org/show_bug.cgi?id=16592
--- Comment #17 from G. Paul Ziemba p-wine-bugs@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)
http://bugs.winehq.org/show_bug.cgi?id=16592
--- Comment #18 from Paul Vriens Paul.Vriens.Wine@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.
http://bugs.winehq.org/show_bug.cgi?id=16592
--- Comment #19 from G. Paul Ziemba p-wine-bugs@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.
http://bugs.winehq.org/show_bug.cgi?id=16592
--- Comment #20 from Paul Vriens Paul.Vriens.Wine@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.
http://bugs.winehq.org/show_bug.cgi?id=16592
--- Comment #21 from Paul Vriens Paul.Vriens.Wine@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.
http://bugs.winehq.org/show_bug.cgi?id=16592
--- Comment #22 from G. Paul Ziemba p-wine-bugs@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.
http://bugs.winehq.org/show_bug.cgi?id=16592
--- Comment #23 from Paul Vriens Paul.Vriens.Wine@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).
http://bugs.winehq.org/show_bug.cgi?id=16592
--- Comment #24 from Austin English austinenglish@gmail.com 2009-07-30 12:14:43 --- Is this still an issue in current (1.1.26 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=16592
--- Comment #25 from Nikolay Sivov bunglehead@gmail.com 2010-01-09 09:24:04 --- Looks like it might be fixed already with f7e6777e6e19ca3be4b84f98baf22ef53ab19f96. Please retest with 1.1.36.
http://bugs.winehq.org/show_bug.cgi?id=16592
Nikolay Sivov bunglehead@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) |
http://bugs.winehq.org/show_bug.cgi?id=16592
HQ cs.tech@comcast.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cs.tech@comcast.net
--- Comment #26 from HQ cs.tech@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
http://bugs.winehq.org/show_bug.cgi?id=16592
Chris Parker cparke@parkerfamily.name changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cparke@parkerfamily.name
http://bugs.winehq.org/show_bug.cgi?id=16592
Chris Parker cparke@parkerfamily.name changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|cparke@parkerfamily.name |
http://bugs.winehq.org/show_bug.cgi?id=16592
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com
--- Comment #27 from Dan Kegel dank@kegel.com 2010-10-20 14:11:01 CDT --- Does http://www.winehq.org/pipermail/wine-cvs/2010-October/071623.html affect this?
http://bugs.winehq.org/show_bug.cgi?id=16592
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|bunglehead@gmail.com |
http://bugs.winehq.org/show_bug.cgi?id=16592
--- Comment #28 from butraxz@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 ?
http://bugs.winehq.org/show_bug.cgi?id=16592
Tom fordoldfart@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fordoldfart@gmail.com
--- Comment #29 from Tom fordoldfart@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
http://bugs.winehq.org/show_bug.cgi?id=16592
--- Comment #30 from Tom fordoldfart@gmail.com --- Thanks for your help trying to get off ox win-XP and this app I need to work.
http://bugs.winehq.org/show_bug.cgi?id=16592
--- Comment #31 from Tom fordoldfart@gmail.com --- Sorry very new to this Wine version 1.7.17
http://bugs.winehq.org/show_bug.cgi?id=16592
--- Comment #32 from Tom fordoldfart@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
https://bugs.winehq.org/show_bug.cgi?id=16592
--- Comment #33 from Austin English austinenglish@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?
https://bugs.winehq.org/show_bug.cgi?id=16592
--- Comment #34 from Tom fordoldfart@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.
https://bugs.winehq.org/show_bug.cgi?id=16592
grouser53@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |grouser53@yahoo.com
--- Comment #35 from grouser53@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.
https://bugs.winehq.org/show_bug.cgi?id=16592
super_man@post.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |super_man@post.com
--- Comment #36 from super_man@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.
https://bugs.winehq.org/show_bug.cgi?id=16592
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #37 from joaopa jeremielapuree@yahoo.fr --- Does the bug still occur with vanilla wine-6.21?
-
wine-bugs＠winehq.org -
WineHQ Bugzilla