Aka PInvoke

Native and Managed Code

Native code is code written in C++ (or assembler) and compiled to produce a binary executable or .DLL. Native code applications are CPU specific and only require the executable and any other required native .DLLs. Native code applications and .DLLs do not produce MSIL code.

Managed code applications are written in C# or VB.NET using the .NET Compact Framework (CF). Unlike desktop .NET, C++ cannot be used to code .NET CF (Smart Device) applications. CF provides a rich library of functionality and is not compiled in a processor specific manner.

.Net CF is in the main, a subset of the desktop .NET Framework with some added features that make sense on a Windows CE/Windows Mobile device. It builds to the same MSIL code as the desktop .NET. As a simple test, build a simple CF windows form application and build it. Choose a non x86 platform such as Windows Mobile/Pocket PC. Build the application. Go to its build directory, on the development machine and run the application directly. It will run on the desktop provided no .NET CF specific features are used. This proves two things:

  • · The .NET Compact Framework is in the main a subset of the desktop .NET Framework
  • · .NET CF code is interoperable: The same compiled code will in principle run on any .NET enabled system (Same version of .NET).


A .NET CF application running on a desktop!

At one stage, I think it was VS 2005 Beta, there was a .NET CF debug option that could be configured that used the desktop.  IT would be productive to get that back!

Native code is used with Windows CE devices for

  • · COM and ActiveX applications
  • · MFC, ATL applications and components
  • · Windows Template Library (WTL), Standard Template Library (STL) applications and components.
  • · Direct calls to the operating system
  • · Taking to directly to hardware
  • · Device driver development

Managed code is used with Windows CE to exploit the APIs provided by the .NET CF. When a managed program is built it is built into MSIL code. This is bit like Java byte codes. When the method from some managed code is first run the MSIL code is “just in time” compiled into a native format for the target platform (ngened) which is cached for subsequent runs. Also managed code manages the runtime by automatically handling memory management (memory allocation and memory garbage collection) as well as rigidly enforcing data typing etc.

.NET CF Libraries

The .NET Compact Framework supports about 30 percent of the namespaces and classes of the full .NET Framework, and is about 8 percent of its size. To keep the size small, only the most important classes and members are supported.

.NET CF Limitations

The .NET Compact Framework does not support the following technologies:

  • · Server functionality
  • · ASP.NET
  • · Remoting
  • · Reflection Emit
  • · C++ development
  • · J# and JSL development
  • · The .NET Compact Framework does not currently support code access security

.NET CF Specific Libraries

  • · Microsoft.WindowsMobile.DirectX
  • · Microsoft.WindowsCE.Forms
  • · IrDAEndPoint: InfraRed
  • · SqlServerCe
  • · Microsoft.ServiceModel.Channels.Mail.WindowsMobile

Platform Invoke

This enabled managed (.NET) code to call unmanaged code. There is a marshalling of the calling parameters from .NET context to the unmanaged context, calling of the unmanaged code, then marshalling of the returned parameters and return type back into managed types. Note that when in the unmanaged phase, the code is unprotected. There can be memory leaks and system level errors through such things as memory access violations.

In the managed code you need to include System.Runtime.InteropServices
eg in C# at the top of the file:
using System.Runtime.InteropServices;

PInvoke Signatures

Given a native code .DLL function and its return and parameter types, it can be called directly from managed code via a signature and by using the correct marshaled data types with that signature. For Windows calls there is a site that lists PInvoke sigantures.

For example, the Windows FindWindowW in .NET CF:

[DllImport("coredll.dll", EntryPoint="FindWindowW", SetLastError=true)]
private static extern IntPtr FindWindowCE(string lpClassName, string lpWindowName);

This then can be used as IntrPr hndl = FindWindowW(“”,”MyApplication”);

The hndl then is the managed code version of a window handle.

A Handy Hint

I was running .NET applications on a development Windows CE system long before the Windows CE .NET debug tools were made available.  Also these tools were a bit flakey when first introduced… Not so now.  I just created my .NET CF project and targeted the tthe target Windows CE release directory as the build directory.  That way I could rebuild the application and run run it on the target development image.  This is because .NET and .NET CF generally only requires the built managed code application to be copied to the device. Anything copied to the Flat Release directory is available in the Windows directory.  This requires:

  • An instance of Visual Studio for the CE image.  Needs to be VS 2005
  • An instance of Visual Studio for the managed application (Can be VS 2005, 2008 but not 2010).
  • :The image to be an image with KITL.

Note that the only debugging you can do here is the “writeline” technique, so its probably best to develop the application elsewhere if possible; for example on a Windows Mobile emulator.  I have often thought that it would be useful to develop a VS extension that allowed debugging via this “portal”.