China DOS Union

Today I did some tests on GRUB for DOS 0.14 in real mode (not in a virtual machine), and found the following BUGs as a result (it seems earlier versions had them too):

If you use GRUB (whether GRUB in the MBR or GRUB for DOS) to chainloader an operating system, and then try to enter GRUB for DOS again by running GRUB.EXE, it will hang. For example, enter this in the GRUB for DOS shell:
root (hd0,0)
chainloader +1
boot
At this point it will automatically reboot from the hard disk and enter DOS again, but if you type GRUB.EXE again it hangs. But in VMWare it may instead not hang.

As for FreeDOS Kernel 2032, I also just tried calling it with GRUB for DOS 0.14 in real mode, and the result was the same as 2030/2031: it still hangs right after the "FreeDOS" text appears.

GRUB for DOS supports MS DOS best. If running MS DOS behaves abnormally, that would be a serious problem.

If your FreeDOS CONFIG.SYS has many drivers (device drivers), such as memory managers, this may cause failure.

Under FreeDOS, faults do indeed occur easily; I have also noticed this. But if config.sys does not load programs, and no TSR programs are running in memory, then it should be very stable (on my machine, all tests passed).

Of course grub.exe works the first time. But when you use grub.exe a second time, since you have not ensured that the system is in a "clean" state at that time, abnormalities will occur. If you make sure that when grub.exe runs, DOS's int table has not been modified, then there definitely will not be any fault.

The hang happens because grub for dos does not support freeDOS very well. This needs improvement later. Even if improved, it would only be a matter of automatically exiting and showing an error message when it finds that the int table is not suitable for running grub.exe. In that state, running grub is not allowed.

I very much hope GRUB for DOS can run in environments such as EMM386/VCPI. Win3.x/9x, BasicLinux, and the like can run under EMM386/VCPI after all, and generally we use EMM386 to provide UMB upper memory.

Also, I suggest updating the following paragraph, because newer DOSes (such as MS-DOS 7.10+DOSLFN or ROM-DOS 7.10, etc.) support long filenames:

“0.1.2 fixed a BUG in reading floppy sectors; added a menu item for installing GRUB to the MBR from the menu.lst menu. The usage is to copy the unpacked boot directory to C:\, that is, under the root directory (so you will have this file C:\boot\grub\menu.lst). This needs to be done under Windows, because there are many long filenames in the C:\boot\grub directory, and DOS cannot create long filenames.”

The presence of EMM386 does not count as "protected mode." EMM386 merely "uses" protected mode, while the service interface it provides to programs does not use protected mode. For example, when using MS DOS, you can include HIMEM.SYS in CONFIG.SYS, and GRUB can still work. The reason it can work is that GRUB FOR DOS does an assembly-language HACK on HIMEM, and can automatically restore the INT vectors modified by HIMEM. Similarly, a similar HACK can be done for EMM386 and any other TSR program as well, but this takes time.

Unfortunately, on FREEDOS, I currently do not have time to HACK its memory manager. If I have time later, I will complete this work.

As for running GRUB from inside true protected mode, that does not seem necessary. Even if someone needs this, it would be hard to implement. If someone knows how to switch from WIN98 protected mode to real mode, then this matter (running GRUB from protected mode) would be very easy. But this seems to be an unpublished Microsoft secret, and I am afraid nobody can really grasp it.

As for that paragraph, everyone understands that it refers to the original Microsoft systems, and does not assume the user has already installed a long filename tool, so I do not think writing it that way is too bad, especially for purely WINDOWS users.

After EMM386 "uses" protected mode, it puts the system into V86 virtual mode so that real-mode DOS programs can run, and by providing VCPI memory it also allows protected-mode DOS programs to run too, right? As far as I know, some DOS extenders (such as CWSDPMI, etc.), as well as the "DOS boxes" in Win3.x 386 enhanced mode/9x, also use V86 virtual mode so that real-mode DOS programs can run, and by providing a DPMI server, protected-mode DOS programs can run too. Real mode, 32-bit protected mode, and V86 mode can be switched easily on 386 or higher computers (it is just that switching to real/protected mode from V86 virtual mode is sometimes somewhat difficult), but what about on 286 computers? Aside from there being no V86 mode at all, switching from real mode to protected mode (the 286 only has 16-bit protected mode, not 32-bit protected mode) is easy, but the reverse is not, unless you do a hard RESET (that is, reboot the whole system) or a soft RESET (that is, the method used in OS/2 1.x to switch from protected mode to real mode in order to run DOS programs).

