
    Why is my Desktop so Fragile and What can I do About it?

How many times have you heard or read about a user who has had to rebuild 
their Desktop, run MAKEINI to recover from corrupted INI files, use Alt-F1 
during the boot process to return to the install Desktop or completely 
reinstall and recustomize OS/2 because of some sort of Desktop problem?  I 
suspect that everyone has heard of multiple instances of one or more of the 
above and many have been the user with the problem.  Why is this happening 
and what can a user do to insure that they are not included in this 
unfortunate group?

                Why is the Desktop so Fragile?

In my opinion, there are five primary reasons why so many Desktops have 
corruption problems:

1. The OS/2, PM, WPS environment is much more complex than virtually any 
user can appreciate.  PM and WPS are both multithreaded applications 
and any environment where various tasks are done asynchronously, which is 
the definition of multithreading, is much more complex than it appears on 
the surface.  The reason for the complexity is that the number of different 
logic paths that can be taken through the code becomes large very quickly, 
since the logic path is very dependent on timing.  When you add this basic 
complexity to the fact that PM and WPS have a very large number of threads, 
you end up with an extremely, to say the least, complex environment. There 
are ways to address this problem, such as semaphores and other mechanisms, 
but it is also very easy to leave holes where unexpected events can occur.

2. Because of the complexity described above, it is not possible to
adequately test the effect of changes that are made to the operating
environment.  IBM keeps an extensive suite of tests that they run on every 
new version of OS/2 and that they use to verify that a fix to one problem 
has not created a problem somewhere else.  These tests can verify that the 
most likely logic paths will work correctly, but they cannot verify that 
every logic path is okay because it is not possible to identify every logic 
path and, even if it was possible, the resources necessary to test them all 
would far exceed what is available.  Thus there will always leave bugs in 
the code and some these bugs may eventually cause a problem with one or more 
user's Desktop.

3. IBM has chosen to downplay the probability of having Desktop problems.  
Although the IBM manuals do describe how to make a Backup of the Desktop, it 
is placed way at the end of one of the manuals and is not stressed as being 
as important as I believe it is.

4. The response of the IBM support mechanisms to user Desktop problems often 
goes directly to the most extreme and difficult solutions. Very frequently, 
when a user contacts IBM for technical support because of a Desktop problem, 
three things occur.  First, very little, if any, effort is made to figure 
out what was the actual cause of the problem and a generic reason for the 
problem, such as INI File Corruption, is given. Second, the proposed 
solution is often to start over, which is easy for the technical support 
person and a lot of work for the user. Finally, the user is given no 
direction for preventing the problem in the future.  The net effect of this 
is that users are left with the vague feeling that they are the reason the 
Desktop is corrupted, not OS/2, PM or WPS, the user is faced with a huge 
amount of work to rebuild their Desktop from scratch and nothing has been 
done to prevent the user from being in the exact same position again.

5. The Desktop can be corrupted by any application that runs in the OS/2 
environment or any number of user actions.  The parts of OS/2 that make up 
the Desktop are not protected from being changed by any application running 
under OS/2 or user modification. Once again, there are reasons for this. 
Providing the protection would significantly increase the size and 
complexity of OS/2 and would have a negative effect on performance.  In 
addition, the added complexity would make maintenance of OS/2 that much more 
work.  One could probably argue both sides of the issue, but it makes little 
difference as far as today's user is concerned.  The fact is that everything 
that makes up the Desktop can be changed by any application in the system 
and, in my opinion, it is a testimony to the quality of OS/2 software that 
third party applications and user mistakes do not cause more problems than 
they do.

There are probably many other things that contribute to the problem and some 
of them are being addressed by IBM.  For example, WPS aware application must 
currently run as part of the single WPS process, requiring close integration 
between all of these applications and WPS.  This problem will be eased 
somewhat when WPS is modified to use DSOM rather than SOM.

             What can I do about this Desktop Problem?

One of the most interesting aspects of this entire problem is that it is 
extremely easy to address.  In the process of developing IniMaint, SysMaint, 
MultiMaint and AccessWPS I have clobbered the Desktop, the INI files, the 
Extended Attributes and other parts of my operating environment in more ways 
than almost anyone one else who has worked with OS/2.  I have never had to 
reinstall OS/2, never had to run MAKEINI to rebuild corrupted INI files, 
never had to use Alt-F1 to return to the Install Desktop or had to rebuild 
my Desktop manually. The reason is that I have always had a Backup of my 
Desktop and a plan for how I would use that Backup to Restore my operating
environment in case of a problem.  It is as simple as that.

There are a number of applications that will make a complete Backup of the 
Desktop in less than a minute.  These same applications can completely 
Restore the Desktop in about a minute, as long as PM is not running.  The 
longest part of doing a Restore is creating an environment where OS/2 is 
running, but PM is not running.  There are two ways, that I know of, to do 
this. First is to boot from a floppy. Second is to interrupt the boot 
process before PM is started with something like ShiftRun.  Once this 
environment is reached, the Desktop Restore is very quick.

If you do not have both a Backup of your Desktop and a clear plan for how 
you will use the Backup to Restore your environment, then you should place 
this at the very top of your priority list and get it done immediately.  
Both the Backup and the plan are critical.  The time to develop a plan for 
how you are going to recover is not while you are staring at a black screen 
or a white screen with the clock sitting in the middle.  If either of these 
happen to you, you will be very upset, mad and probably will have difficulty 
thinking things through.  Therefore, you need to make a Backup and then 
imagine yourself sitting in front of that blank screen and think through the
exact steps you would take to recover.  Here is my sequence:

1. I use ShiftRun, so if the boot got that far, I simply reboot. If the boot 
did not get that far, I boot from the Install Diskettes. If you are running 
OS/2 2.1 with the SP, be sure you have diskettes that you can boot from 
because the original diskettes will not work because of version problems and 
the SP diskettes will not work because they will run the Service Program and 
the Shell.

2. I then run my the Restore CMD file created by my Backup and Restore 
application, SysMaint, specifying the latest Backup generation.

3. I then reboot OS/2 and I am back operating normally.

Total elapsed time, less than 5 minutes.  Rate of failure, zero.

Even though I have not ever had a failure to Restore my Desktop, I am
prepared for a failure, since my Backup application will automatically 
maintain as many generations of Backup as I ask it to and I have asked for 
20 generations.  This means I could go back one generation at a time to 
older and older Desktops.

So what should you do if you do not have a Backup of your Desktop?

1. Get a Desktop Backup and Restore application immediately.

2. Make a Backup of your current Desktop and put it somewhere where it will 
not get clobbered.

3. Sit down and think through exactly what you will do to Restore your 
Desktop if you have a problem and be sure it will work.  In other words, if 
you are going to boot from a floppy, then get out the floppies and boot from 
them to insure you can do it.  If you are running ShiftRun, then interrupt 
the boot and make sure you know exactly what you would do from there.

        When should I make a New Backup of my Desktop?

My answer to this question is that I make a new Backup anytime I make any 
changes to the position, content or settings of any Object on the Desktop.  
The Backup takes less than a minute and I always have at least 10 
generations of Backup so there is no reason to expose myself to having to 
manually recreate things.

The key here is having multiple generations of Backup.  If your Backup 
application does not have a facility for maintaining multiple generations 
then you must insure, at the very minimum, that a new Backup will not 
clobber the current one, so you need to create your own mechanism for 
protecting the current Desktop Backup.  If the process of maintaining 
multiple generations is a complex or time consuming one, then you might 
decide to not make a Backup as often as I do.
