Ich weiá es nicht, bei manchen Systemen funktioniert er einfach nicht, z.B. bei meinem
Warp 3 mit FixPak 35, aber er funktioniert bei meinem Warp 4. Ich habe den Grund hierfr
nicht herausfinden k”nnen, aber einige andere Anwender haben auch davon berichtet, und das
Problem taucht auch bei der Systemneustartfunktion des WarpEnhancer auf, deswegen denke ich,
daá es nicht an &xwp; liegt. (Die Systemneustart-Funktion nutzt sowieso einen undokumentierten
IOCtl-Aufruf von DOS.SYS
, also gibt es keine Garantie von IBM, daá dies immer
funktioniert.) Wenn Sie den IBM BootManager installiert haben, k”nnen Sie das Problem umgehen,
indem Sie SETBOOT.EXE als Anwenderoption beim Systemneustart angeben
(Einstellungsnotizbuch der Arbeitsoberfl„che -> "XShutdown"
-> "Aktionen bei Systemneustart").
Ja. &xshutdown; speichert die Positionen von Ordnern, die sich kurz bevor &xshutdown; aufgerufen wurde ge„ndert haben, nicht ab, da die WPS das Abspeichern der Ordnerpositionen in irgendwelchen Hintergrundthreads verz”gert, zu denen ich keinen Zugang gefunden habe, und das Format der Ordnerpositionseintr„ge in OS2.INI ist undokumentiert, weswegen ich es nicht selbst durchfhren kann. Das gleiche gilt fr Ordner, die von &xshutdown; selbst geschlossen werden. Wenn Sie wollen, daá die Ordnerpositionen gesichert werden, schlieáen Sie sie selbst und warten ein paar (etwa 10-20) Sekunden, bevor Sie &xshutdown; starten.
(Mit "Ordnerpositionen" meine ich die Position eines ge”ffneten Ordnerfensters selbst, nicht die Positionen der Symbole in einem Ordner. Diese werden ordnungsgem„á gesichert.)
Auch kann &xshutdown; an der Fensterliste vorgenommene Modifikationen (z.B. darauf gezogene Schriftarten oder Farben) nicht sichern. Wenn diese Žnderungen gesichert werden sollten, mssen Sie einmal den regul„ren &os2;-Systemabschluá benutzen.
Dies ist eine der beliebtesten Fragen und das Problem hat sich ber mehrere Releases ge„ndert.
WinGetLastError
API
regelm„áig PMERR_MEMORY_ALLOCATION_ERR
zurckgibt, was in der PM-Referenz
lapidar als "Ein Fehler im Speichermanagement ist aufgetreten." beschrieben wird.
Ich glaube, daá der PM bei groáen INI-Dateien keinen shared memory mehr hat, der fr
das Management der INI-Dateien erforderlich ist. Die Grenze, oberhalb derer die Fehler aufzutreten beginnen,
h„ngt davon ab, wieviel shared memory auf dem jeweiligen Rechner bereits verbraucht wird, aber sie liegt
gew”hnlich weit ber 1 MB pro INI-Datei.
Vor V0.9.5 verwendete &xwp; grunds„tzlich PrfOpenProfile, um eine neue INI-Datei anzulegen (jeweils fr die Anwender- und System-INI-Datei) und ging dann alle Anwendungen und Schlssel im Profil durch und kopierte diese einfach. Dies verursachte schon einigen Streá im shared memory Management des PM.
Es half, die Gr”áe der INI-Dateien zu reduzieren. šbrigens versagte nicht nur &xshutdown; bei diesen INIs, sondern auch andere Anwendungen, die die Anwender- und Systemprofile byteweise kopieren (ich habe es einmal mit WPSBackup ausprobiert, das einfach abstrzt).
Um die Gr”áe der INIs zu reduzieren, sollten Sie zuerst einmal CHECKINI (aus Henk Kelders WPTOOLS-Paket) laufen lassen, damit alle ungltigen Eintr„ge entfernt werden. Zus„tzlich k”nnen Sie einen INI-Editor verwenden, um die folgenden Schlssel, die sehr groá werden k”nnen, per Hand zu l”schen (ziehen Sie ein Backup Ihrer INIs, bevor Sie dies tun):
PM_Abstract:Icons
: dieser beinhaltet alle Symbole fr abstrakte Objekte.
Durch das L”schen dieses Schlssels verlieren Sie alle anwenderdefinierten Symbole fr abstrakte
Objekte, aber in vielen F„llen sind die Daten darin redundant, da z.B. Programmobjekte
das Symbol der ausfhrbaren Datei sowieso standardm„áig verwenden.
PM_Workplace:FolderPos
: dieser beinhaltet die Fensterpositionen aller Ordner,
die jemals von der WPS ge”ffnet worden sind, sogar wenn ein Ordner das letzte mal vor fnf Jahren
ge”ffnet wurde. Sie verlieren alle Ordnerpositionen, wenn Sie diesen Schlssel l”schen, aber
abgesehen von vielleicht einem Dutzend Ordnern sollte dies akzeptabel sind, und diese
k”nnen Sie schnell wieder in die gewnschte Form bringen.
Hierbei handelt es sich um das gleiche Problem, wie es in der vorangehenden Frage beschrieben wurde. Offensichtlich sind Ihre INI-Dateien nicht ordnungsgem„á gesichert worden. Als Ergebnis kehrt &os2; zu den Standardwerten fr den Bildschirm zurck und kann die Arbeitsoberfl„che nicht finden.
Falls dies passiert, finden Sie Sicherungskopien der beiden Dateien OS2.INI und OS2SYS.INI in Ihrem \OS2 Verzeichnis, die zu .BAK umbenannt wurden. Bevor &xshutdown; die INI-Dateien abspeichert, benennt es die alten um. Starten Sie das System zu einer Befehlszeile (durch Verwendung von Alt-F1 beim Start) und benennen Sie diese zwei Sicherungskopien wieder in *.INI um.
Ich weiá es nicht. Bei manchen Systemen funktioniert es einfach nicht. Ich bin mir ziemlich sicher, daá
es nicht &xwp;s Schuld ist, da &xwp; nichts anderes tut, als den
APM.SYS
-Ger„tetreiber aufzurufen, wonach es keine Kontrolle mehr darber hat, was der
Treiber macht, um das System abzuschalten.
IBM hat die APM-Untersttzung mit Warp 4 Fixpak 6 (und m”glicherweise auch neueren) aktualisiert. Die Seite "&xshutdown;" im Einstellungsnotizbuch der Arbeitsoberfl„che zeigt die Versionsnummer des installierten APM-Treibers an, die mindestens 1.2 betragen sollte, damit das Abschalten per APM funktioniert.
Was noch schlimmer ist: Es gibt viele Systeme, deren BIOS keine 100%ig kompatible APM-Untersttzung bietet, und daran kann es natrlich auch liegen.
Auch hier kann &xwp; nicht viel daran „ndern. Bei meinem Laptop treten diese CHKDSK-L„ufe
auch auf, obwohl es bei meinem Desktoprechner gut funktioniert.
Anscheinend wartet APM.SYS
nicht lange genug darauf, das Festplatten mit groáem Cache
diesen auf die Platte zurckschreiben k”nnen, bevor das System vom Netz getrennt wird.
Dies scheint ein allgemeines Problem zu sein, worber ich auch in Verbindung mit Win95 gelesen habe, weswegen
Sie in solchen F„llen APM wahrscheinlich ganz deaktivieren werden mssen.