In principle, these file handles are a good thing. It is file handles which allows for the WPS's superior features of program objects and shadows working even after the files they point to have been moved to a different location. Basically, this works because program objects and shadows never store the physical path of an object, but only an object handle.
Object handles are 32-bit integers which are supposed to be unique on the system. The high-word of the integer signifies the storage class of the object while the low-word is a unique identifier within that storage class.
OS2.INI
in the first place.
Abstract objects usually have
a high-word of 0x0002
, and their low-word is listed in the
PM_Abstract:Objects
section in OS2.INI
with the
object's data.
Abstract objects always have a handle created for them because they have no file name and the handle is the only way to reference them, unless they also have an object ID assigned.
xfix does not deal with abstract objects. Use Henk Kelder's CHECKINI for that.
0x0003
. The low-word then comes from the file handles
database in the PM_Workplace:HandlesX
section of
OS2SYS.INI
, which xfix displays to you.
Note that there are two PM_Workplace:HandlesX
sections (with X
being 0 or 1). The WPS holds the file-system handles list in memory all the time
and flushes it to the OS2SYS.INI
only from time to time. When it
does so, it checks the PM_Workplace:ActiveHandles
key to find out
which of the two sections is currently active, flushes the handles to the other
section, and modifies that key to point to the other section then. This is necessary
because entries in the OS/2 INI files may not contain more than 64 KB of data and
the WPS therefore has to use several blocks to hold the entire handles table.
(Yes, that's pretty ugly.)
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. I guess this was the original design when the WPS was first created for OS/2 2.0. (Again, this is only a problem for file-system objects, since per definition, abstract objects must have a handle.)
For example, if you enter a path to an executable file in a program object's settings notebook, the program object wants a handle, so it should get a new one when no one exists yet. The same applies to shadows.
So again, in theory, object handles are a great thing. However, there are several problems with the implementation of them in the WPS:
WPObject::wpQueryHandle
method. For PM programmers, this is the
WinQueryObject
API, which calls the WPS method internally.)
See How can I... for fixing duplicate handles.
<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.
This is OK in most cases, except that if installation programs create a whole lot of object IDs, this creates quite a number of handles. (This includes the standard Warp 4 configuration, which creates an excessive amount of object IDs for the default URL objects.)
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.
Win*
APIs to create
WPS 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.
OS2.INI
so that
the folder's position is not lost when the folder is moved.
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 bug.
And again, since object handles are never removed, these unnecessary handles will stay on the system forever.