Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microsoft Throws in the Towel on UWP, Elevates Win32

extremetech.com

Post reply on HN
Print view View original

31–40 of 104 posts

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

#31

Post by MaulingMonkey »

bpye wrote: post #8
monocasa wrote: 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...

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.

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

#32

Post by eganist »

muststopmyths wrote: post #29

About 7 years too late. This thing should have been drowned in the bathtub when it was called WinRT. An excellent example of the hubris of the Windows division, leading to the demise of Windows Phone (and Windows in due course). The genius who convinced Microsoft to throw its weight behind an API completely incompatible with everything they had done before should be lauded for chutzpah. They couldn't have done a bett…

Ideologically, I'm opposed to the assertions you've made in these two paragraphs primarily because the bloat and backwards compatibility requirements made innovation more difficult given the diversity of hosts which had to be supported.

But I'll acknowledge that I've got a substantial bias here considering I both keenly observed and to a very modest extent contributed to external coverage of the development of the platform reboots conceived during Longhorn/Vista/7/8 (Avalon/WPF, Indigo/WCF, WinFS, WinRT, some of which succeeded, some of which died) and the efforts to shed legacy platforms dating back almost three decades now.

Why do you believe what you believe? Citations would be helpful, but I recognize we're discussing opinions.

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

#33

Post by userbinator »

teddyuk wrote: post #22
codeflo wrote: post #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…

Electron gets a lot of stick but you can write good looking cross platform applications easily. Until someone does something better that isn’t single platform it has to be here to stay

A lot of people, including me, do not think that "good looking" and "native looking" should be any different, and for that, Electron is a failure --- native applications use the UI of the platform and are consistent with other applications on the platform, while Electron applications obviously look different from them, and have the same look regardless of platform, completely ignoring the standard native UI it provides. They don't conform to the customisations I do to the native UI of the platform, which is very frustrating. There's also the unmistakable RAM usage and general sluggishness.

From that perspective, it's not really "cross platform", since you're just developing for one platform that happens to run inside many others: a web app.

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

#34

Post by Iwan-Zotow »

pcwalton wrote: post #9
kitsunesoba wrote: post #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.

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 is COM, component object model, it is language-independent thing in itself

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

#35

Post by Iwan-Zotow »

pcwalton wrote: post #16
userbinator wrote: post #14

Earlier quoted context omitted.

It can be used from C but is a huge pain that makes it obvious whoever designed the interface (or COM in general) really went off the deep end with the abstraction level. There's a major difference between a C API designed to be used from C (Win32, POSIX) and one that only happens to be usable from C. Compare a sane "C API designed to be used from C": https://docs.microsoft.com/en-us/windows/desktop/dlgbox/usin... th…

Also, that code isn't C, it's C++. Method calls are a C++ feature. While you could use COM without language support for method calls, because the ABI is stable, it isn't really something that Microsoft supports.

Of course Microsoft supports it, why not? There is no magic in COM, had COM object written in C

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

#36

Post by snaky »

maxxxxx wrote: post #23
userbinator wrote: post #14

Earlier quoted context omitted.

It can be used from C but is a huge pain that makes it obvious whoever designed the interface (or COM in general) really went off the deep end with the abstraction level. There's a major difference between a C API designed to be used from C (Win32, POSIX) and one that only happens to be usable from C. Compare a sane "C API designed to be used from C": https://docs.microsoft.com/en-us/windows/desktop/dlgbox/usin... th…

Without a language that wraps the naked COM calls it's truly a nightmare. Using COM from C# is pretty OK and VB6 was great too. C++ is worse. To me COM is like an assembly language for interop that needs to be wrapped with higher language constructs. You could probably write a few C macros to reduce the boilerplate code a lot.

ATL and WTL are such bunches of macros actually, but for C++.

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

#37

Post by maxxxxx »

kg wrote: post #24
starik36 wrote: post #15

Earlier quoted context omitted.

I gave up on chasing every new shiny thing MS produces. Winforms work great. They are stable - there are a million packages for it out there and it can work with the version of the framework that's installed with every copy of Windows.

And it's open-source now! I'm looking forward to people creating a better, more portable winforms even if we can't get it from Microsoft.

Doesn't Mono have Winforms already?

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

#39

Post by Varriount »

mastax wrote: post #11
kitsunesoba wrote: post #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.

This has improved recently. WinRT is basically just COM + IInspectable so it's possible to use from any language that supports the msvc abi. The gist is that Microsoft ships .midl files which can then be used to generate bindings. C++: https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-a... Rust: https://crates.io/crates/winrt C: https://stackoverflow.com/questions/7436144/using-winrt-from... etc.

Hm. Where's the actual documentation on the MIDL format, or the ABI, or how it should be translated?

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

#40

Post by lopmotr »

maxxxxx wrote: post #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.

I use WinForms, DirectX9, and .Net 2.0. It's been rock solid for about a decade or more and no sign of that being about to change. I just ignore all the new app store, WPF, UWP, Metro style, etc. stuff.
Post reply on HN