中国DOS联盟

wangsea：

> Can you develop a streamlined version of Grub?

My current response is no. The reason has been mentioned earlier. To truly streamline it on a large scale, one would have to switch to assembly language, and it's possible to streamline GRUB to within 30K. However, you can try gandalf's newly created avldr.exe for a taste.

> Function: A command-line version of Grub XXX.img (no menu.lst needed)

The problem here is (as mentioned earlier) that if XXX.img is loaded into extended memory, it may fail. If there are no memory management programs like himem at this time, it might be achievable, but in the presence of such memory management programs, it becomes very complicated and difficult. That is, the goal of copying XXX.img to the top of physical memory may not be achieved, and the copying process may fail (for example, if it overwrites critical XMS memory that has already been allocated). If someone can study the extended memory specifications under DOS such as XMS in detail and can successfully implement the copying, then they may be able to make the tool you mentioned. I support someone doing it, but I don't have the time or interest to do it. Even without considering the impact of memory management programs, I don't want to do it (I think its significance is not very great).

If you mean without using extended memory, only using disk media emulation (equivalent to no --mem parameter), and assuming that XXX.img is continuous. This can meet your requirement, but there are still the following problems:

If you mean using the grub command to implement emulation and then return to the original DOS, then this is deceiving DOS. Note that DOS can sometimes be deceived and sometimes not.

If your system has a real floppy drive, you can deceive DOS by emulating (fd0) floppy disk with XXX.img. If your system has n hard disks and you use XXX.img to emulate the (n + 1)-th hard disk, this may not work. Even if you modify the bytes of the number of floppy disks and hard disks in the BIOS data area at the same time, it won't work. This is because DOS has determined the total number of disks at startup, and it may not recognize newly added disks after startup.

There is also a problem that it is very easy to crash. The possible crash reasons I can think of are roughly in the following two aspects:

1. If the emulation program does not handle the arena structure of DOS conventional memory well, it will directly crash.
2. If the currently used disk by DOS is emulated, then after emulation, DOS may make a mistake because it cannot find the content on the original real disk, and even crash.

In view of these complex reasons, I do not advocate others to develop such things. Of course, if there are really DOS experts willing to do it, then these problems may all be solved, although it is very difficult.

