China DOS Union

The following is quoted from 不点's post on 2004-4-23 15:22:32:
This displayed debugging information is very useful, and it should also be kept in the official version. Because this debugging information only appears when the command line is not recognized. It will not appear when things are correct. This information is far too useful in helping us determine the root cause of an error.

The debugging information itself is indeed very useful, but if it is only like this then it is very, very unattractive, and it will make users think it is GRUB crash information or a major BUG.

I think some explanatory text could be added before this debugging information, and that should be much better, for example:

GRUB: Unknown parameter! Debug information:

This suggestion is very good.

As for parameters like /y and the like, other than the method mentioned above of “adding a space and slash at the end of the command line,” is there any better method? Could you give your opinion?

The following is quoted from 不点 at 2004-4-23 15:22:32:
/y does not start with a space, it starts with a slash. That makes it rather verbose. This is obviously a Microsoft BUG, the space should be placed before the slash, but it put it after the slash and y.

If the command line is like this:

--config-file=(hd0,0)/boot/grub/menu.lst/y /p /d /k AUTOEXEC

then it won't work. Note: (hd0,0)/boot/grub/menu.lst/y will be treated as a path, and that is an invalid path.

I took a look, and the command line will not be like the above, namely:

--config-file=（hd0,0)/boot/grub/menu.lst/y /p /d /k AUTOEXEC

but rather like this:

/y --config-file=（hd0,0)/boot/grub/menu.lst /d /k AUTOEXEC

That is to say, /y will be attached directly to GRUB.EXE, namely: GRUB.EXE/y --config-file=xxx /d /k AUTOEXEC

And when SHELL normally uses COMMAND.COM, it takes this form:
COMMAND.COM/y /d /k AUTOEXEC

For example, when it is /p /e:640, then the overall command line is:
COMMAND.COM/y /p /e:640 /d /k AUTOEXEC

And this is correct, so it does not really count as an MS BUG. It's just that when COMMAND.COM is replaced with GRUB.EXE, when using Step-by-step mode, the overall command line becomes this form:

GRUB.EXE/y /d /k AUTOEXEC

So I think that if the /y parameter attached directly after GRUB.EXE is ignored, and the space and slash after the --config-file parameter are also ignored, then it should work, right?

I uploaded grub.exe and dosstart.S, try them and see whether they work:

http://ipdown.com/grub4dos/

Method: change /y and the characters after it (up to before “--”) all into spaces, then change the space in the first “space-slash” pair into a carriage return. It should work.

Because the change is not big, I don't want to make a pre7 right now.

This time GRUB's display information really looks much better:

Microsoft(R) MS-DOS 7.1
(C)Copyright Microsoft Corp 1981-1999.

C:\>grub.exe abc

GRUB: Unrecognized command line parameters. Usage:

GRUB --config-file=FILE

The options are case-sensitive, you must use lower-case letters. Example:

GRUB --config-file=(hd0,0)/boot/grub/menu.lst

Hexdump of command-line buffer in PSP:

0080: 04 20 61 62 63 0D 00 00 00 00 00 00 00 00 00 00  abc.
0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

C:\>

But haven't parameters such as --config-file already become case-insensitive (for example, --CONFIG-FILE already works now)? Why then does it still say above, "The options are case-sensitive, you must use lower-case letters"?

It's like this: although on the surface it seems to be case-insensitive here, in fact case still matters. So I still recommend using lowercase. There are two reasons:

First, as a standalone program, grub uses lowercase for filenames on FAT-family systems; only long filenames may possibly use uppercase.【Also, by the way, GRUB cannot open filenames containing spaces, and Chinese filenames are also not easy to open】

Second, in our programming this was only a remedial measure aimed at config.sys converting all lowercase to uppercase. The algorithm is like this: first test whether the string “--config-file=” is entirely lowercase. If it is, then the filename after it is case-sensitive, that is to say, uppercase will not automatically be converted to lowercase. If there are uppercase characters in --config-file=, then the entire command line is converted to lowercase first, and only then handed over to the stage2 code.

From the user's point of view, using lowercase “--config-file=” is always safe, so it was made mandatory. In other words, uppercase can be regarded as an undocumented feature. Most people do not need to understand this detail.

A small suggestion about grub: when using bootgrub as the MBR, it seems that the grldr file can only be placed in the first primary partition. Could it be made more general, so that it searches the root directories of each primary partition in order, and uses the first grldr it finds?

It seems that currently it is already like that. If not, then that is a BUG.

The program in the first sector of BOOTGRUB can only find those sectors containing an NT bootsector. They can be FAT12, FAT16, FAT32, or NTFS, but whichever type it is, it must contain a Microsoft-formatted boot sector. Otherwise, that partition will be skipped and the next one searched.

If the second, third, and fourth sectors of BOOTGRUB are placed in the three sectors immediately after the MBR, then in that case it can find FAT12, FAT16, and FAT32 partitions processed by any formatting software, as well as NTFS partitions formatted by Microsoft.

－－－－－－－－－－－－－－

After writing this, I found that I had not correctly understood what brother bean123 meant. Indeed, at present it searches the first primary partition, and if the format of that partition is valid【that is, it is FAT12, FAT16, FAT32, or Microsoft-formatted NTFS】, then regardless of whether that partition contains GRLDR, the program will hand control to the corresponding boot program. That is to say, the program assumes that the first valid partition it finds contains the GRLDR file. This really can be improved. Thank you, brother bean123.

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

Also, brother bean123, do you have a release plan? I have been waiting all along. After you release, I will only submit patches. Just like Linux versions, with people such as A.C. patching the kernel.

WinGrub is basically finished. I am testing it now, and it can be released very soon.

All right, after releasing it, don't forget to provide the news to Chinese and English news sites. At present, mainly only people who know Chinese know about grub4dos. This is a major defect.

There is never any need to wait for my patching plans; I myself am very casual and have no timetable.

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

Supplement:

These two news sites below seem quite good:

http://slashdot.org/
http://osnews.com/

Personally I feel that after grldr came out, grub for dos gained a whole new field of application, because it is safe and convenient.

Now grub for dos already has floppy and hard disk map; if it could also map iso, then the grub for dos project would gain even wider application, for example CD installation, and CD editions of linux could also be used.