In my experience, emulators are never quite the same as the real deal. Has anyone used this, and if so how was it?
I used to bring a picture of home with me on business trips, now the house just comes along more or less (there are the occasional plumbing issues on the road and it's jarring sometimes when I go outside and realize I'm in some weird neighborhood with maple syrup coating the sidewalks and immediately I'm getting hustled by some guy with his arm around my shoulders and people aren't walking anywhere, just standing there looking at me without blinking and even with the hustler spinning his yarn there's this eerie, heavy silence like a summer storm always on the horizon and I start to miss the fresh clean mountain air back home all the while trying to disengage myself from the hustler without starting too much of a conflict but when I step away my right shoe stays stuck on the sticky street and I stumble over and the hustler, before I've even hit the ground, he's already got his fingers around the wallet in my back pocket and still everyone just stands there watching as I smack pavement ... you know?).
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.
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.
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.
I'd rather just use Linux and not be surprised by anything.
https://blogs.msdn.microsoft.com/commandline/2016/10/07/wsl-...
My point was that I just don't want to encounter bugs. When I run Linux, I get Linux. I already have it installed and I know how it works. I don't want to take the chance of a bug breaking my development workflow.
You purposefully installed a pre-release version in which they heavily mentioned there would be major bugs and other unfinished things in it.
I'm not sure what you expected here but unless you're talking about the release version I don't think you're being fair at all.
> They did. My point was that I just don't want to encounter bugs.
What an awful response. If that's the problem you have then the solution is that you don't run beta software. You're not really making a sensible point by citing bugs in explicitly-marked-as-beta software as a reason to avoid release software that has already fixed those bugs. I would give the final version a try before complaining about nonexistent bugs.
In early builds I did have some file system weirdness but I believe that's all be resolved now. I expect the creators update will be a very solid version.
Have fun
https://blogs.msdn.microsoft.com/commandline/2016/11/17/do-n...
File system performance seems bad. Have tried multiple times to use it. First when it was first announced, and then again when Creators Update came out.
But... it's just not good enough yet. Hopefully the Fall Creators Update improve things.
For now, running a Linux VM is still way faster.
On balance, due to security issues, I decided not to use WSL for day to day.
But, yeah, jokes aside - it depends on the definition.
Still, the translation (or emulation) layer is partial at best. No cgroups (so no native Docker and rkt would work only with fly stage1 and a few patches), sockets are limited (e.g. a number of setsockopt stuff is missing), no tun or tap devices, no netfilter subsystem at all (so no iptables/iproute2/nftables), no GPU access, etc etc etc. Even though it's out of beta it's a bit early to think of it as a "real deal". Best it can do is run some desktop apps and build some software. Would probably work for basic webdev stuff (without containerization), but that's about it. It would probably never come close to the real thing, just as WINE probably won't ever replace Windows. But they try.
And, of course, it's non-free.
It's pretty complex. I don't think I would call it an emulator but I can see why someone would.