Buddy:
I think maybe I didn't express my meaning clearly. For example, I have a batch file: menu.bat
grub.exe --config-file=(hd0,0)/test/menu.lst
My menu.lst is like this:
timeout 0
default 0
kernel (hd0,0)/test/memdisk.gz
initrd (hd0,0)/test/Grub.zip
boot
The content of the above batch file is just to start a simulated disk to enter the system (and not return), so I think if I can remove menu.lst (if I just want to simulate a disk and don't use the menu function of Grub, then why write menu.lst?), and directly enter in the command line: grub.exe -mem -fdo xxx.img would be great.
Since grubfordos can call menu.lst in the batch file to directly simulate the disk, then it should be possible to give parameters in the command line, right? (Even if there are some directory path restrictions, it's worth doing this!)

You mean embedding menus or commands directly into the command line. That's interesting and should be achievable. Thank you for providing this suggestion. Please pay attention to the development of grub.exe.

Thanks, looking forward to new features of grub.

Can the bootable USB drive be added to the GRUB menu? The key lies in the non-standard support of the BIOS for USB booting, and some are just a sham (USB-FDD, USB-HDD, USB-HDD)

Some BIOS does not support booting from USB drives. Can GRUB boot from a USB drive? (This of course requires pre-loading the USB drive driver in GRUB)
Also, can GRUB currently support multiple optical drives?

There seems to be, --enable-preset-menu=FILE
preset a menu file FILE in Stage 2But if it contains a menu, when distributing to others, it will be troublesome to modify

The following is the statement made by gmy on April 29, 2005 at 23:38:13:
Can we add USB drive booting to the GRUB menu? The key is that the BIOS support for USB drive booting is non-standard, and some are just a formality (USB-FDD, USB-HDD, USB-HDD)

USB-ZIP is the most promising bootable method, but some BIOS do not support GRUB booting. You can use the method of installing to a floppy disk, install GRUB to the USB drive, and then test. I only successfully booted on ASUS and IBM machines

Still about the problem that DOS (6.22 or 7.1) remotely booted from NetWare cannot use grub.exe. The situation is the same when trying Avldr. The DOS remotely booted from NetWare changes the BIOS vectors, int19, and int13. Is it possible to improve grub for dos to be able to be used in these "polluted" BIOS DOS?

The issues related to U disks/cds of gmy and GOTOmsdos, as I said before, I have no ability to solve.

Regarding the issues of GONGXP, maybe we can solve them together in the future, but currently I have no development plan. If we improve our detection algorithm in the future, then this problem may be solved incidentally. I won't specifically start to solve this one problem. The improvement of the detection algorithm is a huge change, with quite a lot of development difficulties, and it won't be developed preferentially. It would be very good if it can be done by the end of 2006. If you can't wait, you can try to modify dosstart.S by yourself to achieve your purpose.

Where have you been? Come often, or go to Wuyou! Many people are looking for you!

Recently, everyone has been working on enhancing the functionality of grub.exe mentioned by wangsea. I really didn't expect it to be very troublesome, with many difficulties to overcome, but now it's done and implemented in 0.4.1pre5.

The specific implementation is as follows: No new command-line parameters are added to GRUB.EXE; it still uses the old --config-file=FILE format, but there is a new interpretation of FILE. When FILE starts with the left parenthesis "(", or the slash "/", or the plus sign "+", it is still interpreted as the name of a configuration file as before. When FILE does not start with any of these three characters, it is considered a command sequence, that is, it is considered that the content of the configuration file is directly embedded at the FILE position. Note that if there are more than one command written at the FILE position, they should be separated by semicolons. GRUB.EXE will automatically convert "semicolons" into "newline characters" and then hand them over to the main program of GRUB. It is best to add double quotes around FILE. For example:

grub.exe --config-file="root (hd0,0);chainloader +1"

You notice that the final boot command can be omitted. You can even use

grub.exe --config-file="halt"

to shut down the machine, or use

grub.exe --config-file="reboot"

to restart the machine.

That is to say, at the FILE position, you can fill in any command that GRUB can recognize.

Support for the new feature of not clicking to provide! That is to say, you can load the FDD image from the command line! ^_^, that's great.

Thanks to Budian, is it under the Grub address provided on the first page? I'm really eager to try it. There's a suggestion: Can you separately develop a version of grubfordos or gurb that, after bringing in a certain parameter, can achieve the default boot of the img in the same directory as grubfordos without filling in the absolute disk path like root (hd0,0) (let the program complete this operation). If the path specification fails, return an error message and then not start Gurb. I feel this would be more convenient.

Just did a test just now, and successfully booted the image.

My parameters:
grub.exe --config-file="map --mem (hd0,0)/gxms.img (fd0);map --hook;chainloader (fd0)+1"

The image used is the Ghost perfect Chinese shell I wrote (http://wangsea.ys168.com/ under the Ghost perfect Chinese shell directory gxms_hpa.rar)

Found a problem:
1: The first time I forgot to specify (hd0,0)/gxms.img and directly wrote gxms.img, then after the menu came out I edited it correctly and booted into the image, but it froze in the graphical interface I wrote.
2: If the parameters are specified correctly the first time to enter the image, there is no problem.

But no matter whether the parameters are correct or not, the floppy drive has been beeping before grub boots the image, and it stops until the parameters appear on the screen.

Once again, thank you Budian for providing such a good function for us. Looking forward to a method to avoid this problem.

In addition, because of the character limit of the DOS command line, which is what my upstairs wanted to say, can there be a default current path, so that more command parameters can be written.