It's just the kind of area Rust does really well in. From a certain point of view, Rust can produce executables that are pretty much "written in plain old C" in that they can provide linkage that works like C linkage, don't necessarily need heap/GC, don't necessarily need big std library presuming userspace context.

I'd wager you could do something similar with D (soon if not now), since its no-std support is catching up w/Rust's.

I have a "framework" (really just a build tool and some examples) for bare-bones Win32 support for D[1]. I haven't tried writing kernel drivers with it though.

I used it to create a few Fallout 4 mods[2]. Avoiding the stdlib was not necessary there, but I didn't want the bloat. One interesting application of D's metaprogramming has been automatically recursively instrumenting the DirectX COM API just from the D interface definitions[3] (not IDLs).

  [1]: https://github.com/CyberShadow/SlimD
  [2]: https://github.com/CyberShadow/csfo4
  [3]: https://github.com/CyberShadow/csfo4/blob/master/dxlog/d3d11.d

Windows has been moving to C++ on kernel space since Vista, even newer C-like APIs are actually C++ code with extern "C" calling convention.

They have stated multiple times that C++ is the way forward for systems programming on Windows.

Any reference for this?

Yes, Herb Sutter's blog regarding C99.

https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an...

The new C runtime library was re-written in C++ with extern "C" for the entry points.

https://blogs.msdn.microsoft.com/vcblog/2014/06/10/the-great...

Vista introduced support for C++ in the kernel

https://msdn.microsoft.com/en-us/library/jj620896(v=vs.110)....

I don't think it happened until much later than Vista.

Vista was when the wheels were set on march, not when the travel ended.

For example many of the new APIs were COM based, not plain C like ones.

Being able to integrate with C efficiently is one of the goals of the language.

As a side note, Windows XP support in Rust is partial. We don't support running the compiler on XP, but do support compiling _to_ it, but some parts of the standard library may not work. It's missing some primitives, basically.

Not that that matters in the context of writing a kernel driver, mind you...

Yep, most of modern atomic primitives at WinAPI available since Vista (like SRWLock, Condition variables).

But core of NT is stable since 3.1 (1993) and even there are structures which are dated 1989 (e.g. [FILE_OBJECT](https://msdn.microsoft.com/en-us/library/windows/hardware/ff...).

This is not at all true. Microsoft has recommended for a long time that new drivers use WDF which is a C++ library

Do you have a source for that? KMDF seems to be a C-API.

I meant it's written in C++[0]. The interface is exported through standard C functions, but the header files also have the declarations guarded with "extern "C"".

Microsoft do have some sample drivers that are written in C++, e.g. https://github.com/Microsoft/Windows-driver-samples/tree/mas...

[0]: https://github.com/Microsoft/Windows-Driver-Frameworks/tree/...

It has a C API, but everything under the hood is C++. The source is actually public now: https://github.com/Microsoft/Windows-Driver-Frameworks