Microsoft's team blog on the Windows Subsystem for Linux, explaining its architecture, syscall translation, file system, and interop.
Commenters cite it to explain how WSL1 works, including pico processes and the file system layer, and why it is not a real VM.
It isn't the "NT kernel either way", as you are going through the filesystem translation layer; AFAIK it is implemented as a subsystem, so you are accessing the kernel through an entirely disjoint mechanism.
So like, Microsoft may have fixed this recently, but WSL processes were essentially stuck inside of a filesystem sandbox that uses some inane mechanism to access files via mountpoints that fails to correctly translate the few flags that are supportable by the underlying Windows filesystem, so if you try to do basic things like use WSL's copy of git to manage a git repository stored outside of the WSL sandbox, it just doesn't work correctly.
On the flip side, you also can't run a native Windows process whose binary is sitting inside of the sandbox, as native Windows processes do not have direct access to WSL files. Checking, they seem to have finally added the ability to mount new paths, so that's helpful (if you have network shares or removable media like USB keys, these were previously not accessible via WSL).
The great thing about cygwin and MinGW is that, by and large, it _is_ "just the NT kernel", with nothing more than a userland library sitting between the process and the same kernel interface used by any other Windows application, so tons of stuff "just works" that WSL is having to slowly reimplement.
(FWIW, it could be that Microsoft has fixed some of these filesystem showstoppers since I last tried to seriously use WSL; if so, that's exciting, but it doesn't…
I think MS is trying to both support and not-support WSL, in the sense of building it out enough to support their internal agenda, but not where complex SLAs are needed.
So, COM port access... I don't see that being hard; I envision it as boring API-wiring, since RS232 has been standard since before Windows and Linux existed, so it's likely the code's generally similar.
But in terms of high-level support, RS232 is primarily industrial-class, with a long tail of developers and workstation uses trailing after it. Industrial immediately means complex SLAs and - nooooo - industry certifications and the like. I don't think MS wants to invest that much into WSL.
With this said, a bit of poking around found https://blogs.msdn.microsoft.com/wsl/2017/04/14/serial-support-on-the-windows-subsystem-for-linux/, from last year. Are you on Insider Build #16176 or later?
You mention a target as compliance or certification, but I don't think this is a direct concern for the WSL. They want to support specific use-cases, at least at first.
---
"Moving forward we will be investigating new areas of interest while continuing to support the following scenarios:
+ GNU command line tools such as grep, sed, and awk
+ File system and symlink support within the WSL environment
+ Ability to run apt / apt-get for installs, updates, and package testing
+ Basic functionality for languages such as NodeJS/npm, Python, Perl
+ Command line tools such as Vim, Emacs, Git, and SSH"
https://blogs.msdn.microsoft.com/wsl/2016/07/08/bash-on-ubuntu-on-windows-10-anniversary-update/
"every other system has a feature except us, and we are not going to add it (because reasons) even if it's very widely used"
also:
> When a fork syscall is made on WSL, lxss.sys does some of the initial work to prepare for copying the process. It then calls internal NT APIs to create the process with the correct semantics and create a thread in the process with an identical register context. Finally, it does some additional work to complete copying the process and resumes the new process so it can begin executing.
https://blogs.msdn.microsoft.com/wsl/2016/06/08/wsl-system-calls/
Nice job.
I'm a little skeptical though -- I think the devil is in the details. It's a lot of work to make a highly reliable backup program. As a Windows user, here's a list of questions I'd ask:
1. Does Relica work with OneDrive on-demand files? [1]
2. Does Relica work with WSL files? [2]
Supporting all these corner cases on Windows, Mac, and Linux will be a TON of work.
[1]: https://support.office.com/en-us/article/learn-about-onedrive-files-on-demand-0e6860d3-d9f3-4971-b321-7092438fb38e
[2]: https://blogs.msdn.microsoft.com/wsl/2016/06/15/wsl-file-system-support/
> Windows is the dominant desktop OS
So what? Is desktop computing all that matters? Networking, scientific computing, mobile telephone, don't they matter?
Unix was never meant for looking magic to clueless users; it was meant for programmers, i.e. for people who use the computer and not just some programs written by other people. And, in its realm, it has been brilliant! Not perfect, but very good!
By the way, here's a link to learn something more: https://blogs.msdn.microsoft.com/wsl/