32-bit applications have been around for a long time while 64-bit operating systems are only recently gaining popularity. Therefore, I would expect that the 64-bit OS successors would make it easy to run legacy 32-bit apps. And, they do as long as you compile them correctly.
I have been involved with the conversion of a motor drive configuration application from Visual J++ to C# .NET. This application still relies on many legacy 32-bit drivers and DLLs. When the converted application was installed Windows 7 x64 (64-bit), an error message similar to following message was issued:
“Error: Check to see if ActiveX control is Registered”
When the application is debugged, the following exception is being thrown and causing the crash:
“Class Not Registered (Exception of HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))”
Turns out that 32-bit drivers and DLLs are registered in a different area of Windows designated with “x86” (which stands for 32-bit) but my application was being run from the normal program area, which is a 64-bit area on x64 Windows. To get Windows to run the application from zone x86, it must be complied as a 32-bit application.
In Visual Studio, among the project properties on the Build tab, there is the “Platform target” setting with three options: Any CPU, x86, and x64. “Any CPU” sounds like the right choice because it is flexible- who doesn’t want a CPU independent program. This setting is fine if you install on a 32-bit OS. But, my application is not flexible and only plays well when targeting an x86 platform. The x64 setting would definitely be a mistake, declaring my program as pure 64-bit.
I found out about this setting through Experts Exchange and Xtreme .NET Talk. Here’s some official documentation from MSDN. Once the change is made, installation and execution on the 64-bit platform is seamless. Hope this helps. May all your compilations be well targeted.
Learn more about DMC’s software and web development services.