4 ms·

I might be new here but don't understand the hostility of these comments. Can someone chime in and explain?

monocasa 7y ago
Microsoft has a habit of releasing a new UI toolkit for Windows a few times a decade and then only supporting it for a year or two.
- Fiveplus 7y ago
  Thanks. That clears it up
- MikusR 7y ago
  There is a Microsoft UI toolkit that can't run in latest Windows version?
  - Ididntdothis 7y ago
    There are probably 8 that can run on the latest version. And all of these became abandonware a few years after their introduction.
etaioinshrdlu 7y ago
This comment from few years ago is informative https://news.ycombinator.com/item?id=18105142 https://news.ycombinator.com/item?id=18105142
jbeam 7y ago
This reddit comment has a good overview of the history: https://old.reddit.com/r/csharp/comments/f9i9hc/which_one_is_better_winforms_wpf_or_uwp/firr467/ https://old.reddit.com/r/csharp/comments/f9i9hc/which_one_is...
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 ago
  You 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.

Microsoft has a habit of releasing a new UI toolkit for Windows a few times a decade and then only supporting it for a year or two.

Fiveplus 7y ago
Thanks. That clears it up
MikusR 7y ago
There is a Microsoft UI toolkit that can't run in latest Windows version?
- Ididntdothis 7y ago
  There are probably 8 that can run on the latest version. And all of these became abandonware a few years after their introduction.

etaioinshrdlu 7y ago

This comment from few years ago is informative https://news.ycombinator.com/item?id=18105142 https://news.ycombinator.com/item?id=18105142

jbeam 7y ago

This reddit comment has a good overview of the history: https://old.reddit.com/r/csharp/comments/f9i9hc/which_one_is_better_winforms_wpf_or_uwp/firr467/ https://old.reddit.com/r/csharp/comments/f9i9hc/which_one_is...

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