docs/sources/mono-api-embedding.html

   1 <h2>Embedding Mono</h2>
   2
   3 <h4><a name="api:mono_jit_init">mono_jit_init</a></h4>
   4 <h4><a name="api:mono_set_dirs">mono_set_dirs</a></h4>
   5 <h4><a name="api:mono_runtime_exec_main">mono_runtime_exec_main</a></h4>
   6 <h4><a name="api:mono_runtime_exec_managed_code">mono_runtime_exec_managed_code</a></h4>
   7
   8 <h4><a name="api:mono_jit_cleanup">mono_jit_cleanup</a></h4>
   9 <h4><a name="api:mono_set_defaults">mono_set_defaults</a></h4>
  10
  11 <h3>Internal Calls</h3>
  12
  13         <p>The Mono runtime provides two mechanisms to expose C code
  14         to the CIL universe: internal calls and native C
  15         code. Internal calls are tightly integrated with the runtime,
  16         and have the least overhead, as they use the same data types
  17         that the runtime uses.
  18
  19         <p>The other option is to use the Platform Invoke (P/Invoke)
  20         to call C code from the CIL universe, using the standard
  21         P/Invoke mechanisms.
  22
  23         <p>To register an internal call, use this call you use the
  24         <tt>mono_add_internal_call</tt> routine.
  25
  26 <h4>Data Marshalling</h4>
  27
  28         <p>Managed objects are represented as <tt>MonoObject*</tt>
  29         types.  Those objects that the runtime consumes directly have
  30         more specific C definitions (for example strings are of type
  31         <tt>MonoString *</tt>, delegates are of type
  32         <tt>MonoDelegate*</tt> but they are still <tt>MonoObject
  33         *</tt>s).
  34
  35         <p>As of Mono 1.2.x types defined in mscorlib.dll do not have
  36         their fields reordered in any way.   But other libraries might
  37         have their fields reordered.   In these cases, Managed
  38         structures and objects have the same layout in the C# code as
  39         they do in the unmanaged world.
  40
  41         <p>Structures defined outside corlib must have a specific
  42         StructLayout definition, and have it set as sequential if you
  43         plan on accessing these fields directly from C code.
  44
  45         <p><b>Important</B> Internal calls do not provide support for
  46         marshalling structures.  This means that any API calls that
  47         take a structure (excluding the system types like int32,
  48         int64, etc) must be passed as a pointer, in C# this means
  49         passing the value as a "ref" or "out" parameter.
  50
  51 <h4><a name="api:mono_add_internal_call">mono_add_internal_call</a></h4>
  52
  53 <h3>Mono Runtime Configuration</h3>
  54
  55         <p>Certain features of the Mono runtime, like DLL mapping, are
  56         available through a configuration file that is loaded at
  57         runtime.   The default Mono implementation loads the
  58         configuration file from <tt>$sysconfig/mono/config</tt>
  59         (typically this is <tt>/etc/mono/config</tt>).
  60
  61         <p>See the <tt>mono-config(5)</tt> man page for more details
  62         on what goes in this file.
  63
  64         <p>The following APIs expose this functionality:
  65
  66 <h4><a name="api:mono_config_parse">mono_config_parse</a></h4>
  67 <h4><a name="api:mono_config_parse_memory">mono_config_parse_memory</a></h4>
  68
  69 <h3>Function Pointers</h3>
  70
  71         <p>To wrap a function pointer into something that the Mono
  72         runtime can consume, you should use the mono_create_ftnptr.
  73         This is only important if you plan on running on the IA64
  74         architecture.   Otherwise you can just use the function
  75         pointer address.
  76
  77 <h4><a name="api:mono_create_ftnptr">mono_create_ftnptr</a></h4>
  78