From: jerry@msi.com (Jerry Shekhel)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: Future Amiga chipsets
Date: 30 Dec 92 19:25:41 GMT
Organization: Molecular Simulations, Inc.
X-Newsreader: TIN [version 1.1 PL8]
X-Posted-From: hemi.msi.com
NNTP-Posting-Host: sol.ctr.columbia.edu

Mr. Mike" Passaretti (mrmike@michelotti.ae.ge.com) wrote:
:
: jerry> Suppose I am not interested in real-time embedded
: jerry> systems.  Let's say I need an OS which supports the
: jerry> most varying hardware, can handle the largest, most
: jerry> feature-packed commercial applications, and has an
: jerry> easy-to-use GUI.  Does your real-time embedded OS
: jerry> qualify as a good OS in my case?  No, it doesn't, but
:
: Yes, it does.  "My" real time OS supports NFS, X-Windows, UN*X
: file systems, and runs on most x86, 680x0, or i860 products with
: minimal device driver and board support work.  I've personally
: "ported" it to 12 or so different machines.  It also fits in
: less than 1MB of ROM.  
:

Just wondering:  Does your OS have virtual memory?  How about device-
independent graphics and sound?  These are the things I was talking
about -- the things that I consider the strengths of Windows.

:
: jerry> Windows certainly does.
:
: It doesn't support my Amiga.  I've run my real-time kernel
: (most of it anyway) on Ami as a task.  Which supports the most
: varying hardware again?
:

Oh, I never meant to imply that Windows is portable!  In fact, it's probably
even more tied to the x86 than DOS!  But that's not the type of hardware
support I was talking about.  I was talking about device independence.  This
means being able to send a text or graphics primitive to dumb video,
coprocessed video, a dumb printer, a PostScript printer, a fax board, or
anything else, all with the same call, automatically taking advantage of
coprocessors or PostScript if available.

:
: Actually, all my examples were of resource allocation.
: An OS _must_ do several things; It must allocate resources,
: including but not limited to displays, storage devices and
: input devices.  It must provide for the loading and execution
: of other programs which utilize its features.  It must
: provide a consistent, useful interface to those features for
: the application programmer.
: (I cribbed that from my course notes on OS design)
:

OK, we started this discussion because people were saying that DOS is not
an OS.  What doesn't it provide, in terms of resource allocation?  You'll
probably say, "It doesn't manage the CPU resource," which is true of course,
but does that mean that an OS has to be multitasking by definition?

:
: Agreed.  That doesn't make a motorcycle with a sidecar and a
: trailer a hatchback, though.  I am saying that MSDOS does not
: provide (among other things) adequate resource management to
: be used as a multitasking system, and Windows, for all its
: efforts, cannot "fix" this.  This does not make Windows
: useless, as some might say, but it does make it cumbersome and
: kludgy.
:

I must take issue with this.  Windows replaces *all* of DOS's resource
management code with its own, with one possible exception -- the disk.
I say "possible" because Windows doesn't even have to use DOS to manage
the disk -- the FastDisk driver totally replaces DOS.  Windows also manages
devices which DOS does not, such as mice, sound cards, and graphics screens.
So I believe Windows can and does "fix" DOS's inadequacies.

:
: The simple fact of the matter is that Windows supports no less
: than three different APIs, and that's confusing to say the
: least.
:

What different APIs?

:
: Windows NT is a step in
: the right direction, as is OS/2.  Why are you so resistant to
: the idea that Windows was not designed to be a single OS?  It
: was designed to give App programmers some room to breathe and
: to allow the users to keep their investment in software.  Like
: most attempts at pleasing too many people, it does an adequate
: job to everyone, but it's hardly the best solution possible.
: It is, and here we agree, one of the best solutions available
: to the PC marketplace right now.  OS/2 is just beginning to
: come up the curve...
:

I do agree with this!  OS/2 has everything that Windows has, but with
a better API, preemptive multitasking, memory protection, and a flat 32-bit
address space.  The API is cleaner; IBM and MS saw the mistakes they had
made with the Windows API, and corrected them.  It makes the Windows API
look like a first draft, which is exactly what it is.

As for whether or not Windows was designed to be a single OS, well, I don't
know.  I'm sure BillG always wanted to sell it as an add-on to DOS, but
how it's packaged and bootstrapped doesn't change what it is, does it?

:
: Actually, although X-Windows is delivered with many UN*X
: systems, it is _not_ part of the OS.  This is the point I have
: been making.  UN*X does _not_ support DIG (unless you count
: curses).  The X _environment_ supports DIG, but *this is not
: part of the OS* it's a toolkit grafted on the side.  Do you
: get it yet?  And X is _hardly_ the example you want to hold up
: as a useful GUI.  It works, but it's not real elegant either
: and it has its own baggage to cart around.  
:

Now that we're talking about it, X doesn't really support DIG in the same
sense as Windows or OS/2.  After all, I can't use X calls to send output
to a printer.

:
: There's a big difference between designing a feature in and
: sticking it on later, but that's another story.  If you could
: see some of the code in the MacOS (Yes I have), you would
: cringe.  Or maybe not.  I'm an aesthete when it comes to
: programming.
:

Me too!  Perfectionist down to the alignment of the last closing brace.
I can't comment on MacOS internals, though, because I've never seen them
(should I be thankful?)

:
: Right.  That doesn't mean every product is well designed or
: thought out.  I still think the PC world would have been
: better off with a new, designed from the ground up with no
: baggage, OS.  The pain involved in the changeover would have
: been great, but I think you would have ended up with a better
: product.  None of the big boys would stick their neck out that
: far, though, and it ain't a job for a two man company...
:

Agreed.

: - MM
--
+-------------------+----------------------------+---------------------------+
| JERRY J. SHEKHEL  | Molecular Simulations Inc. | Time just fades the pages |
| Drummers do it... |     Burlington, MA USA     | in my book of memories.   |
|    ... In rhythm! |        jerry@msi.com       |         -- Guns N' Roses  |
+-------------------+----------------------------+---------------------------+
Newsgroups: comp.sys.amiga.advocacy