Managed Code and Native CodeFor most applications, the size of the application's code is significantly smaller than the size of the runtime and operating system code running below it. This is particularly true for graphical user interface applications, where the application developer deals with higher-level abstractions while a great deal of code executes in libraries below to deliver the user interface. This means that a well-designed and highly performing runtime is essential.There are two ways to approach the design of a managed code runtime:Implement as much of the runtime and programming libraries in native code as possible and then build a thin managed-code interface to expose it to application and component developers. This has the potential benefit of maximum performance but the downside of complexity and potentially lower reliability because the runtime is not taking advantage of its own managed code execution capabilities.Implement only what is absolutely necessary in native code and implement all other functionality in managed code. This has the potential benefit of increased portability, better reliability, and a forced dedication to getting the highest performance possible out of the managed-code execution engine because all code possible will be utilizing it.Whenever possible, functionality in the .NET Compact Framework was implemented in managed code; only about 20 percent to 30 percent of the total size of the .NET Compact Framework is due to native code. All the programming libraries were written as managed code. Only the execution engine itself and a small part of the graphics subsystem are written in native code.Using managed code for all the programming libraries allows them to be loaded, compiled, and memory managed just like any other libraries. Figure 3.1 shows a split between native code and managed code in the logical pieces of the .NET Compact Framework. Figure 3.1. Native and managed code components of the .NET Compact Framework.[View full size image] ![]() |