cppwinrt VS winforms

Cppwinrt is in maintenance mode[1]. Cppwin32 is abandoned (with windows.h as the official alternative). It is now possible to deploy WinUI 3 apps as single files in C#[2] but not in C++. From experience, the entire C++ side of WinUI 3 documentation is underbaked to the extent that the easiest road is to read the C# documentation and attempt to guess the cppwinrt equivalent (as docs for cppwinrt are not really... there).

I don’t know if they’ve really abandoned C++ entirely—the compiler team certainly hasn’t, that’s true. But the above doesn’t feel like first-class support.

[1] https://github.com/microsoft/cppwinrt/issues/1289#issuecomme...

[2] https://learn.microsoft.com/en-us/dotnet/core/deploying/sing...

https://github.com/microsoft/cppwinrt/

And then compare with Project Reunion vision from 2021, and where we are three years later

https://blogs.windows.com/windowsdeveloper/2021/03/29/announ...

Mainly because along the way, as if those changes weren't enough, they also decided to reboot their initial approach with Project Reunion, WinAppSDK took another route, and here we are.

This is only a short overview of how WinRT went down since Windows 8, thus only those that never advocated for it, can honestly suggest WinUI, as they lack the background of how chaotic it all is.

[0] - https://devblogs.microsoft.com/cppblog/announcing-hilo/

Windows Runtime (WinRT) seems to be something they are working on. From what I could read are there a bunch of stuff needed apart from just a development library. I guess you meant this: https://github.com/microsoft/cppwinrt

Yeah, I closed it because it didn't seem to be taken into consideration, as later proven by https://github.com/microsoft/cppwinrt/issues/1123

Re: .NET WinForms -- they open sourced it a few years back.

https://github.com/dotnet/winforms

They even went so far as to bring back the forms designer to Visual Studio.

https://devblogs.microsoft.com/dotnet/windows-forms-designer...

Obviously it's still a pretty sizable migration to go from .NET Framework to .NET, but at least the UI framework is available again.

Apps developed for the modern (open-source) version of .NET may be compiled to a native code (NativeAOT). Some time ago, I tried AOT on a simple WinForms project and it worked. Unfortunately, functions using COM APIs are not yet supported (as they rely on reflection). There is an ongoing effort to fix this problem: https://github.com/dotnet/winforms/issues/4649

Windows Forms[0] is still alive and will never die, and very low overhead to start with, and works on new and shiny .NET 8.

If Linux or macOS, you can use AvaloniaUI[1] instead which is sufficiently advanced but assumes some prior knowledge.

[0] https://github.com/dotnet/winforms/blob/main/docs/getting-st...

[1] https://docs.avaloniaui.net/docs/get-started/

Winforms: Licencia MIT.

3. Therefore reified generics are not possible to implement in a backwards compatible way.

Ok, sure, but if you instead a new generic collection types and leave the old ones alone, you don’t have to worry about breaking existing compiled code.

This comment about C# suggests a lack of familiarity with the approach C# took:

> C# made the opposite choice — to update their VM, and invalidate their existing libraries and all the user code that dependend on it.

All of the pre-generic C# libraries continue to exist to this day (ArrayList, HashTable, and the non-generic IEnumerable). Applications that used them never stopped working. New code uses the generic collections (List and Dictionary).

Anyways, I think the costs that Java is currently paying for non-reified generics (reflection, performance, and type safety mentioned in the article) is not worth the backwards comparability with the 20 year old J2SE 1.4. The price C# pays for making a backwards incompatible generics (mostly some minor annoyance when designing a collection class implementing IEnumerable) is worth it at this point.

P.S. ok, I do admit that C# forking the collection library is still causing ongoing maintenance work 18 years later: https://github.com/dotnet/winforms/pull/8673

No, it is fully supported and in active development. https://github.com/dotnet/winforms

No, it's still under active development/maintenance. https://github.com/dotnet/winforms/graphs/contributors

The image is kept in-memory— https://github.com/dotnet/winforms/blob/main/src/System.Windows.Forms/src/System/Windows/Forms/PictureBox.cs

Appears that this has been broken for a while. Seems it has something to do with the new designers being run out of process.