64-bit Insider

Volume I, Issue 12

The 64-bit Advantage

The computer industry is
changing, and 64-bit technology
is the next, inevitable step. The
64-bit Insider newsletter will help
you adopt this technology by
providing tips and tricks for a
successful port.
Development and migration of 64-
bit technology is not as
complicated as the 16-bit to 32-bit
transition. However, as with any
new technology, several areas do
require close examination and
consideration. The goal of the 64-
bit Insider newsletter is to identify
potential migration issues and
provide viable, effective solutions
to these issues. With a plethora of
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.
Under the Hood with COM
in WOW64
Upgrading an application to 64-bit might or might not
require a substantial amount of work. However, there is
one thing that your application will require: the ability to
use a version of all the libraries and third-party
components that the application references.
In this issue of the 64-bit Insider newsletter, we examine
the different techniques that allow Component Object
Model (COM) libraries to work seamlessly in Windows®
64-bit. This issue also discusses how and why it is
possible to have side-by-side 32-bit and 64-bit versions
of the same library without versioning problems.
The target audience for this newsletter is programmers
who develop applications that use COM libraries and run
on Microsoft® Windows Server™ 2003 or Microsoft
Windows XP Professional Edition operating system.
This newsletter contains information required to
understand how 32-bit COM libraries can run in 64-bit
Windows and the implications of doing so.

64-bit Insider Newsletter

Volume 1, Issue 12
Page 1/6
The Theory behind COM in WOW64
COM technology, introduced in 1993, enables
communication between applications and
libraries both in-process and out-of-process.
COM supports dynamic object creation in any
programming language that supports the
technology. In addition, COM is often used in
the software development world as an umbrella
term that encompasses Object Linking and
Embedding (OLE), COM+, Distributed Component Object Modeling (DCOM), and
Microsoft ActiveX® technologies.

With the introduction of the Windows 64-bit operating system, some changes are
expected in regard to COM. For example, a ported library can run natively and be used
from any 64-bit application. However, with a 32-bit COM library, the operating system
must follow a set of rules to avoid mixing 32-bit and 64-bit code in the same process
space. Cross-platform dependencies are not permitted when using in-process
communication. There are many technical reasons for this situation, the most important
being:

 “Thunking.” 64-bit code would have trouble “ ...cross platform

communicating with 32-bit code because of dependencies are not
addressing limitations. Even with smaller data permitted when using in-
structures, the Win32 execution model presents process communication.”
many barriers to reliable thunking for several
reasons: Object lifetimes are often not clearly
defined, objects are passed from thread to thread or
referenced asynchronously, or objects are highly
polymorphic.

 Page Size and Exception Handling. There are a series of differences between
32-bit and 64-bit code exception handling. Also, a 32-bit Dynamic Link Library
(DLL) expects 4 KB pages and x86-style exception handling. On Itanium
Processor Family (IPF), the native page size is 8K, and WOW64 simulates 4 K
pages with assistance from the kernel memory manager and the processor.

 DLL Problems. System DLLs, such as Kernel32.dll, User32.dll, and Gdi32.dll,

expect only one instance per process, either 32-bit or 64-bit. Therefore, the only
way to achieve in-process invocation is to make sure that the calling application
and the library being loaded match the target platform architecture for which they
were built.

But what about 32-bit COM libraries in Windows 64-bit, can they still be used?

64-bit Insider Newsletter

Volume 1, Issue 12
Page 2/6
Understanding Registry Redirection
Figure 1 demonstrates how registration works in
Windows 64-bit. In this case, there is a library,
called COMDemoProject.dll, that has both a 32-
bit and a 64-bit version registered. If you open the
OleView utility, you will find that the information
for both libraries is stored in the registry.

Figure 1 Two versions of COMDemoProject.dll

How is this possible?

