charhook.dll cannot be overwritten during reinstallation process

[vtsaran]

During reinstallation of NVDA, i.e. when overwriting existing installation, the installer is unable to update charhook.dll because it is write-protected, thus causing "abort/ignore/retry" error during the installer. Even if NVDA is forcefully shut down, charhook.dll still stays in memory and does not unlink until the next restart of the computer.

[vtsaran]

Small correction (since there seems to be no way to edit actual description): the dialog produced by the installer when the write-protected file is encountered is "abort/ignore/retry".

[jteh]

We have investigated this and found the following:

• This library does not always fail to unload. On my system, it does seem to be unloaded most of the time.
• We do this using a global hook installed using SetWindowsHookEx. Using this mechanism, the system loads the library into other processes; we do not explicitly load it. Thus, we can't explicitly unload it. The documentation notes that the library is not explicitly and immediately unloaded, so one assumes the system does it at its leisure.
• We may be able to get around this by hooking individual threads instead of setting a global hook. In this case, the documentation notes that the system is supposed to explicitly unload the library when the hook is removed.
• Nevertheless, we're not certain this will fix the problem in all cases.
• We really should be using the InstallLib macro in NSIS to install libraries. Among other things, this handles dll versioning, handles reboots if required and allows us to bypass Windows file protection. This should be done for all dlls we install.
  • This will require that these dlls be installed separately from the rest of the package.

[vtsaran]

Never heard of the InstallLib macro; will investigate.

[jteh]

I have made the appropriate changes to use InstallLib. Shall commit later today.

[jteh]

We now use InstallLib and UninstallLib as of r2161. This means that the installer will now request a reboot if required when handling libraries. Please test and comment.

[jteh]

No one has reported any issues with this fix, nor any reoccurrence of this problem.