[GaProgMan]

I agree. Except that WinForms has not been abandoned. In fact, it's one of the supported paths in the modern .NET stack.

[zerr]

It lacks hardware acceleration.

[RedShift1]

Does it need it?

[zerr]

Good point. Akin to Qt Widgets - it doesn't really need it on desktop. HW acceleration is crucial on mobile, but WinForms doesn't have a story there.

[Dwedit]

WinForms is a layer built on top of raw Win32. So it's not portable.

Even though Wine exists, Win32 calls can only be made from Win32 programs, not native Linux programs. So a WinForms app using the latest dotnet would need to run the Windows version of dotnet under Wine, and not use the Linux version of dotnet.

[DeathArrow]

>WinForms is a layer built on top of raw Win32. So it's not portable.

Neither are SwiftUI and AppKity.

[pjc50]

True, but: Microsoft haven't made a better UI framework that's portable to Windows yet. Everything after WPF has near zero adoption, including (critically important!) by Microsoft itself.

[anthk]

Mono used to have libwine embedded. You know, libwine exists as a library running and compiling Win32 natively under Unix. Instead of PE binaries you would run ELF Linux ones, but with nearly the same outcome.

[Dwedit]

Every time I tried following alone with the winelib/winemaker documentation, I always ended up with an ELF that had to be invoked using "wine" to run. Nothing that could self-load any of the wine dependencies.

[anthk]

Mono supported WinForms. But IDK how did they integrate it with the CIL.

But for sure they used WineLib.