Any person with COM experience knows that problems occasionally occur when a newer
version of a COM library that has been installed on a computer overwrites an older,
incompatible version (this happens enough that the
“ Registry redirection is the problem has become known as “DLL hell”). The problem
secret behind making it arises when the newer version has the same global unique
possible to have both a 32- identifier GUID and name as the previous one and, as a
bit and a 64-bit version of consequence, (in some cases) the application might try to
the same library registered load the wrong version of the library— with unpredictable
with COM.” results. You can register two libraries with the same
GUID and name, but the two target different platform
architectures— a situation that causes much confusion.

Registry redirection is the secret behind making it possible to have both a 32-bit and a
64-bit version of the same library registered with COM. Registry redirection is a feature
of WOW64 and makes sure that applications running under WOW64 always see the 32-
bit version of HKEY_LOCAL_MACHINE\Software that is stored under the
Wow6432node. Figure 2 demonstrates how the registry is structured to
separate information between 32-bit and 64-bit applications.

64-bit Insider Newsletter

Volume 1, Issue 12
Page 3/6
 Figure 2 Registry redirection

The registry redirector also helps locate the correct application and sets up inter-process
communications with an out-of-process library when a 32-bit application makes a COM
call to invoke a 64-bit library, or vice versa. However, it is not as simple as just dividing
32-bit and 64-bit COM calls and redirecting during registration/activation. There are a
series of rules that help prevent compatibility issues and enforce the already well-known
limitations regarding 32-bit and 64-bit code interoperation. These rules (listed below)
affect the HKEY_CLASSES_ROOT\CLSID branch of the registry, which is where COM
class identifiers and their handler DLLs are registered.

 The values for InProcServer32 and InProcHandler32 are not reflected. This
rule helps prevent attempts to load a DLL of a different architecture into an
incompatible process type. For example, the rule prevents loading 32-bit DLLs
into a 64-bit process, and vice versa. These are the in-process libraries that we
observed previously with COMDemoProject.dll.

 LocalServer32 is reflected. This value indicates which out-of-process COM

executable should be instantiated when a particular class is invoked. Because out-
of-process is compatible with both architectures, there is no need to apply special
rules to this value.

Note: The WOW64 registry reflector might change keys and values during the
reflection process to ensure they are correct. Therefore, 32-bit and 64-bit contents
can differ.

By using these rules, COM registry entries can be shared between 32-bit and 64-bit
applications without incurring the problems that result when attempts are made to mix
code that targets different platform architecture within the same process space.

64-bit Insider Newsletter

Volume 1, Issue 12
Page 4/6
Migrating an Application that Uses a COM Library
If you are migrating an application that uses a COM library, you should answer the
following questions and take the appropriate actions.

1. Is there a 64-bit version of the COM library available?

o If yes, then the library can be used in-process, and you only need to re-
reference the new library and verify that no changes took place on the
interface.

o If no, continue to the next question.

2. Is the COM library from a third party?

o If yes, check with your independent software vendor (ISV) to see if it can
provide a 64-bit version of the library.

o If no, continue to the next question.

3. Was the COM library developed in-house and can you perform an immediate
migration to 64-bit? For example, enough time, money, and resources.

If you answered yes to any of these questions then, you will be able to continue using
your COM library in-process right away or as soon as it has been ported to 64-bit.

However, if you can ’t use your library in-process, there are several ways that you can use
it out-of-process. For example:

 Move your in-process dll to an out-of-process executable.

 Use COM+ as a host by installing your dll as a server library.

 Use dllhost.exe as a surrogate host.

 Create an out-of-process COM wrapper for your Win32 library.

Providing more information about these techniques falls outside the immediate scope of
this newsletter, but you can learn more at: www.64advantage.com

Summary
There are many commercial and scientific applications that use COM, and it would be
unacceptable to introduce a new platform that required one to discard all existing
applications.

64-bit Insider Newsletter

Volume 1, Issue 12
Page 5/6
While Windows 64-bit allows both 32-bit and 64-bit COM libraries to coexist, the
process is not straightforward. The operating system must follow a set of rules
established by the registry redirector and file system redirection. It is also possible to
interoperate between 32 and 64-bit libraries/applications by moving your in-process
dependencies to out-of-process.

64-bit Insider Newsletter

Volume 1, Issue 12
Page 6/6