Microsoft schenkt Mono Project aan de Wine-gemeenschap

Microsoft schenkt het opensourceframework Mono Project aan de Wine-gemeenschap. Het Mono Project was de eerste .NET-implementatie op Android, iOS, Linux en andere besturingssystemen en is sinds 2016 in handen van Microsoft.

De beslissing van Microsoft wordt aangekondigd op de website van Mono. Daar geeft het bedrijf aan dat de WineHQ-organisatie het beheer overneemt met een nieuwe repo. Microsoft belooft dat de broncode in bestaande repo's online blijft. Binaries blijven zo'n vier jaar lang beschikbaar. Het bedrijf verwijst ontwikkelaars die Mono willen blijven gebruiken naar zijn eigen 'moderne fork' van het project binnen .NET.

Het Mono Project werd gemaakt door Miguel de Icaza, bekend van de Gnome-desktop. De bedoeling van het project was om het .NET-platform, dat destijds net nieuw was, naar Unix-achtige platformen te brengen. Microsoft kreeg het project in 2016 in handen toen het Xamarin, dat op dat moment eigenaar van Mono was, overnam.

Het is echter al enige tijd geleden dat er grote updates van het Mono Project zijn geweest, zegt Microsoft zelf ook op de website van het project. De laatste grote release was in juli 2019. Sindsdien zijn er alleen nog kleine patches geweest, de laatste in februari dit jaar.

Reacties (64)

[RobertMe]

Mono is voor moderne software ook niet meer zo relevant? Het was relevant omdat je daarmee .NET applicaties op Linux kon draaien. Maar .NET 5 ("runtime"), meen ik, is ook cross platform. Dus de, tegenwoordig open source ontwikkelde, .NET "van Microsoft" draait tegenwoordig ook op, bv, Linux. Waardoor je Mono daarvoor niet meer nodig hebt.

Enige dat ik niet weet is hoe het zit met UI applicaties. De oude "WinForms" APIs. Of daar een .NET 5(+) tegenhanger, die cross platform is, van ontwikkeld is. Want bepaalde zaken uit .NET t/m 4 zijn volgens mij niet meegegaan naar .NET 5.

* RobertMe heeft al ~10 jaar niet meer met .NET gewerkt en de ontwikkelingen niet zo actief gevolgd, kan dus zijn dat er wat foutjes in staan (.NET 5 of 6, bv?). Tussendoor was er nog .NET Core? Die later .NET 5? is geworden? En daarvoor was het officieel ".NET Framework"? Waarbij Framework ook is vervallen in de naam.

[Yuregenu]

De volgorde van ontwikkeling is een beetje warrig geweest, maar in een notendop:
Eerst alleen .NET Framework. Windows only met de mogelijkheid om allerlei Windows-specifieke zaken aan te roepen zoals DPAPI (encryptie op user-niveau), registry editing en WinForms UI die leunt op System.Drawing, een Windows-specifieke DLL. Mono maakte deze laatste native met een .so-bestand. Technisch heel indrukwekkend, maar helaas met kleine verschillen zoals bij fontrendering, dus pixel-perfect kon je je code niet krijgen. Ik kan me niet goed herinneren of DPAPI werd geëmuleerd of niet ondersteund werd.

Windows nam Xamarin en dus Mono over, en begon werk te maken van .NET Core. Dit kon native draaien, met voornoemde System.Drawing port die Mono had ontwikkeld. Maar .NET Core maakte een hoop andere libraries, zoals DPAPI en registry editing, onbeschikbaar zodat de cross-platform ondersteuning gegarandeerd werd.

Daarna kwam .NET Standard. Dit ondersteunde alle libraries, maar kwam dan wel met de waarschuwing bij aanroep van systeemspecifieke code "dit wordt alleen ondersteund op Windows". Met preprocessor directives kon je dan bepaalde stukken code alleen voor Windows compileren, andere stukken alleen voor Linux. Zo kon je backend libraries maken die tijdens compilatie omswitchen en de ene front-end heel specifiek voor Windows schrijven en de andere voor Linux.

Microsoft besefte dat programmeurs niet dom zijn, en maakte .NET. Geen suffix, gewoon dot net. Het kan cross-platform compileren en kan dat specifiek doen voor verschillende processortypes en besturingssystemen. In de Visual Studio IDE kun je heel makkelijk profielen aanmaken als "Debug Linux" en "Release Linux" zodat je per OS-platform de waarschuwingen krijgt of je oncompileerbare code maakt voor dat platform.

