中国DOS联盟

Thanks to WINDRV and Budian!!

WINDRV's method hasn't been tested yet. I'll reply after testing.

Budian:
Actually, the main purpose for me to use GRUB is that GRUB can restore the BIOS environment polluted by DOS. Restore it to a real BIOS environment. Because the program I want to boot may run based on the BIOS (not based on DOS). However, my computer is diskless, and I must boot from the network card ROM first, and the code of the network card ROM will also pollute the BIOS environment.

My idea is like this: Boot the diskless computer from the network card ROM, start diskless DOS, after loading the network card driver under DOS, download the sys.img I need to the virtual memory disk (XMSDSK virtualized memory disk) in DOS. Then, I use a DOS program to exit the code of the network card ROM. This program is ready-made and has been tested.

At this time, the state of the diskless machine is: DOS has been started, the DOS files are placed in the memory disk (XMSDSK virtualized), and this DOS is a relatively clean DOS (because the network card boot code has been exited by my exit program). At this time, there is no longer the A drive virtualized by the network card boot code in DOS.

In this case, I need to use GRUB to call sys.img in the DOS memory virtual disk to simulate booting.

Budian: If you have time and can test in an environment, do it like this: You use a disked computer to boot into a DOS and load XMSDSK to simulate a DOS memory virtual disk, then copy a FLOPPY.IMG to this memory disk. Then the environment is ready. Now what needs to be done is:
1: Compile a DOS program to push the FLOPPY.IMG in the XMSDSK memory disk into the physical memory you specify.
2: Virtualize the physical memory you just specified as a hard disk and tell the BIOS.
3: Use GRUB to call this newly generated hard disk and boot from it. Or call this FLOPPY.IMG inside and boot from it.
4: Done.
That is to say, my requirement has nothing to do with whether it was ever started with a diskless boot chip, because I can exit the boot chip program in DOS, which is equivalent to not having used diskless boot.
For example, I boot into a DOS with a boot CD, which will generate a virtual A drive. At the same time, I load XMSDSK to generate a virtual DOS memory disk. Then, suppose I run a DOS program to exit the control code of the boot CD, and the virtual A drive generated by the boot CD will naturally disappear. At this time, my computer is equivalent to a normal disked boot, equivalent to not having been booted with the CD. In this case, I still need to use GRUB to call FLOPPY.IMG in the DOS memory disk (generated by xmsdsk). However, GRUB cannot point to the DOS memory virtual disk. GRUB does not support the format MAP J:\FLOPPY.IMG (FD0). So, we need another program to push the FLOPPY.img in this memory disk into the specified physical memory segment, then virtualize this physical memory segment as a hard disk and boot from it. Or call this FLOPPY.IMG inside and boot from it. ---------Of course, this is just an example. In fact, we don't have a program to exit the control code of the boot CD, but we have a program to exit the control code of the boot chip.

hnlyzhd:
1. Can the existing GRLDR implement copying its own boot code to the MBR? Also, the hotkey issue during startup I mentioned last time. It's best to specify a hotkey, and one second is enough, not too long to wait. A random key isn't safe either. If there's no hotkey, the GRUB menu will appear every time. During startup, there must be a waiting time. If there isn't, you won't have time to press your hotkey before moving on. This waiting time is 5 seconds, which is relatively reasonable. If it's only one second, it's also easy to cause the key press to be too slow and ineffective.
Currently, the third byte of GRLDR is 0x80 by default, which prohibits the function of preferentially booting the previous MBR. To enable this function, you must manually change the third byte of GRLDR to 0. Although this program is simple, it's sufficient. There are few people who want to preferentially boot the previous MBR, and most people want to preferentially boot GRLDR, so the default value caters to those who want to preferentially boot GRLDR.
If, as you said, there is no waiting time and a hotkey is used, then either you can't press the hotkey in time before the program runs, or you press the hotkey too early. At this time, some BIOSes think the keyboard operation has failed, think the keyboard is malfunctioning, and forcefully lock it and not run. So, it's better to give a prompt like the current one. When you see the prompt, press any key, which is safe. The installation command to write GRLDR to the MBR will wait a bit more. I considered that it's more appropriate to implement this after supporting the LINUX partition. At that time, this issue can be considered comprehensively. If it's done now, it might need to be corrected later, which is more laborious.
2. Regarding GRUB running from ROM, I think it should be possible, just like FREEDOS in ROMOS booting in BIOS. I think it's not very feasible and not very necessary. We are not ROM manufacturers, let ROM manufacturers do it. However, even for ROM manufacturers, it shouldn't be easy because the size of GRUB is too large.
3. Can GRUB's CHAINLOADER boot the PCI module in BIOS? In this regard, the emulator of BIOS is still a blank. If relevant modules are needed, I can provide them to you, including DOS and hard disk protection modules.
I don't quite understand what you mean here. I don't know what the use is to boot these modules. In theory, ROM modules can only be uniformly called by BIOS. When entering the user program, the ROM modules should not be called again because the ROM modules are not designed to be called by users. At the moment when GRUB takes over control, the BIOS startup has been completed and the user program has started. All ROM modules have completed their initialization and recorded relevant information in the interrupt vector table, BIOS data area, and extended BIOS data area, so there's no need to execute them repeatedly, or repeated execution might cause conflicts. Of course, under GRUB, you can indeed execute any command, but you always need to know the memory address of the command you want to execute, that is, where the destination of the JMP jump instruction you want to execute is. If you can determine this, then implementing it with GRUB is very easy.

