Module 3:

Windows Mobile 5.0: Native Code Interoperability.

Applies To:
• Microsoft Windows Mobile 5.0 Development Platform.
• Microsoft Windows Mobile 5.0 SDKs (Both Pocket PC and Smartphone)
• Microsoft Visual Studio 2005 Professional/Developer/Team Suite Editions.
• Microsoft .NET Compact Framework 1.0/1.1/2.0.

Pre-Requisites: This document is targeted to audience who had already worked on

Windows Mobile 5.0 Platform and is familiar with Windows Mobile Programming
Model. It is recommended that one should have understood following before starting
this module.

• .NET Compact Framework 1.0/1.1/2.0.

• Basic Programming experience on Managed and Native Programming models.

Introduction:
In this module we are going to talk about one of the most discussed issue in any
Technology space-Interoperability. This Reference material will try to define what
is Interoperability, Why do you need to Learn/Understand the Interoperability and
How do you achieve Interoperability in your Windows Mobile Applications.

What is Interoperability?
Interoperability is defined as "The capability to communicate, execute programs, or
transfer data among various functional units in a manner that requires the user to
have little or no knowledge of the unique characteristics of those units". Or in a
layman’s terminology it is the ability to write an application that makes use of more
than two-different-Programming Models.

Why do we need to learn Interoperability?

You might be thinking that in previous modules we discussed almost everything on
.NET Compact Framework and managed code; with managed code it is easy to write
applications, it automatically takes care of Memory management, reduces time to
development and more over that it is really easy to build applications that targets
Windows Mobile; But not everything is handled by managed code! If you have
understood the .NET Compact Framework Architecture you might have found that it
adds an extra layer between your application and OS. And when you are writing
certain applications such as System level Applications; you may want to call and use
certain OS functionalities into your App., but because of this extra layer sometimes
your application may perform slower than expected.
To write these nature of applications you need to code them in Native programming
model; native programming model has got full access to the platform (i.e. you have
access to all the OS functionalities that are made available by your OS); Relatively
deterministic execution time, and more over you will be coding these applications in
our very familiar and known old C/C++. But as I mentioned earlier the same is true
for native code also; it may not provide everything that you would have expected!
With native programming model coding can be very complex, and hence debugging
will become more difficult, more over native programming model enforces developers
to take of memory management by application itself and many more things that you
need to keep in mind while coding your application into native programming model.
So next question you are going to ask is “in which programming model should I
program/code my applications?”
To answer this question I would suggest you to read the title of this module once
again; yes! You need to write your application in a way that it uses best out of both
the programming models. So let us get started…

How does one achieve Interoperability in Windows Mobile?

Now we do not want to write a code in traditional programming languages because of
the high complexity and debugging difficulties associated with it, than other option
you have is to use Third party tools that meets your application requirement, but
again cost factor associated with it increases overall app development cost and more
over it brings along with it hundreds of other issues like, amount of time you take to
get familiar with the tool, compatibility issues and etc., So we want a Programming
Platform/model that meets our requirement without any hidden aspects.

Interoperability support in .NET Compact Framework:

.NET Compact Framework version 1.0 did include some Interoperability support like
marshalling though it was very limited; but with the release of .NET Compact
Framework 2.0 there has been significant improvements with Interoperability issue.
We have included:
• Support for COM.
• Supports native calling into managed.
• Marshalling support for most of the types.
• Nested marshalling is also supported for strings, arrays within structures.
• You have MarshalAs attribute to define the marshalling conditions as per your
requirement.
• Provides logging of Interop calls.
Let us try to zoom in each of them by 1x:
Support for COM objects:-
.NET CF (.NET Compact Framework) provides support for COM objects in both ways.
• Exposing/Calling COM objects to .NET CF Components: You can call COM
objects into your managed application to do that you need to make a
reference to Type Library Importer (Tlbimp.exe) this library basically contains
definitions of COM types defined. It is also known as Interop assembly.
You need to perform following tasks to call COM objects from .NET CF:
1. Create managed references to all the COM interfaces and types.
2. Reference those definitions from your project.
3. Use your COM interfaces and types as managed types.
For memory management and house keeping work in managed code, it is
recommended that you use GCHandle structure to pin native objects.
• Exposing/Calling .NET CF Components to COM: You can call managed .NET CF
components into your native code and to do so you need to perform following
steps
1. Design your managed types while considering COM Programming.
2. Define the functionality you want to expose in a managed interface,
and have your managed objects implement this interface.
3. Create native definitions of your managed types.
4. Pass your managed object to native code as a COM interface. You can
then call managed functions implemented by your managed object
from native code by using the COM interface.
 To know more about the limitations and Design-Time attributes refer this
