&xshutdown; funktionen har kostat mig en hel del tankem”da, d„rf”r att det inte finns dokumenterat n†gonstans vad som h„nder under en normal avst„ngningsprocess.

&os2; k„nner som standard till tv† olika avst„ngnings API'er:

Problemet „r att det finns ingen funktion "mellan" dessa tv†. Om du anropar DosShutdown sparas inte WPS data. Och om du anropar WinShutdownSystem f†r du den regulj„ra avst„ngningen utan ytterligare m”jligheter att p†verka. S† grundl„ggande, var jag tvungen att koda om en komplett ny WinShutdownSystem, vilken nu kommer att f”rklaras. Detta var riktigt sv†rt att g”ra, eftersom IBM knappast f”rklarar n†gonting om vad som p†g†r under WinShutdownSystem.

Notera: I &xwp;, delar "Ut”kad Avst„ngning" och "Starta om Skrivbordet" rutinerna samma kod; dom skiljer sig endast i vad som h„nder efter att alla f”nster har st„ngts. Jag kommer d„rf”r att anv„nda termen "&xshutdown;" i den f”ljande beskrivningen av b†da funktionerna, om inget annat s„gs.

&xshutdown; „r integrerad i WPS och bygger v„ldigt mycket p† &xwp; klassutbyten. Jag har avsiktligt inte lagt &xshutdown;'s kod i en separat .EXE fil av tv† sk„l: f”r det f”rsta, &xshutdown; beh”ver access till WPS interna data, vilka endast „r tillg„ngliga fr†n SOM kontexten; f”r det andra, jag vill hindra folk fr†n att f”rs”ka anv„nda &xshutdown; separat, utan att ha &xwp; klasserna installerade, d„rf”r att detta skulle kunna skada Workplace Shell sv†rt. I mera detaljer, &xshutdown; bygger p† XFldObject utbytesklass och &xwp;'s Arbetstr†d, vilka samverkar f”r att h†lla koll p† WPS interna data.

F”r att f”rst† vad &xshutdown; nu g”r, „r det n”dv„ndigt att f”rst† hur WPS hanterar sina objekt internt. Varje enstaka objekt som blir viktigt f”r WPS vid n†gon tidpunkt, det kan ske genom en befolka en mapp eller att ta reda p† dess inst„llningar eller att starta ett program eller vad som helst, „r -- med WPS terminologi -- "uppv„ckt" av systemet, vilket betyder att det existerar som ett SOM objekt i minnet.

WPS skickar endast mycket s„llan uppv„ckta objekt tillbaka till s”mn, trots att det skulle frig”ra associerat minne och lagra objekten tillbaka p† disk. Detta f†r tv† konsekvenser:

  1. Det finns alltid mycket fler uppv„ckta objekt p† ditt system „n du kan f”rest„lla dig, d„rf”r att de flesta av dom „r inte synliga f”r n„rvarande. Žven om du st„nger en mapp med objekt, f”rblir objekten i den uppv„ckta; det snabbar upp befolkningen av mappen n„r den ”ppnas en andra g†ng. Som ett resultat d„remot, „ter WPS upp mer och mer av ditt minne varje g†ng som du ”ppnar en mapp. (Om du aktiverade &xshutdown;'s loggfil, kan du se hur m†nga uppv„ckta objekt som sparades av &xshutdown;; det „r vanligtvis flera hundra objekt, „ven om &xshutdown; inte sparar alla uppv„ckta objekt, utan endast avkomlingar till WPFolder och WPAbstract. P† sidan "Interna" i Skrivbordets notbok med inst„llningar kan du ta en titt p† hur m†nga objekt som f”r n„rvarande „r uppv„ckta.)
  2. En „ndring av objektets data har ibland bara en effekt p† SOM objektet i minnet, men det sparas inte alltid till disk eller OS2.INI / OS2SYS.INI filerna. Detta „r orsaken till att WPS ibland f†r problem ifall du har gjort omfattande „ndringar, som att flytta en mapp med m†nga abstrakta objekt, eller att inte ha st„ngt av ordentligt: d† st„mmer inte det fysiska fildatat p† disken med WPS inneh†ll.
Detta „r vad &xshutdown; beh”ver XFldObject klassen till, vilken byter ut WPObject. Varje g†ng ett objekt v„cks upp, anropar WPS †tskilliga metoder (bland dom wpInitData och wpObjectReady). XFldObject ”verskrider dessa och passar objektadressen i minnet till Arbetstr†den, vilken sedan ordentligt uppdaterar en &xwp;-intern lista ”ver alla f”r n„rvarande uppv„ckta objekt. S† vitt jag vet, finns det inget annat s„tt att ta reda p† vilka objekt som f”r n„rvarande „r uppv„ckta; †tminstone finns det ingen dokumenterad API f”r att r„kna upp dom.

Nu, n„r &xshutdown; „r initialiserad och bekr„ftad, startar den f”rst tv† tr†dar f”r den f”ljande avst„ngningsproceduren, vilken k”rs parallellt med de regulj„ra WPS tr†darna: huvud "Avst„ngningstr†den" med meddelandek”n f”r statusf”nstret, och "Uppdateringstr†den", vilken monitorerar &os2;'s Aktiva sessioner och postar meddelanden till huvud avst„ngningstr†den, om statusf”nstret beh”ver uppdateras. S† avst„ngning av alla f”r n„rvarande ”ppna f”nster „r en relativt komplex process av samarbete mellan dessa b†da tr†dar: Avst„ngningstr†den st„nger ett f”nster och somnar sedan in tills Uppdateringstr†den uppt„cker en „ndring hos Aktiva sessioner (vilket betyder att f”nstret har st„ngts riktigt) och postar ett meddelande tillbaka till Avst„ngningstr†den, vilken i sin tur st„nger n„sta f”nster, tills alla f”nster „r st„ngda.

N„r alla f”nster „r st„ngda, avslutas Uppdateringst†den. Nu g†r Avst„ngningstr†den igenom listan ”ver alla f”r n„rvarande uppv„ckta objekt (vilket beskrevs ovanf”r) och forcerar skrivning av deras data till INI filerna eller till disken genom att anropa varje objekts wpSaveImmediate metod. Detta utf”rs endast f”r avkomlingarna WPAbstract och WPFolder, d„rf”r att enligt min erfarenhet, sparar alla andra klasser sina data synkront. (Jag har f”rs”kt spara alla WPFileSystem avkomlingar en g†ng, och det orsakade att en massa ut”kade attribut skapades f”r varje enskild fil som n†gonsin v„ckts upp av WPS. Resultatet blev att avst„ngningen tog en evighet att utf”ra.)

Slutligen, beroende p† vilken aktion som ”nskades, g”r Avst„ngningstr†den n†got av f”ljande: