China DOS Union

Private messaging system limits 500 characters, and I've lost input content by accident many times. So I'm replying here, which makes me feel more at ease.

====== In your letter on 2003-10-19 2:26:51, you wrote: ======
I want to ask, GRUB for Linux can run locally in pure Linux or even in the Linux window (Linux termin) of X-Window Linux, and you can always use the quit command to exit GRUB and return to the Linux command line. Then why not really use the compiler under DOS to port GRUB to the DOS environment to become a localized DOS software to improve compatibility and adaptability?
=====================================

Indeed, before deciding to develop grub for dos, I once searched for grub.exe on http://www.google.com/, and found relevant web pages, but some key web pages couldn't be opened. I wanted to use GOOGLE's web cache, but this has been prohibited in mainland China, so many precious materials can't be seen.

But I also found a few web pages about grub.exe, which are all bug tracking web pages of GNU GRUB, some letters. From these letters, I slightly knew that the goal of grub for dos was once worked on by someone, but it seemed that there was no follow-up. Among them, some people pointed out the problems of directly compiling GNU GRUB on the DOS/Windows platform. But it seems that no one directly compiled it, or maybe although it was compiled, it wasn't successful.

When I further considered this problem, I found that even if it was successfully compiled, it didn't make much sense. Why? Just look at the GRUB shell under Linux. This GRUB SHELL can only be used to install GRUB and test some commands of GRUB, but it can't be used to directly boot to another operating system from under Linux. Almost all GRUB commands can be executed under the GRUB SHELL of Linux, except the boot command. Imagine, if we implement GRUB for DOS like this, what's the meaning?

The most fundamental reason why the boot command of GRUB can't be used under Linux is that under Linux, it's impossible to return to real mode and execute a user-set program. Under LINUX, only the reboot and halt commands can return to real mode, but they are fixed in use, and the user can't control other behaviors after entering real mode. For example, it's not possible to immediately execute stage2 of grub after entering real mode.

Therefore, under DOS, I chose the method of HACKING DOS to implement GRUB FOR DOS. The purpose of HACK is to restore the BIOS interrupt vectors modified by DOS.

This is different from under Linux. Because under real-mode DOS, we can program freely without restrictions (this is the benefit of real mode). While the environments of LINUX and Windows have many restrictions. They all use the protected mode of CPU, refuse to execute certain instructions, and they don't have known system calls to return to real mode. Therefore, on top of these operating systems, the boot command of grub can't run.

The boot command of GRUB can boot any operating system. A necessary condition to boot these operating systems is that the CPU is in real mode. Because all operating systems in history are designed to start from real mode. The CPU of the computer is in real mode when it starts up.

Because DOS has been HACKED, GRUB can run under DOS. This makes GRUB for DOS probably (currently) the only multi-boot manager that can start running from within an operating system (in this case, from the DOS command line) and can boot any operating system. Usually, after one operating system is started, you can't enter another operating system (unless you restart the machine).

Then BasicLinux, 386Minux, BeOS, or ROMDOS.EXE in ROM-DOS 7.10, etc., can also directly start the corresponding operating system kernel from the DOS command line, and even can start in V86 mode (EMM386) when there is VCPI memory. Then why can't GRUB for DOS do this?

The things you mentioned, I haven't come into contact with any of them, and I don't know how they work.

The existence of EMM386 doesn't mean the CPU is in VM86 mode. To detect whether the CPU is in real mode, grub for dos can be used. When GRUB sends the error message "Cannot run in protected mode", the CPU is in protected mode (VM86 is also a special kind of protected mode). Otherwise, the CPU is in real mode.

Some programs can be used to boot the kernel of an operating system, but such programs can't be called "multiboot managers" yet. For example, I know that Loadlin.exe is a program under DOS, and it can boot the LINUX kernel, but it's not a boot manager. It can only boot the LINUX kernel, and can't boot the kernels of other operating systems. Operating systems generally start from real mode. I haven't found an operating system on a PC that starts from protected mode. The systems you mentioned should actually all start from real mode. Since the LINUX kernel no longer uses BIOS, LOADLIN doesn't need to restore the BIOS interrupt vectors for LINUX. On the contrary, if the operating system kernel to be booted needs to use BIOS, then the BIOS interrupt vectors must be restored for it. There is also a situation: when you use a certain special DOS, and this DOS doesn't destroy important BIOS interrupt vectors at all, then of course there's no need to restore them. Also, although a certain BIOS INT is destroyed, the new kernel doesn't use that INT at all, which is of course no problem. These are all individual examples. They are boot programs for operating systems with a special purpose and can't be used as general multiboot managers.

What you said later makes sense, but regarding the issues of V86 mode and protected mode in the previous passage, you don't seem to have explained it clearly. V86 cannot be said to be a "special protected mode", but rather a quasi-mode used for virtual 86 real mode in the protected mode environment of the system first, that is, an intermediate CPU mode between the two, and it exists in CPUs above 386.

The VM86 mode is indeed sometimes considered to fall within the scope of protected mode in certain situations. A broad sense of protected mode means that when the PE bit of the CPU is set to 1. The PE bit in VM86 mode is 1. Therefore, in Intel's technical reference manuals, sometimes VM86 is also said to belong to protected mode.