
Microsoft Throws in the Towel on UWP, Elevates Win32 - walterbell
https://www.extremetech.com/computing/291124-microsoft-throws-in-the-towel-on-uwp-elevates-win32
======
maxxxxx
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.

~~~
starik36
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.

~~~
teddyuk
I have seen systems developed over decades and they are a complete mess, the
worst had these components:

\- 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

~~~
starik36
VB6 forms designer was actually really good. I don't there is still anything
that rivals it in terms of stability, customization, speed and round-tripping.

------
kitsunesoba
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.

~~~
pcwalton
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).

~~~
ChrisSD
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.

~~~
userbinator
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...](https://docs.microsoft.com/en-
us/windows/desktop/dlgbox/using-common-dialog-boxes#opening-a-file)

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...](https://msdn.microsoft.com/en-
us/library/Bb776913\(v=VS.85\).aspx#basic_usage)

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.

~~~
pcwalton
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.

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

~~~
pcwalton
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.

~~~
tonyedgecombe
Actually I think it was, that was the lowest common denominator.

~~~
pjmlp
Not really, COM is a subset of OLE 2.0, designed to replace VBX as OCX
originally.

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...](https://www.amazon.com/Windows-Programmers-Guide-Book-
Disk/dp/0672302268)

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.

------
codeflo
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.

~~~
teddyuk
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

~~~
userbinator
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.

~~~
crispinb
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.

~~~
lozenge
Maybe my memory is bad but I don't think OS X ever really had it. The flag-
carrying apps (Adobe, Final Cut, Garageband) had custom UIs. Built ins like
Calendar had skeumorphic UIs.

~~~
Razengan
> _Maybe my memory is bad but I don 't think OS X ever really had it._

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.

------
muststopmyths
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 better job of destroying Windows, if
that was their goal.

~~~
eganist
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.

~~~
muststopmyths
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

~~~
_pmf_
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...](https://docs.microsoft.com/de-de/windows/uwp/winrt-
components/brokered-windows-runtime-components-for-side-loaded-windows-store-
apps)

------
monocasa
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.

~~~
bpye
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...](https://docs.microsoft.com/en-
us/windows/desktop/api/memoryapi/nf-memoryapi-virtualprotectfromapp)

~~~
MaulingMonkey
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.

~~~
jdsully
Because the UWP code under the hood calls the real VirtualProtect. It’s to
avoid the name conflict.

Fun fact: your UWP app also links in gdi.dll and user32 as well.

------
userbinator
Discussed yesterday on a different article:
[https://news.ycombinator.com/item?id=19873198](https://news.ycombinator.com/item?id=19873198)

------
mgamache
The MS app store and UWP died with the death of Windows Mobile. UWP was MS'
strategy to have a united mobile and desktop experience (just like Apple is
trying to do now with OSX + iOS). No mobile == no incentive to develop UWP.
There were already hacks for Win32 to use the non-UI APIs from UWP (that's a
lot of acronyms) so you could already do most or the UWP stuff with Win32. The
new strategy starting with UWP islands is just how they are staring to
integrate the UWP offerings with WPF/Winforms officially. I like the UWP UI,
but developing the apps is a pain due to the sandboxing (as compared with old
Win32).

------
neltnerb
I'm not quite sure I know enough to guess, does this suggest that new normal
desktop applications may soon be able to take advantage of a unified upgrade
mechanism rather than every program rolling their own?

------
homero
Some of my apps moved to the app store but i couldn't use them on Windows 7.
So i stopped using them and made sure to never use the windows store even if i
get win 10 someday.

------
Wowfunhappy
> One wonders what Gallo thinks Windows applications used to be called.

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

------
philliphaydon
UWP isn’t dead??? It was demoed at build....

~~~
pjmlp
Many naysayers love to use any misinformation to spread FUD, although it is
clear from BUILD and MSDN, where all is going.

------
rkagerer
Finally. It was a massive mistake from the get-go.

