Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wine 1.8 is released

winehq.org

Post reply on HN
Print view View original

31–40 of 40 posts

Re: Wine 1.8 is released

#31

Post by zanny »

MrBra wrote: post #20

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.

Re: Wine 1.8 is released

#34

Post by giancarlostoro »

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

Re: Wine 1.8 is released

#35

Post by sawwit »

TazeTSchnitzel wrote: post #13
sawwit wrote: post #11

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

Re: Wine 1.8 is released

#36

Post by gdiocarez »

MrBra wrote: post #19

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?

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

Re: Wine 1.8 is released

#37

Post by MrBra »

zanny wrote: post #31
MrBra wrote: post #20

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…

> 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?

Re: Wine 1.8 is released

#38

Post by MrBra »

justabystander wrote: post #22
MrBra wrote: post #19

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 li…

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?

Re: Wine 1.8 is released

#39

Post by zanny »

MrBra wrote: post #37
zanny wrote: post #31

Earlier quoted context omitted.

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…

> 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?

http://source.winehq.org/git/wine.git/tree/HEAD:/dlls

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.

Post reply on HN