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

Internet Message Format | 1992-08-26 | 7.6 KB

Path: sparky!uunet!dtix!darwin.sura.net!zaphod.mps.ohio-state.edu!usc!sdd.hp.com!elroy.jpl.nasa.gov!nntp-server.caltech.edu!heathh
From: [e-mail] (Heath Ian Hunnicutt)
Newsgroups: comp.os.ms-windows.misc
Subject: Re: Windows == OS
Message-ID: <[e-mail]>
Date: 27 Aug 92 01:33:32 GMT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: California Institute of Technology, Pasadena
Lines: 131
Nntp-Posting-Host: punisher

[e-mail] (Name) writes:
(someone else wrote:)

>>   Once more "the same old same old", every OS should provide this exact
>>   amount of abstraction.  With Windows you CAN just malloc, Windows
>>   *will* "juggle" with your memory blocks.  How else do you think
>>   virtual memory is implemented?
>Execuse me!!!!  Windows WILL NOT touch your malloc memory blocks,
>and it will sort of juggle with your memory only with near pointers and
>that is also only because you got the same DS value; that is it does
>not play with your memory blocks in relation to your malloc calls, it
>will move your WHOLE program by changing the base address.  Compile
>in the compact or huge models where everything is far and windows will
>die a horrible death if it tried to play with it.
    This is simply not true.  You seem to be very capable of
making wild claims about how Windows works without really knowing
the truth.  In Windows, you can obtain a FAR pointer to a
global memory object, and, still, Windows can move it around
willy-nilly in physical memory via the GDT and LDT.  Furthermore,
your far pointer may well "point" to the swap file, until you
actually try to use it, when Windows swaps your memory back in,
and remaps your far pointer to the appropriate physical memory.
You don't notice the blocks moving (and this is good work on
Windows' part..) because all the changes are made to the GDT and
LDT, not to your far pointers.  When you alloc a chunk of global
memory, windows will move it about freely, regardless of whether
it is "locked" or not.  Windows does not accomplish this by
"moving the whole program and chaning DS", which is what you
claimed.  That is simply wrong.
    Each segment of an executable, whether code, resource,
or data, is considered a seperate global memory object.  At any
time, segments may be swapped out, moved about, or otherwise manipulated
without your program having a clue.  If you jump to a "not-present"
segment, Windows intercepts the processor exception and loads
the appropriate segment.  If you don't use a segment for about 10 seconds,
Windows discards it to make room for other stuff.  That is virtual
memory, my friend.  No question about it.  It is not restricted
by far pointers, as DOS was.
    The problem with large model programs has to do with
the fact that they implicitly assume that each instance is using
the same DGROUP, not that they use far pointers per se.  It is
possible to write large model programs that can have multiple
invocations, but there is no point under windows, where you can
just use globalalloc to provide plenty of memory.  In DOS,
large model would have been neccessary.

>The sort of virtual memory windows provide is a joke compared to
>UNIX's virtual memory (a real OS), where whole processes get swapped
>out, readable and writable memory is swapped out.  Windows has a long
>way to go before real virtual memory support will appear.  AGGGGAIN,
>windows could not do this because it's still a slave for DOS which
>is a sorry execuse for an operating system now days.
    Except that you are wrong.  Windows very definitely swaps
memory (readable and writable) out to the swap file.  It does so
without changing the far pointers that have been set up to reference
that memory.  And when those pointers are dereferenced, Windows
holds up the access while it loads the memory back in, then the
access proceeds with no special programming on the part of the
application.
    DOS has nothing to do with Virtual memory, and never will.
Windows, however, provides virtual memory that is just like UNIX's.
(With the exception of a flat model, which comes from the 386,
not from Windows.)

>>   Your understanding of what an OS should be is terribly limited... you
>>   seem to be using DOS as an example of what a true OS can do.  Most
>>   good DOS apps bypass DOS entirely when needing access to system
>>   resources...  DOS simply loads them into memory and executes them.
>>   All "good" OS's NEVER, NEVER let application programs access the
>>   hardware directly.
>I am sorry Sir, this group is not known for dog-fighting.  If you want
>dog-fighting join some of the discussions in comp.os.windows.advocacy.
    But he's right, darn it.

>WRONG! I don't use DOS as an example of what a true OS CAN do.  I
>highlight things that an opearting system takes care of and show that
>windows is still a child to DOS;  In that DOS is the operating system
>opearting the PC, when you use windows.  I have never presented DOS as
>THE operating system.
    But you are wrong when you say that Windows uses DOS.
Furthermore, you have provided no proof of your claim that Windows
uses DOS, while I can provide proof that it does not.  (Interrupt
traces/logs, or, rather, the relative lack thereof..)

>Let me help you understand that paragraph: without any knowledge of
>how Windows or DOS are actually written (no source code) one must
>improvise.  Someone said that Windows 4.0 is going to introduce
>preemtive multi-tasking.  Another post said that, among other things,
>DOS 6.0 is a mutli-tasking DOS (the exact meaning of which was not
>clear).  Yet another, earlier, post said that MS is preparing DOS 6.0
>for the upcoming WINDOWS 4.0.  If you sit back now, and digest these
>three pieces of information you will see that windows cannot alone
>handle preemtive mutli-tasking (for window's apps), it needs some help
>from DOS, hence windows is NOT an operating system.  Now, again try to
    Wrong.  The DOS 6.0 hooks are to help in pre-empting
DOS APPLICATIONS.  It has nothign to do with how Win 4.0 will
pre-empt Windows apps.

>understand what I write.  I do not mean that multi-tasking equals an
>opearting system.  It should be clear to you that if you try to
>introduce multi-tasking to a non-multi-tasking environment and you
>cannot do it without making the non-mutli-tasking environment
>multi-tasking, you are seriously dependent on this non-multi-tasking
>environment, most likely to an extent of a master-slave
>relationship,i.e., Opearting System-Application.

>If you follow this discussion, as it seems you have, you will
>encounter a post in which someone said that DOS is sort of a
> device-driver" for windows.  So, when I write, "Hence, windows does
>not use DOS as a device-driver after all." I refer back to that to
>show that the concept of is not true, and in this particular example,
>DOS is more than a device-driver for windows.

>>   Huh??? You've never seen the source code, but you know this?  How an
>>   OS multitasks has nothing to do with anything but multitasking.
>You don't have to see the number 123456! to know it exists.  If you
>read carefully the text-books describing the functionally of windows,
>and you know the general mechanics (implementation) of these concepts
>you don't have to see the code.  If I tell you that FORTRAN has no
>stack, you don't need to be told that you cannot do recursion, and if
>I tell you that PROLOG is a declarative language, you would be stupid
>trying to find a for statement in a prolog manual.
    Well, you have drawn the wrong conclusion, as I pointed out
elsewhere, Windows really does switch stacks, as well as active
PSPs.

Aggravatedly,
Heath

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