🚀 go-pugleaf

In article <1130@hsi86.hsi.UUCP>, springal@hsi.UUCP (Rob Springall) writes:
> In article <5261@ur-cc.UUCP> ttak@uhura.cc.rochester.edu (Timothy Takahashi) writes:
> >I seem to remember that one of the later versions of Concurrent CPM/86
> >was repudedly MS-DOS compatible. Somehow, I doubt that MS-DOS compatible
> >ment IBM compatible.
> 
> A few years ago (when 286s were all the rage) Digital Research came out with 
> a Concurrent MS-DOS (or something like that).  As I remember, it let you have
> four tasks loaded at one time and it time sliced in between them.  
> 
> The program was an absolute dog (VERY slow) and a kludge.  It was actually 
> Concurrent CP/M-86 that was made to look like DOS.  All of the DOS commands 
> that were internal became external, all the error messages were CP/M...  
> Piece of garbage but my boss at the time was very high on CP/M and DR.

This sounds somewhat confused.

Concurrent PC-DOS could certainly handle more than 4 tasks.  However, it
included a rather crude windowing system which ran in text mode (character
based windows rather than graphics based windows) and it allowed up to 4
windows on the main console (you could also have a session on each serial
port).  Each window was equivalent to one MS-DOS session (not a separate
application as on Microsoft Windows).  You are probably thinking of the
number of windows rather than tasks.  A task however could be run without
a window if it was a background task (admittedly not something that a lot
of PC users do, but _very_ useful for some OEM applications).  This would
allow many more than the 6 tasks you get by adding up the MS-DOS sessions
(4 console + 2 serial port) in a simplistic way, though you do run out of
memory on a 640K machine fairly quickly.

I disagree that it was all that slow.  Certainly some applications (notably
those hostile applications that would poll the keyboard with a busy wait,
or do CPU-bound timing delay loops) could do bad things to the system, but
that's really a problem with the application program and all multi-tasking
systems can have problems with this kind of hostile program (though there
are differences in how intelligently the system can reduce the offending
application's priority to the ugly stepchild priority).

It did take up a fair amount of memory (about 256K for the OS alone), but it 
allowed some programs to be run out of expanded memory.

In its day it wasn't a bad idea.

On the other hand, there were some serious problems with the system that
this article doesn't even mention.  For one thing, early versions did not
support either the MS-DOS batch language or ANSI.SYS.  DRI had it emulate
another terminal (which may be fine in the abstract but it doesn't help
the MS-DOS compatibility very much).  Not emulating the batch language
was even worse.  Early versions also had some horrible bugs (notably with
such things as hard drives > 20MB).  They also omitted such useful things
as the MS-DOS environment space (!) in early versions.  And numerous
MS-DOS system calls just didn't work properly (it took several releases
to fix all the system call problems).

Later versions have fixed most or all of these early problems, but at 
the cost of making the system MUCH pickier about what hardware it runs 
on.  If you aren't running an IBM-PC or a Compaq with all the cards from 
the same vendor, there is a _high_ probability that it won't work.  It 
is, from everything I've seen, even more hardware-picky than OS/2.

You will still have problems running huge applications on it unless you
have a 386 (then the memory management becomes much easier).  This is
pretty much a hardware limitation - a multitasking system just takes
more memory than a single tasking system, and you probably don't want
a single task taking up the whole machine;  and a 286 just can't run
each application in a virtual 8086 environment.

I wouldn't call it a piece of garbage but there are now better
alternatives available.

						Bruce C. Wright