Mono 1.2 brengt Windows Forms naar Linux en Mac OS X

Novell heeft vandaag versie 1.2 van Mono uitgebracht. Deze nieuwe release van de opensource-implementatie van het .Net-framework voegt compatibiliteit toe voor technologiëen uit de 2.0-versie van het .Net-platform. De belangrijkste toevoeging in deze release van Mono is ondersteuning voor een volledig in C#-geprogrammeerde implementatie van Windows Forms, waardoor het makkelijker zal worden om desktopapplicaties te porteren van het Windows-platform naar Mono.

SharpChess in Mono met Win.Forms De virtual machine van Mono is aanzienlijk verbeterd, waardoor het geheugengebruik minder is en de snelheid is verbeterd. Ook de ondersteuning voor het runnen van Java-programma's is verbeterd. Ondersteuning voor Java was al aanwezig in eerdere versies van Mono, waardoor het onder andere mogelijk is om vanuit Java-programma's de classenbibliotheek van Mono te benaderen. Naast Windows Forms ondersteunt Mono 1.2 ook andere onderdelen van .Net 2.0. Volgens Miguel de Icaza, de oorspronkelijke auteur van Mono, is het developmentframework inmiddels dermate compleet dat het geschikt is om bedrijfskritische applicaties die voor het .Net-framework zijn geschreven te porteren naar Mono. 'De prestaties van ADO en ASP.Net zijn de laatste tijd flink verbeterd', aldus De Icaza. 'Samen met ontwikkeltools, documentatie, debuggers en profiles is het nu een meer afgerond project dan voorheen'.

Microsoft heeft zelf onlangs versie 3.0 van het .Net-framework uitgebracht. Novell stelt echter dat de meeste .Net-applicaties voornamelijk gebruik maken van 1.0-onderdelen van .Net, waardoor het geen groot probleem is dat Mono nu nog niet eens .Net 2.0 volledig beheerst. Novell en Microsoft maakten vorige week nog een overeenkomst bekend waarbij beide bedrijven patenten uitwisselen en Microsoft ruim 300 miljoen dollar aan Novell betaalt voor patenten. De patentovereenkomst die beiden bedrijven sloten had ook betrekking op Mono, maar Novell blijft benadrukken dat Mono momenteel geen patenten van Microsoft schendt. Mono is inmiddels beschikbaar voor diverse platformen. Naast Linux is er ook een versie van Mono voor Mac OS X waarbij ook een widget-toolkit beschikbaar is die gebruikmaakt van de native widgets van Mac OS X.

Reacties (54)

Verwijderd 9 november 2006 22:53

Even om mensen uit de droom te halen dat Mono ervoor zorgt dat windowsprogramma's draaien op andere besturingssystemen.

Mono is een implementatie van het .Net-framework. Het .Net framework is niet meer dan een gigantische kant en klare classenlibrary die gecompileerd is tot bytecode (net als java dat doet). Voor .Net zijn er wel nog speciale talen gemaakt door Microsoft zoals C#, J# en VB.Net. Ook voor enkele andere talen worden .Net versies voor gemaakt.

.Net applicaties die je hiermee schrijft worden ook slechts gecompileerd tot bytecode en zijn dus niet native x86 of iets dergelijks. Hierdoor kan je een programma zonder hercompileren draaien op verschillende architecturen zoals powerpc, arm, sparc, x86, en meer dmv een JIT-Compiler.

Echter zijn zover ik weet de meeste applicaties voor windows native win32 gecompileerd en dus geen .Net bytecode. Dus geen illusies, Office 2003 of iets dergelijks draait hier dus NIET mee op linux/osx. Misschien worden in de toekomst wel veel meer .Net applicaties geproduceerd.

smokalot @Verwijderd • 9 november 2006 23:11

windowsprogrammaas zullen zelden meteen goed draaien op Linux. Heel veel programmaas die in .NET geschreven zijn maken ook veel calls naar buiten, naar de oude win32 API, en die werken niet op niet-windows.

Maar het is wel veel makkelijker te porten naar bijvoorbeeld Linux. Miguel heeft bijvoorbeeld met een paar uurtjes werk Paint.NET geport. En er zijn ook veel bedrijven die bijvoorbeeld in asp.NET een webapplicatie hebben geschreven, en van hun klanten te horen krijgen dat ze t ook wel op apache met mod_mono willen draaien ipv op een windows server. En die bedrijven kunnen vrij eenvoudig de boel porten.

