Windows Mobile 5

Module 3: Windows Mobile 5.0: Native Code Interoperability. Applies To: • Microsoft • Microsoft • Microsoft • Microsoft

Windows Mobile 5.0 Development Platform. Windows Mobile 5.0 SDKs (Both Pocket PC and Smartphone) Visual Studio 2005 Professional/Developer/Team Suite Editions. .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…