page.
• Accessing Pocket Outlook Object Model (POOM) through COM: Pocket Outlook
exposes lot of functionalities using COM interface that provides code based
access to Personal Information Manager (PIM) data on Windows Mobile
devices. POOM also exposes whole bunch of POOM APIs to manipulate and
access various PIM data. For e.g. I want to call a COM object that
automatically fills the rest of the Contact’s detail based on the Contact’s name
and mobile phone number in my MobileSalesman application, to do so I need
to perform following tasks:
1. Create a type library containing all in interfaces to Pocket Outlook.
2. Add a reference to that library from your Project.
3. Use an Application Class that points to Pocket Outlook and than call
method on it to use Pocket Outlook functionalities.
That’s it! You can take a deeper look at this topic on MSDN TV where Maarten Struys
had explained whole situation with demo.
Supports native calling into managed code:
Platform invoke is a service that enables managed code to call unmanaged functions
implemented in DLLs. You can use platform invoke semantically in the same way as
in the full .NET Framework, but the .NET Compact Framework has a few limitations in
marshaling objects and types between unmanaged and managed code.
There are three parts to a .NET Compact Framework platform invoke:
1. At design-time, the developer provides a description of the unmanaged
function to call. This includes the module name (DLL file), entry point name,
and calling convention.
2. At just-in-time (JIT) compile time, the common language runtime extracts
this information from the metadata, locates the DLL containing the function,
loads the DLL into memory and retrieves the address of the function. If the
module or function is not found, the common language runtime throw a
MissingMethodException.
3. At run time, the common language runtime marshals the parameters from
managed format to unmanaged format before the unmanaged function is
called. The common language runtime determines how to marshal each
parameter based upon the managed declaration of the method.
To know more about Platform Invoke wrapper refer this page and I would strongly
recommend that to get better understanding of calling unmanaged code into
managed code view this Webcast by Jim Wilson where he discusses his view on
Interoperability.
Support for Marshalling:
Interop marshaling is performed by the common language runtime. It controls how
data is passed in method arguments and return values between managed and
unmanaged memory.
.NET CF allows managed delegates to be marshaled as function pointer to
unmanaged code and enables most of the types to be marshaled in the .NET CF.
The .NET Compact Framework version 2.0 also supports the MarshalAsAttribute that
allows you to customize marshalling behavior for e.g.
1. Marshal arrays and strings in a structure.
2. Provides needed flexibility to support common COM Interop scenarios and etc.
You can find more information on MarshalAsAttribute usages here
Support for Interoperability log:
This capability is vastly used by .NET CF developers in their day to day routine. .NET
CF allows us to create log file to record following actions:
 1. Interoperating with native code: Interop log files are very handy in debugging
applications, they logs function signatures for both managed and native calls
with the error messages if any. It logs call details for
• Platform Invoke calls.
• COM Vtable and Dispatch calls.
• Delegate callbacks.
2. Loading Programs: Loader log files is consists of two parts
• Header: It contains Application’s Name, Process ID, Date and Time for
that Log file, .NET CF version, and Information about the platform on
which your app is running.
• Body: It consists of Coercion state, Tracing for each assembly load,
Trust level assigned to each module, Failures to find methods, types,
assemblies, native DLLs, Platform Invoke Call etc.
To get more information on Log files refer this page.

Interoperability support in Visual Studio 2005:

• With Visual Studio 2005 you have unified development architecture i.e. when
you write native application in eMbedded Visual C++, you will get .vcproj file
extension to your application and some time to call this native application
from managed code it is difficult because of these file extensions. But with
Visual Studio 2005, a single project file extension .sln can have both your
managed and native application extensions into it. One advantage you have
with this feature is that now you can debug your native DLLs from managed
code.
• Visual Studio 2005 Emulators supports ARM executables; so you need not
compile your applications separately for emulators and actual devices.

Switch back to normal mode from 1x; to understand all these issues in a greater deal
or if you have any queries on the same, come and join Vineet Gupta on this Friday
4:30 PM in 3rd Module Webcast of Windows Mobile Technology; where he shares his
views and thoughts on Native Interoperability in Windows Mobile 5.0 and get your
question answered by Vineet himself.

Webcast Schedule:

Date: November 3rd 2006.

Time: 4:30-6:00 P.M.
Register yourself at: www.microsoft.com/india/webcasts/mobility

Looking forward to see all of you on Friday…