中国DOS联盟

The following is the statement from Budian at 9:45:19 on April 8, 2005:
I'm really sorry. Except for email and the forum, I don't use anything else. You can contact me via the private message method of this forum. The email method is not good, I only check my email once a month. I come to this forum relatively timely, almost every day.

PE format belongs to Windows programs. In Windows, the running programs are all in protected mode, and grub.exe needs to work in real mode. It's not easy to switch from Windows protected mode to real mode. If this is realized, it will be a great breakthrough. I used to call GRLDR "grub for ntldr" instead of "grub for windows", the reason is that grldr can only run under NTLDR, it can't run under Windows. If you can realize the switch from protected mode to real mode, then the GRUB you make can be called GRUB for WINDOWS. The grub4lin I made is GRUB running in real mode from protected mode under Linux, it can be called grub for linux.

As for the icon, you can like whatever you like, I don't have artistic cells, I can't help you. The key is to solve the CPU mode switching, if this is solved, it doesn't matter whether there is an icon or not. I think it's very difficult, I hope you can succeed.

Dear Tinybit,
I have sent you an email. And I repeat my question addressed to you therein as follows:
The map command does not seem to work when grub4dos is used in non-emulation mode. For instance:
map (cd)/image.img (fd0)
does not seem to work.
May be the map command originally is designed to with with FAT/NTFS partition. Is it possible to make it work under iso filesystem format? Or is it too time-consuming or too large a piece of work to do so?

The map command cannot be used for CDROM files in no-emulation mode, which is normal. The reason is that the no-emulation mode specification was formulated by Microsoft, and it is an incompatible specification. The sector size is 2048 bytes instead of the usual 512 bytes. Although the sectors of the no-emulation mode CD can be read using the LBA mode of int13, the obtained sector size conflicts with the sector size after we simulate it as a disk, so it cannot be used after simulation, which is an invalid simulation.

If the (cd)/image.img file is not too large and your memory is sufficient, you can consider using the --mem parameter of the map command to simulate in memory, which is definitely successful:

map --mem (cd)/image.img (fd0)

There are serious problems with grldr. My Super Emergency Disk hard disk version is based on the final version 0.2.0. Netizens reported bugs saying that grldr doesn't work on some versions of WIN2000 and some XP SP2, and "extended or non-MS: skip" appears. The solution that surprised me is: overwrite the files with the same name of NTLDR and BOOTFONT.BIN from XP SP1 to use GRUB. I analyze that maybe the compilation environment of grldr is XP SP1. I hope the code of grldr is more rigorous to solve this bug. (0.4.0 hasn't been tested)

TO gmy: Is the GRLDR you are using a newly compiled one? TO 不点: Encountered some problems during the use of QEMU and request help: 1. After booting, cannot use GHOST to quickly install the system on the virtual hard disk image. 2. Cannot boot the 24-bit true color ISO generated by EZBOOT. 3. Not sure if the physical hard disk of the local machine can be mounted as the hard disk of QEMU.

The final version of 0.2.0 and the preview version of 0.4.0 were released on the same day. The reason for this is to let everyone switch to the 0.4.0 version.

0.2.0 will no longer be updated, that is to say, there will be no version 0.2.1. When reporting bugs, generally as a routine, it is required to first try the latest version.

Since 0.2 is no longer under development, I have forgotten whether there are bugs in the code part of finding in GRLDR. I remember that the 0.4 version seems to have corrected some errors.

However, your bug report doesn't seem to be accurate. This error: extended or non-MS: skip indicates that the partition type involved is not a known NTFS/FAT type. Even if you replace files like NTLDR, it won't help, because this information is sent by GRLDR. There are other error messages before and after this error. Without providing these information, it is impossible to judge where the error occurs. Hope to get an accurate report.

hnlyzhd: Replied to the QEMU question via text message.

^_^, not clicking your phone number is?!!

Just now someone asked about my guestbook. I said I'm really slow to accept new things. I don't have QQ instant messaging, nor a blog, nor a mobile phone. Others all say it's hard to find me. But if possible in the future, I might consider opening a guestbook, but I don't dare to open it because I might not always go to check it.

Esme said that FTP is not accessible, so now you can download from http://grub.linuxeden.com/wakka.php?wakka=UploadFile.

Additional information: It seems that there has been a large-scale internet blocking action recently. Try the following download address (not guaranteed to always succeed):

ftp://upload:upload@202.114.23.161/grub_for_dos-0.4.0.tar.gz

GRUB is indeed refreshing. DOS (6.22 or 7.1) remotely booted from Netware cannot use GRUB. The error:
Programs such as TSRs and device drivers may also change the BIOS interrupt vector table.
Make sure those programs are not running, then try again.

Please ask GONGXP to elaborate on the detailed information such as the startup process of NetWare. I have never used NetWare.

