There’s been a lot of chatter about Mono, recently, varying from “its a killer dev platform!” all the way to, “the patent issues are going to destroy us all!” And yet, in all this chatter, there has been relatively little chatter about DotGNU or Portable.NET. Well, you know what they say: learning is FUNdamental…What is DotGNU?
The DotGNU project – “GNU freedom for the internet.”
DotGNU is an offical GNU project; it is an attempt at providing a viable alternative to Microsoft’s .NET and Hailstorm business strategies. By providing viable alternative to Microsoft’s .NET technologies, the DotGNU team hopes to help prevent the ever spiteful vender lock-in and make sure the Internet is an not controlled by any one vender in particular.
DotGNU is a “meta project” composed of many different services; the main goal, as taken from the DotGNU FAQ, is “… to build a suite of free software tools to build and execute Common Language Infrastructure (CLI) applications.” These include free software tools include DGEE, a powerful webservice component; phpGroupWare, a suite of applications designed for e-collaberation, and, last but not least, Portable.NET.
What is Portable.NET?
Possibly the only part you really cared to read about. Portable.NET is an implementation of ECMA standards 334/335; that is to say, like Mono, it is a Free Software implementation of “.NET”.
But, then, how does Portable.NET differ from Mono?
-
Licensing.
The Portable.NET project uses a modified GPL license that contains a special linking exception that makes it possible to develop both open and closed source applications, so corporations and friendly ISVs need not fear here. The modified license is commonly referred to as “GPL plus linking exception.” This mouthful of a license is also used by the GNU Classpath project. t3rmin4t0r from the DotGNU project explains this importantance in our beloved OSNews.com comments section:
“There is also a potential problem related to patents: If you write software and release it under the MIT X11 license, and then you find out that someone has a patent on some idea(s) that you used in the program, this MIT X11 licensed program which you have written is actually proprietary software under the control of the owner of the patent.
The owner of the patent can control the code in the sense that he can dictate terms on how or when it should be distributed … And right now for Mono that is Microsoft . (L)GPL explicitly disallows this and therefore it can be taken up as an antitrust lawsuit rather than an open shut patent lawsuit.”
Whoa. Uncool!
-
Portability.
Portable.NET was designed with the concept of portability heavy in mind. For instance, for a long time – a long, long time – it was the only .NET implementation available on Mac OSX; the earliest screenshots of Portable.NET’s robust Windows.Forms implementation on Mac OSX can be found dating back to September of 2003. Portable.NET’s architecture makes it easy to extend it to different systems, x86, Sparc, ARM, ia-64, and the Playstation2, and Xbox gaming systems, just to name a few. Yes, an Xbox. Portable.NET is also known to run on several handheld devices such as the Sharp Zarius and an iPaq. There are many more screenshots available.
-
Windows.Forms
Windows.Forms was developed in a fundamentally different way than Mono’s current winelib-based code. Following true to Portable.NET’s insane portability, the Portable.NET crew worked slavishly to deliever unto you a set of libraries that were not only compatiable with Microsoft’s Windows.Forms, but that also worked under Linux and Mac OSX without dozens of hard to setup dependencies. How? They “hand drew” each and (practically) every widget in the Windows.Forms assembly, painting the result to an X11 server when finished. The result is a highly portable Winforms assembly that, like Portable.NET itself, can be seen running under everything from an iPaq to a Mac at http://www.dotgnu.org/screenshots.html
The best part? It runs pretty damn fast!
-
The Bilingual Virtual Machine.
Portable.NET’s virtual machine doesn’t speak strictly in IL, oh, no. At a higher level, it also speaks “CVM”; Converted Virtual Machine. By default, all bytecode is converted to CVM, although it is reasonable to expect that code could compile directly to CVM for languages that want to compile to Portable.NET and squeeze all the performance they can out of the interpreter. Yes, interpreter – as of this text, there is no JIT-engine available for Portable.NET. Do not assume this to mean that the virtual machine is slow, however; the interpreter is a powerful, high performance engine that can efficiently transform IL to CVM and execute on the fly; as reasoned at in this writeup. The CVM format and its significant advantages are way beyond the scope of this article, however, and discovering this “language” will be an exercise left up to the reader. That’s the cue for you to click the link two sentances back, man.
-
Legal issues.
Oh, boy, this is a fun one, but no talk about anything Mono or DotGNU related is not complete until its brought up. This is what Norbert Bollow had to say on the subject somewhere back in October of last year:
“We have obtained legal advice on how to go about creating legally bulletproof alternatives to the US-patent-endangered APIs. In a
nutshell, the design part has to be outside the US (and whoever does it should never take the fruit of this work with him into the
US), however the FSF patent lawyer says that implementing those replacement APIs in terms of already-exiting free libs will be
“entirely safe”, even for developers in the US.”
The End.
Suffice to say, the DotGNU project and Portable.NET have a lot to offer the GNU community – an entire breadth of technology ranging from webservices to a GNU-based authorization system (think “Hailstorm” but Free!) to .NET compatability, all in one convient, coherent package.
Remember: Unlike Mono, the Portable.NET project seeks to create an alternative but compatiable technology, much like the WINE project.
About the Author:
Mr. Washington is a completely unknown hobbyist hacker who went through the treacherously agonizing feat of using HTML code in a raw text editor, thus reaffirming his status as renegade hacking hero. He is learned in book-reading.
Remember: Unlike Mono, the Portable.NET project seeks to create an alternative but compatiable technology, much like the WINE project.
How is “an alterative but compatiable (sic) technology” any different from Mono? Mono is working towards compatability with MS.NET, and has an “alternative” in the form of the Mono stack using Gtk# and friends. So what differentiates the two? (in this particular instance, I’m aware of the differences in implementation, etc)
That probably should’ve read, the DotGNU Project…
‘cuz, DotGNU has Goldwater, groupware projects, etc; you know, instead of just implementing all the stuff Microsoft has like Hailstorm, they’re trying to compete with their own open and free technologies while remaining compatiable with the proprietary lewt.
Speaking of which, didn’t Hailstorm die an agonizing death two years ago or around then?
Why didn’t he say a thing about cscc?
but the DotGNU authorization system is decentralized and can be adapted to be used in any way you like from authorization on a pen drive, to having authorization service providers, something you might trust a Bank to provide since they have a good track record on personal information.
this is of course the last time I checked the site what was going on.
I’m using portable.NET on cygwin (Mono wouldn’t compile) and it is good. The Windows.Forms is much further along than Mono’s.
In a court of law you’re more likely to win with a BSD/MIT license because if you’re facing a jury your lawyer can make the argument that you don’t hurt the patent holder since whatever you do with their patent can be freely incorporated into their product. Think about it. If Mono adds some cool feature to ASP.NET, since they use the MIT license, Microsoft can legally add the feature as a proprietary add-on.
Chances are still higher than acceptable that you’ll lose, but the GPL makes it worse. Common sense would dictate that if you release a major patent violation under the GPL, that since the patent holder cannot directly benefit at all from your use, that you’re doubly screwed.
The CVM link goes to a single advertisement with no other information.
Bad copy/paste at work?
http://www.sys-con.com/dotnet/article.cfm?id=264 ?
First of all, windows forms on windows will be depricated in Longhorn. Second, X has no concept of widgets (from what I know, all it understands is to draw pixels), and that ugly looking windows controls on linux and os x will no help it’s adoption. Same thing with happened with java. You need to do this SWT style.
How will SWT help X with its non-native widget set? You’ve just said that X has no concept of a widget, so SWT isn’t going to do any good. All the toolkits on X draw their own widgets. Qt draws its own widgets and its pretty good looking on Windows and OS X.
Supposedly Pnet’s windows forms implementation has the ability to hook into native themes. I have no idea of how it looks because I’ve never seen it.
@Wee-Jim Goh – I guess what SpookyET is advocating is the “SWT approach”. Use Gtk+ on unix, windows controls on windows, etc…
I’m working on the theming hooks for native themes. Currently our first step is working on Qt because we have someone in our crew with Qt theming experience, and were looking for someone who has GTK/OSX theming so we can add those as well. The idea is to have a Theme manager that can auto detect your OS, and what environment you are running (KDE/Gnome, etc) and use it to paint widgets.
Currently the Qt stuff is working out great, here’s a very small sample screenshot of a few widgets using the plastik theme in KDE:
http://216.58.40.193/qtwinforms2.jpg
Who says winforms based on X has to be ugly? Looks pretty to me
Isn’t this what wxWindows are for?
there is wxWidgets.NET but it doesn’t get much press. I’ve played with it on Mono before. Worked fine, except for some MFC’ish api behavior.
Yeah wxnet does a pretty damn good job, they just don’t get the advertising. I use it and native widgets everywhere, that just rocks it’s little world
VCF (Visual Component Framework)
Damn, I pressed enter. There is also VCF (Visual Component Framework) at vcf.sf.net. It will be much better than wxWindows in the feature. Right now it is best on Windows.
GPL cannot protect against patents either
Think about it. If Mono adds some cool feature to ASP.NET, since they use the MIT license, Microsoft can legally add the feature as a proprietary add-on.
So MS is allowed to take open standards and embrace and extend ^H^H^H^H^H^H incorporate them into it’s own propietry products (for example, LDAP and Active Directory), but if anyone writes a free implementation of said extension, then extended again, but make the extension GPL’d, it suddenly invalid?
If this is the case, the US legal system is even more screwed up than I thought.
But when are we going to have this integrated nicely with an X server and a windowmanager in a nice standarized package that normal people can enjoy?