Live data from Hacker News

Microsoft Throws in the Towel on UWP, Elevates Win32

extremetech.com

1–10 of 104 posts

Re: Microsoft Throws in the Towel on UWP, Elevates Win32

#4
I watched the videos for every session from the current Build conference I could find on this topic, but still don’t understand the strategy. Like at all. Listing the GUI toolkits that Microsoft is currently investing in, there’s UWP, WPF, React Native and also a new thing called WinUI. Not all of them will survive (by which I mean will continue to get significant new feature releases say three years from now).

So it’s not clear to me at all why I should bet on any of them and not just use Electron, which is in a lot of ways worse, but at least guaranteed to stick around.

Re: Microsoft Throws in the Towel on UWP, Elevates Win32

#5
Win32‘s continued popularity (vs UWP) I’m sure has at least partially to do with how it’s all plain C, which makes it simple to support with any programming language imaginable via bindings. If they were serious about pushing UWP adoption they should’ve provided plain C bindings for it so it could be used with Rust or Python or Swift or whatever. C# and C++ aren’t everybody’s cup of tea.

Re: Microsoft Throws in the Towel on UWP, Elevates Win32

#6
How do they expect desktop developers to bet on anything MS does? Since .NET came out they constantly keep changing direction without any cohesive strategy. The server development strategy looks pretty good with MVC and now Core. But desktop development is just terrible. If I have to write a new app I will either think about making it web based or maybe use qt but I think I will avoid any MS UI toolkit.

Re: Microsoft Throws in the Towel on UWP, Elevates Win32

#7
post #3

Thank god. Among other things UWP didn't allow PAGE_EXECUTE on the memory mapping calls, meaning that JITs were disallowed. That's pretty core to general purpose computing in a real way, IMO.

The DLR was nerfed because of this: no JIT, just interpreted. Really slowed down my live programming implementations.

Also, I remember deploying some code to a surface Hub, my C# build for that took 40 minutes to an hour. Not fun.

On the other hand, it did make me learn some web development to do UIs.

Re: Microsoft Throws in the Towel on UWP, Elevates Win32

#8
post #3

Thank god. Among other things UWP didn't allow PAGE_EXECUTE on the memory mapping calls, meaning that JITs were disallowed. That's pretty core to general purpose computing in a real way, IMO.

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/memorya...

Re: Microsoft Throws in the Towel on UWP, Elevates Win32

#9

Win32‘s continued popularity (vs UWP) I’m sure has at least partially to do with how it’s all plain C, which makes it simple to support with any programming language imaginable via bindings. If they were serious about pushing UWP adoption they should’ve provided plain C bindings for it so it could be used with Rust or Python or Swift or whatever. C# and C++ aren’t everybody’s cup of tea.

Win32 isn't plain C. Lots of Win32 functionality is only accessible via COM, which is C++ (though using only a small subset of features so as to achieve ABI stability).

Re: Microsoft Throws in the Towel on UWP, Elevates Win32

#10
post #9

Win32‘s continued popularity (vs UWP) I’m sure has at least partially to do with how it’s all plain C, which makes it simple to support with any programming language imaginable via bindings. If they were serious about pushing UWP adoption they should’ve provided plain C bindings for it so it could be used with Rust or Python or Swift or whatever. C# and C++ aren’t everybody’s cup of tea.

Win32 isn't plain C. Lots of Win32 functionality is only accessible via COM, which is C++ (though using only a small subset of features so as to achieve ABI stability).

COM isn't C++. It's a language independent interface. There's no reason why COM (and therefore UWP) can't be used from C.
Post reply on HN