S/2's Workplace Shell, or WPS, is a powerful program for organizing and manipulating data. The WPS is responsible for displaying your computer's files and other objects on the OS/2 desktop. Unfortunately, the power of the WPS comes at a price: the .INI files your desktop is stored in are extremely complex, and somewhat fragile. If these files are damaged--by an unexpected power outage, or a poorly-programmed WPS extension, for example--your OS/2 desktop will start behaving strangely. Symptoms include disappearing objects, inexplicable hangs, or WPS crashes. A common indicator of corrupted .INI files is a message telling you that a folder "has stopped responding to the system" when you press Ctrl-Esc.

The common remedy for a misbehaving desktop is to re-create the desktop .INI files. This is a less than optimal solution, since it means that all the customizations you've made are erased. Another solution is to restore the .INI files from a backup. This method is preferable to re-creating the desktop and starting over, but is still not perfect. Since the desktop can be corrupted long before any symptoms occur, it is difficult to know which backup to restore. In addition, the desktop keeps close track of files on your hard drive. An old copy of the desktop .INI files is unlikely to match your current configuration, and thus is itself a potential cause of desktop corruption.

A better solution is to try to repair the damaged files. The best way I've yet found is to use Henk Kelder's CheckINI. CheckINI is part of the freeware WPTools package, which is available at Hobbes. Although CheckINI doesn't fix all desktop problems, I've found it to be effective in most cases.

Even if you don't have any problems with your desktop, you may still wish to use CheckINI. Over time, the desktop .INI files tend to grow in size. Since the WPS .INI files are stored in memory while OS/2 is running, this can result in a substantial performance hit. CheckINI will prune any unnecessary data in the .INI files and free that wasted memory for programs.

Preparation

Before using any diagnostic or maintenance tool, including CheckINI, you should run CheckDisk on your hard drive. This ensures that any problems with your file system won't be aggravated by the maintenance tool. Since OS/2 keeps the boot partition locked while it is running, you must boot OS/2 from floppy disks to check all partitions. See Table 1 for detailed instructions.

Occasionally, your desktop will be so badly corrupted that the WPS won't be able to locate it. Instead of displaying the desktop when you boot OS/2, the WPS will display an error and then give you a windowed command prompt. If this is the case, add the line "SET DESKTOP=x:\DESKTOP" to your CONFIG.SYS, where "x:" is your boot drive (see Table 2 for instructions). After you do so, shut down and reboot your computer. It's possible that your desktop still won't appear even after you've added this line; if so, don't worry. CheckINI may still be able to repair the damage.

Table 1. Checking Partitions

Action	Result
Insert OS/2 installation disk.
Shut down.	Desktop windows will close and a message telling you to press Ctrl-Alt-Del to reboot will appear.
Press Ctrl-Alt-Del.	Computer will reboot and start loading from the OS/2 installation disk. Computer will prompt you to insert "Disk One".
Insert disk one when prompted.	Computer will continue loading OS/2. Installation screen will appear.
Press F3 when installation screen appears.	OS/2 command prompt will appear.
Type CHKDSK x: /F for each FAT partition, where x: is the FAT partition drive letter. For example, if partitions C: and E: were FAT, you would type: CHKDSK C: /F CHKDSK E: /F Repeat this step until no more damage is reported.	OS/2 will check each partition and repair any damage.
Type CHKDSK x: /F:2 for each HPFS partition, where x: is the HPFS partition drive letter. For example, if partition D: was HPFS, you would type: CHKDSK D: /F:2 Repeat this step until no more damage is reported.	OS/2 will check each partition and repair any damage.
Remove the OS/2 disk from the floppy drive.
Press Ctrl-Alt-Del.	The computer will reboot and load OS/2 from the hard drive.

Table 2. Modifying CONFIG.SYS

Action	Result
Type TEDIT x:\CONFIG.SYS. Replace the x: with the letter of your boot drive. For example, if you boot OS/2 from drive C:, type: TEDIT C:\CONFIG.SYS	The IBM text editor will be displayed.
Press Esc.	The cursor will move to the main editing window.
Press Insert.	The cursor will change from a bar to a small block.
Press Enter.	A blank line will be added near the top of the file.
Type SET DESKTOP=x:\DESKTOP. Replace the x: with the letter of your boot drive. For example, if you boot OS/2 from drive C:, type: SET DESKTOP=C:\DESKTOP	The text will appear as you type it.
Press F4.	The revised file will be saved and the program will exit to the command prompt.

