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.

Comments

Wine

[Anonymous Coward]

Is NOT an emulator.

Re:Wine

[Mr0bvious]

Who said it was?

Re:Wine

[Anonymous Coward]

Wine Is aN Emulator

Re:Wine

[ArmoredDragon]

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.

Re:Wine

[dbIII]

It's a bunch of libraries to get called instead of the MS ones.
Either that or a series of tubes :)

Re:Wine

[Anonymous Coward]

It's a bunch of libraries to get called instead of the MS ones. Either that or a series of tubes :)

Your post was a series of blacks shooting each other. That is, after all, what blacks do. The black males shoot other black males at astonishing rates while claiming that every problem is Whitey's fault. The black females breed like rabbits to more than replenish the population loss. I mean, cranking out kids is much more feasible when WIC/EBT/welfare means you don't have to worry about how to pay for them. Black on black violent crime is far worse than racist whites ever dreamed of doing. It's a problem of scale. In their native African habitat, this is a check against overpopulation. In white nations, where there is law enforcement, this check is only partially effective, so the blacks continue to multiply. It is actually white action that is keeping the black population as high as it is. Left to their own devices, there would be only a fraction of the current population of blacks. "Warlords" is the model they tend to follow, which means a high-ranking gang leader is effectively a local warlord. At least until his second-in-command shoots him and takes over. Ah, nothing like the peaceful hand-off of power right?

But they are our equal. Even though they haven't contributed shit to technological advancement compared to whites and Asians. Somehow, they still are our "equal", and if you question that based on an honest assessment of their achievements, well then you are a terrible person, we will brand you with the label "racist" which means we don't have to listen to you anymore. Whew! After all, your objections were uncomfortable and hard to honestly answer. So, relieved of the burden of listening to honest skepticism, we may now declare them equal, perhaps with weasel words like "disadvantaged' added in.

I mean if you really REALLY want a mind trip, consider that the "first humans were out of Africa". Understand? That means that black people have been around for THOUSANDS OF YEARS longer than whites. Whites had LESS TIME and yet have greatly surpassed blacks in technological and sociological achievements. That means, on a level playing field with an equal start, blacks would be even FARTHER BEHIND. If they were truly so equal, blacks should be operating space stations around Mars by now, while whites work out the whole Iron Age deal. Instead, black culture stagnated for ages while whites achieved new breakthroughs. I am glad that "the first people were blacks from Africa" is such a trophy for blacks. So then, viewed fairly, with such a long head start, why are they not the advanced ones? Why are they the lowest class of any society? When other groups such as the Asians, the Native Americans, and the Jews have also faced terrible persecution? It's as though they are not so equal, after all. Of course, no one can prove this wrong, no one can find a fallacy, they will just declare it "-1, Uncomfortable" and ignore it. Cowards.

Re:Wine

[Anonymous Coward]

u don't belong on this earth

Re:Wine

[Anonymous Coward]

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.

Re:Wine

[Anonymous Coward]

Wine is a shim.

Re:Wine

[Anonymous Coward]

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.

Re:Wine

[Anonymous Coward]

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.

Re: Wine

[Anonymous Coward]

not for you to decide, chimp. Go back to india and finish evolving out of street shitting chimp.

Re: Wine

[Anonymous Coward]

Chimps leech on idiots like you making life "great for everyone". Their mission is to colonize america and render others extinct by exploiting social and security services.

Re:Wine

[jabuzz]

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

Re:Wine

[Anonymous Coward]

"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.

Re:Wine

[DrXym]

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.

Re:Wine

[TheRaven64]

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.

Re:Wine

[Anonymous Coward]

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.

Re:Wine

[fgouget]

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.

Re:Wine

[fgouget]

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#.

Re:Wine

[petermgreen]

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.

Re: Wine

[Anonymous Coward]

So it sounds like building on wine gives you more portable and robust code that is not as tied to Microsoft propritary "shortcuts."

Re:Wine

[Anonymous Coward]

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!

Re: Wine

[Rakarra]

Meanwhile, AC trollers just shitpost all over everyone. I think I know which I prefer.

Re:Wine

[Rakarra]

"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.

Re:Wine

[shaitand]

A native API wrapper/implementation. Wine doesn't emulate a cpu instruction set and therefore isn't an emulator.

Re:Wine

[freeze128]

Only 82 days left till the last of the MP3 patents expires...

I believe that sentence requires its own article here on slashdot!

Re:Wine

[shaitand]

No, an emulator is a tool for emulating a cpu instruction set. Wine is just a reverse engineered win32 api implementation.

Re:Wine

[shaitand]

It should and it does. What you are referring to is just a clone.

Re: Wine

[shaitand]

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.

Re:Wine

[shaitand]

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.

Re:Wine

[Rakarra]

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.

Re:Wine

[TheRaven64]

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.

Re:Wine

[shaitand]

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.

Re:Wine

[shaitand]

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.

Re:Wine

[shaitand]

" 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.

Re:Wine

[DrXym]

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.

Re:Wine

[Anonymous Coward]

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.

Re:Wine

[bheerssen]

And another 82 duplicate articles.

Re:Wine

[Anonymous Coward]

People like you deserve to die alone, broke and without a friend in the world.

Re:Wine

[Anonymous Coward]

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.

Re: Wine

[ArmoredDragon]

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."

Re: Wine

[ArmoredDragon]

AC trollers are funny though. Just ride the trollercoaster (or the trolley, whichever you prefer.)

Re:Wine

[jabuzz]

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.

Re: Wine

[Rakarra]

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.

Re:Wine

[fgouget]

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.

Re:Wine

[fgouget]

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

Re:Wine

[fgouget]

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.

6,600 bugs

[Anonymous Coward]

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 1.0

[Anonymous Coward]

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.

But does X now work with it?

[Is Don the new Ron]

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.

Re:But does X now work with it?

[ArhcAngel]

I hear it runs Cygwin so there's that.

Re:But does X now work with it?

[93 Escort Wagon]

I hear it runs Cygwin so there's that.

I'm trying to figure out why the heck anyone would want to do that, since both Mac and Linux offer a complete (and superior) shell already.

Re:But does X now work with it?

[mrvan]

