Bridge the Gap Between 32- and 64-bit Applications

 

From：http://developer.amd.com/documentation/articles/pages/3312006110.aspx What happens when you can't port an application all at once to 64-bits? This article discusses the ramifications of mixed-mode applications and how to deal with the issues that arise.

Allan McNaughton  3/31/2006

While AMD's 64-bit processors run 32-bit applications at impressive speeds, they deliver exemplary performance on 64-bit code. Developers should consider migrating to 64-bits post haste. The performance improvement is well worth the small amount of porting effort involved. But what happens when you can't port an application all at once to 64-bits? In this article we'll discuss the ramifications of mixed-mode applications and how to deal with the issues that arise. Scale Up While the AMD64 versions of Microsoft Windows and Linux support 32- and 64-bit applications equally well, they do require a process to consist entirely of either 32- or 64-bit code, not both. The reason is that 64-bit code uses different calling conventions and a more expansive registers set than 32-bit code. Pointers are also 64-bits. These changes to the programming model allow 64-bit code to run faster and access more memory than 32-bit applications. Although the differences between 32- and 64-bit codes would seem to make an incremental port unlikely, applications that utilize multiple processes have the option of being ported one process at a time. Let's take the case of a multi-process application where one of the processes is reliant on a 32-bit only third-party library. We could keep the process that uses the library in 32-bit mode and port the rest of the application to 64-bits. The question arises: What interoperability problems crop up when 32- and 64-bit processes communicate with one another? Fortunately, AMD and the operating system vendors have dealt with the vast majority of interoperability issues. The 64-bit version of Microsoft Windows, for instance, does a fine job of smoothing differences between 32- and 64-bit processes. WOW Me! Windows 64 is a native 64-bit operating system (all services run in 64-bit mode). When a 64-bit application makes an OS call, it does so using the 64-bit calling convention. 32-bit applications continue to make OS calls using the 32-bit calling convention (just as they would on 32-bit Windows). The crucial difference is that 32-bit OS calls are routed through an emulation layer called WOW64 (Windows-32-on-Windows-64). WOW64's primary purpose is to create a 32-bit environment that provides the interfaces required to allow 32-bit Windows apps to run unmodified in a 64-bit world. When it comes to interprocess communication, it is possible for 64-bit applications to launch 32-bit processes, and vice-versa, and to share handles to named objects (such as semaphores and file handles) and to individual windows. Fortunately, 64-bit Windows takes care of the work of finding and launching processes, if you use the CreateProcess or ShellExecute functions. You can also use COM localservers or remote procedure calls to invoke 64-bit processes or applications from 32-bit apps, and vice-versa. WOW64 does such a fine job that all the common mechanisms that Windows processes use communicate with one another (including shared memory, pipes, out-of-proc COM servers, send message, and event signaling) are highly interoperable. Lost in Translation Although it may seem that 32- and 64-applications interoperate without a hitch, there are pitfalls to avoid. Processes that interoperate typically do so to share data. Let's say you have a 64-bit language translation application (i.e. English to Spanish) that communicates with its callees through a shared memory buffer. Within the shared memory buffer is a structure that the calling application populates with the text that needs translation, the desired language, and pointers to key parts of the translation buffer. When the translation is complete the calling application reads the translated text back from the buffer. The C-language structure is defined as follows: #define MAXSIZE 4096 struct language_translation { int source_language; int target_language; char *source_header, *source_body, *source_end; char *target_header, *target_body, *target_end; char source_buffer[MAXSIZE]; char target_buffer[MAXSIZE]; }; All is well if you're sharing data types that do not exceed 32-bits in size when compiled in 64-bit mode (such as the C-types int, long, char, DWORD). The problem with our structure is that it uses pointers. When compiled in 32-bit mode this structure occupies 8224 bytes of memory. The same structure in 64-bit mode occupies 8248 bytes. Why the difference? The problem is that pointers take up 8 bytes a piece in 64-bit mode (32-bit mode pointers are 4 bytes each). The difference in pointer sizes also changes the offsets of variables in the structure. In 32-mode the pointer source_body is located 12 bytes from the beginning of the structure. In 64-bit mode it's 16 bytes from the beginning. This sizing mismatch is representative of many 32/64-bit interoperability issues. There are a number of solutions to this problem. The best solution is to not mix pointers and shared memory (use an offset from a base instead). Another approach is to define two different structures, a 32-bit mode structure with padding to mimic the offsets of the 64-bit structure (include a dummy int before each pointer), and a structure without the padding for 64-bit mode. This solution would alleviate some, but not all, interoperability concerns. Imagine what would happen if the 64-bit process updated target_body with a pointer value that was not non-zero in the upper 32-bits. The calling application would crash upon reading the translated text out of the buffer. Point to the Future It is quite likely that 32- and 64-bit Windows applications can interoperate without any code changes. WOW64 ensures that Windows rich array of features (including interprocess communication) seamlessly bridge the gap between the 32- and 64-bit worlds. Developers only need be aware of the difference in the way pointers and addressing are dealt with in 32- and 64-bit modes. Allan McNaughton, a veteran developer and long-time writer, is the principal at Technical Insight LLC, a firm specializing in the composition of high-technology white papers.