.NET Framework bestaat nog voor backwards compatibility,
.NET Core en .NET Standard hebben een paar jaar naast elkaar bestaan en zijn samengevoegd tot
.NET, die begon met nummeren als .NET5 en met .NET6 de eerste LTS versie kreeg. We zijn inmiddels bij .NET8 aangekomen.

[alex3305]

Windows nam Xamarin en dus Mono over, en begon werk te maken van .NET Core. Dit kon native draaien, met voornoemde System.Drawing port die Mono had ontwikkeld. Maar .NET Core maakte een hoop andere libraries, zoals DPAPI en registry editing, onbeschikbaar zodat de cross-platform ondersteuning gegarandeerd werd.

Microsoft nam Xamarin over, maar Mono bestond ook al voor Xamarin. Microsoft heeft toen het Xamarin overnam het .NET Framework en Mono-framework, en de eigen kennis en de kennis van Xamarin gebruikt om .NET Core op te gaan bouwen. Door die open mix-and-match van kennis en technologie heeft er best wel een geinige kruisbestuiving plaatsgevonden. Er was een enorme focus op het standaardiseren en daarmee cross-platform krijgen van de .NET bibliotheek zonder daarbij alleen naar de eigen technologie of kennis te kijken. Hierdoor was de eerste versie van .NET Core ook enorm beperkt, vooral ten opzichte van .NET Framework, maar de fundering was wel enorm stevig. Ook werd bijvoorbeeld Xamarin Studio (een eigen ontwikkelde IDE van Xamarin) op MacOS omgedoopt tot Visual Studio for Mac.

Mono is op zichzelf in mijn ervaring en omgeving nooit echt belangrijk geweest, maar de impact van het project is enorm geweest. Naast Xamarin en bijbehorende apps, gebruikte bijvoorbeeld Unity ook Mono. En ook het relatief toegankelijke Microsoft XNA waarmee homebrew mogelijk was de Xbox, heeft een Mono port gehad. Hieruit is ook onder andere MonoGame als game engine ontstaan. En die kennen we dan weer van games Stardew Valley of Fez.

[Loller1]

.NET Framework bestaat nog voor backwards compatibility,
.NET Core en .NET Standard hebben een paar jaar naast elkaar bestaan en zijn samengevoegd tot
.NET, die begon met nummeren als .NET5 en met .NET6 de eerste LTS versie kreeg. We zijn inmiddels bij .NET8 aangekomen.

Wat? .NET Standard was letterlijk wat de naam zegt; een standaard. Het bestond niet naast .NET Framework en .NET Core als een alternatief. Standard kon gebruikt worden in .NET Core en .NET Framework (en nog verschillende andere implementaties zoals Mono en Xamarin). Wat jij zegt is als zeggen dat HTML een alternatief is voor Gecko en Blink.

.NET Core is met versie 5 gewoon omgedoopt naar .NET, er was niks om het mee samen te voegen. Het was simpelweg voldoende uitgewerkt om .NET Framework 4.8 en andere implementaties te vervangen, met als eindresultaat dat .NET het doel van .NET Standard voorbij had gestreeft omdat dat nu van zichzelf al de standaard was.

[Yuregenu]

Hmm, ik herinner me het verkeerd. Wellicht omdat je in je projectbestand kan zeggen "Target framework is .NET Standard".
Maar onder water is het inderdaad geen framework, het is een specificatie van de API's die je kan aanroepen in je code en dan compileren tot iets dat kan runnen op .NET Framework, .NET Core of .NET5+

De mogelijke afschaffing van .NET Framework staat voorlopig blijkbaar nog niet op de agenda. Microsoft heeft zelf geen einddatum aan de meeste recente versie 4.8.1 gehangen en zegt op hun officiële supportpagina dat het ondersteund blijft en ingepakt wordt met "toekomstige versies van Windows".
De laatste .NET Core 3.1 is al bijna twee jaar geleden buiten support gevallen, daar moet je overstappen naar .NET. Gelukkig is dat eenvoudig, de migratiegidsen van Microsoft zijn erg keurig geschreven, ik ben pijnloos meegegroeid van Core 2.1 naar Core 3.1, naar NET6 en nu NET8.

[Wolfos]

