home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / os / mswindo / misc / 2450 < prev    next >
Encoding:
Internet Message Format  |  1992-08-27  |  5.1 KB
  1. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!Sirius.dfn.de!Urmel.Informatik.RWTH-Aachen.DE!dfv.rwth-aachen.de!sungate.fido.de!p1.hippo.fido.de!eurologic.fido.de!Martin_Schloeter
  2. Date: Wed, 26 Aug 92 13:08:10 +0200
  3. From: Martin_Schloeter@eurologic.fido.de (Martin Schloeter)
  4. Subject: Re: Windows == OS
  5. Message-ID: <196ddc1a@p3.f67.n245.z2.fidonet.org>
  6. Newsgroups: comp.os.ms-windows.misc
  7. X-Comment-To: tguez@jade.tufts.edu (Name)
  8. Organization: Die ersten 100.000 Jahre... 
  9. Lines: 90
  10.  
  11. N > I have never seen any of the underline code for windows, but from
  12. N > programming windows I say, with a great deal of confidence, that
  13. N > windows is not even 10% an operating system.  It's one huge layered
  14. N > APPLICATION.  Everything you do that interacts with the hardware goes
  15. N > through a layer, i.e., another function call.
  16. Quite normal for most operating systems.
  17. N >   Instead of calling
  18. N > malloc, one calls globalalloc which is probably nothing more than a
  19. N > malloc that is hidden down somewhere plus some additional tracking
  20. N > information.  
  21. No, no. A malloc done with a DOS based app simply takes some memory out of the 
  22. DOS memory pool a marks it as used. A GlobalAlloc create a new entry in the 
  23. local descriptor table of the protected mode environment of the 286/386. 
  24. N > Windows can move memory because it never gives you the
  25. N > handle it gets from malloc, it keeps it and therefore could do what
  26. N > ever it wants with it without affecting your application, 
  27. No,no. In protected mode (standard and enhanced) there is no real difference 
  28. between the handle and the pointer. There is only one bit switched for internal 
  29. purposes. You can lock the memory in the moment you allocate it, can use the 
  30. pointer and Windows is still able to move the block around. It's protected 
  31. mode, not DOS!
  32. N > These API function calls are great, they hide most of the hardware and
  33. N > they do a lot of work for you and simulate an operating systems.
  34. Nonsense. There is no DOS either device drivers between Windows and 90% of the 
  35. hardware resources of the machine.
  36. N > Windows still uses msdos drivers to do things and it will continue to
  37. N > do this.  
  38. Yes, but only on file system level!
  39.  
  40. N > Again, I never saw any of the code for windows but it seems to me that
  41. N > the whole "windows programs" environment is nothing more than a setup
  42. N > like this:
  43. N > 
  44. N > loop on tasks ( simply run through a linked list of data structures)
  45. N >   get then WinMain function pointer of the current data-structure
  46. N >   (*func_pointer)([the winmain parameters here]) ;
  47. N >   get next pointer
  48. N > end loop
  49. Yes, that is cooperative multitasking. It's one way to implement a multitasking 
  50. system. It's not the best way, but there were "historical" reasons to do it in 
  51. this way. The alternative looks like:
  52.   interrupt on task list (.....) 
  53.     ...
  54.     ...
  55.   end loop.
  56.  
  57.  
  58. N > In Petzold's introduction for windows programming, he writes something
  59. N > to the effect,"...windows will not take away the cpu from a task in
  60. N > the middle of a message processing....make's sense right?"  Of course
  61. N > it does, windows could not take away the processing even if it
  62. N > wanted to; All of windows "multi-tasking" is nothing more than very deep
  63. N > function calls, so everything is on the stack and hence the message
  64. N > (or actually the function) must finish so that the stack will come
  65. N > back to this "ingenious" loop, and continue.
  66. The only difference for a "real" preemptive multitasking system (for example 
  67. Unix) is, that there it a timer driven interrupt mechanismen which 
  68. automatically switches between the different tasks. All other things are the 
  69. same. (In detail there are feature like separated address spaces for different 
  70. task, but this has nothing to do with the basic mechanismen). 
  71.  
  72.  
  73.  
  74. N > I don't mean to be rude to anyone (not even Microsoft) but I am upset.
  75. N > Somewhere in Petzold's book he says something like keep your message
  76. N > processing short so other windows programs could run concurrently, and
  77. N > if you have any big job to do divide your job to small parts and do it
  78. N > with the help of the timer....
  79. Another ways to release CPU time is to do 
  80.   IF PeekMessage(...) THEN DispatchMessage.
  81. And remember, Petzold is a relative old book and doesn't contain all.
  82. N > That is really disguesting, windows
  83. N > programs need to do the job of the operating system, provide the
  84. N > "ticks." 
  85. The ticks are a hardware feature managed by the OS Windows. 
  86. N >  I have still to figure out this one:  in the control panel,
  87. N > 386 enhanced setup, if you read the help about time slicning and all
  88. N > that, it makes a soup out of the whole story and finally says that
  89. N > ms-dos applications ("the old-applications") have a time slice setting
  90. N > each, while windows programs share one setting.  Then, you get the
  91. N > default of 20.  Now if you change it you get some differences in
  92. N > behavior, but I still don't see how they could claim that windows
  93. N > applications are actually and truely time-sliced given the discussion
  94. N > above.
  95. Windows apps are _NOT_ time sliced. There are running virtual machines, one for 
  96. Windows an one for each DOS box with are time sliced by the sceduler of the 
  97. underlaying VMM.
  98.  
  99.  
  100. Greetings Martin
  101.