Hardware
Wine includes some limited support for direct hardware access, including running native Windows drivers. This comes with several restrictions, but we still have been able to successfully access some native devices.
Contents
Restrictions
- Wine runs in user space, and therefore cannot access any hardware that the kernel does not expose a user-space interface for. Depending on operating system this can be prohibitive, although Linux exposes interfaces for many common protocols, including PCI, USB, serial and parallel ports.
- Wine cannot drive hardware that is currently being driven by the host operating system. This means, for instance, that we cannot drive keyboard and mouse devices, or GPU or network drivers, without disabling them on the host side, and hence making them unusable for applications not being run through Wine.
- We are unlikely to implement support for common classes of devices which are usually accessed through a higher-level API, including but not limited to: GPU, network, mass storage, keyboard and mouse, audio, camera. If such devices are unsupported or poorly supported, effort should be spent on bringing up support for the host system instead. Efforts to support direct hardware access in Wine are mostly about domain-specific (and often obsolete) hardware, which it would be difficult and not particularly worthwhile to reverse-engineer host drivers for.
- Although part of the problem here is accessing hardware which is usually also being driven by the host system (as in the above restriction), another part is about hooking up access via high-level Win32 APIs. For example, we implement Win32 sockets directly on top of POSIX sockets; implementing the infrastructure required to run NT network drivers, and hooking up Win32 sockets to these, would be a massive undertaking, and due to the design of kernel drivers in Wine it would likely have negative performance impact. In many cases the kernel interface is also undocumented, adding to the difficulty.
- Note however that some devices have special configuration only available through a Win32 driver, and we may be able to support that special configuration while neglecting to implement support for the device’s «normal» usage. For example, the SteelSeries USB mouse driver offers the ability to modify the mouse’s LED settings as well as simply driving the mouse, and in this case Wine is able to pass through the LED settings while still being unable to drive the mouse normally. Note that other restrictions still apply; e.g. settings cannot be changed while the mouse is being used by the host operating system.
- Hardware that is being driven through wine can only be accessed through Windows programs, and cannot be accessed from host programs outside of Wine. E.g. in some cases it is possible to use Wine to run HID drivers, but those HID devices will only appear to Windows programs run through Wine, and not to other programs on the host operating system.
- Some native NT drivers require kernel interfaces that we cannot support. (One notable example of this is the ability to access user space memory via METHOD_NEITHER ioctls that contain pointers.)
- As of the time of this writing (April 2022), support for direct hardware access has received limited testing and limited attention. Only a small number of protocols have been hooked up to any degree. Many interfaces are also missing. It’s worth mentioning also that there are plenty of bugs affecting driver installation. If an appliation doesn’t work, and you believe it should be able to work—considering the above restrictions—please report a bug.
USB
As of Wine 5.7, Wine includes support for USB kernel drivers. This requires a functional libusb 1.0 on the host, including at compile time. As of the time of writing (Wine 7.6), user space access via winusb.dll is not yet implemented.
Depending on operating system and configuration, you may need to ensure that Wine has permission to access the device in question.
On Linux, this means read/write access. This can be done via a udev rules file. Refer to the udev(7) manual page for full documentation. For quick testing, though, the following file, placed as /etc/udev/rules.d/99-usb.rules will grant full read/write access to the specified device to all (world) users:
SUBSYSTEM=="usb", ATTR=="1234", ATTR=="abcd", MODE="0666"
Safer is to set up a separate group and use the GROUP="mygroup" directive, and then restrict the mode to 0664.
You may need to make sure that your rules apply last, after those shipped by the distribution, hence using a high number such as 99 will help.
Replace 1234 and abcd with the actual hexadecimal ID of the device. This can be found using lsusb .
HID
Wine includes support for HID kernel drivers, and user-space access via hid.dll and via direct ioctls.
There should be some documentation here.
Serial and parallel ports
Wine includes support for serial and parallel I/O via user space. Support for kernel drivers is not implemented.
How to mount USB flash drive to WINE?
I download YUMI from pendrivelinux.com, the website tell me I can use WINE to run it ( using WINE from default repo on raring), but when I run it my USB drive wont show up on YUMI, I have tried to unmount the usb drive in ubuntu but still it not available on YUMI.\ UPDATE: error using multisystem after clicking confirm:
I don’t think Wine has access to USB ports. May I ask what are you trying to accomplish? Because if you just want to create a bootable USB drive, you can use the Startup Disk Creator already included in Ubuntu, or you could use UNetbootin, which is similar to YUMI and has a Linux version. If you’re looking to use YUMI to create a bootable USB with multiple OSs, you can visit this page from pendrivelinux: MultiSystem – Create a MultiBoot USB from Linux.
I want to create multiboot USB drive which consist of Windows 7 and Ubuntu, I know YUMI can do that because I’ve use it before under Windows, I thought it will working on WINE because I found «Windows XP/Vista/7 or WINE to create the Bootable USB» on its website. Does Multiboot can create boot loader for Windows 7 ISO like YUMI do?
1 Answer 1
Good news: Wine supports USB flash drives!
Even more good news: it might be super easy!
1. run winecfg
2. go to the «Drives» tab
3. click «Add. »
4. chose your favorite letter
5. find the «Path:» text field and click the «Browse. » button next to that
6. find wherever your operating system has mounted the flash drive. In Ubuntu it’ll be under /media
7. select your flash drive’s mount point (if you’re using YUMI it’ll probably be called «MULTIBOOT».
8. click «OK» and then «OK» again.
9. Run YUMI or whetever Windows program you were using your flash drive with.If that doesn’t work for you, you might have to patch in USB support and then compile WINE yourself, according to this: https://web.archive.org/web/20160117115117/http://wiki.winehq.org:80/USB
If you want to go that route, the website makes it sound simple enough.
1. open a terminal
2. type wine —version
3. go here and click on your version number: ftp://ftp.etersoft.ru/pub/people/amorozov/usb/
4. download the two text files to your wine source folder
5. run patch -p1 < 0001*.txt and then patch -p1 < 0002*.txt
6. build itThat last step is what kills it for me, because I’m a noob and half of every compile attempt finds me in dependency hell. The website also says «Only for versions before 1.1.22. Run tools/make_makefiles » before building it. I don’t knowú what that means, but it might be useful.
Thankfully the first option worked for me.
I feel it’s worth noting that while adding another OS with YUMI under WINE seems to work fine, I’ve always had trouble setting up a fresh flash drive with YUMI under WINE, but maybe it’s just me. Also, on one of my computers (Kubuntu 64-bit 3.8.0-31-generic) sometimes I would navigate around and the WINE file manager thing wouldn’t see any files or hidden folders. If this hapens to you, paste the exact name of what it is you want to select (like «gparted-live-0.14.1-6-i486.iso» or «.hiddenfolder» and hit enter.
