Live data from Hacker News

Microsoft Throws in the Towel on UWP, Elevates Win32

extremetech.com

41–50 of 104 posts

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

#41
post #28

Earlier quoted context omitted.

If you read the article, it doesn't sound like anything is being abandoned, so I'm not sure how your comment is relevant here. MS does have a tradition of abandoning products (like some other infamous tools vendors) but UWP isn't being abandoned according to the article.

I think we have distinguish between UWP as UI toolkit and UWP for as library for system functions. The latter will stay but I am really doubtful about the former. I don't know of any aspect where UWP UI ie better than WPF or Win32 so I doubt it will get more than the little adoption it already has.

Windows.UI.Composition makes the UWP UI toolkit way better than anything that came before it.

https://blogs.windows.com/buildingapps/2016/09/16/animations...

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

#42
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 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.

Too bad Winforms is butt ugly.

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

#43
post #40
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.

.net 3.0 is new, lulz

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

#44

Earlier quoted context omitted.

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

I don't mean that calling COM objects from C doesn't work. I just mean that COM isn't designed to be used from C.

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

#45
post #32

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 pl…

Fair enough. Let me lay this out as a long time Windows developer and someone who loved Windows Phone 7/8 compared to iOS and Android.

1. The first version of WP7 was fine. Silverlight was a pretty mature technology and there was developer interest (at least in the Microsoft ecosystem).

2. WP8 (and Windows 8) came out with WinRT. This was incompatible with existing ways of writing Windows code, so you couldn't bring (almost) any legacy code over. This means that extensive porting efforts were required for code that used to work fine on Win32. This was particularly brutal for open source libraries (like OpenCV/OpenSSL etc.) which were sorely necessary if you wanted to target all 3 mobile platforms.

In addition there was a much smaller API surface. Bluetooth LE or VPN APIs for example never came out until too late. You couldn't even create COM ports (necessary for GPS dongles) in a Windows 8 (not mobile, just regular desktop) WinRT/UAP app. So Win32 applications would work just fine on Windows 8, but if you wanted they fancy new features, you were either SOL or had a long development cycle ahead of you. The forced async paradigm also added massive complexity for cross-platform development.

They failed to see people rapidly losing interest in Windows (Charles Petzold's Windows 8 book sold so badly, he gave up on Windows for Xamarin. This is the guy who literally wrote the Bible of Windows GUI programming) and take action to remedy that. Instead, they spent time and effort on half-assing "Bridges" which they then rapidly lost interest in and stopped supporting.

It's fine to try to shed legacy platforms, but you don't do it at the cost of developer traction, at the very moment when you need them most. They could have done a lot more to make it easier for developers to bring code over. MS OpenTech, for example, was a worthy initiative that again got killed too soon.

So, my opinion is that nothing but hubris explains the decision to go down the road of abandoning Win32 at a time when Microsoft needed its developers more than anything else.

Having worked at Microsoft way back in the day, I've seen many bad ideas get pushed out, but Microsoft always used to treat developers with respect. WinRT was just a massive slap in the face in comparison.

*edited formating

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

#46
post #22

Earlier quoted context omitted.

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 provid…

Is there really a Windows native look anymore? Every application seems to have a completely different UI style now. The old days of dialog boxes all having the same Winforms controls are gone and now they're a random mixture, even within Windows itself. The tabs in Chrome are not like the tabs in Excel which are not like the tabs in Paint3D. It's all over the place.

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

#47
post #22

Earlier quoted context omitted.

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 provid…

I honestly think the days of the cohesive desktop platform are done. It arguably reached its peak with OS X (perhaps circa Snow Leopard), but the idea has been falling into disrepair even on the mac. It's hard to see any strong force moving us back to it, but given the current situation, if I were a desktop app developer I don't think it's something I would consider it worth investing too much effort in.

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

#48
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…

WinUI is just a new name for the UWP UI stack now that it is open source and decoupled from the OS, React Native is a wrapper on top of UWP/WinUI, and WPF isn't really getting significant new features other than being taken open source and ported to .net core. So really already there's just one forward-looking native UI stack, which is WinUI.

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

#49
post #9

Earlier quoted context omitted.

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

Perhaps language-hostile would better describe it. Sure you can use it from any language that has some sort of ffi, but without compiler support it will not be pleasant.

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

#50
post #11

Earlier quoted context omitted.

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?

[deleted]
Post reply on HN