home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / os / mswindo / programm / win32 / 940 < prev    next >
Encoding:
Text File  |  1992-09-13  |  3.4 KB  |  70 lines
  1. Newsgroups: comp.os.ms-windows.programmer.win32
  2. Path: sparky!uunet!microsoft!hexnut!alistair
  3. From: alistair@microsoft.com (Alistair Banks)
  4. Subject: Re: Windows 3.1 & Processor Mode Swap
  5. Message-ID: <1992Sep13.202557.6677@microsoft.com>
  6. Date: 13 Sep 92 20:25:57 GMT
  7. Organization: Microsoft Corporation
  8. References: <Iegd38G00WB98APb1X@andrew.cmu.edu>
  9. Lines: 59
  10.  
  11. In article <Iegd38G00WB98APb1X@andrew.cmu.edu> ee0n+@andrew.cmu.edu (Eric James Ewanco) writes:
  12. >Hi. I've been having a discussion with someone about WInodws over DOS
  13. >
  14. >Suppose a Win32 application mades a DOS call  First, does the trap go into
  15. >Windows in Protected mode, or into DOS (in 21h)? 
  16.  
  17. Win32 Apps can't make Int21 calls under Win32s+Win3.1 or under Windows NT
  18. so if one attempts to make such a call, the system GP faults that app
  19.  
  20. If you mean "What happens when a Win32 app, under Win3.1+Win32s, makes a
  21. base i/o call?" the answer is that the call is executed by the
  22. Win32s .dlls, and selectively executed within the Win32s VxDs, or "thunked"
  23. back to the Windows system code - there are many places where the file i/o
  24. calls can actually be fulfilled, some of which completely avoid ms-dos
  25. code - the driver model (VxD) of Windows enhanced mode allows hooking
  26. out of ms-dos code at various levels, including the 32-bit prot mode
  27. fault caused by the Int XX or i/o instruction generated - Windows itself makes
  28. use of every one of these levels for different i/o calls, and add-on
  29. drivers make this even more complex - But at the end of the day, if the
  30. original ms-dos code gets called, it'll be executed in
  31. virtual x86 mode - if the ms-dos code accesses "physical" hardware, this
  32. will be coordinated through traps and the physical access will
  33. happen in VxDs in many cases, in some other cases the i/o ports are
  34. not masked as protected, and the i/o will simply go ahead
  35.  
  36. >Hence, the big question, how many times does Windows switch between real and
  37. >protected mode (protected and virtual 8086?) in a Win32 DOS call? Six is my
  38. >guess.
  39.  
  40. As above, there's no general answer - from none, to very many, depending on the
  41. call and the configuration of drivers
  42.  
  43. >Next question, related: what happens when a DOS program does a DOS call? 
  44.  
  45. The MS-Dos or BIOS Int XX call is executed in v86 mode, and faulting
  46. occurs as and when appropriate as above
  47.  
  48. >Final question: DOS is still non-reentrant under Windows, right, so only one
  49. >DOS call may be executing at any given time?
  50.  
  51. MS-Dos 1.0 -> 5.0 are largely non-reentrant, but Windows hooks out some
  52. sections and executes the ms-dos functionality in its own code - this
  53. "non-use" of "non-reentrant" code will only increase in the future!
  54.  
  55. >Basically I am trying to convince someone that Windows NT will be much more
  56. >efficient and less crash-prone than Windows on top of DOS.  I am trying to show
  57. >how awkward DOS compatibility makes Windows execution.
  58.  
  59. Windows NT's design-point is for security & robustness, Windows on MS-Dos's
  60. design point is for compatibility & lower memory useage. I think you can
  61. argue "awkwardness" and "efficiency" both ways in both versions. Windows NT
  62. will more often "blow-away" the app in favour of protecting the system,
  63. Windows on MS-Dos will more often let the app do "dirty" things to the system
  64. in order to keep that app running, so "crash-prone" is relative to the
  65. app or to the system - I'd argue that neither are crash-prone, both are
  66. crash-resistant! -- Alistair
  67. blow-away" the system
  68.  
  69. -- Alistair
  70.