China DOS Union

The old version restored the BIOS interrupt int70 - int77 vectors according to the values in the range 0000:05dc - 0000:05fb. Since this memory area looks like a stack and is sometimes overwritten, the new t12 version no longer restores interrupt vectors according to the values in this area. In this way, the new version solves the old problem that GRUB.EXE was not reentrant.

The method t12 uses is to detect the MS-DOS interrupt service routines pointed to by the interrupt vectors in the range 0000:01c0 - 0000:01df, and from them find the original int70 -int77 BIOS interrupt vectors.

After VIDE-CDD.SYS is loaded, it may have modified the interrupt vectors in the range 0000:01c0 - 0000:01df, which causes this detection to fail.

The solution is to use the old detection method first, and if it fails, then use the new detection method.

Please use debug to list the values in the range 0000:01c0 - 0000:01df. I need to see which vectors have been modified and which vectors have not changed.

grub_t13 has already been uploaded and should solve the above problem.

　　 Fixed the failure that grub_t12 could not start. The release date of the official version basically depends entirely on the completion date of the English documentation. I hope someone can help . Writing English is rather hard for me, so if I write the English explanation for 0.2.0, it may be overly simplified.

　　BUGs can still be reported in the "Boot Disk Room" of Wengier's New DOS Forum.

　　Download the third (perhaps the last) public test version here:

ftp://ftp.cosoft.org.cn/incoming/grub_t13.exe

　　Note: The improved algorithm makes it possible to run grub.exe again after MS-DOS 7+ is started by grub.exe. However, multiple reentries will cause a crash when accessing the hard disk, cause unknown . If it is reentered only once, everything seems normal. Also, under DOS no other danger appears (for example damaging some sector); at most it is only a crash.

The Chinese documentation is temporarily placed at the end of the following webpage:
http://www.linuxeden.com/edu/doctext.php?docid=3006

不点: You said you want to write English documentation. I wonder if there is any ready-made Chinese original text for part of it to be translated? Also, are there any more specific requirements for format, word count, etc.?

About GRUB itself, I found that if Chinese character support systems such as UCDOS and CCDOS97 are started under DOS and Chinese mode is entered (at this time the screen is in graphics mode), then running versions such as T11 and T13 of GRUB.EXE will immediately crash the system. But if Ctrl+F7 is used to switch to English mode (at this time the screen is in text mode), then running GRUB will not crash. However, if GRUB is used this way to reboot DOS on the hard disk, when UMBPCI loads it will prompt that the specified memory parameter range is wrong.

About the English documentation, I currently have not even had time to start doing it, and can only rely on assistance. My preliminary plan is to put the English documentation in the README file , but it can also be placed separately, with the location of that explanatory document indicated in the README file. Regarding word count, format, etc., there are no restrictions at all; it is up to the person writing it to decide. For example, text format is fine, man manual format is fine, html format is fine. Since this is writing, there is no need to strictly translate the Chinese documentation. The Chinese documentation is only for reference; it can be greatly abridged or expanded, and the order can also be rearranged. In short, it is to be rewritten. Any way of writing is fine.

I eagerly hope brother Wengier can help again, and I thank you here first. Recently my health has not been good and I am in the hospital for treatment; I really cannot attend to some things. If brother wengier can help, I would truly be very grateful!

==========

Regarding the BUG you mentioned, my preliminary guess is that it is because int13/AX=4b00 was run. This is the method for exiting disk emulation of CD booting, and it is not of much use. In the next version I will remove it and try, to see whether there are still problems.

grub_t14 uploaded. It first determines whether the bootable CDROM has emulated a floppy disk or hard disk. If it has not emulated one, it does not run int13/AX=4b00. Let's see whether this solves the problem.

ftp://ftp.cosoft.org.cn/incoming/grub_t14.exe

不点: So you have been in the hospital recently? I hope there is nothing seriously wrong. Wishing you good health; don't wear yourself out.

Your spirit is indeed moving. Unfortunately, these days the new computer I often use has broken down (hardware fault), so now I have to use an old public computer. Not only is it slow, but my computer time is also much more restricted. And since this computer does not have a virtual machine and also cannot have one installed (low machine configuration and it is public), recently I have been testing GRUB on a real computer. I very much hope I can help, but unfortunately...

It is not too serious, thank you for your concern. I am semi-hospitalized and often run out. It doesn't matter if you cannot help this time; being able to test is already the greatest help. I hope your testing is safe. Please report BUGs in time. Let's see whether this t14 works.

不点: I just tried this T14 version, but after loading a Chinese character support system such as UCDOS, when the system automatically enters Chinese DOS command line mode, entering GRUB to try to enter GRUB still crashes. I wonder if it is because GRUB currently still does not have a function to restore the display mode?

Also, can GRUB support a batch script mode? For example, can it automatically run the following boothd.cmd file, so that it does not have to be entered manually? The existing menu.lst method must have a menu, otherwise it cannot be executed by GRUB at all. I hope GRUB can be improved so that it directly supports a batch script mode. For example:

