After internal experiments with Rust, Microsoft now apparently wants to encourage its partners to use Rust for drivers.
Microsoft has published a very extensive repository with numerous individual projects as open source on Github, which should enable the development of Windows drivers in the Rust programming language. According to the description, the work comes from the Surface team, i.e. Microsoftās hardware department. It can therefore be assumed that Rust drivers are already used for Surface devices or are at least planned.
Specifically, the projects are about Rust packages (crates), with which the usual driver models WDM and WDF can be implemented, i.e. also kernel and user mode drivers. System services (Win32) should also be possible with it. The Crates cover above all idiomatic API connections to the Windows Development Kit (WDK), which support Safe Rust. In addition FFI connections, macros as well as libraries come to the Panic treatment, to the memory allocation or to the building and linking of the drivers themselves.
Already in the spring of this year Microsoft announced to rely on Rust for some important system components up to the Windows kernel. This is primarily to facilitate maintenance and ultimately also to increase security by being able to rely on Rustās security guarantees. Language bindings for the classic Win32 API for Rust have also been available for more than two years.
However, Microsoft does not want to officially support the work for Rust drivers presented now, nor does it want to recommend them for commercial use. It is rather an experiment to involve the community. For those interested, the company provides a sample driver that was created with the new Rust drivers.
The possibility of Windows supporting Rust as a language for kernel mode development is an exciting one. Having a fully idiomatic Rust interface to the native Windows or WDF APIs would be a wonderful thing (and something we, here at OSR, have been asking for for years).
Sadly, whatās been released (so far at least) on GitHub isnāt too encouraging. Itās completely unsupportedā¦ but, I guess thatās fair for now. Much worse is that the sample driver directly calls the standard WDF APIs by wrapping those calls in āunsafeā blocks. Thus, we donāt have an idiomatic native Rust API for writing Windows drivers. Rather, this project demonstrates how to use Rust to build a Windows kernel-mode module, and call the existing WDF APIs from Rust. Yay?
While itās certainly nice to see the very similar work that was done done years ago by the community brought up to date, it doesnāt give us much thatās new or exciting. Sigh!
What we need is a dedicated effort, by a skilled development team, to build and support a new, native, idiomatic, modern language interface for Windows kernel mode development. I donāt much care anymore if that interface is Modern C++ or Rust. Given the sad lack of Microsoft investment in all things not AI or Azure, I unfortunately donāt see that happening anytime soon. Or, anytime at all, really.
As a good friend of mine at Microsoft said to me a few weeks back āWhen was the last really meaningful app developed for Windows Server?ā ā That REALLY made me think.
And, the sad thing (for me, at least) is that thereās no viable OS thatās positioned to replace it. I had high hopes for Fuchsia for a whileā¦ now, not so much.
Iāve been using Linux for my servers for years now. I find zero value in
running a Windows server. The last Windows server I ran would get hacked
monthly for spamming. It was a royal PITA to get things fixed. Several
times, I had to get a new IP address because the one I was using would get
banned by Google and other mail servers.
Windows makes a great desktop, and I have many Windows apps I would hate to
relearn in Linux. But for serving, you couldnāt pay me enough money to run
Windows.
The last thing I use server for is to provide an AD domain and its associated DNS/DHCP. As everything else in my homelab is running in containers on linux vms, it is only a matter of time before I ditch that as well. That said, the no gui versions of server are pretty easy to set up and configure, are sized correctly instead of being massively bloated, and the web based Windows Admin Center provides most of what I need to keep them running.
Yes, but isnāt that a Good Thing? People donāt buy an operating system in order to run the operating system. People buy an operating system in order to run the applications they need to be productive. That wasnāt necessarily the case in the early years, but itās certainly true today. The operating system is irrelevant, and browsers have made it even more so. The fact that a large majority of home users and even most corporate users could be perfectly happy using a Chromebook that doesnāt even EXPOSE an operating system should be an eye-opener.
What is Microsoftās business case for making radical changes to Windows? It does what it needs to do. Thanks to Linux, operating systems now have net value of approximately $0. Almost nobody buys Windows any more. You get a license with your new laptop, and you get free upgrades from then on. Windows only makes up 12% of Microsoftās net income.
You could argue that Excel drove sales of Windows in the early 90s, but no application developer today is going to exploit a cool Windows feature if it makes his application Windows-only. The world has changed.
The last thing I use server for is to provide an AD domain
You need to migrate to Azure AD. We even did that here at OSR, oh, some number of years ago (waaay before the pandemic).
Thanks to Linux, operating systems now have net value of approximately $0. Almost nobody buys Windows any more.
Well. Yes and no. From a ādesktop and serverā perspective, maybe. But thereās a TON of Windows thatās still being used in embedded environments, like medical equipment. And defense/intelligence related stuff. And, what mystifies me is that it seems like MSFT is doing all they can to annoy/prevent/disempower these exact uses of Windows.
Also, even when the apps are actually running on Azure VMs, thereās still SOME serious pull for people to run stuff under Windows Server. Thank goodness. I mean, we just did a sizeable, super complex, project for an FPGA vendor that had Linux support but also had major customers that needed Windows Server support.
Soā¦ yeahā¦ āitās not dead yetāā¦ but certainly on its way out.
Peter,
I will second your observation about the embedded Microsoft world. The last version of a Windows Embedded product was in 2013, unless you count the aborted attempt at Windows 10 IoT. With Windows 10, Microsoft went to their āUnified Architectureā for drivers which killed it in the embedded world. It was way to heavy, especially with KMDF, UMDF, EIEIODF, dejourDF, etc. Embedded systems need to be lightweight and deterministic (not necessarily fast). The UA simply could not do that. I used to make my living with Windows Embedded series, but not since several years ago. I did some work in Windows Embedded NDIS drivers last year and regretted it immensely. Iām entirely Linux now.
Microsoft ceded the embedded world to Linux, just like they really ceded the entire supercomputing world to Linux.
What market are they really trying to target Windows to? Enterprise servers and Enterprise desktops seem to be their only niche in the middle.
Not to try to steer this back to the original topic, but the Linux kernel is getting some rusted components now. I had hoped Torvalds would have held the line against this as he did for C++, but oh well. Time for me to learn new tricks and how to mitigate the bloat/damage.
Greg
On Tue, 26 Sep 2023 19:29:15 +0000 (UTC), āPeter_Viscarola_(OSR)ā wrote:
Peter_Viscarola_(OSR) commented on Microsoft discloses Rust framework for Windows drivers
> The last thing I use server for is to provide an AD domain
You need to migrate to Azure AD. We even did that here at OSR, oh, some number of years ago (waaay before the pandemic).
> Thanks to Linux, operating systems now have net value of approximately $0. Almost nobody buys Windows any more.
Well. Yes and no. From a ādesktop and serverā perspective, maybe. But thereās a TON of Windows thatās still being used in embedded environments, like medical equipment. And defense/intelligence related stuff. And, what mystifies me is that it seems like MSFT is doing all they can to annoy/prevent/disempower these exact uses of Windows.
Also, even when the apps are actually running on Azure VMs, thereās still SOME serious pull for people to run stuff under Windows Server. Thank goodness. I mean, we just did a sizeable, super complex, project for an FPGA vendor that had Linux support but also had major customers that needed Windows Server support.
Soā¦ yeahā¦ āitās not dead yetāā¦ but certainly on its way out.
IMHO Windows server is far from dead. Well written server applications can perform substantially better on Windows than on anything else. They are not the fancy shiny things that people go after, but they make money for business that rely on them.
In terms of new development, what feature do you think they should add? That was the big idea with Windows 10 - that the OS is essentially complete, and only new service packages are needed. No fundamentally missing or incorrect features. The focus no longer being on the OS itself, but on what you do with it. So called AI programs (which are not intelligent), cloud applications, containers and a focus on small systems of every kind. The hardware guys are doing it too. When was the last new Xeon platinum processor released and whatās on the roadmap in that area? On the other hand, 100Gb/s Ethernet is becoming common
In terms of new development, what feature do you think they should add?
Seriously? Where should I begin?
How about fixing the storage stack, so that out-of-the-box performance doesnāt suck. A modern storage stack would be, you know, sort of a nice thing to have.
Next how about a bunch of updates to WDF to actually finish it properly. I mean, itās been whatā¦ 15+ years now? As much as I love WDF (and I do, I do, I really, really do) Iām sure nobody thinks itās fully fleshed-out and perfect. It could also use some perf improvements.
Then we can move on to the topic of this thread: A modern interface for driver developmentā¦ like Rust or Modern C++. That would be nice.
Oh, and while weāre hoping for the unattainable: How about a modern method of interprocess communication? Something thatās just a BIT newer than COM, and not just one guyās clever idea thatās only sort-of supported and gets effectively abandoned before anybody uses it. I do NOT understand how, in 2023, the only interface to ALPC (for example) is the venerable Microsoft RPC (oh, but I KNOWā¦ itās OSF DCE/RPC compliant, because in 2023 thatās a major thing). Never mind actually having a modern RPC that has modern security concepts and is agnostic regarding whether the client and server are co-located.
I could go onā¦ but doing so would just depress me even more.
There certainly are some things that could be added to Windows, but the ones you highlight seem odd choices.
Saying that COM is bad is easy until you think about what you might replace it with. The same is true with the storage stack - the only really obvious thing is the file system cache policy - which isnāt even part of the stack proper. It would be nice if there was support for NVMEoFC because the vendorsā drivers suck, but most vendor supplied driver suck
But what about better support for NUMA and asymmetric multiprocessing (performance cores versus efficiency cores)?
There is more too, but hankering after the new old thing if a fools errand. Rust and C++ fall into this category. C# on the other hand wouldnāt IMHO
You seem to be implying thatās a bad thing. Sharing the source puts more eyes on the code and reduces the errors. With some exceptions, the drivers are not where the intellectual property is.
@Tim_Roberts said:
You seem to be implying thatās a bad thing. Sharing the source puts more eyes on the code and reduces the errors. With some exceptions, the drivers are not where the intellectual property is.
On a personal level I could not agree more.
However it is still the case that companies go to a lot of effort to hide as much of their product as possible from the eyes of competitors. This is a big selling point for Windows.
Iām not sure that the conclusion that there is nothing worth copying in driver software is true. In the last 20 or so years since the bulk of the windows driver model has stabilized there have been multiple times when commercial advantage has been possible from better algorithms. Think about the MAC overloading that Intel Proset did, the first generation of MPIO and the pre-NVMe modules. The crashes caused by bad broadcom modules was an opposite case, but still important.
Will there be something new again? Probably. But probably not RUST I think
