From: discar@nosc.mil (Joe Discar)
Subject: Re: Windows 3.1 an "operating system"?
Organization: Naval Ocean Systems Center, San Diego
Date: Sun, 8 Nov 1992 06:06:03 GMT

In article <1992Nov06.215249.9731@donau.et.tudelft.nl> linstee@dutecaj.et.tudelft.nl (Erik van Linstee) writes:
>discar@nosc.mil (Joe Discar) writes:
>
>>In article <1992Nov5.225251.14539@mksol.dseg.ti.com> mccall@mksol.dseg.ti.com (fred j mccall 575-3539) writes:
>>>In <7734@lib.tmc.edu> jmaynard@oac.hsc.uth.tmc.edu (Jay Maynard) writes:
>>>
>>>>In article <1992Nov5.165623.808@mksol.dseg.ti.com> mccall@mksol.dseg.ti.com (fred j mccall 575-3539) writes:
>>>>>In <7714@lib.tmc.edu> jmaynard@oac.hsc.uth.tmc.edu (Jay Maynard) writes:
>>>>>>A neat analogy, Fred, but wrong: what does an OS do that DOS doesn't?
>>>>>Gee, Jay, tell me what definition of 'OS' you're using.  :-)
>>>
>>>>A suite of programs that insulates application code from the necessities of
>>>>dealing directly with the hardware.
>>>
>>>And a reasonable definition it is, too.  Ok.  DOS fails the test
>>>because:
>>>
>>>1) Anything doing graphics pretty much has to go straight to hardware,
>>>the 'insulation' that DOS provides being so worthless.
>>>
>
>>Fred, DOS provides (via the BIOS) functions to switch to graphics modes nad
>>plot pixels on the screen.   The routines are slow and don't work
>
>The BIOS is NOT part of DOS so the rest of your argument is of no
>consequence. In fact, isnt the VGA bios on the device itself?!

Regardless, several texts, DOS Power Tools by Paul Somerson (Bantam Books),
MS-DOS Developer's Guide (Howard Sams & Company) all regard the INT 10
routines as valid "DOS" ways of accessing the video card.

Being able to use the BIOS to perform a task does not invalidate the
operating system's compliance with an "OS definition."  If this were true,
OS/2 2.0 (indeed *any* PC based operating system) would not be an
"operating system."

Why?  Because *all* of them use the BIOS--if only just to boot from the
hard disk.  This is *part* of the PC-architecture.

>
>>(naturally) with graphics modes that came out AFTER DOS's/BIOS design.
>>But from a realistic standpoint, it can't been expected that ALL hardware
>>will be supported by an OS.  Take for example my Lantastic network card--
>>it doesn't work under OS/2 under any circumstances (even if I try to use
>>a generic NE2000 driver).  Does this mean OS/2 is not an operating 
>>system?  No... of course not, it means my network card is not
>>quite a standard.
>
>Remember the OS is not required to manage every piece of harware,
>but if a piece of hardware is to be managed, it is to by done
>by the OS.
>
Fildercarb.  The BIOS is *part* of DOS... as much as a V6 is *part* of the
Truck my father drives.  It is not necessary that every layer in an
operating system is "blind" to only the layer directly below it (in modern
times, such abstraction is good design--but it is far from necessary).
Are you saying that, for example, if you as a programmer needed to write
a character to the screen, you should write your own video driver?  Of
course not.


>
>>>2) Accessing upper memory.  DOS is so braindead that it requires
>>>'extenders' to get outside 640k.  So much for 'insulation' on
>>>management of the majority of memory on the machine.
>>>
>
>>So, there is no requirement for an OS to be able to access ALL of memory
>>(various operating systems running in a VM can't).  
>
>>Again, if you could find such a requirement, cite a bibliographical
>>reference and I'll get off your back.
>
>>>Shall I continue?  ;-)
>>>
>>>-- 
>>>"Insisting on perfect safety is for people who don't have the balls to live
>>> in the real world."   -- Mary Shafer, NASA Ames Dryden
>>>------------------------------------------------------------------------------
>>>Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.
>-- 
>Erik van Linstee   |   Delft University of Technology   |   I'll be back ... 
>----
>   We are god, 'cause only we can create the idea of his existence
>   in our holy brains...  (Yello)


Newsgroups: comp.os.os2.advocacy