I hear it runs Cygwin so there's that.

I'm trying to figure out why the heck anyone would want to do that, since both Mac and Linux offer a complete (and superior) shell already.

It's called a joke, you might want to read up on that :)

Re:But does X now work with it?

[mukinrestak]

Ooooh, Civ 4 Complete. No more booting into Windows for Fall From Heaven 2!

Re:But does X now work with it?

[MachineShedFred]

$ man jokes
No manual entry for joke

Nope, no help for you there either.

Re:But does X now work with it?

[alantus]

bash$ wine man jokes
fixme:service:scmdatabase_autostart_services Auto-start service L"Lotus Notes Single Logon" failed to start: 2
wine: cannot find L"C:\\windows\\system32\\man.exe"

Re:But does X now work with it?

[Anonymous Coward]

Never trust a computer you can't throw out a window.
-Steve Wozniak

Re:But does X now work with it?

[hcs_$reboot]

I'm trying to figure out why the heck anyone would want to do that, since both Mac and Linux offer a complete (and superior) shell already.

Because Cygwin now includes Wine as well.

Re:But does X now work with it?

[MichaelSmith]

But can Cygwin run wine?

Re:But does X now work with it?

[Anonymous Coward]

I'd rather use Microsoft's Linux emulation layer or even Cygwin than Apple's outdated and broken "Unix"

Re: But does X now work with it?

[MikeFM]

Obviously you've never tried. MacOS' Unix bits are pretty stable and function as expected other than a bit of changes here and there such as in how stuff is configured. Cygwin, Microsoft's own Linux-bits port, or one of the many other efforts such as what you get with Git are all pretty buggy and can vary wildly. I'm glad Microsoft is finally making the effort but it's still very rough. Often crashes the entire computer and lots of common functionality is just missing as if they compiled everything for maximum lameness. Don't quite see the point of Wine but then I don't use Desktop Linux for serious work anymore as, after decades of trying, it just never got to a truly usable state and even tended to get worse. Combined with how awful most Windows apps are I can't imagine wanting to run a Windows app on a Linux desktop.

Re:But does X now work with it?

[Anonymous Coward]

But can Cygwin run wine?

You might think you're smart sonny, but it's wine all the way down!

Re: But does X now work with it?

[Ash-Fox]

I read your comment and it just sticks out to me like a sore thumb. I genuinely don't understand your experience. I get the distinct impression you haven't ever had the ordeal of trying to port unix applications over to macOS or worked on teams that maintain macports/darwinports/brew and tried to trace down all the stack traces from crashing POSIX userland and developing macOS specific patch fixes. In which case, I wonder what your actual experience in this really is?

MacOS' Unix bits are pretty stable and function as expected

As a user of macOS calling out people saying they haven't tried, I don't know how you missed that it can't even fork() without exec() (as in, it crashes the application), nor handle pthread events in the correct order (violates standards and causes application crashes) and SIP breaks stated unix permissions identified on the filesystem and even returns the wrong error. All of these by the way are required by the certification macOS was supposed to be certified for, but it's clear their testing for compliance was insufficient. The most hilarious thing about this is that the POSIX subsystem for Windows, Linux etc. have no problem following.

That's just scratching the surface on macOS's poor unix support which has required a wide variety of special platform dependent changes (more than others) for cross platform Unix software when compiled for macOS for a reason.

Microsoft's own Linux-bits port

I use Microsoft's (poorly named) "Bash on Ubuntu on Windows" and it emulates a Linux kernel's standard syskernels with ELF binary support in a seperate windows subsystem. It runs an Ubuntu userland (no special executables, these are the same repos used for the official distro) and while there is lack for a few things I consider like IPv6 support or a native xserver (you can at least a win32 x11 server like xming just fine though -- although not much different from needing xquartz on Mac to do the same thing), it runs pretty and well and the kicker is, the issues I described above with macOS's unix support do not exist, meaning that this subsystem is more UNIX and POSIX compliant than macOS is.

Often crashes the entire computer

Cygwin or Microsoft's efforts on POSIX commonly crash the entire computer? I don't really believe you. I can't even think of the last time I saw a userland / ring-3 application from Cygnus or Microsoft crash the entire system, nevermind "often".

Re:But does X now work with it?

[Anonymous Coward]

Try:
man systemd

Re:But does X now work with it?

[Anonymous Coward]

Can it now run the Microsoft spyware? How else is the user experience to be improved if the user data is not sold to Microsoft's corporate customers?

Re:But does X now work with it?

[michael_wojcik]

I hear it runs Cygwin [winehq.org] so there's that.

Yeah, but will it run Hercules under Cygwin under WINE under Linux?

If I had an x86 emulator that ran under zLinux, I could run Hercules under Cygwin under WINE under Linux under x86 emulation under zLinux on a System z. Then I'd really have something.

I think I last used WINE around 1995. It worked for a few things. Since then I've gone to running the preinstalled Windows as host OS and running Linux in a VM, because I'm too lazy to back up the Windows installation and switch to booting Linux as the host. But as Win7 goes out of support I'll probably switch back to native-Linux machines, at least for personal use, and then it might be worth checking WINE out again.

Re: But does X now work with it?

[Anonymous Coward]

Citation needed.

Re: But does X now work with it?

[Anonymous Coward]

it can't even fork() without exec() (as in, it crashes the application)

fork(); printf("Ash is full of shit because this works\n");

nor handle pthread events in the correct order (violates standards and causes application crashes)

There is no guaranteed order of thread execution, your threads are synchronized, or not.

SIP breaks stated unix permissions identified on the filesystem and even returns the wrong error

Not standard unix permissions: chattr +i, selinux
But all three return EPERM.

All of these by the way are required by the certification macOS was supposed to be certified for, but it's clear their testing for compliance was insufficient.

You want to talk about unix standards, but based on this display so far I imagine your face would melt if you had to port software between actual unix systems like AIX, Solaris or HP-UX. They don't work exactly like Linux does either... shocker.

Re: But does X now work with it?

[Ash-Fox]

fork(); printf("Ash is full of shit because this works\n");

More specifically, the crash is a result of the fact that macOS cannot guarentee the libraries you are using are async-signal-safe. POSIX demands that you are able to guarentee a process can be forked at anytime, even in a signal handler.

