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.
0x0003
. The low-word then comes from the file handles
database in the PM_Workplace:HandlesX
section of
OS2SYS.INI
.
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 &os2; 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.
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):
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.
<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.
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.
OS2.INI
so that
the folder's position is not lost when the folder is moved.
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.
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.