If I know the operating mechanism of NetWare, then I may be able to know whether the future grub.exe can support it.

Also, please also talk about why NetWare is used and its uses to help me further understand it.

I am relatively layman in network, and this question can also be answered or solved by GANDALF, BEAN123 and others.

The pre7 version of grldr I downloaded can't boot the Wengier's Super Universal MS-DOS 7.10 bootable disk image. This bootable disk image is also booted by grub. But the screen display shows that grldr only boots to stage1 and then there's no response. There was no such problem with previous versions.

Note that GRLDR has nothing to do with stage1. GRLDR does not use stage1 and stage2; those that use stage1 and stage2 must be old versions of GNU GRUB, which is a non-recommended boot method.

As long as GRLDR gains control and enters the GRUB environment, that's GRLDR's success. After entering the GRUB environment, if it can boot an operating system in a disk image, that's the success of GRUB for DOS. As for various errors in that disk image, such as system freeze, there may be multiple reasons. This may be related to the boot method, such as whether the map command has the --mem parameter and whether your BIOS supports the INT13/EAX=e820h call; it may also be related to the program code in that disk image, such as whether those program codes support the INT13/EAX=e820h call specification. The old version of GNU GRUB in the "Super Universal MS-DOS 7.10 Boot Disk" very likely really does not support the INT13/EAX=e820h call specification, because after all, it was released many years ago and is too outdated.

The possibility of GRLDR itself having an error is relatively small.

NetWare is a server operating system booted from DOS. At least two computers are needed for remote booting: one runs NetWare, and the other has a network card and an RPL boot chip. On a DOS computer, make an image file of a bootable DOS floppy disk and store it on the NetWare server. Then, the computer with the network card having the RPL boot chip can choose to boot remotely (via INT19 interrupt) and start the DOS system on that floppy disk. This DOS system can boot Windows 98, Windows ME, can also start Linux via loadlin, and can start Windows CE via loadce. However, this DOS "pollutes" the interrupt vectors of the BIOS. Can GRUB.exe run on this DOS?

So far, for diskless booting of DOS and remote booting of DOS, the best network operating system is still NetWare, which is widely used in securities companies.

Indeed, you are a professional expert. Thank you.

According to your description, the computer accesses a remote DOS floppy disk through the network card. I guess there should be an emulation here:

The first possibility is to directly load the remote DOS floppy disk into the extended memory of the local machine, and then implement the function of "simulating a floppy disk with memory".
The second possibility is that the processing program of INT13 directly redirects the machine's access to the floppy disk to the network, that is, directly to the remote floppy disk. This method does not occupy the physical memory space of the local machine.

No matter which situation it is, as long as these operations are performed inside the BIOS, then GRUB.EXE can run. The error message you mentioned above indicates that these operations have exceeded the scope of the BIOS and entered an ordinary user program.

Whether DOS is booted remotely or not, it will contaminate the BIOS interrupt vectors. When grub.exe starts running, it will check which interrupt vectors have been contaminated. If these interrupt vectors are not important, it will ignore the contamination and continue running GRUB. If it is found that the key interrupt vectors are contaminated, then grub.exe will take a series of steps to automatically detect the original values of the contaminated interrupt vectors. If the original values are found, then the values are restored and the restoration is declared successful, and GRUB continues to run. If the original interrupt vector entry address value cannot be found, then an error message is printed and it returns to DOS.

1. Which are the key interrupt vectors?

int08, int09, int0a, int0b, int0c, int0d, int0e, int0f
int70, int71, int72, int73, int74, int75, int76, int77

These 16 interrupts are hardware interrupts, which are the most critical interrupt vectors considered by grub4dos. In addition, grub4dos also considers that many interrupts below int20 are also key interrupts. For example, int13, int10, int16, etc.

Grub4dos believes that the above interrupts must be correctly restored to the original entry addresses of the BIOS. If one restoration fails, it will be considered a failure, and thus it will refuse to enter the GRUB environment.

2. How to judge whether the interrupt entry address of an interrupt vector has been contaminated?

When the entry address is in the code space above c000:0000, it is considered that the interrupt is the original BIOS interrupt and does not need to be restored. Otherwise, if it is a value lower than c000:0000, it is considered to be contaminated.

I hope this information can bring you some help. If you can solve this problem, it is also hoped that you can share the experience with everyone. If you can provide a patch or something, I will of course be very welcome.

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

If there are config.sys and autoexec.bat in the DOS floppy disk provided by your (server side), then you should ensure that there are no TSR resident programs in them; otherwise, GRUB.EXE will not run, and the error displayed will be like the one you posted earlier. Even if you run DOS on the local machine, there is this requirement. You may have known this, but it is still reminded just in case you didn't know it before.