64-bit Insider

Volume I, Issue 7

The 64-bit Advantage Dealing with Legacy 32-bit

The computer industry is
changing, and 64-bit technology
Components in 64-bit
is the next, inevitable step. The
64-bit Insider newsletter will help Windows
you adopt this technology by
providing tips and tricks for a Millions of 32-bit applications, worldwide, use
successful port. Component Object Model (COM) technologies. As these
Development and migration of 64-
applications evolve to Microsoft® Windows® 64-bit, they
bit technology is not as require 64-bit versions of their COM libraries.
complicated as the 16-bit to 32-bit
transition. However, as with any This issue of the 64-bit Insider newsletter examines
new technology, several areas do several ways you can support 32-bit COM libraries in
require close examination and 64-bit applications. Specifically, this newsletter presents
consideration. The goal of the 64-
bit Insider newsletter is to identify
several solutions you can use to host in-process libraries
potential migration issues and in an out-of-process fashion. By doing so, you will be
provide viable, effective solutions able to interoperate between 64-bit applications and 32-
to these issues. With a plethora of bit libraries or vice versa.
Web sites already focused on 64-
bit technology, the intention of
this newsletter is not to repeat
previously published information.
Instead, it will focus on 64-bit
issues that are somewhat isolated
yet extremely important to
understand. It will also connect
you to reports and findings from
64-bit experts.

64-bit Insider Newsletter

Volume 1, Issue 7
Page 1/8
Techniques for Interoperating with
COM Libraries Across 32-bit and
64-bit Boundaries
A vast number of applications depend on COM
technologies. Some of these COM components
run within the same process space as their calling
application (referred to as in-process), while
others run in a separate process space (known as
out-of-process).

Any COM component that is currently being used out-of-process should not present a
problem when you are migrating to 64-bit Windows, because Remote Procedure Calls
(RPCs) can cross 32-bit and 64-bit boundaries without any problems.

In contrast, any application that you have ported to 64-bit and that needs to load a
COM component in-process must implement one of these solutions to continue
using the COM component:

1. Obtain a native 64-bit version of the component.

2. Migrate the component to 64-bit.
3. Move the component from in-process to out-of-process.

From a technology perspective, option one or two would be

the preferred choices; however, they might not be the most
“Any COM component
cost-effective solutions. Thus, moving a component from
that is currently being
in-process to out-of-process might be the only realistic way
used out-of-process
to reference a 32-bit component. This solution has many
should not present a
advantages, in addition to several drawbacks. The main
problem when you are
benefit revolves around how soon the 32-bit COM
migrating to 64-bit
component can be used from a 64-bit application. The main
Windows, because
drawback is that the out-of-process communication can be
Remote Procedure Calls
slowed because of having to pass the information across
(RPCs) can cross 32-bit
process boundaries. Therefore, the performance
and 64-bit boundaries
degradation that occurs will vary depending on how the
without any problems.”
library is being used.

The remaining portion of this newsletter explores several

approaches that can be used to move COM components out-of-process. You can choose
the one that works best for your situation.

• Converting a project type from in-process to out-of-process

• Using COM+ as a host
• Using dllhost as a surrogate host

64-bit Insider Newsletter

Volume 1, Issue 7
Page 2/8
 • Adding an out-of-process COM wrapper to a DLL

Converting a Project Type from In-Process to Out-of-Process

This option can work if you meet the following
requirements:
• You have a 32-bit in-process library
that you want to use in your 64-bit
application.
• You have the associated source code.
• You don’t have the time to perform a
migration to 64-bit.

To convert your project from in-process to out-of-process, we’ll also make the following
assumptions:
1. The library currently compiles with Microsoft Visual Studio® 2005.
2. The project is of type ATL (Active Template Library code).

To convert your project, follow these steps:

1. Create a new project of the same type. You can use the same name, or you can
add a qualifier to distinguish the new library. For example, myLibrary could
become myLibraryOutOfProc.
2. Change the server type from Dynamic-link library (DLL) to Executable (EXE) on
the project settings screen (see Figure 1). In doing so, you will create a project
that is the same type as your previous one, but is an out-of-process library.

