Hacker News new | comments | ask | show | jobs | submit login
Wine 1.8 is released (winehq.org)
178 points by coldpie on Dec 19, 2015 | hide | past | web | favorite | 38 comments

I recently used Wine on Ubuntu and was amazed how smoothly it just worked. Download an msi Windows installer and open it just like you would in Windows. The program installs just like on Windows, and runs from its own icon just like in Windows. You hardly need to think about the fact that it's not Windows. Understandably there were a few compatibility problems but having it so well integrated into the UI was a surprise. It's perhaps almost good enough that you don't need to port your Windows application to Linux anymore. Just avoid the broken functionality. As a Windows programmer, I now keep Wine compatibility in mind when deciding to use new features and libraries and will be trying to remove incompatible code.

Interesting. Is that just Wine itself, or does Ubuntu/GNOME/whoever have some special sauce that facilitates the seamless desktop integration?

No real special sauce, but you have winetricks which has a few things to help solve common problems, and then winehq.org to see if others made a particular software/game on Linux.

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.

Wine does it everywhere. The way prefixes work it simlinks the traditional Windows file system heirarchy to Linux, such that XDG_DESKTOP_DIR or XDG_DOCUMENTS_DIR will become the Windows Desktop / My Documents folders.

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.

Thanks a lot to the team for these improvements

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

Given the way Wine versioning works, I wouldn't expect any significant changes from the latest 1.7.x cycle. Wine uses the same versioning system that Linux used prior to (and perhaps after, I'm not sure) the 3.0 release. The second number represents a stable version if it's even or an unstable development version if it's odd. Odd releases are used to "build up" new features towards an even-numbered release.

That convention/development model was dropped with Linux 2.6. Current Linux is essentially still the 2.6 series. Linus just felt silly having the same major version number for ~8 years and has switched to incrementing it whenever the fancy strikes him.

Thanks for this information, I was thinking it was following semantic versionning and looking to the changelog I thought it was big changes.

It's not in alpha like ReactOS. In my experience, most simple apps work well and many older games run perfectly. If there's something you want to run, check the app DB. It's complete and well maintained.


And a good number of newer games, such as Guild Wars 2.

There is a lot of software for Windows. The time it takes to test even a small set of software is likely significantly larger than producing a new release.

sure, I'm not saying the team should take the burden of doing the testing on a given set of windows software (even the 100 most popular one, whatever it means)

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.

At least in my experience, Wine compatibility is usually not binary. Programs don't go from "non-working" to "working" so much as they progress from "intolerable bugginess" to "tolerable bugginess" to "trivial bugginess", with the thresholds between those categories being highly subjective.

> "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...

yes, that's what it is for outside of the release cycle to know if a given software work. But here it's an announcement where you explain changes to the community between previous version and this version. So I was thinking that it may have been interesting to have a brief list of software from the database you've linked that have turned form garbage to bronze etc.

I'm frequently surprised that wine just works even with the most obscure and odd programs, e.g. exe packed Flash SWFs and programs with weird custom GUIs.

Flash Player redistributables aren't really obscure, they're all the same program, so I'd imagine WINE would support it well.

Fair point. I somehow was under the false impression that no one ever uses these Flash Player projectors, but it seems to have been supported for a long time according to the WINE app DB. Still awesome. =D

Great work by Wine team. I use Wine for a lot of Windows application but I could never make Office (2010 and later) work on Ubuntu. If I can somehow do that, probably I would never switch back to Windows. Open Office/Libre office is frustrating and so are most online word replacements.

Office 2010 should run under the commercial version of Wine dubbed Crossover: https://www.codeweavers.com/compatibility/crossover/microsof...

Use playonlinux which is based in wine. Good Luck!

To those using it: did it happen to you at least once to find out that a specific application (or game) you really needed did not work with Wine? What was it?

Games are great and everything, but I'm still hoping for Visual Studio support. Ever since MS switched to a WPF-style UI (2010 and newer), it's been unusable. Here's the status for VS 2015 as of 1.7.49: 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.

Isn't it more realistic to expect that Visual Studio will be made binary-available by Microsoft itself on Linux or even open sourced at some time given the latest Microsoft turnarounds?

AFAICT (checked this a few months ago), it's waiting on a few difficult bugs. A good target is getting through the VS 2015 Community installer first, then working on the rest.

I had one issue with the game DayZ Standalone. Apparently, it uses a function which is not implemented by WINE (yet), and because of that, the game cannot start properly.

The game used to work though, so I really can't blame WINE for this.

I just happen to install it. I can't open exe files. Hmm.. weird.

One thing I'd like to note that some may not realize but ReactOS is based in part on Wine[0], so any improvements to Wine will likely find themselves to ReactOS where possible.I mention this because there was a recent post about ReactOS[1].

[0]: https://en.wikipedia.org/wiki/ReactOS#Wine

[1]: https://news.ycombinator.com/item?id=10746799

Nice! I'm excited to try out the 64bit support on OSX. Thank you to everyone that works on this!

WINE is an amazing project. Big kudos to the team at CodeWeavers and all contributors.

Native Pulseaudio support. Thank you!

Wine has Native JACK support. just install jack, and make pulsaudio its slave.

What part of Windows would need to be made open in order to get a 100% Windows binary compatibility on Linux?

Windows binaries using win32.dll are working pretty universally nowadays. Even WinRT is pretty much implemented. Its all system support libraries and opening up Windows would not make the implementations come faster besides having better access to finding the bugs in the documented API that many programs expect.

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.

> 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

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.

Anyone know if there is a way to run MacOS X or iOS apps on Linux?

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact