Windows 10 @ 10: How Microsoft led developers round in circles It is July 2015. Microsoft has just released Windows 10. Developers, weary from the false trail of Windows 8 and being urged to make "Metro style" apps, are now being pitched a new vision from Microsoft: the Universal Windows Platform (UWP). "Developers can now create a single application for the full range of Windows 10 …
Doesn't really matter once it's been compiled to a "native" format but, yeah, XML was soon discovered to completely unsuitable for describing GUIs, which is what Vista tried to use it for because Microsoft wouldn't license DisplayPostscript from Adobe. Just like they'd refused to license Helvetica and dumped Arial on an unsuspecting world. I assume Verdana was a joke like Comic Sans, but someone forgot the punchline.
XML is okay as a configuration format. Okay, as in all the various formats have their pros and contras.
I've heard that mentioned alot, about XML being unsuitable for describing GUIs... Could somebody please elaborate?
When I started an open source game engine remake, I used XML to design the GUI aspects, and it worked fine... even still present in the project today, despite the fact I'm not active in it any more
Out of dotNET UIs... Nothing beats WinForms yet, IMO. We're moving to WPF, but it seems drastically overly complicated. MAUI seemed an incomplete mess (at the time, no idea now). Never even saw tools for WinUI3, despite their claim it's "the way forward".
I still do 99% of my development in WinForms. I've dabbled once or twice with WPF; the results are much nicer (e.g. automatic handling of high-DPI or font scaling) but updating UI elements at run-time is a pain.
The expression I've heard is that "WPF makes complicated things trivial, and trivial things complicated" and I can't disagree.
I dipped my toe into WinUI3 once because I was worried I was becoming a luddite, but when my simple Hello World-level program compiled to something like 100MB of binary and dependencies (unless I wanted to distribute it through the Windows Store), I ran away at high speed screaming "bugger that for a game of soldiers".
Most user interfaces get loaded and then sit around waiting for a user to click something. It largely doesn't matter if the UI is manually built, or loaded from a .res / .rc, or from a XAML, or from a QML or anything else. What kills performance is how the UI is maintained thereafter. e.g. if I have a complex click handler in QML which builds a table then it might be a LOT slower to run that code in JS vs C++, so much so that it is felt by the user or hurts in other ways like memory footprint.
> get loaded and then sit around
The get loaded part takes longer. Sitting around and wait for me to move the mouse is the same speed. But until I see where I can click, after waiting until the button I want has moved two times until loaded, I have to wait. (though the latter is the classical UX part to hate)
Then after the click it takes longer to get in action, then do whatever it should do at (hopefully) normal speed, and then wait longer than before again until the result is on screen.
All that sums up, and if you remember how fast it can be, you get annoyed.
While you are probably technically right, the speed is like a lazy coder typing in the code RIGHT NOW (or copy pastes it from AI generator) as you open an explorer window. Which then gets pushed to some repository to get compiled in an undefined future. Then downloaded to your computer. Then executed, or at least try, since then it has to download the libraries, compile them too, and then finally start so read the directory and display it on the screen. But the display library is missing too, so again download automatically, compile and then draw pixel by pixel the white area, then the darker are above of, and then the icons and so on.
This is how fast ist feels, taking me back to the time when it made a visible difference in Windows 3.11 whether your 386SX16 was running at 16 or 8 MHz.
Microsoft's constant churn and deprecation of programming tools reminds me more of wild horses running in opposite directions to pull a man apart than it does of any coherent planning.
The resulting pain reminds me even more of the poor guy getting torn apart.
Since Microsoft had no real competitor in software development under Windows - Borland being the last that really challenged it with Borland C++ first, and then Delphi - they felt so sure nobody could take away developers for Windows applications they felt free to let loose the company internal fights.
Moreover one of the targets was exactly to ensure nobody could challenge them again. Win32 with its plain C ABI made it too easy - it could be easily wrapped by any compiled language. New frameworks had to be strongly tied to whatever development technology MS believed was their better competitive advantage in a given moment. Shifting frameworks make anyway far more complex for companies with far less resources follow them - and they can always fall in the pitfalls MS prepares for them. Borland itself made a big mistake when attempted to follow the .NET path.
Rememenber when they told that the "next Windows release will be bult on .NET"? It didn't happen. .NET has all the drawbacks of Java, even if is more integrated with Windows. Getting people like de Izaca on board didn't help.
And Nadella can't really understand the advantate Windows had with an API/ABI stable enough that made application compatibiliy very good. Probably he should ask Raymond Chen for some advices...
It's not new. Microsoft has been doing this even longer than Google. And it's not random, it's strategy.
Every developer hour you spend playing catchup with Microsoft's newest dev tools, systems, environments, whatever... is an hour you're not spending improving your actual product, thinking about new features your customers might actually appreciate. Joel Spolsky calls it "fire and motion". Microsoft puts up covering fire to keep its potential competitors busy and distracted, while it moves quietly towards whatever actual target it's currently focusing on.
Pleeeaaasssee if anyone's done this, post your reasons and motivation here. No snark, I'd genuinely love to know
It provided me with a reasonably lucrative career for over 30 years. Originally I was a Borland developer but after a company takeover I ended up in the Microsoft tools space. The start of an unpleasant journey.
But..I continued to get paid and at the age of 56 I retired. Thankfully the nervous twitches and nightmares are a thing of the past and I can only take my (golfing) cap off and shake my head at the poor sods still stuck at the code face.
Still, at now you have AI to help you..
ROFL.
In 1993, I quit my day job and started writing astronomy software, beginning with a desktop planetarium software (basically, maps of the night sky). This started out in DOS, then Win3.1, then 32-bit Windows. For the last two, I used MFC (Microsoft Foundation Classes, a.k.a. Microsoft Frustration Classes) in Visual Studio. Use of MFC did prove problematic, mostly because it meant I was locked into Microsoft's tools.
While I encountered a decent degree of frustration, it really did all work reasonably well. I abandoned the software about a decade back, mostly because of other projects coming along and because the astronomy community leans toward Linux (astronomers were very much early adopters).
I've since written some Windows software using the Win32 API. That has the benefit of being relatively carved in stone, and will work on almost any fork of Windows (and in Wine under Linux, giving me cross-platform capability). Dunno as how I'd like doing it for a really large project, though; it'd probably depend on the nature of said project.
I learned Win16 and made the transition to Win32 since it clearly offered new capabilities (like threads, pre-emption, security, Unicode).
No subsequent platform offered noticeably improved capabilities, so I stuck with Win32 and carried on developing a selling products. It still works and I haven't wasted any time learning platform-du-jour.
OK so perhaps I got lucky but Win32 really was an obvious improvement whereas all the others really weren't obviously so. I do feel that pretty much anyone could have reasoned as I did and enjoyed the same win.
It was, and as long as you still target Win32 and not the frameworks Windows keep on inventing, a far better environment do develop in. Far better than Linux. And far better than any "web app" and its stack of libraries and frameworks that changes too every few years.
This post has been deleted by its author
My first Windows dev experience was Borland Pascal for Windows - oop cut very close to the Win32 API, so I got a quite low-level understanding of how Windows worked (and still does), then onto Delphi (1,3,5 - only the odd-numbered versions were sound), then onto .NET and C# WinForms in 2003.
I have loved the longevity of WinForms based on .NET Framework.It provided the long-term stabilty that allowed me to be as familiar with my trade as a carpenter would be with theirs. Even the jumps between .NET Framework 1, 1.1, 2 and 4 were manageable.
But Inever fully intuitively grasped the .NET roadmap beyond that and the various (in)compatibility issues across NET Standard, .NET Core and NET 5,6,7,8,9,10… driven by Microsoft’s flailing attempts to be relevant across more than just Windows desktop. I count myself fortunate that I never really needed to. New .NET versions are now banged out at 2 year intervals with odd-version numbers given comically short 18 month support lifetimes. It seems to me that a modern .NET developer will need to spend as much time migrating projects to the latest .NET as actually writing features, compounded by the dependency tree of any packages you might reference.
I found my WinForms niche, and was lucky enough that it saw me through a decently long career, but I’m done now.
I lost interest in writing Windows SW with .net, where C# was far better than VB.net, but both seemed to be missing bits. Then it got worse with Vista, Win8, Win10, apps, UWP, Modern, and Fluent..
By 2008 Java and QT were both looking better as both genuinely multiplatform and MS had lost the plot on everything.
Oh I think C# worked out well. I eventually accepted that garbage collection was a reasonable alternative to RAII and every iteration of C# offered more useful stuff. I did think it was getting a little bit too complicated but each time, once I'd got to grips with the new features I felt comfortable and happy again.
Really? Only for smartphonetards. There's a lot of people using PCs at home for tasks well beyond mobes and tabled capabilites (and not only gamers). And most of them don't use Linux, for the simple reason they use applications not available on Linux. Lots of Macs too, of course.
Just, they don't feel the need to replace them as fast as they did ten-twenty years ago.
They aren't kidding about the insane WinUI3 build process. Microsoft wants you to use .msix app bundles to package, distribute and install winui3 apps. Ok sure, fine. It's quite easy to build and package a .msix bundle through visual studio. But try to then install that app on a different computer! You can't! Your .msix is either unsigned, or signed with a test certificate. Youd need to pay $$$ for a trusted certificate, or pay $$ to upload your app to the MS store. The janky poweshell workaround doesn't work either! I guess it's not possible to create a FOSS WinUI3 app, since you literally can't install it without the creator paying for signing somehow.
You *can* create a nearly static build which puts all of the build outputs and dependencies in one folder, then use the traditional .msi or simply .zip, but it's massive! multiple hundreds of MB or even a few GB for a hello world application. When this is supposed to be a windows native framework.
Poor me wanting to learn something about desktop development and making a simple test app, I'd send you the link but you literally can't run it. How does MS imagine people getting involved and using their framework if you aren't allowed to learn how to use it?!?!?
Windows Forms is tied to .NET which saw life starting around the turn of the century. Win32 has been stable since, oh I dunno, 1996?
I've always found wxWigets, which is a easy-to-use C++ wrapper around Win32, GKT+ and Mac Cocoa, the best option for developing desktop applications. And you don't need no frickin' runtime, you can just statically link the wxWidgets library into your application and you can just run it.
And you can compile your application for all three desktop platforms (Windows, Linux and Mac OS X). Even if you only use it for Windows development it still has advantages in that it's much easier to develop for than competing frameworks, like WPF and WinUI.
"WinUI 3 is not dead, I would even say that I see WinUI as the future of Windows desktop development,"
It is dead
It is the future
your future involves rich opportunities for carrion feeders, and loads of fun times for necrophiliacs..
Everyone else has to put up with horrendous stench and serious biohazard risks.
icon - putrescence more apt than bones.
Not quite clear where or what that place might be.
Appears that to work for Microsoft you need to be fluent in bollockspeak which *is* also an attribute that AI possesses by the bucket load.
Microsoft reserving interfaces and technology for its own applications while denying other developers access goes back to at least Win 2.0.
Interesting that Win32 is still a functional and active technology; has the advantage that such applications conceivably could run on any OS supported by WINE which stripped down could be shipped as part of a Win32 application's runtime.
Another “runs everywhere” promise that never did.
I once attended a small MS Dev meeting in the UK where Silverlight v1 was demo’ed and evangelised. However, the writing was on the wall even then as, at the end of the meeting, they revealed that v2 was being demo’ed in the US, and that it didn’t support backwards compatibility for v2.
From “the future” to obsolescence in the space of a couple of hours.
I never went anywhere near it and barely blinked when it was killed off.
Having coded programs to run on MS OSes[1] since MS DOS 1[2] (and thankfully skipping certain versions of Windows[3]) I had been blissfully unaware that "WinUI 3" even existed. For that mater, couldn't tell you what "WinUI 2" was supposed to be, either: may have seen something built with, maybe not - who cares?
Will I bother finding out what "WinUI 3" is or does? Nope. Do I think I'm ever likely to lose out by not learning more about "WinUI 3"? Nope.
As others have pointed out, there are some stable platforms to use if you want to code for Windows and even if you want to be multi-platform (and, as nobody has mentioned it, I'll chuck in FLTK just for a laugh!).
So why would anyone care about "WinUI 3"? Or 4? Or whatever.
[1] and others, and not just Unices, FWIW
[2] and PC DOS alternate weeks
[3] but then again, so did the clients so no harm done
I have no issue with Microsoft saying "here is the way we develop apps from now on". The problem is they've said that so many times that nobody has confidence that apps will actually be developed that way from now on.
I still use Win32 APIs where possible because it's the least likely to have the rug pulled from underneath. Or I'd use some open source cross platform API since it would probably outlive anything that Microsoft wrote.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
