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.
I remember when Wine 1.0 was released. It was quite a surprise, as Wine was one of the classic programs famous for never reaching version 1.0 despite working well and being extensively deployed for many years. NASM hit 1.0 around that time too, if I recall correctly. Vista had been released not long before that, and the following year Enlightenment E16 hit 1.0 too. Weird times... people began thinking that Duke Nukem Forever might end up getting finished and released after all.
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
But can it run Linux?!
i'm seriously contemplating buying a mac book, I would love nothing more than to be able to dump MS completely since Win10.
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.
Better yet, lets see how well everything can be coded such that we can fit as many of these things in as small a space as possible, while still being capable of actually running things having just one in memory.
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.
It's a bunch of libraries to get called instead of the MS ones. :)
Either that or a series of tubes
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"
Word and Excel 2013 are still rated as garbage. The 2013 installer is only rated silver. That's some great office 2013 support. Are we all using Trump style facts now?
Perhaps he wants to run those applications and run his preferred OS at the same time.
And almost nothing that the rest of us want.
I'm so happy for you that Wine meets your needs. It falls quite short of being a practical substitute for Windows for everything I've ever wanted to use it for.
File under 'M' for 'Manic ranting'
Someday you'll realize that life is hard enough without us making it harder for each other. Prove you have some worth in this world, and work to make life better for everyone.
1. Can I open Chrome in it and watch netflix / other streaming services that people watch?
Who cares? Netflix has been working in Linux-native Chrome for over a year now. There's no need to mess with Wine.
2. Can I download Steam on it and play a library of games without running into driver issues?
Most D3D9 games (and also the relatively-rare OpenGL or Vulkan titles) work fine. If you have a problem with any of them, it's usually an issue with 3rd-party DRM. D3D11 support still has a long way to go toward getting playable results.
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...
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.
It's an implementation of the Win32 APIs. Microsoft has implemented many of these twice (though often sharing code), once atop the services provided by the Windows 9x series of operating systems and once atop those provided by the Windows NT kernel. In this sense, WINE is no more an emulator than Windows 7 is when it provides reimplemented APIs created for Windows 95.
WINE is a little bit more like an emulator, in that it is often providing Windows services atop other APIs with a similar level of abstraction. For example, WINE translates Direct3D into OpenGL, whereas the Windows implementation translates Direct3D into the APIs used by the top of the 3D device driver. It doesn't always work this way though. Windows font, windowing, and 2D drawing are all implemented by WINE on top of lower-level APIs and there was some work a couple of years back to provide a Direct3D state tracker in Gallium, allowing WINE to directly translate Direct3D into things consumed by the top of the GPU driver stack, just as the Windows implementation does.
If WINE is an emulator, then GNU Classpath running on the Kaffee JVM is an emulator of the Sun JVM.
I am TheRaven on Soylent News
Well to use an old Jerry Pournelle catchphrase from his Byte Magazine column, "you maybe won't need it often, but when you do need it, you need it bad".
Case in point. I run Linux Mint 17 LTS. When I moved from Windows one of the few Windows-only applications I wanted to keep was my usenet client - xnews. It is, IMHO, the best usenet client I've found over many years and I have it tweaked just how I like it. YMMV. So being able to continue to run it under Wine was a win for me.
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.
There are several parts to wine.
One is a big set of libraries that act as substitutes for the windows ones, either implementing functionality themselves or translating it to calls to native Linux libraries.
Another is a binary loader that knows how to actually load windows binaries into the right place in memory (which is tricky because you have to make sure Linux doesn't put any shared libraries there first) and resolve their imports against both windows dlls and the wine-specific libraries.
Another is a program that provides a substitute for the windows kernel, allowing programs to talk to each other as-if they were on a windows sytem.
There is also a reimplmentation of the compatibility layer that allows 16 bit programs to run on 32-bit systems.
No actual processor emulation takes place but an awful lot of other stuff gets emulated.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
I believe that sentence requires its own article here on slashdot!
" If the emulated thing does not exist, then it is a simulator not an emulator."
A simulator doesn't actually do the thing it relates to. You can't go anywhere in a flight simulator. You can't kill anything in an RPG or gain any kind of experience. You can execute code in the emulated instruction set of the jvm. Destroying every C64 on earth would not magically turn the emulators into simulators just because the thing they emulate no longer exists. Creating a chip that uses byte code as its native instruction set would not change the jvm from simulator to emulator either.
The performance of an application ported through WineLib is going to be identical to the performance of the Windows binary running through Wine. So WineLib is no more and no less useful for games than it is for any other application.
No it isn't. A Win32 application running over wine involves more context switching and memory contention due to wineserver and other libraries eating up resources. In theory a natively compiled Win32 exe might be more optimal if MSVC ran more efficiently than gcc / clang but these days that's unlikely.
In addition, games tend to be self contained and only touch certain APIs. So the rest of the Wine runtime is superfluous bloat. Compiling and linking against winelib saves space on disk because the code that is unused will not be linked into the executable. It also means the game can ship only things that it needs to work and can tested to within an inch of its life against those things instead of some random Wine on someone's machine.
Thirdly, a game running on Linux might have to disable or modify its copy protection, change or remove certain texts and assets, interact with Linux in certain ways (e.g. disable screensaver, input devices), interact with other software such as Steam on Linux, or use different file paths. These changes might only amount 2% of the codebase allowing the rest to be preserved. I'd add that code is very unlikely to be using #import or MFC in a game. And even they did use #import, it's easy to fix since #import generates the source code for itself so just compile that instead.
Yes you could run a game on Linux through Wine and that's the fallback situation you'd still be running the Windows game. You wouldn't even register as a Linux user on some spreadsheet of the company that produced it. It would be better for you and Linux if the game was ported and ran natively on the platform even if that were through winelib.
And another 82 duplicate articles.
(Score: -1, Stupid)