Microsoft Throws in the Towel on UWP, Elevates Win32
extremetech.com
extremetech.com
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 line, my guess is that very few people will be hurt by this decision. They've all moved to greener pastures long ago.
I'd probably choose Qt.
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.
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.
- vb com+ - c++ dcom - c++ mfc - .net 1.1 winform - .net 4 - wpf - delphi
Microsoft causes this by events like build which go “we are betting everything on x” then the year later it is “x was cool but look at xx”
Gahhhhhh
https://www.mono-project.com/news/2019/02/13/plastic-scm-a-f...
https://blogs.windows.com/buildingapps/2016/09/16/animations...
Silverlight, Winforms, MFC, etc. still all work perfectly fine.
Compare a sane "C API designed to be used from C":
https://docs.microsoft.com/en-us/windows/desktop/dlgbox/usin...
that involves nothing more than initialising a structure and calling a single function, with MS's "recommended replacement" using COM:
https://msdn.microsoft.com/en-us/library/Bb776913(v=VS.85).a...
That is a ten level deep nested if with just as many function calls, to do essentially the equivalent of the code above. The first time I saw this, I seriously thought they were taking the piss.
Naturally OLE was designed as C framework back in Win16 days, with endless pages of boilerplate code.
https://www.amazon.com/Windows-Programmers-Guide-Book-Disk/d...
As such COM can be called from C, specially since C++ Windows compilers have a VTBL layout as if they were a plain old C struct with function pointers.
However unless one is masochist, it is not sane to use COM from bare bones C.
WTL is definitely "deep" C++. Templates, multiple inheritance, and more.
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) anytime you have an error code to check. CHK being defined as something like “if(FAILED(hr)) goto Error;”. This is how error handling for non-trivial functions is done in any serious C code, regardless of the platform. One common pattern is actually to just put the entire line of code inside the macro, so your code would look like CHK(hr = AWin32Function(param1, param2)). You can get real cute and even have the macro assign hr for you, so you can drop the “hr =“ from your code.
I worked on Windows at Microsoft and with very few exceptions, the only time I saw the pyramid-of-doom was in the public documentation. I wonder if was just bowing to the irrational hostility some people have to any use of goto, even though this is a highly structured pattern that should be uniform across your codebase, the opposite of unstructured, ad-hoc uses of goto that are the actual problem.
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.
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.
kind of swig for com/winrt supporting just now only c++ and python https://github.com/Microsoft/xlang/wiki/xlang-faq
I don’t see why you couldn’t write a UWP app in pure C, you’d just need a shitload of boilerplate and glue to make it sane to work with.
Though the C++ projection contains quite a bit of boilerplate itself, so... shrug
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.
Until someone does something better that isn’t single platform it has to be here to stay
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.
The standard tab control looks like this:
https://docs.microsoft.com/en-us/windows/desktop/controls/ta...
There is a (probably incomplete) list of standard controls here, I believe the documentation for each one contains screenshots of what they look like:
https://docs.microsoft.com/en-us/windows/desktop/controls/in...
That said, Chrome's tabs are (at least the last time I checked) actually bitmap images, Excel's tabs are also probably custom-drawn yet fortunately aren't bitmaps (just judging by how they look), and I believe Pain(t)3D is actually UWP.
Not perfect (what is?), and many of the longstanding apps are still around, but the steam has arguably gone out of the platform.
This is not a binary question of either a desert or either a rainforest, but Apple's side of the fence is definitely a lot greener than Microsoft's in terms of UI/UX consistency.
I was a purely PC/MS user up until about 10 years ago, but I haven't suffered as many befuddled facepalm moments from Apple's UI decisions as from the Escheresque nightmare that Microsoft is even now.
> The flag-carrying apps (Adobe, Final Cut, Garageband) had custom UIs. Built ins like Calendar had skeumorphic UIs.
However, almost every macOS app has the same standard menus, same standard shortcuts, and most of them support the same OS extensibility features. Even as a developer you just need to build against the latest AppKit and you get not only all the current features, but usually future features for free too (e.g. most of the NSDocument stuff such as autosaving and previous versions.)
Compare this to the hodgepodge of different interfaces even in Windows' builtin apps alone, and championing a different API almost every other year.
And they announced that WinUI 3.0 will open source all built-in XAML controls (they are even rewritten some to be on top of Composition because of that), will also open the XAML Stack and Composition.
This is a big deal.
Microsoft.MicrosoftEdgeWin32_8wekyb3d8bbwe
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 better job of destroying Windows, if that was their goal.
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.
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
[0] https://docs.microsoft.com/de-de/windows/uwp/winrt-component...
UWP meant dropping support for old Windows, you can't even access the filesystem (open a playlist file? Unzip an archive? Open subtitle files? Nah), and you can only publish on Windows Store which nobody visits. It didn't catch on.
I feel for the developers at MS building a platform nobody would use. Until this announcement.
Compare with gtk, which breaks backward compatibility liberally. After a few versions, old applications stop working unless someone takes the time to fix them. This means application progress is reset again and again. We lose tons of old code for no good reason. OTOH, the old tools written in win95's win32 or in x11's xlib (or posix, mother of all stable APIs), still work 20 years later. This means you can focus on improving instead of rebuilding.
Don't get me wrong: Backwards compatibility is a cost. But I'd rather have to pay it once, centrally, instead of distributed over all applications. Very rarely you can deprecate and fix a small part. But in general, libraries are the ground upon which applications are built. That ground should be stable.
BTW, I fear the damage wayland will do to the linux ecosystem.
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.
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.
(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...
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.
Fun fact: your UWP app also links in gdi.dll and user32 as well.
(Excluding the platform-holder’s own JIT’s, of course.)
DVD players, microwaves, and even game consoles are single-purpose computing devices, designed to do one thing. I'm having a lot of trouble putting iPhones and iPads in that category. As terribly locked down as they are, they're still very much "general purpose".
And BTW, I think Microsoft's goal was quite clearly for UWP to be as locked down as iOS.
I’d only call the last element of that chain “general-purpose” — to me, one requirement for earning that label is the ability to write and compile programs. If I can’t write iOS apps from inside iOS, it isn’t general-purpose.
> Regardless, the idea that consumers would shift their application acquisition behavior just because Microsoft wanted it was a poor idea that ought to never have been implemented in the first place. It’s good to see the company catching up to the place its customers never left.
That just about sums it up for me. Good on Microsoft, I guess.