Object handles are 32-bit integers which are supposed to be unique on the system. The high-word (upper 16 bits) of the integer signifies the storage class of the object (abstract or file-system), while the low-word (lower 16 bits) is a unique identifier within that storage class. To understand where all those file-system handles come from, some more understanding of the WPS's inner workings is required.

In theory, the WPS should only create a handle for a file-system object if this is really needed, i.e. the object was really referenced somewhere.

However, file-system handles can also cause problems. The more file-system handles exist, the slower the WPS becomes in general. Most importantly, the total number of file-system handles is limited. If there are too many file-system handles, the WPS can become unstable.

From my testing, file handles are created in the following situations (in which the aforementioned API is called):

  1. From program objects and shadows. This is desireable because this allows program objects and shadows to still point to the correct target object when the target object is no longer at the original location.

    For example, if you enter a path to an executable file in a program object's properties notebook, the program object wants a handle, so it should get a new one when no one exists yet. The same applies when you create a shadow to an object.

  2. From other parts of the WPS (and &xwp;) to store object references. For example, &xwp; uses object handles to remember your object buttons in the &xcenter;.

  3. Whenever an object is given an object ID (those things in angle brackets, e.g. <WP_DESKTOP>). Object IDs are stored in the PM_Workplace:Location section in OS2.INI together with the object handles and can only be resolved if the handle is valid.

    The major problem with this implementation is that if the file-handles table is broken, the WPS won't find the Desktop any more because it uses the <WP_DESKTOP> object ID to locate it at startup. If you get the "Cannot find Desktop" dialog, in 95% of all cases the file handles table is broken.

  4. From application programs which use the Win* APIs to create Desktop objects or work with them. This is normally tolerable if this affects only a few files. Unfortunately, some of those APIs (such as WinMoveObject) require object handles as input.

  5. For every folder that was ever opened. This is also tolerable because the WPS uses a folder's handle to store its position into OS2.INI so that the folder's position is not lost when the folder is moved.

  6. Automatically for every parent folder in a file's path if a new handle is created for the file. This is due to the handle database's implementation which only stores the short name of each file-system object and stores a reference to its parent with the short name. This is very efficient because if a folder with many sub-objects is moved, only a single entry in the database has to be updated. The sub-objects only have a parent handle stored, which still works.

  7. For each data file that is opened through a program object association. This is because the WPS sets the WP_OBJHANDLE environment variable to the handle of the data file that was opened. Some programs rely on this, but this also has the unfortunate effect that a handle is created every time you double-click on a data file even if the application doesn't need that handle.

    &xwp; allows you to disable this behavior with its extended file associations.

  8. Unfortunately, the WPS also creates handles for each object that is refreshed during folder auto-refresh. That is, if a folder is open and you do something in it from a command line (or another application does something with files in that folder), for every file that changes in the folder, a new file handle is created.

    A simple test case for this is to unzip a ZIP file into an open folder. This will create lots of file-system handles which are probably never used again. Quite a large number of file-system handles are created as a result of this behavior.

    And again, since object handles are never removed, these unnecessary handles will stay on the system forever.

    This problem has been fixed with &xwp;'s replacement folder refresh.