• Onbepaalde objecten hebben gewoonlijk een hoog-woord van 0x0002, en hun lage-woord is opgenomen in de PM_Abstract:Objects sectie in OS2.INI met de gegevens van het object.

  Voor onbepaalde objecten wordt altijd een ingang gecre‰erd omdat zij geen bestandsnaam hebben en de ingang de enige manier is om naar hen te refereren.

• Daar tegenover staat dat, alleen bestandssysteem objecten (bestanden en mappen) soms een ingang toegewezen hebben gekregen. Bestandssysteem objecten hebben gewoonlijk een hoog-woord met 0x0003. Het lage-woord komt dan van de bestandsingangen database in de PM_Workplace:HandlesX sectie van OS2SYS.INI.

  Merk op dat er twee PM_Workplace:HandlesX secties zijn (waarin X de waarde 0 of 1 heeft). De WPS houdt de bestandssysteem ingangen lijst altijd vast in het geheugen en speelt dat, alleen van tijd tot tijd, door aan de OS2SYS.INI. Wanneer het dat doet, controleert het de PM_Workplace:ActiveHandles sleutel om uit te zoeken welke van de twee secties op dit moment actief zijn, speelt de ingangen door naar de andere sectie en verbetert dan die sleutel om hem naar de andere sectie te laten verwijzen. Dat is noodzakelijk omdat ingangen in de OS/2 INI bestanden niet meer dan 64 KB aan gegevens mogen bevatten en de WPS daarom diverse blokken moet gebruiken om de gehele ingangen tabel vast te houden.

In theorie moet de WPS alleen voor een bestandssysteem object een ingang maken als dat echt noodzakelijk is, b.v. er wordt ergens naar het object gerefereerd.

Echter, bestandssysteem ingangen kunnen ook problemen veroorzaken. Hoe meer bestandssysteem ingangen er bestaan, des te langzamer in het algemeen de WPS wordt. Meest belangrijke, het aantal bestandssysteem ingangen is beperkt. Als er te veel bestandssysteem ingangen zijn, wordt de WPS instabiel

Bestandsingangen worden, o.a. in de volgende situaties gemaakt:

1. Vanuit programma objecten en reflecties. Dat is gewenst omdat dit programma objecten en reflecties in staat stelt om toch naar het juiste doel object te verwijzen als het doel object zich niet meer op de originele lokatie bevindt.

   Bijvoorbeeld, als u een pad invoert naar een uitvoerbaar bestand in een instellingen notitieblok van een programma object, dan wil het programma object een ingang, dus moet het een nieuwe krijgen als er op dit moment nog geen bestaat. Hetzelfde geldt als u een reflectie maakt van een object.

2. Vanuit andere delen van de WPS (en &xwp;) om object referenties op te slaan. B.v., &xwp; gebruikt object ingangen om zich uw objecttoetsen in het &xcenter; te herinneren.

3. Telkens als een object een object ID krijgt (die zaken die tussen rechte haken staan b.v. <WP_DESKTOP>). Object ID's worden opgeslagen in de PM_Workplace:Location sectie in OS2.INI tezamen met de object ingangen en kunnen alleen worden omgezet als de ingang geldig is.

   Het grote probleem met deze implementatie is dat wanneer de bestandssysteem tabel defect is, de WPS de Werkplek niet meer kan vinden omdat het de <WP_DESKTOP> object ID gebruikt om hem bij het opstarten te lokaliseren. Als u de mededeling "Kan de Werkplek niet vinden" krijgt, is in 95% van de gevallen de ingangen tabel defect.

4. Vanuit applicatie programma's die de Win* API's gebruiken om Werkplek objecten te maken om daarmee te werken. Dat is normaliter alleen toelaatbaar als het een paar bestanden betreft. Helaas, hebben sommige van deze objecten (zoals het WinMoveObject) object ingangen als invoer nodig.

5. Voor iedere map die ooit was geopend. Dat is ook aanvaardbaar omdat de WPS de ingang van een map gebruikt om zijn positie op te slaan in OS2.INI zodat de positie van de map niet verloren gaat als de map wordt verplaatst.

6. Automatisch voor iedere ouder map in een bestandspad als een nieuwe ingang wordt gecre‰erd voor het bestand. Dat komt door de ingangsdatabase implementatie die alleen de korte naam van ieder bestandssysteem object opslaat en een referentie naar z'n ouder met een korte naam. Dit is zeer effici‰nt omdat als een map met veel sub-objecten wordt verplaatst, er alleen een enkele ingang in de database moet worden aangepast. Alleen de sub-objecten hebben een ouder ingang opgeslagen. die nog steeds werkt.

7. Voor ieder gegevensbestand dat wordt geopend door een programma object koppeling. Dit is omdat de WPS de WP_OBJHANDLE omgevingsvariabele instelt naar de ingang van het gegevensbestand dat werd geopend. Sommige programma's steunen hierop, maar dit heeft ook het ongelukkige effect dat de ingang iedere keer wordt gemaakt telkens als u dubbel-klikt op een gegevens bestand, zelfs als de applicatie die ingang niet nodig heeft.

   &xwp; staat u toe om dit gedrag uit te schakelen in zijn uitgebreide bestandskoppelingen.

8. Helaas, maakt de WPS ingangen voor ieder object dat wordt vernieuwd gedurende een automatische vernieuwing van een map. Dat gebeurt, als een map is geopend en u doet er iets in vanuit een opdrachtregel (of een andere applicatie doet iets met de bestanden in die map), voor ieder bestand dat in de map wordt gewijzigd wordt een nieuwe bestandsingang gemaakt.

   Een simpele proef is om een ZIP bestand te unzippen in een open map. Dit cre‰ert een groot aantal bestandssysteem ingangen die waarschijnlijk nooit meer worden gebruikt. Een redelijk groot aantal bestandssysteem ingangen worden er gemaakt als resultaat van dit gedrag.

   En wederom, omdat object ingangen nooit verwijderd worden, blijven deze niet noodzakelijke ingangen voor altijd in het systeem staan.

   Dit probleem wordt opgelost door "Nu vernieuwen" van &xwp;.