Help please: Installing VB6 App on Windows 7

[SyncVB]

Hi all

As an amateur VB6 developer I have read a lot recently about compatability betwix Visual Basic 6 applications and Windows 7. I have learned a lot but I do not understand one element...

When using Package and Deployment or Inno or similar should we continue to include Windows XP DLL, OCX etc? And if so, where should these be programmed to be placed - {SYS} or {SYS}\sysWOW folder?

How do programmers, installer software or Windows 7 o/s know if it is sysWOW 32/64 ?

Thanks in advance for all help

[BenJones]

Well when I install any ocx for my program on WindowsXP i used to place them into the system folder, but on Vista I found a few problums installing to that folder, so on vista I install the ocx files into the program folder.

[akhileshbc]

Welcome to the forums...:wave:

Check this link too: Modifications Required for VB6 Applications to Work on Vista/7 (http://www.vbforums.com/showthread.php?t=456795&highlight=vista) :wave:

[baja_yu]

Well when I install any ocx for my program on WindowsXP i used to place them into the system folder, but on Vista I found a few problums installing to that folder, so on vista I install the ocx files into the program folder.

I don't think that's the best idea. What problems did you have?

SyncVB, Inno should have a function (I presume since it's scripted) that should 'detect' the path of the System folder, so use that, instead of hardcoding it into your script when copying and registering ocx files. Because, Windows could be on a partition with different drive letter than "C".

Personally, I use NSIS (made by Winamp guys), it's scripted and free, plus has great community support and forums. In it, for example, you can use:

SetOutPath "$SYSDIR"

Then copy the files without having to worry about where the folder is located.

[dilettante]

The PDW, InnoSetup, and it appears that NSIS are examples of deprecated legacy scripted installers. However they all work and may offer a few advantages over the mainstream Windows Installer technology supported as the primary installer technology on Windows for a long time.

They are supposed to continue operating on Vista and later Windows versions through legacy installer detection heuristics performed by Windows during process initiation. This generally works ok as long as the product being installed is simple and the installer process hasn't tried shenanigans to bypass the compatibility process.

For even a 32-bit Windows Installer package (MSI) on 64-bit Windows registry and filesystem redirection (separate from registry and filesystem virtualization) is performed. If the 32-bit package specifies "System32" files are redirected so they end up in "SysWOW64" instead, which is necessary. Trying to brute-force things by running InnoSetup with elevation manifests and explictly specifying SysWOW64 is where things can go wrong. Running regsvr32 by hand can lead to additional... fun.

If one insists on using such scripted setups it is probably wise to avoid trying to interfere with the Windows appcompat shims that apply to legacy installers.


There are very few "Windows XP" components that it ever made sense to try to deploy, let alone deploy to another OS. Attempted deployment of OS components is another common source of failure.

Installing shared components (like those supplied with VB6) next to your EXE is almost always a bad idea. We've discussed the risks of doing this many times. Any application-specific OCXs or DLLs you create don't present the same issues however.


Deployment is not a trivial topic. Network admins end up spending lots of time unraveling packages for proper repackaging - to permit things like push installs, advertised installs, install rollback and servicing, and other benefits of the Windows Installer infrastructure. A casual developer shouldn't need to worry about these issues, so the PDW generally works fine yet as long as your programs can run under compatibility mode.

However as the Windows ecosystem has changed the PDW's rules base has not. For best results you need to update these files of rules PDW operates by, and this means reading through nearly 12 years of Microsoft Knowlege Base articles on the use of the PDW in a changing world. Things you needed to deploy under Win9X or NT 4.0 sometimes cannot be successfully deployed on later versions of Windows. This is because they were absorbed into the set of OS files and are now part of Windows, and each versions of Windows may require a different version of such component libraries.

[SyncVB]

Thanks to all for their comments. They were most helpful. This comment jumped out at me:

If the 32-bit package specifies "System32" files are redirected so they end up in "SysWOW64" instead, which is necessary.


So, I will continue to include the standard MSCOMTRL, TABCTL32..etc with the {SYS} folder (as I would for XP) and let the o/s decide where to put them. Nice.

:wave:

[Hack]

Moved To Applications Deployment