Slashdot Mirror
Portable.NET Now 100% Free Software
rhysweatherley writes "Finally after months of hard work and bucket loads of caffeine, the
DotGNU community has finally got
Portable.NET
to the point of building our C# libraries on many Free Software
platforms with our own C# compiler.
This is a big deal! Portable.NET is now 100% pure Free Software,
with no dependencies on third party C# tools. The compiler, which
is written in C, bootstraps off gcc, so there are no icky 'how to
compile the compiler' problems. And it's fast! The DotGNU team consists of lots of contributors, many of whom are
coincidentially named 'Rhys Weatherley,' but this wouldn't have been
possible without the support of the DotGNU community, especially
the Weekend Warriors. .NET is not the only thing we are doing. We're playing around with JVM and Parrot (of perl6 fame) backends to the compiler. And we have a
C compiler front-end that generates pure bytecode apps that can run
on any decent CIL implementation (Portable.NET, Mono, etc). We are about 95% of the way towards our first milestone of an
ECMA-compatible C# implementation. There are lots of things still
to be done in the low-level C# libraries, runtime engine, and the
compiler. So, if you have some time on your hands, and like messing with
languages and stuff, like yours truly ... have look and maybe
have some fun!"
This is a huge milestone. Now everyone who has two hands and 10 fingers needs to get in there and help rhys out! There are lots of things for people to work on. From Documentation to Libraries. so go to http://dotgnu.org and get started!
This is an excellent step forward for Linux on the Desktop. As Corporations begin to adopt the Microsoft .NET servers (for better or for worse), Linux desktop clients will be able to participate, and not be left out in the cold.
Congratulations to the development team on their achievement.
I'd rather be a conservative nutjob than a liberal with no nuts and no job.
before, the portable.net libraries had to be compiled using a certain proprietary C# compiler. Now, pnet can compile them by itself. So it is completely independant of proprietary software making it 100% free.
Yup they have copyrights but we are reproducing our implementation from ECMA spec (334 and 335) which are public
So their copyrights don't matter as we're not using their code . Their patents can be contested as ECMA does not look lightly on submarine patents
And we have GNu to support us !
Quidquid latine dictum sit, altum videtur
Mono's compiler is written in C#. Mono has a fast JIT. Mono's libraries include preliminary versions of Microsoft.NET libraries (see non-ECMA) like System.Windows.Forms and support for ASP.NET and ADO.NET. Mono is a joint project of Ximian and the larger community. Mono's commercial nature also limits community participation.
DotGNU is a GNU project and has a CLR/.NET environment sub-project called Portable.NET. Some of the key differences with Portable.NET and Mono are:
PNet has a C# compiler written in C that is very fast, but not as complete. As a consequence it does not suffer from bootstrapping problems.
PNet's compiler architecture is meant to provide great support for new CIL language compilers. Currently, cscc (that's the IL compiler suite) supports compiling C and C# to CIL with other languages on the way. It can also compile a subset of C# to the JVM.
PNet only has an interpreter called ilrun (no JIT) at this time. PNet's libraries are not as far along, but one of the goals is complete ECMA compatibility while Mono's goal is to track Microsoft.NET as
closely as possible. PNet is also talking with the Perl/Parrot folks about supporting C# on the next generation Perl runtime.
You should have a look at #Develop. I really like it and it is Free Software too :-)
t .a sp
http://www.icsharpcode.net/OpenSource/SD/defaul
granted that word and excel were practically taken from other suites
Word is a junk product as far as I am concened, but Excel 1.0 was clearly superior to the competition when it came out for the Mac. I know several people who dumped their PCs running Lotus after working with Excal. Of course they switched back when Excel came out for Windows.
Unfortunately Microsoft's market position has effectively quashed any attempts to displace Excel as the standard spreadsheet. There was a time when Wingz was better than Excel, and Lotus had a very interesting product for OS/2 for a while. This is very bad as far as I am concerned because Excel is really oriented more towards business users than I would like - which makes it harder to use for the scientific and engineering applications I am involved in.
It essentially means they wrote the compiler in C, and didn't write the compiler in C#, just to paint themselves in the corner and have a chicken and egg problem on how to compile a compiler written in C# if you don't have a C# compiler. I thought this was kind of odd myself, seems like a pat on the back for not doing something stupid, unless someone could point me to some need to compile a compiler in it's native language.
gcc itself has a bootstrap problem. The gcc code itself is actually pretty gcc specific, non-standard C code that can't be directly compiled correctly by other compilers. So there's an extra step, the gcc build routne adds a bootstrap compiler - youdon't compile the real compiler directly, you compile a small 'gcc-ish' compiler that though not complete, has a sufficent enough subset of gcc-isms to compile the real compiler.
If you are writing a C compiler in C, how do you compile it in the first place?
Traditionally, you compile by hand, which produces crappy but working code.. then you use the resulting compiler to re-compile, yielding clean code.
The entire monolinux operating environment and code-generation utilities are available at this link.
Get the release and report bugs if you can find !
PS: assigning them to me does not count as funQuidquid latine dictum sit, altum videtur
Very robust and well thought out language. Yes, Yes, I know blah blah blah M$ this and M$ that. But ya know what? I could give a flying crap about everyone's predisposition against Microsoft.
.NET -- not it's Windows-specific libraries.
I'm not sure Microsoft should be thanked for the greatness of the C# language on it's own, which I'm sure most of us agree is the best thing of
Thank Anders Hejlsberg, chief architect of the C# language, instead.
While I'm on the topic...
Anders Hejlsberg interviewed about C# #1
Anders Hejlsberg interviewed about C# #2
Pretty interesting, where he discuss the design goals of C#, how satisfied he is with what C# became, etc.
Beware: In C++, your friends can see your privates!
Hang on, .Net is essentially a replacement of COM! COM interop from C# is messy and feels like a hack at best
.Net framework. ADO (actually ADO.net is the replacement for ADO) is System.Data, DOM is System.Xml and the FSO (FileSystemObject) has been replaced by System.IO
None of the functional areas you mention are actually ActiveX objects - they are in fact namespaces in the
You're right, C is a fast and portable language. However, C hands the tedious job of memory management over to the programmer. Not all of us are as proficient at avoiding or debugging memory leaks as you. Most of us would rather spend our time productively coding the program. .NET provides automatic memory management, and is still impressively fast.
.NET's very nice hierarchy of classes also stands out in this regard (System.Windows.Forms).
.NET will be a major boon.
.NET could be a great thing to happen to Linux.
Also, C code requires the maintenance of multiple versions of your application - at least for applications that have a GUI.
Moreover, OOP is big; C is not an object-oriented language, and C++ is, for many, a convoluted nightmare. When you're building truly portable (no rebuilding necessary) enterprising applications,
Don't be blinded by your hostility toward Microsoft. After all, these projects help undermine the dominance of Windows by providing an alternative platform on which to run your programs.
I laughed at your ed source, I wish I had mod points.. I hated vi "it's better than ed" so much when I was programming UNIX at school, I actually coded on a mac and ftp'ed the code over to UNIX, i hated UNIX editors that much. You do realize your code will core dump on every read, a pointer isn't a buffer. And since you're discarding the string anyway...
int main( void )
{
char buffer[1000];
for(;;)
{
printf( "- " );
fgets(buffer, 1000, stdin);
printf( "?\n" );
}
}
There are a lot of statements here that need correction.
.NET) and Perl's .NET support is awesome.
.GNU project aims to bring ActiveX functionality over to *NIX, and port all of the cool ActiveX objects like ADO (Database), DOM (XML), System.DirectoryServices (LDAP), FSO (Files), etc.
.NET rewreites all of these, and MONO is writing all of them. ADO is replacd with the much more usefull ADO.net, DOM is boosted with XSL, XSD, X** (many other XML standards), System.Directory is also bein gimplemented. FSO is replaced by the much cleaner streaming interface. Mono is implementing all of these
First of all, cOM is on it's way out. It is being replaced by the new remoting and web services architecture. The new component arch works much better and is far easier to understand then the iUnknown interface in COM. COM+ services (most notable, transactions) are still being supported, and I have no doubt that Mono will do a great job implementing these.
Sadly, *NIX has never really implimented anything like COM.
Not true. In fact, there is a COM implemented for UNIX called XPCOM. It's the foundation of Mozilla. In addition, COM itself is a copy of CORBA/IDL (the tools for Corba/IDL are fairly poor tho). Gnome uses CORBA, and KDE also uses a distributed object protocol. In additional, almost every language supports SOAP (including
So, really: what is the need for C# on *NIX? None of my c# code that I am writing will port, because it is heavily dependent on the COM/ActiveX objects to get the real work done. Unless the
It's a really good thing that
The C programming language does everything I need it to do.
I too once was a C zealot. Then I had a job at Compaq which required me to develop in TCL which I hated at first, but eventually it opened my eyes a lot.
These days I do 90% of my work in python, it's a bloody great language. I remember when I first started hacking C about a decade ago, I'd pump out these little programs quite quickly but anything large took a lot of time, usually debugging. I never got tierd of C but I suppose when I started programming professionally it lost a lot of its appeal.
Anyway, I diverge.
Python lets me create complex systems very fast. The first time I used python I worte a client/server chat program, it took about half a day to do (including the basic python tutorial). I find I don't have the time to fuck around with C anymore, I don't find the joy in hunting down bugs either (at least I hunt less in python).
I still use C on occasion though. But only then I can't do it fast enough in python, the C code is still usually ran from python in the end.
He who defends everything, defends nothing. -- Fredrick The Great
There are four GUIs available for Mono which can be used for Portable .NET and Microsoft .NET too.
.DLLs for Windows.Forms to run on Windows.
1. GTK# - C#/CLI Bindings to GTK+ 2.0. Works on Windows and Linux. It also has C# Bindings for GNOME 2.0 as GNOME#, GConf as GConf#, Glade as Glade#, etc...
http://gtk-sharp.sourceforge.net
2. QT# - C#/CLI Bindings to QT 3.0 and KDE. Runs on Linux, but it is difficult to run on Windows though. It currently uses QtC for its C# bindings, but this will change.
http://qtcsharp.sourceforge.net
3. Windows.Forms - the System.Windows.Forms like GUI uses Winelib in Wine and monostub.exe in mono to run on Linux, and it uses native Windows
4. ASP.NET - System.Web works on Linux and Windows. It can be tested with XSP test server.
So, to test this, you will need mono, mcs, and xsp.
Why aren't they porting .NET/Windows Forms and so on to OS-X? For starters, it would make it easier to maintain their Office software base on a common platform. Are they worried that independant developers would do the same and mess up their master plan?
Sun has to strive for true platform independence with its Java, but since Microsoft is the Apple silent partner, what would be wrong, from Microsoft's dark, evil perspective, of running .NET on both Windows and Mac -- they run Office both places while there is no such thing as Linux-Office.
What precisely do you mean by "full ECMA certification"? Last I heard it was just the language itself and none of the libraries. Which is effectively the same as none of it being submitted since MS can still break compatibility across platforms that they themselves don't support. So it boils down to trust, which I have zero of in MS.
.class file, the constant pool contains
As for your endianness claims, here's part of two messages from a Google group search on the issue:
One:
"Java specifies the endianness used in object files, and (I believe) the
endianness used when writing numbers to binary data files, but the
language is defined in such a way that there is no way for a program to
tell which endianness is used for in-memory representations. So long
as the JVM (Java Virtual Machine) implementation does the correct
conversions when reading in `.class' files and when read/writing binary
data files, it is free to use a little-endian represention internally."
Two:
"If you'd bothered to study the JVM before jumping to such conclusions
you'd know that, in a
_unaligned_ data of _variable-length_, endianness is completely
irrelevant. The thing _has_ to be parsed byte-by-byte... Not even
the bytecode vectors are aligned within the file, although the
tableswitch' and 'lookupswitch' bytecodes are word-aligned within the
code vectors, so these are the only constructs that would require
extra work on a little-endian machine, and only in the 25% of cases
where the code vector happens to be word-aligned by accident....
Incidentally the format of the constant pool _inside the JVM_ is
completely undefined and up to the implementor."
"Gold still represents the ultimate form of payment in the world." - Alan Greenspan, 1999