Running CheckINI

CheckINI performs a wide variety of tests. Before running each test, CheckINI will display a box in the center of the window that describes the upcoming test. The name of the test is displayed at the bottom of the screen between two lines of equal signs. As errors are encountered, CheckINI displays your options for dealing with the error in the center of the screen, and adds a detailed description of the error to the bottom of the screen.

The following list describes each of the tests CheckINI performs and some of the errors that can occur. Each section starts with a short description of the test in boldface, followed by the CheckINI name for the test in a monospaced font. Below that is an extended description of the test. There may be some cases that aren't covered; if an error is displayed that you don't understand, it's usually safest to delete or fix the problem instead of leaving it in place. CheckINI won't cause damage to your .INI files--at worst, you will lose some customizations or objects.

Table 3. CheckINI Tests

WPS Classes
PM_Objects:ClassTable

Checks if all the programs registered with the WPS are actually available on your hard drive. On many machines, CheckINI will ask, "Deregister class WPCmpnp because WPCMPNP cannot be loaded?" Answer "NO" to this question. WPCmpnp is a standard part of the WPS, but the supporting file is not installed unless you install plug-and-play PCMCIA support. You should answer "YES" to any other classes, however. If you see any other class names starting with "WP" listed, it is possible that essential parts of the WPS have been deleted from your system. If this is the case, and the desktop continues to have severe problems after you finish using CheckINI, then you will probably have to reinstall OS/2 to resolve the problems.

Abstract Objects
PM_Abstract:Objects & PM_Abstract:FldrContents

Checks the abstract objects on your desktop. Abstract objects are any permanent non-file objects, such as shadows, programs, and the Launchpad. This test also checks if shadow and program objects are pointing to a file that really exists. You should usually remove or fix any abstract object with errors, with the following exception: If you have a shadow or program object that points to an object that isn't currently accessible (for example, on a CD-ROM, or on an inaccessible network drive), this test will think the object has errors. Watch for the name of such objects and don't delete them. Even if you do, however, all you will lose is the objects that point to removable or network drives.

Orphaned Icons
PM_Abstract:Icons

Looks for icons that belonged to deleted abstract objects. Remove any that are found.

Program Associations
PMWP_ASSOC_FILTER
PMWP_ASSOC_TYPE

Both of these tests check your program associations. Remove or fix any invalid associations. Doing so may result in a few program associations disappearing after CheckINI is finished.

Checksums
PMWP_ASSOC_CHECKSUM

The WPS stores checksums for its objects. This test checks to make sure that the objects that the checksums refer to still exist. Remove any invalid checksums.

Positions
PM_Workplace:FolderPos
PM_PrintObject:JobCnrPos
PM_Workplace:PalettePos
PM_Workplace:StatusPos

The WPS stores the position and size for every folder, printer, palette, and power status object, but never removes these values. Therefore, the .INI files are usually full of entries for deleted folders and folders on removable media like CD-ROMs. These four tests check for and remove the extraneous data. Since the first test (PM_Workplace:FolderPos) typically finds several hundred invalid folder settings, CheckINI will ask you if you want to confirm each error. Answer "NO" to this question. You'll save a considerable amount of time, and even if the parameters for a valid folder are somehow removed, all you'll lose are the position and size information for the folder in question. For the remaining tests, just remove any settings that CheckINI encounters. Again, the most you'll lose is position and size information.

Print Jobs
PM_PrintObject

The WPS occasionally forgets to remove the .INI settings for a print job after it's finished. This test allows you to remove any print jobs that have been left in the .INI files.

Startup Folders
PM_Workplace:Startup

Checks that all the startup folders listed in the .INI files actually exist and are really startup folders. Remove any invalid listings.

Object Desktop users: Object Desktop registers some of its objects as startup folders. CheckINI does not recognize these objects as valid startup folders and will ask you to delete them. Unfortunately, its hard to tell which object the errors in this test refer to, so you have two choices: Either skip this test entirely, or delete all startup folders that CheckINI reports. If you delete all the startup folders, the Object Desktop window list and Keyboard Launchpad will not autostart properly when you reboot. Simply opening the Object Desktop folder will fix this problem until you next run CheckINI.

