China DOS Union

Yes, fully supported.

GRUB.EXE and GRLDR use the default menu (hd0,0)/boot/grub/menu.lst if it exists.

You can also use a command-line argument to adjust which menu.lst file is needed:

GRUB --config-file=(hd?,?)/somewhere/else/your_menu_lst_file

At the end of the first sector of GRLDR there is the string (hd0,0)/boot/grub/menu.lst. You can use a hexeditor to change it to a different filename.

The MENU.LST file can contain our map command; this is definitely supported.

The following is quoted from 不点 on 2004-2-18 16:10:18:
Yes, fully supported.

GRUB.EXE and GRLDR use the default menu (hd0,0)/boot/grub/menu.lst if it exists.

You can also use a command-line argument to adjust which menu.lst file is needed:

GRUB --config-file=(hd?,?)/somewhere/else/your_menu_lst_file

At the end of the first sector of GRLDR there is the string (hd0,0)/boot/grub/menu.lst. You can use a hexeditor to change it to a different filename.

The MENU.LST file can contain our map command; this is definitely supported.

Oh! Thanks a lot!

That is wonderful!

After your MBRs are finished, that is a very convenient tool.

We shall develop a GRUB for Windows to support your GRUB for DOS by:

1. copy the MBRs to hard disk of choice within windows
2. copy GRUB.EXE / GRLDR and /boot/grub/menu.1st to the root directory of
FAT12/16/32/NTFS of choice under windows

Any other files?

Only GRLDR needs to be in the root directory; the others do not.

What is booted from the MBR will be the GRLDR file, and GRUB.EXE will no longer be used.

After the GRLDR file takes over control, it automatically reads the (hd0,0)/boot/grub/menu.lst file as the menu. As mentioned earlier, you can use a hexeditor to modify the location and name of this file.

The MBR may not be just one sector, but several sectors. But at most it will not exceed 63 sectors.

To find the GRLDR file on FAT12/16/32/NT, one sector is not enough. So the first 4 sectors at the beginning of the hard disk all have to be used. If expanded later, all 63 sectors may be needed.

We do not modify the BOOTSECTOR of FAT12/16/32/NT itself. Our boot loader resides entirely in the MBR. The MBR referred to here means all 63 sectors at the beginning of the hard disk; more precisely, all sectors of track 0 (that is, all sectors of cylinder 0, head 0)

Note: If the hard disk's sectors per track is not 63, then "all sectors of track 0" will not equal 63.

TO brother wengier:

Could you update this webpage:
http://newdos.yginfo.net/grubdos.htm


OK, I just updated the above webpage. Take another look.

Many thanks.

I forgot to mention another point that could be changed:
as a diff patch to the grub-0.93 release
change to
as a diff patch to the grub-0.94 release

However, this is not very important; it's fine even if you don't change it.

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

Oh, and this sentence too:

Tinybit, a nice Chinese person, ported the GRUB executable program and installer to DOS. THIS IS A VERY GOOD NEWS FOR ALL DOS USERS!

It would be better to remove it (it doesn't feel very comfortable to mention a particular person's name). For the sake of keeping the webpage clean and concise, it's better to remove it.

GPL projects are usually considered to belong to everyone, and to have no national boundaries. Also, a GPL project is usually not entirely one person's affair, but something multiple people participate in. So mentioning one particular person is not very appropriate.

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

Also, GNU GRUB FOR DOS in the title seems better changed to GRUB for DOS.

1. GRUB for DOS is not a GNU project (it is only secondary development based on GNU GRUB)

2. After changing it to GRUB for DOS, it will no longer be confused with GNU GRUB.

3. The wording GNU GRUB for DOS easily causes ambiguity: a. GNU (GRUB for DOS) and b. (GNU GRUB) for DOS. The latter understanding is closer to correct, but the name of our project is not GNU GRUB for DOS, but GRUB for DOS.

