New tools and old tools
Last week we released a versions of our tools that no longer install DLLs in the Windows system32 directory. We documented these changes in an article Changing How We Install Our Software.
In hindsight, I think we rushed that release. Which is a strange thing to write given that the work that went into it was nearly a month in duration and the last two weeks of testing every use case for the update NT Service API and the new DLL locations, that was very detailed and deliberate.
But where we let ourselves down was how we communicated about how the old versions of the tools and the new versions of the tools can live side by side. This blog post is about clearing up any misunderstanding. We’ve also improved the user interface for informing you about the old DLLs and choosing what action to take if old DLLs are found.
How do old tools and new tools co-exist?
Old Tools
The old tools always copy the DLLs they need to System32 every time they start. Because of this, even if a new tool removes the DLLs, the old tools will reinstall the DLLs automatically.
New tools
The new tools don’t expect to find DLLs in System32 and thus may not work correctly if DLLs are found there (because of how Windows search paths work). To deal with this we’ve provided a helper utility system32 cleanup which you can use to automatically delete any DLLs from old tools.
If you set the cleanup utility to automatically delete any dlls from old tools, then the new tools will always cleanup any dlls from the old tools, while the old tools will always replace them. This system will work unless you have an anti-virus tool that starts deleting anything copied into System32 – if that is happening you need to start using the new versions of our tools.
System32 Cleanup
The system32 cleanup user interface is only displayed if there are DLLs from old versions of the tools in the Windows system32 directory.
Please note that on 64 bit machines the 32 bit versions of our tools will be looking in SysWow64 (although the path will be reported as system32 due to the Windows file redirection mechanism).
We’ve replaced the message box with a dedicated dialog that allows you to choose how you want the old DLLs treated.
The dialog provides a list of DLLs that are from old versions of our software tools.
Below the list is a combo box allowing you to choose what action is taken when any subsequent check for DLLs is run (regardless of which Validator tool starts the check for old DLLs). The options are:
- Always ask to delete files.
- Always delete files.
- Never delete files.
Each option results in different behaviour.
Always Ask To Delete Files
If Software Verify DLLs are found in system32 the dialog is displayed. The user of the software gets to choose if the DLLs are deleted or not. The DLLs can be deleted by clicking the Delete Files button. The future behaviour of the dialog can be changed by choosing one of the options in the combo box. If Always delete files is chosen the DLLs will be deleted when the dialog is closed.
Always Delete Files
If Software Verify DLLs are found in system32 the DLLs are deleted without informing the user. The dialog is never displayed.
Never Delete Files
No DLLs are deleted. The dialog is never displayed.
/reset
Because only one of the above behaviours results in the dialog being displayed it is possible to set the dialog up so that you can never interact with it again. But what if you wanted to change the behaviour once later on? To do that, run the svlSystem32Cleanup.exe (or svlSystem32Cleanup_x64.exe as appropriate) with the
/reset
command line argument. This will reset the behaviour to the default state and cause the user interface to display even if there are no DLLs to delete.