Getting to Know Mono

At the heart of the CLI is the Common Type System (CTS). The CTS defines a shared data type system and the rules used in declaring, using and managing the types. By employing a strictly enforced type system, the CLI can ensure that type safety is maintained as well as make it possible for languages to interoperate with types of another language. In order to accommodate a multitude of different programming languages, the CTS furnishes two main data types that contain multiple subtypes, values (value types) and objects (reference types). Values are reserved for representing simple data types such as integers and floating-point values. Objects are used for the more complex entities required by programming languages.

The Common Language Specification (CLS) outlines the framework compilers must adhere to when generating libraries and binaries for cross-language interaction. The CLS is actually a subset of the CTS, providing a reasonable type system and rules a language compiler must support in order to produce compiled code that can be used or extended by other languages. A language has the ability to choose how much of the CLS to support. Languages that allow any CLS type to be used are called CLS consumers. Languages that allow CLS types to be created or extended are called CLS extenders. A language that fully embraces the CLS is both a consumer and extender.

When a source file is compiled by a CLI-compliant compiler, a binary file called a portable executable (PE) or sometimes referred to as an assembly, though an assembly can consist of one or more files, is output. The PE contains two important pieces of information. The first is metadata. Metadata is used to describe the types used as well as information the CLI uses to locate and load classes, lay out memory and other execution-time information. The second piece is the Common Intermediate Language (CIL) bytecode. CIL is a language-independent set of intermediate instructions. When a language is compiled for the CLI, CIL bytecode is produced. CIL is robust enough to to handle a myriad of different programming languages and is designed to be converted efficiently to native platform instructions. A snippet of CIL instructions for a “hello world” program written in C# can be seen in Listing 1.

Listing 1. Part of a Disassembled C# Program Showing the CIL Instruction Set

The Virtual Execution System (VES) provides the environment for executing programs written for the CLI. It loads, links, manages memory, handles security and exceptions and provides the support framework for executing CIL instructions.

The memory management supplied by the CLI is administered by a garbage collector (GC). Unlike other runtime environments, the GC of the CLI can be switched on and off within the source code. The data allocated and destroyed by the GC is called managed data. When the GC is not used on data, it is referred to as unmanaged data. Managed code, source code executed by the CLI, can access both managed and unmanaged data.

The goal of the Mono Project is twofold. First, it provides an implementation of the ECMA standards for the CLI and C#. Second, it adds compatibility with the Microsoft .NET development platform. Each part has its own intrinsic value and benefits Linux in different ways. If, for example, .NET compatibility was no longer available, Mono would remain a valuable development framework for Linux.

However, by adding .NET compatibility to the Linux platform, Mono makes software developed for Windows available to Linux. Along the same line of thought, developers wishing to make the transition to Linux application development will have access to a development framework with which they are already familiar, thereby lowering the learning-curve barrier.

The major portions of .NET that the Mono Project is working on delivering are Win Forms (System.Windows.Forms), ADO.NET and ASP.NET. Win Forms contain all the necessary methods, classes and events for creating GUI applications compatible with Microsoft Windows. Because it is nearly impossible to emulate the Windows GUI API calls with native Linux GUI toolkits, Mono is using WineLib (www.winehq.com) to provide the Windows interface. If you have ever seen an application running in Wine, you know it looks nothing like Linux desktop environments. To solve this, Mono is looking to add theming support to Wine to use the same rendering routines for the widgets as the rest of the desktop.

ADO.NET contains the .NET data access classes for Mono. ADO.NET offers more than mere database access. It provides a model for accessing data from any source in a disconnected, scalable method based on XML. At the time of this writing, about a dozen databases are working as Mono ADO.NET data providers. Work continues to increase the maturity and add additional database vendor support.

ASP.NET support in Mono is divided into two parts, web forms and web services. Web forms create the user interface for a web application. Much like Win Forms, web forms provide properties, methods and events for controls such as buttons, text boxes or complex controls made of multiple simple controls. This allows web form interfaces to be created in rapid application development (RAD) environments using drag-and-drop techniques similar to Glade on GNOME. This separates the presentation from the logic and lessens the amount of coding needed. Web services offer SOAP-based remote procedure call support. Using ubiquitous internet protocols like XML and HTTP, web services allow the sharing of data or logic over the network and even through firewalls. Any language supported by the CLI can be used to program the logic for ASP.NET. This also means that ASP.NET code is compiled and not interpreted like previous versions of ASP and other web-scripting languages. ASP.NET is available for Mono in either the XSP web server or in the mod_mono component for Apache 2.

In addition to the Mono class libraries implementing .NET, several other libraries and tools offer interesting and useful functionality:

Of course, these are only a few examples, but they're enough to illustrate the potential for developing with Mono for Linux and other platforms.