areyong：
Finally, I understand what you mean. I don't have a clear idea yet, but I have some initial intuitive thoughts, which are stated as follows.

According to your description, you can access your virtual disk and the SYS.IMG file in it under DOS at this time. However, there is an important issue. I wonder if you have noticed that the physical memory location of this memory disk may not be continuous. The second question is, where exactly is the physical memory address occupied by this memory disk? If these two points cannot be determined, I'm afraid we won't have subsequent means.

Assuming that in the most ideal case, the physical memory space occupied by this memory disk is a continuous block and exactly occupies the top of the physical memory, then in this case, we may be able to relatively easily add some parameters to GRUB.EXE to pass the address of the memory disk, so that we can access any file in this memory disk, including the sys.img file, under GRUB.

If it's too complicated, it may be difficult for us to do.

++++++++++++++++++++++++++++++++++++++++++++

I don't quite understand what you mean here. I don't know what the use is of starting these modules. In theory, ROM modules can only be called uniformly by the BIOS. When entering the user program, the ROM modules should not be called again because the ROM modules are not designed for user calls. At the moment when GRUB takes over control, the BIOS startup has been completed and the user program has started. All ROM modules have completed their initialization and recorded relevant information in the interrupt vector table, BIOS data area, and extended BIOS data area, so there is no need to execute them repeatedly, or repeated execution may cause conflicts. Of course, under GRUB, you can indeed execute any command, but you always need to know the memory address of the command you want to execute, that is, where the destination of the JMP jump instruction you want to execute is. If you can determine this, then it is very easy to implement it with GRUB.

++++++++++++++++++++++++++++++++++++++++++++++

