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 hierf�r
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 durchf�hren kann. Das gleiche gilt f�r 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, m�ssen 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 zur�ckgibt, 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 f�r
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 f�r die Anwender- und System-INI-Datei) und ging dann alle Anwendungen und Schl�ssel 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 abst�rzt).
Um die Gr”áe der INIs zu reduzieren, sollten Sie zuerst einmal CHECKINI (aus Henk Kelders WPTOOLS-Paket) laufen lassen, damit alle ung�ltigen Eintr„ge entfernt werden. Zus„tzlich k”nnen Sie einen INI-Editor verwenden, um die folgenden Schl�ssel, 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 f�r abstrakte Objekte.
Durch das L”schen dieses Schl�ssels verlieren Sie alle anwenderdefinierten Symbole f�r abstrakte
Objekte, aber in vielen F„llen sind die Daten darin redundant, da z.B. Programmobjekte
das Symbol der ausf�hrbaren 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 f�nf Jahren
ge”ffnet wurde. Sie verlieren alle Ordnerpositionen, wenn Sie diesen Schl�ssel l”schen, aber
abgesehen von vielleicht einem Dutzend Ordnern sollte dies akzeptabel sind, und diese
k”nnen Sie schnell wieder in die gew�nschte Form bringen.
Hierbei handelt es sich um dasgleiche 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 f�r den Bildschirm zur�ck 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 dar�ber hat, was der
Treiber macht, um das System abzuschalten.
IBM hat die APM-Unterst�tzung 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-Unterst�tzung bietet, und daran kann es nat�rlich 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 zur�ckschreiben k”nnen, bevor das System vom Netz getrennt wird.
Dies scheint ein allgemeines Problem zu sein, wor�ber ich auch in Verbindung mit Win95 gelesen habe, weswegen
Sie in solchen F„llen APM wahrscheinlich ganz deaktivieren werden m�ssen.