From: nowhere@nevernet.at   
      
   On 21/02/2022 19:35, James Harris wrote:   
   > On 21/02/2022 17:18, wolfgang kern wrote:   
   >> On 21/02/2022 15:33, wolfgang kern wrote:   
   >>   
   >>>> If so, can you think of an instruction or sequence which would   
   >>>> distinguish between the two?   
   >>   
   >>> give me some time to check in deep detail, I'll be back on this soon.   
   >>   
   >> here we go:   
   >> this works in RM as long it points to an far RETURN:   
   >> you can test this yourself   
   >> 9A xxxx 0000 call far 0000:xxxx ;raise exception if PM   
   >>   
   >> PM only (raise invalid opcode exception in RM):   
   >> 63 xx        ARPL  (seems obsolete)   
   >> 0F 00 /1     STR   an easy test possibility ie:   
   >> 0F 00 c8     STR ax |eax |rax   
   >> 0F 00 08 xx  STR [mem16] ; all except RM   
   >>   
   >> 0F 00 /0     SLDT r16/r32/r64/m16   
   >> 0F 00 /2     LLDT rm16   
   >>   
   >> 0F 00 /3     LTR   
   >> 0F 02 /r     LAR   
   >> 0F 03 /r,[m] LSL   
   >>   
   >> these work in UNreal after correct loaded   
   >> 0F 00 /4     VERR   
   >> 0F 00 /5     VERW   
   >   
   > Sorry, I wasn't clear enough. What I was thinking about was a legitimate   
   > instruction or sequence thereof which would work differently in RM and   
   > PM16. ARPL and similar are not RM instructions.   
   >   
   > For example, here's an instruction which is legitimate in both modes but   
   > executes differently:   
   >   
   >    mov ds, ax   
   >   
   > In PM16 it loads the hidden part of DS from the appropriate descriptor   
   > table. In RM it doesn't.   
   >   
   > What I am trying to prove is that once CR0.PE is set (and prefetch   
   > queues flushed) the processor will be in PM, not RM, even _before_ CS is   
   > reloaded.   
   >   
   > AISI the different behaviour of MOV DS, AX shows that the processor /is/   
   > in Protected Mode, not Real Mode, even if it's PM16 rather than PM32.   
   >   
   > IIRC you thought the processor would still be in RM. If I'm wrong,   
   > therefore, perhaps you can think of another instruction (a legitimate   
   > one) or sequence which could be executed after setting CR0.PE but before   
   > loading CS which would tell whether the CPU was in RM or PM.   
      
   assume or make your RM-CS 07c0 before the switch   
   and try this after it:   
     push cs   
     pop ax   ;ax show the RM-segment and nothing else   
      
     or try self-modify and check where the change happens:   
   mov word [cs:00FE],31c8  ;or whatsoever. might crash if PM   
   __   
   wolfgang   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)