Interesting topics this month as well in the Linux Gazette newsletter: “Making Your Own Toy Boot Floppy“, “Meeting C# and Mono“, “Debian APT Part 1: Basic Commands” and “Using the Logical Volume Manager“.
Linux Gazette November 2002, Issue 84, is Out
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
a great article that goes unappreciated.
Thanks for the post Eugenia
Funny … I have read the LG every month since its inception, but the last time I’ve read it was over 2 years ago. Thanks for renewing my interest
Anyone knows why mono compiles to the .exe extension under linux???
>Anyone knows why mono compiles to the .exe extension under linux???
Because .NET are Java files embedded in .EXE and .DLL files.
Now this isn’t an explicitly anti Microsoft comment, so don’t take it that way. But I’m terribly scared of this whole .exe naming business. Microsoft’s naming conventions are horrendously ugly. I used to do Windows programming, and Win32 reads like some /. troll post. You’ve got 30 character structure names in all caps with no spaces! They make up random acronyms for everything, and make up their own words for concepts that already have accepted names. For an example of what I’m talking about, read the Portable Executable file format reference than read the ELF file format reference. Tell me which one is easier to understand. I just say the output of the mono dissasembler, and the minute I saw the acronym RVA, I got this horrible feeling. If mono becomes common in the UNIX world, maybe Microsoft’s naming conventions will too! I mean, you already have newbie programmers learning C++ with Visual C++, MFC, and Microsoft API examples, and the code they write is full of crappy naming conventions!
Stop the FUD. they are EXE becasue the standard calls for it. the Run-time looks for exe as the extention to the file and iif Linux is devoted to open standards, then this is perfectly fine…..and it is not embeding Java code.
funny, we used VC++ in my programming class and we were taught the Standard Library, nothing more.
“Because .NET are Java files embedded in .EXE and .DLL files.”
You are kidding right? It is not embedding Java files. Not even close…
-G
read the Portable Executable file format reference than read the ELF file format reference. Tell me which one is easier to understand
Pretty much the same, PE format was based on the ELF, the added stuff to the PE format is there so that we can have icons, bitmaps and (i think) windows gui descriptors for window menu’s and dialogs. I kinda like having the icons on the .exe file itself rather than on an .ico file like under linux, this is one of the things that bugs me on linux.
Anyway i don’t think that mono compiled executables are in the PE format, at least not on linux, but then again i could be wrong, And they are certainly not “Java files embedded in .EXE and .DLL files”
Just to fix some misconceptions….
The PE (Portable Executable) file format was originally based on COFF (Common Object File Format), not ELF. Try a google search for `PE File Format COFF’; the 6th result is a Microsoft page to download the PE Format Specification (with a click-through license which I haven’t read yet).
Mono generates files with a .exe or .dll extension because it generates PE files that can be executed on Windows. The ECMA standard specifies the use of PE files, so to be standard-compliant they must generate and consume PE files.
As for “.NET [being] Java files embedded in .EXE and .DLL files” (gmlongo), this is incorrect. Mono (and .NET) use Common Intermediate Language (CIL), not Java bytecode.
Information on CIL can be found in ECMA standard 335, at http://www.ecma.ch/ecma1/STAND/ecma-335.htm.
I took a stab at answering the “differences between Java bytecode and CIL” question before; my answer can be found at: http://lists.ximian.com/archives/public/mono-list/2002-September/00…
Short answer: CIL was designed to be easily JIT-able, and for future Generics support. Java bytecode was designed to be easily interpreted.
Something my mailing list answer missed was that Java bytecode allows for stack slots to be re-used by variables of different type: the same slot may be used as an int in one spot and as an object in another. This makes JITing difficult. CIL requires that a stack slot always have the same static type, simplifying JIT implementation.
If you have any other questions, feel free to contact me.
– Jon