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.
> 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.
因为我们亲手创建，这个世界更加美丽。
