Newsgroups: comp.os.ms-windows.misc
Subject: Re: Windows == OS
Date: 02 Sep 92  02:16:00 mst

  >If windows was an operating system layered over dos, everything that
  >happened at it's level and above would be completely under windows
  >control-- as the defintion goes, the operating system is the ultimate
  >controller of the underline hardware, and everything under window would
  >be viewed as the underline hardware.  However, the fact that a malloc
  >would allocate a memory block and windows is not able to control it
  >(i.e. windows controls it's memory blocks with management that is
  >above and beyond DOS's control, and the particular example I was
  >refering to moving these malloc blocks, which windows cannot, and
  >actually this malloc call is almost completely invisible to windows,
  >because one does not use window's primitves here) suggests that
  >windows is not a layered operating system (because DOS handles the
  >memory management of the malloc block).

You've been told by any number of people now that Windows is indeed
ultimately responsible for any malloc's incurred by a Windows app or
by a DOS box running under Windows.  Yet you still refuse to believe
us.  You have made lots of accusations that we don't understand or
read your arguments carefully, yet, after being told repeatedly that
Windows does indeed juggle "malloc"ed memory blocks, you still choose
to believe that it doesn't.  You have not provided any evidence to
back up your belief.  The only way I would ever agree with you is if
there was the possibility of running a DOS session that was
independant of Windows, AND running Windows at the same time.  But
this is clearly impossible, because Windows takes control of the
system over from DOS.  Thus, after Windows starts up, it manages all
the memory.

  >The explanation of the argument above (and the argument itself) is
  >relevant to windows if and only if malloc calls are handled by DOS.  I
  >had specifically not mention malloc blocks under dos-boxes because
  >these are virtual dos machines, and hence, windows controls them
  >(because windows does the virtualization here), this would again make
  >the argument misplaced (by the way, do not confuse box-dos
  >virtualization, and the virtulization necessary by dos to support and
  >windows to bow to, in order to consider windows a layered operating
  >system).  Since I have not seen any code of either DOS or Windows, and
  >since it is not specifically mention, in any operating system books I
  >have read during the time I studied operating systems, how malloc
  >is really handled and implemented, I have resorted to Petzold's
  >comment, that windows will swap out an MS-DOS box, and will have to

Ah ha!  You are reading OLD information then, which was relevant to
Windows REAL mode (version 3.0 and versions prior to 3.0).  Time to
upgrade your knowledge.  (Although we've been trying to do that, you
just don't seem to be listening... see above paragraph).

If each DOS box was loaded into fixed locations, then it would be easy
to create more DOS boxes than there are fixed locations... and indeed
it is easy.  Set your PIF settings for your DOS box to only use 128K
memory in the "virtual" DOS box. If you have 4Mb RAM, and the maximum
size swap file, you could have access to 16Mb of virtual memory (16
bit addressing, 4K pages - 16Mb RAM can yield 64Mb virtual memory).
Assuming that Windows uses fixed addresses for the DOS boxes, and
taking the maximum amount of memory that one DOS box can have (1Mb),
then it is reasonable that you could open no more than 16 concurrent
DOS boxes.  Now make the memory requirements smaller... use minimum
memory requirements for the DOS box, say 512K (128K for RAM, 384K for
virtualized hardware address space).  Since fixed addresses must be
assigned on a worst case basis (ie, when the DOS box is 1Mb), then
there would still only be 16 possible locations to put the DOS box,
and thus only 16 DOS boxes could be opened, although they would use
only alf the memory.  This is where your argument falls apart, Tomer.
You can open at least 20 DOS boxes under such conditions.  Try it.
Don't try and bluff me with "theory".  I'm a computer scientist and
have studies operating systems and virtual machine concepts, etc...
obviously you haven't realized that most "theory" about how operating
systems *should* work does NOT apply to DOS.

  >return this MS-DOS box to the exact location whence it was swap from.
  >This ment that windows does not virtualizes DOS machines very well (if
  >it were these DOS-machines could be moved, since the underline
  >hardware is virtual and can therefore be duplicated else where).  It
  >also SUGGESTED that windows is not touching any of DOSs memory
  >management, it leaves that to DOS.  This along with the knowledge that
  >windows needs dos device-drivers to manage it's own memory (don't jump
  >on me for this statement, by dos's device-drivers I mean that they are
  >installed on DOS, and that DOS is the creature that runs them, hence
  >windows is a slave for this, it needs dos to survive), I decided that
  >it is highly likely that windows will not dare to touch a malloc
  >block, and if it did it would die a hurrible death and would cause the
  >system to enter an unstable state.


  >>   If you write a DOS app with MSC malloc will be
  >> translated to "intr( XXX) -
  >>   blabla (additional stuff)".
  >>   malloc-call on whatever OS will ALLWAYS be translated
  >> to underlaying memory>    managemant calls. There is no
  >> conceptional difference!

  >Excellent, it is appearnt from you reply that you begin to surface.

What is this supposed to mean?  All he is saying is that the DOS API
call for malloc is "intr (XXX)...".  The Windows API for malloc is
"GlobalAlloc(XXX)...".  Please note:  GlobalAlloc() does not EVER call
a DOS memory routine.  "intr(XXX)..." and "GlobalAlloc(XXX)" are two
spearate entities and make no use of each other.

-Monroe

 * OLX 2.2 * "The maid has the night off," said Tom helplessly.

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