home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / os / mswindo / misc / 2486 < prev    next >
Encoding:
Internet Message Format  |  1992-08-29  |  5.1 KB
  1. Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!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     2/
  5. Message-ID: <TGUEZ.92Aug28151952@jade.tufts.edu>
  6. Date: 28 Aug 92 19:30:01 GMT
  7. References: <714962865.2@ttlg.ttlg.UUCP>
  8. Sender: news@news.tufts.edu (USENET News System)
  9. Organization: Tufts University - Medford, MA
  10. Lines: 86
  11. In-Reply-To: Monroe.Thomas@ttlg.UUCP's message of 27 Aug 92 23:44:12 GMT
  12.  
  13. >   Since DOS is not re-entrant, you have to play tricks with memory
  14. >   addresses to make DOS think its the only thing running.  YOu can't
  15. >   multitask any other way than preemptively, since DOS doesn't know when
  16. >   to give up its time slice.
  17. Exactly refer to diagrams (earlier posts) and this is an argument
  18. against widows being an operating system.  I could explain if it is
  19. needed, but the way windows sends hooks into terratories not it's it
  20. breaking the rules, another quote from a conversation:
  21.  
  22. >   Windows programs, up until now, have been based on another paradigm of
  23. >   mulktitasking, which has proven to be not as good as pre-emptive.
  24. That was known a head of time.
  25. >   However, each Windows app is its own separate entity, with its own
  26. >   separate stack and heap.
  27.  
  28.  
  29. >   As far as your other comments in another post concerning Dynamic
  30. >   Linking.  This has nothing to do with DOS overlays, as you suggested,
  31. >   and again, this comment shows that your knowledge about Windows and
  32. >   what it does are lacking.  Dynamic linking means that you don't
  33. >   have
  34. Correct my knowledge about the specific implementation of windows is
  35. limited to the literature available-  MS does not release the source
  36. code, if there is anyone to blame it's MS.
  37. >   to bind in the executable code in the actual executable itself.  You
  38. >   can make reference to it in another file, and when you call that
  39. >   function, Windows will use the code in the other file.  This
  40. >   "other
  41. This is very easy to do if you view windows as an application that can
  42. dynamically link object libraries, and then obviously linking ten of
  43. the same object libraries will leave only one copy in memory.
  44. Windows, then, looks more like an advanced dos applciation, and then
  45. my suggestion was that as a dos app it could very well implement
  46. dynamic linking by taking overlays (which are a part of dos, built
  47. in, this is a fact) make these fixes windows does and enhance this
  48. mechanism so it looks nice and smooth.  At any event, let's discard
  49. specifics and look at the things abstractly with concepts in mind and
  50. not blends of concepts as the posts.
  51. >   function" has a separate code segment than the caller, and also a
  52. >
  53. >  different data segment, although it will share the caller's stack
  54. > (necessary, since the DLL may be called by several different callers;
  55. >this way the DLL has a separate stack for each different application
  56. >   that it is a part of).
  57.  
  58. >   This brings me to your comments about the Windows stack, and how you
  59. >   believe that all windows apps stacks are just part of the main Windows
  60. >   "stack".  Again, this is wrong.  Each Windows app has its own
  61. >   physically separate stack, in a different segment than any stack that
  62. >  the Windows kernel might use.  If the opposite were true, as you
  63. >   suggest, then it would be easy for applications to overwrite the
  64. >   "main" stack and it would be awfully inefficient to monitor this kind
  65. >   of activity to make sure you didn't violate another applications part
  66. >   of the stack.  In fact, Windows does trap most illegal writes to parts
  67. >   of memory that don't belong to a particular process, but it does this
  68. >   by monitoring the segment selector of any pointer that you have.
  69. >   Also, think carefully about the structure of memory that Windows uses,
  70. >   and the maximum size of a segment in Windows: 64K.  If all
  71. >   applications were to share the same stack then it would be very easy
  72. >   to exceed the 64K limit very quickly.  In fact, each application's
  73. >   individual stack can grow to be as large as 64K (theoretically), but
  74. >   no larger.
  75.  
  76.  >  Which brings me to your point in another post about WinMain.
  77. >   WinMain's parameters are NOT on the same stack as any "main"
  78. >   application stack (which doesn't exist).  Rather, there is the use of
  79. >   "instance thunks" which Windows uses to place the parameters on the
  80. >   application's stack.
  81.  
  82. >  You have done a nice job of theorizing about some of the concepts, but
  83. >   frankly, you are wrong in a lot of your assumptions about what the
  84. >   functional specs for Windows are. 
  85. I agree with you!!!
  86. >   Resource Kit manual if you wish to gain a true understanding of what's
  87. >   going on.
  88.  
  89. I am having an extremely successful email conversation with
  90. raymondc@microsoft.com I think everyone would be very interested to
  91. join and observe, this is the sort of converstion I ment to have.
  92. Therefore, the next post I will take all the emails I sent him and the
  93. ones he replied and all the followups between us put them into a file
  94. and post them.  Then we'll move this discussion to posting.
  95.  
  96.  
  97. Simling even more,
  98. Tomer
  99.