home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / os / mswindo / misc / 2389 < prev    next >
Encoding:
Internet Message Format  |  1992-08-25  |  6.0 KB
  1. From: Monroe.Thomas@ttlg.UUCP (Monroe Thomas)
  2. Sender: postmaster@ttlg.UUCP
  3. Path: sparky!uunet!wupost!gumby!destroyer!ubc-cs!alberta!ttlg!postmaster
  4. Newsgroups: comp.os.ms-windows.misc
  5. Subject: Re: Windows == OS
  6. Message-ID: <714807912.2@ttlg.ttlg.UUCP>
  7. Date: 25 Aug 92  21:57:04 mst
  8. Lines: 110
  9.  
  10.   >The way the sentence is phrased makes one think that windows
  11.   >virtualizes like an operating system virtualizes.  Yet, this is all
  12.   >nothing more than a layer of primitives.  You have to use window's
  13.   >primitives to fell this "virtualization" try accessing any of these
  14.   >things you mention directly and see how much of virtualization windows
  15.   >truely provides.
  16.  
  17. Huh????  Do you know what you are talking about?  Any "good" OS
  18. always hides the hardware from the software developer.  If you want to
  19. access a hardware device, you have to do so through SYSTEM calls with
  20. a well defined API.  The OS then takes care of device contention,
  21. allocation, etc...  This is why DOS is *not* a good OS, because it
  22. lets software developers manhandle the hardware without DOS's
  23. knowledge.  I think anyone would agree that Unix is a "good" OS.  How
  24. do you think that malloc is implemented?  It eventually makes a system
  25. call (through that system's API) requesting memory.  The system then
  26. returns with a pointer to that piece of memory.
  27.  
  28. And what do you think an OS is except a bunch of "primitives"?  How do
  29. you expect any programs to run if they can't request resources and
  30. services from the operating system through "primitives"?
  31.  
  32.   >>   >touch it because now you have the malloc pointer.  Yet a true
  33.   >>   >operating system, which supports this feature, does not care that
  34.   >>   >you have the actual pointer, it changes the base address of your
  35.   >>   >pointer on the hardware level.
  36.   >>    Actually, Win 3.1 changes the base address on the hardware
  37.   >>   level.  By abandoning real mode, Windows has gained greatly in
  38.   >>   memory management abilities.  Now, you can lock that HGLOBAL once, and
  39.   >>   use the pointer throughout your App's life.  When you quit, just
  40.   >>   unlock it once.  Windows will still be able to juggle your blocks,
  41.   >>   it just doesn't have to have your cooperation to do it.
  42.  
  43.   >Once more the same old same old, use window's primitves and you get
  44.   >the abstraction, the point is that if windows was a real operating
  45.   >system I could use malloc and the operating system could still juggle
  46.   >with my memory blocks.
  47.  
  48. Once more "the same old same old", every OS should provide this exact
  49. amount of abstraction.  With Windows you CAN just malloc, Windows
  50. *will* "juggle" with your memory blocks.  How else do you think
  51. virtual memory is implemented?
  52.  
  53.   >You probably mis-understood what I wrote or I did not express myself
  54.   >clearly.  The API function, these primitives, hide the hardware and
  55.   >help you write software that is a little more distant from the
  56.   >hardware for that they are great.  They do a lot of work for you, one
  57.   >function call to FillRect stands for many complex lines of code, for
  58.   >this also they are great.
  59.  
  60. NA>Again, the same thing.  You probably missed it but I worte, "simulate
  61.   >an operating system."  The fact that to open the communication port
  62.   >one calls OpenCom does not make windows an operating system.  In fact,
  63.   >in every well-designed communciation program there are primitves to
  64.   >access com ports that does not virtualize nor makes the program an
  65.   >operating system.  Windows still is a collection of 600+ primitives.
  66.  
  67. In every well written communication program for DOS, DOS is ignored
  68. and the application communicates directly with the hardware.  This
  69. means that DOS is NOT a good OS.  With Unix, (and with Windows 59% of
  70. the time) you can't ever touch the hardware unless you are a device
  71. driver.  If you are an application program, then you request a port
  72. from the operating system, and it gives it you.
  73.  
  74. Your understanding of what an OS should be is terribly limited... you
  75. seem to be using DOS as an example of what a true OS can do.  Most
  76. good DOS apps bypass DOS entirely when needing access to system
  77. resources...  DOS simply loads them into memory and executes them.
  78. All "good" OS's NEVER, NEVER let application programs access the
  79. hardware directly.
  80.  
  81.   >WindowsNT is another issue (another operating system not a GUI),and
  82.   >Windows 4.0 is another story, and hay, I just read a post that says
  83.   >that DOS 6.0 has a few things changed to make it ready for Windows
  84.   >4.0, and among other things, make some changes to DOS 6.0 so that
  85.   >windows 4.0 could become preemtive.  Hence, Windows does not solely
  86.   >use DOS as a system device driver after all.
  87.  
  88. Again, it is woefully apparent that you don't grasp what operating
  89. systems are all about.  That's OK... lots of people use OS's without
  90. understanding them.  Just because I use a car doesn't mean that I'm an
  91. expert on internal combustion engines.
  92.  
  93.   >>    So what if it is?  That is a lot like what UNIX does, too.
  94.   >>   Windows also provides for interprocess communication, device
  95.   >>   sharing, serialization of input, virtualization of all hardware,
  96.   >>   file locking and sharing, true preemptive multitasking with DOS
  97.   >>   boxes in enhanced mode.
  98.   >Noooo, unix plays with the stack and does context switches and all
  99.   >sorts of things.  You see if the loop outlined above is a good guess
  100.   >of what's happending (again, never seen the source code), then the
  101.   >function WinMain uses the same stack as the calling program (simple
  102.   >function call).  Hence, in order to introduce preemptive multi-tasking
  103.   >there should be some arrangement to make a copy of the stack, and hold
  104.   >a few stocks in memory and switch between them and take care of PCLBs
  105.   >and all sorts of things that windows does for DOS apps but not for
  106.   >windows apps.
  107.  
  108. Huh??? You've never seen the source code, but you know this?  How an
  109. OS multitasks has nothing to do with anything but multitasking.
  110.  
  111. I suggest heading down to the local library and grabbing a book on
  112. operating systems.  Read it, and then come back and tell us this all
  113. over again.
  114.  
  115. -Monroe
  116.  
  117.  * OLX 2.2 * "What a lovely entrance," Tom adored.
  118.  
  119.  * Origin: Through the Looking Glass (42:100/14)
  120.