🚀 go-pugleaf

In article <1990Sep8.134722.4843@techbook.com>, fzsitvay@techbook.com (Frank Zsitvay) writes:
> 
>    Microsoft is one of those companies that knows a buck when they see it,
> and will do almost anything to sell their operating system, including
> allowing the hardware manufacturer to tailor the operating system to
> the hardware, instead of doing it all in the BIOS.   (there are some
> arguements in favor of this sort of thing, but i don't want to get into
> that.

I think relatively few manufacturers modify the MSDOS.SYS file (or
whatever they choose to call it - IBM calls it the IBMDOS.SYS file)
very much.  The IO.SYS file (what IBM calls IBMBIO.SYS) is another
story - strictly speaking, that IS the BIOS for the machine.  I don't
know of any machine that directly wires into the ROM-BIOS;  one of
the problems is that in this case you have problems if a version of
the ROM-BIOS has serious bugs:  it's much cheaper to make IO.SYS a
bit bigger and move the function into there, rather than replacing
the ROMs.

Most manufacturers just call the ROM-BIOS from _most_ of the IO.SYS
calls, but this is hardly necessary;  you could do everything in
IO.SYS and not have any ROM-BIOS functions at all.

>    Something that is quite common is mapping the interrupts physically 
> differentthan in the original ibm, and rerouting the interrupts in the
> operating system so that everything works fine as long as you use that
> custom version of dos in that machine.   i don't understand there to be
> any technical advantage to doing this, but some manufacturers want to be
> different. 

Actually, IBM screwed up big time when they designed their ROM-BIOS:
they ignored the big type in the Intel spec sheets for the 8086/8088
that said that interrupts 1 through 1F were RESERVED TO INTEL for
future enhancement of the 80x86 chip family.  That's why the MS-DOS
interrupts start at 20h;  a well-behaved ROM-BIOS for the 80x86 chip
family should start at, say, 30h or 40h (leaving the ones from 20h
to 2Fh or 3Fh to the OS).  Or perhaps the entire structure should
have been moved up to allow interrupts from 20h-3Fh to be used for 
devices; any number of things would have been better than what we
got.  For example, when the AT first came out there were quite a few
gyrations required to allow the BIOS to coexist with an 80286, and
it still causes a lot of unnecessary complications in the BIOS to
have to figure out whether it's getting a program request or some
kind of machine check when one of the 00h-1Fh interrupt calls is
made.  In fact IBM themselves had to revector some of the interrupts
in this case to make the whole Rube Goldberg contraption work.  I 
can well understand why a manufacturer might want to do it the 
"right" way;  in a number of ways it results in a simpler and
cleaner design.  It also just happens to be incompatible with the
Revealed Truth from a certain large multinational company.

>    and of course there are those companies that some time ago marketed semi-
> compatible machines, like DEC's Rainbow, which i consider to be one of the
> "left feild" orphans.   not only is the interrupt structure screwy, or the
> floppy disk format screwy, or the bios screwy (IT HAS NONE!!!), but it
> runs a funny version of the operating system as well.  (a bastard mod of
> dos 3.1, which packs along its own bios on disk.) I really shouldn't slam the
> rainbow as much as i do (i'm using one to write this) because it does have
> its good points.   (when chkdsk reports 800k ram free, i still snicker at
> those stuck with less that 600k free.)

The Rainbow, as it turns out, does have a BIOS that programs can call
(I know, I've written quite a bit of code for it);  it's just that
it's completely incompatible with the IBM BIOS.  The modification of
MS-DOS 3.1 that you are referring to was done by Suitable Solutions,
not by DEC, and was never marketed by DEC (they never sold anything
beyond 2.11),  and it's not really a very screwy version.  It's pretty
much a vanilla MS-DOS 3.1 with an IO.SYS for the Rainbow.  Naturally,
since the BIOS and hardware for the Rainbow isn't PC-compatible, you
often have trouble running PC programs on it, which are often ill-
behaved about the way they manipulate machine resources, often 
preferring to access the hardware directly rather than use standard
OS calls.  (DEC's non-support of the Rainbow - in particular its
refusal to bring out even DOS 3.1 for the Rainbow - turned a LOT of
people off ever getting involved with DEC PC's again).

The unfortunate thing here is that too often, because of the way 
Microsoft and IBM did things in DOS and on the PC, too many functions -
video and comm hardware in particular - have either pretty slow or 
inadequate support in the OS, tempting or even forcing software houses
to bypass the OS to use them.  Some programs are even worse though - 
like doing direct I/O to the disk, a VERY dangerous thing to do since 
it leaves you open to breaking even with a new version of DOS, let 
alone on "orphan machines".

It's too bad that there have been so many design problems with the
MS-DOS system and with the PC architecture;  it's certainly causing
the microcomputer industry fits trying to deal with the next
generation of hardware and software coming down the pike.  Just
consider the problems Microsoft is having getting the DOS compati-
bility box to work for OS/2;  it really shouldn't have been necessary
to go to that much trouble if things had been done right from the
start.

The PC industry is in danger of getting run over by the low-cost
RISC workstations that will be coming out over the next year or
two;  they don't have quite so much software entropy that they have 
to drag along with them, and could very well be able to adapt to
the new technologies much better and faster than the PC will be
able to do.

As the Chinese curse goes, we live in interesting times.

						Bruce C. Wright