4 ms·

On another thread an HN comment complained that Win32 was becoming standard API for games instead of Linux native, thanks to Wine. The reply kind of opened my

On another thread an HN comment complained that Win32 was becoming standard API for games instead of Linux native, thanks to Wine. The reply kind of opened my eyes. If Wine/ReactOS do continue the trend of becoming better more stable platform than Windows itself, thanks to Microsoft hell bent on destroying their reputation, eventually, Wine/ReactOS can even Embrace-Extend-Extinguish Windows itself. A man can dream..

smoldesu 5y ago
I really do believe it's possible. 10 years ago it would have been a pipe dream, but the dedication people put into making Wine and DXVK function properly is nothing short of astounding. Aside from high-performance studio software like NLEs and DAWs, you can pretty much expect everything to "just work" through Wine these days. From Bonzi Buddy to Battlefield, nothing seems to escape it's compatibility.
- jchw 5y ago
  We need to implement WM_POINTER* support in the input stack somehow, though. If we had that, Clip Studio Paint would work fine with a graphics tablet. Probably even Photoshop. Some hacking on Wine was able to get SAI2 running, but SAI1 is elusive due to the design of Wine’s wintab32 implementation; XI2 events only go to the window that is being interacted with, whereas wintab32 events can and often are pumped to hidden background windows (for reasons unknown to me, though I guess if the window is on a different event loop it probably helps to mitigate events lagging. WM_POINTER magically coalesces events when the loop is tied up, and lets you grab the coalesced events, so it has less of this problem.) I’ve thought about it a lot, but… The Wine input stack is fairly complicated and I haven’t grokked it all. I do have some projects I made for (clean room) examining behavior of the WM_POINTER events though. (Also, testing for this will suck.)
- dTal 5y ago
  >you can pretty much expect everything to "just work" through Wine these days Oh... if only... I can't remember the last time I tried to run a non-game application and it actually worked. And I try often - I can think of three instances in the past few weeks alone (if you want to know - Fusion 360, an internal .NET app from 2010 that by rights should have worked perfectly, an old DVD of Altium Designer). Don't get me wrong, I'm extremely grateful for Wine. But perfectly compatible it ain't, not even close.
GranPC 5y ago
Something I found pretty interesting, in that same line of thought, is that the VKD3D developer apparently added a specific hack [0] to work around a game bug that causes heavy stuttering even on Windows systems, effectively making Wine/Proton a better platform to play this game than Windows itself. [0]; https://github.com/HansKristian-Work/vkd3d-proton/commit/f39ece9a7ce579a56196455933a200ec04a9d8eb https://github.com/HansKristian-Work/vkd3d-proton/commit/f39...
- collegeburner 5y ago
  I thought graphics driver vendors often did the same for big titles?
  - johnny22 5y ago
    they do, but this solution affects all cards (or hopefully does) across all card driver versions. One example is folks stuck with the legacy nvidia driver. If the game can still run, they can still get fixes this way. It's nice when we can sidestep the process of waiting on nvidia or whoever in the various closed source drivers on both linux and windows.
zitterbewegung 5y ago
Yea well for business users of Windows in the enterprise it’s very attractive to have a service and support contract with them. On the other hand if ReactOS and or wine try to do the same thing then we could see some shift but I don’t think it is likely.
- e3bc54b2 5y ago
  Eventually, there will be businesses offering support contracts. And if history is any indication, MS cannot out-litigate that future. RH/IBM rose despite SCO lawsuite. If the code is there and it works, people will make use of it.
a9h74j 5y ago
Perhaps those creating developer tools etc can aid this scenario by making their "cross platform" story Linux/MacOS/ReactOS or Linux/MacOS/Linux.Wine, rather than Linux/MacOS/Windows. This might also facilitate developing cross-platform support for the Win32 option in a VM rather than on a live Windows machine -- e.g. a ReactOS VM. Besides avoiding licensing issues, some kinds of developer on-boarding could be facilitated by just pointing them to an available VM, rather than a gauntlet of environment setup. In a sense, all this points toward an alternate reference implementation for Win32, or at least some subset, for some purposes. And/or a possible phrase: "ReactOS-First" development on Win32.
rubenbe 5y ago
I did notice this first hand when trying trying to play an older game under Linux natively (Enemy Territory: Quake Wars). The Linux binaries refused to function (IIRC due to incompatible user space ABIs), but the Windows binaries worked perfectly using Wine.

