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