From: buhr@umanitoba.ca (Kevin Andrew Buhr)
Newsgroups: comp.os.os2.advocacy,comp.os.os2.misc
Subject: Re: OS/2 Crashproof? NOT!
Date: 17 Nov 92 00:46:37 GMT
Organization: University of Manitoba, Canada

I've seen a lot of replies to this, and all of them seem to have
missed the mark.  Let me throw in my spare change...

In article <1992Nov13.164155.14309@msc.cornell.edu>
tommy@msc.cornell.edu (Mike Thompson) writes:

>  As a programmer trying to develop a 32 application for OS/2 2.0, I
>  am increasingly finding it difficult to remain dedicated to OS/2
>  development.  I find it VERY funny that IBM should try to sell OS/2
>  as crashproof operating system.

More accurately, IBM is selling OS/2 as an integrating platform with
Crash Protection (TM).  In short, OS/2 is *first*, the environment
with which you can run DOS, Windows, and OS/2 applications all at the
same time, and *second*, OS/2 is stable enough to protect these
programs from clobbering each other to a significant degree.

>  Example 1: 
>  My lab machine runs IBM's TCP/IP in a networked environment.  The
>  mean time between system crashes is less than 24 hours.  Trap 8,
>  trad D, trap E, just plain hung - you name it, we've seen it.
>  Admittedly the machine is being worked hard, but any UNIX system
>  with that kind of performance would never survive.  (Northgate
>  486/33, 16 MB memory, SpeedStar graphics, TCP/IP 1.2.1 + all
>  patches, OS/2+CSD).  My machine at home, similar configuration,
>  traps roughly every 2-3 days, better but it only gets used 4 hours
>  per day.

This is a legitimate complaint, but it is not the norm.  Frankly, it
sounds like substandard memory, but it could have one of a hundred
causes.  Have you run similar configurations on anything other than a
Northgate 486/33?  Is your 16 MB of memory all the same speed?  Have
you contacted IBM, and were they any help?  Have you contacted
Northgate, and what do they say?

Who knows?  If you post some details, maybe someone can offer some
valuable help.  It's been known to happen.

>  Example 2: 
>  From programming, it is TRIVIAL to hang the OS.  Write a PM
>  application and before starting the StdWindow, create a named pipe
>  and wait for another process to access the pipe.  Hang city...

Clearly, this is a bug.  On the other hand, it is a rather obscure
bug.  I think one can reasonably differentiate between a lack of
general ability to protect processes from each other and an operating
system error that manifests itself in a specific situation.  For
example, in my admittedly limited experience, I find the SparcStation
to be terrifically stable machine.  On the other hand, I can crash it
by remote copying a file to its "/dev/audio" (or almost any character
device, if I remember correctly).

This is a bug, not a major shortcoming.  Bugs can usually be worked
around:  start your "StdWindow" before creating your named pipe;
remote copy to a file on the target machine, and copy it to
"/dev/audio" from there.  More importantly, bugs can be concisely
reported to the parties responsible and are usually fixed relatively
quickly.  Major shortcomings aren't nearly as easy to deal with.

>                                                                 And
>  try this one after loading the CSD.  SubClass the FrameWindow in a
>  PM application to modify the RESIZE message.  Pass minimize and
>  maximize message unchanged to original routine.  Resize works
>  correctly, however, minimizing the window (only after the CSD is
>  installed) will hang the sytem

Good God!  I've just taken the CSD off my machine.  Thanks for the
info. ;)  You can understand my position.  Once again, this is a bug.
Whether there is a convenient workaround, I can only guess.  I suppose
it depends on how complicated it is to handle minimize messages.
Report it to IBM, and it'll probably get fixed.

>                                 - full reboot time again!  With 400
>  MB of HPFS partitions to chkdsk, the mean time between debugging
>  attempts is about 5 minutes.

A little practical advice...  Shut off lazy writes, (can you do this
on an HPFS partition?  I *think* so.)  and stop the "chkdsk".  I can't
remember if its possible to ask that the "chkdsk" not be performed.
If not, try replacing the "chkdsk.exe" executable with something that
does nothing.

>  It seems odd that in a multitasking environment one can write any
>  application that takes down the whole OS.  Blocked semaphores may
>  trap your process, but the scheduler should allow others to run.
>  Is it really so hard to preempt a running process?

The single-threaded message queue problem has been beaten to death.
This, and operating system bugs, can hang a system so it is unable to
preempt processes, as you have seen.  For the most part, OS/2 does a
respectable job of keeping things running under adverse conditions, at
least in my experience.

>  Are others getting as frustrated with the OS/2 environment as I.
>  Or have I just been spoiled by the relative stability of large UNIX
>  environments.  As I said at the beginning, I am working with a
>  company to put out a 32 bit app.  But I am getting so frustrated
>  that I wonder if its really worth the continued effort.

You're probably just spoiled.  ;)

Seriously though...  I am glad you are developing for OS/2.  I'm sorry
it's been such a trial.  Please, further investigate the multicrash
problems you have been having.  Try switching to VGA resolution (if
you are running a SuperVGA driver); try pulling out banks of memory to
see if you have something flaky; and talk to IBM and Northgate to see
if you can narrow down the problem.

In addition, realize that operating system bugs may be infuriating and
they may fly in the face of zero-tolerance programming principles, but
in the PC world, the relative stability of OS/2 2.0 (and *not* OS/2
2.1 or OS/2 2.2!) is impressive to some of us.

Kevin <buhr@ccu.UManitoba.CA>