Nee, je hebt eigenlijk alleen .NET Framework, Mono en CoreCLR. Microsoft heeft Xamarin (de Mono ontwikkelaars) overgenomen en is samen aan het open source en cross-platform CoreCLR gaan werken. Als je nu een nieuwe applicatie ontwikkeld zal dat vrijwel altijd op CoreCLR zijn.

.NET Standard is een standaard die libraries kunnen gebruiken om ervoor te zorgen dat hun code op alle drie de runtimes draait.

[Reactie gewijzigd door Wolfos op 29 augustus 2024 10:08]

[MiesvanderLippe]

Dat was juist de kracht van Xamarin. Je kon met relatief weinig moeite dezelfde UI code gebruiken op iOS en Android. En dezelfde codebase gebruiken voor Windows en MacOS.

[Daco]

zoals aangegeven door @joost00719 is MAUI de officiele 'opvolger' van xamarin. het eenige verschil is dat in MAUI de linux support niet te vinden is.

right now is er enkel Avalonia om crossplatform (met linux) UI's te maken & is ook xaml based.

[TheVivaldi]

Dan kun je dus Maui van KDE gebruiken: https://invent.kde.org/maui Iets ander framework, maar wel ook cross-platform.

[Daco]

denk niet dat die te vergelijken zijn. die lijkt QT te gebruiken en c++ of java (import bestaat niet in c++ dacht ik, tenzij het een # directive is) based te zijn, niet .net

[TheVivaldi]

Maar het ging toch om cross-platform en Linux-ondersteuning? Dat biedt Maui van KDE. Dus nee, niet te vergelijken in hoe je ermee programmeert, maar wel qua platformondersteuning.

[ahprins]

Sinds c++20 zijn er modules en die importeer je met een "import" statement in C++.

[TweakerTom]

Niet alleen Avalonia. Je hebt ook het Uno platform (website: platform.uno) en als het alleen gaat over desktop UI's, dan zijn er nog veel meer mogelijkheden.

[joost00719]

Dat kan nog steeds, maar nu heet het Maui. Onder de motorkap is het volgens mij nog grotendeels hetzelfde, althans, je komt zo nu en dan wel wat Xamarin referenties tegen.

[Exirion]

Ze lijken meer op elkaar dan je lief is: MAUI erft zelfs het gros van de bugs in Xamarin.

[TheVivaldi]

Maui van Microsoft of Maui van KDE? https://invent.kde.org/maui Want voor beide geldt hetzelfde argument wat MiesvanderLippe noemt.

[Reactie gewijzigd door TheVivaldi op 29 augustus 2024 10:41]

[breezie]

WinForms is inderdaad niet cross-platform. Je kan het gebruik in .NET Core / .NET 5+ maar het zal enkel op Windows werken.
Er zijn wel alternatieven beschikbaar die wel cross-platform zijn.

[geoffrey.vl]

winforms werkt gewoon hoor op linux onder Mono.
WPF, dat niet.

[Reactie gewijzigd door geoffrey.vl op 29 augustus 2024 13:32]

[LongTimeAgo]

Wellicht dat oude games hier van kunnen profiteren?
Aan de andere kant... Er zijn al Proton versies die oudere games beter kunnen draaien dan dat Windows dat kan.

[JBVisual]

Proton draait oude software op Linux soms inderdaad beter dan Windows dit doet. Dit komt uiteraard doordat proton op Wine gebaseerd is, en WINE geen emulator is, maar code native uit probeert te voeren.

Daar waar Windows al bepaalde elementen geschrapt heeft, en deze onderdelen via emulatie aan bied.
(Oude onderdelen schrappen en vervolgens emuleren kan veel redenen hebben, denk aan exploits die misbruikt kunnen worden of onderdelen die niet meer efficiënt te werk kunnen gaan op moderne platformen)

[fre0n]

Voor crossplatform GUI's wordt gebruik gemaak van MAUI

[biteMark]

Behalve voor Linux Desktop

[ThinkCreative]

Klopt, zaken zoals System.Drawing werken alleen op Windows (ook als je .NET 8 draait).
Je hebt wel cross-platform frameworks zoals .NET MAUI van Microsoft zelf of Avalonia.

[Gr4mpyC3t]

Heeft iemand bronnen die wat meer informatie delen over de haat-liefde verhouding van Microsoft ten opzichte van Linux? Software als Microsoft Edge, Visual Studio Code en .NET zijn al een tijdje beschikbaar, maar Microsoft Office en Microsoft Teams dan weer niet.

Is dit strategie? Onwil? Of simpelweg te lastig om die software stack om te katten naar Linux? Heb zelf al langer het vermoeden dat Microsoft Office bewust niet naar Linux gebracht wordt omdat je dan wel vast aan Windows zit. Maar dat is misschien te negatief gesteld.

[bantoo]

Microsoft releast alleen server en hobby tools voor Linux. Een kantoorpakket last daar niet echt tussen.

[walteij]

Daarom zijn Visual Studio Code en .NET natuurlijk ook naar Linux gebracht, dat zijn hobby tools....

Iets serieuzer: Office is volgens mij erg lastig om 'om te katten' voor Linux. Je ziet hoeveel moeite Microsoft heeft om Office voor Mac in dezelfde update cycle als Office voor Windows heeft.
Daarnaast denk ik dat de diversiteit van distributies en het gebrek aan een echte standaard waar alle distributies zich aan houden (onafhankelijk van .RPM of .DEB package formaat) die portering een stukje lastiger maakt./

[HollowGamer]

.NET is niet door MS naar Linux gebracht, maar zoals in artikel staat door een Gnome ontwikkelaar.

VSCode is naar Linux gebracht, omdat MS juist die developer groep interessant vind.

[walteij]

Nee, mono is door een Gnome ontwikkelaar als implementatie van het .NET framework naar Linux gebracht.
.NET Core is echt door Microsoft ontwikkeld en naar Linux (en MacOS) gebracht, dat mono daar een flinke invloed op had, ga ik niet betwisten .
In 2020 zijn .NET Core en het .NET Framework samen verder gegaan en heet het gewoon .NET.

[Loller1]

Is dit strategie? Onwil? Of simpelweg te lastig om die software stack om te katten naar Linux?

Neen, het is gewoon omdat er geen meerwaarde is om Office naar Linux te porten in verhouding met de support die Microsoft ervoor zou moeten leveren, de end user markt is daar gewoon te klein - om niet te zeggen onbestaand. Edge, VSC, etc. zijn beschikbaar op Linux omdat respectievelijk Chromium en Electron dat ook al zijn.

[The Zep Man]

Edge, VSC, etc. zijn beschikbaar op Linux omdat respectievelijk Chromium en Electron dat ook al zijn.

Als dat de reden zou zijn, dan zou een volledige Teams client ook beschikbaar zijn voor Linux. Die was echter altijd al beperkt.

Neen, het is gewoon omdat er geen meerwaarde is om Office naar Linux te porten in verhouding met de support die Microsoft ervoor zou moeten leveren, de end user markt is daar gewoon te klein

Ik denk dat je actie en gevolg door elkaar haalt. Waarom is de end user markt klein?

[Loller1]

Als dat de reden zou zijn, dan zou een volledige Teams client ook beschikbaar zijn voor Linux. Die was echter altijd al beperkt.

Teams is gebouwd met WebView2, wat enkel en alleen voor Windows bestaat. Toen het nog Electron gebaseerd was, was het wel degelijk beschikbaar op Linux.

Ik denk dat je actie en gevolg door elkaar haalt. Waarom is de end user markt klein?

Wat heeft dit met mijn reactie te maken? De end user markt is klein, dus het wordt niet ondersteund. Dat dat een kip-en-ei verhaal is maakt daar geen verschil aan en heeft niets te maken met de redenatie van Microsoft om een pakket het formaat van Office naar Linux te brengen. Het is niet aan Microsoft om Linux te promoten, laat staan dat het aan Microsoft is om Linux een platform te maken waar bedrijven ondersteuning voor willen bieden...

[The Zep Man]

[...]

Teams is gebouwd met WebView2, wat enkel en alleen voor Windows bestaat. Toen het nog Electron gebaseerd was, was het wel degelijk beschikbaar op Linux.

Toen het nog Electron was, was het beperkt beschikbaar op Linux. Het was een uitgeklede client t.o.v. die van Windows. Zo kon je bijvoorbeeld alleen met een enterprise/education account inloggen.

Wat heeft dit met mijn reactie te maken?

Dat de reden is om Office niet naar Linux te halen (ook) ligt in het dat het eigen ecosysteem potentieel ondermijnt.

[TheVivaldi]

Toen het nog Electron was, was het beperkt beschikbaar op Linux. Het was een uitgeklede client t.o.v. die van Windows. Zo kon je bijvoorbeeld alleen met een enterprise/education account inloggen.

Nee hoor, dat is niet waar. Ik heb geen Enterprise- of Education-account van Microsoft, maar heb Teams op Linux gewoon met mijn persoonlijke account kunnen gebruiken toen die Electron-cilent beschikbaar was.

[DdeM]

Dat de reden is om Office niet naar Linux te halen (ook) ligt in het dat het eigen ecosysteem potentieel ondermijnt.

Microsoft investeert de laatste jaren gigantisch in Linux en ondersteuning hiervan voor veel van hun apps. Ik vermoed eerder dat support voor Office op Linux er nog niet is omdat het gigantisch veel legacy heeft, waar de moderne applicaties zoals edge en vs code al vanaf het begin cross platform zijn gebouwd. Waarom ze dit met teams anders hebben gedaan kan je ook alleen over speculeren, maar gezien ze dat verder met geen enkele app hebben gedaan haalt het idee dat het voor het Windows ecosysteem is wel een beetje onderuit. Kijkend naar de ontwikkelingen in Windows zou het me juist niets verbazen als ze bezig zijn deze stap voor stap richting een Linux kernel om te bouwen.

[Loller1]

Zo kon je bijvoorbeeld alleen met een enterprise/education account inloggen.

Heb je nog andere voorbeelden, want dat dit de "enige" opties waren indertijd is logisch aangezien dat de enige accounts waren waar je mee kon inloggen op Teams ongeacht het platform. Voor zover ik weet en nog kan vinden was Teams op Linux altijd gelijkwaardig aan de Windows en macOS versie.

[PureTryOut]

Zover ik mij kan herinneren kon je op Linux altijd maar 4 webcams tegelijkertijd zien waar je bij Windows e.d. er veel meer kon.

[DieMitchell]

waarschijnlijk is dit omdat er voor bedrijven geen goed alternatief is voor teams en office maar wel voor edge en vscode. geen idee van .net

[The Zep Man]

Heeft iemand bronnen die wat meer informatie delen over de haat-liefde verhouding van Microsoft ten opzichte van Linux? Software als Microsoft Edge, Visual Studio Code en .NET zijn al een tijdje beschikbaar, maar Microsoft Office en Microsoft Teams dan weer niet.

VS Code en .NET zijn met name voor ontwikkelaars. Edge (zeg maar Chromium) ook. Ontwikkelaars hoef je niet aan je ecosysteem te binden. Het zijn er maar weinig, en je hebt liever dat ontwikkelaars buiten jouw ecosysteem (ook) voor jouw ecosysteem ontwikkelen.

Office en Teams zijn productiviteitspakketten waarmee je gebruikers (waar er veel van zijn) naar jouw ecosysteem trekt. Net als win32 compatibiliteit zijn dat de gouden eieren die ervoor zorgen dat er geen discussie is over welk ecosysteem omarmd wordt, want er is in de praktijk maar één keuze. Die gouden eieren in dezelfde vorm uitbrengen voor andere platformen ondermijnt het eigen ecosysteem.

[DdeM]

Als die gouden eieren op andere platformen uitbrengen een probleem zou zijn dan zou Office for Mac ook niet bestaan, maar toch https://www.microsoft.com...mac/microsoft-365-for-mac

[maevian]

Microsoft heeft apple nodig, om niet als monopolist gezien te worden

[RobertMe]

Edge is gebaseerd op Chromium en dat is al cross platform.
Visual Studio Code is volgens mij begonnen als een fork van Atom, en ook dat was al cross platform.

Daarnaast wat @The Zep Man aanhaalt en Steve Ballmer bekend van is: YouTube: Steve Ballmer - Developers ("Developers, developers, developers, ..."). Het kost Microsoft relatief weinig om een Edge of VS Code aan te bieden voor Linux (zie hierboven, "het was er al". En Chromium wordt ook gewoon door bv Google bv verder ontwikkeld voor Linux waar MS op meelift). Terwijl ze met deze tools wel weer developers aan zich binden die daarmee ook Windows interessant houden. Ik als web developer die alleen maar Linux gebruikt kan een website nu toch/ook in Edge testen, kon dat niet zou ik niet specifiek Windows ervoor gaan gebruiken en dus zou het mogelijk zijn dat de door mij gemaakte website niet werkt in Edge en ik klanten zelfs zou bewegen naar "gebruik <een andere browser>".

[Loller1]

Visual Studio Code is volgens mij begonnen als een fork van Atom, en ook dat was al cross platform.

Visual Studio Code is geen fork van Atom.

[CAPSLOCK2000]

Heeft iemand bronnen die wat meer informatie delen over de haat-liefde verhouding van Microsoft ten opzichte van Linux? (...)Is dit strategie? Onwil? Of simpelweg te lastig

Ik denk het er geen simpel antwoord is, MS is een enorm bedrijf dat een reputatie heeft van interne silo's die soms geen idee lijken te hebben van wat andere afdelingen doen. Daar hebben wel meer grote bedrijven last van. Sommige afdelingen zien voordelen in Linux, anderen niet, weer anderen zien het als bedreiging, en ze hebben de vrijheid om daar hun eigen keuzes in te maken.

In het algemeen is MS steeds meer online aan het doen, steeds meer producten zijn ook of zelfs alleen als webversie beschikbaar. Op termijn verwacht ik dat de vraag voor native versies voor Linux zal verdwijnen omdat die er gewoon niet meer zijn. (Ik ben niet blij met veel van die webversies, maar dat is een ander verhaal).

[lasharor]

Er staat nergens in dit artikel waarom deze schenking belangrijk is?

.NET is toch van Microsoft? Dus, leest een beetje alsof ze de ontwikkeling van software waar ze zelf profijt van hebben nu overdragen aan de opensource community?

[KirovAir]

Mono is legacy. De laatste .NET versies draaien al op Linux/Mac waardoor Mono alleen interessant is voor legacy software of oudere games die nooit geport zijn naar Linux of Mac. Dat maakt Wine een meer dan logische keuze.

[Caayn]

.NET is al wat jaren gewoon opensource, daar veranderd deze actie niks aan.

Mono is een opensource implementatie van de standaarden waar .NET op is gebaseerd met als focus om compatible te zijn met .NET. Ontstaan omdat .NET in het verleden enkel beschikbaar was voor Windows. In het verleden gebruikte je Mono om multiplatform .NET compatible code te schrijven. Sinds een aantal jaar is dat overbodig nu .NET/C# officieel runtimes hebben voor andere systemen dan Windows.

Wat @KirovAir ook al zegt, Mono is tegenwoordig legacy en loopt achter op "gewoon"/Microsoft .NET. Voor Wine, mogelijk, interessant voor oude Windows-only applicaties gebouwd op .NET.

[Reactie gewijzigd door Caayn op 29 augustus 2024 08:49]

[xrf]

Oorspronkelijk was er .NET Framework, dat werkte alleen op Windows. Om toch .NET Framework-applicaties op Linux te kunnen draaien, is toen onafhankelijk het Mono-project start dat (met haken en ogen) .NET Framework-applicaties op Linux laat werken.
Mono werkt ook voor bestaande .NET Framework-applicaties waarvan de broncode niet beschikbaar is.

Later is Microsoft met .NET Core, later gewoon .NET, gekomen, een variant die gemaakt is om cross-platform te kunnen werken.
(Waarom niet gewoon .NET Framework voor OS X en Linux uitbrengen? Het is behoorlijk verweven met Windows-specifieke functionaliteit (elders in de comments wordt WinForms als voorbeeld genoemd) die je misschien nog net kunt emuleren maar die niet echt past binnen OS X en Linux.)

Echter, er zijn nog de nodige oude applicaties die met .NET Framework zijn gemaakt, en het kost werk om .NET Framework-specifieke code te vervangen door code die werkt met .NET Core - als je de broncode überhaupt al hebt.

Voor Microsoft is het logischer om zich toe te leggen op .NET (Core), want daarmee help je met het ontwikkelen van toekomstige programma's met jouw tools. Oude, al bestaande (binaries van) Windowsprogramma's op Linux kunnen laten werken is voor hun niet echt interessant. Logisch dus dat sinds ze eigenaar van het Mono-project zijn geworden, ze er niet veel energie in gestopt hebben.
Wine echter houdt zich bezig met het laten werken van bestaande Windowsprogramma's op Linux (waaronder computergames); voor hun is het Mono-project dus belangrijk om bestaande .NET Framework-programma's onder Linux te kunnen draaien.

[WernerL]

Heeft Mono uberhaubt nog meerwaarde nu .NET gewoon native op linux draait? Volgens mij was .NET Core wel ooit op Mono gebasseerd maar is het nu een eigen codebase.

Vroeger nog wel gebruikt toen je met C# GTK applicaties kon maken met monodevelop.

[Noxious]

Mono wordt nog wel veel gebruikt binnen Unity meen ik; en ook voor FNA en een aantal andere XNA-spinoffs (maar MonoGame is grotendeels of helemaal over naar dotnet).

[Wolfos]

Mono word in Unity voornamelijk gebruikt in de editor zelf om de game snel te kunnen herladen als de code wijzigt. Games worden veelal native gecompileert via IL2CPP. Als het goed is moet de volgende release (Unity 7) ook CoreCLR gebruiken en nemen we dus afscheid van Mono. Waarschijnlijk word de editor daardoor een stuk sneller.

Unity's Mono is wel een eigen fork dus het upstream project (dat al even niet meer geüpdatet word) is niet zo relevant voor Unity.

[Reactie gewijzigd door Wolfos op 29 augustus 2024 08:57]

[Noxious]

Hier zijn wel at uitzonderingen op, zoals sommige games die het bewust niet toepassen om meer moddable te zijn, of gameservers zoals die van Rust, waar het enkel op de anti-cheat code wordt gebruikt; maar op de rest bewust niet t.b.v. modding.

Maar verder goed punt ja, ik was vergeten dat het al een lange tijd een eigen fork is.

[himlims_]

leuk hopelijk kunnen de programmeurs van wine er iets nuttigs mee. geloof dat ik mono eens gebruikt heb om visualbasic (?) te kunnen gebruiken op toen malige mandrake.

[1Joshua5]

Stardew Valley was/is erin geschreven, en wordt binnen Unity gebruikt. Ik hoop dat Mono niet een stille dood sterft.

[Wolfos]

Komt helemaal goed. Stardew Valley draait op Monogame en die zijn inmiddels al over op CoreCLR. Unity onderhoud haar eigen Mono versie en werkt ook aan een overstap.
Dat hoeft niet te zeggen dat Stardew Valley gaat updaten (dat is ook niet nodig), maar het is wel een mogelijkheid.

Zolang het allemaal nog werkt is er voor games niet de noodzaak om de runtime te updaten.

[Reactie gewijzigd door Wolfos op 29 augustus 2024 11:54]

[Arroquw]

Dit is natuurlijk "gewoon" een kwestie van "wij willen deze legacy 'crap' niet meer ondersteunen en geen geld meer aan uitgeven, dus hier, succes ermee.".

Lekker makkelijk als een open source gebaseerd project free of charge je legacy meuk blijft onderhouden.

[Loller1]

Ze hadden het ook gewoon volledig de nek om kunnen draaien als je dat liever hebt. Je kan zelfs gewoon op de laatste versie die Microsoft heeft uitgebracht blijven zitten als protest als je hier zo'n probleem mee hebt.

[ShadLink]

Ondersteuning voor Mono / .NET Framework loopt gewoon op zijn einde en is in bijna alle oplossingen te vervangen door de .NET "Core" varianten (.NET 5 - .NET 9) Je kan niet van een bedrijf als MS verwachten lagacy software altijd te blijven ondersteunen.

Dat ze Mono nu aan de Open Source community schenken is IMHO enkel een goed teken.

[blorf]

Het wordt niet zo opgevat, maar volgens mij is het een soort troll, met name richting Wine die vanaf het begin eigenlijk Windows wilden vervangen maar voor altijd achter de feiten aan blijven lopen omdat ze bij MS alles mbt graphics wat iets te goed werkt gewoon vervangen met andere dll versies die ze opnieuw moeten voorkauwen.

[Arroquw]

Dat is inderdaad ook mijn idee

[BoerBart]

@EvelineM Volgens mij staat er een kleine typo in het bericht.

Regel 7:
"ontwikkelaars die Moni willen blijven gebruiken" - moet dit niet Mono zijn?

[EvelineM]

Dat klopt! Dank voor het melden, ik pas het even aan.

[FrostyPeet]

Doet Microsoft vaker. https://www.freeallegiance.org/ is ook zo'n project dat over is genomen door de "gemeenschap". The Greatest Game You Never Played was ooit de bijnaam.