Rinat Sadretdinow wrote in a message to Detlef Engert:

 DE> Next you have to enter a 32bit ring2 segment. This is the 
 DE> trick, but a cheap one since OS/2 already has set up a proper 
 DE> selector equivalent to the common 32bit ring3 code selector.

 RS> Common 32 bit flat code selector is 5Bh, but it really maps 
 RS> onto ring 2 selector 5Ah which describes a conforming code 
 RS> segment with DPL = 2. OS/2 system loader invokes user 
 RS> application via far call using this selector and having RPL set 
 RS> to 3 so the application starts at ring 3 due conforming 
 RS> attribute. If I try directly modify CPL from ring 3 I get 
 RS> exception.

Be aware that this works by accident.  If you change the driver profile,
meaning that you load more or less BASEDEVs, this will probably stop
working.  Upgrading to a different version of OS/2, or even to a different
kernel build by applying a FixPack, may also cause a problem.  Note also
that the DPL2 selector would not even exist if the machine was configured
for IOPL=NO.

 RS> But if I make a far 16->32 call/jump (far jumps within the same 
 RS> ring are allowed) using this selector from my 16 bit IOPL 
 RS> segment everything will work fine. Do you mean this? 

It was my understanding that what was being asserted was that some
mechanism exists which is reliable and stable to allow pure 32-bit code to
execute at DPL2 and obtain IOPL permission.  Transferring from a 16-bit
IOPL stub to 32-bit code is, within the context of what I understand to
have been asserted, cheating.
 
-- Mike


---