Formatting changes

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

4 files changed, 113 insertions, 72 deletions

diff --git a/docs/assembly-bundle b/docs/assembly-bundle
index 25da5533370..3e64e147cb1 100644
--- a/docs/assembly-bundle
+++ b/docs/assembly-bundle
@@ -1,42 +1,57 @@
 
-	HOWTO bundle assemblies inside the mono runtime.
-
-Bundling assemblies inside the mono runtime may be useful for a number
-of reasons:
-	* creating a standalone complete runtime that can be more easily
-	distributed
-	* having an application run against a known set of assemblies
-	that has been tested
-
-Of course, there are drawbacks, too: if there has been fixes to the assemblies,
-replacing them means recompiling the runtime as well and if there are other mono apps,
-unless they use the same mono binary, there will be less opportunities for
-the operating system to optimize memory usage. So use this feature only 
-when really needed.
-
-To bundle a set of assemblies, you need to create a file that lists the assembly 
-names and the relative files. Empty lines and lines starting with # are ignored:
-
-== cut cut ==
-# Sample bundle template
-mscorlib: /path/to/mscorlib/assembly.dll
-myapp: /path/to/myapp.exe
-== cut cut ==
-
-Next you need to build the mono runtime using a special configure option:
-
-	./configure --with-bundle=/path/to/bundle/template
-
-The path to the template should be an absolute path.
-
-The script metadata/make-bundle.pl will take the specifie assemblies and embed 
-them inside the runtime where the loading routines can find them before
-searching for them on disk.
-
-There are still two issues to solve:
-	* config files: sometimes they are needed but they are not yet bundled
-	inside the library ()
-	* building with the included libgc makes it not possible to build a mono
-	binary statically linked to libmono: this needs to be fixed to make bundles
-	really useful
+	   HOWTO bundle assemblies inside the mono runtime.
+		   Paolo Molaro (lupus@ximian.com)
+
+* Intent
+
+	Bundling assemblies inside the mono runtime may be useful for a number
+	of reasons:
+
+		* creating a standalone complete runtime that can be more easily
+		distributed
+
+		* having an application run against a known set of assemblies
+		that has been tested
+	
+	Of course, there are drawbacks, too: if there has been fixes
+	to the assemblies, replacing them means recompiling the
+	runtime as well and if there are other mono apps, unless they
+	use the same mono binary, there will be less opportunities for
+	the operating system to optimize memory usage. So use this
+	feature only when really needed.
+
+* Creating the Bundle
+	
+	To bundle a set of assemblies, you need to create a file that
+	lists the assembly names and the relative files. Empty lines
+	and lines starting with # are ignored:
+	
+	== cut cut ==
+	# Sample bundle template
+	mscorlib: /path/to/mscorlib/assembly.dll
+	myapp: /path/to/myapp.exe
+	== cut cut ==
+	
+	Next you need to build the mono runtime using a special configure option:
+
+		./configure --with-bundle=/path/to/bundle/template
+
+	The path to the template should be an absolute path.
+
+	The script metadata/make-bundle.pl will take the specifie
+	assemblies and embed them inside the runtime where the loading
+	routines can find them before searching for them on disk.
+
+* Open Issues
+
+	There are still two issues to solve:
+
+		* config files: sometimes they are needed but they are
+	          not yet bundled inside the library ()
+
+		* building with the included libgc makes it not
+	          possible to build a mono binary statically linked to
+	          libmono: this needs to be fixed to make bundles
+	          really useful.
+
 	
diff --git a/docs/embedded-api b/docs/embedded-api
index 1df64744bb6..1fd739ae2ba 100644
--- a/docs/embedded-api
+++ b/docs/embedded-api
@@ -1,7 +1,7 @@
 	
 	   Embedding the Mono runtime, preliminary version
-
-		    Miguel de Icaza, Paolo Molaro.
+		 Miguel de Icaza (miguel@ximian.com),
+		   Paolo Molaro (lupus@ximian.com)
 
 	This document describes how to embed the Mono runtime in your
 	application, and how to invoke CIL methods from C, and how to
diff --git a/docs/exceptions b/docs/exceptions
index 881b207de1f..d5ecaeead43 100644
--- a/docs/exceptions
+++ b/docs/exceptions
@@ -1,5 +1,6 @@
-Author: Dietmar Maurer (dietmar@ximian.com)
-(C) 2001 Ximian, Inc.
+	     Exception Implementation in the Mono Runtime
+		 Dietmar Maurer (dietmar@ximian.com)
+			(C) 2001 Ximian, Inc.
 
 Exception implementation (jit):
 ===============================