Voor niet-.NET win32 applicaties is er wine, en die doet het ook heel erg goed.

humbug @smokalot • 10 november 2006 01:35

Heel veel programmaas die in .NET geschreven zijn maken ook veel calls naar buiten, naar de oude win32 API, en die werken niet op niet-windows.

1 van de doelen van Microsoft is om voor elke Windows API een .Net versie beschikbaar te stellen. "Calls naar buiten" zijn dan ook lang niet altijd noodzakelijk. Probleem is wel dat de complete windows API niet zo 1,2,3 nagebouwd kan worden maar voor veel basis software was het eigenlijk al met Net 1.0 mogelijk om alles in .Net te doen en een hoop .Net software is dan ook vrijwel onafhankelijk van de Windows API.

Dat Mono veel APIs nog niet ondersteund is een veel grotere beperking dan het directe gebruik van de windows API vanuit .Net. Maar het komt, langzaam maar zeker.

Verwijderd @humbug • 10 november 2006 12:01

Maar dan nog, als je de .Net API gebruikt om iets in het register te schrijven, of om een .ini file in c:\WINDOWS te openen, dan zal je programma op een ander systeem dan Windows niet veel zinnigs doen. Op dezelfde manier kan je ook Java programma's maken die totaal niet portable zijn, een programmeur moet gewoon blijven nadenken, welke omgeving hij ook gebruikt. is maar goed ook, anders zou elke aap kunnen programmeren en zaten wij tweakers zonder werk;)

humbug @humbug • 10 november 2006 12:43

punt is dat je dat dusniet doet. Je schrijft via een api je settings weg. HOE dat gebeurd is niet relevant voor de applicatie. Dat kan in het registry zijn maar ook in een ini file of database. Belangrijk is dat de api ondersteund wordt, niet dat de regisry beschikbaar is.

Analoog voor bestandsnamen. Je vraagt op in welke directory je applcatie staat. Dat kan c:\windows zijn maar ook /home Een goed geschreven programma gebruikt gewoon de api die met beide uitkomsten overweg kan.

PrinsEdje80 9 november 2006 23:41

Stomme vraag dan misschien... Kunnen we dan straks gewoon paint.net.exe typen in tcsh (of bash) en we draaien dan Paint.net?!?

smokalot @PrinsEdje80 • 10 november 2006 00:32

ja, dat kan nu al wel (niet zo makkelijk met Paint.NET maar wel met een heleboel andere applicaties). Onder Linux that is, ik weet niet hoe het met andere unices is.

Het werkt onder linux precies hetzelfde als met java. Je definieert als het ware de interpreter:

echo ':CLR:M::MZ::/usr/bin/mono:' > /proc/sys/fs/binfmt_misc/register

t is niet helemaal echt dus, maar het werkt prima.

mOrPhie @PrinsEdje80 • 10 november 2006 00:27

De binary-compatibility hangt af van de .NET-versie vs. de Mono-versie en de compiler die gebruikt is, maar in theorie zou het moeten kunnen ja.

Prozaq @PrinsEdje80 • 10 november 2006 11:25

Waarschijnlijk niet. Ik kan me zo voorstellen dat paint.net stijf staat van GDI en windows calls (buiten het framework om dan).

Verwijderd 10 november 2006 09:32

In het .NET Magazine van Microsoft is ooit een mooi artikel verschenen over MONO.

Zie: http://www.microsoft.com/...azine/code/magazine7.aspx

Een aanrader voor een ieder die iets meer wil weten over de mogelijkheden van MONO.

Artikel is wel geschreven ten tijde van MONO 1.0 maar het geeft wel een goede indruk..

En ook leuk het is dus geplaatst in het .NET Magazine van MicroSoft....

Elephtera 9 november 2006 22:19

Een zeer mooi initiatief om meerdere windows programmas te kunnen draaien onder linux als er nog geen linux native voor is.

Eigenlijk had MS zelf het .NET framework moeten porten naar linux.

Word Office eigenlijk in het .NET framework gedraait? Want dan zou het betekenen dat ook dat binnenkort fatsoenlijk zou moeten kunnen draaien. (zonder wine)

daft_dutch @Elephtera • 9 november 2006 22:35

Microsoft doet er nog alles aan om Juist te voorkomen dat Microsoft programmas niet volledig kunnen werken zonder windows.
Bijvoorbeeld controleert MS of een programma wordt gedraait onder windows of wine. Als het onder wine draait kan je geen updates krijgen van MS sites.

