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

Internet Message Format | 1992-08-27 | 9.2 KB

From: [e-mail] (Monroe Thomas)
Sender: [e-mail]
Path: sparky!uunet!cs.utexas.edu!sdd.hp.com!wupost!usc!sol.ctr.columbia.edu!destroyer!ubc-cs!unixg.ubc.ca!kakwa.ucs.ualberta.ca!alberta!ttlg!postmaster
Newsgroups: comp.os.ms-windows.misc
Subject: Re: Windows == OS     1/
Message-ID: <[e-mail]>
Date: 27 Aug 92  16:44:10 mst
Lines: 150

  >>   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.

Not true!  I do this everyday in my Windows programming - and I work
exculsivley in large model - everything is far.  I can malloc huge
amounts of memory, all with different DS values.  Windows juggles them
just fine.  See, the pointer you get from Windows when you malloc is
not a pointer to a physical chunk of memory... instead of the
segment:offset you get with DOS, you get a segment_selector:offset
pointer.  This is "virtualization", as you are using the term.  Since
Windows maintains a table that converts the segment selector to the
actual physical segment, Windows can "move" segments around at will,
without ever invalidating your pointers.  Just like Unix.  I ask
again, how the heck else do you implement virtaul memory???  And
Windows certainly has virtual memory.

NA>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.

I agree with your commentary about DOS.  I completely disagree with
your opinions on Windows virtual memory... and it seems you don't have
a good idea how virtual memory works in either Windows or Unix.  In
either case, memory is divided up into "pages".  If a process in
either Windows or Unix makes a reference to a page that isn't
currently in physical memory, then the OS gets that page from disk,
and determines which was the least recently used (or similar
technique) for determining which page should be swapped from physical
memory to disk.  Your idea that Unix swaps "whole" processes and all
their associated memory out is simply incorrect.  It only swaps what
it needs to, which can be any page, containing either code or data for
any process.  And it is unlikely that a whole process's code or data
will be in one page, since pages usually come in 4K sizes.  So at any
given time, in either Windows or Unix, it is highly unlikely that if
there are several processes running that any one process has all of
its memory in physical memory at one time, or that any one process is
entirely swapped out.  I do agree that Windows VM is not as fast as on
Unix, because VM requires disk access, and remember that Windows must
still use DOS (the only portion of DOS that it uses) for some disk
operations.  As documented in the WIndows Resource Kit manual, the
virtual memory scheme is virtually the same as any VM scheme on Unix.
(ie, based on modified LRU algorithm for paged memory).

Tomer, I *highly* recommend that you read the WIndows Resource Kit
manual for Windows 3.1, and you will find that a lot of your
assumptions about how Windows operates are incorrect.

  >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.

Hmmm... you are partly right here. Windows is a child of DOS in that
it needs DOS to boot the system up.  After Windows is run, though, it
takes over *all* operating system services *except* for some file
management services.  DOS has nothing to do with the way Windows
manages memory or resources, except for some parts of the file system.
Thus, the original argument, which was "is Windows 90% of an OS", is
essentially correct.  You must understand, Tomer, that since DOS is
not re-entrant, it cannot be responsible for a lot of the things that
Windows does.  Windows does *not* pass on any OS responsiblities
through "layers" back to DOS, except for file opening and closing.
Thus, DOS is no longer operating the PC when you use Windows.
Honestly.  Windows takes full control away from DOS.

  >>   Again, it is woefully apparent that you don't grasp what operating
  >>   systems are all about.  That's OK... lots of people use OS's without
  >>   understanding them.  Just because I use a car doesn't mean that I'm an
  >>   expert on internal combustion engines.
  >English is not my native tongue, and I have been using it on
  >day-to-day basis for only two years.  Therefore, I may use the wrong
  >words or I may grammatically structure a sentense that would be more
  >transparent otherwise.  You should, therefore, pay much more attention to
  >the essence of the argument than it's surface appearance.

You are doing very well with your English.  Keep it up!

  >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
  >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.

I think you have taken the pieces and synthesized them incorrectly,
Tomer.  Or rather, you were given misleading peices to work with.
Improvising does not mean just guessing and hoping that you are
correct.  And one deosn't need the source code to know how something
works.  Since I DO know something about Windows internals, I can quite
confidently say that Windows does not use DOS as a device driver.  The
ONLY thing that Windows uses DOS for is to achieve a system boot-up,
and for some file management.

Also, some of your assumptions about what DOS 6.0 is capable of are
incorrect.  DOS 6.0 will NOT be multitasking.  There are, supposedly,
hooks in place for multithreaded execution of a single process.  Also,
some of the disk/file access routines are being re-written to support
I/O in a multitasking environ.  This means that Windows 4.0 will
probably contoinue to rely on DOS for some file management facilities.

  >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.

  >>     >> So what if it is?  That is a lot like what UNIX does, too.
  >>     >>   Windows also provides for interprocess communication, device
  >>     >>   sharing, serialization of input, virtualization of all hardware,
  >>     >>   file locking and sharing, true preemptive multitasking with DOS
  >>     >>   boxes in enhanced mode.
  >>     >Noooo, unix plays with the stack and does context switches and all
  >>     >sorts of things.  You see if the loop outlined above is a good guess
  >>     >of what's happending (again, never seen the source code), then the
  >>     >function WinMain uses the same stack as the calling program (simple
  >>     >function call).  Hence, in order to introduce preemptive multi-tasking
  >>     >there should be some arrangement to make a copy of the stack, and hold
  >>     >a few stocks in memory and switch between them and take care of PCLBs
  >>     >and all sorts of things that windows does for DOS apps but not for
  >>     >windows apps.
>>> Continued to next message

 * OLX 2.2 * "This isn't real turtle soup," said Tom mockingly.

 * Origin: Through the Looking Glass (42:100/14)