MANAGED-UNMANAGED TRANSITIONS in C#

Printer Data Matrix 2d barcode in C# MANAGED-UNMANAGED TRANSITIONS

Figure 9-1 shows a simple application that is built from two source files: one compiled to native code and one compiled to managed code. In this application, main, which is compiled to native code, calls the managed functions fManaged and fManaged2.

// compiled w/o /clr void __cdecll fManaged(); void __stdcall fManaged2(); int main() { fManaged(); fManaged2(); } // compiled with /clr using namespace System; void __cdecll fManaged() { Console::Writeline("fManaged called"); } void __stdcall fManaged2() { Console::Writeline("fManaged2 called"); }

Figure 9-1. Unmanaged code calling managed code It is possible to call fManaged and fManaged2 in main because both functions have a native calling convention. To perform the switch from native code to managed code, fManaged and fManaged2 are called via a thunk.

When a managed function has a native calling convention, the compiler can emit special interoperability metadata. The following listing shows the ILDASM output for fManaged and fManaged2. In this code, you can see an IL instruction that refers to this interoperability metadata: .method assembly static void modopt(System.Runtime.CompilerServices.CallConvCdecl) fManaged() cil managed { .vtentry 1 : 1 .maxstack 1 ldstr call "fManaged called" void [mscorlib]System.Console::WriteLine(string)

ret } .method assembly static void modopt(System.Runtime.CompilerServices.CallConvStdcall) fManaged2() cil managed { .vtentry 2 : 1 .maxstack 1 ldstr call ret } Both functions in this ILDASM output have a line starting with .vtentry. This .vtentry instruction is used to define data structures that are needed for method calls from native code to managed code. The term vtentry stands for vtable entry, because these data structures, like vtables for C++ classes, are arrays of function pointers. In further explanations, I will refer to these data structures as interoperability vtables. For each of the global functions fManaged and fManaged2, a separate interoperability vtable with just one element is created. The instruction .vtentry 1 : 1 in fManaged specifies that a native client can call fManaged by calling the address in the first slot of the first interoperability vtable. For fManaged2, the .vtentry instruction specifies that the first slot of the second vtable should be called. Interoperability vtables have a fixed location in the assembly, and they are initialized when the assembly (in this case, the sample application) is loaded. All information necessary for the initialization of the interoperability vtables can be found in the assembly manifest. Here is the interesting part of the sample application s assembly manifest: // Image ... .vtfixup .vtfixup .vtfixup .vtfixup base: 0x00400000 [1] [1] [1] [1] int32 int32 int32 int32 retainappdomain retainappdomain retainappdomain retainappdomain at at at at D_00007000 D_00007004 D_00007028 D_0000702C // // // // 06000001 06000002 06000004 06000018 "fManaged2 called" void [mscorlib]System.Console::WriteLine(string)

From the comment in the first line, you can conclude that the EXE file is loaded at the address 0x00400000. For the first vtable, the metadata provides a mapping from the relative virtual address (RVA) 0x7000 to metadata token 06000001. The runtime can use this information to generate an unmanaged-to-managed thunk for fManaged. The RVA is relative to the image s base address, 0x00400000. Therefore, the function pointer for the thunk to target function fManaged can be found at the virtual address 0x00407000. To find the thunk to fManaged2, you have to look at the virtual address 0x00407004. The metadata token identifies the managed target function. As described in 4, assemblies store metadata in various metadata tables. For functions, there is a special metadata table. In all metadata tables, rows are identified by a 32-bit value called the metadata

token. Metadata tokens for entries in the metadata table for functions and methods have the pattern 0x06 . When an assembly is loaded, the CLR iterates through all .vtfixup entries of the assembly. For each .vtfixup entry, it creates a thunk to the target function dynamically and stores a pointer to that thunk in the interoperability vtable specified by the RVA of the .vtfixup entry.