Jeroen V @daft_dutch • 9 november 2006 22:42

En drie maal raden wie de basis voor Mono gemaakt heeft? Doe jezelf eens een plezier en zoek op Google eens op rotor.

Verwijderd @Jeroen V • 9 november 2006 22:52

En drie maal raden wie de basis voor Mono gemaakt heeft? Doe jezelf eens een plezier en zoek op Google eens op rotor.

Microsoft maakte .NET zodat Windows applicaties op andere CPU's dan x86 konden draaien. Voorheen zat Windows net zo vast aan x86 als dat x86 (praktisch gezien) vast zat aan Windows.

Aangezien x86 niet van Microsoft zelf is, was dat voor hun een onwenselijke situatie. Windows NT zelf draait al vanaf dag 1 op elke willekeurige CPU met relatief weinig moeite. De beschikbaarheid van non-x86 software voor Windows was echter zo laag dat deze feature van Windows in de praktijk nooit enige waarde heeft gehad.

De bedoeling van .NET is dus niet om Windows applicaties op niet-Windows operating systems te draaien, maar om Windows inclusief apps om non-X86 te kunnen draaien.

GiantRabbit @Jeroen V • 10 november 2006 00:48

Hmmm, mijn vermoeden was altijd dat Miscrosoft de .Net ontwikkelde omdat ze een 200-tal programmeurs aan het werk moesten houden. Nmlk. die van Visual J waren afgeknikkerd (SUN <=> MS, java lawsuit).
Konden ze meteen de wat diepere OS integratie en VB compatibiliteit uitvoeren; wat juist de reden was dat ze moesten stoppen van SUN.

humbug @Jeroen V • 10 november 2006 01:17

@terracotta:
Windows NT heeft gewerkt (en werkt nog steeds) op Alpha, PowerPC, MIPS en Itanium processoren. Daar zitten dus verschillende 64bits versies tussen. Wat wel een probleem was bij XP is dat microsoft er niet eventjes vanuit kan gaan dat alle oude software gerecompiled wordt naar 64bits. Microsoft heeft dus een 32 bits emulatielaag moeten schrijven voor de support op die applicaties. (WOW32) Ook zit je bij 64bit XP met driver ondersteuning. Het heeft geen zin om een OS te maken zonder dat er drivers voor beschikbaar zijn. Tot slot is XP 64 heel lang in Beta geweest, o.a. om de bovengenoemde redenen maar ook omdat Microsoft geen zin had om een product uit te brengen wat mogelijk niet lekker zou werken op Intel chips.

Dus het vergelijk van de ontwikkeltijd van Windows XP 64 met de 64 bits Linuxen slaat eigenlijk nergens op. Wie de eerste 64 bits Linuxen heeft geprobeerd weet dat je die vaak eerder als Alfa versie dan een volwaardig product kon beschouwen.

Korben @Jeroen V • 10 november 2006 03:01

@Terracotta:
Microsoft is anders wel bezig met een research-OS, Singularity genaamd, wat volledig managed draait. Overigens vind ik niet dat je kunt zeggen dat .NET-code in een 'virtual machine' draait. Er draait een garbage collector omheen en alles wordt gerefcount, ja, maar in de praktijk is het gewoon pure x86 code die native draait, nadat het is geJIT door de runtime.

Terracotta @Jeroen V • 10 november 2006 00:33

Windows op .NET laten draaien? Hoe wil je dat gaan doen. Windows applicaties tot daar aan toe, moeten ze enkel hun VM porten, maar een OS zal nooit op een VM draaien, mag ik hopen. En dat NT vanaf het begin op elke CPU werkt hebben ze met XP toch ontkracht, die kregen ze niet eens binnen een redelijk tijd naar 64-bit geport, wat bij linux nog geen maand geduurd heeft na de intro van de procesoren, bij windows duurde het meer dan een jaar.

Verwijderd @Jeroen V • 10 november 2006 09:25

@humbug

Correctie.. 't is WoW64 (hoewel ik de vergissing begrijp).

Verwijderd @Jeroen V • 10 november 2006 10:22

Er draait een garbage collector omheen en alles wordt gerefcount, ja

Nog niet eens dat, want met directives als bv 'unsafe' kun je dat ook nog omzeilen.
Voor de robuustheid niet altijd aan te raden, maar het kan wel de prestaties van je kritieke code aardig verbeteren.

Verwijderd @daft_dutch • 9 november 2006 22:45

