I wondered if the headline author had a stroke, but reading the article body confirmed that the whole .NET ecosystem has collectively had a stroke
> "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."
They just needed to toss in some miscellaneous "Core" and "ECMA" to complete the version/platform/release word salad
Anyway, if someone else was similarly confused it seems to be
> Wine, who have taken over the Mono Project, released "Framework Mono" v6.14
Even if it appears confusing to people (there is .NET Core, Standard and Framework) it can be summarized fairly easily.
The original .NET variations up until 4.8 are called Framework, built into Windows with quite a bit of Windows-dependencies and probably conversely also a bunch of Windows components that depend on it.
The modern core lineage (Core 1 to 3.1 and all "unified" .NET releases after 5) are named so since the "core" parts are platform independent running equally well on f.ex. Linux as Windows for webservers and similar. Desktop API's are moved to packages/SDK's to avoid creeping platform dependant code into the core.
Standard is an even more limited subset meant for developers who want to make libraries for both core and framework.
Now about Mono Framework, Mono was initially built to emulate old .NET Framework (hence Mono Framework) and due to it being intertwined with Windows it makes sense (and feels surprisingly progressive by MS) for Wine to steward these parts.
More modern unified/core .NET versions are meant to be distributed with applications and not bloat up Windows proper(and thus no need for Wine to support in addition to regular Windows API's).
Why Mono was taken into MS initially was to bring in their Xamarin branded crossplatform support for iOS and Android applications.
Did any of those apart from the Unity runtime ever gain any significant traction? (Iirc they've had some idea of porting to mainline .NET but weaning a sloppy codebase off Boehm is probably easier said than done).
Any particular reasons for Xamarin people not being happy? (I know Miguel left but can't remember why). I was still using some Java back then so I was particularly bummed from the outside about RoboVM being abandoned.
Yes, the Xamarin.Forms to MAUI rewrite, killing off MonoDevelop/Xamarin Studio, and with exception of a few key technologies like the linker, llvm AOT (used by Blazor), and the mobile targets, everything else is gone.
There are few public faces from Xamarin still at Microsoft.
Microsoft has a habit of naming similar (or not) things the same as each other. VS and VS Code; Powershell and Windows Powershell; Copilot and Github Copilot; Azure, Azure DevOps, and probably other Azure things.
I'm not sure what internal incentives in the company lead to such terrible naming practices.
After using .NET and COM as names for important platform products I half expect Microsoft to announce a new platform called .ORG or maybe just ORG. Visual ORG for .NET with COM support.
Oh then it's even worse than I knew: I had no idea there was Windows Powershell, too, and had (evidently erroneously?) through they just renamed Copilot to GitHub Copilot
My understanding is that Windows PowerShell is the version that shipped with Windows, i.e. PowerShell up to 5.4. The new PowerShell is just the newer versions (6.x/7.x), which doesn't ship with Windows and is meant to be cross-platform (i.e. runs on not-Windows). But that means dropping support for stuff that they can't make cross-platform.
Same with .net — Framework (up to 4.8 I think) is Windows, newer stuff (Core) is cross-platform. So this Framework release from Wine is for stuff that ties heavily into Windows, which is why Microsoft gave it to them in the first place.
The different categories are worth considering separately.
PowerShell is more than just "similar" to Windows PowerShell; it's a slightly-backwards-incompatible new version with cross-platform support. With cross-platform support, the old name didn't make sense any more; and presenting it as a "new" product solved the issue of people complaining when they upgraded and things broke. (Same thing they did with .NET.) I don't know what else they could have done here.
"Copilot" is Microsoft's name for their LLM functionality across all their products. Question in, slop out. That's entirely consistent. I'm not sure what difference you're even seeing between "Copilot" (which Copilot?) and "Github Copilot".
Azure DevOps was them renaming an existing product to coopt a better-known brand name. Same with Visual Studio for Mac. (Visual Studio Code and Azure Data Studio were similar - although those weren't renames but rather a new product trying to steal mindshare.) This is the only category I'd really call "terrible".
Nothing internal about those incentives (though, happily, at least some people at Microsoft still find that sort of thing in poor taste). "The purpose of a system is what it does", as famously observed by a man named Beer.
Microsoft is no stranger to what's very transparently a bastardized form of nominative determinism, meant to sabotage the playing field by confusing generic and branded nomenclature. It's the opposite process to genericizing a trademark: you take as many random words as you can get away with, and turn them into brand names while nobody is looking. And then... you are suddenly everywhere they look.
So, a clear totalizing influence; its purpose: to tombstone a consumer product into the early termination of any attempt at independent thought - until thinking remains purely the domain of machines (that everyone is forced to trust) and illiterates (that nobody believes). Never succeeds for reason of some natural law or other, but it's a pain in the ass, a.k.a. a great motivator of economic growth, especially in epochs where imagination is frowned upon, like our present one.
Far from limited to Microsoft, either. Though theirs are particularly crude - someone else mentioned COM and .NET. Well, why would you even name a proprietary runtime platform something as plainly idiotic as "dot net" - except to mount an attack against the networked commons? Take "Windows", for fuck's sake - at least they didn't name a statistics package that. What about "Meta", and their "Messenger" - remember when all chat apps were called messengers? Privatize the entire "Alphabet" - then nationalize it, then repeat a buncha times!
These kinds of organized attacks against language are nothing new. They just take a lot of entrenched mindshare to pull off in the first place, so are usually the domain of actors of nation-state and transnational caliber. One of their side effects is that people become technically unable (not just unwilling) to learn from immediate history: while the spectrum of observable reality remains covered by a network of interlocking notions, the boundaries between notions shift. So, the most important nuances become impracticable to translate between those established mental models that precede the attack, and any newly elucidated ones. So a lot of wheels end up having to be reinvented. Sometimes entire bicycles. Like I say, great driver of economic growth - just like many other more obviously horrible things.
"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."
Sounds like a way to port an old Windows Forms app to mac and linux.
I'm not sure whether to interpret Microsoft's donation of the project as a good or bad thing. Yes, they have given it a home under a project that is not driven by corporate whims*, but doesn't that then recuse Microsoft from any responsibility of contributing?
*Yes, Wine is heavily developed by CodeWeavers, but CodeWeavers exists largely to help fund and support Wine.
"Modern" .NET (previously ".NET Core" v1, v2, v3 - but now just ".NET" v6, v7, v8, v9) works really well on Linux and in containers etc. "Legacy" .NET, .NET Framework, version 4.X, does not.
If you build something new today in .NET land you are using a version that is compatible out of the box with linux, but there's gazillions of LOC .NET Framework out in enterprises that have yet not been migrated/rewritten.
But I don't actually know if Mono is stable enough to run Framework services on Linux?
I don't know how (if at all) Kudu is related to Mono, but on Azure you can run .NET Framework in e.g App Services (which uses Kudo under the hood). It's probably the only way to host a Framework service outside of IIS on a Windows VM. And Kudo contains references to Mono, and looks really linuxy when I've used it.
It 100% is! I've used Mono years ago to run older .net in VMs and containers. I found a single service that didn't really work well and we spent our time working on that instead of rewriting the world.
> If you build something new today in .NET land you are using a version that is compatible out of the box with linux
This is not a generally true statement, particularly with anything involving UI. WPF or anything modern WinForms are not supported. MAUI has no official Linux support.
And neither is recommended to be used over AvaloniaUI (or Uno, or Gir.Core if you want to target just Linux), which supports it.
Given the amount of whining about Linux GUI support despite good and proven solutions being provided, it leaves me with an impression some parts of Linux community actually don't want support at all and the goal is to have a convenient scapegoat to complain about.
>I haven't been following .NET lately, but AFAIK .NET works on Linux now and "Mono" is basically .NET for Linux... what even are the differences?
Mono implements the GUI stuff like WinForms
Microsoft .Net for Linux /cross platform has no GUI or maybe they added some new GUI now , I am not a .Net dev ,I know they were experimenting always with latest and greatest GUI stuff and failing to get traction.
I don't actually think mono ever implemented cross-platform versions of the various GUI libraries. There was/is Gtk#, a binding to the Gtk GUI library, which was used for a few Linux apps.
> I haven't been following .NET lately, but AFAIK .NET works on Linux now and "Mono" is basically .NET for Linux... what even are the differences?
Ideally few, but I think it is a good thing to have a separate implementation of the dotnet runtime as an insurance policy against the main contributor to dotnet.
This is exactly the kind of argument that leads to projects decaying. Not saying that WINE will let that happen, but without contributions, it is hard to develop, maintain and upgrade codebases the size of Mono.
i'm not saying mono doesn't need contributions, i'm saying that microsoft in particular has no real reason to contribute to it. it's not part of their .net strategy in any way, and it wasn't even their project to begin with.
I wondered if the headline author had a stroke, but reading the article body confirmed that the whole .NET ecosystem has collectively had a stroke
> "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."
They just needed to toss in some miscellaneous "Core" and "ECMA" to complete the version/platform/release word salad
Anyway, if someone else was similarly confused it seems to be
> Wine, who have taken over the Mono Project, released "Framework Mono" v6.14
Even if it appears confusing to people (there is .NET Core, Standard and Framework) it can be summarized fairly easily.
The original .NET variations up until 4.8 are called Framework, built into Windows with quite a bit of Windows-dependencies and probably conversely also a bunch of Windows components that depend on it.
The modern core lineage (Core 1 to 3.1 and all "unified" .NET releases after 5) are named so since the "core" parts are platform independent running equally well on f.ex. Linux as Windows for webservers and similar. Desktop API's are moved to packages/SDK's to avoid creeping platform dependant code into the core.
Standard is an even more limited subset meant for developers who want to make libraries for both core and framework.
Now about Mono Framework, Mono was initially built to emulate old .NET Framework (hence Mono Framework) and due to it being intertwined with Windows it makes sense (and feels surprisingly progressive by MS) for Wine to steward these parts.
More modern unified/core .NET versions are meant to be distributed with applications and not bloat up Windows proper(and thus no need for Wine to support in addition to regular Windows API's).
Why Mono was taken into MS initially was to bring in their Xamarin branded crossplatform support for iOS and Android applications.
From Microsoft there are also.NET Native, .NET Nano Framework, .NET Micro Framework.
Additionally outside Microsoft, Meadows and Unity .NET (which is a kind of hybrid between Mono and their own IL2CPP/Burst).
Many Xamarin folks are not that happy how the whole merge turned out.
Did any of those apart from the Unity runtime ever gain any significant traction? (Iirc they've had some idea of porting to mainline .NET but weaning a sloppy codebase off Boehm is probably easier said than done).
Any particular reasons for Xamarin people not being happy? (I know Miguel left but can't remember why). I was still using some Java back then so I was particularly bummed from the outside about RoboVM being abandoned.
Enough to keep some companies in business,
https://nanoframework.net/
https://www.wildernesslabs.co/
Yes, the Xamarin.Forms to MAUI rewrite, killing off MonoDevelop/Xamarin Studio, and with exception of a few key technologies like the linker, llvm AOT (used by Blazor), and the mobile targets, everything else is gone.
There are few public faces from Xamarin still at Microsoft.
you forgot the .NET Compact Framework, =D
It let XNA games run on the xbox360: https://en.wikipedia.org/wiki/.NET_Compact_Framework
Right, good point.
There is also nanoFramework which is an open-source continuation of .Net Micro Framework to bring .NET to MCUs.
> nanoFramework which is [...] .Net Micro Framework
(nod)
And for even further historical background, I wrote .NET on Non-Windows Platforms: A Brief History.[1]
[1]: https://entropicthoughts.com/dotnet-on-non-windows-platforms...
Microsoft has a habit of naming similar (or not) things the same as each other. VS and VS Code; Powershell and Windows Powershell; Copilot and Github Copilot; Azure, Azure DevOps, and probably other Azure things.
I'm not sure what internal incentives in the company lead to such terrible naming practices.
After using .NET and COM as names for important platform products I half expect Microsoft to announce a new platform called .ORG or maybe just ORG. Visual ORG for .NET with COM support.
Not to mention .EDU, the educational version of COM, and .IN-ADDR.ARPA, the module for looking up other modules by UUID.
the .MIL product is rumored to be in widespread use, but still classified.
Oh then it's even worse than I knew: I had no idea there was Windows Powershell, too, and had (evidently erroneously?) through they just renamed Copilot to GitHub Copilot
My understanding is that Windows PowerShell is the version that shipped with Windows, i.e. PowerShell up to 5.4. The new PowerShell is just the newer versions (6.x/7.x), which doesn't ship with Windows and is meant to be cross-platform (i.e. runs on not-Windows). But that means dropping support for stuff that they can't make cross-platform.
Same with .net — Framework (up to 4.8 I think) is Windows, newer stuff (Core) is cross-platform. So this Framework release from Wine is for stuff that ties heavily into Windows, which is why Microsoft gave it to them in the first place.
The different categories are worth considering separately.
PowerShell is more than just "similar" to Windows PowerShell; it's a slightly-backwards-incompatible new version with cross-platform support. With cross-platform support, the old name didn't make sense any more; and presenting it as a "new" product solved the issue of people complaining when they upgraded and things broke. (Same thing they did with .NET.) I don't know what else they could have done here.
"Copilot" is Microsoft's name for their LLM functionality across all their products. Question in, slop out. That's entirely consistent. I'm not sure what difference you're even seeing between "Copilot" (which Copilot?) and "Github Copilot".
Azure DevOps was them renaming an existing product to coopt a better-known brand name. Same with Visual Studio for Mac. (Visual Studio Code and Azure Data Studio were similar - although those weren't renames but rather a new product trying to steal mindshare.) This is the only category I'd really call "terrible".
>> internal incentives in the company lead to such terrible naming practices
I suspect overthinking is the root cause.
Nothing internal about those incentives (though, happily, at least some people at Microsoft still find that sort of thing in poor taste). "The purpose of a system is what it does", as famously observed by a man named Beer.
Microsoft is no stranger to what's very transparently a bastardized form of nominative determinism, meant to sabotage the playing field by confusing generic and branded nomenclature. It's the opposite process to genericizing a trademark: you take as many random words as you can get away with, and turn them into brand names while nobody is looking. And then... you are suddenly everywhere they look.
So, a clear totalizing influence; its purpose: to tombstone a consumer product into the early termination of any attempt at independent thought - until thinking remains purely the domain of machines (that everyone is forced to trust) and illiterates (that nobody believes). Never succeeds for reason of some natural law or other, but it's a pain in the ass, a.k.a. a great motivator of economic growth, especially in epochs where imagination is frowned upon, like our present one.
https://en.wikipedia.org/wiki/Generic_trademark
Far from limited to Microsoft, either. Though theirs are particularly crude - someone else mentioned COM and .NET. Well, why would you even name a proprietary runtime platform something as plainly idiotic as "dot net" - except to mount an attack against the networked commons? Take "Windows", for fuck's sake - at least they didn't name a statistics package that. What about "Meta", and their "Messenger" - remember when all chat apps were called messengers? Privatize the entire "Alphabet" - then nationalize it, then repeat a buncha times!
https://en.wikipedia.org/wiki/Trademark_distinctiveness
These kinds of organized attacks against language are nothing new. They just take a lot of entrenched mindshare to pull off in the first place, so are usually the domain of actors of nation-state and transnational caliber. One of their side effects is that people become technically unable (not just unwilling) to learn from immediate history: while the spectrum of observable reality remains covered by a network of interlocking notions, the boundaries between notions shift. So, the most important nuances become impracticable to translate between those established mental models that precede the attack, and any newly elucidated ones. So a lot of wheels end up having to be reinvented. Sometimes entire bicycles. Like I say, great driver of economic growth - just like many other more obviously horrible things.
It wouldn't be a faithful reimplementation of a Microsoft product without confusing naming.
This has tradition https://blog.oneunicorn.com//2020/03/26/numbersarehard/
AFAIK, "Wine mono" are just bindings that let wine interoperate with mono.
That said, I wish they would unify dotnet and "platform mono" so we don't need 2 instances of things to run .net applications...
[flagged]
Are you attempting a subtle dig, or what is the purpose of this comment?
EDIT: The original comment read, before edits:
> Do you program exclusively in Java?
[flagged]
"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."
Sounds like a way to port an old Windows Forms app to mac and linux.
> Sounds like a way to port an old Windows Forms app to mac and linux.
Mono only supports up to Winforms 2.0. It's typically not been great on porting Windows UI support in the very few places it even exists.
https://www.mono-project.com/docs/gui/winforms/
Not port, but you can just run them on wine and they run fine, most of the time.
I'm not sure whether to interpret Microsoft's donation of the project as a good or bad thing. Yes, they have given it a home under a project that is not driven by corporate whims*, but doesn't that then recuse Microsoft from any responsibility of contributing?
*Yes, Wine is heavily developed by CodeWeavers, but CodeWeavers exists largely to help fund and support Wine.
I haven't been following .NET lately, but AFAIK .NET works on Linux now and "Mono" is basically .NET for Linux... what even are the differences?
Sounds like Microsoft just doesn't want to maintain 2 different versions so they're dumping it.
Also,
> Microsoft became the steward of the Mono Project when it acquired Xamarin in 2016
They probably never even wanted Mono, they just inherited it because they wanted Xamarin.... which they've also killed now according to https://dotnet.microsoft.com/en-us/apps/xamarin
"Modern" .NET (previously ".NET Core" v1, v2, v3 - but now just ".NET" v6, v7, v8, v9) works really well on Linux and in containers etc. "Legacy" .NET, .NET Framework, version 4.X, does not.
If you build something new today in .NET land you are using a version that is compatible out of the box with linux, but there's gazillions of LOC .NET Framework out in enterprises that have yet not been migrated/rewritten.
But I don't actually know if Mono is stable enough to run Framework services on Linux?
I don't know how (if at all) Kudu is related to Mono, but on Azure you can run .NET Framework in e.g App Services (which uses Kudo under the hood). It's probably the only way to host a Framework service outside of IIS on a Windows VM. And Kudo contains references to Mono, and looks really linuxy when I've used it.
It 100% is! I've used Mono years ago to run older .net in VMs and containers. I found a single service that didn't really work well and we spent our time working on that instead of rewriting the world.
Can you provide any details on what did and did not work well in V4 that was different afterwards?
> If you build something new today in .NET land you are using a version that is compatible out of the box with linux
This is not a generally true statement, particularly with anything involving UI. WPF or anything modern WinForms are not supported. MAUI has no official Linux support.
Yeah sorry, I'm too focused on backend services.
And neither is recommended to be used over AvaloniaUI (or Uno, or Gir.Core if you want to target just Linux), which supports it.
Given the amount of whining about Linux GUI support despite good and proven solutions being provided, it leaves me with an impression some parts of Linux community actually don't want support at all and the goal is to have a convenient scapegoat to complain about.
>I haven't been following .NET lately, but AFAIK .NET works on Linux now and "Mono" is basically .NET for Linux... what even are the differences?
Mono implements the GUI stuff like WinForms Microsoft .Net for Linux /cross platform has no GUI or maybe they added some new GUI now , I am not a .Net dev ,I know they were experimenting always with latest and greatest GUI stuff and failing to get traction.
I don't actually think mono ever implemented cross-platform versions of the various GUI libraries. There was/is Gtk#, a binding to the Gtk GUI library, which was used for a few Linux apps.
Mono did implement WinForms, and they separately worked on a Silverlight implementation.
> I haven't been following .NET lately, but AFAIK .NET works on Linux now and "Mono" is basically .NET for Linux... what even are the differences?
Ideally few, but I think it is a good thing to have a separate implementation of the dotnet runtime as an insurance policy against the main contributor to dotnet.
why should microsoft have any responsibility to contribute to mono? they've done their bit in handing the project over to winehq.
This is exactly the kind of argument that leads to projects decaying. Not saying that WINE will let that happen, but without contributions, it is hard to develop, maintain and upgrade codebases the size of Mono.
i'm not saying mono doesn't need contributions, i'm saying that microsoft in particular has no real reason to contribute to it. it's not part of their .net strategy in any way, and it wasn't even their project to begin with.
This is relevant for running .NET 4.x apps on Linux or Mac. .NET 5+ is dotnet core, so mono is still relevant here.
Should have called it "Mono Framework"
> native support for ARM64 on macOS
I'm still missing x64 support on macOS in Wineskin.