I love Wine, but I have some rather obscure apps that I'd like to run that just refuse to run in any version of it (mainline, Crossover, Winebottler, manually extracted copies of Cider from macOS-ported games...) As-is, I have to run these in a Windows VM to get them to work at all.
It's a lot of hassle, especially because the least-working Windows programs are also some of the tiniest little utilities where they display maybe one GUI screen, but also take command-line parameters. So I usually have to copy files for them to interact with into the VM, open cmd.exe to run the utility on the files, interact with the utility GUI, then copy the files back out. Wine would make this workflow a lot better!
What I'm wondering is: if I don't care about being a Wine "purist", and I have a legitimate copy of Windows laying around, is there any way to dissect that copy of Windows for its files (drivers, helper executables, etc.) and wrap them around a Windows EXE, such that Wine will be using as few Wine implementations of DLLs as possible, rather than just the minimum required to get the individual EXE vaguely working? Is there a way to start off a Wine install with "maximum compatibility" like this?
I really do wish there was some equivalent of Windows' WSL: a kernel-side ABI shim for Linux/macOS that can run a complete copy of Windows (minus the kernel) inside it, including services like GDI—which you could then use an RDP client to connect to—but where the entrypoint is running an individual EXE, and those services are only started when clients attempt to connect to/use them. If I can make Wine like that, that'd be a dream.
Alternatively, Linux+macOS support for running Windows Docker applications, plus support for containerizing graphical Windows applications, would largely obviate my need for Wine.
Funny enough, when I was younger and more naive, I attempted to write a Linux kernel implementation of Win32, starting with a PE binfmt and linker. Never got much of interest working because I had trouble dealing with syscalls.
But I realized over time that it wasn't actually a good idea. Linux and Windows have one hell of an impedance mismatch. Windows distributes the user-space and kernel-space dramatically differently from Linux. The Linux VFS layer is greatly different than the Windows filesystem layer, and related semantics. Windows likes UTF-16 APIs, Linux likes UTF-8. They do threading differently, Winsock is extremely broken, named pipes don't work like netlink sockets, Windows is a little bit country, Linux is a little bit Rock'n'roll...
I'm sure someone with more experience can list off more. Even the general ecosystems are entirely different. A lot of things on Windows are kind of 'defacto.' Like, wintab32.
At the end of the day, the hacks that Wine does to make things work are astoundingly small compared to the massive undertaking they have reimplementing Windows in a fashion that is useful. You could go in with the logic of trying to be 'as Windows as possible' and use as much of the Windows libraries as you can, but how are you going to deal with things at that level, when Windows puts GDI and RPC in the kernel and Linux has it as userspace daemons?
> What I'm wondering is: if I don't care about being a Wine "purist", and I have a legitimate copy of Windows laying around, is there any way to dissect that copy of Windows for its files (drivers, helper executables, etc.) and wrap them around a Windows EXE, such that Wine will be using as few Wine implementations of DLLs as possible, rather than just the minimum required to get the individual EXE vaguely working? Is there a way to start off a Wine install with "maximum compatibility" like this?
the majority of problematic DLLs are officially redistributable by MS. the vast majority of the remainder depend on undocumented kernel APIs, which are... also unimplemented in wine, and usually the reason the builtin wine DLL doesn't work properly. you'd have an easier time importing your legitimate windows drivers to Linux, through ndiswrapper!
> So I usually have to copy files for them to interact with into the VM, open cmd.exe to run the utility on the files, interact with the utility GUI, then copy the files back out.
Most VMs provide the ability to share folders between the host OS and guest OS.
you can certainly redirect api calls into native windows dlls. there are also debugging utilities to see where your applications are failing. how low level are the utilities you are using?
It's a lot of hassle, especially because the least-working Windows programs are also some of the tiniest little utilities where they display maybe one GUI screen, but also take command-line parameters. So I usually have to copy files for them to interact with into the VM, open cmd.exe to run the utility on the files, interact with the utility GUI, then copy the files back out. Wine would make this workflow a lot better!
What I'm wondering is: if I don't care about being a Wine "purist", and I have a legitimate copy of Windows laying around, is there any way to dissect that copy of Windows for its files (drivers, helper executables, etc.) and wrap them around a Windows EXE, such that Wine will be using as few Wine implementations of DLLs as possible, rather than just the minimum required to get the individual EXE vaguely working? Is there a way to start off a Wine install with "maximum compatibility" like this?
I really do wish there was some equivalent of Windows' WSL: a kernel-side ABI shim for Linux/macOS that can run a complete copy of Windows (minus the kernel) inside it, including services like GDI—which you could then use an RDP client to connect to—but where the entrypoint is running an individual EXE, and those services are only started when clients attempt to connect to/use them. If I can make Wine like that, that'd be a dream.
Alternatively, Linux+macOS support for running Windows Docker applications, plus support for containerizing graphical Windows applications, would largely obviate my need for Wine.