home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / os / mswindo / misc / 2460 < prev    next >
Encoding:
Internet Message Format  |  1992-08-27  |  3.4 KB
  1. From: Monroe.Thomas@ttlg.UUCP (Monroe Thomas)
  2. Sender: postmaster@ttlg.UUCP
  3. 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
  4. Newsgroups: comp.os.ms-windows.misc
  5. Subject: Re: Windows == OS     2/
  6. Message-ID: <714962865.2@ttlg.ttlg.UUCP>
  7. Date: 27 Aug 92  16:44:12 mst
  8. Lines: 60
  9.  
  10. >>> Continued from previous message
  11.  
  12. Since DOS is not re-entrant, you have to play tricks with memory
  13. addresses to make DOS think its the only thing running.  YOu can't
  14. multitask any other way than preemptively, since DOS doesn't know when
  15. to give up its time slice.
  16.  
  17. Windows programs, up until now, have been based on another paradigm of
  18. mulktitasking, which has proven to be not as good as pre-emptive.
  19. However, each Windows app is its own separate entity, with its own
  20. separate stack and heap.
  21.  
  22. As far as your other comments in another post concerning Dynamic
  23. Linking.  This has nothing to do with DOS overlays, as you suggested,
  24. and again, this comment shows that your knowledge about Windows and
  25. what it does are lacking.  Dynamic linking means that you don't have
  26. to bind in the executable code in the actual executable itself.  You
  27. can make reference to it in another file, and when you call that
  28. function, Windows will use the code in the other file.  This "other
  29. function" has a separate code segment than the caller, and also a
  30. different data segment, although it will share the caller's stack
  31. (necessary, since the DLL may be called by several different callers;
  32. this way the DLL has a separate stack for each different application
  33. that it is a part of).
  34.  
  35. This brings me to your comments about the Windows stack, and how you
  36. believe that all windows apps stacks are just part of the main Windows
  37. "stack".  Again, this is wrong.  Each Windows app has its own
  38. physically separate stack, in a different segment than any stack that
  39. the Windows kernel might use.  If the opposite were true, as you
  40. suggest, then it would be easy for applications to overwrite the
  41. "main" stack and it would be awfully inefficient to monitor this kind
  42. of activity to make sure you didn't violate another applications part
  43. of the stack.  In fact, Windows does trap most illegal writes to parts
  44. of memory that don't belong to a particular process, but it does this
  45. by monitoring the segment selector of any pointer that you have.
  46. Also, think carefully about the structure of memory that Windows uses,
  47. and the maximum size of a segment in Windows: 64K.  If all
  48. applications were to share the same stack then it would be very easy
  49. to exceed the 64K limit very quickly.  In fact, each application's
  50. individual stack can grow to be as large as 64K (theoretically), but
  51. no larger.
  52.  
  53. Which brings me to your point in another post about WinMain.
  54. WinMain's parameters are NOT on the same stack as any "main"
  55. application stack (which doesn't exist).  Rather, there is the use of
  56. "instance thunks" which Windows uses to place the parameters on the
  57. application's stack.
  58.  
  59. You have done a nice job of theorizing about some of the concepts, but
  60. frankly, you are wrong in a lot of your assumptions about what the
  61. functional specs for Windows are.  Again, I point you to the Windows
  62. Resource Kit manual if you wish to gain a true understanding of what's
  63. going on.
  64.  
  65. -Monroe
  66.  
  67.  * OLX 2.2 * "This isn't real turtle soup," said Tom mockingly.
  68.  
  69.  * Origin: Through the Looking Glass (42:100/14)
  70.