It is not an emulator and the experience is pretty great for anything involving Linux as a workstation.
Even though they say "NO current plans to support X/GUI apps, desktops, servers, etc. at this time", this is achievable by installing VcXsrv.
Even though they say "NO current plans to support X/GUI apps, desktops, servers, etc. at this time", this is achievable by installing VcXsrv.
That's kind of a strange comment given that in these very same comment boxes the most ardent *nix users tend to bash the entire concept of GUI (no pun intended) and just assert that a command-line interface is the right way to use a computer.
WINE originally stood for "WINdows Emulator". It was several years later that it became "WINE Is Not an Emulator". The change was for marketing reasons, not technical reasons, since nothing had actually changed in how WINE worked.
The first time anyone suggested "WINE Is Not an Emulator", as far as I've been able to track down, was late August, 1993, over concern that Microsoft might win its trademark case over "Windows" and come after WINE. Someone suggested WINE become WAW, for "WINE Ain't Windows", and someone else responded to that suggesting "Wine Is Not an Emulator".
Soon fear of the trademark issues abated and nothing happened for quite a while.
By 1997, the "not an emulator" usage had become an acceptable alternative. The Wine FAQ late that year said:
> 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 saying WINE was an emulator came in late 1998. The 981108 release notes said:
> This is release 981108 of Wine, the MS Windows emulator.
The 981211 release notes said:
> This is release 981211 of Wine, a free implementation of Windows on Unix.
From what I was able to find, it seems there were a couple reasons for dropping calling it an emulator.
One was that it could be used for more than just running a Windows binary on Unix via emulation. It could also be used as a library that you could link with code compiled on Unix. This provided a way to provide a native port of you Windows program to Unix instead of running the Windows binary in emulation.
Calling it an emulator unnecessarily pigeon holed it.
Another was that emulators that emulated hardware were getting popular. People were making emulators that emulated x86 hardware on RISC systems. They were making emulators that emulated older personal computers, like C64 and Apple II. They were making emulators that emulated console gaming systems like NES.
One thing all of those emulators had in common was that they were very slow, in the sense that emulating one instruction of the emulated machine took many instructions on the host machine. For emulating the old gaming consoles, or the old 8-bit personal computers, where the host machine was running two or three orders of magnitude faster, that was not a problem--the emulation could run as fast or faster than the original machine actually ran. But when emulating something more contemporary, such as emulating an x86 PC at the hardware level to run Windows on it, they were very slow.
Since hardware emulators like these were the only kinds of emulators most people encountered, people tended to see "emulator" and read "ridiculously slow". If they kept calling WINE an emulator, many people would think that means it is ridiculously slow and avoid it, so they stopped calling it an emulator.
Everything else in the WSL is the regular Ubuntu user land. So all the processes are "native" and they make calls to a kernel that acts just like Linux.
It's kinda funny: the Windows NT kernel (and Executive, the actual native API) are a single-root object hierarchy where everything gets mounted - much like unix - only even moreso. Mutexes, Registry Keys, etc are all objects mounted in the root filesystem.
I guess everything old is new again. Microsoft used to have a server product called Services for Unix that replaced the built-in POSIX 1.0 subsystem with a legit Unix environment but it was always a neglected product that only existed to get people to port server apps to Windows. This time they're doing the integration on end-user desktops and have spent more time getting Win API integration working smoothly.
Although it would seem logical, the WSL doesn't actually use this system. The whole pico process engine and how it interacts with Windows is all new and not related to that design. I'm not really sure the reasoning behind it; perhaps it didn't allow them to do the level of integration they wanted.
I develop a rails app on Windows using WSL daily. Ruby runs in Linux and gems compile to Linux, not win32. So there is no weirdness compiling something like ImageMagic.