root (hd0)
chainloader +1
boot

First question: after loading a Chinese character support system such as UCDOS, when the system automatically enters Chinese DOS command line mode, entering GRUB to try to enter GRUB still crashes. I wonder if it is because GRUB currently still does not have a function to restore the display mode?

First of all, I don't know whether GRUB has always had this problem, or whether it was introduced by later versions. This is very important. Because the new version 0.2.0 has no special differences; if this problem has always existed before, then it may be the reason you said, that the display mode has not been restored to text mode. It can be solved by restoring the display mode, or it may not be solved. If it is a new problem introduced by the new version, then it is a BUG that needs to be corrected, and should be correctable.

-------

I feel the second question seems to be something that can be handled. menu.lst seems enough. Set timeout to 0 and the menu will not appear; it will directly boot the operating system from the default title.

GRUB has a command configfile that can be used to run a menu.lst file (or any specified menu file), equivalent to running a DOS BAT file. If you want the menu not to appear, you can set timeout to 0. This way it will automatically run the commands in the default item.

However, the menu will automatically add a boot command at the end, which is rather annoying. If you do not want this boot command, it may be more troublesome. Perhaps this was a problem the people who originally designed GRUB did not consider.

不点:

Regarding the first question, it should be a problem that GRUB for DOS has always had. I just did an experiment: first under DOS I used the MODE CO40 command to switch DOS's display mode to 40 columns (whereas it is usually 80 columns). As a result, when I used the GRUB command to run GRUB for DOS, I found that it did not restore the display mode, and still used the 40-column display mode. It can be seen that GRUB for DOS indeed currently lacks the function of restoring the display mode, causing it to crash when entering GRUB for DOS from graphical command line mode.

Regarding the second question, I had tried setting timeout to 0 before as you said, but it seems it is not that the menu does not appear, but that the menu flashes past (sometimes even longer; I also once tried using the color command to hide the menu, but the result was still not very ideal). In addition, a boot command is indeed always automatically added at the end, and it seems to have seriously affected the operating effect (I discovered these problems when I was preparing to add GRUB for DOS to the Super DOS Boot Disk for booting multiple boots). Is there any way to solve this?

I used the "Super Universal MS-DOS 7.10 Boot Disk" to boot real-mode DOS, then ran the XZL Chinese system, and then typed grub. As a result, there was no response on the screen at all. But this was not a crash; it was merely that nothing could be displayed. If I type GRUB's "reboot" command from the keyboard, the machine can still restart just fine.

We can consider using grub's mode switching command, if GRUB has such a command.

Let's study it further.

＝＝＝＝＝＝＝＝

Regarding GRUB batch processing, we can try adding a command called "exit-to-command-line". Put this command as the last line in the menu, so that in the menu it can avoid executing the final boot command.

Or implement it using map --exit-to-command-line.

The problem of the menu flashing past should also be solvable.

Using GRUB placed in the MBR (in Boot.ini) to boot an img, after the boot command either only the cursor remains blinking in the lower-left corner, or the screen becomes garbled, but executing guru on the hard disk in dos and then booting the IMG is normal. Is there a Chinese command HLP for Grub?

Thanks.

What you report is a strange situation. According to your report, it seems that before NTLDR boots the 512-byte boot sector, it also modifies some BIOS interrupt vectors or something else. Logically, this should not happen.

I hope more people test and study this situation.

Detailed Chinese help for GRUB commands may not be common (I have not paid attention either); search in google.

------------

Also adding a note: some BUGs are BUGs in GNU GRUB, not only in GRUB FOR DOS, or in other words, they have nothing to do with the GRUB FOR DOS patch itself. For this kind of BUG, it is best to report directly to GNU GRUB's BUG reporting mailing list. The webpages are below, and you can also check whether others have reported the same BUG before:

GNU GRUB homepage: http://www.gnu.org/software/grub/
BUG GRUB information page: http://mail.gnu.org/mailman/listinfo/bug-grub
View all previous BUG report information: http://mail.gnu.org/archive/html/bug-grub/

For GNU GRUB BUGs, even if we discover them, they may not be easy to solve. We can only solve some of the easier BUGs among them. The vast majority of BUGs are left for the GNU GRUB project team to solve.

We can only focus on solving BUGs specific to GRUB FOR DOS, that is, the extension parts to GNU GRUB:

1. BUGs caused by the DOS startup code part.

2. BUGs caused by the disk emulation code part.

GRUB dual boot, as long as the WINDOWS disk is formatted the file gets damaged. MBR

Brother 《电脑爱好者》, please say it in more detail; I did not quite understand.

Did you use disk emulation commands?

Format what? What is damaged?

There is detailed explanation on the webpage about grub for dos 0.2.0 disk emulation, especially regarding the formatting function. Take a look:

The Chinese documentation is temporarily placed at the end of the following webpage:
http://www.linuxeden.com/edu/doctext.php?docid=3006