home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / os / mswindo / misc / 2655 < prev    next >
Encoding:
Internet Message Format  |  1992-09-02  |  6.2 KB
  1. From: Monroe.Thomas@ttlg.UUCP (Monroe Thomas)
  2. Sender: postmaster@ttlg.UUCP
  3. Path: sparky!uunet!elroy.jpl.nasa.gov!usc!sol.ctr.columbia.edu!destroyer!ubc-cs!alberta!ttlg!postmaster
  4. Newsgroups: comp.os.ms-windows.misc
  5. Subject: Re: Windows == OS
  6. Message-ID: <715427454.0@ttlg.ttlg.UUCP>
  7. Date: 02 Sep 92  02:16:00 mst
  8. Lines: 104
  9.  
  10.   >If windows was an operating system layered over dos, everything that
  11.   >happened at it's level and above would be completely under windows
  12.   >control-- as the defintion goes, the operating system is the ultimate
  13.   >controller of the underline hardware, and everything under window would
  14.   >be viewed as the underline hardware.  However, the fact that a malloc
  15.   >would allocate a memory block and windows is not able to control it
  16.   >(i.e. windows controls it's memory blocks with management that is
  17.   >above and beyond DOS's control, and the particular example I was
  18.   >refering to moving these malloc blocks, which windows cannot, and
  19.   >actually this malloc call is almost completely invisible to windows,
  20.   >because one does not use window's primitves here) suggests that
  21.   >windows is not a layered operating system (because DOS handles the
  22.   >memory management of the malloc block).
  23.  
  24. You've been told by any number of people now that Windows is indeed
  25. ultimately responsible for any malloc's incurred by a Windows app or
  26. by a DOS box running under Windows.  Yet you still refuse to believe
  27. us.  You have made lots of accusations that we don't understand or
  28. read your arguments carefully, yet, after being told repeatedly that
  29. Windows does indeed juggle "malloc"ed memory blocks, you still choose
  30. to believe that it doesn't.  You have not provided any evidence to
  31. back up your belief.  The only way I would ever agree with you is if
  32. there was the possibility of running a DOS session that was
  33. independant of Windows, AND running Windows at the same time.  But
  34. this is clearly impossible, because Windows takes control of the
  35. system over from DOS.  Thus, after Windows starts up, it manages all
  36. the memory.
  37.  
  38.   >The explanation of the argument above (and the argument itself) is
  39.   >relevant to windows if and only if malloc calls are handled by DOS.  I
  40.   >had specifically not mention malloc blocks under dos-boxes because
  41.   >these are virtual dos machines, and hence, windows controls them
  42.   >(because windows does the virtualization here), this would again make
  43.   >the argument misplaced (by the way, do not confuse box-dos
  44.   >virtualization, and the virtulization necessary by dos to support and
  45.   >windows to bow to, in order to consider windows a layered operating
  46.   >system).  Since I have not seen any code of either DOS or Windows, and
  47.   >since it is not specifically mention, in any operating system books I
  48.   >have read during the time I studied operating systems, how malloc
  49.   >is really handled and implemented, I have resorted to Petzold's
  50.   >comment, that windows will swap out an MS-DOS box, and will have to
  51.  
  52. Ah ha!  You are reading OLD information then, which was relevant to
  53. Windows REAL mode (version 3.0 and versions prior to 3.0).  Time to
  54. upgrade your knowledge.  (Although we've been trying to do that, you
  55. just don't seem to be listening... see above paragraph).
  56.  
  57. If each DOS box was loaded into fixed locations, then it would be easy
  58. to create more DOS boxes than there are fixed locations... and indeed
  59. it is easy.  Set your PIF settings for your DOS box to only use 128K
  60. memory in the "virtual" DOS box. If you have 4Mb RAM, and the maximum
  61. size swap file, you could have access to 16Mb of virtual memory (16
  62. bit addressing, 4K pages - 16Mb RAM can yield 64Mb virtual memory).
  63. Assuming that Windows uses fixed addresses for the DOS boxes, and
  64. taking the maximum amount of memory that one DOS box can have (1Mb),
  65. then it is reasonable that you could open no more than 16 concurrent
  66. DOS boxes.  Now make the memory requirements smaller... use minimum
  67. memory requirements for the DOS box, say 512K (128K for RAM, 384K for
  68. virtualized hardware address space).  Since fixed addresses must be
  69. assigned on a worst case basis (ie, when the DOS box is 1Mb), then
  70. there would still only be 16 possible locations to put the DOS box,
  71. and thus only 16 DOS boxes could be opened, although they would use
  72. only alf the memory.  This is where your argument falls apart, Tomer.
  73. You can open at least 20 DOS boxes under such conditions.  Try it.
  74. Don't try and bluff me with "theory".  I'm a computer scientist and
  75. have studies operating systems and virtual machine concepts, etc...
  76. obviously you haven't realized that most "theory" about how operating
  77. systems *should* work does NOT apply to DOS.
  78.  
  79.   >return this MS-DOS box to the exact location whence it was swap from.
  80.   >This ment that windows does not virtualizes DOS machines very well (if
  81.   >it were these DOS-machines could be moved, since the underline
  82.   >hardware is virtual and can therefore be duplicated else where).  It
  83.   >also SUGGESTED that windows is not touching any of DOSs memory
  84.   >management, it leaves that to DOS.  This along with the knowledge that
  85.   >windows needs dos device-drivers to manage it's own memory (don't jump
  86.   >on me for this statement, by dos's device-drivers I mean that they are
  87.   >installed on DOS, and that DOS is the creature that runs them, hence
  88.   >windows is a slave for this, it needs dos to survive), I decided that
  89.   >it is highly likely that windows will not dare to touch a malloc
  90.   >block, and if it did it would die a hurrible death and would cause the
  91.   >system to enter an unstable state.
  92.  
  93.  
  94.   >>   If you write a DOS app with MSC malloc will be
  95.   >> translated to "intr( XXX) -
  96.   >>   blabla (additional stuff)".
  97.   >>   malloc-call on whatever OS will ALLWAYS be translated
  98.   >> to underlaying memory>    managemant calls. There is no
  99.   >> conceptional difference!
  100.  
  101.   >Excellent, it is appearnt from you reply that you begin to surface.
  102.  
  103. What is this supposed to mean?  All he is saying is that the DOS API
  104. call for malloc is "intr (XXX)...".  The Windows API for malloc is
  105. "GlobalAlloc(XXX)...".  Please note:  GlobalAlloc() does not EVER call
  106. a DOS memory routine.  "intr(XXX)..." and "GlobalAlloc(XXX)" are two
  107. spearate entities and make no use of each other.
  108.  
  109. -Monroe
  110.  
  111.  * OLX 2.2 * "The maid has the night off," said Tom helplessly.
  112.  
  113.  * Origin: Through the Looking Glass (42:100/14)
  114.