Add docs

svn path=/trunk/mono/; revision=15

16 files changed, 890 insertions, 0 deletions

diff --git a/doc/c-sharp b/doc/c-sharp
new file mode 100644
index 00000000000..d77490d46de
--- /dev/null
+++ b/doc/c-sharp
@@ -0,0 +1,114 @@
+* MCS: The Ximian C# compiler
+
+	MCS began as an experiment to learn the features of C# by
+	writing a large C# program.  MCS is currently able to parse C#
+	programs and create an internal tree representation of the
+	program.  MCS can parse itself.  
+
+	Work is progressing quickly on various fronts in the C#
+	compiler.  Recently I started using the System.Reflection API
+	to load system type definitions and avoid self-population of
+	types in the compiler and dropped my internal Type
+	representation in favor of using .NET's System.Type.  
+
+** Phases of the compiler
+
+	The compiler has a number of phases:
+
+		* Lexical analizer: hand-coded lexical analizer that
+		  provides token to the parser.
+
+		* The Parser: the parser is implemented using Jay (A
+		  Berkeley Yacc port to Java, that I ported to C#).
+		  The parser does minimal work and checking, and only
+		  constructs a parsed tree.  
+
+		  Each language element gets its own class.  The code
+		  convention is to use an uppercase name for the
+		  language element.  So a C# class and its associated
+		  information is kept in a "Class" class, a "struct"
+		  in a "Struct" class and so on.  Statements derive
+		  from the "Statement" class, and Expressions from the
+		  Expr class.
+
+		* Parent class resolution: before process can happen
+		  on the actual code generation, we need to resolve
+		  the parents for interfaces, classes and structs.
+
+		* Semantic analysis: since C# can not resolve in a
+		  top-down pass what identifiers actually mean, we
+		  have to postpone this decision until the above steps
+		  are finished.
+
+		* Code generation: nothing done so far, but I do not
+		  expect this to be hard, as I will just use
+		  System.Reflection.Emit to generate the code. 
+
+** Current pending tasks
+
+	Arrays declarations are currently being ignored, 
+
+	PInvoke is not supported.
+
+	Pre-processing is not supported.
+
+	Attribute declarations and passing is currently ignored.
+
+	Compiler does not pass around line/col information from tokenizer for error reporting.
+
+	Jay does not work correctly with `error' productions, making parser errors hard to point.
+
+** Questions and Answers
+
+Q: Why not write a C# front-end for GCC?
+
+A: I wanted to learn about C#, and this was an excercise in this
+   task.  The resulting compiler is highly object-oriented, which has
+   lead to a very nice, easy to follow and simple implementation of
+   the compiler.
+
+   I found that the design of this compiler is very similar to
+   Guavac's implementation.
+
+   Targeting the CIL/MSIL byte codes would require to re-architect
+   GCC, as GCC is mostly designed to be used for register machines.
+   
+   The GCC Java engine that generates java byte codes cheats: it does
+   not use the GCC backend, it has a special backend just for Java, so
+   you can not really generate Java bytecodes from the other languages
+   supported by GCC. 
+
+Q: If your C# compiler is written in C#, how do you plan on getting
+   this working on a non-Microsoft environment.
+
+   The compiler will have two output mechanisms: IL code or C code.
+   A compiled version of the compiler could be ran on Unix by just
+   using the JIT runtime.
+
+   The C output generation bit is just intended to be a temporary
+   measure to allow Unix hackers to contribute to the effort without
+   requiring Windows and Microsoft's .NET implementation to work on
+   the compiler.  So the MCS C# compiler will compile itself to C,
+   this code then compiled on Unix and voila!  We have a native
+   compiler for GNU/Linux. 
+
+Q: Do you use Bison?
+
+A: No, currently I am using Jay which is a port of Berkeley Yacc to
+   Java that I later ported to C#.  This means that error recovery is
+   not as nice as I would like to, and for some reason error
+   productions are not being catched.  
+
+   In the future I want to port one of the Bison/Java ports to C# for
+   the parser.
+
+Q: How do I compile it?
+
+A: Compiling MCS currently requires you to run my port of <a
+   href="http://primates.ximian.com/~miguel/code/jay.cs.tar.gz">Jay to
+   C#</a> on a Unix system to generate the parser, and then you need
+   to use Microsoft's .NET csc.exe compiler to compile the compiler.
+
+   It might be simple to port Jay.cs to Windows, but I have not tried
+   this. 
+
diff --git a/doc/class-library b/doc/class-library
new file mode 100644
index 00000000000..4cea4b24a9d
--- /dev/null
+++ b/doc/class-library
@@ -0,0 +1,67 @@
+* The Class Library
+
+	The Class Library should be compatible with Microsoft's .NET
+	implementation.  
+
+	Ideally as much code as possible should be written using C#,
+	in some cases we might either need to interface with code
+	written in C for large chunks of functionality (libart and
+	Gtk+ for example) or we would need to interface to the system
+	libraries (libc on Unix for networking functions for
+	example).  
+
+** Using existing components from GNOME.
+
+	Our current plan is to implement the GUI tools on top of
+	Gtk+.  The only problem is that applications from Windows
+	might expect to be able to pull the HWND property from the
+	widgets and use PInvoke to call Windows functions.
+
+** Class Library and Win32 dependencies.
+
+	There are a few spots where the Win32 foundation is exposed to
+	the class library (the HDC and HWND properties in the GDI+),
+	it seems from casual inspection that these can be safely
+	mapped to Gdk's GC and GdkWindow pointers without breaking anything.
+
+	The only drawback is that, we will not support PInvoke
+	invocations of Win32 code.  This could be possible in the
+	future by reusing pieces of Wine, and probably using Wine as
+	our toolkit, but we think this is not as important as most
+	people will always be isolated from the Win32 system.
+
+*** Initial GDI+ and WinForms implementation
+
+	The initial implementation will use Gtk+ as the underlying
+	toolkit, but implementations for other windowing systems
+	should be possible (specially thinking about PDA devices
+	here).
+
+	Since Gtk+ 2.0 has been ported to other windowing systems
+	other than X (frame buffer, Win32 and BeOS implementation
+	exist) it should cover most uses for most users.
+
+*** Database access
+
+	Implementing the ADO.NET functionality can be done through
+	reusing <a href="http://www.gnome-db.org">GNOME-DB</a> as
+	GNOME-DB was implemented precisely to provide an ADO-like
+	system for GNOME.
+
+*** Component Integration
+
+	We will provide a new namespace to use GNOME specific features
+	as well as a namespace to host Bonobo interfaces and classes
+	in Mono.  
+
+** Licensing
+
+	The class library will be licensed under the terms of the GNU
+	GPL, with the special provision that linking to this library
+	does not cause your application to be covered by the GNU GPL.
+
+	This is a stop gap measure, I am using this until we can
+	figure out why not use the laxer GNU LGPL license.  We do
+	request that contributors allow us to relicense the code under
+	a GNU LGPL like license in the future for inclussion in the
+	code base at any point in the future.
diff --git a/doc/download b/doc/download
new file mode 100644
index 00000000000..9ac6f1afa1f
--- /dev/null
+++ b/doc/download
@@ -0,0 +1,11 @@
+* Software Availability
+
+	The Virtual Execution System is available in package `mono'. 
+
+	Currently the code for the C# compiler as well as the error
+	test suite and the class library is in package `mcs', we will
+	move this later into `mono'.
+
+	The parser generator required by `mcs' is available in the
+	module `jay'. 
+
diff --git a/doc/gcc-frontend b/doc/gcc-frontend
new file mode 100644
index 00000000000..6046d6c66e5
--- /dev/null
+++ b/doc/gcc-frontend
@@ -0,0 +1,10 @@
+* The GCC front-end
+
+	The GCC front-end will be a front-end that would accept as
+	input in a binary file with codes in the Common Intermediate
+	Language (CIL) that will generate native code.
+
+	This will allow pre-compilation and full optimization to take
+	place before a program is executed.
+
+
diff --git a/doc/rationale b/doc/rationale
new file mode 100644
index 00000000000..a57132d939e
--- /dev/null
+++ b/doc/rationale
@@ -0,0 +1,159 @@
+
+The Mono Project
+
+* Background.
+
+	The GNOME project goal was to bring missing technologies to
+	Unix and make it competitive in the current market place for
+	desktop applications.  We also realized early on that language
+	independence was important, and that is why GNOME APIs were
+	coded using a standard that allowed the APIs to be easily
+	wrapper for other languages.  Our APIs are available on most
+	programming languages on Unix (Perl, Python, Scheme, C++,
+	Objective-C, Ada). 
+
+	Later on we decided to use better methods for encapsulating
+	our APIs, and we started to use CORBA to define interfaces to
+	components, and we complemented it policy and a set of
+	standard GNOME interfaces for easily creating reusable and
+	language independent components, controls and compound
+	documents.  This technology is known as <a
+	href="http://www.ximian.com/tech/bonobo.php3">Bonobo<a>, and
+	easy to use interfaces to Bonobo exist for C, Perl, Python,
+	Java.
+
+	CORBA is good when you define coarse interfaces, and most
+	Bonobo interfaces are coarse.  The only problem is that
+	Bonobo/CORBA interfaces are not good for small interfaces.
+	For example implementing an XML parser component and use it to
+	parse, create and walk an XML document would be inneficient
+	compared to a C API.
+
+* Microsoft's .NET
+
+	The Microsoft .NET initiative is confusing because it is a
+	company wide effort that ranges from development tools to end
+	user applications.  
+
+	Depending who you ask, you will probably get a different
+	answer on what .NET is, .NET is a branding name that has been
+	applied to:
+
+		* The .NET development platform, a new platform for
+		  writing software.
+
+		* Web services.
+
+		* Microsoft Server Applications.
+
+		* New tools that use the new development platform.
+
+		* Hailstorm, the Passport centralized single-signon
+		  system that is being integrated into Windows XP.
+
+	From all the above, the one I am interested in is the new .NET
+	development platform. 
+
+* The .NET development platform.
+
+	Microsoft has created a new development platform, the
+	highlights of this new development platform are:
+
+		* A runtime environment that provides garbage
+		  collection, threading and a virtual machine
+		  specification (The Virtual Execution System, VES)
+
+		* A comprehensive class library.  
+
+		* A new language, C#.  Very similar to Java, that
+		  allows programmers to use all the features available
+		  on the .NET runtime.
+
+		* A language specification that compilers can
+		  follow if they want to generate classes and code
+		  that can interoperate with other programming
+		  languages (The Common Language Specification: CLS)
+
+	The .NET development platform is similar to the goals we had
+  	in GNOME of giving language independence to programmers.  Any
+  	API that is written using a CLS provider language can be used
+  	by any language that is a CLS consumer.   Compilers generate
+  	code in a format called Common Intermediate Language (CIL)
+  	which is an intermediate representation of a compiled program
+  	and is easy to compile to native code or compiled using
+  	Just-in-Time (JIT) engines.  The restrictions placed by the
+  	runtime on the CIL byte codes ensures that it is possible to
+  	do a good job at optimizing the code in a JIT compiler. 
+
+	There is not really a lot of innovation in this platform, we
+	have seen all of these concepts before, and we are all
+	familiar with how these things work.
+
+	What makes the .NET development platform interesting is that
+	it is a good mix of technologies that have been nicely
+	integrated.   
+
+	The .NET development platform is essentially a new foundation
+	for program development that gives Microsoft a room to grow
+  	for the next years. 
+
+* ECMA standards.
+
+	Microsoft together with HP and Intel have submitted the
+  	specifications of C#, the runtime, the metadata and the
+  	other various bits of the .NET development platform to the
+  	ECMA for standarization.  
+
+* Mono: The GNU .NET implementation. 
+
+	Ximian has begun work on Mono, a project that aims to bring
+  	the .NET development platform to free systems.  
+
+	When the GNU project was launched, they picked the best
+  	operating system that was available out there, and they
+  	began to clone it: Unix.
+
+	The .NET development platform is a very rich, powerful, and
+  	well designed platform that would help improve the free
+  	software development platform.  Just like the GNU project
+  	began to clone Unix sixteen years ago, we will be cloning the
+  	.NET development platform because it is a great platform to
+  	build on.
+
+* What makes up Mono?
+
+	There are various pieces that will make up Mono:
+
+		* A C# compiler.
+
+		* A .NET executable tools.
+
+		* The Virtual Execution System: that will have the
+  		  Just-in-Time compiler, garbage collector, loader,
+  		  threading engine.
+
+		  A byte code interpreter will be provided for quickly
+  		  porting Mono to new systems. 
+
+		* An implemenation of the .NET class library.
+
+		* Visual development tools. 
+
+		* A CIL GCC frontend.
+
+* Why use GNOME components?
+
+	GNOME is an umbrella project that consists of infrastructural
+	components (GUI toolkit, XML libraries, CORBA implementation,
+	printing architecture, imaging system), a desktop environment,
+	and productivity applications.
+
+	The GNOME infrastructural components can be used to quickly
+	implement various pieces of the .NET API without reinventing
+	the wheel, and since all those components are licensed under
+	the terms of the GNU LGPL it is a perfect fit.  
+
+	Libart will be used to implement the Drawing.2D API; Gtk+ and
+	the GNOME libraries will be used to implement the WinForms
+	API and of course Glib and libxml will be used in various
+	places.
\ No newline at end of file
diff --git a/doc/roadmap b/doc/roadmap
new file mode 100644
index 00000000000..6cdfa1366a8
--- /dev/null
+++ b/doc/roadmap
@@ -0,0 +1,12 @@
+* Roadmap
+
+	We are working on the following three projects at Ximian:
+
+		The C# Compiler (mcs/mcs)
+
+		A .NET compatible Class Library (mcs/class)
+
+		The JIT/interpreter (mono)
+
+	
+		
\ No newline at end of file
diff --git a/doc/runtime b/doc/runtime
new file mode 100644
index 00000000000..877d3435e51
--- /dev/null
+++ b/doc/runtime
@@ -0,0 +1,70 @@
+* The MonoNet runtime
+
+	The MonoNet runtime will implement the JIT engine (and a byte
+	code interpreter for quickly porting to new systems), the
+	class loader, the garbage collector, threading system and
+	metadata access libraries.
+
+	Currently the runtime contains the beginning of an image
+	loader and metadata access entry points.  Since Beta2 has been
+	now released, it is possible to resume work using the ECMA
+	specs and testing with Beta2-generated executables.
+
+	The runtime core will be implemented in C, in a library
+	"libMonoVES.so".  
+
+** Executing MSIL/CIL images
+
+	The code will load an executable and map the references to
+	external assemblies to our own version of the assemblies on
+	GNU/Linux.
+
+	Our roadmap looks like this:
+
+		* Milestone 1: Fully read and parse all CIL byte-codes
+		  and metadata tokens (ie, a disassembler).
+
+		* Milestone 2: Complete an interpreter for CIL byte
+		  codes.  This interpreter can be used temporarly to
+		  run CIL byte code on a system where no JIT is
+		  available.
+
+		* Milestone 3: IA32 translating-JIT engine.
+
+		* Milestone 4: non-Intel port of the JIT engine.
+
+		* Milestone 5: Optimizing JIT engine port for IA32.
+
+		* Milestone 6: non-Intel port of the Optimizing JIT
+		  engine.
+
+	A setup similar to the Kaffe JIT engine can be used to
+	layout the code to support non-IA32 architectures.  Our work
+	will be focused on getting a IA32 version running first.  
+
+	The JIT engine should work on Linux and Win32, although you
+	might need to install the CygWin32 development tools to get a
+	Unix-like compilation environment which is what we know how to
+	use. 
+
+** Garbage Collection
+
+	We have decided to implement a tracing garbage collector,
+	which is very similar to the one being used by .NET.  For an
+	introduction to the garbage collection system used by
+	Microsoft's CLR implementation, you can read this book on <a
+	href="http://www.amazon.com/exec/obidos/ASIN/0471941484/o/qid=992556433/sr=2-1/ref=aps_sr_b_1_1/103-5866388-0492603">Garbage
+	Collection.</a>
+
+	Although using a conservative garbage collector like Bohem's
+	would work, all the type information is available at runtime,
+	so we can actually implement a better collector than a
+	conservative collector.
+
+** PInvoke
+
+	PInvoke will be supported, and will be used to wrap Unix API
+	calls, these in turn are required for reusing some of the
+	GNOME libraries that will reduce the work we have to do to
+	deliver a complete class library
+
diff --git a/doc/team b/doc/team
new file mode 100644
index 00000000000..eff7bc9d3d5
--- /dev/null
+++ b/doc/team
@@ -0,0 +1,2 @@
+* The MonoNet Team
+
diff --git a/web/c-sharp b/web/c-sharp
new file mode 100644
index 00000000000..d77490d46de
--- /dev/null
+++ b/web/c-sharp
@@ -0,0 +1,114 @@
+* MCS: The Ximian C# compiler
+
+	MCS began as an experiment to learn the features of C# by
+	writing a large C# program.  MCS is currently able to parse C#
+	programs and create an internal tree representation of the
+	program.  MCS can parse itself.  
+
+	Work is progressing quickly on various fronts in the C#
+	compiler.  Recently I started using the System.Reflection API
+	to load system type definitions and avoid self-population of
+	types in the compiler and dropped my internal Type
+	representation in favor of using .NET's System.Type.  
+
+** Phases of the compiler
+
+	The compiler has a number of phases:
+
+		* Lexical analizer: hand-coded lexical analizer that
+		  provides token to the parser.
+
+		* The Parser: the parser is implemented using Jay (A
+		  Berkeley Yacc port to Java, that I ported to C#).
+		  The parser does minimal work and checking, and only
+		  constructs a parsed tree.  
+
+		  Each language element gets its own class.  The code
+		  convention is to use an uppercase name for the
+		  language element.  So a C# class and its associated
+		  information is kept in a "Class" class, a "struct"
+		  in a "Struct" class and so on.  Statements derive
+		  from the "Statement" class, and Expressions from the
+		  Expr class.
+
+		* Parent class resolution: before process can happen
+		  on the actual code generation, we need to resolve
+		  the parents for interfaces, classes and structs.
+
+		* Semantic analysis: since C# can not resolve in a
+		  top-down pass what identifiers actually mean, we
+		  have to postpone this decision until the above steps
+		  are finished.
+
+		* Code generation: nothing done so far, but I do not
+		  expect this to be hard, as I will just use
+		  System.Reflection.Emit to generate the code. 
+
+** Current pending tasks
+
+	Arrays declarations are currently being ignored, 
+
+	PInvoke is not supported.
+
+	Pre-processing is not supported.
+
+	Attribute declarations and passing is currently ignored.
+
+	Compiler does not pass around line/col information from tokenizer for error reporting.
+
+	Jay does not work correctly with `error' productions, making parser errors hard to point.
+
+** Questions and Answers
+
+Q: Why not write a C# front-end for GCC?
+
+A: I wanted to learn about C#, and this was an excercise in this
+   task.  The resulting compiler is highly object-oriented, which has
+   lead to a very nice, easy to follow and simple implementation of
+   the compiler.
+
+   I found that the design of this compiler is very similar to
+   Guavac's implementation.
+
+   Targeting the CIL/MSIL byte codes would require to re-architect
+   GCC, as GCC is mostly designed to be used for register machines.
+   
+   The GCC Java engine that generates java byte codes cheats: it does
+   not use the GCC backend, it has a special backend just for Java, so
+   you can not really generate Java bytecodes from the other languages
+   supported by GCC. 
+
+Q: If your C# compiler is written in C#, how do you plan on getting
+   this working on a non-Microsoft environment.
+
+   The compiler will have two output mechanisms: IL code or C code.
+   A compiled version of the compiler could be ran on Unix by just
+   using the JIT runtime.
+
+   The C output generation bit is just intended to be a temporary
+   measure to allow Unix hackers to contribute to the effort without
+   requiring Windows and Microsoft's .NET implementation to work on
+   the compiler.  So the MCS C# compiler will compile itself to C,
+   this code then compiled on Unix and voila!  We have a native
+   compiler for GNU/Linux. 
+
+Q: Do you use Bison?
+
+A: No, currently I am using Jay which is a port of Berkeley Yacc to
+   Java that I later ported to C#.  This means that error recovery is
+   not as nice as I would like to, and for some reason error
+   productions are not being catched.  
+
+   In the future I want to port one of the Bison/Java ports to C# for
+   the parser.
+
+Q: How do I compile it?
+
+A: Compiling MCS currently requires you to run my port of <a
+   href="http://primates.ximian.com/~miguel/code/jay.cs.tar.gz">Jay to
+   C#</a> on a Unix system to generate the parser, and then you need
+   to use Microsoft's .NET csc.exe compiler to compile the compiler.
+
+   It might be simple to port Jay.cs to Windows, but I have not tried
+   this. 
+
diff --git a/web/class-library b/web/class-library
new file mode 100644
index 00000000000..4cea4b24a9d
--- /dev/null
+++ b/web/class-library
@@ -0,0 +1,67 @@
+* The Class Library
+
+	The Class Library should be compatible with Microsoft's .NET
+	implementation.  
+
+	Ideally as much code as possible should be written using C#,
+	in some cases we might either need to interface with code
+	written in C for large chunks of functionality (libart and
+	Gtk+ for example) or we would need to interface to the system
+	libraries (libc on Unix for networking functions for
+	example).  
+
+** Using existing components from GNOME.
+
+	Our current plan is to implement the GUI tools on top of
+	Gtk+.  The only problem is that applications from Windows
+	might expect to be able to pull the HWND property from the
+	widgets and use PInvoke to call Windows functions.
+
+** Class Library and Win32 dependencies.
+
+	There are a few spots where the Win32 foundation is exposed to
+	the class library (the HDC and HWND properties in the GDI+),
+	it seems from casual inspection that these can be safely
+	mapped to Gdk's GC and GdkWindow pointers without breaking anything.
+
+	The only drawback is that, we will not support PInvoke
+	invocations of Win32 code.  This could be possible in the
+	future by reusing pieces of Wine, and probably using Wine as
+	our toolkit, but we think this is not as important as most
+	people will always be isolated from the Win32 system.
+
+*** Initial GDI+ and WinForms implementation
+
+	The initial implementation will use Gtk+ as the underlying
+	toolkit, but implementations for other windowing systems
+	should be possible (specially thinking about PDA devices
+	here).
+
+	Since Gtk+ 2.0 has been ported to other windowing systems
+	other than X (frame buffer, Win32 and BeOS implementation
+	exist) it should cover most uses for most users.
+
+*** Database access
+
+	Implementing the ADO.NET functionality can be done through
+	reusing <a href="http://www.gnome-db.org">GNOME-DB</a> as
+	GNOME-DB was implemented precisely to provide an ADO-like
+	system for GNOME.
+
+*** Component Integration
+
+	We will provide a new namespace to use GNOME specific features
+	as well as a namespace to host Bonobo interfaces and classes
+	in Mono.  
+
+** Licensing
+
+	The class library will be licensed under the terms of the GNU
+	GPL, with the special provision that linking to this library
+	does not cause your application to be covered by the GNU GPL.
+
+	This is a stop gap measure, I am using this until we can
+	figure out why not use the laxer GNU LGPL license.  We do
+	request that contributors allow us to relicense the code under
+	a GNU LGPL like license in the future for inclussion in the
+	code base at any point in the future.
diff --git a/web/download b/web/download
new file mode 100644
index 00000000000..9ac6f1afa1f
--- /dev/null
+++ b/web/download
@@ -0,0 +1,11 @@
+* Software Availability
+
+	The Virtual Execution System is available in package `mono'. 
+
+	Currently the code for the C# compiler as well as the error
+	test suite and the class library is in package `mcs', we will
+	move this later into `mono'.
+
+	The parser generator required by `mcs' is available in the
+	module `jay'. 
+
diff --git a/web/gcc-frontend b/web/gcc-frontend
new file mode 100644
index 00000000000..6046d6c66e5
--- /dev/null
+++ b/web/gcc-frontend
@@ -0,0 +1,10 @@
+* The GCC front-end
+
+	The GCC front-end will be a front-end that would accept as
+	input in a binary file with codes in the Common Intermediate
+	Language (CIL) that will generate native code.
+
+	This will allow pre-compilation and full optimization to take
+	place before a program is executed.
+
+
diff --git a/web/rationale b/web/rationale
new file mode 100644
index 00000000000..a57132d939e
--- /dev/null
+++ b/web/rationale
@@ -0,0 +1,159 @@
+
+The Mono Project
+
+* Background.
+
+	The GNOME project goal was to bring missing technologies to
+	Unix and make it competitive in the current market place for
+	desktop applications.  We also realized early on that language
+	independence was important, and that is why GNOME APIs were
+	coded using a standard that allowed the APIs to be easily
+	wrapper for other languages.  Our APIs are available on most
+	programming languages on Unix (Perl, Python, Scheme, C++,
+	Objective-C, Ada). 
+
+	Later on we decided to use better methods for encapsulating
+	our APIs, and we started to use CORBA to define interfaces to
+	components, and we complemented it policy and a set of
+	standard GNOME interfaces for easily creating reusable and
+	language independent components, controls and compound
+	documents.  This technology is known as <a
+	href="http://www.ximian.com/tech/bonobo.php3">Bonobo<a>, and
+	easy to use interfaces to Bonobo exist for C, Perl, Python,
+	Java.
+
+	CORBA is good when you define coarse interfaces, and most
+	Bonobo interfaces are coarse.  The only problem is that
+	Bonobo/CORBA interfaces are not good for small interfaces.
+	For example implementing an XML parser component and use it to
+	parse, create and walk an XML document would be inneficient
+	compared to a C API.
+
+* Microsoft's .NET
+
+	The Microsoft .NET initiative is confusing because it is a
+	company wide effort that ranges from development tools to end
+	user applications.  
+
+	Depending who you ask, you will probably get a different
+	answer on what .NET is, .NET is a branding name that has been
+	applied to:
+
+		* The .NET development platform, a new platform for
+		  writing software.
+
+		* Web services.
+
+		* Microsoft Server Applications.
+
+		* New tools that use the new development platform.
+
+		* Hailstorm, the Passport centralized single-signon
+		  system that is being integrated into Windows XP.
+
+	From all the above, the one I am interested in is the new .NET
+	development platform. 
+
+* The .NET development platform.
+
+	Microsoft has created a new development platform, the
+	highlights of this new development platform are:
+
+		* A runtime environment that provides garbage
+		  collection, threading and a virtual machine
+		  specification (The Virtual Execution System, VES)
+
+		* A comprehensive class library.  
+
+		* A new language, C#.  Very similar to Java, that
+		  allows programmers to use all the features available
+		  on the .NET runtime.
+
+		* A language specification that compilers can
+		  follow if they want to generate classes and code
+		  that can interoperate with other programming
+		  languages (The Common Language Specification: CLS)
+
+	The .NET development platform is similar to the goals we had
+  	in GNOME of giving language independence to programmers.  Any
+  	API that is written using a CLS provider language can be used
+  	by any language that is a CLS consumer.   Compilers generate
+  	code in a format called Common Intermediate Language (CIL)
+  	which is an intermediate representation of a compiled program
+  	and is easy to compile to native code or compiled using
+  	Just-in-Time (JIT) engines.  The restrictions placed by the
+  	runtime on the CIL byte codes ensures that it is possible to
+  	do a good job at optimizing the code in a JIT compiler. 
+
+	There is not really a lot of innovation in this platform, we
+	have seen all of these concepts before, and we are all
+	familiar with how these things work.
+
+	What makes the .NET development platform interesting is that
+	it is a good mix of technologies that have been nicely
+	integrated.   
+
+	The .NET development platform is essentially a new foundation
+	for program development that gives Microsoft a room to grow
+  	for the next years. 
+
+* ECMA standards.
+
+	Microsoft together with HP and Intel have submitted the
+  	specifications of C#, the runtime, the metadata and the
+  	other various bits of the .NET development platform to the
+  	ECMA for standarization.  
+
+* Mono: The GNU .NET implementation. 
+
+	Ximian has begun work on Mono, a project that aims to bring
+  	the .NET development platform to free systems.  
+
+	When the GNU project was launched, they picked the best
+  	operating system that was available out there, and they
+  	began to clone it: Unix.
+
+	The .NET development platform is a very rich, powerful, and
+  	well designed platform that would help improve the free
+  	software development platform.  Just like the GNU project
+  	began to clone Unix sixteen years ago, we will be cloning the
+  	.NET development platform because it is a great platform to
+  	build on.
+
+* What makes up Mono?
+
+	There are various pieces that will make up Mono:
+
+		* A C# compiler.
+
+		* A .NET executable tools.
+
+		* The Virtual Execution System: that will have the
+  		  Just-in-Time compiler, garbage collector, loader,
+  		  threading engine.
+
+		  A byte code interpreter will be provided for quickly
+  		  porting Mono to new systems. 
+
+		* An implemenation of the .NET class library.
+
+		* Visual development tools. 
+
+		* A CIL GCC frontend.
+
+* Why use GNOME components?
+
+	GNOME is an umbrella project that consists of infrastructural
+	components (GUI toolkit, XML libraries, CORBA implementation,
+	printing architecture, imaging system), a desktop environment,
+	and productivity applications.
+
+	The GNOME infrastructural components can be used to quickly
+	implement various pieces of the .NET API without reinventing
+	the wheel, and since all those components are licensed under
+	the terms of the GNU LGPL it is a perfect fit.  
+
+	Libart will be used to implement the Drawing.2D API; Gtk+ and
+	the GNOME libraries will be used to implement the WinForms
+	API and of course Glib and libxml will be used in various
+	places.
\ No newline at end of file
diff --git a/web/roadmap b/web/roadmap
new file mode 100644
index 00000000000..6cdfa1366a8
--- /dev/null
+++ b/web/roadmap
@@ -0,0 +1,12 @@
+* Roadmap
+
+	We are working on the following three projects at Ximian:
+
+		The C# Compiler (mcs/mcs)
+
+		A .NET compatible Class Library (mcs/class)
+
+		The JIT/interpreter (mono)
+
+	
+		
\ No newline at end of file
diff --git a/web/runtime b/web/runtime
new file mode 100644
index 00000000000..877d3435e51
--- /dev/null
+++ b/web/runtime
@@ -0,0 +1,70 @@
+* The MonoNet runtime
+
+	The MonoNet runtime will implement the JIT engine (and a byte
+	code interpreter for quickly porting to new systems), the
+	class loader, the garbage collector, threading system and
+	metadata access libraries.
+
+	Currently the runtime contains the beginning of an image
+	loader and metadata access entry points.  Since Beta2 has been
+	now released, it is possible to resume work using the ECMA
+	specs and testing with Beta2-generated executables.
+
+	The runtime core will be implemented in C, in a library
+	"libMonoVES.so".  
+
+** Executing MSIL/CIL images
+
+	The code will load an executable and map the references to
+	external assemblies to our own version of the assemblies on
+	GNU/Linux.
+
+	Our roadmap looks like this:
+
+		* Milestone 1: Fully read and parse all CIL byte-codes
+		  and metadata tokens (ie, a disassembler).
+
+		* Milestone 2: Complete an interpreter for CIL byte
+		  codes.  This interpreter can be used temporarly to
+		  run CIL byte code on a system where no JIT is
+		  available.
+
+		* Milestone 3: IA32 translating-JIT engine.
+
+		* Milestone 4: non-Intel port of the JIT engine.
+
+		* Milestone 5: Optimizing JIT engine port for IA32.
+
+		* Milestone 6: non-Intel port of the Optimizing JIT
+		  engine.
+
+	A setup similar to the Kaffe JIT engine can be used to
+	layout the code to support non-IA32 architectures.  Our work
+	will be focused on getting a IA32 version running first.  
+
+	The JIT engine should work on Linux and Win32, although you
+	might need to install the CygWin32 development tools to get a
+	Unix-like compilation environment which is what we know how to
+	use. 
+
+** Garbage Collection
+
+	We have decided to implement a tracing garbage collector,
+	which is very similar to the one being used by .NET.  For an
+	introduction to the garbage collection system used by
+	Microsoft's CLR implementation, you can read this book on <a
+	href="http://www.amazon.com/exec/obidos/ASIN/0471941484/o/qid=992556433/sr=2-1/ref=aps_sr_b_1_1/103-5866388-0492603">Garbage
+	Collection.</a>
+
+	Although using a conservative garbage collector like Bohem's
+	would work, all the type information is available at runtime,
+	so we can actually implement a better collector than a
+	conservative collector.
+
+** PInvoke
+
+	PInvoke will be supported, and will be used to wrap Unix API
+	calls, these in turn are required for reusing some of the
+	GNOME libraries that will reduce the work we have to do to
+	deliver a complete class library
+
diff --git a/web/team b/web/team
new file mode 100644
index 00000000000..eff7bc9d3d5
--- /dev/null
+++ b/web/team
@@ -0,0 +1,2 @@
+* The MonoNet Team
+