The following is quoted from 不点 at 2003-9-26 23:27:51:
For example, when using MSDOS, you can include HIMEM.SYS in CONFIG.SYS, and GRUB can still work. The reason it can work is that GRUB FOR DOS does an assembly-language HACK on HIMEM, and can automatically restore the INT vectors modified by HIMEM. Similarly, a similar HACK can be done for EMM386 and any other TSR program as well, but this takes time.

I think that if a similar hack has to be done for each driver or TSR program, it is bound to be extremely complicated and can never be perfectly complete (because there are too many kinds of drivers/TSR programs). I wonder whether GRUB could be given code that automatically finds and restores modified INT vectors, to automatically complete these functions?

Ah, that's exactly right.

Yesterday I installed that PC DOS of yours and was preparing to HACK it. Although the HACK was going fairly smoothly, I stopped going further. The reason is that I started to feel it was too tedious. Just as you said (great minds think alike).

Fine then, from now on I won't HACK any particular DOS anymore. I want to design a program to automatically restore interrupt vectors.

The following is a quote from Wengier at 2003-9-26 5:23:15:
I very much hope GRUB for DOS can run under environments such as EMM386/VCPI. Things like Win3.x/9x and BasicLinux can run under EMM386/VCPI, after all, since we generally use EMM386 to provide UMB upper memory.

Also, I suggest updating the following passage, because newer DOS versions (such as MS-DOS 7.10+DOSLFN or ROM-DOS 7.10) do support long filenames:

“0.1.2 fixed a BUG in reading floppy disk sectors; added a menu item for installing GRUB to the MBR from the menu.lst menu. To use it, copy the unpacked boot directory to C:\, that is, under the root directory (so you get this file: C:\boot\grub\menu.lst). This needs to be done under Windows, because there are many long filenames in the C:\boot\grub directory, and DOS cannot create long filenames.”

In books I read when I was little, UMB was called upper memory, and HMA was called high memory.
I wonder how books write it now?

That's right, it should be:

UMB: Upper Memory Block: upper memory block
HMA: High Memory Area: high memory area

不点:

As for the following paragraph, it seems there is a need to revise it:

“As mentioned above, GRUB's disk emulation is based on BIOS int 0x13. Those operating systems that use BIOS can run well under GRUB emulation. These systems include: all kinds of DOS; systems before Windows Me (not including Windows Me). I do not know whether Windows Me uses BIOS, but the Windows family after Windows 2000 apparently no longer uses BIOS. LINUX is also known not to use BIOS.”

Windows 3.x/9x/ME are all DOS-based (whether MS-DOS 6.x, MS-DOS 7.x, or 8.0), so they all access things through DOS/BIOS functions. But Win2K/XP are completely different, because they are updated versions of OS/2 and WinNT. So-called Windows 2000 is Windows NT 5.0 (specific version number: NT 5.00.2195), and Windows XP is Windows NT 5.1 (specific version number: NT 5.10.2600). WinNT was modified on the basis of OS/2, and OS/2 and WinNT/2K/XP, being one system family, use methods entirely different from BIOS to access disks. By contrast, Win3.x/9x/ME are all programs that run under DOS. Win95 is Windows 4.0 GUI (specific version number: 4.00.950), Win98 is Windows 4.1 GUI (specific version number: 4.10.1998/2222), and WinME is Windows 4.9 GUI (specific version number: 4.90.3000). They are all the same sort of thing. So if Win95/98 access disks through DOS/BIOS functions, then WinME is the same as well.

The following is quoted from Wengier at 2003-9-25 5:28:58:
Today I did some tests on GRUB for DOS 0.14 in real mode (not in a virtual machine), and found the following BUGs as a result (it seems earlier versions had them too):

If you use GRUB (whether GRUB in the MBR or GRUB for DOS) to chainloader an operating system, and then try to enter GRUB for DOS again by running GRUB.EXE, it will hang. For example, enter this in the GRUB for DOS shell:
root (hd0,0)
chainloader +1
boot
At this point it will automatically reboot from the hard disk and enter DOS again, but if you type GRUB.EXE again it hangs. But in VMWare it may instead not hang.

As for FreeDOS Kernel 2032, I also just tried calling it with GRUB for DOS 0.14 in real mode, and the result was the same as 2030/2031: it still hangs right after the "FreeDOS” text appears.

Moderator, if I boot the system from CD, after creating a virtual floppy drive,
can I use the grub on the virtual floppy
to boot the system again?
That is, can I use the virtual floppy to boot the system again?