The BIOS PCI standard ROM module is generally that after the BIOS is initialized, if a conforming ROM module is found, the ROM module is loaded into memory 0000:d800 (in units of 32K??? I'm not sure), then the BIOS makes a jump, jmp 0000:d800, and hands over control to the ROM.大致 like this. You don't need to care about the BIOS data area and extended BIOS data area, etc.





++++++++++++++++++++++++++++++++++++++++++++++

Assuming that in the most ideal case, the physical memory space occupied by this memory disk is a continuous block and exactly occupies the top of the physical memory, then in this case, we may be able to more easily add some parameters to GRUB.EXE to pass the address of the memory disk, so that we can access any file in the memory disk, including the (sys.img file), under GRUB.

+++++++++++++++++++++++++++++++++++++++++++++++

You know, we have been able to read the SYS.IMG file in the XMSDSK memory disk under DOS. We don't need to care whether this file is connected together in the physical memory space. We can compile a program under DOS to force the sys.img to be pushed into our own defined physical memory space and be continuous, isn't that okay.



Another: I have used the method mentioned by WINDRV to implement my previous requirement with GRUB with network function. I'm very happy!

But this GRUB with network function is based on GRUB4DOS 0.2.0 version and does not have the "--MEM" function. A bit regrettable.



There is also a small problem. After starting WINXP with GRUB, WINXP will find two floppy drives but neither can be used. It shows that the floppy drive light flashes and then says the floppy disk is not formatted. In fact, the floppy disk is good. I don't know if the floppy drive can still be used after starting WIN9X with GRUB? Is there a good solution?

> But this network-enabled GRUB is based on GRUB4DOS version 0.2.0 and does not have the "--MEM" function. A bit of a pity.

It doesn't matter. Below version 0.2.0, you can use the memdisk method to achieve a similar function to --mem.

> We don't need to care whether this file is contiguous in the physical memory space. We can compile a program under DOS to forcefully push sys.img into our own defined physical memory space and make it contiguous, right?

The key is that under DOS, it may be根本 impossible to program to achieve your purpose. If you don't know the physical address of the memory disk virtualized by xmsdsk, you may overwrite the virtual disk during the process of copying sys.img to the destination you determined, thus making the copy fail.

Another problem is that XMS memory may not be equal to physical memory. The maximum memory accessed by XMS may not be equal to the physical maximum memory. This is probably two very different concepts. If you can be sure that XMS memory is the same as physical memory, then it may be easier. If they are not the same, then it is very difficult for you to copy SYS.IMG to the specified address in physical memory.

Since your problem has been solved through other means, then I think this discussion doesn't need to continue. As mentioned above, although it seems easy to solve on the surface, in reality, there are still many difficulties to overcome to solve it. On the surface, we don't need to understand the details of the XMS specification, but in reality, since it involves memory operations, it is necessary to understand the XMS specification. If we have to deal with the XMS specification, this problem cannot be regarded as a simple problem, and we don't need to go to so much trouble to get such a dispensable function.

> After using GRUB, after starting WINXP, WINXP will find two floppy drives, but neither can be used.

After GRUB virtualizes the disk, XP does not recognize the virtual disk. XP does not recognize anything in real mode, and GRUB's virtualization is exactly a real-mode concept. Any behavior of XP is XP's own business, irrelevant to GRUB. Since it is already known that XP does not accept real-mode things, the simulation implemented under GRUB clearly does not support XP.

Under win98, the disk simulated by --mem can be accessed safely. The simulation without --mem may bring serious problems, such as the possibility of losing all disk data, which has been reminded in the readme file.

Accessing the floppy drive under win98 is no problem.

T Bu Dian
I have thought of various methods to add GRUB in the BIOS to achieve it. GRUB is really a great thing.
Your QLINUX's IMG can't find the GRLDR file on the hard disk. If you can make an IMG and put the first eight sectors of your existing GRLDR into the boot sector of the IMG so that it can find the GRLDR on the hard disk, then I can use other methods to generate a BIN file and add it to the ROM. The second method is that if you have time to make a streamlined GRLDR and put it in the IMG, that would be best. It can start to GRUB alone with the ROM without the file on the hard disk. The size of the IMG can't exceed 64K.

> The IMG of your QLINUX can't find the GRLDR file on the hard disk. If you can make an IMG that embeds the first eight sectors of your existing GRLDR into the boot sector of the IMG so that it can find the GRLDR on the hard disk, then I can use other methods to generate the BIN file and add it to the ROM.

The floppy disk image naturally can't do that because a floppy disk only has one sector, that is, the first sector can store the boot file. What you need is 8 sectors or more. Therefore, to achieve this purpose, a hard disk image is needed. You make a hard disk image file, and note that the number of sectors per track is not less than 8. Then, you follow the method in http://grub.linuxeden.com/ to write GRLDR to this "hard disk", and it becomes a hard disk image.

In addition, if you just want to use these 8 sectors, then you don't need to rely on any hard disk image or floppy disk image. You just need to load these 8 sectors to 0000:7C00 and use jmp to jump here to execute, and then it can find the GRLDR file on the hard disk and floppy disk. It's very simple. You can completely implement this in the ROM because it only occupies 8 sectors of ROM space, that is, 4K, which is very small.


> The second method is that if you have time to make a streamlined GRLDR and put it in the IMG, that would be best. In this way, there is no need for the file on the hard disk, and you can start directly to GRUB with the ROM. The size of the IMG should not exceed 64K.

This is not that easy. Just the driver programs for more than a dozen file systems occupy 80K of space, not to mention other things. To significantly reduce the space occupied by this program, you must use assembly language entirely, but this is also a huge project, and moreover, it's not generally difficult, but very difficult (in my opinion). I think no one is willing to do this.

TO 不点兄：Then let's talk about something else. Regarding the person who scolded you, I have replied. You don't need to care about him so much. Still what I said, if one day you are bitten by a dog on the road, will you care about it? I'm already used to it! Regarding the next idea of GRUB, I'll briefly say. If possible, add file lists, file and folder copy and delete, as well as hide and unhide the last partition, which is the so-called high-end hard disk partition. I wonder if these commands are achievable. If so, it will be a great development for GRUB. I'm waiting for good news.

EZBOOT can generate an ISO with a 24-bit true color boot screen. How is this function achieved? How does it correctly display 24-bit color without the need for a graphics card driver? It seems like a nice function. If it is embedded into MSDOS 7.1, so that the 24-bit color boot screen runs through the entire boot process until config and autoexec are executed, that would be great. I think it is necessary to consider the aesthetic situation of the DOS system.

areyong, I think your idea can be completely solved with the -mem parameter, there's no need to specifically use a virtual memory disk. Just change the grub in your network bios to a version later than 0.4.0, right? It doesn't seem very difficult to change, I guess.

Many software versions reach their best state within one year after the first release. Then the volume gets larger and larger, there are more and more redundant functions, and the core functions regress. For example, why did ACDSee launch the traditional version 2.44 after 7.0 came out? This is a lesson and also an experience. I hope Budian will always review himself and GRUB FOR DOS, because you are the first person who made me have a good impression of LINUX, and everyone likes you. Don't be proud. Currently, I only use 0.2, because there is not a single function added in 0.4 that makes me excited (to be honest). Maybe your thinking is too forward-looking, and I haven't reacted yet.

gmy, version 0.4 is much safer than version 0.2, didn't you find that? The newly added -mem greatly reduces the possibility of damaging the hard disk. Although 0.2 can also use memdisk, it still needs to add this file. If grldr itself has this function, isn't it a good thing? Moreover, the size has not increased, I think this is a quantum leap

Regarding the development of GRUB for DOS, thank you brothers for your opinions and suggestions. I clearly remember that the versions of grub4dos 0.0.x have received a lot of attention. Since Wengier introduced it to foreign websites such as FreeDOS, the people paying attention to it have also extended to foreign countries. The addition of GRLDR is a very late thing. Originally, it was a suggestion from a brother. It seems that this brother is also a member of this forum. When he made the suggestion, I wasn't sure if it would be successfully developed. But now, GRLDR has become a very important aspect, and its importance even exceeds that of grub.exe. Many people in the forum have contributed to the development of grub4dos. Some people's names have been written in the Changelog, and some have not been mentioned at all. It can be said that grub4dos belongs to everyone, and I am just one of them. Of course, this is determined by the nature of the GPL, and the "United DOS Forum" also advocates this spirit.

Different people have different purposes for using grub4dos. Those Linux users may not care much about Grub4dos, or although they care, they only care about individual simple functions. For example, they may not need the disk emulation function. Some people only use grub.exe, and some only use grldr. Naturally, in the eyes of these people, the functions they don't need are all redundant. If they can consider it comprehensively, they will understand that others may have different views from their own. In fact, it is very difficult to have absolute "correct" and absolute "wrong" in the world. They are all different views and feelings from different angles. If everyone is more understanding, then this may be very beneficial to grub4dos. Grub4dos belongs to everyone, and everyone hopes it is good. If we compare everyone to a "family", then grub4dos is like a pot of rice (or a plate of dishes). Some people like to put more salt, and some like it lighter. It is impossible to satisfy everyone. At most, we can take care of the majority. Therefore, some of us need to sacrifice our own needs to meet others' needs. Such a big company as Microsoft produces WinXP, which may not be suitable for everyone. Some people still need DOS/Win98/Win2000.

For any software, there may be many areas for improvement. There is a trade-off in what we develop first. Also, there are issues such as development difficulty, and the personal strengths and hobbies of the developers, etc. Another point is that we are based on GNU GRUB. Some problems suitable for GNU to solve are not very suitable for us to solve.

Of course, everyone's suggestions are, in themselves, an acknowledgment, motivation, and promotion of this software. The purpose is still to hope that this software can be better. gmy has overly praised me. There is no need to be so exaggerated and polite. The efforts are from everyone, and I will work harder. Thank you all.

Asking not to point: Can we develop a streamlined version of Gurb? The function: the command-line function of Grub XXX.img command (no need for menu.lst). If possible, it is best to be in.com format, so that it is more convenient to embed Grub for dos. This may be more conducive to the promotion of Grub for dos (because everyone can directly call it in their own programs to complete the Grub function).

I have two ideas: - From the architecture of Avldr.exe, it can implement FAT1x/FAT32/NTFS/Ext2 partitions to load files of any size, so it can also read disk image files of memdisk and FDD into memory in the way of grub/syslinux, thereby realizing virtual boot; - And, if the FDD disk image file is small, I personally think that Grub4DOS's map can also be used. After all, the low-end memory is only 640KB. If compression technology is used, it is estimated that it is relatively difficult for a 1.44 MB disk. In addition, we seem to be able to "speculate" a bit, make a program similar to NTOSKrnl.exe, let ntldr load into memory from any position, run in protected mode, it can include a resource of FDD image, and then perform (multiple) boot; However, this thing needs to be used on a machine with an NT system installed. Of course, maybe we can streamline the files that need to be loaded. ;-)