NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/os/mswindo/misc/2476

Text File | 1992-08-29 | 13.5 KB | 281 lines

Newsgroups: comp.os.ms-windows.misc
Path: sparky!uunet!stanford.edu!ames!elroy.jpl.nasa.gov!nntp-server.caltech.edu!heathh
From: [e-mail] (Heath Ian Hunnicutt)
Subject: Re: Windows == OS
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: punisher
Organization: California Institute of Technology, Pasadena
References: <[e-mail]> <[e-mail]>     <[e-mail]>     <[e-mail]>     <[e-mail]>     <[e-mail]>     <[e-mail]> <[e-mail]>
Date: Fri, 28 Aug 1992 16:55:18 GMT
Lines: 268

[e-mail] (Name) writes:

>It does not matter how I installed QEMM (as long as it works),
>and if it is anyone's fault that it is not installed properly,
>it's the installation program's fault.  Have I used emm, and it
>would have informed windows that there was a problem and windows
>would of consequently displayed a dialog box is of no material
>here.  It does not matter who informs the user of the error, it
>is important who takes care of things.  If window's would of
>displayed dialog boxes, and qemm or emm would of never display
>the error themselves, then I would have no argument, but that
>would only credit windows with a good job at hiding, not
>managing things.
    Well it does matter.  The way you have QEMM installed
has caused it to keep control of exception handling.  Once Windows
loads, exception handling is Windows' duty.  Emm does not "inform"
windows of anything, as you state above.  In fact, Windows intercepts
the interrupts (aka exceptions) generated by the processor in the
event of various system errors.  QEMM should relinquish those
interrupts, but apparently does not.
    Windows DOES display the type of dialog that you wish it
would, but only if you have your system software properly installed.
EMM386.EXE does not "hold Windows' hand" as you imply above.


>Clearly, you seem to miss the point every time.  It is not
    Oh, really?
>argued that windows does not take care of memory management for
>it's environment, it is argued that windows does not take care
>of system-wide memory management-- as an operating system should.
    Well, then why did YOU start the argument about whether
Windows supported a nice, easy-to-use malloc().  I guess once
enough people pointed out that Windows does support this, you
had to change your tack again.
    And, what do you mean by system-wide?  For your info,
if a DOS box malloc()s memory, it really gets it as a result of
Windows handling the request, not as a result of any DOS code
swinging into action.


>Your response to the virtual machines paragraph clearly shows
>that you have absolutely no idea what virtual machines are.
    Oh, bull. Your response in this post clearly shows
that you have absolutely no ideas left to discuss on this
subject.

>Therefore, let me teach you a little about them:
    Ha, ha, ha.

>Conceptually a computer system is made up of layers.  The
>hardware is the lowest level.  The kernel running at the next
>level utilizes the hardware to create a set of system calls to
>be used by higher layers (this is operating system APIs).  The
    And this is what the KERNEL.DLL module does in Windows,
along with SYSTEM.DRV.  These two programs together manage
the processor, memory, hardware I/O, in other words, all the
resources of the computer.  They also provide an API for the
higher level modules and programs.

>system programs are the next level, above the kernel, and are
>allowed to use either system calls or hardware calls to enrich
>the set of system APIs.  There is a vague line between system
>programs API and the kernel's API, and sometimes there is no
>telling apart.  System programs view the hardware and kernel
>calls as if they were at the same level-- kernel functions are
>thought to bootstrap the hardware.  On some systems this is
    Actually, my PC boots from a ROM program, I don't know
about yours.

>carried even further, and application programs are allowed to
>make system calls.  The application views everything underneath
>it in this hierarchy as though it is apart of the machine itself.
    Whoa!  So you say that all real OS's will not provide
APIs such as OpenComm()?  I guess that would be too abstract and
clean for a real OS, huh?  It sure will be smart when all the
programs you write that go directly to I/O port 2F8h have to be
ported.  Good thing you did't use OpenComm(), huh?  For the
record, Unix does not do the sort of thing you seem expect.  If
I go straight to the hardware in UNIX, I get a BUS ERROR.  OS/2
wouldn't hear of your 'clever' idea, either.
    A good OS _abstracts_ the hardware so that applications
don't have to jump through hoops to use it.  In DOS, apps jumped
through a lot of hoops.  In Windows, we just call OpenComm(), and
we are happy as bugs in rugs.


>The logical extension of this approach, and also the conclusion
>of this approach is reached in the concept of virtual machines.
>The development of CPU scheduling algorithms and virtual-memory
>techniques made it possible for an operating system to create
>the illusion of multiple processes.  This virtual machine
>concept does not provide any additional functionally, it
>provides multiple, identical virtual copies of the bare
>underlying hardware.  Virtual machines are obliged, by their
>nature and concept, to support virtual disk-drives, virtual
>printers (otherwise known as spooling) and (even) virtual tape
    Well, that's nice in theory, but what if two machines try
to hit the tape drive at once?  Windows prevents this, as it
obviously makes no sense.  What would your wonderful OS do?  Have
scotty beam down another tape drive?

>drivers.  A process or a user that is given a virtual machine
>can run any software that is available to the underline machine.
>On the VM operating system (which I mistook for the CP/M, in an
>earlier post) , which IBM wrote, the user would typically run a
>single-user operating system, I think it's the CMS operating
>system
    Just because you have experience with one operating system
does not make you an expert at OS's in general.  I have written
programs under Windows, OS/2, DOS, UNIX (many flavors), and VMS.
I have no trouble saying that Windows is 90% of an OS, needing
only its own file system.

>  Yes, here you have a classical scenario of an operating
>system nested within an operating system.  However, notice that
    Ah, yes.  I had forgotten that example from my CS classes.
*snicker*

