Framework Mono release 6.14.0
Esme Povirk <[email protected]> Sat, 8 Mar 2025 16:53:22 +0000
| Newsgroups | gmane.comp.emulators.wine.announce |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============2255946412870984973==
Content-Type: multipart/alternative;
boundary="------------YYQF1OWhblOFKgUMWtsVD0tT"
Content-Language: en-US
This is a multi-part message in MIME format.
--------------YYQF1OWhblOFKgUMWtsVD0tT
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
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.
--------------YYQF1OWhblOFKgUMWtsVD0tT
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-text-flowed"
style="font-family: -moz-fixed; font-size: 12px;" lang="x-unicode">The
6.14.0 release of Framework Mono is now available.
<br>
<br>
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.
<br>
<br>
The current set of supported platforms is:
<br>
* Linux: x86[3], amd64[1], arm64[3]
<br>
* macOS: amd64[2], arm64[2]
<br>
* Windows: x86[3], amd64[3]
<br>
[1] Tested manually and automatically through GitLab CI.
<br>
[2] Tested manually only, no CI implemented yet.
<br>
[3] No testing process yet.
<br>
<br>
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.
<br>
<br>
Binary packages are not currently available. The source is
available at <a class="moz-txt-link-freetext"
href="https://dl.winehq.org/mono/sources/mono/mono-6.14.0.tar.xz">https://dl.winehq.org/mono/sources/mono/mono-6.14.0.tar.xz</a>
<br>
<br>
There has also been a release of libgdiplus, version 6.2, with
source code available at <a class="moz-txt-link-freetext"
href="https://dl.winehq.org/mono/sources/libgdiplus/libgdiplus-6.2.tar.gz">https://dl.winehq.org/mono/sources/libgdiplus/libgdiplus-6.2.tar.gz</a>,
which did not get its own announcement at the time.
<br>
<br>
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.
<br>
<br>
# What's New in 6.14.0
<br>
<br>
* Native support for macOS on ARM. Cis-compilation on ARM macOS is
now assumed to be compiling for macOS, not cross-compiling for
iOS.
<br>
* System.Windows.Forms:
<br>
* Fixed various resource leaks on X11.
<br>
* Redesigned Clipboard and Drag And Drop implementation on X11.
<br>
* Stability improvements on X11.
<br>
* Improved support for generated COM interfaces.
<br>
* Fixed some common cases where processes would hang on exit.
<br>
* Added Georgian translation.
<br>
* 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.
<br>
* Many bug fixes.
<br>
<br>
# A Note on Terminology
<br>
<br>
There are at least 3 different related projects using the name
Mono:
<br>
* Framework Mono is the project previously hosted at <a
class="moz-txt-link-freetext"
href="https://github.com/mono/mono">https://github.com/mono/mono</a>,
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.
<br>
* "monovm" is a separate fork of the Mono runtime that's part of
modern .NET and can be used instead of CoreCLR.
<br>
* "Wine Mono" is a downstream distribution based on Framework Mono
that is used in Wine to replace .NET Framework.
<br>
<br>
There are also at least 2 different related .NET projects using 3
different names:
<br>
* .NET Framework is a proprietary Windows component that supports
cross-platform executable code using an object-oriented model.
<br>
* .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.
<br>
<br>
# My Goals
<br>
<br>
For those not aware, in February of 2024, I made a fork of
Framework Mono at Winehq (<a class="moz-txt-link-freetext"
href="https://gitlab.winehq.org/mono/mono/-/tree/main">https://gitlab.winehq.org/mono/mono/-/tree/main</a>).
In August, Winehq took over the project officially, with me as
maintainer, and this fork became the project's official home (<a
class="moz-txt-link-freetext"
href="https://github.com/mono/mono/issues/21796">https://github.com/mono/mono/issues/21796</a>).
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
# What we lost in the Winehq Migration
<br>
<br>
## Clarity for Users and Contributors
<br>
<br>
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 <a class="moz-txt-link-freetext"
href="https://github.com/wine-mono/mono">https://github.com/wine-mono/mono</a>),
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.
<br>
<br>
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.
<br>
<br>
Anyway, if you want to get the latest development version of the
source code, or file an issue or merge request, use this link: <a
class="moz-txt-link-freetext"
href="https://gitlab.winehq.org/mono/mono">https://gitlab.winehq.org/mono/mono</a>
<br>
<br>
## Official Binaries
<br>
<br>
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.
<br>
<br>
It'd be really nice for macOS in particular because there haven't
been any ARM binaries released yet.
<br>
<br>
## Platform Support
<br>
<br>
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.)
<br>
<br>
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.
<br>
<br>
## Testing and Continuous Integration
<br>
<br>
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.
<br>
<br>
## Crash Reporting (MERP)
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
# My Current Priorities
<br>
<br>
## Fix armv5te Platform
<br>
<br>
See <a class="moz-txt-link-freetext"
href="https://gitlab.winehq.org/mono/mono/-/issues/7">https://gitlab.winehq.org/mono/mono/-/issues/7</a>.
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.
<br>
<br>
## Update Cryptography
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
## Expand the CI
<br>
<br>
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.
<br>
<br>
## Binaries for macOS and Windows
<br>
<br>
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.
<br>
<br>
## Remove Dependencies on Old Hosting
<br>
<br>
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.
<br>
</div>
<p></p>
</body>
</html>
--------------YYQF1OWhblOFKgUMWtsVD0tT--
--===============2255946412870984973==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
--===============2255946412870984973==--