upgrading protected vb6 dlls

I have an installation package that is attempting to upgrade the following DLLs:
Oleaut32.dll
stdole2.tlb
msvcrt.dll

Upon installation on a machine with older libraries, the reboot prompt occurrs (correctly). However the libraries are not upgraded upon reboot.

The first two are part of the vb6 runtime libraries. The last is required for installation of the microsoft scripting runtime libraries (scrrun.dll).

I searched for and read a post by a user having the exact same problem:

where the conclusion by Joost Verburg was that the library in question (msvcrt.dll) is a protected library.

I am wondering if this is still thought to be the case or if there is a workaround that has been found (the original post is a couple of years old). I would not think the vb runtime libraries are protected. Can I verify what dlls are protected somewhere in the registry?

I am using NSIS v2.0. Here is a small snippet of code from the script:
*************
!insertmacro UpgradeDLL ${VBFILESDIR}\Oleaut32.dll $SYSDIR\Oleaut32.dll $SYSDIR

!define UPGRADEDLL_NOREGISTER
!insertmacro UpgradeDLL ${VBFILESDIR}\Stdole2.tlb $SYSDIR\Stdole2.tlb $SYSDIR
!insertmacro UpgradeDLL ${VBFILESDIR}\msvcrt.dll $SYSDIR\msvcrt.dll $SYSDIR ;required if installing scrrun
!undef UPGRADEDLL_NOREGISTER
**************

Does anyone know how to upgrade these files or what might be happening? Is it possible another app/service is grabbing the dlls before the RunOnce registry key is fired (this occurrs after a logon)? As you can tell from the code, only one file is registered but all three are set to be renamed and copied from temporary files on reboot.

Thanks for the help.
Sorry for the long post.

Paul

These OLE files are indeed protected by modern Windows versions. You can't update them, but there is also no need to update, they are linked the the operating system. Your application works fine with these files.

If you want to prevent the installer from trying to update, check the windows version during installation using the GetWindowsVersion function (ME/2000/XP have this protection).

Thanks! Yes the application works fine even though the upgrade does not occur.

Just a quick note though... the code for installation of the VB6 runtime files came from the following section in the NSIS documentation:
C.4 How to install the VB6 runtimes

It should probably be updated to reflect the need to only install if the files do not exist (since upgrade is not allowed).

Thanks again for the quick response!

Paul

Note that you still have to upgrade all files when running Windows 95/98/NT4.

Thanks again... I realized that after hitting send on the last post.

One other quick question. Is there a way to determine which files are protected on the system? Is there a list in the registry somewhere?

It would be nice to know for future reference since I am sure I will attempt this in the future with a different protected file.

Thanks,
Paul

There is a hidden folder called dllcache in your system folder which contains the files.

Interestingly, I checked this cache and only found two of the three files I mentioned previously. I could not find msvcrt.dll.

In searching on the net I seemed to find that the files that are protected do not necessarily exist in this directory. If they do not exist here and they are protected, the user will be prompted to insert the windows installation disk to restore the protected file.

I will keep looking for how to determine which files are protected, but as of yet I have not found a way to determine this for sure.

Thanks for the help.
Paul

You can always try to remove the file on reboot. If it doesn't work the file is protected.

Unfortunately that will cause the same problem as simply attempting to upgrade the dll that is protected. I would like to avoid forcing the user to reboot when it is unecessary. In addition to being forced to reboot, the user may be required to insert their windows install disk to replace the changed dll with the protected version.

I attached code I wrote to wrap around UpgradeDLL.

Any comments would be appreciated (I'm still new to writing NSIS scripts). It works well for what I would like to do, you just need to know which files might be protected prior to calling it.

That script doesn't work at all, remember that defines are processed on compile-time.

...

I guess it appeared to work since I haven't tested it on a non Windows File Protection enabled system. Thanks for the response. I will change the code.

Paul

corrected script

here is a second attempt at that script. This should work as it uses variables instead of defines.

Thanks again for the help.

Paul

(I changed the script slightly so that it is no longer necessary to call CheckSFC prior to including the macro.)

That looks better. Why define 3 unique values? One is enough.

good point 🙂

I have changed the script to reflect this.

Thanks so much for your help.

(I added a comment regarding when to use this file for anyone who happens to download it.)