The way to parse WSL is that it's a <Windows (NT) Subsystem> for Linux.
Windows NT had environment subsystems as a key part of its architecture, with subsystems for POSIX and OS/2, originally[1], and even Win32 was conceptually a subsystem for NT, albeit a very important one.
> The way to parse WSL is that it's a <Windows (NT) Subsystem> for Linux.
For me that still parses wrong on first try. I mean I can make sense of it, because I already know how it is meant, however for me the most obvious assumption is, that it is for the given host and that host is Windows, not Linux. So Linux (compatibility) subsystem for Windows would make more sense to me.
And the fun part is that since WSL 2 it's no longer a Windows Subsystem, but just a Linux kernel in VM with some nice integrations with host Windows OS.
Maybe it's cynical, but I wonder if it's a PR/imaging move. When you read these kind of names, it seems like the Linux/Rust community is embracing and supporting Windows, while really it's the reverse.
I think you are right. If I remember correctly, someone on the typescript team said they have no control over version numbers. PR/marketing decides what is version 4.0 vs 3.11.
It was Rust/WinRT, then they added support for other kinds of Windows APIs alongside the WinRT support. Someone probably thought Rust/Windows looked weird, so, Rust for Windows.
Rust/WinRT was called that because it was patterned after C++/WinRT, which was called that because it was a replacement for or alternative to C++/CX, which was called that because it was an analog to C++/CLI. C++/CX and C++/CLI are language extensions/forks, while C++/WinRT and Rust/WinRT are just libraries (and tools).
(I always thought C++/WinRT was a bad choice of name for this reason)
"Let's deliberately choose a name for a thing that could be confused for a different thing. [some amount of time and nefarious activity later, and with false innocence] Oh, we've always called it that, so you can't have that namespace even though you think it should belong to that technology that predates our suspicious name with which we encroached on non-Microsoft technology."
A good usage example for a similar naming is "Qt for Python" which is the name of Python bindings of Qt framework.
I literally didn't understand what "Rust for Windows" meant, I needed to read the blog post to understand what it is, which is a Rust library to use Windows API from Rust.
Mentioned somewhere else: Windows NT has subsystems. E.g. posix, os2, win32, ... What they do is adding a subsystem to windows. The module they code is the subsystem not the distribution. Nowadays it is a bit blurry die to the full kernel and this windowing subsystem.
AFAIK it was their legal department, who advised them that calling it a "Linux Subsystem" may run afoul of the Linux trademark, especially considering that in WSL1, Linux itself was not involved at all.
You say "correct" but you're directly contradicting the parent's point, since with your argument the easily and correctly parsed 'Linux Subsystem "for Windows"' would not run afoul of any trademarks.
Remember -- the name "Linux" is trademarked. Microsoft is free to call something Windows X since they own the Windows trademark, but they can't call something Linux X because they don't own the Linux trademark. But they can call something X for Linux the same way a third party can call something X for Windows. Hence, Windows Subsystem for Linux. It sounds dumb, but that's the legal rationale.
But even in your example, it shows how bad of a name WSL is. "Chess for Windows" implies that there is a chess program that runs on windows. By analogy, "Windows Subsystem for Linux" implies that there is a Windows Subsystem that can run on Linux.
This is mostly for legal reasons and the "for X" where X is a trademark is a common theme. (just look at Google Play store "for Twitter" or "for Reddit").
I think Microsoft played all of us with this name. The confusion is there intentionally for developers to argue about, therefore generating marketing material for free.
This was mentioned somewhere else already, but the way to parse [Windows Subsystem for Linux] is [Windows] [Subsystem for Linux] (not [Windows Subsystem] [for Linux]). In case of [Rust for Windows], it should actually be called something like [Rust] [API for Windows].
Even with that, I'd expect a "subsystem for Linux" to be a subsystem that runs on Linux, not a subsystem that runs Linux. I think it's the word "for" that is causing confusion, rather than the parsing order itself.
I just started using this library 2 weeks ago. It is beautiful. We were in python land, and dreading moving to C++ for performance. This is a life saver.
Not having to dig up COM UUIDs for interfaces is super nice. The lead developer of com-rs told me that com-rs is deprecated in favor of windows-rs (he works on both.)
I recently tried to use this library and had to go back to winapi-rs for the mean time.
The bindings to set it up gave hard to debug errors and there is no support for compiling the x86_64-pc-windows-gnu toolchain on anything else besides a windows system; Which makes sense but winapi-rs compiled on Linux so I stuck with it. I don't want to manage another build machine and I know I'm probably like the one guy.
Working with strings was a bit rough too, it'd be nice if you could just pass a CStr and call it a day instead of messing with buffers and lengths and double function calls, one to get size of the string and then another to fill the actual buffer. I know this is how Win32 works, but it doesn't feel natural coming from Linux Kernel Dev.
Regardless of my criticisms, I am excited to see the future of this crate. I think it's an awesome effort and a great addition to Rust and Windows.
Check Core Foundation [0]. It implements a lot of OS-X's API in Rust.
It is not Apple, is made by Mozilla as part of their Servo browser project. But is probably the best we'll have. Apple stopped playing the "open" game long ago, even before MS started it.
In what concerns C++/WinRT, doing great, assuming that you enjoy editing IDL files without any kind of Visual Studio support, manually copying and merging files, and that the team had waves any complaint how the tool is lacking versus C++/CX to the miraculous day when ISO C++ gets reflection support.
Really, ageing MFC feels more productive.
I don't know, maybe at BUILD 2021 they will announce something, there is always hope.
It is closed source unfortunately. I'd gladly contribute if it were open. Having first party Rust on .NET platform, especially classlib compatible, would be rejuvenating. The platform certainly has all the necessary whistles.
Judging by the getting started guide[0], they thankfully haven't forked Rust or anything, this is all about windows-rs[1], a Rust library for conveniently accessing the Windows API.
It's still Rust for Windows, as in "this is what we need to make Rust an option for Windows development". Thankfully, it's not 2003 anymore when the tools involved would only run on the target OS unless written in Java or by RMS. Nobody wants to bother with the specifics of their build server environment.
Rust for Windows -> a version of Rust for Windows? Windows Library for Rust -> a library for Rust that allows to interface with Windows APIs
Same with Windows Subsystem for Linux. It's a Linux system for Windows.
But hey, that's just names. Nice for win-devs to get more languages supported.