Gasten, .Net is wel neergezet als de vervangende api voor win32. Dus zo gek zou het niet zijn om ook office volledig in .Net te proggen.

lvh @Verwijderd • 9 november 2006 23:02

Kost meer, in het beste geval zelfde resultaat maar dan ongetest.

YaPP @Elephtera • 9 november 2006 23:11

Word Office eigenlijk in het .NET framework gedraait? Want dan zou het betekenen dat ook dat binnenkort fatsoenlijk zou moeten kunnen draaien. (zonder wine)

Programma's als Office en bijv. Internet Explorer zijn typische Windows programma's die in C/C++ geschreven zijn en veel gebruik maken van API calls die *niet* in de MSDN gedocumenteerd staan. Dergelijke software draait niet op .Net

PrisonerOfPain @YaPP • 10 november 2006 00:07

Waarom zou je onder .Net geen calls kunnen doen naar undocumented API's? Met P/Invoke kun je ze gewoon aanroepen lijkt mij..

Ahrnuld @Elephtera • 9 november 2006 22:44

Office is geen .NET applicatie.

Verwijderd @Elephtera • 9 november 2006 22:48

Word Office eigenlijk in het .NET framework gedraait?

Absoluut niet. Office is een combinatie van C en C++ en maakt voornamelijk gebruik van win32, MFC en een eigen interne library voor widgets (MFC achtig als het goed is).

Omzetten van het huidige Office is onmogelijk, maar het is niet ondenkbaar dat er steeds meer delen van nieuwe versies .NET gaan gebruiken. Het kan echter wellicht wel 10 jaar of meer duren voordat op deze manier heel Office stukje bij beetje herschreven is.

d-snp @Elephtera • 10 november 2006 05:23

Microsoft heeft een shared source implementatie van .net geport naar BSD. Het was een experiment dat nooit geoptimaliseerd is maar toch.

84hannes @Elephtera • 9 november 2006 22:24

Ik weet niet heel veel van het .net framwork, maar het lijkt me sterk dat Microsoft Office slechts op .net draait. Aangezien Microsoft Office een doorontwikkeld produkt is zouden alle native API calls vervangen moeten worden door .net API calls. Het enige voordeel voor Microsoft zou dan zijn dat het ook onder Mac OS X en Linux draait, en vooral dat laatste kent weinig prioriteit.

Verder heeft Microsoft er weinig belang bij de .net op Linux/MacOSX draait, maar heeft volgens mij wel bewsut .net zo opgebouwt dat anderen een implementatie kunnen maken. Mooi dat Novell die taak op zich heeft genomen.

gamepower2005 9 november 2006 22:33

Het zou mooi zijn als meer Windows programma's onder Linux gedraaid zouden kunnen worden. Dit lijkt me een van de grootste drempels om over te schakelen naar Linux, je moet ineens met een hoop nieuwe programma's leren werken die vaak minder goed zijn dan de Windows varianten.

Als MS Office, Photoshop etc. ook stabiel op Linux gedraaid kunnen worden, zouden al een hoop mensen overstappen imo. Als daarnaast ook nog wat serieuze games voor Linux beschikbaar zouden komen, is er nog maar weinig dat je aan Windows bindt.

Mooi initiatief dus!

farlane @gamepower2005 • 10 november 2006 08:48

Vergeet niet dat het draaien op .NET niet de enige vereiste is voor een applicatie om portable te zijn.

Als de ontwerper van de software zelf allerlei OS dependent dingen inbouwt, of libraries gebruikt die alleen op Windows beschikbaar zijn heb je er nog niets aan.

gfgw @gamepower2005 • 13 november 2006 08:05

Als MS Office, Photoshop etc. ook stabiel op Linux gedraaid kunnen worden, zouden al een hoop mensen overstappen imo.

Alleen jammer dat Photoshop (hoogst waarschijnlijk) niet in .Net gebouwd is)

i-chat @gamepower2005 • 9 november 2006 23:02

ik denk dat je er wat dat betreft aardig naats zit,
die dingen die jij noemt zijn misschien (of eigenlijk wel zeker) belangrijk voor kleinere bedrijven...

maar bij grotere netwerken word al zeer regematig gewoon bijv. staroffice in een netwerk omgeving gedraaid, en worden de meesten documenten al standaard PDF (ipv doc).

grotere problemen zijn er met, photoshop achtige aplicaties, en vooral cad- en cam aplicaties...

