home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / ibm / pc / hardware / 34744 < prev    next >
Encoding:
Internet Message Format  |  1993-01-04  |  3.3 KB
  1. Xref: sparky comp.sys.ibm.pc.hardware:34744 comp.sys.mac.hardware:25265 comp.os.ms-windows.advocacy:3675
  2. Newsgroups: comp.sys.ibm.pc.hardware,comp.sys.mac.hardware,comp.os.ms-windows.advocacy
  3. Path: sparky!uunet!microsoft!hexnut!georgem
  4. From: georgem@microsoft.com (George Moore)
  5. Subject: Re: Windows Memory Protection (was Re: "Windoze" slow? Naah...)
  6. Message-ID: <1993Jan04.183233.25951@microsoft.com>
  7. Date: 04 Jan 93 18:32:33 GMT
  8. Organization: Microsoft Corporation
  9. References: <1992Dec21.062031.8868@cs.uoregon.edu> <1992Dec23.223919.26720@microsoft.com> <1992Dec29.165518.25293@cs.uoregon.edu>
  10. Lines: 50
  11.  
  12. >tracer@majestix.cs.uoregon.edu (Roger M. Wilcox) writes:
  13. >> I wrote:
  14. >>As of Windows 3.1, all applications, including the shell, 
  15. >>GDI.DLL, and USER.DLL run in Ring 3.  Only the p-mode kernel runs 
  16. >>in Ring 0.
  17. >
  18. >
  19. >Privilege Level 3?
  20. >Uh oh.  Then I see a potential problem in possible future releases.
  21. >    [things deleted]
  22. >This kind of closes a potential door for even greater protection in future
  23. >releases of Windows.  If IOPL were 2, instead (as in OS/2), and for the
  24. >present all Windows tasks were run at Ring 2 instead of Ring 3, it would
  25. >be possible to give I/O protection in future releases by running non-I/O-
  26. >dependent Windows apps in Ring 3 and old, misbehaved, I/O-port-using Windows
  27. >apps in Ring 2 (selected by a check box in the "Run" dialog or something).
  28.  
  29.  
  30. I guess I should have given a longer answer before, since I managed
  31. to confuse you.  The Windows kernel (kernel.exe) runs in Ring 3 along
  32. with everything else, but the virtual machine kernel (win386.exe) runs
  33. in Ring 0.  kernel.exe only runs Windows programs, and as such is treated 
  34. as one process by win386.exe.  All of the other virtual dos machines, 
  35. along with the Windows process itself, are pre-emptively multitasked based
  36. upon the values you set up in the PIF files.  Note that this pre-emptive 
  37. multitasking only occurs between VDMs and the Windows session; each 
  38. individual Windows program still is cooperatively multitasked.
  39.  
  40. The IOPL, on the other hand, is set to 0 so that anybody can do almost
  41. anything they want with the port trappings.  VxD's (which run in Ring 0
  42. too) can also be set up to trap specific ports.  I'm not the local
  43. expert on 80386 port trapping in win386.exe, but from what I've been 
  44. told your sound-emitting program shouldn't have any problems.
  45.  
  46. For Windows 3.1, it wouldn't have been a good idea for us to try to 
  47. provide I/O protection against certain apps since there are some
  48. programs floating around which do very low-level things to the hardware
  49. in order to support some boards or other I/O devices.  Compatibility
  50. with Windows 3.0 and MS-DOS and all of that (it's a horrible fact of
  51. life).  We had an pre-beta of Windows 3.1 in early June of '91 that
  52. was shipped to around 100 ISVs just to make sure that we didn't
  53. break any of their programs when we moved their execution from Ring 0
  54. to Ring 3.  The regular beta of 3.1 went out in July of '91.
  55.  
  56. Windows NT, on the other hand, obviously doesn't allow any random
  57. process to mess with these low-level things for security reasons.
  58. Although I'm not in the NT group, I have heard that we are working 
  59. closely with any of the vendors who have MS-DOS, Windows 3.0 or 
  60. Windows 3.1 style applications which attempt to do these naughty things
  61. so that their programs can be ported to NT.
  62.