2 ms·
I believe this was true at one point, but isn't any more. Whilst you cannot allocate executable memory, you can use VirtualProtectFromApp to remap memory as exe
by bpye 7y ago
I believe this was true at one point, but isn't any more. Whilst you cannot allocate executable memory, you can use VirtualProtectFromApp to remap memory as executable [1]. UWP does enforce W^X though. You do need the codeGeneration capability.
(Disclaimer, work for Microsoft - made LuaJIT run on UWP in my free time, this definitely works :) )
[1] - https://docs.microsoft.com/en-us/windows/desktop/api/memoryapi/nf-memoryapi-virtualprotectfromapp https://docs.microsoft.com/en-us/windows/desktop/api/memorya...
- MaulingMonkey 7y agoVirtualProtectFromApp 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.