TO Wengier:

Good! The evidence is quite sufficient, and that has convinced me, although I do not understand ME very well.

TO hanshen:

No problem. I can boot from CD into DOS and run GRUB.exe. As for GRUB being in the first sector of the floppy disk (this floppy disk is a floppy disk image file on the CD), naturally that is also possible. There is no essential difference.

If you are not quite at ease, you can use VMWARE or Virtual PC and test with an ISO file, so as not to waste a burned CD.

The following is quoted from 不点 at 2003-10-1 11:44:03:
If you are not quite at ease, you can use VMWARE or VirtualPC and test with an ISO file, so as not to waste a burned CD.

I very much hope GRUB for DOS can support booting from ISO image files through Bootable CD Loader. I believe many people need this, whether DOS/WIN users or Unix/Linux users. Is there any progress lately?

That CD boot loader written by the Russians seems in essence to use the same method as SBM: both operate on the physical addresses of the CD, bypassing the BIOS. So this method can only boot a real CD-ROM drive, not an ISO file.

The reason software like VMWARE can boot ISO files is that at the level between the operating system and the hardware, they emulate reads and writes to physical IO ports. This is impossible in a real situation. Our emulation modifies the BIOS, while everything else is a completely real machine, so there is no way to use port reads and writes to implement ISO booting.

BIOS-based ISO booting is not in itself very difficult to implement. But I would first like to implement real CDROM booting based on BIOS int (rather than CDROM booting based on IO ports). After that work is completed, it may provide basic help for BIOS int-based ISO booting. This work will not be finished quickly; it will take one or two years or even longer.

Implementing BIOS int CDROM booting may provide useful information to help implement BIOS int-based ISO booting. So I do not want to implement the latter first.

The following is quoted from 不点 at 2003-10-1 21:41:15:
That CD boot loader written by the Russians seems in essence to use the same method as SBM: both operate on the physical addresses of the CD, bypassing the BIOS. So this method can only boot a real CD-ROM drive, not an ISO file.

VMWARE and similar software can boot ISO files because they emulate physical IO port reads and writes at the level between the operating system and the hardware. This is impossible in a real situation. Our emulation modifies the BIOS, while everything else is a completely real machine, so there is no way to use port reads and writes to implement ISO booting.

BIOS-based ISO booting is not in itself very difficult to implement. But I would first like to implement real CDROM booting based on BIOS int (rather than CDROM booting based on  IO ports). After that work is completed, it may provide basic help for BIOS int-based ISO booting. This work will not be finished quickly; it will take one or two years or even longer.

Implementing BIOS int CDROM booting may provide useful information to help implement BIOS int-based ISO booting. So I do not want to implement the latter first.

Actually, as long as bcdl.bin can load shsucdhd.exe, it can be done...
But......
shsucdhd.exe would need to be modified a bit...

Roy above mentioned that “SHSUCDHD needs some small modifications,” meaning changing it from EXE format to SYS format so that it can be loaded by BCDL. SHSUCDHD is that ISO-image CD-ROM driver, that is, it virtualizes an ISO file as a physical CD-ROM drive. I once used it under pure DOS to virtualize a Win2003 ISO image file as a CD-ROM drive and perform the installation. Below I upload its EXE executable file and ASM source code:
Open attachment

Judging from the structure of the source code SHSUCDHD.ASM, it seems to already contain some of the necessary parts unique to a SYS device driver (for example, the strategy and interrupt sections that are unique and required in SYS device drivers, etc.), so I think if it is modified a bit and converted into a real SYS driver, it should not be too difficult, right? (It is just a pity that my ASM level is still rather limited, so I am not yet very clear on exactly how its source code should be modified to truly achieve this.)

BCDL.BIN itself should not be directly operating on the physical addresses of the CD. Rather, before BCDL.BIN is actually loaded, it first calls a DOS CD-ROM driver program (such as VIDE-CDD.SYS, OAKCDROM.SYS, and the like), and that CD-ROM driver operates on and drives the physical CD. Then BCDL.BIN uses an MSCDEX INT-compatible method to actually load and boot from the CD. If SHSUCDHD.SYS (that is, the SYS version of SHSUCDHD.EXE) were used as that intermediate CD-ROM driver to virtualize an ISO image file, then what BCDL.BIN would see would be a real physical CD-ROM drive, because BCDL.BIN does not directly access the physical addresses of the CD-ROM drive, but only performs the next step according to the already loaded DOS CD-ROM driver.