More information about WPTOOLxx.ZIP

WPTools is a package of utility programs I originally made for my own use. The package contains the following programs:

CHECKINI

WPSBKP and WPSREST

CheckIni

I noticed already when only OS/2 2.0 was available that much of the information the workplace shell stores inside the INI files is never removed when the information became obsolete. CHECKINI began its existence as a tool to check worksplace shell related information in the INI files and mainly remove the information if it was no longer relevant or pointing to non-existing files and directories.

During the years I have kept adding additional tests to it. Also, internal inconsistencies (internal references) are now detected and if requested corrected or removed.

You could say that although I do not know anything about SOM programming (the workplace shell is build using IBMs SOM techniques), I do know almost everything about how the WPS stores its persistent information.

Basically, the information is stored at two different locations:

OS2.INI contains, amongst other things, all abstract objects. An abstract object is an object (visible as an icon in the workplace shell) that does not exist on disk. If you f.i. take a look in the desktop directory tree you will not find many objects that are visible on the workplace shell.

Filesystem objects do exist on disk as files or directories. The specific workplace shell settings for these objects are stored in extended attributes, mainly in the .CLASSINFO extended attribute.

CHECKINI is by concept a very dangerous program since it allows a person with less knowledge about the WPS to more or less fiddle about in the INI files. I would therefore strongly suggest to always make backup copies of the INI before running CHECKINI with the /C(orrect) option.

How to run CHECKINI

CHECKINI is run from a OS/2 session. It is not a presentation manager program. CHECKINI can only be run if presentation manager (or to be more precise: the workplace shell) is running. It is not neccessary that the desktop is actually loaded, if the desktop cannot be found and you only have a temporary desktop CHECKINI can also be run.

CHECKINI has the following arguments:

/C - Write corrections to ini-files
/APath - Specify different location for ini-files to be checked (CHECKINI only checks internal consistency of the INI files)
/Llogfilename - specify name of logfile (default CHECKINI.LOG)
/W[:x] - Write all output to logfile
/S - Silent run, only write logfile
/R - Only warn about missing files on existing non-removable drives
/Dpath - Specify location of DESKTOP directory (use with care)
/Y[:x] - Answer all correcting questions YES
/H - Only check for obsolete handles in PM_Workplace:HandlesN
/T - Include a scan of all local drives to detect lost startup folders
/? - Show info

What CHECKINI checks

CHECKINI runs various different tests:

At first (but only if /C is specified) the desktop itself is checked. If problems are found, they are reported. This check is handy if the workplace shell refuses to start because it cannot find the desktop. Checkini offers to fix this problem.
Next CheckIni checks all registered object classes to see if these classes are still valid.
At this point CHECINI checks the integrity of PM_Workplace:Handles. In specific, CHECKINI checks for incorrect first node names (leading to drives having an incorrect name) and for duplicate drive definitions. If CHECKINI fixes incorrect nodes, CHECKINI will terminate and the WPS should be reset;
Next CheckIni gets all abstract objects from OS2.INI and checks them. If problems are found they are reported. For some object classes like WPProgram or WPShadow additional checks are done. Also, the folders (directories) these objects are located are checked.
Then CheckIni checks all icons for abstract objects that are stored inside OS2.INI to see if these icons are not orphaned.
Next CheckIni checks all the workplace shells associations by file type and file filter to see if they still point to valid programs.
Also, CHECKSUM entries are checked.
Then CheckIni does four checks for stored screen positions for folders, print job containers, the various color and font palettes and for status windows. Mainly these items are checked to see if the target they refer to still exists.
Next, CheckIni checks printer objects settings to see if these printers still exist.
Then CheckIni checks the worksplace shells list of startup folders - the folders whose objects must be started as the WPS starts.
Then the list of template objects is checked to see if these objects still exist.
Next all OBJECTID's are checked to see if they still point to anything existing. (An OBJECTID is an alfanumeric identifier like <WP_DESKTOP> that can be used to change object settings via a program e.g. a REXX program.
Then the list of all folders that are workarea's is checked.
Next, when /T is specified, all local harddisks are scanned to see if there might be any problems with folders not containing abstract objects. For one thing any startup folders found are checked. You should NOT enable this test if you have multiple versions of OS/2 on your machine;
Again, the integrity of PM_Workplace:Handles is checked. This time duplicate drive definitions are removed. Again, if any problems are corrected CHECKINI terminates and the WPS should be restarted.
Finally, CHECKINI checks the objecthandle to pathname translate table the WPS uses to remove all obsolete entries. This check normally shrinks OS2SYS.INI a lot.

WPSBKP and WPSREST

WPSBKP is a program that retrieves the object setup strings for all object of some object classes and writes them into a text file in such a way that WPSREST can restore the objects either on the same PC, but in theory also on another PC. You could also use the created text file to see what kind of setupstrings are possible.

The textfile will contain all standard OS/2 objects, but also all the modifications that are made.

The following object classes are processed:

WPProgram
WPShadow
WPLaunchPad

Also, all the folders these objects reside in are processed, and finally the desktop itself is backupped.

WPSBKP uses WPTOOLS.DLL to query the object setup strings.

Also present in the archive is a REXX command file called GETSET.CMD. It is mainly intended as an example on how to use the WPTOOLS.DLL, but it can also be used to make a backup file that WPSREST can restore. Please note that other than WPSBKP, GETSET.CMD writes out all object classes and can be used selectively. You could also backup only one folder using this REXX program.

RESETWPS

ResetWPS is a small program that does only one thing: It resets the workplace shell so it will restart without rebooting. It will do so without saving all the last changes.

ResetWPS is handy to have floating around whenever the WPS turns ballony or after you have run CHECKINI.

REPLINI

REPLINI is a program to dynamically change OS2.INI and OS2SYS.INI while OS/2 is running. Using this program you could switch to a backup version of both ini files without rebooting.

WPTOOLS.DLL

WPTOOLS.DLL is a dynamic link library that contains most of the logic used by WPSBKP and just for the fun of it, I included the possiblity to call the functions in the DLL from the REXX environment.

For usage from REXX the following functions can be used:

WPToolsQueryObject - A function to query the objectclass, the title, the setupstring and the location for any WPS object. Only for standard object classes, setupstrings are returned.
WPToolsFolderContent - Returns the (alfanumeric) OBJECTID's or (numeric) object handles for all abstract objects present in a given folder. Optionally it can also return all filesystem objects.
WPToolsSetObjectData - Works more or less the same as SysSetObjectData, but can also be used with objecthandles returned by WPToolsFolderContent

DEFASSOC.EXE

I made DEFASSOC because several users asked for a command line program to set the default association for a file type or file filter. DEFASSOC can do this.