diff --git a/docs/internal-calls b/docs/internal-calls
index 2f3d4abbda0..1fed33078e4 100644
--- a/docs/internal-calls
+++ b/docs/internal-calls
@@ -1,7 +1,19 @@
+			 Internal Call Topics
 
-* How to map C# types for use in the C implementation of internal calls
+* Introduction
+
+	The Common Language Infrastructure allows for methods to be
+	implemented in unmanaged code.  Unlike the Platform Invocation
+	services which provide marshalling and unmarshalling of data
+	from managed to unmanaged and viceversa the Internal calls do
+	not perform any kind of marshalling.
+
+* Basic Type mapping
+
+	The following lists how the C# types are exposed to the C API.
 
 	C# type 	C type
+	-----------------------------
 	char 		gunichar2
 	bool 		MonoBoolean
 	sbyte 		signed char
@@ -16,44 +28,57 @@
 	object 		MonoObject*
 	string 		MonoString*
 
-For ref and out paramaters you'll use the corresponding pointer type.
-Arrays of any type must be described with a MonoArray* and the elements 
-must be accessed with the mono_array_* macros.
-Any other type that has a matching C structure representation, should use
-a pointer to the struct instead of a generic MonoObject pointer.
+* Pointers
 
-Instance methods that are internal calls will receive as first argument
-the instance object, so you must account for it in the C method signature:
+	For ref and out paramaters you'll use the corresponding
+	pointer type.
 
-	[MethodImplAttribute(MethodImplOptions.InternalCall)]
-	public extern override int GetHashCode ();
+	So if you have a C# type listed as "ref int", you should use
+	"int *" in your implementation.
 
-becaomes:
+* Arrays
 
-	gint32 ves_icall_System_String_GetHashCode (MonoString *this);
+	Arrays of any type must be described with a MonoArray* and the
+	elements must be accessed with the mono_array_* macros.
 
+* Other Structures
 
+	Any other type that has a matching C structure representation,
+	should use a pointer to the struct instead of a generic
+	MonoObject pointer.
 
-* How to hook internal calls with the runtime
-
-Once you require an internal call in corlib, you need to create a C
-implementation for it and register it in a static table in metadata/icall.c.
-Add an entry in the table like:
+* Instance Methods.
 
-	"System.String::GetHashCode", ves_icall_System_String_GetHashCode,
+	Instance methods that are internal calls will receive as first argument
+	the instance object, so you must account for it in the C method signature:
 
-Note that you need to include the full namespace.name of the class.
-If there are overloaded methods, you need also to specify the signature
-of _all_ of them:
+		[MethodImplAttribute(MethodImplOptions.InternalCall)]
+		public extern override int GetHashCode ();
 
-	[MethodImplAttribute(MethodImplOptions.InternalCall)]
-	public extern override void DoSomething ();
-	[MethodImplAttribute(MethodImplOptions.InternalCall)]
-	public extern override void DoSomething (bool useful);
+	becomes:
 
-should be mapped with:
+		gint32 ves_icall_System_String_GetHashCode (MonoString *this);
 
-	"Namespace.ClassName::DoSomething()", ves_icall_Namespace_ClassName_DoSomething,
-	"Namespace.ClassName::DoSomething(bool)", ves_icall_Namespace_ClassName_DoSomething_bool,
+* How to hook internal calls with the runtime
 
+	Once you require an internal call in corlib, you need to
+	create a C implementation for it and register it in a static
+	table in metadata/icall.c.  Add an entry in the table like:
+	
+		"System.String::GetHashCode", ves_icall_System_String_GetHashCode,
+	
+	Note that you need to include the full namespace.name of the
+	class.  If there are overloaded methods, you need also to
+	specify the signature of _all_ of them:
+	
+		[MethodImplAttribute(MethodImplOptions.InternalCall)]
+		public extern override void DoSomething ();
+		[MethodImplAttribute(MethodImplOptions.InternalCall)]
+		public extern override void DoSomething (bool useful);
+	
+	should be mapped with:
+	
+		"Namespace.ClassName::DoSomething()", ves_icall_Namespace_ClassName_DoSomething,
+		"Namespace.ClassName::DoSomething(bool)", ves_icall_Namespace_ClassName_DoSomething_bool,
+