- 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.
+
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
-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):
===============================
+ 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
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,
+
projects / mono.git / commitdiff