[VB6] CheckLST - a PDW Setup.LST file checker

People using VB6's old PDW setup packager often get into trouble because they have failed to keep the PDW's knowledge base up to date. This is understandable, since it isn't an easy task.

The "knowledge" is contained in VB6DEP.INI and in *.DEP files (that in some cases have not been provided so you are supposed to create them). Updating means keeping up with 17 years or more of MS KB articles about files that have become non-deployable for various reasons as well as updating *.DEP file version and date information.

The upshot is you can end up with a PDW-created setup package that fails, hangs, causes reboot loops, etc.

Most of those can be resolved by examining the PDW-created Setup.LST file for the package to identify and remove "problem" files (usually DLLs and OCXs). However this takes an educated eye, and not everyone has the necessary experience for this.


CheckLST Utility

This program attempts to perform an automated check of the contents of *.LST files created using the PDW. It makes use of its own "knowledge base" in the form of its [Exclusions] section in CheckLST.ini and calls to SfcIsFileProtected() in Sfc.dll in Windows XP and later.

The *.LST file to scan can be provided several ways. You can drag/drop its icon onto CheckLST.exe's icon in Explorer, you can run CheckLST.exe from a command prompt and provide the *.LST file's name as a parameter, you can drag/drop the file's icon from Explorer onto CheckLST.exe's Label1 (the file name Label control at the top of the Form), or copy/paste, etc.

See the comments at the head of Form1's source code.

There is a TestSetup.lst file provided in the attached archive for testing. CheckLST.vbp includes this file name as the command line parameter for in-IDE runs, so you can generally just open the Project and hit F5 to run a canned test.


Requirements

The VB6 compiler is needed to compile the utility. No special steps should be required to do this.

Windows XP or later is required at runtime.

CheckLST.exe is self-contained as a single file, except that it requires CheckLST.ini located at App.Path. However this makes it pretty easy to copy anywhere you want to keep it for use.


References

You may find a few specific MS KB articles useful in understanding CheckLST and what it is doing:

MS KB 189743: Description of Setup.lst sections

MS KB 189739: How to use Package and Deployment Wizard installation macros


The Report

Analysis of a *.LST file is reported in a LiteGrid UserControl (a simple flexgrid-like control used here to eliminate use of an OCX).

Attachment 127465

Bad things are noted in red, and these should be investigated. In most cases anything noted there in red is a file that you should be excluding from your PDW package.

You could also modify CheckLST to offer saving of the report as a TXT, RTF, HTM, etc. file.


CheckLST.ini's [Exclusions] Section

You can modify this for special cases, to correct things you consider errors there, or to add new items as you discover them or as new Windows versions change deployment rules in the future.

It may be worth noting here that MDAC_TYP.EXE is a good example of something that should be added to [Exclusions] because except for deployments targeting early Windows 95 machines it is unnecessary and undesireable. You might still want it for Win98, Win98SE, or even WinMe to update MDAC components, but even then it is usually a Bad Idea.

The upshot is that you want to investigate even the items reported in blue as "not found" because they might be trouble.

In the post #1 screenshot you can see that wiaaut.dll was detected as a Protected system file.

This is true on the system where the run was done, however if you need to deploy to Windows XP you may need to provide that DLL as part of your setup. This also suggests that CheckLST should really only be run on a Windows Vista or later system. XP just doesn't quite cut it.

What we have here is an example of how you need to do some diligence about investigating.

In this particular case you do not just want to go ahead and package the file from its live system location. Even though this library can be deployed to Windows XP SP1 or later, this is only safe if you use the redist version that Microsoft provides for this specific purpose (assuming you can even find it anymore at Microsoft Downloads).

The way these things are supposed to be handled using the PDW is that you would obtain the WinXPSP1 redist version from Microsoft and copy it into the PDW's REDIST folder, normally at:

C:\Program Files\Microsoft Visual Studio\VB98\Wizards\PDWizard\Redist

When the PDW needs to package a file it will look for it here and use the copy found if present. This REDIST folder is another of those things VB6 programmers are supposed to be maintaining over time.

See:

MS KB 830761: Best practices for deploying Visual Basic 6.0 applications

Yes Reginald, as you pointed out in your private message much of this is being done heuristically.

It almost has to be because of several factors.

First, the setup.lst files do not tell us the actual source of each file, but only its intended destination. By default these are the same, but things vary when manually overridden in the Wizard or when *.DEP files tell the Wizard to use a different location. So CheckLST uses the provided destination as the potential source, and if not found it tries the other likely sources defined by the destination macros used by the PDW, Setup.exe, and the standard Setup1.exe programs.

Second, various files are protected... or not protected... on a Windows version by version basis. Which files get preinstalled and protected by Windows has changed through history. In many cases such "protected" files actually aren't a problem because the mechanism of protection has gotten better through history as well and newer versions of Windows can fend off attempts to cause trouble by a bad setup better than earlier versions. Where this is true inclusion of protected files just becomes "setup baggage." So a setup that must target Windows XP as well as supported versions of Windows could include the redist version of wiaaut.dll safely because post-XP file protection will block overwriting.

Third, there are large numbers of things like VC-runtime DLLs, MDAC components, pieces and parts of IE or Office applications, etc. that can cause grief when a wrong-version DLL gets deployed to a given target system. There is no hard and fast indicator to check, so all we can do is apply pattern matching against a list of suspects. Such a list must be developed based on 17 years of MS KB articles and some experience. When you have to deploy to an oddball target like creaky old Windows 95 you might have to ignore some of the cases.

There is no magic, but perhaps CheckPDW can help point out items worth scrutiny.


After a few of these you might decide to help "smarten up" the PDW by adding items to its own VB6DEP.INI file's [Do Not Redistribute] section.