There is no guaranteed order of thread execution, your threads are synchronized, or not.

It's true, there is no guarenteed order of thread execution, but I said 'events'. If my thread sends back events '1,2,3', I expect to recieve '1,2,3', not '3,1,2'. There is nothing in the pthread specification that allows this behaviour and I don't care for the sloppy libc workaround.

Not standard unix permissions: chattr +i, selinux
But all three return EPERM.

I was actually thinking about the incorrect use of EACCES for non-file permission related activites when opening related files in RAW mode, which has confused ported applications to get into a root access request loop.

I imagine your face would melt if you had to port software between actual unix systems like AIX, Solaris or HP-UX.

Well, you'll be suprised to learn it was fun and paid well. I have ported c applications from SunOS 5.8 to Solaris 9 and rewrote some Cobol applications from HP-UX systems (which were very system dependent designed, so took a fair bit of learning) into Java (where the only system dependent functionality was a file drop location).

But this is different from where someone says, "MacOS' Unix bits are pretty stable and function as expected other than a bit of changes here and there such as in how stuff is configured".

They don't work exactly like Linux does either... shocker.

You misunderstand, when I talk about UNIX or POSIX compliance, I am referring to the UNIX 03 certification that Leopard originally passed which includes POSIX compliance in it's specification (although, I believe it shouldn't have passed due to the tests performed were insufficient to detect all of it's incorrect behaviours).

Re: But does X now work with it?

[Ash-Fox]

Citation needed.

You can verify the correct behaviours macOS should be following for UNIX and POSIX in the UNIX 03 specification.

But can it run Linux?!

[edtice1559]

But can it run Linux?!

Re:But can it run Linux?!

[filesiteguy]

LOL

Re:But can it run Linux?!

[zoid.com]

I'm thinking that you run virtualbox on wine and you are good to go.

Re:But can it run Linux?!

[KiloByte]

But can it run Linux?!

This isn't a stupid question -- WSL processes can not exec a PE. On the other hand, on my system, with qemu and wine binfmts, arch-test reports:
alpha amd64 arm arm64 armel armhf hppa i386 m68k mips mips64 mips64el mipsel powerpc ppc64 ppc64el sh4 sparc sparc64 win32 win64 x32
and you can run processes for any of these archs from any other, completely transparently.

On the other hand, in WSL you can start amd64 Linux ELFs and nothing else. A compat layer on Windows that can't even interact with Windows -- what's the point?

Re:But can it run Linux?!

[TheRaven64]

On the other hand, in WSL you can start amd64 Linux ELFs and nothing else. A compat layer on Windows that can't even interact with Windows -- what's the point?

You can, at least, interact with the filesystem, and I think some forms of IPC work between the Windows and Linux worlds. This isn't new for Windows: NT 4 had a POSIX compatibility layer that, like WSL, was a separate OS personality. It implemented the minimum possible amount of POSIX (anything allowed to simply return not-implemented errors did) and gave you a completely distinct set of APIs. But it let them tick the checkbox...

X11 makes this easier on *NIX systems because it's intrinsically designed for remote display, so all of the communication is via well-defined IPC mechanism. If you run a Linux binary on FreeBSD, the Linux system calls are translated into FreeBSD ones at the syscall layer (in a similar way to how WSL works), but the UNIX domain socket and shared memory regions that you use for communicating with the X server are the same on both operating systems and so you can easily run graphical Linux and FreeBSD applications that interact with the same clipboard and so on with no interposition.

Re:But can it run Linux?!

[squiggleslash]

More importantly, can it work under "Bash on Ubuntu for Windows" (great name Microsoft!) under Windows 10?

'cos if it can, then there's finally a way to run Alpha Centauri under Windows 10! Hooray!

Re:But can it run Linux?!

[KiloByte]

Yeah, I'd understand high-level communications not working, emulating them right would be a task as hard as wine's -- but on WSL, even basic execve("hello.exe") doesn't work.

Re:But can it run Linux?!

[Thelasko]

But can it run Linux?!

In Soviet Russia, Linux runs Wine!

Re:But can it run Linux?!

[caseih]

I know you're being funny, but no you really couldn't ever run virtualbox on Wine, even if Wine was 99% compatible. Just like the poorly named Windows Subsytem for Linux could not ever run VirtualBox for Linux. Neither system ships with an OS kernel. Rather they translate the system calls into the native kernel. Both systems are really aimed at providing the userspace needed to run these foreign binaries on a foreign kernel.

ReactOS on the other hand is an open-source Windows NT-compatible kernel that borrows from Wine for userspace API support. Some day ReactOS could get to the point where it could run VirtualBox because it has a real kernel with real installable drivers.

Re:But can it run Linux?!

[caseih]

Wine currently depends on certain Linux kernel features to load the COFF binaries that the WSL may or may not have emulated yet. But there's no technical reason Wine couldn't run under the WSL as Wine is a userpace program that doesn't require drivers or ring-0 instructions.

Re:But can it run Linux?!

[edtice1559]

Actually, I would think that VirtualBox for Windows would be something that might run under Wine. If you are using VT-x, much of the code is operating-system independent. There is, of course, no good reason for doing this, but I don't think this would be the biggest stretch.

Re:But can it run Linux?!

[edtice1559]

If you have a really big hard disk, you could make a giant RAMdisk out of virtual memory!

Re:But can it run Linux?!

[TheRaven64]

execve isn't particularly simple. When you do execve on a UNIX system, you're inheriting a bunch of things such as file descriptor tables. In Windows, the process creation mechanism is entirely different.

Re:But can it run Linux?!

[KiloByte]

The STARTUPINFO structure you pass to CreateProcess() has fields hStdInput, hStdOutput and hStdError which do just that. An UNIX process can have more than these three descriptors, but I don't think anyone would expect them to work for a Windows process anyway.

Can it run AutoCAD or Solid Works yet?

[Anonymous Coward]

If not who cares.

Re:Can it run AutoCAD or Solid Works yet?

[Anonymous Coward]

WTF? You'll pay for AutoCAD or SolidWorks, but are too cheap to buy Windows? You deserve what you get, I guess.

