home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / os / mswindo / misc / 2496 < prev    next >
Encoding:
Internet Message Format  |  1992-08-29  |  4.8 KB
  1. Path: sparky!uunet!olivea!decwrl!access.usask.ca!kakwa.ucs.ualberta.ca!alberta!ttlg!postmaster
  2. From: Monroe.Thomas@ttlg.UUCP (Monroe Thomas)
  3. Newsgroups: comp.os.ms-windows.misc
  4. Subject: Re: Windows == OS
  5. Message-ID: <715053988.1@ttlg.ttlg.UUCP>
  6. Date: 29 Aug 92 02:05:02 GMT
  7. Sender: postmaster@ttlg.UUCP
  8. Lines: 87
  9.  
  10. NA>>   Since DOS is not re-entrant, you have to play tricks with memory
  11.   >>   addresses to make DOS think its the only thing running.  YOu can't
  12.   >>   multitask any other way than preemptively, since DOS doesn't know when
  13.   >>   to give up its time slice.
  14.   >Exactly refer to diagrams (earlier posts) and this is an argument
  15.   >against widows being an operating system.  I could explain if it is
  16.   >needed, but the way windows sends hooks into terratories not it's it
  17.   >breaking the rules, another quote from a conversation:
  18.  
  19. It has to, DOS simply cannot provide the services that are needed to
  20. run Windows.  If DOS did have those resources, then we wouldn't see
  21. Windows taking control over DOS.
  22.  
  23. NA>>   Windows programs, up until now, have been based on another paradigm of
  24.   >>   mulktitasking, which has proven to be not as good as pre-emptive.
  25.   >That was known a head of time.
  26.  
  27. Ahhh, but we have history playing a role here.  The 8086 was not
  28. capable of efficient pre-emptive multitasking.  The original platform
  29. for Windows included the 8086, up until version 3.0.  Since version
  30. 3.1 is basically just an API extension of 3.0 with bug-fixes, we can't
  31. expect any changes in paradigm.  Now that 3.1 no longer runs on 8086
  32. platforms, we are now prepared for Windows 4.0(?) which will multitask
  33. Windows apps pre-emptivley as well.
  34.  
  35.   >Correct my knowledge about the specific implementation of windows is
  36.   >limited to the literature available-  MS does not release the source
  37.   >code, if there is anyone to blame it's MS.
  38.  
  39. I beg your pardon... but it isn't at all apparent that you have
  40. availed yourself of the current literature.  If you had read the
  41. literature about Windows, then you would have known about DLL's, and
  42. that Windows can move memory around transparent to bothe Windows and
  43. DOS apps being run under Windows.  I've never seen the source code for
  44. Windows... yet reading the tech journals and publications gives me a
  45. good idea as to what is going on.
  46.  
  47.   >>   to bind in the executable code in the actual executable itself.  You
  48.   >>   can make reference to it in another file, and when you call that
  49.   >>   function, Windows will use the code in the other file.  This
  50.   >>   "other
  51.   >This is very easy to do if you view windows as an application that can
  52.   >dynamically link object libraries, and then obviously linking ten of
  53.   >the same object libraries will leave only one copy in memory.
  54.   >Windows, then, looks more like an advanced dos applciation, and then
  55.   >my suggestion was that as a dos app it could very well implement
  56.   >dynamic linking by taking overlays (which are a part of dos, built
  57.   >in, this is a fact) make these fixes windows does and enhance this
  58.   >mechanism so it looks nice and smooth.  At any event, let's discard
  59.   >specifics and look at the things abstractly with concepts in mind and
  60.   >not blends of concepts as the posts.
  61.  
  62. Not the same, and again you are revelaing your ignorance of Windows
  63. technical matters.  What if you had 10 different programs that all
  64. statically linked a comman library routine into there executables?  If
  65. you have each of those 10 programs running, then there is a copy of
  66. that library code in each one of those apps' memory space.  That means
  67. there is 10 copies of the library  routine in memory.  Inefficient use
  68. of system resources.  DLL's are different.  You can leave the library
  69. routine OUT of the executable code.  Now you can run your ten
  70. different applications, and they will access the library routine
  71. through a DLL.  Only ONE copy of the code exists, and it is linked
  72. dynamically, AT RUN TIME, to the applications that request it.
  73.  
  74.   >>You have done a nice job of theorizing about some of the concepts, but
  75.   >>   frankly, you are wrong in a lot of your assumptions about what the
  76.   >>   functional specs for Windows are.
  77.   >I agree with you!!!
  78.  
  79. Good!
  80.  
  81. NA>I am having an extremely successful email conversation with
  82.   >raymondc@microsoft.com I think everyone would be very interested to
  83.   >join and observe, this is the sort of converstion I ment to have.
  84.   >Therefore, the next post I will take all the emails I sent him and the
  85.   >ones he replied and all the followups between us put them into a file
  86.   >and post them.  Then we'll move this discussion to posting.
  87.  
  88. I would be interested to hear what raymond@microsoft.com thinks about
  89. Windows in terms of an operating system.  I would bet that he would
  90. lean toward the "90% of an OS" definition.
  91.  
  92. -Monroe
  93.  
  94.  * OLX 2.2 * "My stereo's half fixed," said Tom monotonously.
  95.  
  96.  * Origin: Through the Looking Glass (42:100/14)
  97.