Figure 1 Project settings screen

3. Move all of the functionality from the in-process library to your new
project. This step involves moving all the source code and header files
contained in your project.
Note While this is not a hard step, it might be tedious, depending on the
size of your project.

64-bit Insider Newsletter

Volume 1, Issue 7
Page 3/8
 4. Recompile to create an out-of-process component from your in-process
library.

An advantage of this approach is that it is not necessary to perform any changes on the
64-bit client code, only on the 32-bit server project.

Using COM+ as a Host

COM+ is an architecture and system of COM-based
services and technologies that automatically handles
“COM+ is an
difficult programming tasks such as resource pooling,
architecture and system of
disconnected applications, event publication and
COM-based services and
subscription, and distributed transactions.
technologies that
automatically handles
As an added bonus, COM+ is architecture agnostic in
difficult programming
Windows 64-bit. Therefore, 32-bit and
tasks such as resource
64-bit binaries can be mixed freely when registered as
pooling, disconnected
server applications. This feature is really useful in
applications, event
Windows 64-bit to interoperate between different target
publication and
platform libraries and applications.
subscription, and
distributed transactions.”
To use 32-bit COM components in binary form from a 64-
bit application, use COM+ as a proxy mechanism. Register
the component with the COM+ framework and encase it in
a Server Application that, in turn, your 64-bit application will reference. Therefore, you
can invoke 32-bit COM components through COM+ from your 64-bit applications,
without rebuilding all the dependencies.
When you register a COM component in COM+, it can be either an in-process library or
an out-of-process server application. The key is to select the type of application as a
Server application, as shown in Figure 2. By doing so, the object will run out-of-process
automatically, any time that it can be instantiated.

Figure 2 Select the Server application option.

One significant benefit of using this approach is that there is no need to change the source
code of either the client or the COM component.
64-bit Insider Newsletter
Volume 1, Issue 7
Page 4/8
Using dllhost as a Surrogate Host
Another way to call a COM library across a 32/64-bit boundary is to use dllhost.exe, (part
of the Windows operating system) as a surrogate host. When you use dllhost, it runs as a
separate process and provides all the mechanisms for the server to run as a local server.
Dllhost works as a wrapper that relays calls between the 32-bit client and the 64-bit DLL.
Windows handles both the activation and the termination of the surrogate process as
needed. Also, the overhead associated with COM+ can be avoided.
COM automatically handles marshaling, and the client code gets a proxy and a stub
instead of directly addressing the DLL as it normally would have. The downside to this
approach is that the client code needs to be changed and, when you look in Task
Manager, all you can see is dllhost.exe. If another object is being hosted by dllhost.exe,
you don’t have a quick and practical way of determining which process contains your
object (unless you download a third-party utility, such as Process Explorer by
SystemInternals).

Hosting a COM library in dllhost is not a very complicated procedure. You only need to
complete some changes in the registry on the activation information to specify that the
COM library will run as a surrogate and change the way the client loads the COM object.

1. Change the AppId value of the library’s Global Unique Identifier (GUID)
contained in the HKEY_CLASSES_ROOT\CLSID\{YOUR-CLSID} node, so
that the AppId contains its own GUID as the corresponding value. In this
example, we have a COM object with a name of CConversion (See Figure 3).

Figure 3 Change the AppID value of the COM library.

2. On the HKEY_CLASSES_ROOT\AppID node, set the default value of the key to

the class name of the object you will be hosting in dllhost, (in this example,
CConversion Object), and then add a DllSurrogate entry with an empty string for
the value. The type should be REG_SZ (See Figure 4).

64-bit Insider Newsletter

Volume 1, Issue 7
Page 5/8
 Figure 4 Add a DLLSurrogate entry with an empty string for the value.

