I don't know, on some systems it just doesn't, for example my Warp 3 with FixPak 35, but it does on my Warp 4. I was unable to figure out what the reason for this is, but a few users have also reported this, and the problem also occurs with the WarpEnhancer reboot feature, so I guess it's not &xwp;'s fault. (The reboot feature uses an undocumented IOCtl to DOS.SYS anyway, so there is probably no guarantee by IBM that it will always work.) If you have the IBM BootManager installed, you can circumvent this problem by specifying SETBOOT.EXE as a user reboot option (Desktop settings notebook -> "XDesktop" page 1 -> "Actions").

Yes. &xshutdown; does not save positions of folders which have changed just before &xshutdown; was initiated, because the WPS delays saving folder positions in some background thread to which I have found no access, and the format of the folder position entries in OS2.INI is not documented, so I cannot do it myself. The same applies to folders which are closed by &xshutdown; itself. If you want folder positions to be saved, close them manually and wait a few (about 10-20) seconds before starting &xshutdown;.

(With "folder positions", I mean the position of an open folder window itself, not the positions of the icons in a folder. These are properly saved.)

Also, &xshutdown; cannot save changes to the Tasklist window (e.g. fonts or colors being dropped on them). If you want these changes saved, you'll have to use &os2;'s regular shutdown just once.

This is one of the all time favorites, and the problem has changed with several releases.

• With early versions before XFolder 0.85, this was mostly due to INI keys which do not contain any data, which shouldn't happen. This has been fixed a long while ago.

• Still, many people reported these errors to occur pretty randomly, even with INI keys which do contain data. I was finally able to track this down to occur with pretty large INI files. I suspect that basically the problem sits in PM itself, since the WinGetLastError API frequently returns PMERR_MEMORY_ALLOCATION_ERR, which is cooly described in the PM reference with "An error occurred during memory management.". I believe that with large INI files, PM runs out of shared memory, which is used for INI file management. The limit above which the errors start to occur is dependent on how much shared memory is already used on the respective machine, but it's usually way above 1 MB per INI file.

  Basically, before V0.9.5, &xwp; used PrfOpenProfile to create a new INI file (for the user and system INI file, respectively) and then went through all applications and keys in the profile and simply copied them. This caused quite some stress on the PM shared memory management.

  Reducing the size of the INI files did help. By the way, it was not only &xshutdown; which fails on these INIs, but any other application which copies the user and system profiles bytewise also (I've checked this with WPSBackup once, which just crashes).

  To reduce the size of the INIs, first of all, run CHECKINI (from Henk Kelder's WPTOOLS package) to have all invalid entries removed. In addition, use any INI editor to manually delete the following keys which can grow very large (make a backup of your INIs before doing this):

  • PM_Abstract:Icons: this contains the icons for all abstract objects. By deleting this key, you will lose all user-defined icons for abstract objects, but in many cases, the data in here is redundant, because e.g. program objects use the executable's icon per default anyway.
  • PM_Workplace:FolderPos: this holds the window positions of all the folders that were ever opened by the WPS, even if a folder was last opened five years ago. You will lose all your folder positions when deleting this, but except for maybe a dozen folders this should be acceptable, and for those, you can quickly resize them again.
• With V0.9.5, I have rewritten the routines so the PM APIs are no longer used for creating the new profiles. Since Carsten Arnold told me the file format of the INI files, I wrote a set of routines which write these without using shared memory. Apparently, this helped. This is the "new method" which is now selectable on the "&xshutdown;" page in the Desktop's settings notebook.

This is the same problem as described in the previous question. Obviously, your INI files have not been properly saved. As a result, &os2; reverts to default values for the screen and cannot find your desktop.

If this happens, you will find a backup copy of both OS2.INI and OS2SYS.INI in your \OS2 directory, renamed to .BAK. Before &xshutdown; saves the INI files, it renames the old ones. Boot to a command line (using Alt-F1 during startup) and rename these two backups back to *.INI.

I don't know. On some systems, it just doesn't. I'm pretty sure it's not &xwp;'s fault because &xwp; does nothing but calling into the APM.SYS device driver, after which it has no control over what that driver is doing to power off the system.

IBM updated the APM APM support with Warp 4 Fixpak 6 (and possibly later too). The "&xshutdown;" page in the Desktop's settings notebook displays the version number of the installed APM driver, which should be at least 1.2 to make APM power-off work.

Even worse, there are many systems which have no 100% compatible APM support in the BIOS, and this might be the problem too.

Again, &xwp; can't do much about this. I am getting these CHKDSKs too on my laptop, even though it's working fine on my desktop machine. Apparently APM.SYS does not wait long enough for some hard disk with large internal caches to flush their caches to disk before the system power is killed. This appears to be a generic problem which I've also read about with Win95, so you'll probably have to disable APM altogether in this case.