Wine 1.8 is released
winehq.org
winehq.org
I've found it to work remarkably well with games. Basically install Steam from Wine and then install Steam games like you normally would. It mostly just works.
I also installed and played "Path of Exile" through Wine with no problems. It's a fast, online hack 'n slash where if I died I would have to start over tens of hours of gameplay and Wine never let me down on latency or anything.
It also generates .desktop files for Windows programs entries that populate your ~/.local/share/applications/wine/Programs folder and are thus indexed by most desktop application launchers. That means when I install Skyrim on Linux it shows up in krunner.
As a normal man, in addition to the technical changelog, what would be interesting for me to have is a list of software that can now be run by wine, or that have a significantly improved experience with this version compare to 1.7
What I wanted to express is that, as I guess the development is followed by a community of people to which it has been said that future version of wine will fix their current compatibility problem, they may have got some feedback of said people "hey cool now whateversoft version x.y works" and gathered a list of said software, especially if it does include some big names.
I thought that's what this[1] was for.
[1] https://appdb.winehq.org/objectManager.php?sClass=version&iI...
If I could get this, I could run Linux on all of my work dev machines. But I'm pretty sure the day this works is rather far away. Thankfully, people like Anastasius Focht have been extremely helpful in dealing with related issues.
The game used to work though, so I really can't blame WINE for this.
For example, DX11 being opened up doesn't matter because it relies on the Windows driver model while Wine is translating HLSL and D3D calls to OpenGL, or Gallium-Nine is translating them to TGSI. Opening up most system libraries doesn't work, because they are all using Windows kernel primitives the Linux kernel won't have.
The complexity of Wine is more that Windows is a 30 year old maze of complexity with millions of independent APIs and callbacks implemented over the years without rhyme or reason, and a Windows exe can call any of them any time and get anything back because the APIs are anything but bugfree. You need to translate Windows soup to Posix soup and somehow get all the expected behavior the running program needs, and then on the backend they are supporting pretty much every non-Windows OS so they have to fight with all their targets quirks.
Do you have a typical good example for this?
So, genuine question, are you suggesting that if Microsoft decided to do something about this, that would pretty much have to rewrite it from scratch?
These are all the system libraries Wine has reimplemented so far, and thats only up to its current near-DX10 support, and these libraries are just the base - most applications can ship their own copies of Windows libraries, but as long as the core libraries everything else depends upon work you can run other libs on top of them.
But a lot of Windows has been reimplemented between the old 3.1 era and now, and not just the kernel - MS has maintained fair backwards compatibility the whole say so new versions of the same API can be dramatically different in implementation.
If Microsoft wanted to support Windows executables on Unix they would need to just pick up where Wine is at now and continue their work, albeit with insider access to code to know all the edge cases of their own implementations of these APIs, since software is written against the bugs.
Previous HN discussion: https://news.ycombinator.com/item?id=6171925