Slashdot Mirror
Wine 2.0 Released (softpedia.com)
An anonymous reader quotes a report from Softpedia: It's finally here! After so many months of development and hard work, during which over 6,600 bugs have been patched, the Wine project is happy to announce today, January 24, 2017, the general availability of Wine 2.0. Wine 2.0 is the biggest and most complete version of the open-source software project that allows Linux and macOS users to run applications and games designed only for Microsoft Windows operating systems. As expected, it's a massive release that includes dozens of improvements and new features, starting with support for Microsoft Office 2013 and 64-bit application support on macOS. Highlights of Wine 2.0 include the implementation of more DirectWrite features, such as drawing of underlines, font fallback support, and improvements to font metrics resolution, font embedding in PDF files, Unicode 9.0.0 support, Retina rendering mode for the macOS graphics driver, and support for gradients in GDI enhanced metafiles. Additional Shader Model 4 and 5 shader instructions have been added to Direct3D 10 and Direct3D 11 implementation, along with support for more graphics cards, support for Direct3D 11 feature levels, full support for the D3DX (Direct3D Extension) 9 effect framework, as well as support for the GStreamer 1.0 multimedia framework. The Gecko engine was updated to Firefox 47, IDN name resolutions are now supported out-of-the-box, and Wine can correctly handle long URLs. The included Mono engine now offers 64-bit support, as well as the debug registers. Other than that, the winebrowser, winhlp32, wineconsole, and reg components received improvements. You can read the full list of features and download Wine 2.0 from WineHQ's websiteS.
Lots of features and bug fixes, including 64-bit support, but I suspect the typical WINE user will be more interested in a simple list of programs that now work with it.
Deja vu: In the 80s we had a 70ish actor as POTUS, a woman PM in the UK, and a bald leader of that other nuke superpower
Working at Microsoft and having a job of making Linux apps play on Windows would be kinda cool, because Linux has a reasonably small set of system calls (OK, we're not talking dozens anymore, its more like hundreds) and the overall userspace/kernel interface is well designed and explained in a number of good books.
Trying to make Windows apps play on Linux is an Sisyphean/Augean Stables type task, because the Windows API was designed to be horrendously difficult to copy (by OS competitors), and hard for application competitors (like Netscape, Lotus, or WordPerfect) to keep up with. If API's had 15 arguments each of which was a complicated struct, so much the better in the thinking of the MS Windows honchos.
As Steve Jobs put it: "They (Microsoft) have no taste."
I'm guessing that WINE doesn't leak users (design) data back to Microsoft? This could be -exactly- why you would want to run pro tools on WINE these days... It's precisely why I was thinking the same thing when I read the comment.
Highlights of Wine 2.0 include the implementation of more DirectWrite features, such as drawing of underlines
It truly is the year of the Linux desktop!
This should bring ReactOS closer to being useful.
Linux running Windows in a QEMU, running a Linux subsystem, running Windows in WINE. Let's see how many system resources we can hog without actually running anything.
I recall long ago (2003 maybe?) one of the Wine developers showed up on Tech TV and Leo Laporte asked him something like "if wine isn't an emulator, then what is it?" and the dude answers back "it's an emulator". I have a feeling that the rest of the wine devs were gritting their teeth at that though, but I never checked their mailing lists to see.
My understanding is that rather than an emulator, it's just an API wrapper, or alternatively a simulator or maybe "high level emulator", but I'm not an expert on how you name these things.
They run Cygwin under Wine for their Apple ][e emulator, to run Logo. Once you're in Logo, it's turtles all the way down.
A bug fix isn't a bug fix in the normal term. As far as wine is concerned, a bug is "this random program x doesn't work"
Perhaps he wants to run those applications and run his preferred OS at the same time.
WTF? You'll pay for AutoCAD or SolidWorks, but are too cheap to buy Windows? You deserve what you get, I guess.
You think I run Linux because I can't afford free-as-in-beer windows? Newsflash: many Linux desktop users already have the windows license when it came bundled with the computer. Our reasons for discarding the windows install has nothing to do with price.
I'm a minority race. Save your vitriol for white people.
That's because originally LAME was a set of patches against the "dist10" MPEG reference software sources. As such it was not an MP3 encoder. It took some time before all the original reference source was removed. Only 82 days left till the last of the MP3 patents expires...
I recall long ago (2003 maybe?) one of the Wine developers showed up on Tech TV and Leo Laporte asked him something like "if wine isn't an emulator, then what is it?" and the dude answers back "it's an emulator".
The dude in question was Alexandre Julliard, Wine's project leader. The goal of the show was to present Wine so there was a sort of rehearsal during which the journalist said he was going to say something like "so Wine is an emulator" to which Alexandre would object. But during the live interview the journalist actually said "so Wine is not an emulator" which caused Alexandre to take the opposite stance as per the rehearsal. I'd say he a better as a tech leader than as a PR guy and I certainly wouldn't want it any other way.
Even so he did not say that Wine would emulate CPUs which was the common understanding of the word 'emulator' at the time. It's still true that Wine will not deal with CPU emulators or virtual machines. Both of these aspects are best dealt with independently of Wine. So anyone who needs that should run Wine and their application inside their VM or CPU emulator. Except in pathological cases, if the VM / CPU emulator is fast enough to run the application it's still going to be fast enough if you add Wine to the mix.
Wine is a reimplementation of the Win32 and Win64 APIs on top of the Unix (and X, OpenGL, Cocoa) APIs. It's not all that different from Glib and GTK+ which provide their own system and graphics APIs on top of the underlying system APIs, be that Unix or Windows. Of course the Windows APIs were not meant for this so there are some extra complications and side effects (e.g. %fs register usage conflicts on some platforms), but not so much for the general case.
I believe that sentence requires its own article here on slashdot!