[om-list] The Mono Project

[Mark Butler]

For those of you interested in C#, here is a nice article on the Mono Project, a project to create an open source C# / .Net implementation:

 http://www.ddj.com/documents/s=1818/ddj0201a/0201a.htm


-----------------------------------------------------------------------------------

Mono & the .NET Framework
Dr. Dobb's Journal January 2002

An open-source alternative
By Miguel de Icaza and Brian Jepson
Miguel is the founder and leader of the GNOME Foundation and cofounder and CTO of Ximian (http://www.ximian.com/). He can be contacted at miguel at ximian.com. Brian is the author of Database Application Programming with Linux (John Wiley & Sons, 2000) and coauthor of the Perl Resource Kit Utilities Guides (O'Reilly & Associates, 1997, 1998). He can be contacted at http://www.jepstone.net/. 

--------------------------------------------------------------------------------

Since the early days of the GNOME project (http://www.gnome.org/), there's been a tremendous demand to export API calls to programming languages other than C — Python, Perl, Ada, and Java, to name a few. However, the problem with language bindings is that it takes considerable time and effort to expose new APIs to languages other than C once those APIs are defined. This clearly impacts development costs. Like most organizations, Ximian (the company Miguel works for), wants to minimize costs when building large applications — and the .NET Framework appears to offer a way to do this. Take, for example, Evolution, Ximian's groupware suite that consists of approximately 750,000 lines of source code. By providing language independence, garbage collection, and thread support, the .NET Framework appeared to address some of the language-binding and development-cost challenges we face.
Furthermore, the C# language is a great object-oriented programming language our developers can use.

In March 2001, with this in mind, we started prototyping Mono — an open-source implementation of the .NET Development Framework — with the specific goal of addressing these cost and language-binding challenges. We were confident that if we made Mono (http://www.go-mono.com/) an open-source project, we could implement the framework, a JIT engine, and C# compiler relatively quickly. Nevertheless, we were pleasantly surprised when so many programmers expressed interest in contributing to Mono when we launched it with a partial implementation last July — even without a self-hosting environment on Linux. As it turns out, much of the class library code ended up coming from Windows programmers, as well as tools such as the IL assembler and code verifier. 

.NET Standardization
The .NET Framework can be divided into two parts: 

That which Microsoft, Intel, and Hewlett-Packard submitted to the European Computer Manufacturers Association (ECMA) as an open standard. The Framework Class Library (FCL), which includes class libraries that go beyond those submitted for standardization. Mono is based on the ECMA Common Language Infrastructure (CLI) and C# specifications (available at http://msdn.microsoft.com/net/ecma). Mono will also be compatible with the .NET Framework and offer compatible implementations of FCL libraries such as ADO.NET and Windows Forms. 

The C# specification describes the lexical structure of C#, the types it supports, and its syntax. C# was designed with the CLI in mind, so its structure complements the CLI.

The CLI specification, in turn, is broken down into five partitions: 

Partition I describes the underpinnings of CLI, which include the Common Language Specification (CLS), Common Type System (CTS), and Virtual Execution System (VES). 
Partition II describes the metadata that drives the operation of the VES. 
Partition III is a complete reference to the Common Intermediate Language (CIL), the instruction set to which C# programs are compiled. 
Partition IV describes the run-time libraries that support various CLI profiles. For example, the kernel profile is the smallest possible collection of APIs needed to implement the CLI. The compact profile is a superset of the kernel profile and includes simple XML support, networking (including HTTP), and reflection. 
Partition V includes miscellaneous information related to the specification, such as sample CIL programs and class library design guidelines. 
The Common Language Specification 
The CLS is a set of rules that guarantee language interoperability. A language is said to be a CLS consumer (for example, JScript.NET) if it can instantiate objects and invoke methods on them. A CLS extender language (such as C# and VB.NET) can act as a CLS consumer, but can also define new types and extend existing types. Applications and libraries that conform to the CLS can be consumed and extended. 

For example, the .NET Framework includes two integral types, UInt32 and Int32. Both are 4 bytes, but UInt32 represents an unsigned integer. As it happens, the CLS does not define an unsigned integer, and the UInt32 type is marked as not CLS compliant. If you use UInt32 in your application, it is not guaranteed to be portable to all CLI implementations.

The Common Type System 
The CTS specifies two fundamental data types for the CLI. Reference types live on the heap (a region of memory from which memory is dynamically allocated) and have a unique identity, lifetime management, and the ability to contain other types. Value types, on the other hand, are strongly typed blobs of data that live on the stack. In the declarations in Example 1(a), the struct, when viewed in disassembly, has no code — only fields. A value that has its types is an 8-byte blob of memory that has MyStruct superimposed on it; see Example 1(b). The object in Example 1(a), on the other hand, is more complicated. The fields are there, but there is also some code, see Example 1(c), to support the constructor. 

Starting with value and reference types, the CTS supports a variety of derived types. Value types give rise to such types as enumerations and primitive types. Reference types are the basis of delegates, arrays, interfaces, and classes. Reference and value types have common ground in boxing and unboxing operations: A value type can be boxed into an object and later unboxed back into a value type, as in Example 1(d).

The Virtual Execution System 
The VES specifies a hypothetical virtual machine that interprets a machine code called Common Intermediate Language (CIL). Like Java's JVM, this virtual machine is stack based. Unlike the JVM, this virtual machine does not exist in any ECMA-compliant implementation of .NET. This is because the ECMA specification stipulates that all CIL be Just-In-Time (JIT) compiled into native code before it's executed.

The VES supports several primitive integral and floating-point types, as well as an object type and a managed pointer type. The object type is a reference into managed memory (memory that is under the control of the CLI's garbage collector).

Mono Availability
The Mono C# compiler is written in C#, as are the Mono class libraries. The JIT engine is written in C. As of this writing, the Mono compiler runs on Windows as a standalone .NET application. To compile Mono on Windows, you need the Cygwin subsystem (http://www.cygwin.com/) — a Linux-like subsystem for Windows that includes the GNU C compiler and tools. (Mono requires the make utility and possibly some shell utilities that make depends on.) Mint, the Mono run time, runs under Linux or Cygwin.

You can get Mono at http://www.go-mono.com/. Follow the instructions to obtain the source and compile Mono, paying attention to recommended versions of tools and libraries. Since Mono is likely to be in a rapid state of development for some time, it may be sensitive to such things.