What does HackerNews think of wil?

Windows Implementation Library

Language: C++

a) Not just the Windows kernel - Office uses SAL, too, in numerous places. Mostly in legacy places predating more modern C++. b) It's not true to say that kernel devs don't really use it. They use it a lot, though there are attempts at obsoleting some of it[0].

[0]: https://github.com/microsoft/wil

Not since Vista.

https://docs.microsoft.com/en-us/cpp/build/reference/kernel-...

> Creates a binary that can be executed in the Windows kernel. The code in the current project gets compiled and linked by using a simplified set of C++ language features that are specific to code that runs in kernel mode.

And then there is WIL, https://github.com/microsoft/wil

https://community.osr.com/discussion/291326/the-new-wil-libr...

> First off, let me point out that this library is used to implement large parts of the OS. There are hundreds of developers here who use it. So unlike, uh, some other things that get tossed onto github, this project is not likely to wither and die tomorrow.

> There are, however, only a handful of kernel developers working on the library, so the kernel support has been coming along much slower. I'd like to expand the existing kernel features in depth ....

WIL seems to be in more or less active development, according to its GitHub page. ATL doesn't seem to have much done to it in the last decade or so.

https://github.com/microsoft/wil

> Plus C++ standard library can't be used anyway and auto pointers aren't really that much of a concern at the kernel level

https://github.com/microsoft/wil

"Ah, but that isn't used on the Windows kernel" would be the expected reply, well

https://community.osr.com/discussion/291326/the-new-wil-libr...

"Microsoft's toolchain does not ship a copy of the STL that works in kernel mode. Partly this is because the kernel's CRT doesn't support C++ exceptions. (And partly this is because I/O is wildly different in kernel, so you'd have to rewrite the implementation of all the I/O libraries.)

But for kernel developers, wil ships a subset of an STL implementation. To avoid conflicting with the real STL, it's available under the wistd namespace. The rule of thumb is that wistd::foo is a drop-in replacement for std::foo."

Windows is a mix of legacy C code, which started to be migrated into C++ around the Vista time (hence /kernel in VC++) and .NET/COM (WinRT is basically COM with some extras).

Modern kernel code makes use of WIL.

https://github.com/microsoft/wil

C++/WinRT tooling is so bad, that MFC feels modern.

Ok, I got the point that they decided to stop doing language extensions and C++/CX was a dead end.

Surely the PM that signed the idea to replace C++/CX, could have spent one minute considering not to ship a development experience that is worse than MFC.

In 30 years haven't they had time to add syntax highlighting and code completion to IDL files?

Ah, and the Windows team then ignores C++/WinRT on their own samples, and use their own internal WIL framework instead.

https://github.com/microsoft/wil

So you get some samples on MSDN now that after being rewritten from C++/CX into C++/WinRT, are also tainted with WIL library types