home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / os / mswindo / misc / 2530 < prev    next >
Encoding:
Internet Message Format  |  1992-08-30  |  4.5 KB

  1. Path: sparky!uunet!usc!rpi!bu.edu!jade.tufts.edu!news.tufts.edu!news.tufts.edu!tguez
  2. From: tguez@jade.tufts.edu (Name)
  3. Newsgroups: comp.os.ms-windows.misc
  4. Subject: Re: Windows == OS
  5. Message-ID: <TGUEZ.92Aug30225630@jade.tufts.edu>
  6. Date: 31 Aug 92 03:06:38 GMT
  7. References: <197a1eea@p3.f67.n245.z2.fidonet.org>
  8. Sender: news@news.tufts.edu (USENET News System)
  9. Organization: Tufts University - Medford, MA
  10. Lines: 72
  11. In-Reply-To: Martin_Schloeter@eurologic.fido.de's message of 28 Aug 92 07:28:30 GMT
  12.  
  13. >   N > >   makes it an OS, why not just do this:
  14. >   N > >   #define malloc(size) GlobalLock(GlobalAlloc(GMEM_NODISCARD,(size)))
  15. >   N > >
  16. >   N > >        Ta,da!  I turned Windows into an OS with just one #define!
  17. >   N > It's not the five letter combination m-a-l-l-o-c.  Malloc supposedly
  18. >   N > get's memory from DOS.  Now, if ms-windows was an operating
  19. >   N > system,i.e., taking over the system as an operating system and
  20. >   N > releaving dos from it's duties, then it would of been able to juggle
  21. >   N > with malloc memory blocks too.
  22. >   Sigh...
  23. >
  24. >   OK Simply take the MSC Compiler and write a Windows app which use malloc!
  25. >   This 
  26. >   will work! malloc well be automatically translated to the sequence 
  27. >   "LocalAlloc 
  28. >   - LocalLock".
  29. Good, refer back to my arguments that seemed stupid to you-- that
  30. gives me a swift chance to clear my name, the one you tryied so
  31. enthusastically to destroy.
  32.  
  33. The intention I had behind using malloc as an example was to show you
  34. the mess windows is doing to DOS, and this assumed you were keen to
  35. fundamental operating system concepts-- which you turnout to be a
  36. little rusty on-- and in particular the VM concept.
  37.  
  38. If windows was an operating system layered over dos, everything that
  39. happened at it's level and above would be completely under windows
  40. control-- as the defintion goes, the operating system is the ultimate
  41. controller of the underline hardware, and everything under window would
  42. be viewed as the underline hardware.  However, the fact that a malloc
  43. would allocate a memory block and windows is not able to control it
  44. (i.e. windows controls it's memory blocks with management that is
  45. above and beyond DOS's control, and the particular example I was
  46. refering to moving these malloc blocks, which windows cannot, and
  47. actually this malloc call is almost completely invisible to windows,
  48. because one does not use window's primitves here) suggests that
  49. windows is not a layered operating system (because DOS handles the
  50. memory management of the malloc block).
  51.  
  52. The explanation of the argument above (and the argument itself) is
  53. relevant to windows if and only if malloc calls are handled by DOS.  I
  54. had specifically not mention malloc blocks under dos-boxes because
  55. these are virtual dos machines, and hence, windows controls them
  56. (because windows does the virtualization here), this would again make
  57. the argument misplaced (by the way, do not confuse box-dos
  58. virtualization, and the virtulization necessary by dos to support and
  59. windows to bow to, in order to consider windows a layered operating
  60. system).  Since I have not seen any code of either DOS or Windows, and
  61. since it is not specifically mention, in any operating system books I
  62. have read during the time I studied operating systems, how malloc
  63. is really handled and implemented, I have resorted to Petzold's
  64. comment, that windows will swap out an MS-DOS box, and will have to
  65. return this MS-DOS box to the exact location whence it was swap from.
  66. This ment that windows does not virtualizes DOS machines very well (if
  67. it were these DOS-machines could be moved, since the underline
  68. hardware is virtual and can therefore be duplicated else where).  It
  69. also SUGGESTED that windows is not touching any of DOSs memory
  70. management, it leaves that to DOS.  This along with the knowledge that
  71. windows needs dos device-drivers to manage it's own memory (don't jump
  72. on me for this statement, by dos's device-drivers I mean that they are
  73. installed on DOS, and that DOS is the creature that runs them, hence
  74. windows is a slave for this, it needs dos to survive), I decided that
  75. it is highly likely that windows will not dare to touch a malloc
  76. block, and if it did it would die a hurrible death and would cause the
  77. system to enter an unstable state.  
  78.  
  79.  
  80. >   If you write a DOS app with MSC malloc will be translated to "intr( XXX) - 
  81. >   blabla (additional stuff)".
  82. >   malloc-call on whatever OS will ALLWAYS be translated to underlaying memory>    managemant calls. There is no conceptional difference!
  83. Excellent, it is appearnt from you reply that you begin to surface.
  84. >   Martin 
  85.