Templates
PM_Workplace:Templates

Checks the internal list of templates to ensure that all the templates listed really exist. This test often displays templates that look like they should be saved, but in fact are obsolete. Remove any templates that are displayed. Even if you somehow remove a valid template, all system templates (not the ones you created yourself, though) are re-created when you open the Templates folder.

Object ID's
PM_Workplace:Location

Checks that all objects with an object ID, such as <WP_DESKTOP>, actually exist where they are supposed to. Remove any incorrect location records.

Object Desktop users: If you ran Object Desktop's SETUPTLP.CMD batch file, Object Desktop changed the object ID of the Tab Launchpad to that of the regular Launchpad. CheckINI will generate an error if this is the case. The error is OBJECT <OBJD_TABLAUNCHPAD> (pathname) CLAIMS TO HAVE ID '<WP_LAUNCHPAD>'!. Do not answer yes when asked if you want to delete this location record, or the Tab Launchpad won't pop up when you double-click a folder background.

Work Areas
FolderWorkareaRunningObjects

The WPS keeps a list of the objects that were still opened when the work area folders containing them were closed. If you rename or delete a work area folder, it is not always removed from this list. This test checks the .INI files for old work area folders. Many of the work areas displayed will look familiar, especially if you've renamed a work area recently. Delete any work areas that are found--chances are good that the work area you think is valid is in fact an older copy of the real work area. Even if you accidently delete a work area, the associated work area folder will simply "forget" which objects you last had open.

Object Handles
PM_Workplace:Handles1

The WPS stores a list which correlates object handles with their pathnames, even after the pathname is no longer valid. This test allows you to remove the invalid pathnames. Be careful not to remove pathnames to valid drives that are not currently connected (for example, a temporarily unavailable network drive). You should delete the pathnames for removable media such as floppies or CD-ROM's, however. This test usually finds a lot of errors.

After all the tests are complete, CheckINI will ask you if you want to write the changes. The following steps must be performed quickly, or the WPS will overwrite the changes CheckINI makes to the .INI files. Answer "Yes" then press a key to dismiss the information box that follows. At the command prompt, type RESETWPS and answer "Yes" when asked if you're sure. Your desktop will disappear, then reappear after several seconds of hard drive access. If you performed these steps before the WPS updated its files, the new .INI files will have been loaded.

ResetWPS has a few unusual side effects that are due to bugs in the WPS. Occasionally, the WPS will crash with a SYS3175 after you run ResetWPS. On some machines, system sounds will stop functioning. Frequently, the OS/2 or DOS command prompt icons become blank. All these symptoms are normal and shouldn't cause alarm. They will go away once you reboot.

You should run CheckINI /C again to make sure that you reset the WPS in time. Continue to run CheckINI, followed by ResetWPS, until CheckINI no longer reports errors (except for the WPCmpnp and Tab Launchpad errors). There are a few situations in which CheckINI will report an error and seem to fix it, only to report the error again when re-run. If you run CheckINI and ResetWPS several times and a few errors still persist, they probably cannot be resolved. If these errors are referencing a particular object, you can try to solve the problem by finding the offending object and deleting it.

Once you're finished with CheckINI, shut down and reboot. Your desktop should come up without problems. It is possible, however, for a desktop to be so badly damaged that after running CheckINI and rebooting, the WPS reports that it couldn't find the desktop, even if it previously did load it. If this occurs, add SET DESKTOP=x:\DESKTOP to your CONFIG.SYS as described in the "preparation" section and run CheckINI again.

There may be times when your desktop is corrupted beyond hope. If the above procedure simply doesn't work for you, you have no choice but to recreate your desktop or restore from backup. If you restore from a backup, I recommend running CheckINI afterwards to ensure that the backup itself doesn't have problems. If you don't have any backups, then your only alternative is to recreate the desktop. This procedure is outlined under the heading "Rebuilding the Desktop" on page 219 of the OS/2 Warp manual and on page 433 of the OS/2 2.1 manual.

Conclusions

letter to the editor.

Our Sponsors: [Surf'nRexx] [BMT Micro] [ChipChat] [EmTec] [Indelible Blue]

Contents | Previous Article | Next Article

Copyright © 1996 - Falcon Networking