echter nu mono een zeer sirrieuze stap maakt in de richting van NET 2, zou het wel eens gedaan kunne zijn met Autocad (onder windows) dat zover ik weet op NET-v2 draaid).

GiantRabbit @i-chat • 10 november 2006 00:43

Autocad is niet gebouwd op het .Net framework, maar er is een kleine "shell" gepubliceerd, zodat je dmv .Net met Autocad bepaalde calls kan maken.

Bijvoorbeeld: MySQL in PHP, iedereen weet dat MySQL niet in PHP is geschreven, maar je kan wel dmv. PHP MySQL calls maken.

Verwijderd @i-chat • 10 november 2006 12:33

maar bij grotere netwerken word al zeer regematig gewoon bijv. staroffice in een netwerk omgeving gedraaid, en worden de meesten documenten al standaard PDF (ipv doc)

Kan je een voorbeeld geven van een groot bedrijf dat staroffice draait en documenten in PDF opslaat? (en niet SUN zeggen aub.)

Ik zie niet in waarom bedrijven interne documenten als PDF's op zouden slaan aangezien deze dan niet meer bewerkt kunnen worden.

StarOffice is i.m.h.o. ook niet een "Enterprise-class" software. Het draait op mijn P4 3.0 met een GB aan ram onzettend traag. Voor klein en middel grote bedrijven misschien maar....?

StiGMaTa @Verwijderd • 10 november 2006 13:06

Gehandtekende (approved) versies worden vaak als pdf opgeslagen om de papierberg te doen dalen.
En dan heb ik het wel over een entreprise bedrijf dat in belgië alleen al voor (rechtstreeks) 10.000+ banen zorgt.

mxcreep @gamepower2005 • 10 november 2006 09:32

Hmm ik weet niet of het iedereen al is opgevallen, maar MS zelf heeft tot nu toe maar weinig software uitgebracht voor het .NET platform. En eerlijk gezegd denk ik dat dat voorlopig ook wel zo zal blijven. Ik zie het het meest ingezet worden in de custom applicatie bouw. Voor applicaties als Photoshop denk ik eerlijk gezegd dat het een stap achteruit gaat zijn als het geport zou worden naar .NET. Daar zijn nog steeds alle resources welkom om alle bewerkingen vlot uit te kunnen voeren. Laat staan producten als 3DStudioMax...dat wil je echt niet in een VM draaien. Voorlopig is de toekomst van C/C++ (unmanaged) nog niet onzeker

Verwijderd @mxcreep • 10 november 2006 10:27

Voor applicaties als Photoshop denk ik eerlijk gezegd dat het een stap achteruit gaat zijn als het geport zou worden naar .NET. Daar zijn nog steeds alle resources welkom om alle bewerkingen vlot uit te kunnen voeren. Laat staan producten als 3DStudioMax...dat wil je echt niet in een VM draaien.

Hybride-oplossingen zouden echter wel interessant zijn.
Bij een applicatie als Photoshop of 3DStudioMax zit er een grote en complexe GUI omheen, die waarschijnlijk prima naar .NET geport kan worden.
De bewerkingsfilters/rendering-routines kunnen ze in een native DLL plaatsen, en die vanuit de GUI aanroepen.
Zo is de applicatie grotendeels .NET, maar zullen de prestaties niet minder zijn.
Op die manier zijn ze ook meteen praktisch OS-onafhankelijk. De routines in die DLL zullen namelijk eigenlijk puur rekenfuncties zijn, en niet direct met het OS hoeven communceren. Is dus een stuk makkelijker portable te maken dan de GUI zelf.
Op alle populaire OSen voor x86 (Windows, OS X, linux..) zou je dan je applicatie met weinig moeite kunnen draaien.

jj71 @gamepower2005 • 10 november 2006 09:50

Als MS Office, Photoshop etc. ook stabiel op Linux gedraaid kunnen worden, zouden al een hoop mensen overstappen imo. Als daarnaast ook nog wat serieuze games voor Linux beschikbaar zouden komen, is er nog maar weinig dat je aan Windows bindt.

Daar ben ik het helemaal mee eens,

maar het heeft helemaal niets met Mono en .NET te maken.

smokalot 9 november 2006 23:06

ik geloof dat 1.2 voor t eerst volledige generics support, en dat lijkt me minstens zo belangrijk als Windows.Forms.

Verwijderd 10 november 2006 05:33

hier zat ik echt op te wachten, voor de mensen die mono nog niet kennen, tijd om het eens uit te proberen. de community is ook wel leuk en het gaat vrij goed vooruit