http://bugs.winehq.org/show_bug.cgi?id=35903
Bug ID: 35903 Summary: CED1401 Device connected through USB not found Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: alois.schloegl@gmail.com
The CED1401 is a devices which connected with USB to the PC. The software for controlling the device installs and runs well, but it does not identify the USB device.
For this reason, the application "CED1401" in Winehq's AppDB has currently status "Garbage".
http://bugs.winehq.org/show_bug.cgi?id=35903
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |hardware
--- Comment #1 from Ken Sharp imwellcushtymelike@gmail.com --- Read this: http://wiki.winehq.org/Bugs
Logs, Wine version, etc. etc. etc.
http://bugs.winehq.org/show_bug.cgi?id=35903
--- Comment #2 from Alois Schlögl alois.schloegl@gmail.com --- Created attachment 48125 --> http://bugs.winehq.org/attachment.cgi?id=48125 registry
http://bugs.winehq.org/show_bug.cgi?id=35903
--- Comment #3 from Alois Schlögl alois.schloegl@gmail.com --- (In reply to Ken Sharp from comment #1)
Read this: http://wiki.winehq.org/Bugs
Logs, Wine version, etc. etc. etc.
I've also recompiled wine 1.4.1 with USB support [1] with patches from [2] according to the instructions [3]. The instructions in [1] are laborious, but I think, I've managed to complete them all.
Specifically I've moved the driver file found in regedit HKLM\System\CurrentControlSet\Services<driver name> (it's ced_usb.sys for 32bit windows and ced_us64.sys for 64bit windows) in place, and exported the registry information from a running windows system and imported these in wine. (see attachments).
The software starts but does not recognize the device connected on USB (application report in [4]).
I've also compiled recent versions of wine 1.7.14 on (debian7/adm64) without patches, because [2] does not contain patches for more recent versions of wine. The result was the same.
Concerning log files,
Best, Alois
[1] http://wiki.winehq.org/USB [2] ftp://ftp.etersoft.ru/pub/people/amorozov/usb/ [3] http://wiki.winehq.org/Wine64 (Building a shared WoW64 setup) [4] http://appdb.winehq.org/objectManager.php?sClass=version&iId=30056
http://bugs.winehq.org/show_bug.cgi?id=35903
--- Comment #4 from Alois Schlögl alois.schloegl@gmail.com --- I noticed this has not been exported as nt4/reg file. I'll redo the whole procedure
http://bugs.winehq.org/show_bug.cgi?id=35903
Alois Schlögl alois.schloegl@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #48125|0 |1 is obsolete| |
--- Comment #5 from Alois Schlögl alois.schloegl@gmail.com --- Created attachment 48126 --> http://bugs.winehq.org/attachment.cgi?id=48126 nt4/reg file for ced1401 driver
http://bugs.winehq.org/show_bug.cgi?id=35903
--- Comment #6 from Alois Schlögl alois.schloegl@gmail.com --- Created attachment 48127 --> http://bugs.winehq.org/attachment.cgi?id=48127 HKLM\System\CurrentControlSet\Services\CEDUSB registry file for the ced1401
http://bugs.winehq.org/show_bug.cgi?id=35903
--- Comment #7 from Alois Schlögl alois.schloegl@gmail.com --- I've repeated the test in order to make sure nt4/reg files were used. Here are the steps for testing ced1401.
export WINVER=1.7.16
### Install CED1401/try1432 wget http://www.ced.co.uk/files/winsupp.exe WINEPREFIX=$HOME/.$WINVER $HOME/src/wine64/wine winsupp.exe
# import registry keys - the *reg files were extracted from Windows when when device was connected and turned on. WINEPREFIX=$HOME/.$WINVER $HOME/src/wine64/wine $HOME/.$WINVER/drive_c/windows/regedit.exe /S "HKLM.System.CurrentControlSet.Services.CEDUSB.on.nt4.reg" WINEPREFIX=$HOME/.$WINVER $HOME/src/wine64/wine $HOME/.$WINVER/drive_c/windows/regedit.exe /S "HKLM.System.CurrentControlSet.Enum.USB.Vid_0525&PID_A0F0.on.nt4.reg"
# move driver in place (ced_usb.sys, ced_us64.sys, hidusb.sys) cp *.sys $HOME/.$WINVER/drive_c/windows/system32/drivers/
# set permissions - device need to be connected and turned on lsusb |awk -F "[: ]" '/0525:a0f0/ { printf("sudo chmod a+rw /dev/bus/usb/%s/%s\n",$2,$4); }' ## sudo output of previous command
# TEST WINEPREFIX=$HOME/.$WINVER $HOME/src/wine64/wine $HOME/".$WINVER/drive_c/1401/utils/try1432.exe"
The test failed again (click on "All On" and "Run Once") with an error message "device driver to installed or not loaded"
http://bugs.winehq.org/show_bug.cgi?id=35903
--- Comment #8 from Alois Schlögl alois.schloegl@gmail.com --- Created attachment 48132 --> http://bugs.winehq.org/attachment.cgi?id=48132 dump of ced_usb.sys (used by CED1401 in windows 32bit)
http://wiki.winehq.org/USB states "Drivers which depend on modules other than ntoskrnl.exe, hal.dll, usbd.sys will not work."
The ced1401 uses ced_usb.sys on win32 and ced_us64.sys on win64, that might be the cause why it does not work. Probably this bug report should be renamed to "wine is missing ced_usb.sys"
Attached is the dump of winedump -j import ced_usb.sys The winedump for ced_us64.sys will follow
http://bugs.winehq.org/show_bug.cgi?id=35903
--- Comment #9 from Alois Schlögl alois.schloegl@gmail.com --- Created attachment 48133 --> http://bugs.winehq.org/attachment.cgi?id=48133 winedump of ced_us64.sys (used by ced1401 on Win64)
winedump -j import ced_us64.sys
https://bugs.winehq.org/show_bug.cgi?id=35903
Qian Hong fracting@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fracting@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=35903
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |http://www.ced.co.uk/files/ | |winsupp.exe CC| |focht@gmx.net Version|unspecified |1.7.16
--- Comment #10 from Anastasius Focht focht@gmx.net --- Hello Alois,
--- quote --- Probably this bug report should be renamed to "wine is missing ced_usb.sys" --- quote ---
That proprietary driver is provided by the vendor CED Ltd. and is not part of Windows OS (Microsoft). Hence it can't be part of Wine ever.
Building an outdated Wine 1.4.x with USB patches is kind of pointless. The externally referenced USB patchset has a limited scope/usefulness - it's not meant to enable/run any kind of class/hardware driver. Custom patched Wine versions are *not* supported here anyway.
Your "recipes" are basically hacks around some missing driver installation. You could try to force an install through 'wine rundll32 setupapi.dll,InstallHinfSection ...' on the provided .inf file.
The main point you are missing/confusing here is that Wine is *not* an operating system. Wine doesn't have the proper architecture/design on the "kernel" part which is required to support various kinds of hardware drivers (not even talking about layered ones). I could proceed with things like missing PnP device manager, etc.
If you feel confident enough you could try to wrap the userspace part, that is likely a dll interfacing the driver into a winelib. Reverse engineering a vendor library/API can be a very daunting task, given the device is recognized with the Linux kernel. It's likely not worth the time.
You should have really checked for native Linux support from the vendor before purchasing hardware/software. Don't by products from vendors that have a Windows lock-in.
Regards
https://bugs.winehq.org/show_bug.cgi?id=35903
--- Comment #11 from Alois Schlögl alois.schloegl@gmail.com --- Hello Anastasius,
thanks for looking into that issue.
For clarification, ced_usb.sys is part of the CED 1401 installer, and is provided by the installer. Concerning, proprietary softwarem I perfectly agree with that. Actually, the company CED provides the sources code on request under the GPL, I made it available here https://github.com/schloegl/ced1401 and it was also for some time in the linux staging tree.
These CED devices on the market for a long time, and a number of windows applications use them, which are not likely to be ported Linux. This includes Software from CED (Signal, Spike) , as well as IgorPro from WaveMetrics, and some legacy Inhouse software (we call it FPulse). I've tested these software packages on Wine, and they install and run fine one Wine, except that the software can not talk to the hardware.
And yes, I've learned that these driver issues are were special and that there is no straight-forward for solving that issue. If you have any suggested, please let me know.
Best regards, Alois
https://bugs.winehq.org/show_bug.cgi?id=35903
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- URL|http://www.ced.co.uk/files/ |https://web.archive.org/web |winsupp.exe |/20150315053450/http://ced. | |co.uk/files/winsupp.exe Status|UNCONFIRMED |NEW Ever confirmed|0 |1
--- Comment #12 from Anastasius Focht focht@gmx.net --- Hello folks,
adding stable link via Internet Archive.
https://web.archive.org/web/20150315053450/http://ced.co.uk/files/winsupp.ex...
You could try with recent Wine 5.6+ if your device (vid=0525, pid=A0F0) is at least recognized at wineusb level, although it doesn't mean much.
--- snip --- $ WINEDEBUG=+wineusb wineboot --- snip ---
https://devicehunt.com/view/type/usb/vendor/0525
https://devicehunt.com/view/type/usb/vendor/0525/device/A0F0
Apart from that, PnP driver autoinstall and layered drivers support is still not going to happen in near future.
$ sha1sum winsupp.exe 8081a20bbc0c9b99f37b98a823ce07ab25f15e9d winsupp.exe
$ du -sh winsupp.exe 7.3M winsupp.exe
$ wine --version wine-5.7-177-gad1fad8a94
Regards
https://bugs.winehq.org/show_bug.cgi?id=35903
--- Comment #13 from Alois Schlögl alois.schloegl@gmail.com --- Created attachment 67322 --> https://bugs.winehq.org/attachment.cgi?id=67322 error message when running "wine winsupp.exe"
When I try to run the installer one wine-5.9 (debian/bullseye) wine winsupp.exe it still fails.
https://bugs.winehq.org/show_bug.cgi?id=35903
--- Comment #14 from Alois Schlögl alois.schloegl@gmail.com --- (In reply to Anastasius Focht from comment #12)
Hello folks,
adding stable link via Internet Archive.
https://web.archive.org/web/20150315053450/http://ced.co.uk/files/winsupp.ex...
You could try with recent Wine 5.6+ if your device (vid=0525, pid=A0F0) is at least recognized at wineusb level, although it doesn't mean much.
--- snip --- $ WINEDEBUG=+wineusb wineboot --- snip ---
I tried this with wine-5.9 on Debian/bullseye. I can confirm that the device "CED 1401" is recognized. Running
WINEDEBUG=+wineusb wineboot
when turning the device on, the output contains these lines
0078:trace:wineusb:add_usb_device Adding new device 0x7e70d340, vendor 0525, product a0f0. 0078:warn:wineusb:add_usb_device Failed to open device: Access denied (insufficient permissions)
the lines are not shown, when I turn it off or disconnect the device.
When I run WINEDEBUG=+wineusb winefile turning it off and on again it shows this
0098:trace:wineusb:remove_usb_device Removing device 0x7e70d340. 0098:trace:wineusb:fdo_pnp irp 0xb802a8, minor function 0x7. 0098:trace:wineusb:add_usb_device Adding new device 0x7da01b30, vendor 0525, product a0f0. 0098:warn:wineusb:add_usb_device Failed to open device: Access denied (insufficient permissions)
What can I do about the permission issue ? Currently, there is no linux kernel module handling this device, so there is no /dev/### associated with it.
When I try to run the installer, wine winsupp.exe
it still fails (see attachment). I'm using wine-5.9 on debian/bullseye.
https://bugs.winehq.org/show_bug.cgi?id=35903
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #15 from Zebediah Figura z.figura12@gmail.com --- In order to access the device, you'll need to give your user permission to access it at the host OS level. For Linux, the usual way to achieve this is through udev rules. It's relatively easy to find out how to create these rules with an Internet search. In my case I created a simple file with the contents:
SUBSYSTEM=="usb", ATTR{idVendor}=="07cf", MODE="0666"
at /etc/udev/rules.d/90-usb-casio.rules.
https://bugs.winehq.org/show_bug.cgi?id=35903
--- Comment #16 from Alois Schlögl alois.schloegl@gmail.com --- Created attachment 67331 --> https://bugs.winehq.org/attachment.cgi?id=67331 log file when trying to install winsupp.exe on wine 5.9
After setting the permissions like this
$ cat /etc/udev/rules.d/90-usb-ced1401.rules. SUBSYSTEM=="usb", ATTR{idVendor}=="0525", MODE="0666"
and when running this command, the attached log file is produced: $ WINEDEBUG=+wineusb wine winsupp.exe
I tried with WINEARCH=win32 and WINEARCH=win64, I did not see a difference. The installer runs, and the driver files are put in place, but it displays the error as shown in https://bugs.winehq.org/attachment.cgi?id=67322
https://bugs.winehq.org/show_bug.cgi?id=35903
--- Comment #17 from Zebediah Figura z.figura12@gmail.com --- Can you please attach a log with WINEDEBUG=+wineusb,+setupapi,+ntoskrnl,+plugplay,+pid,+msgbox?
https://bugs.winehq.org/show_bug.cgi?id=35903
--- Comment #18 from Alois Schlögl alois.schloegl@gmail.com --- Created attachment 67333 --> https://bugs.winehq.org/attachment.cgi?id=67333 log file with extended debug options when trying to install winsupp.exe on wine 5.9
This is the log file when running with these debug options:
WINEDEBUG=+wineusb,+setupapi,+ntoskrnl,+plugplay,+pid,+msgbox wine winsupp.exe
https://bugs.winehq.org/show_bug.cgi?id=35903
--- Comment #19 from Zebediah Figura z.figura12@gmail.com --- I'm not sure we're running the same installer, because mine (which I downloaded from the link in the URL field) is behaving differently. I don't have the relevant device, but I don't think the installer is checking for it. Instead, it copies an INF file into the C:\windows\inf directory:
04bc:04c0:trace:setupapi:SetupCopyOEMInfA "C:\1401\WinDrv\CED_1401.INF", (null), 1, 8, 00000000, 0, 00000000, 00000000
When the device is plugged in (or the prefix started, which may require shutting down the prefix first), that INF file should be picked up by our Plug and Play manager.
However, I don't see any such calls to SetupCopyOEMInf() in your log, but I do see an attempt to enumerate the USB device, which I don't get. It then seems to be trying to install the same INF file through difxapi, which is a stub.
Does your sha1 match?
hazel@watership:~/Downloads$ sha1sum winsupp.exe 8081a20bbc0c9b99f37b98a823ce07ab25f15e9d winsupp.exe
https://bugs.winehq.org/show_bug.cgi?id=35903
--- Comment #20 from Alois Schlögl alois.schloegl@gmail.com --- Created attachment 67334 --> https://bugs.winehq.org/attachment.cgi?id=67334 log file with extended debug options and winsupp with chksum
You are right. The previous logs were generated with a different version of winsupp.exe, its sha1sum is 2048a4ba9822c8d99f66aad0d041db754d928e16 winsupp.exe
The log attached here was run with 8081a20bbc0c9b99f37b98a823ce07ab25f15e9d winsupp.exe
The error message (as in attachment 67322) does not appear.
I tested the installation with try1432.exe (see also https://appdb.winehq.org/objectManager.php?sClass=version&iId=30056 ), and it still fails.
https://bugs.winehq.org/show_bug.cgi?id=35903
--- Comment #21 from Zebediah Figura z.figura12@gmail.com --- Okay, good, that explains that difference nicely then.
The log from winsupp.exe looks about what I would expect, no obvious problems there. Where the problems probably start showing up is with the program itself (or probably any boot of the wineprefix). Can you please take a log of try1432.exe with the same channels?
https://bugs.winehq.org/show_bug.cgi?id=35903
--- Comment #22 from Alois Schlögl alois.schloegl@gmail.com --- Created attachment 67338 --> https://bugs.winehq.org/attachment.cgi?id=67338 log file when running try1432.exe
https://bugs.winehq.org/show_bug.cgi?id=35903
--- Comment #23 from Zebediah Figura z.figura12@gmail.com --- 006c:0078:trace:setupapi:SetupOpenInfFileW L"C:\windows\inf\CED_1401.INF" -> 001FEE90 006c:0078:trace:setupapi:SetupGetLineByIndexW (001FEE90,L"Manufacturer"): returning 7/0 006c:0078:trace:setupapi:SetupGetStringFieldW context 001FEE90/001FEE90/7/0 index 0 returning L"CED Ltd" 006c:0078:trace:setupapi:SetupGetStringFieldW context 001FEE90/001FEE90/7/0 index 1 returning L"CED_1401" 006c:0078:trace:setupapi:SetupGetStringFieldW context 001FEE90/001FEE90/7/0 index 2 returning L"NTamd64" 006c:0078:trace:setupapi:SetupGetLineByIndexW (001FEE90,L"Manufacturer") not found
---
So the problem is that you're using a 32-bit prefix, but the version specified in the INF file only seems to support a 64-bit installation:
[Manufacturer] %String0%=CED_1401, NTamd64
What's weird is that there are sections in the INF file that *look* like it supports a 32-bit driver, but I'm not sure that anything's actually wired up to them. I wonder if earlier versions of Windows just ignore the architecture field?
Anyway, I'd recommend trying with a 64-bit prefix. When I get the time, I'll test if (older versions of) setupapi will ignore the architecture field...
https://bugs.winehq.org/show_bug.cgi?id=35903
--- Comment #24 from Alois Schlögl alois.schloegl@gmail.com ---
I tried to do the same in WINEARCH=win64, but had difficulties setting up the environment. wineboot failed already, one message indicated a problem with the vulkan driver. It seems my setup on debian/bullseye is not really very stable. I'll have access to the system again sometimes next week; only then I can provide more details. Thanks anyway for looking into this.
https://bugs.winehq.org/show_bug.cgi?id=35903
--- Comment #25 from Zebediah Figura z.figura12@gmail.com --- (In reply to Alois Schlögl from comment #24)
I tried to do the same in WINEARCH=win64, but had difficulties setting up the environment. wineboot failed already, one message indicated a problem with the vulkan driver. It seems my setup on debian/bullseye is not really very stable. I'll have access to the system again sometimes next week; only then I can provide more details. Thanks anyway for looking into this.
What is the exact terminal output? Not all FIXME/ERR messages actually indicate a bug that needs solving (and e.g. missing Vulkan libraries in particular is only a problem if you plan to use applications that require Vulkan, or d3d12).
https://bugs.winehq.org/show_bug.cgi?id=35903
--- Comment #26 from Alois Schlögl alois.schloegl@gmail.com --- Created attachment 67384 --> https://bugs.winehq.org/attachment.cgi?id=67384 log file - failure to setup win64 env with wine-5.9
The attached log file shows the output when running the following commands on wine-5.9.
export WINEPREFIX=$HOME/.wine.fpulse.0004 export WINEARCH=win64
# clean evironment rm -rf $WINEPREFIX wineboot -u
The problems are gone after the latest upgrade which pulled in wine-5.10. I'll continue testing the try1432.exe, and will send a follow-up.
https://bugs.winehq.org/show_bug.cgi?id=35903
--- Comment #27 from Alois Schlögl alois.schloegl@gmail.com --- Created attachment 67385 --> https://bugs.winehq.org/attachment.cgi?id=67385 log file running try1432.exe
The logfile shows the output on terminal from this command: WINEDEBUG=+wineusb wine $WINEPREFIX/drive_c/1401/utils/try1432.exe
with ced1401 device connected.
Select "Self test" and press "run once" shows this message:
Pass 0 - Failure opening 1401 - device driver not installed or not loaded (code -581) at 09:24:41 09/Jun/20
wine-5.10 was used.
https://bugs.winehq.org/show_bug.cgi?id=35903
--- Comment #28 from Zebediah Figura z.figura12@gmail.com --- Can you please attach a log of try1432.exe with the channels from comment 17? It seems likely the CED function driver still isn't getting loaded, and I can't tell why without all of those channels.
https://bugs.winehq.org/show_bug.cgi?id=35903
--- Comment #29 from Alois Schlögl alois.schloegl@gmail.com --- Created attachment 67400 --> https://bugs.winehq.org/attachment.cgi?id=67400 log file running try1432.exe with more verbose debug information
attached is the log when running
WINEDEBUG=+wineusb,+setupapi,+ntoskrnl,+plugplay,+pid,+msgbox wine $WINEPREFIX/drive_c/1401/utils/try1432.exe
on wine-5.10.
The log file is gzip-ed because it was too large (18 MB).
https://bugs.winehq.org/show_bug.cgi?id=35903
--- Comment #30 from Zebediah Figura z.figura12@gmail.com ---
From the log:
006c:0078:trace:setupapi:SetupDefaultQueueCallbackW need media L"C:\windows\inf" L"1464ui.dll" 006c:0078:trace:setupapi:SetupDefaultQueueCallbackW start copy L"C:\windows\inf\1464ui.dll" -> L"C:\windows\system32\1464ui.dll" 006c:0078:trace:setupapi:queue_copy_file copying file L"C:\windows\inf\1464ui.dll" -> L"C:\windows\system32\1464ui.dll" 006c:0078:trace:setupapi:do_file_copyW copy L"C:\windows\inf\1464ui.dll" to L"C:\windows\system32\1464ui.dll" style 0x10000 006c:0078:warn:setupapi:do_file_copyW failed to copy, err 2
So it gets stuck trying to install the driver files (this ends up looping forever). It's using the INF directory as a default source, because no other source was provided, but that's not correct. I'll have to run some tests, but it looks like we need to use the original location of the INF file, which means we need to write PNF files.
https://bugs.winehq.org/show_bug.cgi?id=35903
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |setupapi Summary|CED1401 Device connected |CED1401 USB driver fails to |through USB not found |install (setupapi should | |use the original INF path | |as a default source path | |when copying files)
--- Comment #31 from Zebediah Figura z.figura12@gmail.com --- (In reply to Zebediah Figura from comment #30)
From the log:
006c:0078:trace:setupapi:SetupDefaultQueueCallbackW need media L"C:\windows\inf" L"1464ui.dll" 006c:0078:trace:setupapi:SetupDefaultQueueCallbackW start copy L"C:\windows\inf\1464ui.dll" -> L"C:\windows\system32\1464ui.dll" 006c:0078:trace:setupapi:queue_copy_file copying file L"C:\windows\inf\1464ui.dll" -> L"C:\windows\system32\1464ui.dll" 006c:0078:trace:setupapi:do_file_copyW copy L"C:\windows\inf\1464ui.dll" to L"C:\windows\system32\1464ui.dll" style 0x10000 006c:0078:warn:setupapi:do_file_copyW failed to copy, err 2
So it gets stuck trying to install the driver files (this ends up looping forever). It's using the INF directory as a default source, because no other source was provided, but that's not correct. I'll have to run some tests, but it looks like we need to use the original location of the INF file, which means we need to write PNF files.
I've submitted some patches for this.
I'm going to limit this bug in scope to that specific issue. I don't doubt there are others hiding behind it, but it's Bugzilla policy to file one bug report per issue; we can track new problems in follow-up reports.
https://bugs.winehq.org/show_bug.cgi?id=35903
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED Fixed by SHA1| |f779f36da3d6bc9b3ae2f223063 | |fc02602fe3dc6
--- Comment #32 from Zebediah Figura z.figura12@gmail.com --- Fixed by https://source.winehq.org/git/wine.git/commitdiff/f779f36da3d6bc9b3ae2f223063fc02602fe3dc6.
https://bugs.winehq.org/show_bug.cgi?id=35903
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|CED1401 USB driver fails to |CED1401 USB function driver |install (setupapi should |fails to install (setupapi |use the original INF path |should use the original INF |as a default source path |path as a default source |when copying files) |path when copying files)
https://bugs.winehq.org/show_bug.cgi?id=35903
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #33 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 5.11.
https://bugs.winehq.org/show_bug.cgi?id=35903
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |5.0.x
https://bugs.winehq.org/show_bug.cgi?id=35903
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|5.0.x |---
--- Comment #34 from Michael Stefaniuc mstefani@winehq.org --- Removing the 5.0.x milestone from bug fixes included in 5.0.3.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla