no

Hmmm... Strange: http://stackoverflow.com/questions/9137947/as … d-mode-with-gdt says the jump activates protected mode. So does some wikipedia article I've read(but cannot fimd again). It said something about the CPU decoding instructions like real mode otherwise. Makes sense though: the segment descriptor caches still have real-mode compatible values loaded in them?

So it's in protected mode, behaving like in real mode until the segment registers are reloaded?

its either luck or crash

But even if so: the descriptors still have real mode values loaded in them. As long as external interrupts and faults are prevented(cli and 100% safe real mode addresses), it should continue executing as real mode, until the segment registers are reloaded(through a far jump)? Fetching continues at CS(real mode descriptor) and EIP, until reloaded? So it can still continue executing, just no interrupts or new segment loads?

probably not

Has anyone ever tried this kind of stuff, executing some extra real-mode instructions before the jump? Real mode vs protected mode makes no difference until exceptions, interrupts or loading of segment registers. Otherwise, it still executes code the same way as in real mode? CS.D is still 0 after all(16-bit offsets) and interrupts won't fire(except INT(O)/IRET and exceptions) due to cli,so the real mode code can still run somewhat in 'protected mode'. The prefetch will continue loading sequentially(CS/EIP not being reloaded), so the code above should work reliably with CLI before setting CR0?

Of course, the GDTR/IDTR(probably real-mode compatible base 0 limit 0x3FF) needs to be loaded for this to fully work.

Even after switching to protected mode, old segment registers continue to work *exactly as before* until they are reloaded.
That means that even after the jump to load CS, the other registers (DS, ES, FS, GS, SS) will still behave like real mode until they are reloaded.
Note that reloading can happen implicitly because of an interrupt, for example. If an interrupt occurs after the switch to protected mode, then the p-mode handler will receive control. If the handler loads selectors then they become active. If the handler tries to restore them later using the original r-mode values, then you'll get a fault.

So the only way that's affected is how the loads of segment registers(and interrupts/exceptions) are handled? The only problem would be reloads of CS or other segment registers, which load descriptor table entries instead of filling (part of) it with predetermined values(access rights and real-mode base address)? Thus causing real-mode segments loading as protected mode selectors, causing faults(depending on the actually loaded selector and 'CPL/RPL')?