OSDev.org

I took my time to read this thread. My interpretation is that you are saying, that you are saying, that when software switches CPU back to real mode, it must also restore the hardware configuration made by BIOS so it can use BIOS calls, which are the only sensible reason to switch back to real mode. You also say that cases where some other firmware than BIOS is used aren't related to this discussion. Where am I wrong? If it is interpretation of your term "default configuration", please tell why someone should restore the hw configuration left by EFI to things function correctly in real mode.

I guess I'll just go write a DOS clone for EFI based systems. Damn, I didn't remember I have to restore the hardware configuration left by BIOS when I switch to real mode. And, oh, right, this all doesn't make sense, because I can't make any BIOS calls, which would be the only sensible reason to switch back to real mode. I guess I have to forget that project.

You are right, of course. But one thing I'd like to ask is that how many OS over here are EFI-aware? Even if we have reasonable amount of OSes that support EFI-booting(without GRUB), can I have a look at one that makes flexible Protected mode -> Real mode transition (to satisfy myself)?

The answer is no. The argument has already been given before:
- If you need to drop to real mode from a running protected mode OS your design is seriously flawed.
- If you need to drop to real mode as part of your bootstrap, there should be no state that needs restoring.

In the case of EFI, there is no state to restore at all. In the case of a legacy BIOS, anything you do to the hardware without the bios' knowledge has the ability to break it until a reset as you can in many cases not know what state the BIOS expects, so the only correct approach is to make all the BIOS calls before any direct hardware access after which the BIOS is not to be touched ever after.

So the entire point about restoring state is only about what hacks you might try to have some chance of success of implementing an "exit to DOS" option without rebooting.

Just going to chime in here, but, dropping to real mode is not worth the trouble.. you have virtual 8086 mode and lightweight software emulators like x86emu.

As for the Wiki reference, perhaps that section should be removed entirely.

Dropping to real mode can be useful. For example you could launch your OS from DOS (where you could be running your development environment) then drop back to real mode to continue development. It saves a lot of rebooting time.

gerryg400 wrote:Dropping to real mode can be useful. For example you could launch your OS from DOS (where you could be running your development environment) then drop back to real mode to continue development. It saves a lot of rebooting time.

The involvement of DOS is anyway with any modern project is a critical failure by default.

That said, how is VBE not a good reason to drop back into RM? EDIT: Nevermind.

The involvement of DOS is anyway with any modern project is a critical failure by default.

I disagree. I have found MSDOS to be an acceptably good boot-loader.

gerryg400 wrote:

The involvement of DOS is anyway with any modern project is a critical failure by default.

I disagree. I have found MSDOS to be an acceptably good boot-loader.

We differ in philosophy.

Combuster wrote: If you need to drop to real mode from a running protected mode OS your design is seriously flawed.

Maybe. But that's how I like to experiment with my OS. I did present the idea of "Restoring the hardware to original configuration" just to reckon the possible consequences of switching to Real Mode. I didn't realize that would gain me criticism as a solid feedback. Nor did I expect that someone would criticise my design.

Brynet-Inc wrote:As for the Wiki reference, perhaps that section should be removed entirely

I don't agree. V86 has it's own place. Some emulators don't even support it. There's a reason to drop to Real Mode.

Combuster wrote:In the case of EFI, there is no state to restore at all.

Like I asked before, "how many OSes over here are EFI-aware?"

fronty wrote:You also say that cases where some other firmware than BIOS is used aren't related to this discussion. Where am I wrong?

You're wrong at that very point. EFI is not the theme of this discussion, so I've been avoiding this from the very beginning. EFI is a very different beast. I know it's the replacement to the legacy-BIOS but it isn't quite supported in every OS here. So, I see no reason to divert this topic to EFI.

Since EFI is becoming the more centralized issue over here, let me get this straight...

Wiki: Real Mode article wrote:The program needs to go through the following steps:
Disable the interrupts:
Turn off maskable interrupts using CLI.
Disable NMI (optional).
Turn off paging:
Transfer control to a 1:1 page.
Ensure that the GDT and IDT are in a 1:1 page.
Clear the PG-flag in the zeroth control register.
Set the third control register to 0.
........

So, there's a step suggesting to disable paging, no? So what if an OS uses segmentation instead of paging? That step is skipped, right? I too am following similar route. I just want to add a step that suggests to restore the hardware configuration. In case someone is implementing EFI, this step could be skipped. What's wrong with that?

Combuster wrote:So the entire point about restoring state is only about what hacks you might try to have some chance of success of implementing an "exit to DOS" option without rebooting.

Hacks?

I know it is easy to criticize people, but extremely difficult to think from the other side.

Since it seems as if some guys over here, are annoyed by this discussion, I hereby request a moderator to lock this thread. In the end, it won't really matter, so there's no reason to continue it.