For example, no object for KSPIN_LOCK and thus no guaranteed initialization
This is on its way. Feel free to file an issue on github or complain here if you’d like to see any other types.
What is preventing getting these updated to the latest file set?
Finding the time to do it. We seem to have finite hours in the day, and infinite tasks to work on… just like, I’m sure, everyone else here.
IMO, anything that allocates/deallocates behind the scenes would be a bad bad bad, very bad idea in the kernel.
A big part of C++'s offering is that it can hide things. E.g., it can hide a call to Dereference, Unlock, Free, Close, LowerIrql, or CompleteRequest. Whether you want this in your codebase is a matter of taste, and I can’t ever see Microsoft ever forcing this decision on a driver writer. If you can’t grep for all the Free calls because they’re invisible, how can you possibly debug a memory leak? But the counterargument is that if the Free code is automatic, there aren’t memory leaks. Whether you & your codebase buys into that is your choice.
potential for confusion “down stream”
This is very real, and something we’ve been (and still are) working through internally. At first, a lot of devs were startled to see bits of wil spackled throughout code reviews, and there were more than a few “WTF is this?” comments. Over time, though, the thing has caught on in many parts of Windows. So just as every win32 developer knows about the GetLastError()
dance, we’re getting to the point where most win32 developers (internally) know about RETURN_IF_WIN32_BOOL_FALSE
. (That macro is the equivalent of the GetLastError()
dance, with some logging thrown in.)
Nobody (at this point, at least) is really pushing wil outside of Microsoft, but there’s some hazy dream of a future where every win32 developer just knows these macros and types, and it would look weird to manually spell out the error-checking or handle-closing.