Wine 1.6 released

[Posted July 18, 2013 by corbet]

Version 1.6 of the Wine Windows emulation system is out. "This release represents 16 months of development effort and around 10,000 individual changes. The main highlights are the new Mac driver, the full support for window transparency, and the new Mono package for .NET applications support."

to post comments

Wine 1.6 released

Posted Jul 19, 2013 7:42 UTC (Fri) by Zenith (guest, #24899) [Link] (4 responses)

Second to last paragraph is:

*** Known issues

- The addition of DirectWrite causes Steam to be unable to display
  text. This can be fixed either by setting dwrite.dll to disabled for
  steam.exe using Winecfg, or by running Steam with the -no-dwrite
  option.

That seems fairly important to mention - I imagine quite a few of Wine's users are running games, and still Steam games, in spite of better native support - as not all games runs natively.

Wine 1.6 released

Posted Jul 19, 2013 11:03 UTC (Fri) by bradh (guest, #2274) [Link]

All bugs are important to someone, and it did get mentioned in the announcement.

I asked too, here's the answer.

Posted Jul 19, 2013 18:06 UTC (Fri) by david.a.wheeler (subscriber, #72896) [Link] (1 responses)

I asked the same thing on slashdot.

fgouget (925644) answered, saying: "Before Wine had no DirectWrite dll at all, causing applications to detect that and fall back to other code paths like they do on older Windows versions. Now Wine has a DirectWrite dll so applications try to make use of it. However it's still pretty incomplete, thus causing new bugs. But then theres' also some applications that will only run on Vista or greater that had no fallback work and that have no fallback code path which have now started working, at least to some extent, because this dll is now present. So it's a case of lose, some win some; as every time Wine adds a new dll."

Will this be fixed soon? "Depends. We're waiting for your patches!"

I asked too, here's the answer.

Posted Jul 25, 2013 9:36 UTC (Thu) by andrey.turkin (guest, #89915) [Link]

It has happened on more than one occasion before: some new functionality is introduced and some programs start working because of it; however the support is not yet complete so there are some pieces of missing functionality and some bugs so other programs are now broken. Sometimes those are high-profile programs so there is an outcry demanding to fix these "regressions" even though those are not technically regressions.
I think Wine should follow Microsoft in their quest for software compatibility and start populating appcompat database. A lot of application can be fixed using some small fix/quirk/workaround, and the knowledge of how to do that is out there in bugs.winehq.org issues and in appdb.winehq.org pages. Wine certainly could've detected Steam application and hidden dwrite.dll from loading, so people don't have to tinker with configuration themselves. Of course these workarounds must be seen as a stop-gap measure; bugs must be fixed and workarounds removed afterwards.
Other use for appcompat can be same as Windows' - to work around various bugs in applications (recent discussion on wine-devel about Civilization V is a perfect example).

Wine 1.6 released

Posted Jul 20, 2013 7:04 UTC (Sat) by Seegras (guest, #20463) [Link]

Well, as long it is known, and a reasonable workaround is there, I can live with it.

Actually, I do, since the earliest 1.5 days when dwrite was added. And at that time, finding out why Steam wouldn't show any characters wasn't that easy to find out...

Wine 1.6 released

Posted Jul 21, 2013 21:36 UTC (Sun) by pr1268 (guest, #24648) [Link] (6 responses)

I wish to commend the Wine developers on their hard work in producing yet another stable release. Also note that what I mention below is not meant to criticize or dismiss Wine and the hard work its developers put forth. That being said...

After reading various news articles [1] [2] [3] about ~~the demise of MS Windows on the desktop~~ the epic failure of the Surface RT tablet, I sometimes wonder if the day when Wine is not really needed anymore is not too far off. With the likes of {Open,Libre}Office, various mobile platforms, many game/entertainment software being ported to HTML5, and Steam (supposedly) now working natively on Linux, I'm beginning to think that Wine may be unneeded in the near future. Does anyone else have this perception?

Again, I'm hoping this isn't misunderstood as an anti-Wine rant. Far from it. I do use some (older) Windows software with Wine on a daily basis. Gratefully.

[1] Microsoft stock price plummets

[2] MS Surface RT a Disaster

[3] MS Business Model the Punchline to a Joke

Wine 1.6 released

Posted Jul 21, 2013 22:04 UTC (Sun) by apoelstra (subscriber, #75205) [Link]

I think these days the typical use case for Wine is to run older Windows programs (for Win 95-2000), which don't run on modern Windows desktops anyway.

So while it's nice that Windows is going away (especially before they managed to do any lasting damage with Secure Boot), I don't think it'll affect Wine much.

Wine 1.6 released

Posted Jul 22, 2013 11:14 UTC (Mon) by Tobu (subscriber, #24111) [Link] (3 responses)

Steam has been ported to Linux, but most games haven't. DirectX (with Direct3D) is still unreasonably popular for windows games; the portable alternative to that is SDL2 (with OpenGL); here are guides to porting. You did mention “HTML5”; it will take time and effort for the web platform/Air/Chrome to become viable beyond low-end games — they will need to provide a wide yet reliably available platform, ease of porting, and strike a compromise between driver functionality and security. Even when porting is easy, for example because the game is multiplatform already, you still need the porting expertise and some market pull. It's depressing to see some games that have Humble Indie Bundle ports but don't get activated on Steam for Linux (and, to a lesser extent, Mac).

Wine 1.6 released

Posted Jul 22, 2013 17:12 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (2 responses)

But there's this commit[1]. How does one actually leverage it? Or is it behind the scenes with WINE already?

[1]http://cgit.freedesktop.org/mesa/mesa/commit/?id=92617aea...

Wine 1.6 released

Posted Jul 22, 2013 17:20 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

Looking into it, support doesn't seem to be built on either Fedora or Debian.

Wine 1.6 released

Posted Jul 22, 2013 18:14 UTC (Mon) by Tobu (subscriber, #24111) [Link]

There was some work on the DirectX 10/11 tracker (notably by Christoph Bumiller of Nouveau), but ultimately it didn't get off the ground and someone of, err, VMWare suggested it be killed off last March (Phoronix).

Christoph Bumiller did just publish a DirectX 9 state tracker in Mesa and matching patches to Wine (Phoronix again); maybe it will catch on.

Wine 1.6 released

Posted Jul 22, 2013 22:52 UTC (Mon) by rgmoore (✭ supporter ✭, #75) [Link]

The death of Windows has been greatly exaggerated. That said, in the short term, the demise of Windows would make Wine even more important. If Windows gets so awful that people feel a need to move away from it, there will be an ugly transition period where they have a mix of new, non-Windows programs and legacy Windows programs, neither of which they can afford to give up. Wine could really ease the transition by letting people continue to operate their legacy programs without needing to keep a legacy Windows machine or VM running to do so.

Wine 1.6 released

Posted Aug 1, 2013 10:28 UTC (Thu) by callegar (guest, #16148) [Link] (2 responses)

Release notes have no mention of a bug with ShellExecuteEx failing for paths with spaces in them and possible impact.

If I understand correctly, when there is a space in a path, a call to execute the file pointed to by that path will unexpectedly result in executing a file residing at the location pointed by the path truncated at the space if it exists.

I wonder if this could be exploited maliciously to to run A when the user thinks he is running B. Can someone provide some hint on this?

Wine 1.6 released

Posted Aug 2, 2013 2:48 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (1 responses)

I *think* this was a vulnerability in Windows as well a few years ago (2007ish? At least, that's when I heard about it). I think it also affected library loading (implicit ".dll" appended where spaces occurred before trying with the space in there). Light searching didn't turn up anything (the WINE bug I imagine you're referencing is higher on the list).

Wine 1.6 released

Posted Aug 5, 2013 17:50 UTC (Mon) by callegar (guest, #16148) [Link]

This information seems quite useful. I wonder if someone among the readers could confirm if this was in fact considered a security vulnerability in Windows and in case provide a pointer to it. Apparently, this is not recorded as a security issue in the wine bug tracker now, but if it is critical it would be good to rise the priority.

Wine bug is http://bugs.winehq.org/show_bug.cgi?id=23321, and as a matter of fact it is an extremely old one, since reporting started with http://bugs.winehq.org/show_bug.cgi?id=7900 back in 2007.