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.
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 line, my guess is that very few people will be hurt by this decision. They've all moved to greener pastures long ago.
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 "business apps" only? Can I use it to write another Winamp?
There is no clear choice in windows desktop anymore. Only obsolete or soon to be obsolete options. If I had to do it now my first choice would be to go web based, then qt or WPF. Electron looks very appealing too. Pretty sad but it looks like MS doesn’t care about the desktop much anymore.
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.
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.
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.
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.
Pretty sure they've fixed that in recent releases (within 18 months, I believe) of Windows 10. You should only need to recompile to gain hi-DPI awareness, if I recall properly.
No, there are still problems. My understanding is there will be further work on the .Net Core version although I haven't paid any attention to that so far.
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.
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.
Desktop development was a dream with Delphi but Microsoft decided to compete against it and then undermine it instead of supporting it. Not just a dick move, but DaF.
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).
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":
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.
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.
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.
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.
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) 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.
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.
You should always check the return value for an error, no matter what. I would not suggest otherwise. Whatever the source of the failure, you want to explicitly fail in a defined way rather than have your application behave in unexpected ways, potentially destroying user data or otherwise misbehaving.
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.
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.
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.
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.
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.
Yes, I believe the inconsistencies started with Vista, and has gotten worse since then, but the parts they didn't change still have the consistent normal Win32 style.
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.
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.
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.
Oh, true of course, especially from the big guns. But there was a flourishing ecosystem of great apps like Textmate, Things, Acorn, and a bunch of others from outfits like Omnigroup, Panic, IconFactory. These tended to fit beautifully on the platform, and not just in aesthetic terms, but functionally with reasonably consistent keyboard shortcuts, AppleEvents support, etc.
Not perfect (what is?), and many of the longstanding apps are still around, but the steam has arguably gone out of the platform.
> 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.
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.
Depends on personal preferences I guess. I generally find "native" interfaces poorly suited to productivity. In fact even Microsoft agrees which is why they have UI of their Office products running on a highly contextually customized ribbon interface and visual cue based context menus which use transparency to hint at options. I similarly find Electron based apps usually focus on usability rather than throwing a million option into menus or cluttered toolbars which is the default "native" UI.
Flutter for desktop is in early stages currently, but in theory it could deliver apps that look & feel like Electron apps but with much better performance.
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.
Maybe, but how does that square with the widespread assumption that UWP and the store are basically dead? Do you expect WinUI to be available in desktop apps eventually? There’s something called “XAML Islands” to integrate UWP components into desktop apps, but that’s technically ugly, incomplete, and very explicitly targeted at legacy applications. Beyond that, they didn’t announce anything as far as I can tell.
Windows Terminal will be distributed on Store, and so do new Edge. I don't know why people are calling it dead...
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.
Neither old or new Edge is being distributed on Store. Old one gets bugfixes from Windows update and new features come with the big biannual Windows updates. New one uses it's own updater. They also removed ability to install Office from store.
Maybe, but apps are already using XAML Islands - the new Windows terminal does its entire UI in one big XAML Island. There's talk of a new XAML Desktop project/app type that would basically formalize this pattern: https://twitter.com/pag3rd/status/1126940080294154241
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.
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.
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.
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.
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.
.NET was available for old versions of Windows, had full capabilities, and could be distributed any way. It caught on.
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.
To be honest, I'm completely of the opposite opinion. Backwards compatibility means I don't have to rewrite anything again and again and again.
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.
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 :) )
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.
How do you define "general-purpose computing", then?
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.
Well, it’s a spectrum. Microwaves < Game consoles < iPhones < laptops/desktops.
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.
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).
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?
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.
> 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.
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.
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 line, my guess is that very few people will be hurt by this decision. They've all moved to greener pastures long ago.
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 "business apps" only? Can I use it to write another Winamp?
I'd probably choose Qt.
There is no clear choice in windows desktop anymore. Only obsolete or soon to be obsolete options. If I had to do it now my first choice would be to go web based, then qt or WPF. Electron looks very appealing too. Pretty sad but it looks like MS doesn’t care about the desktop much anymore.
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.
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.
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.
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
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.
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?
Yes, but I don't personally know how complete it is. The only company using it that I'm aware of is Plastic SCM.
This is how we use it:
https://www.mono-project.com/news/2019/02/13/plastic-scm-a-f...
Too bad Winforms is butt ugly.
It looks native, it's fine. The problem I've found is high-dpi support is still a dogs dinner.
Pretty sure they've fixed that in recent releases (within 18 months, I believe) of Windows 10. You should only need to recompile to gain hi-DPI awareness, if I recall properly.
No, there are still problems. My understanding is there will be further work on the .Net Core version although I haven't paid any attention to that so far.
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...
WinUI is actually open source, and WinUI 3.0 will open-source all XAML controls, XAML Stack and Composition.
But when will MS lose interest in this too and do something else? I don’t think it can live as open source without a lot of MS support.
Well, this also work for everything MSFT launches. Not exclusive to UWP or anything.
Does it matter what flavor of the month they focus on, as long as they don’t drop support for things?
Silverlight, Winforms, MFC, etc. still all work perfectly fine.
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
Not here, please.
I'd be curious to know if you are still using a web toolkit from 10 years ago.
Desktop development was a dream with Delphi but Microsoft decided to compete against it and then undermine it instead of supporting it. Not just a dick move, but DaF.
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 isn't C++. It's a language independent interface. There's no reason why COM (and therefore UWP) can't be used from C.
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...
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.
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.
I remember using C to call com components as a learning excercise - it was just that to see how it worked. You wouldn’t do it otherwise
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.
Actually I think it was, that was the lowest common denominator.
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...
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.
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++.
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.
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) 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.
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.
You should always check the return value for an error, no matter what. I would not suggest otherwise. Whatever the source of the failure, you want to explicitly fail in a defined way rather than have your application behave in unexpected ways, potentially destroying user data or otherwise misbehaving.
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.
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?
its open sourced https://github.com/Microsoft/xlang
kind of swig for com/winrt supporting just now only c++ and python https://github.com/Microsoft/xlang/wiki/xlang-faq
https://docs.microsoft.com/en-us/windows/desktop/midl/midl-s...
COM has always supported C. Go and look at any headers generated by MIDL and you’ll see a C variant of the interfaces.
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
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.
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
As a long time Windows desktop dev I am horrified to say that Electron looks really attractive as dev platform on Windows :-)
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.
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.
Yes, I believe the inconsistencies started with Vista, and has gotten worse since then, but the parts they didn't change still have the consistent normal Win32 style.
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.
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.
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.
Oh, true of course, especially from the big guns. But there was a flourishing ecosystem of great apps like Textmate, Things, Acorn, and a bunch of others from outfits like Omnigroup, Panic, IconFactory. These tended to fit beautifully on the platform, and not just in aesthetic terms, but functionally with reasonably consistent keyboard shortcuts, AppleEvents support, etc.
Not perfect (what is?), and many of the longstanding apps are still around, but the steam has arguably gone out of the platform.
> 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.
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
Depends on personal preferences I guess. I generally find "native" interfaces poorly suited to productivity. In fact even Microsoft agrees which is why they have UI of their Office products running on a highly contextually customized ribbon interface and visual cue based context menus which use transparency to hint at options. I similarly find Electron based apps usually focus on usability rather than throwing a million option into menus or cluttered toolbars which is the default "native" UI.
Flutter for desktop is in early stages currently, but in theory it could deliver apps that look & feel like Electron apps but with much better performance.
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.
Maybe, but how does that square with the widespread assumption that UWP and the store are basically dead? Do you expect WinUI to be available in desktop apps eventually? There’s something called “XAML Islands” to integrate UWP components into desktop apps, but that’s technically ugly, incomplete, and very explicitly targeted at legacy applications. Beyond that, they didn’t announce anything as far as I can tell.
Windows Terminal will be distributed on Store, and so do new Edge. I don't know why people are calling it dead...
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.
Neither old or new Edge is being distributed on Store. Old one gets bugfixes from Windows update and new features come with the big biannual Windows updates. New one uses it's own updater. They also removed ability to install Office from store.
It's coming once it hits final release. :)
Microsoft.MicrosoftEdgeWin32_8wekyb3d8bbwe
Maybe, but apps are already using XAML Islands - the new Windows terminal does its entire UI in one big XAML Island. There's talk of a new XAML Desktop project/app type that would basically formalize this pattern: https://twitter.com/pag3rd/status/1126940080294154241
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.
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.
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.
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
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...
.NET was available for old versions of Windows, had full capabilities, and could be distributed any way. It caught on.
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.
To be honest, I'm completely of the opposite opinion. Backwards compatibility means I don't have to rewrite anything again and again and again.
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.
I bet it was related to Sinofsky and the whole WinDev vs DevTools political issues that also torpedoed the Longhorn and Midori efforts.
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.
The DLR was nerfed because of this: no JIT, just interpreted. Really slowed down my live programming implementations.
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.
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.
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.
iOS also disallows JIT’s. I’m not saying this is okay, but it is quite clearly possible to have a successful software platform without them.
(Excluding the platform-holder’s own JIT’s, of course.)
iOS is not really “general-purpose computing”.
How do you define "general-purpose computing", then?
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.
Well, it’s a spectrum. Microwaves < Game consoles < iPhones < laptops/desktops.
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.
Discussed yesterday on a different article: https://news.ycombinator.com/item?id=19873198
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).
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?
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.
> 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.
UWP isn’t dead??? It was demoed at build....
Many naysayers love to use any misinformation to spread FUD, although it is clear from BUILD and MSDN, where all is going.
Finally. It was a massive mistake from the get-go.