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

Text File | 1992-08-25 | 7.9 KB | 159 lines

Newsgroups: comp.os.ms-windows.misc
Path: sparky!uunet!cs.utexas.edu!sdd.hp.com!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]>
Date: Wed, 26 Aug 1992 04:48:58 GMT
Lines: 146

[e-mail] (Name) writes:

>In article <[e-mail]> [e-mail] (Heath Ian Hunnicutt) writes:

>Well it was my guess that there is something like malloc underneath.
>You put it nicely, "internal abstraction," everythig in windows API
>seemed to be aimed at an "internal abstraction." (I might add that
>they done a pertty good job at that).  However, this is nothing more
>than the definition of over 600 primitives-- My point will be come
>clearer as you read ahead.
    How do you think malloc works, anyway?  It just magically
poofs some memory into existence.  Heck no, GlobalAlloc() works
very much like a standard malloc would, and also much like the
DOS functions for allocating memory blocks.  The only difference
is in the special functionality for protected mode, along with
some tracking of ownership, etc., to keep track of which memory
belongs to whom.
    And, you took my phrase "internal abstraction" out of
context.  What I meant was, since DPMI is part of Windows,
whether GlobalAlloc hacks on the LDT or calls DPMI, memory
allocation is still being handled by windows.
    My point was that Windows makes no calls outside
its own modules when allocating memory. i.e., it does not
pass the request on to DOS.

>>       THE ONLY DOS CALLS THAT WINDOWS MAKES ARE FOR FILE  MANIPULATION.
>>   few things that DOS can do well, and, for the most part, Windows
>>   lets it go ahead and handle that.  (32-bit access is an exception
>>   to this, but DOS is still used to open and close the files.)
>>
>>       Windows intercepts and virtualizes:
>The way the sentence is phrased makes one think that windows
>virtualizes like an operating system virtualizes.  Yet, this is all
>nothing more than a layer of primitives.  You have to use window's
>primitives to fell this "virtualization" try accessing any of these
>things you mention directly and see how much of virtualization windows
>truely provides.
    Ok.  If you directly access the DMA controller under
Windows, you get a GPF.  (This assumes a 386, and enhanced mode,
the only hardware that this is possible with, running under the
appropriate software.)  If, however, you access the UART directly,
and are the first to do so, you will succeed, but an OpenComm on the
same port by another app willl fail.  That is virtualization.
Furthermore, Windows even handles DOS apps doing hardware I/O,
and controls which task gets the access.


>>       Actually, Win 3.1 changes the base address on the hardware
>>   level.  By abandoning real mode, Windows has gained greatly in
>>   memory management abilities.  Now, you can lock that HGLOBAL once, and
>>   use the pointer throughout your App's life.  When you quit, just
>>   unlock it once.  Windows will still be able to juggle your blocks,
>>   it just doesn't have to have your cooperation to do it.
>Once more the same old same old, use window's primitves and you get
>the abstraction, the point is that if windows was a real operating
>system I could use malloc and the operating system could still juggle
>with my memory blocks.

    As I said, Windows 3.1 lets you do this.  If having malloc
makes it an OS, why not just do this:
#define malloc(size) GlobalLock(GlobalAlloc(GMEM_NODISCARD,(size)))

    Ta,da!  I turned Windows into an OS with just one #define!

>>       Well, now there's a weird argument if ever there was one.
>>   If Windows is the only code that can access hardware or memory
>>   directly, at all times, and manages the access of user programs
>>   to hardware and memory, then it is DEFINITELY NOT AN OPERATING
>>   SYSTEM?  And what planet do you hail from, sir?
>You probably mis-understood what I wrote or I did not express myself
>clearly.  The API function, these primitives, hide the hardware and
>help you write software that is a little more distant from the
>hardware for that they are great.  They do a lot of work for you, one
>function call to FillRect stands for many complex lines of code, for
>this also they are great.
    Well, so does the unix _open call.  I rarely make (nor am
I allowed to) system calls or I/Os to the drive array, nor do
I ever open the raw file systems.  Yet, _open is little
more than a function call, which proceeds to issue an interrupt,
trap, sysvect, or whatever to open a file.  How _open works
depends on that OS's API.  Yessiree, all OS's have APIs.
You're just going to have to accept that.   Just because Windows
uses dynamic linking and nice names like GlobalAlloc, doesn't
mean that it is any less an OS than any other OS.
    Furthermore, Windows is more than an OS!  Yes, it
is 300% of an OS.  None of the functions provided in USER
and GDI have much to do with the OS aspects of it.  Yet,
the functions in KERNEL and SYSTEM have all the functionality of
a real OS, except for managing the file system at the hardware level.


>dos application that usually prints something that this is a win
>executable file, and it has a WORD signature some were in the header of DOS
>executable that this is no ordernay DOS app, and then a database is
>attached to the end of this DOS executable.  This database is complex,
>includes resources, tables and more.  This DATABASE is then
>accessed by this DOS APPLICATION we know as the windows's engine, and
>it uses some type of an analog to dos overlays to load the actual
>library into memory (as regualr dos-like functions) and deals with the
>rest of this database,i.e.,resources, import/export tables and all
>that.  Then all these resources MUST be accessed via the
>primitves so widely knows as API functions, and this makes an
>operating system?  If this guess is correct at the core, then windows
>is not much different than DesqView and we have a dos application for
>an operating system.  As you mentioned earlier, "internal
>abstraction," correct internal to the dos application I refer to here
>as window's engine.
    What about the concept of Dynamic linking?  What about
the fact that all functions must be reentrant?  And stop
misquoting my phrase "internal abstraction".  I did not mean
that it was presented to Apps, hence "internal".  I was talking
about DPMI, not the API.
    Also, isn't the event-driven nature of Windows quite a bit
different from DOS?



>How are these function calls deferent than Borland BGI drivers?  You
>register the screen with the initate command and than you use their
>primitives.  Ture windows' API are much much more extensive but that
>does not make it an operating system.
    For one thing, the BGI drivers do not support multiple
applications calling them "at the same time."
    However, as I said before, GDI does not make Windows an
OS.  KERNEL does.  GDI and USER are for the interface, KERNEL
is the OS component.

Finally-
 I seem to have unintentionally deleted your points about how the
Windows scheduling loop is not as OS-like as the one in, for example,
Unix.  You stated that since it doesn't switch stacks, it is not
really multitasking.  Well, I've got news for you:  All apps
have their own stack that the scheduler switches them to before
dispatching them.   They also have their own local heap, their own
data segment, etc.,

If I have misrepresented your views, sorry.  I'd like to quote you,
but my fumble-fingeredness got the better of me.  And if the
point I represented above was something I read somewhere else, and
attributed to you, sorry again.

Heath

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