Difficult to say. If it keeps rebooting, this is a sure sign that the WPS is trapping, i.e. exceptions occur when it's booting up. Same thing as on the previous page, XFolder seems to be conflicting with other WPS extensions.
Otherwise, it might simply be that restarting the WPS is not working on your system. The WPS restart is only intended as a shortcut, but if it doesn't work, try rebooting instead.
Some people have reported that removing XFolder INI keys seems to help. Take some INI editor and look in OS2.INI for application names starting with "XFolder". Delete them all. With V0.81, XFolder does not rely on INI keys any more. This will delete all your settings and reset the language to English, but maybe XFolder will run.
In addition, it is always recommended to have more recent OS/2 fixpaks applied, that is, at least Fixpak 35 for Warp 3 and fixpak 5 for Warp 4. XFolder will run without fixpaks, but this might lead to problems. IBM has changed many things with the SOM kernel over time, which the WPS uses for its class management. I have tried my best to enhance compatibility, but I cannot test all possible configurations myself. I have found, for example, that the standard Warp 3 SOM kernel is extremely buggy, so at least for Warp 3 I strongly recommend applying fixpaks. (Although with V0.82, XFolder now does install on Warp 3 even without fixpaks.)
There were serious installation problems with the previous V0.8x versions. Apperently, with V0.82, things have become much better since I've removed SOM multiple inheritance, which the WPS apparently doesn't like too much on some systems.
If installation still fails, even if only some of the classes could not be installed, please deregister all the XFolder classes. Get rid of XFolder altogether until these problems have been solved. The classes are designed to interact, and your WPS is really likely to crash all the time if only some of the classes are installed.
With V0.80, the install script failed to create the new system objects if the XFolder config folder already existed. This should be fixed now, but if problems persist, simply delete your config folder, and all the objects should be created.
Otherwise, you can still execute the
INSTLxxx.CMD
and CROBJxxx.CMD
scripts in the
INSTALL
subdirectory, with "xxx" being your three-digit language code,
as described on the "NLS" page.
However, this might also be due to the fact that the "XFldSystem" and "XFldWPS" classes could not be properly registered. I have seen this happen on a Warp 3 system without any fixpaks installed.