Re:Can it run AutoCAD or Solid Works yet?

[slacka]

Yes it can. Some of the Engineers at my office used to run SolidWorks 2012 on CrossOver. Looks like Wine runs it with some workarounds:

https://appdb.winehq.org/objec...

Re: Can it run AutoCAD or Solid Works yet?

[Anonymous Coward]

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.

Re: Can it run AutoCAD or Solid Works yet?

[Anonymous Coward]

Are you saying that Microsoft is stealing your dubstep mix tape and using it for something?

Re:Can it run AutoCAD or Solid Works yet?

[Narcocide]

If not who cares.

Well, World of Warcraft stopped working in the old version about 2 days after 2.0-rc2 was released, so in reality you don't actually have to go far to find people who care about this.

Re:Can it run AutoCAD or Solid Works yet?

[Anonymous Coward]

This might come as a huge shock to you but most people have zero need for AutoCAD or SolidWorks. Wine runs almost everything that 99% of users want.

Re: Can it run AutoCAD or Solid Works yet?

[Anonymous Coward]

^^^ does not know what AutoCAD and Solid Works are for.

Re:Can it run AutoCAD or Solid Works yet?

[epyT-R]

Perhaps he wants to run those applications and run his preferred OS at the same time.

Re: Can it run AutoCAD or Solid Works yet?

[Anonymous Coward]

He's replying to the Pro Tools part - Avid Pro Tools the digital audio workstation.

Re:Can it run AutoCAD or Solid Works yet?

[mark-t]

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.

Re:Can it run AutoCAD or Solid Works yet?

[goose-incarnated]

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.

Re:Can it run AutoCAD or Solid Works yet?

[Anonymous Coward]

Because the cost of a licence is the only problem with Microsoft Windows?

Re: Can it run AutoCAD or Solid Works yet?

[Anonymous Coward]

there are people who don't get the comment and move on. since they don't know something, how can they reply to it?

then there are people like you. people who go their whole life entertaining others, without knowing it. they are people who are not super bright, are unwilling to look anything up, but think it's everyone else who is an idiot. nothing can change their mind. the more people make fun of them and laugh at them, the less they notice. this is a weird phenomenon, but I have an explanation - and it comes from walmart.

these people are inadequate and losers in reality. the more facts of this are presented to them, the less these facts matter to them. It's the brain's way of preventing depression. if the brain presented the world to them as it really is, these people would blow their brains out. you ever see a fat chimpbitch being loud at the walmart, draped in hot pink spandex, rolls popping out, ass dimples and cameltoe housing small families of hairy midgets (turks). she really does think she's sexy and hot, and that everyone wants here. the more people laugh at her, the harder her brain has to pump her with fake confidence in order for her to simply survive.

how ya doing fat bitch?

Re: Can it run AutoCAD or Solid Works yet?

[Anonymous Coward]

Sounds a lot like Trump if you think about it.

Re:Can it run AutoCAD or Solid Works yet?

[Anonymous Coward]

Who says you actually paid for AutoCAD and SolidWorks?

Re:Can it run AutoCAD or Solid Works yet?

[freeze128]

Well, it might have a LITTLE to do with price...

Re: Can it run AutoCAD or Solid Works yet?

[thegarbz]

I'm guessing that WINE doesn't leak users (design) data back to Microsoft?

Neither does Windows which does not tie into specific applications to leak data.

And even if it did, no one will find it in the clusterfuck that is Microsoft user data. It's probably the best and most secret place to store your data.

Re:Can it run AutoCAD or Solid Works yet?

[Anonymous Coward]

Then you are the odd one out, sorry to say.

Re:Can it run AutoCAD or Solid Works yet?

[mark-t]

Perhaps so, but that doesn't mean we won't wine (hah!) about it.

Seriously though, just because one happens to be in a minority, should that mean their concerns are not worthy of consideration?

Is Wine an emulator yet?

[sims 2]

Is Wine an emulator yet?

Re:Is Wine an emulator yet?

[Anonymous Coward]

No.

Re:Is Wine an emulator yet?

[Kargan]

No of course not!

Wine
Is
Not
Emulated

Win10 alternatives

[thygate]

i'm seriously contemplating buying a mac book, I would love nothing more than to be able to dump MS completely since Win10.

Re:Win10 alternatives

[Anonymous Coward]

I ditched windows long ago for linux and never looked back.

Re:Win10 alternatives

[thygate]

Visual Studio and gaming are the only things that kept me buying windows boxes. Win7 was awesome, wtf happened ?

Re:Win10 alternatives

[vux984]

That like jumping out of the frying pan into another frying pan. OSX and windows are just playing leapfrog with eachother.

Microsoft account to sign in... OSX had their version of that first.

All your updates in one lump instead of individual patches... OSX had it first, and doesn't even let you roll back either. full restore from backup or re-image from scratch are you options.

App store? OSX had it first; and even defaults to settings that only allow using it.

Having the local search hooked up to Bing? Another feature of OSX... that was around back in OS9 if not even earlier.

So... Microsoft has telemetry? You really trust Apple won't copy that?

Re: Win10 alternatives

[Anonymous Coward]

Yep.
Did that in 2001.
Dumped microshaft for linux. Never looked back.
Poor pathetic bastards still addicted to that bastard of an OS.
Left linux for FreeBSD an couple years back when Debian was about to be adulterated with systemd.
And again, not much need for linux either, anymore.

Re:Win10 alternatives

[epyT-R]

Hipsters and mobile crapware. Microsoft wanted to emulate them. As usual, they've done a poor job.

Re: Win10 alternatives

[Anonymous Coward]

Oh and,
Wine workes just fine on FreeBSD.
Looking forward to installing wine 2.0.

Re:Win10 alternatives

[Anonymous Coward]

Parallells is cheap and awesome.

Re:Win10 alternatives

[Drinking Bleach]

So... Microsoft has telemetry? You really trust Apple won't copy that?

Apple had it first as well.

Re:Win10 alternatives

[fisted]

I ditched Windows long ago for Linux and never looked back -- mostly because I ditched Linux for NetBSD shortly thereafter (and still never looked back).

Re:Win10 alternatives

[fph il quozientatore]

