🚀 go-pugleaf

>tracer@majestix.cs.uoregon.edu (Roger M. Wilcox) writes:
>> I wrote:
>>As of Windows 3.1, all applications, including the shell, 
>>GDI.DLL, and USER.DLL run in Ring 3.  Only the p-mode kernel runs 
>>in Ring 0.
>
>
>Privilege Level 3?
>Uh oh.  Then I see a potential problem in possible future releases.
>	[things deleted]
>This kind of closes a potential door for even greater protection in future
>releases of Windows.  If IOPL were 2, instead (as in OS/2), and for the
>present all Windows tasks were run at Ring 2 instead of Ring 3, it would
>be possible to give I/O protection in future releases by running non-I/O-
>dependent Windows apps in Ring 3 and old, misbehaved, I/O-port-using Windows
>apps in Ring 2 (selected by a check box in the "Run" dialog or something).


I guess I should have given a longer answer before, since I managed
to confuse you.  The Windows kernel (kernel.exe) runs in Ring 3 along
with everything else, but the virtual machine kernel (win386.exe) runs
in Ring 0.  kernel.exe only runs Windows programs, and as such is treated 
as one process by win386.exe.  All of the other virtual dos machines, 
along with the Windows process itself, are pre-emptively multitasked based
upon the values you set up in the PIF files.  Note that this pre-emptive 
multitasking only occurs between VDMs and the Windows session; each 
individual Windows program still is cooperatively multitasked.

The IOPL, on the other hand, is set to 0 so that anybody can do almost
anything they want with the port trappings.  VxD's (which run in Ring 0
too) can also be set up to trap specific ports.  I'm not the local
expert on 80386 port trapping in win386.exe, but from what I've been 
told your sound-emitting program shouldn't have any problems.

For Windows 3.1, it wouldn't have been a good idea for us to try to 
provide I/O protection against certain apps since there are some
programs floating around which do very low-level things to the hardware
in order to support some boards or other I/O devices.  Compatibility
with Windows 3.0 and MS-DOS and all of that (it's a horrible fact of
life).  We had an pre-beta of Windows 3.1 in early June of '91 that
was shipped to around 100 ISVs just to make sure that we didn't
break any of their programs when we moved their execution from Ring 0
to Ring 3.  The regular beta of 3.1 went out in July of '91.

Windows NT, on the other hand, obviously doesn't allow any random
process to mess with these low-level things for security reasons.
Although I'm not in the NT group, I have heard that we are working 
closely with any of the vendors who have MS-DOS, Windows 3.0 or 
Windows 3.1 style applications which attempt to do these naughty things
so that their programs can be ported to NT.