smoldesu 5y ago

I really do believe it's possible. 10 years ago it would have been a pipe dream, but the dedication people put into making Wine and DXVK function properly is nothing short of astounding. Aside from high-performance studio software like NLEs and DAWs, you can pretty much expect everything to "just work" through Wine these days. From Bonzi Buddy to Battlefield, nothing seems to escape it's compatibility.

jchw 5y ago
We need to implement WM_POINTER* support in the input stack somehow, though. If we had that, Clip Studio Paint would work fine with a graphics tablet. Probably even Photoshop. Some hacking on Wine was able to get SAI2 running, but SAI1 is elusive due to the design of Wine’s wintab32 implementation; XI2 events only go to the window that is being interacted with, whereas wintab32 events can and often are pumped to hidden background windows (for reasons unknown to me, though I guess if the window is on a different event loop it probably helps to mitigate events lagging. WM_POINTER magically coalesces events when the loop is tied up, and lets you grab the coalesced events, so it has less of this problem.) I’ve thought about it a lot, but… The Wine input stack is fairly complicated and I haven’t grokked it all. I do have some projects I made for (clean room) examining behavior of the WM_POINTER events though. (Also, testing for this will suck.)
dTal 5y ago
>you can pretty much expect everything to "just work" through Wine these days Oh... if only... I can't remember the last time I tried to run a non-game application and it actually worked. And I try often - I can think of three instances in the past few weeks alone (if you want to know - Fusion 360, an internal .NET app from 2010 that by rights should have worked perfectly, an old DVD of Altium Designer). Don't get me wrong, I'm extremely grateful for Wine. But perfectly compatible it ain't, not even close.

GranPC 5y ago

Something I found pretty interesting, in that same line of thought, is that the VKD3D developer apparently added a specific hack [0] to work around a game bug that causes heavy stuttering even on Windows systems, effectively making Wine/Proton a better platform to play this game than Windows itself. [0]; https://github.com/HansKristian-Work/vkd3d-proton/commit/f39ece9a7ce579a56196455933a200ec04a9d8eb https://github.com/HansKristian-Work/vkd3d-proton/commit/f39...

collegeburner 5y ago
I thought graphics driver vendors often did the same for big titles?
- johnny22 5y ago
  they do, but this solution affects all cards (or hopefully does) across all card driver versions. One example is folks stuck with the legacy nvidia driver. If the game can still run, they can still get fixes this way. It's nice when we can sidestep the process of waiting on nvidia or whoever in the various closed source drivers on both linux and windows.

zitterbewegung 5y ago

Yea well for business users of Windows in the enterprise it’s very attractive to have a service and support contract with them. On the other hand if ReactOS and or wine try to do the same thing then we could see some shift but I don’t think it is likely.

e3bc54b2 5y ago
Eventually, there will be businesses offering support contracts. And if history is any indication, MS cannot out-litigate that future. RH/IBM rose despite SCO lawsuite. If the code is there and it works, people will make use of it.

a9h74j 5y ago

Perhaps those creating developer tools etc can aid this scenario by making their "cross platform" story Linux/MacOS/ReactOS or Linux/MacOS/Linux.Wine, rather than Linux/MacOS/Windows. This might also facilitate developing cross-platform support for the Win32 option in a VM rather than on a live Windows machine -- e.g. a ReactOS VM. Besides avoiding licensing issues, some kinds of developer on-boarding could be facilitated by just pointing them to an available VM, rather than a gauntlet of environment setup. In a sense, all this points toward an alternate reference implementation for Win32, or at least some subset, for some purposes. And/or a possible phrase: "ReactOS-First" development on Win32.

rubenbe 5y ago

I did notice this first hand when trying trying to play an older game under Linux natively (Enemy Territory: Quake Wars). The Linux binaries refused to function (IIRC due to incompatible user space ABIs), but the Windows binaries worked perfectly using Wine.