64-bitInsider
Volume I, Issue 7
Dealing with Legacy 32-bitComponents in 64-bitWindows
64-bit Insider NewsletterVolume 1, Issue 7Page 1/8
The 64-bit Advantage
The computer industry ischanging, and 64-bit technologyis the next, inevitable step. The
64-bit Insider
newsletter will help you adopt this technology by providing tips and tricks for asuccessful port.
Development and migration of 64-bit technology is not ascomplicated as the 16-bit to 32-bittransition. However, as with anynew technology, several areas dorequire close examination andconsideration. The goal of the
64-bit Insider
newsletter
is to identifypotential migration issues andprovide viable, effective solutionsto these issues. With a plethora of Web sites already focused on 64-bit technology, the intention of this newsletter is not to repeatpreviously published information.Instead, it will focus on 64-bitissues that are somewhat isolatedyet extremely important tounderstand. It will also connectyou to reports and findings from64-bit experts.
Millions of 32-bit applications, worldwide, useComponent Object Model (COM) technologies. As theseapplications evolve to Microsoft
®
Windows
®
64-bit, theyrequire 64-bit versions of their COM libraries.This issue of the
64-bit Insider
newsletter examinesseveral ways you can support 32-bit COM libraries in64-bit applications. Specifically, this newsletter presentsseveral solutions you can use to host in-process librariesin an out-of-process fashion. By doing so, you will beable to interoperate between 64-bit applications and 32-bit libraries or vice versa.
Techniques for Interoperating with COM Libraries Across 32-bit and 64-bit Boundaries
A vast number of applications depend on COMtechnologies. Some of these COM componentsrun within the same process space as their callingapplication (referred to as in-process), whileothers run in a separate process space (known asout-of-process).Any COM component that is currently being used out-of-process should not present aproblem 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 aCOM component in-process must implement one of these solutions to continueusing 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 bethe preferred choices; however, they might not be the mostcost-effective solutions. Thus, moving a component fromin-process to out-of-process might be the only realistic wayto reference a 32-bit component. This solution has manyadvantages, in addition to several drawbacks. The mainbenefit revolves around how soon the 32-bit COMcomponent can be used from a 64-bit application. The maindrawback is that the out-of-process communication can beslowed because of having to pass the information acrossprocess boundaries. Therefore, the performancedegradation that occurs will vary depending on how thelibrary is being used.
“Any COM component that is currently beingused out-of-processshould not present a problem when you aremigrating to 64-bit Windows, because Remote Procedure Calls(RPCs) can cross 32-bit and 64-bit boundarieswithout any problems.”
The remaining portion of this newsletter explores severalapproaches that can be used to move COM components out-of-process. You can choosethe 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 NewsletterVolume 1, Issue 7Page 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 followingrequirements:
•
You have a 32-bit in-process librarythat you want to use in your 64-bitapplication.
•
You have the associated source code.
•
You don’t have the time to perform amigration to 64-bit.To convert your project from in-process to out-of-process, we’ll also make the followingassumptions: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 canadd a qualifier to distinguish the new library. For example, myLibrary couldbecome myLibraryOutOfProc.2.
Change the server type from Dynamic-link library (DLL) to Executable (EXE) onthe project settings screen (see Figure 1). In doing so, you will create a projectthat 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 newproject. This step involves moving all the source code and header filescontained in your project.
Note
While this is not a hard step, it might be tedious, depending on thesize of your project.
64-bit Insider NewsletterVolume 1, Issue 7Page 3/8
Search History:
Result 00 of 00
00 results for result for
p.
Recommended
More From This User
Notes
Load more
