Deploying PDW setup to Windows 10 64 bit

[jhewitt972]

I created an installer using the VB6 Package and Deployment Wizard and stared testing on both Windows 10 32bit and Windows 10 64bit. The apps seen to behave as expected. Development environment includes SP6. I'm a little concerned about the deployment of msvbvm60.dll. The setup program version is 6.0.98.48 but it is not getting copied to SysWOW64. The existing version, 6.0.98.15, does not get updated. When I look at ST6UNST.LOG I see this:

ACTION: SystemFile: "C:\Windows\System32\msvbvm60.dll"
(File was not found or was an older version -- new file copied)

The other files, e.g., MSCOMM32.OCX, get copied to SysWOW64 and registered.

This does not happen on Windows 10 32Bit, The updated msvbvm60.dll exists in windows\system32.

Anyone understand what's going on here?

[dilettante]

You should be excluding the VB6 core runtime files ("VB6 Runtime and OLE Automation") from your package. Long ago those files became protected system components of Windows and it will defend against attempts to replace them.

Do not mess around with msvbvm60.dll, which is serviced by Windows Update and not your legacy scripted setup package.

MSCOMM32.OCX is another story, and always requires deployment.

See Support Statement for Visual Basic 6.0 on Windows which provides more detail.


I suspect the reason you see different runtime file versions has a lot more to do with the two PCs being at different Windows 10 versions/patch levels than anything else.

[jhewitt972]

Yup, the 32 bit OS is at version 20H2 and the 64 bit OS is version at 1703.

So in the list below, all I should need is VB6STKIT.DLL...correct?

[Bootstrap Files]
File1=@VB6STKIT.DLL,$(WinSysPathSysFile),,,7/15/00 12:00:00 AM,101888,6.0.84.50
File2=@COMCAT.DLL,$(WinSysPathSysFile),$(DLLSelfRegister),,5/31/98 12:00:00 AM,22288,4.71.1460.1
File3=@STDOLE2.TLB,$(WinSysPathSysFile),$(TLBRegister),,6/3/99 12:00:00 AM,17920,2.40.4275.1
File4=@ASYCFILT.DLL,$(WinSysPathSysFile),,,3/8/99 12:00:00 AM,147728,2.40.4275.1
File5=@OLEPRO32.DLL,$(WinSysPathSysFile),$(DLLSelfRegister),,3/8/99 12:00:00 AM,164112,5.0.4275.1
File6=@OLEAUT32.DLL,$(WinSysPathSysFile),$(DLLSelfRegister),,4/12/00 12:00:00 AM,598288,2.40.4275.1
File7=@msvbvm60.dll,$(WinSysPathSysFile),$(DLLSelfRegister),,3/12/21 11:06:48 PM,1436032,6.0.98.48

Thanks

[Episcopal]

The setup program version is 6.0.98.48

I don't know this version, for me it would be version 6.0.98.15 it would be the last

[jhewitt972]

All, I posted 3 replies not realizing that they are moderated.. Hopefully the moderator will only include the first one.

[dilettante]

So in the list below, all I should need is VB6STKIT.DLL...correct?

That looks correct. You can manually edit the LST file or update it using the Wizard again.

[dilettante]

I don't know this version, for me it would be version 6.0.98.15 it would be the last

That's a little old now. Probably missing many monthly updates as well as the 20H2 version update for Windows 10.

I can't find a list of changes but I assume they are mainly security and stability bug fixes.

[dilettante]

See Description of the Windows File Protection feature:

WFP protects critical system files that are installed as part of Windows (for example, files with a .dll, .exe, .ocx, and .sys extension and some True Type fonts). WFP uses the file signatures and catalog files that are generated by code signing to verify if protected system files are the correct Microsoft versions. Replacement of protected system files is supported only through the following mechanisms:

• Windows Service Pack installation using Update.exe
• Hotfixes installed using Hotfix.exe or Update.exe
• Operating system upgrades using Winnt32.exe
• Windows Update

If a program uses a different method to replace protected files, WFP restores the original files. The Windows Installer adheres to WFP when installing critical system files and calls WFP with a request to install or replace the protected file instead of trying to install or replace a protected file itself.