I have a VB6 program that runs fine on Windows 7 64-bit (with some manual registering of three OCX files). It also seems to run fine on 32-bit Windows 8.
However, when I try to run it on 64-bit Windows 8, when I try to bring up a data window, it says that MSADODC.OCX or one of its dependencies is not registered. This happens even if I manually register that file.
When I try to access other areas of the program, it also gives me different OCX file errors.
Is there a procedure to ensure that all relevant OCX files get properly registered when installing a VB6 program under Windows 8 64-bit?
Ideally you'd create a Windows Installer package (.MSI) to install your application. Even then when building this package you'd use the provided merge modules rather than trying to deploy live copies of OCXs from your development system, which has never been consdered proper.
However you might still have poblems with controls built on top of ADO, like the ADO Data Control. These may fall afoul of Microsoft's misguided attempts to provide support for 64-bit VBA in Office suite applications, starting in Win7 SP1. The fallout from this nuclear disaster is still driffting down to cause no end of grief.
In theory there was some "ultimate fix" pushed out in Windows 8. But enough people have been spared the need to address Windows 8 so far that I'm not aware of where things stand.
The ADODC issue you're seeing might be either unrelated or totally unrepairable! Hard to say without more detailed information.
However you should be aware that on 64-bit Windows these OCXs do not go into System32 and they are not registerable using the 64-bit version of regsvr32, which is the default one you'll run if you just open a command prompt.
Manual self-registration (which is what running regsvr32 is) requries a couple of steps.
First you need to be running an elevated command prompt, and second you need to run the 32-bit regsvr32.exe which you'll find in C:\Windows\SysWOW64 (which is also where your OCX goes).
Once again, a proper installer package takes care of this for you. Installer detects a 32-bit package and invokes the necessary filesystem and registry redirection to make things work transparently. The standard tool for creating Installer packages is Visual Studio 6.0 Installer 1.1, which was a free Microsoft download until two years ago or so. You might also use a 3rd party package authoring tool, or even a later version of Visual Studio which ought to have an Installer project type.
Even the older PDW that shipped with VB6/VS6 should work via "legacy scripted installer heuristics" if you don't rename setup.exe to somthing else.
Copying files and manually registring things at random has never been an approved deployment technique.
I have been using the elevated prompt and the SysWOW64 folder in 64-bit Windows Vista and 7 installations.
Unfortunately, I don't have the wherewithal to create a new msi file. (Is there an easy, low-cost way to do this? I used Installshield Express to create the initial installation package back in 2007 or so when we last updated the program.)
In Windows Vista and 7, the manual registration has worked. In fact, in Windows 8 it SAYS that the files are being registered successfully, but they still come up as not registered when they are accessed by the VB6 app.
The OCX needs to go into SysWOW64 and you must run the regsvr32 found in SysWOW64.
Hard to imagine you can't create an MSI package since the tool required was a free add-on for VB6, but the downloads are no longer available. Surely you can create a PDW setup package?
However if the process you follow is working for Win7 64-bit then it should also work for Win8/64. This suggests your problem might be that the MSADODC.OCX is looking for and not finding the standard ADO class registration entries, possibly as a result of those breaking changes Microsoft began to fumble with Win7 SP1.
If that's the case there isn't any fix. But you say your program works fine in Win8 32-bit, which takes us back to the more likely possibility that your installation procedure is flawed.