WSL executes unmodified Linux ELF64 binaries by emulating a Linux kernel interface on top of the Windows NT kernel. One of the kernel interfaces that it exposes are system calls (syscalls). This post will dive into how syscalls are handled in WSL.
Exactly what it says on the tin.
The explanation went way over my head, but is this good for those of us who are interested in running bash and its associated utils on Windows 10?
It’s basically wine, but in the opposite direction. A binary loader for the other binary format, and a layer that provides the other OS’s syscalls.
Does that mean like half the apps I try to run aren’t going to work? 😐
That was my experience, yes
My experience so far has been that Wine is more compatible with Windows than Windows 10 is
It also feels like a huge compatibility increase occurred in Wine between 2012 and 2014. But maybe it was just happenstance and the specific programs I use.
Yes, that is exactly what this is for.
(and theoretically for many other subsystems in the future)
This is possible because Linux is open source.
That’s why MS can implement a Linux layer which has a hope of actually working (because you can see how it is supposed to under the hood, and all the exceptions and bugs that have become features etc).
You can’t implement a Windows layer on Linux with anywhere near the same degree of success.
Ironic that MS was so anti-OSS … and now it couldn’t do this without OSS.
… actually I catch myself … I’m told Windows NT implemented BSD’s IP stack years ago….
#giveback MS?
Source code isn’t needed – just a proper documentation. In fact, I’d guess that they didn’t use the source, in able to be sure that their clean room implementation was completely untainted.
This is why the Wine project was able to implement so much of the vastly larger Win32 API, too: Proper documentation.
Then you were told something false.
Seems like slowly but surely every major OS is able to execute Linux binaries. Windows, FreeBSD, NetBSD and Illumos. Is one missing?
There has been a lot of cross-breeding of kernels and operating systems lately with Android Apps on ChromeOS and now this Linux layer for Windows NT.
Is this another attempt by Microsoft to bind all developers and users alike to their Windows NT Kernel?
So Linux system calls are loaded from an external driver ? This should mean that you could run any other operating system applications in Windows just by writing a driver for the other operating system. That’s nice.
Not sure why everyone is going apeshit over this. It’s almost like no one remembers the history of Windows NT.
I forget the exact terminology, but 3.5 shipped with the ability to load multiple “flavours”, that allowed it to run programs from Windows 3.x, DOS, OS/2, and could run on 5 or 6 different CPU architectures (x86, MIPS, Alpha, M68K, PA-RISC, a few others). Services for UNIX (the POSIX â€flavour”) was added later as well.
Over the years, CPU architectures were dropped, and “flavours” were removed, but all the plumbing to make it possible remained. Not that hard to re-enable support for a new “flavour”.
And for those mentioning BSD TCP/IP stack, NT 3.5 got it’s stack from UNIX, using the STREAMS implementation from (I think) SunOS. That’s the kernel side of the stack. Only a handful of userland applications (like http://ftp.exe and telnet.exe) used BSD sources. In later versions of NT (I think with 4.x maybe 2K, but don’t quote me on that) the kernel side of the stack was re-written from scratch by MS.
For more details, check out (most likely from a library or a used book store) the book “Showstopper!”
https://www.amazon.com/gp/aw/d/0029356717
Edited 2016-06-12 20:12 UTC