Rust for Windows 0.9(blogs.windows.com)
blogs.windows.com
Rust for Windows 0.9
https://blogs.windows.com/windowsdeveloper/2021/05/06/announcing-rust-for-windows-v0-9/
86 comments
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.
[1] https://en.wikipedia.org/wiki/Architecture_of_Windows_NT#/me...
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.
[1] https://en.wikipedia.org/wiki/Architecture_of_Windows_NT#/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.
And how are you supposed to parse the rust library?
A Rust Binding for WinAPI
[deleted]
[deleted]
> 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.
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.
I think rearranging those words in almost any other order would’ve been superior: WLS, LSW, LWS
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 don't think it's cynical at all, and is probably both. I guess in all big companies PR/marketing teams chime in to all public facing projects
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.
I don't think that's strictly true: https://twitter.com/drosenwasser/status/1098748330765619200
As far as major versions go, AFAIK they just bump the mayor version every ten minor versions, of which they release a new one every 3 (?) months.
As far as major versions go, AFAIK they just bump the mayor version every ten minor versions, of which they release a new one every 3 (?) months.
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)
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)
At least they didn’t name it Azure Rust, Rust Live, Rust.net or Rust 365 :)
[deleted]
I'm pretty certain some of these names will appear sooner or later.
Microsoft naming is incomprehensible sometimes. Doing a .net framework -> dotnet core transition at the moment has really exposed me to a lot of this.
I find Microsoft naming is always suspicious.
"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."
"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."
New Microsoft project name idea: Microsoft Namespace
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.
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.
When it was Windows Subsystem for Linux, I assumed marketing dictated "No no, the word Windows MUST be the first word."
This one just seems deliberately confusing for no reason.
This one just seems deliberately confusing for no reason.
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.
Correct. It's a trademark law issue. In the same way that you can develop a "Chess for Windows" but not a "Windows Chess". Using "for X" is fair use.
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.
Similarly, the unofficial Reddit apps had to rename from e.g. "Reddit Sync" to "Sync for Reddit".
and windows 0.9? Cmon, not even full 1.0? https://en.wikipedia.org/wiki/Windows_1.0
Yes, this is more of a "Rust rof Windows" thing.
Thank you. I was wondering why someone resurrected Windows 0.9 (was that even a thing?) and why in the hell someone would port Rust to it.
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").
Looks and sounds weird though!
Looks and sounds weird though!
They use that excuse but it doesn't explain the fact that they had alternatives like "the Windows Linux Subsystem" or "the Windows Rust library"...
Even "Rust Library for Windows" (or why not just "Rust Windows API Library") would be more clear.
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.
That's exactly what I thought.
It should be Windows support for Rust and not the other way around.
It should be Windows support for Rust and not the other way around.
Microsoft sucks at many things. Naming things in a descriptive way is one of them.
I'm completely confused by Microsoft's use of "for Windows" naming.
Rust for Windows already exists. This is a Windows SDK for Rust.
Windows Subsystem for Linux is Linux subsystem for Windows.
Is this some usage of the "for" word that I'm not getting? I'm a non-native English speaker so I could be at fault here.
Rust for Windows already exists. This is a Windows SDK for Rust.
Windows Subsystem for Linux is Linux subsystem for Windows.
Is this some usage of the "for" word that I'm not getting? I'm a non-native English speaker so I could be at fault here.
It's not just non-native speakers that are getting confused by their inconsistent English. Don't worry, not just you
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].
But I agree, the naming is very confusing.
But I agree, the naming is very confusing.
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 think it's more like (Windows Subsystem) for [running] Linux.
That's incorrect.
The name is Windows Subsystem (as in a Subsystem that runs on the windows kernel) for linux, that is, designed to run Linux.
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.)
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.)
This is awesome.
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.
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.
I wish apple would do the same.
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.
https://github.com/servo/core-foundation-rs
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.
https://github.com/servo/core-foundation-rs
I wonder if there’s some way to leverage the Swift annotations in the SDK to help generate the Rust code automatically.
Servo is now managed by the Linux Foundation. Mozilla quit managing it after their round of layoffs early last year.
A bit off-topic but is the C++ API library for Windows coming along too? I've been looking out for that, but I'm not sure what state it's in.
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.
Really, ageing MFC feels more productive.
I don't know, maybe at BUILD 2021 they will announce something, there is always hope.
Why is the v in v0.9 missing in the title
I sure can't wait when they release Rust for Windows 3.1
When are they going to do a Rust backend to generate .Net code?
Why would they? Rust is for native development -- that's its reason to exist.
Somebody is doing it as a side project: https://ericsink.com/entries/llama_rust_013.html
Bookmarked with thanks, it's on my list of projects to check out.
Is this closed source closed license? I'm asking just out of curiosity; I cannot find repo info
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.
Windows 0.9 was an OS in 1980s... NOT.
After Windows 10 comes 0.9? Did 11 cause a version integer overflow?
Why is microsoft posting this / working on this rather than the rust project itself?
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.
[0]: https://docs.microsoft.com/en-us/windows/dev-environment/rus...
[1]: https://github.com/microsoft/windows-rs
[0]: https://docs.microsoft.com/en-us/windows/dev-environment/rus...
[1]: https://github.com/microsoft/windows-rs
So it's more like "Windows for Rust" rather than "Rust for Windows"...
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.
It's their Windows API SDK, same as Amazon posting about their Rust SDK for AWS.
Aws named it "A New AWS SDK for Rust – Alpha Launch".[1]
[1]https://aws.amazon.com/de/blogs/developer/a-new-aws-sdk-for-...
[1]https://aws.amazon.com/de/blogs/developer/a-new-aws-sdk-for-...
Microsoft does also contribute to the Rust project itself, alongside the other stuff folks are talking about.
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.