He missed two important point that really puts me off.
The continuous reboots since Windows 8 was introduced.
The complete lack of respect for paying customers to deprecate C++/CX in name of ISO C++17 compatibility, with C++/WinRT, without any kind of Visual Studio tooling support, even after 4 years in development.
So now any .NET Native developer that would be dealing with C++/CX for those APIs that the WinDev refuses to create WinRT bindings, needs to write IDL files without any tooling, copy and merge generated files into their projects.
Wait for ISO C++ to get reflection and maybe we will do something about it they say.
Sometimes I get the feeling WinDev requires Notepad as their IDE.
Speaking of .NET Native, it is in maintenance, expect nothing beyond .NET Core 3.1 / C# 7.3.
> Sometimes I get the feeling WinDev requires Notepad as their IDE
When I was involved with Win32 Office, this (or the moral equivalent with VS Code) was often the case. Proper Visual Studio support was kludgy and difficult to maintain, and many (myself included) did without.
Most of the major desktop product groups have 30+ year old codebases and sure as hell aren't working off the latest C++, let alone C++/WinRT bindings. They've got other tools, or just put up with the drudgery because it's all they know.
How else can someone praise C++/WinRT versus the capabilities of C++/CX, which was finally something on the Microsoft side that could be compared with C++ Builder.
Sure it is an uplevel from WRL, however almost no one outside Redmod ever cared that WRL existed.
The only way to consider C++/WinRT on its present state as good is if the person in question never knew anything better, including MS own tooling.
I made tons of Desktop applications for Windows. Not a single one uses UWP. All are native Win32. Zero problems with acceptance / distribution for them not being UWP. Also probably worth mentioning that for Desktop Windows apps I use Delphi and its open source sibling - Lazarus. Those provide very nice GUI toolkits and are true RAD tools while producing reasonably fast native code.
What's the point of posting this now? Pure UWP is practically dead. Microsoft has made most of the new APIs and GUI features originally meant for UWP available to all Windows programs through WinRT/COM. UWP is simply being absorbed into the wider Windows ecosystem. You only need to deal with the UWP sandbox these days if you're a masochist.
What they are making available in Win32 still requires code rewriting, is incomplete, while throwing away the VS tooling support they have on the UWP side of the fence.
This is disappointing to me, even though I'm no longer at Microsoft, because it means that Windows is now the only major platform where there isn't an official modern platform-native UI toolkit that people are likely to use. Win32 isn't really a good choice for new applications because it uses an antiquated graphics implementation (GDI). Win32 also doesn't make it easy to tweak or extend the accessibility implementation of a standard control. All of this means that for developers of native applications, Windows makes it harder to do the right thing with regard to accessibility than, say, Mac or iOS. If WinUI 3 actually took off, it might fix this.
If Microsoft had put all the work into improving the Win32 underpinnings instead of throwing it all away and inventing all new and incompatible APIs it would have been fine. Modern UI frameworks can be implemented on top of the basic Win32 UI elements or even Direct2D, and those modern UI frameworks don't need to live on the operating system side at all but can be linked into applications.
Windows basically has lost a decade chasing a pointless unification of desktop and mobile platforms. UWP turned out a turd, no matter how you look at it.
I don’t particularly expect WinUI 3 to take off, sadly. I agree that it’s disappointing.
The team still has a lot of work to do; unpackaged applications still aren’t supported, for one. And even once it’s production-ready (next year?), I’m not sure it will be good enough to use instead of web UI.
I do quite like how easy it is to build UIs that work for both keyboard+mouse and touchscreens. But overall it’s basically WPF with a few improvements, and the worst parts of WPF (styling, verbosity) are still there.
I wish it was an improvement over WPF, it can hardly match WPF in feature comparisasion, every time someone complains we get the standard reply of getting in touch and explaining our case.
The XAML is incompatible as the rendering engine doesn't expose the same feature set.
Well, our use case is not to rewrite everything yet one more time, a use case that apparently is hard to understand.
Designers aren't supported, yet another please get in touch and explain your business case kind of answer.
> the worst parts of WPF (styling, verbosity) are still there
WPF is supported in Expression Blend, the tool helps with both styling and verbosity. For optimal UX it needs a bit of support from within the application, to provide design-time data. Ain’t terribly hard to do, and helps a lot when working on WPF GUI apps.
What is really disapointing to me it that they don't acknoledge the hurdles that they are still putting in our way.
For .NET developers, WinUI still represents rewriting the UI and for stuff like Viewport3D or HLSL support, the advice is to learn C++, make use of SurfaceImageSource and rewrite the stuff directly in DirectX.
Quite a change for LOB developers, then there are the missing components as well.
For C++ devs, the aging MFC is more productive than dealing with IDL files without any kind of VS tooling support, all components are based on COM (hello boilerplate) and requires manually merging generated files into the project.
They say they are listening to us, however they still fail to deliver what we complain about.
Meanwhile those that can afford it, will just adopt Qt, Delphi, C++ Builder instead.
So expect most people to still ignore these efforts.
Exactly. If you don't need pixel perfection or 3D, WinForms are perfect. Fast, simple, and with a lightning develop-build-test loop. Plus, it's officially supported on .NET Core.
UWP is fine and in fact should be preferred for apps targeted at content consumption. E.g. you want your IM, Facebook app, media player, all the video games to be UWP so that you would know the companies making these apps are not stealing your data and not making your system too vulnerable to RCE attacks.
This also applies for any professional apps that do not require extensive access to the file system.
For the rest of the stuff like system tools, arbitrary file editors, user interface utilities you need to run in full trust UWP is currently not suitable.
Media players are already a somewhat iffy proposition because playlists, subtitles or multi-part (video) files for example are the kind of multi-file file formats that don't work well with heavily sandboxed file access because of the implicit relationships between separate files that the OS doesn't know anything about.
We just started looking at building a new UWP app and have been wondering what reasonable alternatives may exist. I don't think anyone on our team is hellbent on authoring XAML documents, so maybe we start looking back at stuff like win32.
For C++, the path to avoid XAML is to stay with legacy MFC, adopt Qt or C++ Builder.
For .NET, there is really no way around XAML, other than keeping using Windows Forms, or doing everything by hand calling the .NET classes that map into XAML components, regardless of WPF, WinUI or MAUI.
I think Windows could succeed with UWP if they embraced 0% sales commission, and just charged a yearly fee per app (which could scale based on units sold, to cover credit card fees).
They should allow developers to directly distribute the software from their own websites, and for 3rd-party stores to sell and distribute UWP apps.
Regardless of any financial considerations with the Store around UWP, they really just screwed the pooch on the developer experience. Going back to Window 8, it's been a trainwreck for years. Nobody wants to chase their recommended newest thing when it is perpetually half-baked, so a fair number of people have thrown up their hands and decided to just stick with tried-and-true WinForms or WPF or raw Win32 forever.
The very fact that WinDev doesn't get it why using COM and dealing with IDL files without any kind of tooling support is a problem shows how they don't even make an effort to understand what Windows developers want.
It is not like something like C++ Builder and Delphi don't exist for 25 years now.
He missed two important point that really puts me off.
The continuous reboots since Windows 8 was introduced.
The complete lack of respect for paying customers to deprecate C++/CX in name of ISO C++17 compatibility, with C++/WinRT, without any kind of Visual Studio tooling support, even after 4 years in development.
So now any .NET Native developer that would be dealing with C++/CX for those APIs that the WinDev refuses to create WinRT bindings, needs to write IDL files without any tooling, copy and merge generated files into their projects.
Wait for ISO C++ to get reflection and maybe we will do something about it they say.
Sometimes I get the feeling WinDev requires Notepad as their IDE.
Speaking of .NET Native, it is in maintenance, expect nothing beyond .NET Core 3.1 / C# 7.3.