OK, I've revised it again.

GNU GRUB for DOS ----> GRUB for DOS

Also, I wonder whether BUG reports can be allowed at http://denbbs.2ya.com too?

The FAQ and other documents can be improved later on.

Budian: those have just been changed. Take another look.

Thanks, wengier

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

Also, thanks to brother windrv for the information about BOOTPROG. It's a good piece of software.

Today I specifically looked at the introductory materials for GRUB and learned that GRUB can use stage1.5 to boot stage2. Even if stage2 has been defragmented into fragments, that does not matter. And our current bootgrub (if placed in the MBR) can already solve a similar problem under NTFS systems. So the MBR-related issue can actually be considered almost done. In view of this, our follow-up work on the MBR will slow down and be done gradually.

Our approach is similar to STAGE 1.5. The differences are:

1. stage1.5 varies depending on the file system, while we have only one program that can adapt to any file system, as long as we support that file system (the first ones supported are only Microsoft's FAT/NTFS).
2. stage1.5 is written in C and takes up a lot of space. We use ASM and can make it as compact as possible.
3. When partition software is used to adjust partitions, stage1.5 may become invalid, but our program can adapt to such adjustments.
4. Following the convention of Microsoft DOS, we place the kernel file GRLDR in the root directory rather than the /boot/grub directory.

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

Hehe, GRUB is looking more and more like an operating system. Unlike a real operating system (for example DOS), GRUB does not modify the BIOS interrupt vectors. Real operating systems must all be installed on some fixed partition, while GRUB can move around, has no fixed place, can live parasitically in any partition, and can make itself at home everywhere.

The following is quoted from 不点 on 2004-2-19 14:46:39:
Thanks wengier

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

Also, thanks to brother windrv for the information about BOOTPROG. It's a good piece of software.

Today I specifically looked at the introductory materials for GRUB and learned that GRUB can use stage1.5 to boot stage2. Even if stage2 has been defragmented into fragments, that does not matter. And our current bootgrub (if placed in the MBR) can already solve a similar problem under NTFS. So the issue related to the MBR can actually be considered almost done. In view of this, our follow-up work on the MBR will slow down and be done gradually.

Our approach is similar to STAGE 1.5. The differences are:

1. stage1.5 varies depending on the file system, while our program is only one, and can adapt to all file systems, as long as we support that file system (the first ones supported are only Microsoft's file systems FAT/NTFS).
2. stage1.5 is written in C and takes up a lot of space. We use ASM, so it can be made as compact as possible.
3. When partition software is used to adjust partitions, stage1.5 may become invalid, but our program can adapt to such adjustments.
4. Following Microsoft's DOS convention, we place the kernel file GRLDR in the root directory, rather than the /boot/grub directory.

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

Hehe, GRUB is looking more and more like an operating system. Unlike a real operating system ( for example DOS&nbsp, GRUB does not modify the interrupt vectors of the BIOS. Real operating systems all have to be installed on some fixed partition, while GRUB can move around, has no fixed location, and can live parasitically inside any partition, making itself at home everywhere.

Dear TinyBit,

Waiting for your good news!

Your idea is equivalent to: GNU GRUB's MBR (Stage 1) + an ever expanding
Stage 1.5 for all popular partition types = Stage 1+ all-purpose Stage 1.5
put into the first sectors (within 63 sectors limit) of any bootable hard disk.

Is it?

I think it should be able to load up GRLDR independently without relying on
,let's say, NT boot sector or other boot sectors. To boot up these boot sectors
should be the responsibility or task of GRLDR.

So GRLDR could then boot up any OS relying on their own boot sector residing on
their own partition or boot up bootable disk-image files using virtualization commands.

Your idea is equivalent to: GNU GRUB's MBR (Stage 1) + an ever expanding
Stage 1.5 for all popular partition types = Stage 1+ all-purpose Stage 1.5
put into the first sectors (within 63 sectors limit) of any bootable hard disk.

Is it?

Yes.

I think it should be able to load up GRLDR independently without relying on
,let's say, NT boot sector or other boot sectors. To boot up these boot sectors
should be the responsibility or task of GRLDR.

That depends on how you understand it. In actual use there is no problem at all. For FAT12/16/32, we use our own code entirely to boot GRLDR, while for GRLDR inside NTFS, we borrow the program in NT's bootsector to boot GRLDR. We only make use of the existing boot sector in the NTFS partition because we do not want to write an NTFS boot sector ourselves. (Writing such a bootsector program would be rather difficult.) Once GRLDR has been booted, it can of course boot the NTFS bootsector; at that time, using the chainloader command, what gets booted will be the usual NTLDR.

Do not confuse these two things: BOOTGRUB and GRLDR:

The sole purpose of BOOTGRUB is to find GRLDR and hand control over to GRLDR. Therefore, it does not matter by what means BOOTGRUB finds GRLDR. After GRLDR takes over control, GRLDR does not know which partition it is on, nor how it was booted. It was simply placed into memory by BOOTGRUB; it does not know its exact location on disk. GRLDR only runs its own code and does not care about anything else. Therefore, just like ordinary GRUB, it can use the chainloader command to boot any operating system, and of course it can also use any map command to emulate disks.

The division of labor between BOOTGRUB and GRLDR is very clear. BOOTGRUB only looks for people; GRLDR only does the work. Neither of them repeats things the other one also does. The one looking for people has no idea what the person being sought can do or wants to do. The person who is found is fully capable of doing his own work, but he will not know how he was found, nor who found him, from where, or by what method. He is like someone delivered to the workshop in a prison cart to do work.

So GRLDR could then boot up any OS relying on their own boot sector residing on
their own partition or boot up bootable disk-image files using virtualization commands.

Of course yes. The current BOOTGRUB and GRLDR, in a certain sense, have already (partly) achieved this goal. Its limitation is: GRLDR needs to be on a primary partition containing an NT BOOT SECTOR.

When I restored a boot-file image with xp into Vpc, even without an NT partition, it could still boot from Boot.ini. A question for big brother Budian: can the Splashimage command only be used on the command line? Why can't it start when put in the menu? The background picture is really nice, it's just a pity that both the background and the text are gray, so it's a bit tiring to look at, hehe...

The following is quoted from cavvie on 2004-2-10 1:14:12:
Chinese support is probably rather difficult, and there's not much point in it either

Actually, it is said that the BluePoint Linux distribution already added Chinese support to GNU GRUB, and even localized some commands. There should be related patch programs online.

The following is quoted from xiaojun on 2004-2-22 2:12:19:
When I restored a boot-file image with xp into Vpc, even without an NT partition, it could still boot from Boot.ini. A question for big brother Budian: can the Splashimage command only be used on the command line? Why can't it start when put in the menu? The background picture is really nice, it's just a pity that both the background and the text are gray, so it's a bit tiring to look at, hehe... 

It's fine without NTFS, but without an NT boot record sector it definitely won't work. On a FAT32 partition, the NT installer has already created an NT boot record. The first sector of that FAT32 partition contains the NTLDR signature, not the usual DOS/win98 boot sector.

Also, I just tested it in VMWARE, and the spalshimage command can also be used in the menu. I put it before the timeout command, and the image was already displayed.

The robin picture is only for testing. I didn't make it myself; it was a freely downloadable picture from the Internet. I don't know how to make pictures. This picture is very small; actually, before this I had never tested its effect.

This is how I put it in my menu, but I still have to type the command before the background appears Where is the mistake?
# This is a sample menu.lst file. You should make some changes to it.
# Added items for installing GRUB to MBR

color blue/cyan yellow/cyan
splashimage (hd0,0)/boot/grub/robin.xpm.gz
timeout 0
default 0

Thanks