OS X apps run on Linux with Wine-like emulator for Mac software | Hacker News Reader

OS X apps run on Linux with Wine-like emulator for Mac software

arstechnica.com

66 pointsdagurp21 comments

Open articleView on HN

> Doležel would like to bring Angry Birds, other games, and multimedia applications to Linux.

Who needs real apps when you have Angry Birds? Sigh.

A "Wine is not an emulator"-like emulator? Come on, Ars.

My first thought as well. I just hope this was just one guys fault...

Flies like an emulator, quacks like an emulator, waddles like an emulator: duck-typing says it's a bloody emulator.

I'm not sure it virtualizes an x86 box running Windows like an emulator though.

come on... WINE is a compatibility layer. Nothing gets emulated in any way. You can check the FAQ, a sibling posted the link.

> Nothing gets emulated in any way

Except for the Windows API, including all of its bugs and oddities.

Emulation != Vitualization

> Except for the Windows API, including all of its bugs and oddities.

Back in the day, us of the emulation community would refer to such things as "wrappers" (see, glide[1]). WINE definitely qualifies as a wrapper, as it merely translates one API to another. Darling seems to fit this same definition. Both are handling big API's, but that doesn't make it emulation when you reimplement them.

Wikipedia's definition mentions hardware specifically as a requirement of Emulation [2]. In fact, they go even further to say that any software that duplicates the hardware of another machine should be considered a simulator [3]. This means that WINE and Darling are now twice removed from the Emulation family.

[1] http://www.glideunderground.com/modules.php?op=modload&name=...

[2] https://en.wikipedia.org/wiki/Emulator

[3] https://en.wikipedia.org/wiki/Emulator#Emulation_versus_simu...

It is not an emulator though... It is a reimplementation layer of winapi.

Wine emulates an API, not a CPU or a machine. The original meaning of WINE was WINdows Emulator. [1]

The word "emulator" in tech sometimes acquired an association with CPU or computer emulators. So for whatever reason (joke, marketing, etc.) WINE changed the meaning of the acronym. But it's still an emulator, just an API emulator rather than CPU emulator.

[1] http://www.faqs.org/faqs/windows-emulation/wine-faq/

>So for whatever reason (joke, marketing, etc.) WINE changed the meaning of the acronym.

It's likely they did it for the same reason for which "Windows Commander" famously had to change its name to "Total Commander": to avoid infringing upon Microsoft's trademark. Christian Ghisler got a letter from Microsoft's lawyers about the name of his file manager, though [1]; AFAIK, Wine didn't.

[1] http://www.ghisler.com/name.htm

That's a reference for the name but nothing is actually emulated on this. I find the wikipedia article explanation very appropriate:

"The phrase "Wine Is Not an Emulator" is a reference to the fact that no processor code execution emulation occurs when running a Windows app under Wine. "Emulation" usually refers to the execution of compiled code intended for one processor (say, x86) by interpreting/recompiling software running on a different processor (say, PowerPC). " : ... In Wine, the Windows app's compiled x86 code runs at full native speed on the computer's x86 processor, just as it does when running under Windows. And Windows API calls and services also are not emulated, but rather substituted with Linux equivalents that are compiled for x86 and run at full, native speed."[1]

[1] http://en.wikipedia.org/wiki/Wine_%28software%29

Even for the Wine project, it's a little more nuanced than just that: http://wiki.winehq.org/FAQ#head-c9e6502ad636315e905d07f7e445...

I'm glad that portion of the FAQ is getting some use. I'd been answering that question for years before updating it :)

Also keep in mind that the Wine project was named a long long time ago when ironic recursive acronyms were still cool. Systems built with "GNU's Not Unix" were, after all, eventually certified Unix ;)

Maybe it's like Wine in other ways. Wine isn't defined by the fact that it isn't an emulator. It's just named as such.

I once spent some time once tracking down some of the history of how Wine went from officially being "WINdows Emulator" to "Wine Is Not an Emulator" even though nothing had actually changed about how it actually worked. Here's a copy of what I found:

----------------

It might be nice to have a history of how the name "Wine" went from meaning "Windows Emulator" to "Wine is Not an Emulator". I did some poking around on this a long time ago. Here are the results, with references, if someone would like to clean them up and add them to the article.

I believe the first suggestion of the "not an emulator" name was in this usenet post [1]. This was in 1993, prompted by concern over trademark issues with the name "Windows Emulator".

In this post [2], Bob Amstadt responds to the above post with more interesting history:

   My orignal line of thinking was "winemu", but I didn't
   like that. Then I thought of shortening it to "wine".
   This led me to think of "whine" and "whinny". I liked
   "whine", but felt that it was too long.

By 1997, the "not an emulator" interpretation was in use, but as an alternative, according to the Wine FAQ from late 1997 [3]:

   The word Wine stands for one of two things: WINdows
   Emulator, or Wine Is Not an Emulator. Both are right.
   Use whichever one you like best.

The dropping of calling Wine an emulator happened between releases 981108 and 981211. The 981108 release notes [4] said:

   This is release 981108 of Wine, the MS Windows emulator.

The 981211 release notes [5] said:

   This is release 981211 of Wine, a free implementation of
   Windows on Unix.

The dropping of "Windows Emulator" seems to have been for two reasons. One was that Wine could be used for more than just taking a Windows binary and running it on Unix. It could also be linked with code compiled on Unix, to give a native Unix binary port of a Windows program. The other was that most users were only familiar with emulators that emulated hardware, which tended to be slow. Wine might get an undeserved reputation of slowness because of that, so they stopped calling it an emulator. I have been unable to locate the references I had to support this paragraph. I think they were posts in comp.emulators.ms-windows.wine from around 1997 or 1998, if someone better at Googling than I wants to try to track them down.

----------

[1] https://groups.google.com/forum/#!original/comp.os.linux.mis...

[2] https://groups.google.com/forum/#!original/comp.os.linux.mis...

[3] https://groups.google.com/forum/#!msg/comp.emulators.ms-wind...

[4] https://groups.google.com/forum/#!msg/comp.emulators.ms-wind...

[5] https://groups.google.com/forum/#!msg/comp.emulators.ms-wind...

Howto add the Gentoo Overlay:

     A) Quick & Dirty
     1. Run: layman -o https://raw.github.com/LubosD/darling-overlay/master/overlays.xml -f -a darling-overlay

     B) Safe and Standard

     1. Find the overlays section in /etc/layman/layman.cfg
     2. Add https://raw.github.com/LubosD/darling-overlay/master/overlays.xml
     3. Update all repos by running: layman -S
     4. Now run: layman -a darling-overlay

I wonder if they have implemented/made use of any libdispatch ports for Linux to support GCD.

Oh, they did, together with libkqueue and libpthread_workqueue.

http://darling.dolezel.info/en/Build#Grand_Central_Dispatch_...

The GNUstep libraries already provide a large part of all that has to be done. Frankly, I'd be happy with source-level compatibility or even an Xcode plugin that helped programmers write cross-platform programs that run on both OSX and GNUstep.

Considering the huge amount of work behind Quartz and Core Animation, I feel quite pessimistic about this goal.

How about creating a translation layer from ObjC and CoreGraphics sources to js and canvas in WebKit based browsers with some JavaScript engine?

Reply on news.ycombinator.com