If the component itself is 16-bit, then using a virtual machine running a 32-bit version of Windows is your only real choice. What would be the best way to get round this problem?
It's hard to imagine anyone out there in the wild that is still using 16-bit applications and seeking to upgrade to 64-bit OSes. The transition to 64-bit seemed like as good a time as any. Support for 16-bit had to be dropped eventually, even in a culture where backwards-compatibility is of sacred import. The 64-bit versions already have to provide a compatibility layer for 32-bit applications. You can't run 16-bit applications (or components) on 64-bit versions of Windows. You can also repackage this modified installation, so it can be distributed as an installation program, using a free program like Inno Setup 5. Then I just ran the new 32-bit setup.exe in disk1 to start the installation and my program installed and runs perfectly on 64-bit Windows. I then replaced the original 16-bit setup.exe, located in the disk1 folder, with InstallShield's 32-bit version of setup.exe (download this file from the site referenced in the above link). First I extracted the installation program contents (changed the extension from. The issue was that the setup.exe program used by InstallShield 5.X is 16-bit. In my case, the installation program was InstallShield 5.X.
There are ways to modify a 16-bit installation program to make it 32-bit so it will install on 64-bit Windows 7. If the program itself is 32-bit, and just the installer is 16-bit, here's your answer. You don't need to install a virtual environment running a 32-bit version of Windows to run a program with a 16-bit installer on 64-bit Windows. It took me months of googling to find a solution for this issue.