
Windows Kernel Logic Bug Class: Access Mode Mismatch in IO Manager - discreditable
https://googleprojectzero.blogspot.com/2019/03/windows-kernel-logic-bug-class-access.html
======
CoolGuySteve
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.

~~~
pcwalton
> 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.

~~~
wtallis
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.

~~~
cl0ckt0wer
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?

~~~
wtallis
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.

