Windows Kernel Logic Bug Class: Access Mode Mismatch in IO Manager | Hacker News Reader

Windows Kernel Logic Bug Class: Access Mode Mismatch in IO Manager

googleprojectzero.blogspot.com

It's been a while since I've programmed for Windows but I'm so glad to be away from the LPCS_LONG_SHOUTY_NAMES. It actually kind of hurts my eyes to read this article due to all the normal text/SHOUTY/CamelCase changes.

It would be nice if there was a windows.h replacement that used namespaces, typedefs, enum classes, and bitfield structs to make typesafe non-namespace polluting names for everything while still being compatible with Win32.

> It would be nice if there was a windows.h replacement that used namespaces, typedefs, enum classes, and bitfield structs to make typesafe non-namespace polluting names for everything while still being compatible with Win32.

I think Microsoft has made too many Win32 wrappers at this point: WinForms, XAML, MFC, UWP... Adding another one isn't likely to succeed. New Windows desktop app development happens in Electron or C#; Win32 is the layer for low-level or legacy apps that aren't going to switch to anything different anyway.

You're probably right that applications still using Win32 directly are unlikely to switch to anything new. But the other frameworks you mention seem to be more than just wrappers; they're relatively heavyweight application frameworks that bundle a lot of new functionality rather than just providing a cleaner interface to the core Win32 functionality.

It seems like there should be some appeal in a clean modern Win32 API wrapper that compiles down to almost nothing and doesn't impose design decisions like using XML to define UI layout. That would allow higher-level frameworks like UWP to be implemented in a dialect that isn't so disgustingly arcane.

It sound like you want a wrapper that does nothing but change SHOUT to CamelCase. A lot of work to for a developer only cosmetic.

What are you doing in UWP that's arcane?

Please read more carefully; I think you missed the point of more than one comment in this thread, so your reply comes across as too dismissive. A modern wrapper around Win32 would offer real advantages beyond just renaming things, such as greater type safety and less namespace pollution.

And I didn't imply that such a thing would have benefits for authors of UWP applications, but for the implementors of UWP itself and other frameworks that build atop raw Win32.

A while back I noticed a trend of Window C programmers (often game developers) writing their own minimal Windows.h to reduce compilation times. If you're already doing that, modifying the identifiers or adding preprocessor aliases to match your preferred style wouldn't be so much effort. But then again, you'd be rather committing yourself to maintaining your custom header indefinitely.

Personally, I have several complaints about the Win32 API (not least the ridiculous situation with long paths and having to prefix them with \\?\, which I've been dealing with lately), so the Hungarian naming barely registers as a problem, despite my distaste for it.

Reply on news.ycombinator.com