OSDev.org

I am reading more about OS development on other websites and found out about Unreal Mode, where you switch to protected mode, load a new GDT, and switch back to real mode, so you can use Real Mode benefits without the penalty of the little amount of ram.
My OS design does not use normal binary files, and instead uses a bytecode system read by the kernel (Similar to how Java works) so I do not have to worry about malicious programs with a sneaky CLI or HLT in the code.
With my design, is Unreal Mode still safe or should I continue using Protected Mode?

http://wiki.osdev.org/Unreal_Mode

Knowing you target architecture would help - as well as 32 or 64 bit?

If 64 bit - why bother?

dchapiesky wrote:http://wiki.osdev.org/Unreal_Mode

Knowing you target architecture would help - as well as 32 or 64 bit?

If 64 bit - why bother?

Developing mainly for 32 bit. I will develop 64 bit when I get farther into development.

Hi,

beauhefley wrote:I am reading more about OS development on other websites and found out about Unreal Mode, where you switch to protected mode, load a new GDT, and switch back to real mode, so you can use Real Mode benefits without the penalty of the little amount of ram.
My OS design does not use normal binary files, and instead uses a bytecode system read by the kernel (Similar to how Java works) so I do not have to worry about malicious programs with a sneaky CLI or HLT in the code.
With my design, is Unreal Mode still safe or should I continue using Protected Mode?

For BIOS functions, "real mode" is a relatively insignificant problem (it's fairly easy to solve using a variety of methods).

For all the problems that actually do matter, see this warning.

You should not use BIOS functions; and if you aren't using BIOS functions then you have no reason to prefer (e.g.) Unreal Mode over Protected Mode.


Cheers,

Brendan

What are the "Real Mode benefits"?

beauhefley wrote:is Unreal Mode still safe or should I continue using Protected Mode?

Could you elaborate your question? What kind of safety are you talking about?

Oh ok. I will continue using protected mode. I thought that the only problems with real mode were the ram limit and no memory protection and ring modes.

Actually, it might be good for now, as I do not have much time and have to go to school. Maybe over the summer I can re-write my code with my own drivers.

iansjack wrote:What are the "Real Mode benefits"?

In the older systems for which unreal mode was originally used, protected mode was much slower, and unreal mode allowed direct access to more than 640KB while working around that issue. This stopped being the case from Pentium onwards though, and you're better off using protected mode (or long mode!) in just about anything even remotely modern.

EDIT: and yes I've seen documents describing unreal mode without ever mentioning how its main advantage is gone from Pentium onwards.

My first stage boot loader uses unreal mode to load the second stage boot loader from disk to memory. By using unreal mode I can use int 13h to perform the disk read into upper memory. I plan on moving to a fully protected mode first stage boot loader before the switch to long mode + a jump to the second stage boot loader.

That's about the only useful thing I'd consider about unreal mode

Well, protected mode was never slower than unreal mode. The overhead was always related to using the protection features of protected mode. But if you start comparing a protected kernel with an unprotected one, it's like comparing apples to oranges. Since you're using software protection, all the user code can run in ring 0 and thus the checks related to trapping into the kernel and switching back to user mode can be skipped.