Mono, more on cross-platform


Mono (very different from mono), is, at its core, an implementation of the Common Language Specification - which we purposefully made public domain through ECMA.  Mono is pretty cool, too, and I'm personally glad to see it.  They even praise the standard Microsoft helped develop:



The Common Language Infrastructure platform is similar to the goals we had in GNOME of giving language independence to programmers. It is more mature, documented, larger in scope, and has a consistent design.


What makes the Common Language Infrastructure development platform interesting is that it is a good mix of technologies that have been nicely integrated.


Which is a welcome change from what we usually hear from the open-source community.  Garrett mentioned:



Without System::Windows::Forms , having the CLR on Mac OS X and FreeBSD is kinda like a mule with spinning wheel : no-one knows how he got it, and be damned if he knows how to use it 🙂


Well, Lyle... I mean Garrett, remember that the SSCLI is in its first version - not everything is there yet.  And GTK# looks like a fairly good idea.  But the truth is that Windows::Forms is a COM-interop wrapper for the native Win32 GDI, which hasn't been ported to other platforms, and likely won't be - except by those great people over at WINE :).  What you ought to be wondering about is WinFX.  And I don't know the answer to that question...

Comments (4)
  1. Anonymous says:

    I assume you’re also not thinking about the electronica group Mono 😉

    http://www.allmusic.com/cg/amg.dll?p=amg&uid=UIDMISS70312081555012502&sql=B6orj28vt05ja

  2. Anonymous says:

    Kinda on a note from the other Cross-Platform thread as well as this one, check out http://www.wxwindows.org/ which provides native GUI while staying cross-platform. There are C# bindings in the works if not done already for this.

  3. Anonymous says:

    Ah, yes.

    A few points:

    Microsoft SSCLI is never going to have S::W::F functionality on MacOS X or FreeBSD, First Version or not. The Reason: S::W::F is Win32 api centric. Without the underlying API, it would be a monumental task to port it to an alternative archetecture.

    Microsoft has pretty much made Rotor simply to show others how it is done–the license restricts the possibility for commercial use.

    So, the only likely candidate for getting S::W::F working on other platforms seems to be Wine. Sounds good in theory, but less workable in practice. I’ve worked with both Wine and Winelib, and built the S::W::F stuff for Mono.

    Winelib is a funny beast. In order to use it you must still setup a .winerc file, which is used to tell Winelib how your unix filesystem should be made to look like a windows filesystem so that winelib can represent it as a file system with drive letters, etc. You also have to build a registry, which is quite a pain too. Then when you are finished, you have an application that mistakenly thinks it is running on Windows, therefore doesn’t operate the way it should. (kinda like cygwin binaries on Windows, thinking they are unix-style apps, and have the windows drives mapped into a single unix style tree).

    So, enter GTK#. Same exact problem, but in reverse(it needing cygwin on windows, with all that baggage)–Although much much cleaner built, and it isn’t such a pain to use, except I haven’t seen it run on .NET, just mono on XP.

    WinFX won’t change anything, it just raises the stakes.

    Personally, I’m pretty damn happy on windows these days. Best tools for development I’ve ever had, fastest development I’ve had, my clients are happy with how fast things go. I’ve only got one Java-based client left, and they seem to be clinging to that like a rat on a sinking ship.(sigh). The custom work I have to do for them takes me probably 4 or 5 times longer on Java with JNI than it would on .NET.

    Wow. I didn’t mean to rant like that. 🙂 Maybe it’s time I got my own blog :p

  4. Anonymous says:

    Hi Andy,

    I am using Visual Studio 7.0 (2002?). I turn on my computer in the morning, and run it until midnight and my visual studio is always open. however, it consumes 60-150MB Virtual memory, specifically when i use VisualPerl (I usually use Visual C++). sometimes i need to run two instances of visual studio, but virtual memory usage keeps growing in both processes. do you know any fixes, or suggestions?

    btw, i am very glad to hear that i can use clr on "chuck" (my freebsd box, running natd). i prefer using clr, not java (i dont know java + dont want to learn, anyways). they say java is platform independent; but java brings its platform with itself and java itself is too heavy, i think. but it is a little different for microsoft, i think. microsoft supports similar byte-code compatibility for non-windows platforms (this is what i understand).

    in fact, an ABI (Application Binary Interface) support at native code level could be better, but since windows does not seem compatible with unix-flavors, this seems impossible for awhile. but probably clr runs faster than java, i believe this.

    as i have posted in my prior posts, i have never used .net. i will say one more thing, but i dont know if it is correct, so it contains a question as well; we dont need windows forms or anything else dealing with user-interface to run a service at the server, right? i think it is nonsense to run a freebsd operating system at your desktop (my opinion, can be used for software development, at the desktop). so, if i can write and run servers running on clr on a freebsd box, i would be very glad! i dont care if i can use windows forms or sort of things; i just need to transfer data between a server and a client, and i dont want to suffer thinking about "should i write my own tcp server and protocol, or should i use another technique which is using apache http server, or should i use…".

    i might be wrong, because i have a very brief knowledge about .net and clr. if i am wrong, please correct.

    PS: Andy, i really need a solution to my visual studio problem, please do not suggest me vs 2003 :/ thanks!

Comments are closed.

Skip to main content