From: andy@cbmvax.commodore.com (Andy Finkel)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: Amiga 4000/Atari Falc
Date: 11 Sep 92 21:35:31 GMT
Reply-To: andy@cbmvax.commodore.com (Andy Finkel)
Organization: Flying Cat, Inc.

In article <1992Sep10.173146.18998@ctr.columbia.edu> jerry@connection.prospect.com (Jerry Shekhel) writes:
>andy@cbmvax.commodore.com (Andy Finkel) writes:
>>>
>>>No, I just think that a computer grafted on top of another computer is
>>>a kludge.  It has nothing to do with the Intel CPU.
>>
>>Then, by obvious implication, an operating system grafted on top
>>of another operating system is also a kludge.  Therefore, the
>>DOS box grafted to OS/2 is a kludge.
>>
>
>I don't see where you got this "obvious implication".  Software is different
>from hardware.  There's nothing kludgy about software layers; that's the way
>software is designed.  

Apparently you are not quite clear about the concept of 'layering', otherwise
you could have not made such a statement.  The Amiga OS is layered.
You have lower level portions of the system providing services,
and higher level pieces taking advantage of those services while providing
other, more complex services.

OS/2 is _not_ layered on top of MS-DOS.  There is _not_ a core of
MS-DOS running at the low level.  OS/2 does _not_ use MS-DOS services.

MS-DOS is not layered on top of OS/2.  MS-DOS does not take advantage of
the lower level OS/2 calls and provide other, more complex services.

Instead, the OS/2 design itself was compromised to provide for the concept
of the MS-DOS compatibility box.  You can tell by reading the design docs.
They do things like provide an elegant semaphore mechanism that has tacked
onto it a screwy 'extra' couple of modes that are required to support
MS-DOS.  Or the process control calls.  They came up with a clean, consistant
design, then distorted that design to support the MS-DOS box.  This
is _not_ layering.  This is pure kludge.  The OS would have been cleaner
and more elegant without the MS-DOS support.

>Consider X-Windows.  There's Xlib, above which is the
>X Toolkit, above which is a widget set (like Motif), above which is a virtual
>toolkit (like XVT).  So, OS/2 supports the DOS API.  I don't see anything
>wrong with that.  

See above.  Its nothing like the X-Window system.

>However, the amount of "kludginess" depends on which OS/2
>you're talking about:
>
>>
>>Seriously, read the book _Inside OS/2_ by Gordon Letwin.  If you are
>>at all familiar with the details of other operating systems, and
>>the details of MS-DOS, you'll be amazed at the kludges that MSDOS
>>compatibility forced into OS/2.  The first time I read the book I
>>was not familiar with MSDOS, so in a lot of places I was puzzled
>>as to why they took a clean concept, then grafted a really twisted
>>mode into it.  I recently reread the book , and now that I know MSDOS
>>I understand why the screwy twists got in.  The MS-DOS compatibility
>>box is probably the worst thing to happen to OS/2 as an operating
>>system.  (You can argue all you want about how it was necessary
>>to OS/2 as a marketable product;  this is different from what it did
>>to OS/2 as an OS)
>>
>
>I read the book, and yes, OS/2 1.x had to do a lot of trickery to switch
>the 286 CPU into Real Mode from Protected Mode (something the 286 isn't
>designed to do) and execute a DOS app while running OS/2 processes in the
>background.

Well, no, I wasn't really refering to the "switching the car off at
60 miles per hour" needed to get the 286 to go back from protected
mode to real mode.  I was talking more about the distortions to
the redirector, the design of the environment strings, process control,
and so on.
  All of this is gone now that we have the 386 and OS/2 2.0; read
>"The Design of OS/2" by Deitel & Kogan.

I'll take a look at it;  I'm always interested in OS books by OS
designers.  Those are usually the only ones worth reading :-)

>
>>
>>On the realtime nature of OS/2:   Again, from _Inside OS/2_, the
>>scheduler always runs the thread with the highest priority, until
>>that thread blocks for some reason, or a higher priority thread
>>requires the CPU.  (Has this changed in OS/2 2.0?)  
>>
>
>OK, what does this imply about OS/2 -- is it real-time or isn't it?
>

I deliberately left out the conclusion.  How _can_ you argue about
whether or not OS/2 is realtime if you don't have the background ?

Are you just arguing for the sake of argument ?  Or was it just a
reflex protest ?  (It's Intel so it MUST do it...)

Not being realtime is not necessarily a disadvantage, unless you are
doing a realtime application.  If you are not doing something that
requires realtime response, your OS may have different goals, like
maximizing throughput, responsiveless to the user, and so on.

Note:  I still haven't given you the conclusion.  Again, deliberately.
If you want to argue whether something is realtime or not, you have
to do your _own_ homework.  :-)

>| Jerry J. Shekhel  | Molecular Simulations | Time just fades the pages      |


			andy
-- 
andy finkel		andy@cbmvax.commodore.com

"OS/2 is the operating system for the next thousand great applications." -
 one of the things Bill Gates probably wishes he hadn't said.


Any expressed opinions are mine; but feel free to share.
I disclaim all responsibilities, all shapes, all sizes, all colors.
Newsgroups: comp.sys.amiga.advocacy