3 ms·
VirtualProtectFromApp has the exact same signature as VirtualProtect, just supporting fewer constants and being legal in UWP apps. I don't suppose you have any
by MaulingMonkey 7y ago
VirtualProtectFromApp has the exact same signature as VirtualProtect, just supporting fewer constants and being legal in UWP apps. I don't suppose you have any insight as to why Microsoft forced this kind of API churn? Why I have to lace my code with #ifdef s to support both UWP Apps and earlier OSes? What's the upside? I feel like VirtualProtect could've just supported fewer constants inside the sandbox.
Maybe to limit sandbox attack surface? Or working around KnownDLLs pinning perhaps? But even then, why not provide forwarding stubs instead of forcing all UWP devs to write their own or #ifdef spam? Time constraints before shipping Windows 8?
This style of API churn - not limited to VirtualProtect, and often with only newfangled COM C++/CX bindings for replacement APIs - definitely put me off UWP App dev, and I just don't see what the upside was supposed to be for anyone. Lots of extra work, mostly just to lose functionality.
- jdsully 7y agoBecause the UWP code under the hood calls the real VirtualProtect. It’s to avoid the name conflict. Fun fact: your UWP app also links in gdi.dll and user32 as well.