4 ms·
First, there was Win32. That is still supported, and works reliably. It's a plain C interface, and it works on all versions of Windows. You have to do your own
by bmh 7y ago
First, there was Win32. That is still supported, and works reliably. It's a plain C interface, and it works on all versions of Windows. You have to do your own anchoring logic (ie all controls are positioned like HTML 'absolute'), and lots of stuff yourself, but it works, it's fast, and the docs are good.
Then, in 2000, Microsoft gave us .NET and WinForms, and we all thought that we'd be cross-compiling our C++ apps so that they ran inside of the hybrid native/.NET compiler called C++/CLR, so that we could take advantage of this improved UI toolkit. From C#, WinForms worked great. From C++, not so. But we thought that maybe we could write our GUI in C#, and interface to C++ for the heavy lifting/legacy code. I tried it a bit, and it was doable, but it ended up being very clunky to have this giant divide between the .NET world and the native C++ world.
Fast forward a couple of years, and Microsoft started talking up XAML, and it's native Windows Desktop incarnation called WPF. It had a browser sibling, which was Silverlight. This was a completely different to WinForms, and it was the future of Windows UIs. I tried it a bit. It made your app startup slowly, because it was now a .NET app. There were some interop issues between plain old C++ code, and C++/CLR, but it was OK.
Not long after that, Microsoft started talking about Windows 8, UWP, and Windows on ARM, and that's kind of where I lost track. With Windows 8, there were going to be a variety of ways that you could build desktop GUIs. Some of them seemed to be inherited from XAML. But now, instead of C++/CLR, you would use some kind of COM 2.0 thing. So you didn't need to build a hybrid .NET app, but the API wasn't great. In addition, Microsoft supported some kind of HTML-based app - which was some kind of thing inspired by Electron... but running on the IE engine instead of Chromium.
And now... this.
I don't know what most people ship these days, when they build Windows UIs. It's a mix of Electron (eg Slack, VS Code), as well as QT, and good ol' Win32, that we've had since the 90s.
So this is why people are tired. Microsoft keeps shipping yet another UI framework - and the people have stopped believing that they can invest in this thing, which is inevitably going to be replaced by yet another thing in 3 years time.
If you stick to plain ol' Win32, you can be pretty sure your app will be trivial to compile and run for decades, so that's what I do for little Win32 UIs.
- Ididntdothis 7y agoYou totally forgot that Silverlight for a while was supposed to be the best framework for the desktop :-) "I don't know what most people ship these days, when they build Windows UIs. It's a mix of Electron (eg Slack, VS Code), as well as QT, and good ol' Win32, that we've had since the 90s. " Most probably use WPF but that's not much fun.
- lostmsu 7y agoAs a .NET dev I've settled on WPF. Win32 is too low-level, and might have problems with high DPI support.
- contextfree 7y agoBut since Windows 8 they've stuck with essentially the same XAML framework (albeit under different names - Metro/UWP/WinUI). So they've been reasonably consistent for the last 8 years at least.
- jfkebwjsbx 7y agoWin32 is even better: it will run on Linux and macOS, too, thanks to Wine and friends.
- asveikau 7y agoThe thing about especially some of the more recent efforts is: the approach might have made sense when Microsoft was a monopoly and there was lots of interest writing software for Windows. But suddenly targeting Windows is much less interesting, but they still have the monopolist's arrogance: "You will rewrite your app to work on our new UI framework, right? Right...?" What actually happens is that every deprecation and every new thing weakens their ecosystem. Their biggest draw is in legacy software, and they variously want to throw out their legacy support, or create tomorrow's legacy today with new frameworks that end up abandoned.
- pjmlp 7y agoI still find interesting being able to target 85% of desktop systems, including laptops and 2-1 detachables out there. And a large majority of factory and laboratory automation control systems.
- Fiveplus 7y agoThat was a really informative comment, thanks for taking out time to explain it. Do you still make apps for Windows?
- pjmlp 7y agoI have done it during the past 5 years before switching jobs. Life science research laboratories and many medical devices are pretty much some form of Windows running a mix of MFC, Forms or WPF, dependending on when the application was made. The large majority of device manufactures, delivers their SDKs as a mix of DLLs and COM libraries, with samples written in C++, VB and C#. While HN might talk all day about R vs Python vs Julia, many of the researchers actually use Excel or Tableau, and when their built-in programming cannot keep up, it gets reborn as a .NET desktop app.
- userbinator 7y agoYou have to do your own anchoring logic Or moving logic, as it were... I'm sure I wasn't the only one who has made the "button you can't click"[1] prank application after finding out that UI controls are windows, and can be resized and moved too. [1] A single window containing a button labeled "CLICK ME", which jumps to a random place every time your mouse approaches it. I have also made a version without the window, or rather the containing window, which has the slightly amusing appearance of a lone button that jumps around the desktop. Labeling it "click me to close" of course makes it even more fun...
- sdegutis 7y agoI've been wanting to make a Windows app for my specific budgeting needs so that I can uninstall LibreOffice since that's all I use it for. So my plan was to use React + Electron since it's easy and quick, but it feels like overkill. So I considered downloading VS Community and using C# and .NET for it, but that also kinds of feels like overkill. So I considered using Win32 APIs, but I remember the sample hello world program's source being surprisingly complex. So I considered learning MFC and using that since I heard it's a decent layer on top of Win32, but then I'd have to relearn C++. So I opened the WinUI page and the WinJS repo linked to somewhere else in here, and both seem like dead ends. This is why I still have LibreOffice installed. Which of course also feels like overkill.