And then people say Apple does not innovate and just copies ideas other people had. Take that, haters!

Re:Win10 alternatives

[Anonymous Coward]

The default for OS X is to only allow signed applications to run, this includes application that are not distributed by the app store.

Re:Win10 alternatives

[Ash-Fox]

The default for OS X is to only allow signed applications to run, this includes application that are not distributed by the app store.

I work around it by giving my Mac users a command ( to copy paste into a terminal (opened through spotlight with exact instructions) that automatically downloads and installs the given unsigned software they need to use. It's basically a shell script that sets it up locally, bypassing the restrictions, command is just something like:

curl -fsSL http://server/script.bsh | bash -e

I've found many Mac users otherwise just find it hard to do things like downloading a .dmg and copying the package to the Applications path, nevermind right clicking (be it two fingers on the mouse or control + click) and choosing 'open' for something unsigned. Adding Applications to the Dock also seemed to be another difficulty some couldn't wrap their heads around. Using a script also saves me the drama of trying to get them to find the correct version for what version of macOS they're using.

Re:Win10 alternatives

[Anonymous Coward]

All of those features you've listed, the user is free to turn off or ignore.

Re:Win10 alternatives

[Anonymous Coward]

"App store? OSX had it first; and even defaults to settings that only allow using it."

This is false. macOS will stop you from running unsigned apps but you don't have to go through the App Store in order to do that. After all there are tons of big applications for OS X that aren't available in the App Store.

You fucking liar.

Re:Win10 alternatives

[petermgreen]

Afaict MS has seen the writing on the wall.

People are replacing their computers less often and spending less money on each computer. When a computer costs $1000 a $100 or so windows license is tolerable, when a computer costs $200 it is much less so.

To discourage sellers of low end computers pushing Linux and/or potential purchasers of low end computers buying smartphone like tablets instead, MS has been practically giving away windows for low end computers. That helps to keep people in the windows ecosystem but it further errodes revenue.

So MS has been trying hard to reinvent themselves. With win8 they tried to push a tablet OS on desktop users, presumablly in the hope that doing so would help them capture the target market. With win10 they seem to be trying to reinvent windows into a platform they can use to push their online services.

Re:Win10 alternatives

[vux984]

"You fucking liar."

Touched a nerve?

"This is false. macOS will stop you from running unsigned apps but you don't have to go through the App Store in order to do that. After all there are tons of big applications for OS X that aren't available in the App Store."

You're right of course. However, there are a ton of small and F/OSS applications that are not signed. I run into the warning dialog boxes about it all the time.

The funny thing here is that if Windows implemented a feature that required signed apps by default people would collectively lose their shit over it. Yet Apple's already done it.

And apple's been turning the screws... they've already outright removed the option to run apps from anywhere... the only choices in sierra are 'app store' or 'app store plus signed apps'. You can still run unsigned apps, but the screws are slowly being tightened.

Re:Win10 alternatives

[Blaskowicz]

Well, long ago Microsoft implemented an "Are you sure?" when you run an .exe you downloaded from the web to your dekstop.
They do like the "Are you sure?" method a lot - it basically gives you root on most people's running and not-locked desktop session (friends and family etc.), at least on Windows 7.
People did complain about Windows not running unsigned drivers. Otherwise, Microsoft has been most interested in locking down their themes. Like removing the color schemes in Windows 7's classic mode. One of the worst Windows 7 "features", I hate that lol.

Re:Win10 alternatives

[ilsaloving]

The big difference is that Apple's updates don't have better than even odds of hosing your computer, unlike Microsoft who manages to brick people's computers on a routine basis.

As far as privacy goes, Apple has said repeatedly on multiple occasions that user privacy is a primary concern. I can't speak to the future obviously, but up till now, an OSX machine sends nothing to apple that the user doesn't allow. People have even tested this, and verified it. Don't want anything going to Apple? Don't sign into iCloud. Don't use Siri. Disable all that stuff and not so much as a single byte gets sent to Apple. At this point I am inclined to take Apple at their word that they will continue doing what they're doing until such time as they demonstrate they've changed their mind.

The pre-configured defaults are just fine for people who don't know what they're doing, but every single one of them is bypassable by anyone with technical skill.

Just to pick out a particular item you mentioned, Gatekeeper (the thing that doesn't allow you to use apps outside the app store) is a fantastic security tool. If a user doesn't know what they're doing, they are basically shepherded to the app store where everything is curated, validated, and reasonably safe from malware. If you want to run apps outside the App Store, it's just a setting away, and still only permits signed applications from official developers. If you download some open source application from sourceforge and you really want to run it? You right-click and choose Open. It gives you a one time warning of "Are you sure?", and after that you can open it freely like any other application.

As a sysadmin, and as someone who has to do tech support for family members who really ARE confused by left and right mouse buttons, this sort of functionality is a godsend because it protects users from themselves, while still allowing those with the knowhow to do what they need to do.

There are other things about OSX that bug me, but privacy isn't one of them. At no point have I ever been concerned that Apple is going to sneak into my machine while I wasn't looking and start siphoning files from my hard drive, as Microsoft has the ability to do.

Now if only their hardware division would pull their thumb out... :\

Re:Win10 alternatives

[ilsaloving]

This is news to me. Do you have a link?

Re:Win10 alternatives

[vux984]

The big difference is that Apple's updates don't have better than even odds of hosing your computer, unlike Microsoft who manages to brick people's computers on a routine basis.

On the other hand when apple updates to hose your computer, there is no rollback. And windows has a gazillion possible hardware configurations to cope with... Apple has tiny number.

And I've been through plenty of Apple's abortions. I had a 17" macbook pro that ran like molasses and couldn't hold a wireless connection after updating to snow leopard. As for windows update? Yeah, i've seen a few fails too. Although with 40x the marketshare who is surprised?

On ios where apple has a nice fat marketshare and only a dozen supported skus... we hear PLENTY of ios update woe.

As far as privacy goes, Apple has said repeatedly on multiple occasions that user privacy is a primary concern.

Yeah. You are right. Apple is currently better on privacy. Apple is however a hardware company that is transitioning to a services company... as that transition continues, I'm skeptical they'll hold fast.

Just to pick out a particular item you mentioned, Gatekeeper (the thing that doesn't allow you to use apps outside the app store) is a fantastic security tool.

I don't dispute that. But if Windows were to do the same hting it would not be heralded as a fantastic security tool... it would be pounced on as a deplorable act to lock people into the app store, kill steam, kill open source, etc etc. Even if it were the same exact thing.

I'm not railing against apple here, but i don't like the double standard. I think driver signing was a good move for windows. I think secure boot ... despite the potential for abuse was a good move. I think UAC was a much needed move. Think curated appstores are godsend for naive users. But I worry that both Microsoft and Apple are too greedy for lockin to suffer any store but their own as soon as they can get away with it.

Apple launched ios with one app store, and hasn't budged. That should tell you where they want to be. And the only reason OSX allows anything else is it would be rejected out of hand if they didn't... but they're gradually turning the screws... they want 30% of ever sale on the desktop, they want everyone who programs to have a registered and paid for developer account... that's there clear endgame, and they are slowly but surely taking us there.

I'm not saying Microsoft is any better. I see them both inching their way there, each hungrily watching the other to see how much further they get away with pushing users into the walled garden with each step.

So, yeah, Gatekeeper is a fantastic tool right now... but since its release to today they've already steadily made it less and less 'optional'. I am far to realistic to beleive they'll allow it to be optional for one minute longer than they have to.

Now if only their hardware division would pull their thumb out... :\

Don't even get me started... :\

Re:Win10 alternatives

[ilsaloving]

I pretty much agree with everything you're saying. I just wanted to address one thing:

Apple launched ios with one app store, and hasn't budged. That should tell you where they want to be. And the only reason OSX allows anything else is it would be rejected out of hand if they didn't... but they're gradually turning the screws... they want 30% of ever sale on the desktop, they want everyone who programs to have a registered and paid for developer account... that's there clear endgame, and they are slowly but surely taking us there.

Having a single curated app store is not necessarily a bad thing. Android has demonstrated quite well just how much of a clusterfuck alternative app stores can be. It takes work to vet all those applications, and I'm sure you know as well as I do, just how lazy people can be. The fact is, we've seen what happens when people are given freedom. It's a foregone conclusion that they can and will fuck it all up, and that's why we can't have nice things.

As annoying as it is to be at Apple's (or MS or Google) beck and call, it does enforce a minimum level of quality that ultimately is in the best interest of the consumer buying the apps. Hell, look at what Google's app store was like before they finally started turning the screws themselves. Shockingly poor quality software. Malware everywhere. It's so much better now than it was a few years ago.

Re:Win10 alternatives

[vux984]

Having a single curated app store is not necessarily a bad thing. Android has demonstrated quite well just how much of a clusterfuck alternative app stores can be.

Yes and no.

It also demonstrates their benefits. I currently use 3 "stores" on my android. Google's, F-Droid, and the HumbleBundle app. The lack of fdroid and the humble app are major minuses to the Apple ecosystem.

I compare it to the real world of brick and mortar. There are lots of stores -- some of them are hole in the wall fly by night, and some of them are good.

Just because you CAN go to to some no-name shithole and get totally ripped off with fake goods doesn't mean that walmart should be the only store you are allowed to shop at. That's not 'better'.

Yeah, some segment of the public is inevitably going to buy something in some shithole and walkaway with malware. But most of us don't really have that problem... most of us have figured out the benefits of dealing with reputable places in the real world.

Would you submit to only shopping at walmart for the rest of your life because some mouth-breathing idiot bought a "leather belt" made of cheap plastic at a night market that broke 20 minutes after he put it on?

Re:Win10 alternatives

[ilsaloving]

Humble Bundle has their own store? That's pretty cool! Not that it helps me any, since I have an iPhone.

Logically, what you say makes perfect sense. My argument is that you give people's tech skills way too much credit. Also, it's not just that "some mouth-breathing idiot" did blah blah. It's "a huge portion of the population" did blah blah because they thought they could cheap out and save money.

A perfect and obvious example is batteries. Almost nobody makes devices with removable batteries anymore, because either people specifically sought out cheap batteries, or stores would procure cheap batteries and sell them as if they were the real thing, etc. So basically manufacturers en masse threw their hands up in the air and said "fuck it, we're gonna just build them in so they're not user replaceable". So thanks to the cumulative antics of a huge number of fuckwits, *I* can no longer buy a phone with a replaceable battery even though I am skilled enough to procure a good one.

The software landscape is just as bad, if not worse. Microsoft et al are so concerned about lowering the barrier to entry to maximize the number of people buying their development tools, but they don't give a fig about the end result, which is that a bunch of "developers" who shouldn't be allowed to flip burgers let alone code, write breathtakingly terrible software. The halo effect of all this incompetence ends up hurting people like you and me in completely unpredictable ways, in order to protect people from themselves.

I'm not even sure where I'm going with this. I guess I'm just venting at this point. :P

Re:Win10 alternatives

[vux984]

Humble Bundle has their own store?

https://www.humblebundle.com/a...

Not that it helps you, but yeah, it is pretty cool that it exists. Since it saves you having to sideload any of the humble mobile titles you may have, you just install and update them etc via the app.

I think you are mostly wrong about batteries though. I don't think its cheap knockoffs that were the main issue; although it IS a real issue, and one the manufacturers like to scapegoat.

But I think they took away replaceable batteries because:

  - it lets you go thinner
  - built in obscelesence
  - cheaper
  - batteries last longer than they used to, so the need to replace them has dropped off; so the market for replacements is smaller
  - batteries charge faster than they used to, so the need for infrastructure for swapping batteries, and using external chargers etc, as part of regular usage has died out.

There are lots of forces at work against replaceable batteries.

That said, I don't disagree with your vent about software. A lot of the stuff in the so-called "curated" stores should be relegated to the 'bottom shelf' in the back of the store... where you have to walk past a sign that says beware of the leopard before it shows it to you.

On simply having it "in the store" gives it far more visibility and exposure than it would ever get in a real market.

Re:Win10 alternatives

[ilsaloving]

re: Batteries, I hadn't thought about that. That's a good point.

If I had the ability, I would have just modded you up. But since I can't, I'll just say thank you for the insightful discussion.

Wow, this brings back memories!

[filesiteguy]

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 Asymmetry

[Anonymous Coward]

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."

Re:The Asymmetry

[Anonymous Coward]

Read up on drawbridge, you can run a windows applications with only 68 syscalls. Edge has been sandboxed using this. Using drawbridge you could run windows app on a mac or linux. See https://www.microsoft.com/en-us/research/project/drawbridge/

Re:The Asymmetry

[Anonymous Coward]

Apples and pears, really. The Windows API includes GDI, the Linux kernel does not include X11 or Wayland. The Windows API includes the Service Control Manager, the Linux kernel does not include systemd. In general, the the part that's comparable to the Linux kernel would best be described as the NT kernel.

Still, the NT kernel is bigger, because it supports multiple personalities. That's how you the Linux subsystem for Windows 10 works - just a different NT personality.

But can it run Linux...

[hackwrench]

...well how about the Windows Subsystem for Linux?

Re:But can it run Linux...

[Anonymous Coward]

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.

Re:But can it run Linux...

[hackwrench]

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.

Re:But can it run Linux...

[Anonymous Coward]

There's already Firefox for that.

DirectX, the universal API?

[Anonymous Coward]

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?

Re:DirectX, the universal API?

[epyT-R]

Kinda runs counter to his whole spiel about cutting down latency and api overhead for VR applications.

Re:DirectX, the universal API?

[Drinking Bleach]

Maybe more accurately, the Windows ABI being the universal one thanks to Wine. DirectX can be hit-or-miss, especially if you don't have gallium drivers on your system.

Carmack always used OpenGL for his game engines too, a tradition maintained in Doom 2016 as well, despite being developed and released after his departure. The Vulkan version even runs well in Wine.

underlines!

[tobiasly]

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!

Re:underlines!

[Spacelem]

I've been using Linux exclusively for about 13 years. To me, 2003 was the year of the Linux desktop, and then every year since then.

Just because it hasn't achieved the popularity of Windows or OSX, doesn't mean it isn't just as capable (I've used a MacBook Pro for 4 years at work, and I still haven't been persuaded to make the switch at home). I installed it on my mother's ageing laptop a few years ago, and she's been pretty happy using it since then.

Re:underlines!

[Anonymous Coward]

Capable is a pretty relative term. In my case, "capable" means completely useless for my structural engineering company where I can't work without AutoCAD and Revit, both of which still get consistent "garbage" reviews at the wine database. Same goes for the various custom structural analysis apps we use. I would have switched over to Linux years and years ago if only it was an option. Many people, like myself, are simply trapped.

Re:underlines!

[Anonymous Coward]

Generally the people who work on wine are people who are just interested in running games. Unfortunately that is where all the work is going. Like you, I would like my engineering applications to run under wine. I've been waiting for 20 years. After years of deluding myself that this goal was "just around the corner", I finally woke up and realized that IT AIN'T EVER GONNA HAPPEN. Duh! I could've had a V8!

Can't force people to work on features they aren't interested in. I've resigned myself to the fact that professionally I will not be able to ever fully extricate myself from Microsoft. However Linux has a wonderful selection of maths software that allows you to "roll your own" solutions if push comes to shove (and you have the time and energy--items in increasingly short supply the older I get).

Re:underlines!

[Blaskowicz]

Sometimes the odd thing can run on Wine. E.g., tool to edit a graphics card's BIOS to change the fan speed or clocks etc. ; BIOS is to be downloaded from the Internet or dumped from DOS. Edit your BIOS by running the tool in Wine. Boot DOS from USB (can be MS-DOS) or other means, then flash the modded BIOS to your graphics card.

Perhaps that's a silly example. But a simple, plain application with no particular dependencies or use of features has good chances of working. Like, about any single-author stuff that looks like freeware from the late 90s. How come stuff like that always works? It's like going back to the old days where everything worked (yes that's how I remember the DOS days.)

Re:underlines!

[tobiasly]

I've been using Linux exclusively for about 13 years. To me, 2003 was the year of the Linux desktop, and then every year since then.

Just because it hasn't achieved the popularity of Windows or OSX, doesn't mean it isn't just as capable (I've used a MacBook Pro for 4 years at work, and I still haven't been persuaded to make the switch at home). I installed it on my mother's ageing laptop a few years ago, and she's been pretty happy using it since then.

I completely agree; my remark was just poking fun at the headline which for some reason decided that "drawing underlines" was one of the top features of Wine 2.0.

And yeah, I got fed up troubleshooting my Dad's desktop with Windows, and talked him into buying a System 76 "nettop" with Ubuntu. He's been using it ever since and my support calls have dropped to near zero.

How soon until it is included in ReactOS?

[jfdavis668]

This should bring ReactOS closer to being useful.

Re:How soon until it is included in ReactOS?

[TheRealMindChild]

Not on real hardware

Re:How soon until it is included in ReactOS?

[unixisc]

Why not? What's there about ReactOS that makes it hostile to any of the current CPUs? Also, does wine 2 support Windows 8/10 as far as win64 goes, or is it just Windows 7?

Re:How soon until it is included in ReactOS?

[Anonymous Coward]

Sometimes you warn a child not to put her hand in the fire. Sometimes she will listen. But some children need to find out for themselves.

Why don't you write an article about getting ReactOS to boot and run on current industry standard hardware. Submit it to Slashdot. No doubt, that article would be of interest to many including myself. I kid you not.

ReactOS on current up-to-date hardware? I claim it can't be done.

Re:How soon until it is included in ReactOS?

[Drinking Bleach]

Yes, 2.0 supports Windows 8 and 10 compatibility, both 32- and 64-bit. Actually, Wine 1.8 was the first to include Windows 10 compatibility ;)

Re:How soon until it is included in ReactOS?

[iampiti]

If actually is included in ReactOS.
Well, sort of: ReactOS and Wine already share a lot of code. I believe it's mostly userland DLLs because what's the part that can be shared.
Take into account that both aim (among other things) to implement the Windows APIs but they do it differently:
- WINE on top of Linux APIs.
- ReactOS on top of a Windows NT kernel.
So of course, WINE progress helps ReactOS but the latter also have to implement on their own many os level things (kernel, filesystem support, network stack, USB stack...) that the former doesn't because it takes those services from the underlying OS (Linux or MacOS).

I see what you did there.

[Anonymous Coward]

If Wine was accelerated by Qemu then maybe it would Timothy.

Re:I see what you did there.

[unixisc]

Can wine be a subsystem on top of systemd? In fact, why not have a daemon called windowsd in systemd, just like you have all the other *d?

Re: I see what you did there.

[Anonymous Coward]

You really like the D!

NTTAWWT

Turtles

[raymorris]

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.

Re:Turtles

[Anonymous Coward]

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.

Your predictable joke is n1g.gers all the way down, you know.

6,600 bug fixes?!

[wvmarle]

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

Re:6,600 bug fixes?!

[Anonymous Coward]

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"

Re:6,600 bug fixes?!

[Anonymous Coward]

I'm not sure if it's still true, but Wine historically applied bug fixes which purposefully introduces bugs that exist in the Windows win32 api.
See question 3 of http://www.osnews.com/story/227

Re:6,600 bug fixes?!

[Anonymous Coward]

Please remember that Wine developers don't have a clean fully working specification to do write there code. Large part of the layer between the DLL ans the NT kernel is undocumented and constantly modified by Microsoft.

Word 2013 rated garbage

[watermark]

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?

Re:Word 2013 rated garbage

[hawk]

Yes, we are.

Use _hillary() to create a jail for office . . . :)

hawk

Re:Word 2013 rated garbage

[Gumbercules!!]

Oh that's disappointing. I was really hoping to use Real Office(tm) on my Mac, not that pathetic port version Microsoft still ships for Macs - and yes I am being serious, not sarcastic. Some of the Excel features I really need are missing and the simply fact of not having favourites folders in Outlook is beyond irritating. Parallels is slow as hell.

Re:Word 2013 rated garbage

[Anonymous Coward]

That's because Word and Excel ARE garbage.

Re:Word 2013 rated garbage

[Anonymous Coward]

Funny, the Windows version of Office used to be a pathetic port of the Mac version. How times have changed.

Re:Word 2013 rated garbage

[Anonymous Coward]

That's fucking funny.

TL;DR: Mod up.

Re:Word 2013 rated garbage

[Anonymous Coward]

Spinlock her up!

(captcha: immature)

Re:Word 2013 rated garbage

[ilsaloving]

Well it *did* just get released. Lets give it some time for people to compile binaries and test things out. None of the apps have been yet tested with 2.0

I'm not holding my breath, mind you, but I'm keeping my fingers crossed.

ReactOS to Linux to Wine to Virtual PC

[Anonymous Coward]

ReactOS can do it first!

Is Wine Useful?

[Notabadguy]

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.

Re: Is Wine Useful?

[p91paul]

For 1, absolutely useless, since Chrome has a fully-featured Linux version, never heard reports of Netflix not working on it. About Steam, if your games don't run on Steam for Linux, I think there is no global answer. Some may work, some may not at all, some could work partially. You have to try, and possibly report your findings on the Wine database.

Re:Is Wine Useful?

[Anonymous Coward]

Dear masses,
1. Why? Native clients work for Chrome and Netflix. I suppose I could check but again, why?
2. Often. But since it's not 100% great I guess you'd better just toss it in the dumpster. Let let me know when you do it so I have another computer to play Fallout New Vegas on.

Re:Is Wine Useful?

[preflex]

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.

Re: Is Wine Useful?

[Anonymous Coward]

Tons and tons of games work on Mac. Check out "the porting team" where folks specifically make "wrappers" based on Wine.

Re:Is Wine Useful?

[Anonymous Coward]

Why would you want to use Chrome? There are several much better browsers available for Linux.

Re:Is Wine Useful?

[Anonymous Coward]

Such as...?

Firefox isn't it.

Re: Is Wine Useful?

[Anonymous Coward]

I tried Netflix with Chrome on a Debian amd64 and it simply don't work at all, complaining that the platform is unsupported.

My children uses Stream Windows executable under Wine since many years thanks to PlayOnLinux. Most of the games there tried work well enough, but a few don't. There will certainly try Wine 2.0 this week-end... It's very easy to upgrade with PlayOnLinux.

Re:Is Wine Useful?

[Jahta]

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.

Re:Is Wine Useful?

[Anonymous Coward]

So true. xnews kicks ass.

Re:Is Wine Useful?

[McLoud]

About 2, you might run into driver issues in windows as well (ex: periodic crashing in Witcher 2). On wine, depends on the game. Skyrim (not special edition) runs just fine, including with skse, skyui and the ESB shader stuff

Re:Is Wine Useful?

[Anonymous Coward]

Firefox has been available for Linux from the beginning.

so what ?

[Torvac]

Beer was 2.0 more than 1000 years ago

Re:so what ?

[Anonymous Coward]

> Beer was 2.0 more than 1000 years ago

In my neighborhood, it's up to 3.2.

Re:so what ?

[Anonymous Coward]

Milwaukee's Best ICE has recently been reformulated to 6.9!

Re:so what ?

[Torvac]

you cannot call american pisswater beer even after 2.0

Blizzard launcher

[majorme]

Any word on that? Was a major pain to use their HTML5 based battle.net launcher back in the summer.

Re:Blizzard launcher

[tdailey]

I have been successfully playing SC II using PlayOnLinux with 32 bit Wine 1.9.21 (staging). Required a lot of DLL overrides, however.

It begs the question

[ruir]

Red or white, Pinot, Nebbiolo or what?

No

[Anonymous Coward]

It does not beg the question. Your mum begs for the D, which raises the question "who's your dad?"

Wine 2.0?

[joncombe]

Have they fixed the morning after hangover?

BF3 (Battle Field 3) under Wine

[Trax3001BBS]

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.

Re:

[kurkosdr]

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.

Re:

[kurkosdr]

(i meant no open-source media player obviously)

iTunes

[Tempest_2084]

I just wish iPhone syncing worked with iTunes under Wine, then I could pretty much ditch Windows completely.

Re:

[Wootery]

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.

None of you

[Anonymous Coward]

Can duel boot I take it.