Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 54 reacties
Bron: Novell

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.FormsDe 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.

Moderatie-faq Wijzig weergave

Reacties (54)

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.
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.
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.
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;)
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.
Stomme vraag dan misschien... Kunnen we dan straks gewoon paint.net.exe typen in tcsh (of bash) en we draaien dan Paint.net?!?
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.
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. :)
Waarschijnlijk niet. Ik kan me zo voorstellen dat paint.net stijf staat van GDI en windows calls (buiten het framework om dan).
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....
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)
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.
En drie maal raden wie de basis voor Mono gemaakt heeft? Doe jezelf eens een plezier en zoek op Google eens op rotor.
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.
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.
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.
@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.
@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.
@humbug

Correctie.. 't is WoW64 (hoewel ik de vergissing begrijp).
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.
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.
Kost meer, in het beste geval zelfde resultaat maar dan ongetest.
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 ;)
Waarom zou je onder .Net geen calls kunnen doen naar undocumented API's? Met P/Invoke kun je ze gewoon aanroepen lijkt mij..
Office is geen .NET applicatie.
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.
Microsoft heeft een shared source implementatie van .net geport naar BSD. Het was een experiment dat nooit geoptimaliseerd is maar toch.
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.
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! :)
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).
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....?
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. :Y)
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.
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 :)
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.
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.
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.
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) ;)
waardoor het makkelijker zal worden om desktopapplicaties te porteren van het Windows-platform naar Mono

Porten? maar .NET zou nu juist zorgen dat er helemaal niet geport hoeft te worden.. ofwel als je netjes puur .NET zou schrijven dan zou het dus op elke .NET variant moeten werken.. Anders kun je net zo goed geen gebruik hier van maken.. pfff..
.NET is nooit bedoeld geweest om "crossplatform" in deze zin te zijn.
Uhm.. dat is juist wel de achterliggende gedachte geweest..
Ik sluit me bij SuperDre aan: wat moet er eigenlijk "geporteerd" worden? In essentie is .NET cross-platform, en applicaties die voor .NET geschreven zijn, kunnen uitstekend onafhankelijk van het OS draaien. Ook met betrekking dingen als tot paden en systeeminfo. Alleen dingen als P/Invoke enzo die worden lastig (onmogelijk?), maar dat probleem is met Java natuurlijk ook.
Nou, veel applicaties gebruiken 'wrapper' API's in .NET. Als je bijvoorbeeld 3d graphics wilt weergeven kom je snel uit bij Managed DirectX, wat een wrapper is van DirectX zelf. Zodra je zoiets gebruikt in je .NET applicatie heb je wel een probleem met porten.

Dat was eerst ook zo met Windows Forms, maar dat is nu dus opgelost door een implementatie te maken die gebruik maakt van native linux componenten.

Dus simpel .NET core/winforms/asp.net werkt nu. Maar GDI+, Managed DirectX en het aanroepen van 'traditionele' windows .dlls/activeX compontenten gebeurt ook nog vaak in '.NET software.'

Dat valt er dus te porten...
Ik mag toch hopen dat GDI+ wel werkt. Daar worden WinForms nml voor een belangrijk deel mee gerenderd...
Voor mij als .NET ontwikkelaar is dit echt geweldig om te lezen. Kan niet wachten om het uit te proberen! :9
Ik ben benieuwd hoe het er uit gaat zien. Waarschijnlijk ziet het er vreselijk uit onder gnome/kde.
gnome kde xcfce fluxbox (draaid 't niet gewoon op GTK dan?? dan werkt 't iig op alle versies).
ik geloof dat 1.2 voor t eerst volledige generics support, en dat lijkt me minstens zo belangrijk als Windows.Forms.
Naast Linux en MacOS, kan je natuurlijk ook Mono onder Windows installeren om je programma's goed te kunnen testen ;)

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True