|
|
Subscribe / Log in / New account

Framework Mono 6.14.0 released

Version 6.14.0 of Framework Mono has been announced.

This is the first release of Framework Mono from its new home at WineHQ. It includes work from the past 5 years that was never included in a stable release because no stable branch had been created in that time. Highlights are native support for ARM64 on macOS and many improvements to windows forms for X11.

See the release notes for a full list of new features and plans for future releases.



to post comments

An interesting release

Posted Mar 12, 2025 10:36 UTC (Wed) by lproven (guest, #110432) [Link] (4 responses)

MS planned to merge Mono into .NET 6 or thereabouts. It didn't happen. .NET on Linux still can't run Windows GUI code, and MS doesn't seem to care; I suspect it sees this as an advantage. There are cross-platform toolkits for building GUIs but they're not Windows-native so Windows folks don't use them.

I would like to read a deep-dive analysis that compares Mono 6.14 with .NET 6, at least on Linux, and covers the differences between Mono and "official" .NET, what either can do that the other can't, and looks at how far ahead either is than the other.

It's not clear to me how Mono compares functionally to .NET. AFAICS, .NET on Linux includes the CLR and the CLF: the runtime, akin to a JVM, and the framework libraries for text-mode server-side app. MS seems to want to play down that .NET on Linux is still a much smaller and simpler thing than .NET on Windows, which appears to include much more.

I am not a developer and have not dug deeply. I'd like to know what's included, what isn't, what the differences are, and whether Mono provides more of what's missing from .NET on Linux compared to .NET on Windows.

An interesting release

Posted Mar 12, 2025 21:07 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

> .NET on Linux still can't run Windows GUI code

It's worse than that.

.NET on Windows can't run Windows GUI code :) .NET Core migration left some of the older WinForms code in a semi-usable state.

An interesting release

Posted Mar 13, 2025 12:07 UTC (Thu) by lproven (guest, #110432) [Link]

> .NET on Windows can't run Windows GUI code :)

Oh, well done. Actual *LOL* here.

An interesting release

Posted Mar 14, 2025 10:45 UTC (Fri) by jamescrake-merani (subscriber, #157540) [Link] (1 responses)

On that subject, it kind of puzzled me that .NET has a runtime similar to the JVM yet at the beginning it was pretty much Windows only. Although perhaps I don't know enough about the subject.

An interesting release

Posted Mar 14, 2025 17:54 UTC (Fri) by raven667 (subscriber, #5198) [Link]

tldr; random thoughts at lunchtime...

Yeah, but it does make sense given the history. MS engineers really liked Java and the JVM and invested a bunch to make their implementation on Windows the fastest and most capable, but in doing so they made optimizations that broke compatibility with Sun Java, Sun didn't want to lose control of the Java ecosystems so Sun sued MS and introduced a compatibility test framework so they couldn't use Java trademarks or language unless they passed. There were a number of competing implementations at the time, not just MS, GNU had gcj, IBM had their own same as MS, and Blackdown Java which morphed into the OpenJDK (IIRC, it's been a while). MS engineers still liked the idea of a managed runtime so they took the engineering talent which designed their JVM and had them design a new runtime, the CLR and language to go with it, which MS submitted to standards bodies so that they wouldn't be guilty of monopolization, something they recently lost in court. Miguel de Icaza from GNOME and the commercial org Helix Code / Ximian also liked the idea of a managed runtime and liked C# which has an open standard so took on the effort to write Mono and make GTK# a supported GNOME technology, but without proprietary Windows libraries which aren't part of the language specification. WINE and other projects are more focused on re-implementing Windows stuff for cross-platform compatibility and GNOME doesn't care about Win32 or MS libraries, plus they designed the Vala language and put a lot more effort into making their C libraries robust and powerful, so MS use of ht CLR and GNOME use of the CLR are almost two ships in the night. MS did buy out the maintainership of Mono so they could improve the cross-platform compatibility of .NET, creating .NET Core and porting PowerShell to it so they can use it more on Linux servers, in competition with Enterprise Java (and I suppose to a lesser extent Python, Perl and PHP) as MS isn't really trying to "take over the world" with Windows NT Servers anymore, that ship has sailed and Linux has won. I think MS engineering really wanted to leave all the tech debt baked into Win32 (with designs going back to Win16 and the 1980s) and move to C# but they couldn't figure out the business case even when the technology was good, 3rdparty developers and customers really want long-term compatibility with legacy apps and MS wasn't able to gain leverage with Windows Phone or the Windows Store, so they abandoned a lot of the tech around .NET, which is why the joke that you can't even run Windows .NET apps on Windows because the underlying XAML/WinForms/Silverlight/whatever (I don't dev on Windows so I don't follow this closely) isn't ported to the new .NET Core runtimes. It's a shame technically because I've heard good things about the development experience, although I suppose what really killed it all off was web apps and wrappers like Electron that deprecated a huge amount of "native" app development across the industry.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds