The 6.14.0 release of Framework Mono is now available.
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.
The current set of supported platforms is: * Linux: x86[3], amd64[1], arm64[3] * macOS: amd64[2], arm64[2] * Windows: x86[3], amd64[3] [1] Tested manually and automatically through GitLab CI. [2] Tested manually only, no CI implemented yet. [3] No testing process yet.
Linux armv5te is known to be broken, but a work-around is possible by disabling float optimizations. I am hoping to fix that in the near future.
Binary packages are not currently available. The source is available at https://dl.winehq.org/mono/sources/mono/mono-6.14.0.tar.xz
There has also been a release of libgdiplus, version 6.2, with source code available at https://dl.winehq.org/mono/sources/libgdiplus/libgdiplus-6.2.tar.gz, which did not get its own announcement at the time.
Since this is the first release at Winehq, I wanted to give a detailed report on where this project is and what my priorities are. I'm including that below.
# What's New in 6.14.0
* Native support for macOS on ARM. Cis-compilation on ARM macOS is now assumed to be compiling for macOS, not cross-compiling for iOS. * System.Windows.Forms: * Fixed various resource leaks on X11. * Redesigned Clipboard and Drag And Drop implementation on X11. * Stability improvements on X11. * Improved support for generated COM interfaces. * Fixed some common cases where processes would hang on exit. * Added Georgian translation. * Many warning fixes. The Linux amd64 build no longer warns when compiling the C portion of the codebase, and this is enforced for new changes via CI. * Many bug fixes.
# A Note on Terminology
There are at least 3 different related projects using the name Mono: * Framework Mono is the project previously hosted at https://github.com/mono/mono, which was then simply called Mono. I have made this change to distinguish it from "monovm" and "Wine Mono", which are different projects. Framework Mono is a cross-platform runtime compatible with .NET Framework. * "monovm" is a separate fork of the Mono runtime that's part of modern .NET and can be used instead of CoreCLR. * "Wine Mono" is a downstream distribution based on Framework Mono that is used in Wine to replace .NET Framework.
There are also at least 2 different related .NET projects using 3 different names: * .NET Framework is a proprietary Windows component that supports cross-platform executable code using an object-oriented model. * .NET Core was an open-source project supporting many of the same languages and APIs as .NET Framework but mostly incompatible with it. .NET Core was renamed to ".NET" when version 5 was released. I call it "modern .NET" to distinguish it from .NET Framework.
# My Goals
For those not aware, in February of 2024, I made a fork of Framework Mono at Winehq (https://gitlab.winehq.org/mono/mono/-/tree/main). In August, Winehq took over the project officially, with me as maintainer, and this fork became the project's official home (https://github.com/mono/mono/issues/21796).
I approach this project with very different motivation and resources from the previous team. I am not trying to sell it to anyone as a development platform. I do not have a dedicated team for this effort. My employer is supportive, but I have other responsibilities, and I've found that for my own mental health I have to switch frequently between different projects.
I mention this because I think it's important for people to understand where I'm coming from, so they can get some idea of why I prioritize the things I do, and why certain things are missing.
My main goal is to keep Mono working the way it has been, on desktop platforms. For a project of this complexity, that takes consistent effort, because other software it needs to interact with is updating, and sometimes those updates will break things. Personally, I use Mono to run KeePass natively on Linux, and as a target platform for a program I am developing called Xalia.
I want to provide a space for people who want to contribute. I don't like watching contributions get lost simply because no one is there to review them, which was a frequent occurrence on GitHub.
Selfishly for my employer, I want Wine Mono to have a functioning upstream. I have to continue working on Wine Mono to improve its compatibility with Windows. Wine Mono is a fork of cross-platform code designed only to work on a single implementation of a single platform. The longer I keep to that narrow focus, without anyone working on the other platforms, the worse that codebase will get. I believe that maintaining code for multiple platforms makes it cleaner, and this is worth it even for Wine Mono alone.
# What we lost in the Winehq Migration
## Clarity for Users and Contributors
The announcement in August was confusing and still lacks visibility. People regularly show up on GitHub and file issues and pull requests without realizing the project has moved. I do keep an eye on these, and I respond or transfer contributions where appropriate, but it's not ideal. GitHub doesn't have the latest version of the code, at least not at the old URL (I have created an official mirror at https://github.com/wine-mono/mono), so they may duplicate effort or write changes that conflict with the latest version. Archiving the repository was suggested as a solution, but I worry that contributions would be lost if people can't immediately file them.
There doesn't seem to be any way to add a banner to the top of the project page. Redirects are only possible by transferring the repository to another organization on GitHub, and I can't do that because of concerns about protecting the data currently on that repository. Those concerns are also the reason I can't mirror updates to the original repository on GitHub.
Anyway, if you want to get the latest development version of the source code, or file an issue or merge request, use this link: https://gitlab.winehq.org/mono/mono
## Official Binaries
The infrastructure used to build binaries for Mono was not transferred to Winehq (and I doubt we could maintain it if it had been). For us to supply binaries, someone needs to recreate that on Winehq's infrastructure (probably GitLab jobs). I haven't been able to do that yet.
It'd be really nice for macOS in particular because there haven't been any ARM binaries released yet.
## Platform Support
Mono supported a lot of different platforms and CPU architectures. I have neither the knowledge, time, nor hardware to support all of them. I figure Web Assembly, Android, and iOS are already covered by modern .NET, and in Mono they lack the specific advantage of binary compatibility with .NET Framework. Therefore, I am focusing on the most common desktop platforms and the CPU architectures that could run Mono. (Notably, I believe Windows on ARM would be worth supporting, but Mono hasn't yet been ported to it, and this would likely be a non-trivial effort that I don't currently have the resources for.)
I don't plan to intentionally break the other targets, but I also cannot currently test them, so they may unintentionally break. If someone has a use case for some other target, and is able to maintain it (or at least add CI support so I have a way to tell when it's working), then I'd be open to supporting it. In particular, the Linux armv5te platform is broken, and I know that someone is depending on it, so I am hoping to fix it and add support in the future.
## Testing and Continuous Integration
The old Mono GitHub had CI for a dizzying array of platforms and configurations. On Winehq GitLab, our CI currently supports amd64 Linux and no other platforms. I would really like to have CI for all the supported CPU/operating system combinations. I'd intended to get it done before this release, but that ended up taking so much of my time that I had to just set it aside for a while. I'm hoping to get back to it soon.
## Crash Reporting (MERP)
The Crash Reporting (MERP) feature was causing test failures on macOS. I have been advised by the previous maintainers that this feature was probably only used by Microsoft for their own projects, and that flaws in the approach made it not worth maintaining. Microsoft has, of course, moved on, and I couldn't find any indication of anyone else using this. It also required an external reporting tool that is proprietary to Microsoft. It's likely possible for a third party to create their own implementation, but again, I couldn't find any indication that anyone had done this.
Specifically, MERP did crash reporting in a manner similar to WER (Windows Error Reporting). Its major design flaw is that it attempted to produce crash reports from inside the process that had crashed. If a process crashed, it's likely that the state is corrupted, and this corruption would often cause MERP to fail to produce a report. To mitigate this, a complex "breadcrumbs" system was implemented in MERP so that, if it fails to gather crash information for a report, it can at least report that it failed to gather the crash information, but such reports do not help with understanding either the original crash or the MERP failure. Making this work properly would require a redesign using an external process that monitors an application for crashes and handles crash reporting.
The "Mono.Runtime" methods that configure MERP and check for crashes are now no-ops. Related methods that query information outside of a crash throw PlatformNotSupportedException.
# My Current Priorities
## Fix armv5te Platform
See https://gitlab.winehq.org/mono/mono/-/issues/7. Since there is a work-around available, I'm hoping for a simple solution by detecting the platform capabilities. It may also be possible to add this platform to CI using QEMU.
## Update Cryptography
Mono uses BoringSSL for its cryptography. It was forked in 2016, and since then it has never been updated from upstream. The fork contains hacks that remove a dependency on the Go programming language.
My understanding is that updating simply isn't practical. Some people have apparently had success with resetting to the newest version, but I've since been told that only rebuilds work, not clean builds, so there's no telling what kind of strange hybrid that creates. It's no longer practical to remove the Go dependency. Upstream also explicitly recommends against any third party using BoringSSL, because they have no guarantees of API or ABI stability.
I'm not an expert in computer security, but using an 8 year old fork of a cryptography library that's impossible to update is, in my uneducated opinion, very bad. I would like to replace BoringSSL with something modern, and preferably dynamically linked so it can be more easily updated, probably OpenSSL.
## Expand the CI
I would like to have CI for all the supported platforms. I'm hoping to get back to this soon. See "Testing and Continuous Integration" above.
## Binaries for macOS and Windows
I understand compilation is a barrier for users of macOS and Windows especially, and the old binary packages included more projects than just Framework Mono itself. I feel that it makes sense to wait until after we have CI though, as I'd prefer to have these packages built by CI. Packaging is also more complex than building and testing these projects.
## Remove Dependencies on Old Hosting
We still depend on mono-project.com and github.com/mono for a lot of things. I don't know how long those resources will continue to work, so I would like to mirror them and ensure that the Framework Mono codebase isn't using them.