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.
Who said it was?
Never happened. True story.
After so many months of development and hard work, during which over 6,600 bugs have been patched
Are they also patched in 1.x? If not, I can't wait for 2.1's patch notes "fixed over 6,600 regressions." :P
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?!
If not who cares.
Is Wine an emulator yet?
Minimum threshold fixed. Thanks!
i'm seriously contemplating buying a mac book, I would love nothing more than to be able to dump MS completely since Win10.
Wine Is aN Emulator
I remember wanting to run Office and Visual Studio on WINE. It worked for the most part.
http://www.perfectreign.com/stuff/2009/20090614_wine_excel_2007.jpg
The Kai's Semi-Updated Website Thingy
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."
...well how about the Windows Subsystem for Linux?
Several years ago, John Carmack seemed to think that writing for a version of DirectX, supported by Wine, was good enough for video gaming in Linux, given Linux's small market share. Why be limited to video games, why not some productivity software as well?
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.
If Wine was accelerated by Qemu then maybe it would Timothy.
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
6,600 bug fixes shouldn't be something you're proud of.
With that many bugs that were in the software in the first place, who knows how many are still left?!
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?
ReactOS can do it first!
Questions from the masses:
1. Can I open Chrome in it and watch netflix / other streaming services that people watch?
2. Can I download Steam on it and play a library of games without running into driver issues?
Especially #2.
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.
Wine is a shim.
Exactly. Just like LAME, which stands for Lame Ain't an MP3 Encoder, actually is an mp3 encoder. The name was a cute gimmick, that's it.
Beer was 2.0 more than 1000 years ago
Any word on that? Was a major pain to use their HTML5 based battle.net launcher back in the summer.
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.
The Linux OS + userland + Wine = an emulator for a Windows OS + userland.
Wine itself is just an adapter layer that provides/implements the same binary API as Windows. By itself it emulates nothing.
Red or white, Pinot, Nebbiolo or what?
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...
It does not beg the question. Your mum begs for the D, which raises the question "who's your dad?"
"Emulation" has a strong connotation with a software implementation of CPU hardware. Wine is an implementation of various Windows API, and is not an emulator of any central processing unit.
Wine is an emulator and it's not an emulator. You can run a Windows executable on the runtime or you can compile Windows source code and run it as a native executable. The latter would be more useful for things like porting games.
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
Wine is an (imcomplete) implementation of the Win32 API running on top of the Linux kernel.
Just like like Microsofts implementation of the Win32 API running on top of the NT kernel.
If the latter is not an emulator, then neither is the former.
Have they fixed the morning after hangover?
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.
Wine is an emulator and it's not an emulator. You can run a Windows executable on the runtime or you can compile Windows source code and run it as a native executable. The latter would be more useful for things like porting games.
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.
What WineLib does buy you however is lots of complications with the compilation toolchain as soon as your code depends on Microsoft-specific C++ features like the omnipresent #import directive, Visual C++ project files (even with winemaker), or the MFC, etc. Things get complex pretty quickly if you also have third-party libraries or use other languages like Visual Basic or even C#.
I'd do anything to play that game again (other than installing Windows a given).
BF3 is the best game I've ever played and I've play a lot of them yet BF3 just blew me away. I'd sure like to play that game again, I had 3000 hours into it and could still played 6 hours a day,
Crazy talk I know - , BF3 under Wine... but one can hope.
aannd... still no Direct3D 9 support. One of the reasons I avoid FOSS is those eternal feature requests that languish forever while the developers focus on more "important" stufff (such as porting Wine into Windows, no really). If Wine was a commercial package, this problem would have been addressed one way or another. Just like LibreOffice still doesn't do OOXML perfectly, but WPS Office does. Or just like how PowerDVD supported Bluray discs shortly after they were introduced while no media players does it yet (not even unencrypted ones). Because commercial interest. Because money.
(i meant no open-source media player obviously)
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 just wish iPhone syncing worked with iTunes under Wine, then I could pretty much ditch Windows completely.
So it sounds like building on wine gives you more portable and robust code that is not as tied to Microsoft propritary "shortcuts."
I suspect you're just trolling, but still:
aannd... still no Direct3D 9 support.
What? Of course there is.
If Wine was a commercial package, this problem would have been addressed one way or another
If you want a closed-source Wine, look at CrossOver.
Yeah, people have come to think of an "emulator" solely as something that reproduces CPU functionality, but WINE is a software compatibility layer that emulates the functionality of Windows calls.
In a broad sense "emulate" just means "fill in for functionality." A simulator implements functionality so you can see how well it works, but an emulator is meant to actually do the job of the thing being emulated!
Can duel boot I take it.
Meanwhile, AC trollers just shitpost all over everyone. I think I know which I prefer.
"Emulation" has a strong connotation with a software implementation of CPU hardware
It shouldn't, and these days I don't think most people make that association anymore. Environments can be emulated as well.
A native API wrapper/implementation. Wine doesn't emulate a cpu instruction set and therefore isn't an emulator.
I believe that sentence requires its own article here on slashdot!
No, an emulator is a tool for emulating a cpu instruction set. Wine is just a reverse engineered win32 api implementation.
It should and it does. What you are referring to is just a clone.
Right, the problem is the flavor of development you've chosen requires you to either hire non-windows devs who will have to struggle with all this windows nonsense, or windows devs who will feel hamstrung. Either way your staff is going to complain endlessly about the toolset.
It seems that jargon nuance is lost over time. The term emulator in technical jargon refers to something emulating a separate machine code instruction set or other hardware. The JVM itself is an emulator, emulating an invented instruction set. Wine has grown into more than an API implementation but at most you could call it a windows "clone" much like FreeDOS is a dos clone, Minetest is a Minecraft clone, and Openoffice is a MS Office clone.
Keeping the nuance allows us to effectively communicate the difference between these things expediently among one another but more and more the waters get muddied by the common English definition of emulate. This jargon developed for a reason. The common English definitions do not cover these technical distinctions, they are too generic.
The utility for "emulator" is far from obsolete or past. An emulator would run windows not pretend to be it. We use emulators for game consoles, for thousands of arcade systems, for mobile development, etc and emulators will always offer theoretically improved compatibility vs clones while clones will have theoretical performance advantages.
The performance of an application ported through WineLib is going to be identical to the performance of the Windows binary running through Wine.
Only if the libraries are as fast or as feature-rich as they are under Windows. For instance, if there are certain graphics routines that take advantage of particular hardware features or GL routines, but they are not available or poorly implemented in the wine libraries, then a problem will likely run slower than it would under Windows. It could cause graphical corruption, or the program might just instead fall back to doing graphics routines in software instead of hardware. Or it might just crash. Or all three. :-)
I played World of Warcraft for six years using just wine (and/or cedega, back when that was a thing). Eventually I just ran it on Windows instead.
It seems that jargon nuance is lost over time. The term emulator in technical jargon refers to something emulating a separate machine code instruction set or other hardware
This is simply not true. Even in the '70s the term encompassed a lot more. There's a reason that the term 'machine emulator' was in common usage for a while. It's only recently that 'emulator' has been shorthand for 'machine emulator'.
The JVM itself is an emulator, emulating an invented instruction set
No it isn't, because for something to be an emulator there must be something that it is emulating. If the emulated thing does not exist, then it is a simulator not an emulator. The JVM isn't even that, it is a virtual machine.
I am TheRaven on Soylent News
Emulate does not in a broad sense mean anything. There is the common language definition which has little relationship to the technical jargon in which emulator has a very specific meaning of a technical implementation which emulates machine code. It is a useful distinction because an emulator offers higher potential theoretical compatibility vs a clone which is what wine is now (it was once an api implementation which is just a library but has grown to encompass several apis now). An emulator does not "pretend to be" windows in any fashion, it very specifically replicates the machine code of the underlying computer windows run on, a complete emulator would run windows.
The importance of the distinction still exists and I fight for keeping the technical jargon term emulator pure. Wine was once an api implementation, now it is better called a clone. A clone offers the theoretical potential of native performance whereas an emulator trades performance for theoretically perfect completeness. Neither generally delivers on those theoretical potentials but in practice they do generally have superior performance/completion relative to one another where you find both approaches taken to a problem.
" 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.
Go fuck yourself, you entitled little shit. The only person I'm looking out for is number one because that's the way the world works, that's the way the game is played. If you want something, get off of your lazy niger ass and do it for yourself. Nobody owes you a god damned thing.
And another 82 duplicate articles.
(Score: -1, Stupid)
People like you deserve to die alone, broke and without a friend in the world.
The technical definition of emulation is "when one system performs in exactly the same way as another" - there is no requirement that the two systems have different ISAs.
If a compatibility layer is enough to deliver identical behavior (which in fact WINE doesn't) then it is emulating the other system.
You guys fail at trolling. You're supposed to make a half politically correct statement that offends two groups in such a way that they end up flamebaiting each other.
My favorite one liner to do this is: "Abortions are ok so long as they're only for minorities."
AC trollers are funny though. Just ride the trollercoaster (or the trolley, whichever you prefer.)
It probably does. For a long time it was thought to be on 30th December this year when 5703999 would expire, but then it was noticed that they had added 20 years to date of grant, rather than 17 years and come up with the wrong date. It is either 20 years is from date of filing, or 17 from date of grant which ever is the longer. So that has expired.
There are just two patents left 6185539 which expires on the the 19th February and 6009399 which expires on the 16th April 2017. I have had this date in my diary for a long time now.
The last decoding patent expired in September 2015 which is why it has been added to Fedora.
http://www.osnews.com/story/24...
Note that MPEG2 will probably become patent free next year as well. Though this requires you to note that the standard was released in 1996 so anything filed after that is invalidated by the prior art in the standard and was improperly issued. So while the last patent 7334248 expires in 2026, it was first filed in 2002 and should never have been issued. However it probably needs a current licensee with some big Cahoonas to stop paying the license fee and invite the MPEG-LA to sue and get a ruling that the patents are not valid.
AC trollers are funny though. Just ride the trollercoaster (or the trolley, whichever you prefer.)
I like really well-crafted trollings, but the above felt lazy.
Only if the libraries are as fast or as feature-rich as they are under Windows.
That's true when comparing Wine to Windows. But this thread is comparing Wine to WineLib and they both use the same libraries.
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.
It is the wineserver that handles all accesses to the registry. For that reason and many others, there is no way you're going to start a Wine or WineLib process without it. So it really makes no difference either way.
Once compiled there is no more difference between a WineLib process and a Wine one than between an a.out process and an elf one. Probably even less since in both cases you have all the PE structures (since some applications access them directly), only in the Windows executable file the PE-stuff is all alone, while in the WineLib case there's an extra ELF wrapper.
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.
Another point for just running the regular Windows executable.
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.
WineLib is not something distinct from Wine. Rather it's just the source-level compatibility aspects of Wine: are the functions definitions in the right C header files, do they use the right types, can we produce PE executables, etc. WineLib does not have its own libraries: it uses the Wine dlls. So if you package your application with a self-contained Wine environment you can of course pick and choose which Wine dlls you want to package it with. That requires a non trivial amount of work though and it's not going to impact performance, just disk usage which nobody care much about these days. The latter is particularly true for games since they are typically multi-GB beasts these days while a full Wine is under 0.15GB.
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.
The things you care about for games are the X and OpenGL libraries, and graphics driver (including the Linux kernel part) and you cannot package those with your game. Also, as stated before there's no difference between Wine and WineLib there.
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.
True. The ISV would typically do that by modifying the source code and producing a Linux-specific Windows binary thus side-stepping all of the toolchain changes. He would then package the resulting Windows executable with Wine as stated before (or have someone like CodeWeavers package with CrossOver). In some extreme cases he may end up developing a Wine dll (i.e. a WineLib dll as all Wine dlls) to interface in some way with Linux and use the API provided by that dll in his game. That's pretty rare though.
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.
You're mixing up buying the standard Windows game and running it through Wine with no involvement on the part of the game studio, and buying a Linux or Mac game that has been ported using Wine rather than WineLib. Of course in the first case the game studio is not going to know you're running their game in Linux or Mac since, as far as they know, it only runs on Windows. But if they made a port with Wine it's up to them to decide
And even they did use #import, it's easy to fix since #import generates the source code for itself so just compile that instead.
That's just not workable. First it means you still need the Windows toolchain to generate the source that you will then have to transfer to Linux to compile. But then it means your Linux developers will not be able to modify the code they compile because it's auto-generated code and any change they make will be lost the next time around. So if they find a bug or need to make a change they will have to find the matching original source file, make the change there, use the Windows toolchain to regenerate the source code, transfer to the Linux build machine and rebuild. It's too cumbersome.