These are the only two changes that you must make for the COM library. The binary
stays the same. As far as the changes required in the client application, we only need to
change the activation information. To create an in-process (commonly called “in-proc”)
COM instance from C++, it is necessary to call the CoCreateInstance function with only
one parameter, the GUID of the class to be instanced. However, to create an out-of-
process (or “out-of proc”), it is necessary to pass as a parameter
CLSCTX_LOCAL_SERVER.

The following code shows an example of in-proc COM instance.

HRESULT hr = spUnknown.CoCreateInstance(__uuidof(CConversion));

The following code shows how you could create an out-of-proc COM instance.
HRESULT hr = spUnknown.CoCreateInstance(__uuidof(CConversion), NULL, LSCTX_LOCAL_SERVER);

By performing these simple changes, the COM library will run as a surrogate, and the
application will be able to access the functionality with just one minor change and a
recompile.

Adding an Out-of-Process COM Wrapper to a DLL

If a 32-bit DLL is loaded into a 64-bit application, an exception will occur. Therefore, if
you need to use a 32-bit library from a 64-bit process, you must find a way to host this
library out-of-process. For example, suppose you have calculator application that is made
up of the following three components:

• The graphical user interface (GUI),

• A complex math library that performs advanced mathematical calculations, and
• A basic math library that is in charge of the operations: add, subtract, multiply and
divide.

In this example, we’ll also assume that we cannot migrate the basic math library, but can
migrate the rest of the application. Consequently, we have to find a way to use a Win32
library out-of-process. A good way to solve this challenge is to build an out-of-process
COM wrapper (See Figure 5).

64-bit Insider Newsletter

Volume 1, Issue 7
Page 6/8
 Figure 5 Build an out-of-process COM wrapper.

This way, the 64-bit application will be able to call the 32-bit COM wrapper that is
running in a separate process space. The COM wrapper will then forward these calls to
the 32-bit DLL and return the results of these calls to the 64-bit process.

Wrapping the DLL in an out-of-proc COM Component will involve changing the
references in the 64-bit client application and modifying it so that it calls the new COM
wrapper. There will be no changes to the 32-bit DLL.

The required steps (high-level) are outlined here:

1. Create a COM wrapper class and implement the necessary methods to mirror the
calls published by the DLL. This step reduces the amount of work necessary on
the client side to transition from Win32 into COM invocation.
2. Change the client application to invoke the COM wrapper instead of the DLL
directly. This change can be achieved by substituting the Win32 class declaration
with the COM declaration, but having both classes expose the same interface.
Because they both expose the same interface, the client code could be left as-is for
the most part, and the changes can be limited to class declaration and
instantiation.
By completing these steps, it is possible to create a wrapper that will serve as a bridge
between a 64-bit application and a 32-bit Win32 library. Following this same basic
roadmap, you can migrate other real-world applications to 64-bit in an incremental
fashion. Creating a bridge wrapper can help reduce the cost and risk of adopting
Windows 64-bit, while allowing you to maintain functional equivalence and reliance on
proven code.

Summary
During the process of upgrading an application to Windows 64-bit, there’s a possibility
that not all references might be available natively. On a first impression, this might look
like a showstopper; however, there is a way to continue using your references by moving
them out-of-process.

64-bit Insider Newsletter

Volume 1, Issue 7
Page 7/8
Some of these techniques require modifying the client code, others require changing the
library code, while others require modifying both. Or, you can even achieve RPCs
without changing the library or the application.

Any methodology that you decide to use will allow you to interoperate and continue
using your 32-bit libraries from 64-bit applications.

Additional Reading
Overview of Compatibility Considerations for 32-bit and 64-bit
http://support.microsoft.com/kb/896456/en-us

Bridge the Gap Between 32- and 64-bit Applications

http://www.devx.com/amd/Article/31090

Designing 64-bit-Compatible Interfaces

http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/win64/win64/designing_64_bit_compatible_interfaces.asp

64-bit Insider Newsletter

Volume 1, Issue 7
Page 8/8