Understanding When to Call Native Code

Chapter 2, "Introducing the .NET Compact Framework," discussed the architecture of the .NET Compact Framework and its implementation of the Common Language Runtime. Managed applications and managed DLLs that support them, such as System.dll , are composed of Intermediate Language (.IL) byte codes. As a program calls class methods, the runtime compiles the byte codes of the methods into machine code instructions that can be executed by the CPU on the device running the program.

Chapter 2 explains the rules of how the Just-In-Time (JIT) compilation works. Understanding these rules is crucial to writing complex managed applications that perform well.

By developing with managed code, developers enjoy a variety of helpful features: Automatic garbage collection, access to a rich class framework, and the use of the powerful Visual Studio IDE to develop applications for devices. These features cut development and debugging time drastically, but they do not change the fact that the CLR and .NET Compact Framework have limitations that can only be circumvented by calling native code. The following list depicts situations in which accessing native code from managed applications is helpful:

• Managed code does not execute as rapidly as native code. Applications that include computationally intense subsystems can benefit substantially by writing the computationally intense subsystems in native code.

• There are many legacy DLLs written in native code that offer functionality that would be difficult or impossible to rewrite in managed code.

• Calling into native code makes it possible to interact with COM components on the device.

• The Windows CE operating system's application programming interface (API) is exposed as a set of function calls whose code is housed in several DLLs. In order to directly call with Windows CE OS, developers must invoke the native code housed in the DLLs. This activity is called Platform Invoking, or P/Invoking for short.