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

81–90 of 104 posts

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

#81

Post by tonyedgecombe »

ungzd wrote: post #74
elorant wrote: post #12

Earlier quoted context omitted.

It's simple. You wait for five years before you start developing in any given technology. By that time it will either have been substituted or polished. UWP was a clustefuck from the beginning, especially after everyone realized that MS intended to give-up on mobile. There aren't many people who bought into it and given Microsoft's infamous support for legacy code it's no surprise that they decided to tank it. Bottom…

Suppose I'm going to add simple Windows gui for an app today, what should I use out of > 5 year old technologies? WinAPI in classic way, using Petzold's "Programming Windows, 4th edition" as a guidebook? WinAPI wouldn't be enough, I suppose, so can I use at least Comctl32 or is it deprecated? Should I use MFC? ATL? COM? Or should I use WinForms with .NET? Even if my app is written in native code? Isn't it for "busine…

None of it is going away, the problem is it doesn't get the attention it deserves. All the while Microsoft is busy introducing UWP or whatever comes next they are ignoring everything that came behind it.

On the subject of cross platform I wouldn't go for qt or anything like it unless I really needed it. All those frameworks are too compromised if you are targeting a single platform. Possibly even if you aren't.

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

#82

Post by _pmf_ »

muststopmyths wrote: post #45
eganist wrote: post #32

Earlier quoted context omitted.

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…

I actually bought this particular book to make sense of the mess (i.e. 80% of the API surface missing), but of course it did not help here. The way to brigde UWP and regular Win32 APIs was described in this utterly kafkaesque document[0], which was the point where I decided that this is a complete deadend. I implore anyone to read it, and remember: this was the solution to a problem that could have been solved by importing a DLL in any sane ecosystem.

[0] https://docs.microsoft.com/de-de/windows/uwp/winrt-component...

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

#83

Post by userbinator »

ungzd wrote: post #74
elorant wrote: post #12

Earlier quoted context omitted.

It's simple. You wait for five years before you start developing in any given technology. By that time it will either have been substituted or polished. UWP was a clustefuck from the beginning, especially after everyone realized that MS intended to give-up on mobile. There aren't many people who bought into it and given Microsoft's infamous support for legacy code it's no surprise that they decided to tank it. Bottom…

Suppose I'm going to add simple Windows gui for an app today, what should I use out of > 5 year old technologies? WinAPI in classic way, using Petzold's "Programming Windows, 4th edition" as a guidebook? WinAPI wouldn't be enough, I suppose, so can I use at least Comctl32 or is it deprecated? Should I use MFC? ATL? COM? Or should I use WinForms with .NET? Even if my app is written in native code? Isn't it for "busine…

so can I use at least Comctl32 or is it deprecated?

Of course you can. The Common Controls are part of Win32 in the same way that user32 and gdi32 are.

Also worth noting that Microsoft is in the unique position that they do not want to break countless applications and realise that backwards compatibility is their strong point and a major reason why people use Windows, so even if something is "deprecated", unless it's related to some low-level system functionality, chances are it is not going to stop working. I'd say that they use "deprecation" more as a way of marketing newer-but-not-necessarily-better technologies.

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

#84

Post by la_barba »

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'd be curious to know if you are still using a web toolkit from 10 years ago.

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

#85

Post by userbinator »

wildmusings wrote: post #75
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…

It’s funny that they use that awful pyramid-of-doom error handling style in a lot of the public documentation. The correct way is to have an “Error:” label at the end of the function before all the cleanup code. After calling any function that can return an error code, you check the error code and “goto Error” if necessary. You can encapsulate that whole logic in a macro so you just call something like CHK(hr) anytim…

True, the error handling could be better, but my main point was really to say that much of that code should not even be necessary; the majority of those calls are really just doing the equivalent of setting a field in a structure in the old way.

Furthermore, because it's a function call and "could" fail, "best" (more like dogmatic) practice dictates that the return values must be checked, despite the fact that failure means something was really wrong (like the hardware failing) and there's no way to recover from that, and you can argue that point as much as you like but your corporate-drone manager isn't going to care, only about whether you're "following the standards" and his precious metrics that are just as uncaring. (That's a rant for another day.)

On the other hand, no one argues whether you need to check for errors when using assignment statements. Doing it the old way is so much simpler and avoids the whole aforementioned argument issue around pointless error-checking.

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

#86

Post by la_barba »

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…

It might be "fun" to dump on MS, but the thing with MS tech is that, like it or not, it definitely 'sticks around'. They are probably the best in business at ensuring backwards compatibility. At work we're using windows apps that were sold in 2006, on W10. And these are fairly complicated analytical equipment control softwares that work over COM (well.. usb emulated now). I don't know if you can install and run applications from 13 years ago on any other modern platform.

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

#87

Post by dragontamer »

maxxxxx wrote: post #77
snaky wrote: post #36

Earlier quoted context omitted.

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

ATL yes, I think WTL is macros around Win32.

WTL is built on top of ATL. Both use C++ isms, like curiously recurring template pattern.

WTL is definitely "deep" C++. Templates, multiple inheritance, and more.

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

#88

Post by mastax »

Varriount wrote: post #39
mastax wrote: 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?

https://docs.microsoft.com/en-us/windows/desktop/midl/midl-s...

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

#89

Post by bpye »

bni wrote: post #69
mhermher wrote: post #56

Earlier quoted context omitted.

The only people who ever bring this up are all on HN. Spotify is electron, vs code is electron, slack is electron. I have them open all day, and never even notice.

Spotify is not electron

Desktop Spotify does use CEF though doesn't it? Whilst it might not be electron it's a similar idea

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

#90

Post by maxxxxx »

dragontamer wrote: post #87
maxxxxx wrote: post #77

Earlier quoted context omitted.

ATL yes, I think WTL is macros around Win32.

WTL is built on top of ATL. Both use C++ isms, like curiously recurring template pattern. WTL is definitely "deep" C++. Templates, multiple inheritance, and more.

I worked a little with WTL a while ago and it felt like MFC done right.
Post reply on HN