Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!amdahl!drivax!cavender
From: cavender@drivax.UUCP
Newsgroups: comp.os.minix
Subject: Re: First Impressions of Minix
Message-ID: <1267@drivax.UUCP>
Date: Thu, 16-Apr-87 10:12:33 EST
Article-I.D.: drivax.1267
Posted: Thu Apr 16 10:12:33 1987
Date-Received: Sat, 18-Apr-87 04:36:02 EST
References: <288@grebyn.COM>
Reply-To: cavender@drivax.UUCP (Steve Cavender)
Organization: Digital Research, Monterey
Lines: 67

In article <288@grebyn.COM> bob@grebyn.COM (Robert A. Baumann) writes:
>Well, I've gotten the executable files and had a chance to play.  I
>am, in a word, disappointed.

OK so far.  In reading the accompanying textbook "Operating Systems: Design
and Implementation" I've learned quite a bit about design considerations and
compromises made by AST to keep things simple.  Even though I haven't received
the disks yet, I know quite a lot about what to expect from the system when it
does arrive.  I'm looking forward to studying Minix and tinkering with it.  I'm
not planning on receiving a production multitasking system, with uucp, or X
windows, etc. for $80.

>The basic problem is that the thing is too closely tied to the
>hardware.  There's no good reason to bypass the BIOS for everything.

Hold on.  Here comes trouble.  There's at least one good reason to bypass
the BIOS for everything, and boy is it GOOD.  Minix is a multitasking system,
while the BIOS is simply polled about most operations.  Yes, interrupts are
used in a few places, but those interrupts are not communicated to a higher
level than the BIOS itself.  If you used the BIOS for the keyboard, for
instance, the keypresses are buffered up by the BIOS, and you would not be
able to interrupt an application any better than you can under MS-DOS, which
is a real problem.

>Specifically, MINIX goes straight to the screen.  This is fine, when
>you do it right.  But MINIX doesn't, so MONO and EGA screens get
>garbaged in odd ways. 
...

The correct solution here is not "Use the BIOS" but "Write a more correct
video driver".  It's been done before.  There's no mystical power the BIOS has
that can't be duplicated in a real device driver for an MT system.

...
>Due to this low-level implementation, you can't use any of the
>thousands of DOS device drivers (like for my Bernoulli box, my custom
>clock chip, etc).  I'm not impressed by a so-called operating system
>that has to be recompiled to move from my XT to my XT + Bernoulli
>system.

The same problem with the BIOS applies to loadable device drivers written for
MS-DOS.  Yes, I know that they have a "strategy" entry point and an "interrupt"
entry point, but they still haven't been designed or built for an MT system.

>What to do?  I have scoped the effort needed to convert MINIX to
>something useful viv-a-vis the rest of the PC world.  This includes
>supporting DOS device drivers first and foremost, and handling the ...
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  good luck

...
>Weigh the plusses against the minuses, and in my opinion it's not
>worth spending any more hours on MINIX.  It's neat as a teaching tool
>(if you take lots of the DOS stuff with a grain of salt), but I've got
>real work to do. I'll stick with DOS.

OK, fine.

>  - Bob Baumann
>-- 
>Robert A. Baumann, CCP, CDP		{decuac, seismo}!grebyn!bob

-- 
Steve Cavender  Digital Research, Inc.|(My opinions.  You can't have them.)
USENET:    cavender@drivax.UUCP       |"The size of the FAT for a 128 giga-
Telex:     9102406616 TAG SEMI SEA UQ |byte disk is unpleasant to contem-
EasyLink:  62211010                   |plate." -- Andrew S. Tanenbaum