>the inner operating system does not depend on the services of
>the outer operating system, it does not even know of it's
>existence-- long way from DOS/Windows relationship.  I would
    Once again, the only services Windows uses from DOS
is for file operations.  Even direct access to the harddrive is
managed by Windows.

>love to go an and explain to you these concepts but I really
>would rather spend my time more productively.
    Well, that's Ok, anyway.



>I have tried very hard to keep away from these formal discussions and
>to bring out examples that would clearly imply a sort of DOS/Windows
>dependency that is not consistent with a true operating system.
>However, you have repeatedly misunderstood my simple and subtle
>arguments for ignorant arguments and pulled my tongue by the low use
>of personal remarks.  If you still don't get the picture, then I feel
>very sorry for you.  Simple windows reactions could easily shoot it
>down as an operating system, as Erike van Linstee
>([e-mail]) put one example, "Ever hear of an OS
>you can quit and still have a functioning machine?!"
    Yes, it is called "Windows."  Then again, ever hear of a non-OS
that runs the processor in a special mode, loads programs in a unique
format, virtualizes hardware, and serializes input, along with
managing memory, cpu time, and I/O access to peripherals?  Nope, me
neither.


>MS-DOS is one of those operating system that started as a small,
>simple and limited system, and is know in the mids of growing beyond
>it's intendent scope.  Although MS-DOS has some structure, it's level
>of functionality are not well separated:
    You think DOS is an OS, but Windows is not?  You really are
crazy.

>This how window seems to look like:
                 ^^^^^ Well, we all know how much you know about
Windows' internals, without having any real reason for your
beliefs.

>        +=============== Some Larger Frame =================+
>        |                        |                          |
>        | +--------------------+ | +----------------------+ |
>        | | applications (dos) | | | Windows Applications | |
>        | +--------------------+ | +----------------------+ |
>        |                        |                          |
>        +------------------------+==========================+
>                   |             |     Window's Engine      |
>                   |             +--------------------------+
>                   |             |   Kernel   |   memory    |
>                   |             | device man | management  |
>+--------------------------------+--------------------------+
>|     application program        | window's device drivers**|
>+--------------------------------+==========================+
>|                    command  interpreters                  |
>+-----------------------------------------------------------+
>      |            |          |       |    |
>      +------------+----------+-------+    | * Notice the
>      |                       |            | soup between DOS
>+--------------------------+  |            | device drivers
>| resident system program  |  |            | and window's
>+--------------------------+  |            | device drivers
>      |      |           |    |            |
>      |      |           |    |            |
>+----------------+       |    |            |
>| MS-DOS device  |       |    |            |
>|   drivers      |       |    |            |
>+----------------+       |    |            |
>      |      |           |    |            |
>+----------------------------------------------+
>|           ROM BIOS device drivers            |
>+----------------------------------------------+

    First,  DOS apps running in Windows do not make direct calls
to DOS, as Windows has to fix up the memory references.  How do
you think you can have more than one DOS machine running, and each thinks
it is in memory lower than 1MB?
    Second, the command interpreter is not involved.  I sometimes
boot straight to Windows without using COMMAND.COM to do so.  There
is no need for COMMAND.COM to be loaded.
    Third, Windows cannot call the BIOS because most BIOSes are
not written to be called from protected mode.  So, Windows must
either convert all calls to real mode, or emulate the BIOS.  Often,
it just emulates the BIOS.
    Fourth, a DOS application cannot be running "under" windows.
If you are referring to a TSR or something, lump that into the
device driver category.

>MS-DOS is not structured well, and windows sorts
>of expands,replaces,intervines, completes, layers
>and integrates into DOS.  DOS is still the dominant
>operating system at all times.  Windows looks more
>like a shell that breaks the rules and does things
>that it should not than an operating system.
    How do YOU know that DOS is always dominant?  You keep making
these wild claims that imply you understand how Windows works.  I don't
think you have a clue.

>I'll tell you what.  I could go over the acceptible definitons of an
>operating systems but arguing with you is really hopeless.  Since you
>are soooo concerned to get an absolute decision if windows is or is
>not an operating system rather then exploring the holes and the
>inconsistency each view creates, I'll just destroy this silley view
>now:
    If you would like to learn about OS's go read a book.  I have
sufficient experience to know one when I see one.  (And yes, I've
read the books, too.)  I have never been "soo concerned about an
absolute decision" either.  I have said from the start the Windows is
90% and OS, and I intend to stick to that.  I would like to destory
your silly view that you have psychic powers of disassembly that allow
you to make broad statements about how Windows works.

>Bare hardware alone is nothing, it's like a human body with all the
>integral parts except the nerves to connect them all.  An operating
>system alone performs no useful function by itself (io.sys, and
>bios.sys without command.com, clearer now?).  An operating system can
    I don't use command.com, even when I'm at the DOS prompt.
Your point, however, is taken.  You just needn't be so condescending
to people who know more than you.

>also be viewed as a resource allocator, allocates resources to programs
>(memory for command.com, for instance).  There is no universally
>accepted defintion of what is a part of the operating system or not.
>However, there is one thing that appears in absolutely every operating
>system, and this single thing logically follows from any single statement
>about an opearting system.  I'll use simple words, now, so you'll be
>sure to understand:

>An operating system is the one program running at all times on the
>computer, with all else being programs.
    Well, since Windows supplants all of bios.sys, and all of
io.sys other than the file handling stuff, what OS is running
when I run Windows?
    I think you are wrong. I can start a new OS after
boot-time and still have it be an OS.  Even your friend DOS
has to be loaded by the ROM...


>Entertained,
>Tomer

Might I suggest a duel?  :)

Heath

--
On Saturday, April 18, 1992, this .sig became self-aware.