China DOS Union

BUG report: grldr has not been able to run on fat16 since the versions after February 1st. It's fine on fat32. Hasn't anyone noticed? ... You all seem to be using it just fine, only mine doesn't work. To prove it wasn't because of my bad luck, I made a fat32 partition, and sure enough there was no problem. But DOS no longer worked.

BTW, grldr is easier to use than grub.exe, because if the machine has things like an ATA or SCSI card installed that need to load their own BIOS, grub.exe(0.2) will complain that a TSR has modified the interrupt vectors and refuse to run. grldr doesn't have this problem.

Thanks for Budian's work.

tmpid:

The new February 13 and 18 versions of GRUB for NTLDR (the February 7 version does not work) definitely support FAT16 partitions. At least on my two hard disks (both C: drives are FAT16) they work normally, and I use it every day (to disable the other hard disk in order to boot WinME)!

However, according to my test results on a real machine, when the GRLDR file itself is stored contiguously on a hard disk whose partition is at least FAT12/16 (that is, when using the blocklist command there is no comma), GRLDR indeed seems unable to boot successfully (the symptom is a black screen and a hang). But if GRLDR itself is stored non-contiguously, then it boots normally.

Also, the new DOS version itself supports both FAT16 partitions and FAT32 partitions. But you said your DOS no longer works; could it be that the DOS version you use is too old?? If so, please upgrade your DOS system.

Thanks to both of you.

Let me explain why GRLDR can no longer run. Before February 1, the first sector of GRLDR copied the corresponding contents of NTLDR, so it ran well. After February 1, NTLDR was no longer used, and instead I used a program written by myself, so some errors appeared. A formally released version cannot copy other people's stuff. I'll check the program again and see whether there are any errors.

When testing, please use the latest BOOTGRUB file (the newer this file is, the better). Then post the version of GRLDR that has no problem. Does everyone think February 1 is really the dividing line?

FAT32 and NTFS indeed have no problem, because the program segment at the beginning of GRLDR was written only for FAT12/16, while FAT32 and NTFS do not use that segment. So only FAT12/16 can have errors.

GRUB.EXE ought to be able to run. If yours cannot run, see whether it is a DOS version issue. The DOS versions we support are limited; MS DOS 3.3, 4.0, 5.0, 6.0, 6.22, 7.0, 7.10, and 8.0 are supported. If there is an unsupported MS DOS version, please report the version number.

GRLDR is started by NTLDR; it runs in a clean environment and has nothing to do with DOS, so it does not complain and can always run.

I really found the problem! Thanks, wengier, for the detailed description of this BUG! Without your description, it would have been very hard to find where the problem was. GRUB for DOS cannot do without you, brother wengier.

In grldrstart.S, there is the following piece of code:

movb %al, %cl
xorb %ch, %ch /* CX = number of sectors read */
shlw $9, %cx /* CX = number of bytes read */
addw %cx, %bx /* ES:BX points to new location */
jnc 2f
movw %es, %ax /* BX=0, exceeds 64K boundary, adjust ES */
addw $0x1000, %ax
movw %ax, %es
movb $0x80, %ah /* adjust max number of sectors to read */
2:

If changed as follows, it should be OK:

movb %al, %cl

/* xorb %ch, %ch */ /* CX = number of sectors read */
Comment out this statement because it is redundant. Keeping it is not exactly wrong either. Note that below there is a shlw statement that shifts left by 9 bits.

shlw $9, %cx /* CX = number of bytes read */
This statement is the key. If the sector count CX＝ 0x80, then after shifting left by 9 bits, CX becomes 0!!!!

jz 3f
When CX＝0, jump to label 3: to execute the statements that adjust ES.

addw %cx, %bx /* ES:BX points to new location */
If CX is 0, adding it to BX cannot possibly produce a carry. Executing the JNC below will jump directly to label 2:.

jnc 2f
3:
movw %es, %ax /* BX=0, exceeds 64K boundary, adjust ES */
addw $0x1000, %ax
movw %ax, %es
movb $0x80, %ah /* adjust max number of sectors to read */
2:

Under ftp://ftp.cosoft.org.cn/incoming/ there are already too many GRUB files, it feels a bit like garbage. So I'm a little afraid to upload there. Can anyone provide another upload space, temporary? Because there have been a lot of changes recently, I don't want to upload to cosoft's valuable space for every tiny little change.

If there is no other upload space, then either wait and update everything together next time, or trouble you two brothers to compile the update yourselves.

Going a step further, I guess that when NTLDR is physically arranged as follows, NTLDR (Microsoft's NTLDR) will also hang. Because it seems that the NTLDR program also has a BUG.

The first part is x contiguous sectors, the second part is y contiguous sectors, the third, fourth, ... parts arbitrary. Here x is between 1 and 127, and y is greater than or equal to 128.

This BUG only shows up under FAT12 and FAT16 file systems. There is no problem under FAT32 and NTFS.

The following is quoted from 不点 at 2004-2-28 19:49:44:
There are already too many GRUB files under ftp://ftp.cosoft.org.cn/incoming/ 之下已经有太多的 GRUB 文件了，有点垃圾的感觉。所以，我有点害怕上载了。谁能提供一个别的上载空间，临时的？因为最近有很多的修改之处，所以不想为一点点修改而上载到 cosoft 的宝贵空间上 it feels a bit like junk. So I’m a little afraid to upload there. Can anyone provide some other upload space, temporary is fine? Because there have been a lot of changes recently, so I don’t want to upload to cosoft’s precious space for every tiny modification.

If there is no other upload space, then either wait and update everything together next time, or trouble you two brothers to compile the update yourselves.

]

TinyBit:

How about uploading it to the FTP at ipdown.com that I mentioned last time? For example, create a grubdos directory there, and then just upload the GRUB files into it.

All right. Give me an upload password.

OK, the upload password has been sent by private message. Please check it.

Already uploaded.

http://www.ipdown.com/grub4dos/bootgrub
http://www.ipdown.com/grub4dos/grldr

BOOTGRUB is now 3 sectors, that is, 1536 bytes. If it does not work well, then switch back to the previous version, OK.

BOOTGRUB now adds FAT32 boot code. Please place the second and third sectors of BOOTGRUB in the sectors immediately following the hard disk MBR. For now, do not place the first sector of BOOTGRUB into the MBR. It can be called from BOOT.INI. Or you can also use chainloader (...)/bootgrub from grub.

If the second and third sectors of BOOTGRUB are not placed in the sectors immediately after the MBR, it can still work normally, but it will depend on the system having an nt boot sector.

BOOTGRUB is not completely finished. Support for fat12/16 is currently missing. When completed, it will probably be 4 sectors, 2048 bytes.

It is also possible to place the first sector of BOOTGRUB into the MBR. Of course, only the first 446 bytes at the beginning of BOOTGRUB can be placed into the MBR. In other words, the last 66 bytes of the MBR must absolutely not be overwritten (friends unfamiliar with this should stop here and do not act blindly).

－－－－－－－－－－

Please test whether the GRLDR file is normal now.

Also, Microsoft's NTLDR program has no error; I saw it wrong. Do not test it anymore.

Last time I said that after changing to fat32 DOS no longer worked, it was because I forgot to update bootsect.dos.

Some tests I did:

NTBootSector + bootgrub(February 7 version) + grldr(ipdown February 29 version, contiguous blocks) + FAT16 = pass
NTBootSector(change NTLDR->GRLDR) + grldr(ipdown February 29 version, contiguous blocks) + FAT16 = pass

NTBootSector + bootgrub(February 7 version) + grldr(ipdown February 29 version, contiguous blocks) + FAT32 = pass
NTBootSector(change NTLDR->GRLDR) + grldr(ipdown February 29 version, contiguous blocks) + FAT32 = pass

NTBootSector + bootgrub(February 7 version) + grldr(ipdown February 29 version, contiguous blocks) + NTFS = fail
NTBootSector(change NTLDR->GRLDR) + grldr(ipdown February 29 version, contiguous blocks) + NTFS = enters grub command line
(as expected)

NTBootSector + bootgrub(ipdown February 29 version) entirely inside the file system + grldr(ipdown February 29 version, contiguous blocks) + FAT32 = fail
(displays NTLDR not found)
bootgrub(ipdown February 29 version) sectors 2,3 -> MBR sectors 2,3 not tested

Also: I mentioned last time that on some machines with ATA raid cards and similar cards installed, grub for dos version 0.2 cannot run. Version 0.1 does not have this problem, and 1.44M floppy read-only emulation is also normal. I suggest that when grub for dos version 0.2 encounters uncertain situations in the BIOS interrupt vector table, if possible it should retain the most basic boot function of version 0.1, or even retain the standard floppy read-only emulation function of version 0.1, rather than simply exiting grub. Such a design may be more comprehensive. After all, version 0.2 at least gives people the feeling that it is an enhancement of version 0.1. If version 0.1 originally worked well, but after replacing it with version 0.2 it flat-out refuses to work and does not even allow the basic boot function, that is not conducive to promoting version 0.2.

Many thanks to brother tmpid for the strong assistance!

Based on your tests, I think the new GRLDR is relatively normal now. But before you made this post, BOOTGRUB had an error. This morning (March 1) at 9:00 I just updated the BOOTGRUB file, that is, corrected one error. But whether it can actually boot GRLDR, I really have not tested either. The download address of the updated BOOTGRUB file is still http://www.ipdown.com/grub4dos/bootgrub

Also source download:

http://www.ipdown.com/grub4dos/bootgrub.S
http://www.ipdown.com/grub4dos/grldrstart.S

Interested friends can download and study them, and help improve them.


> Last time I mentioned that on some machines with ATA raid cards and similar cards installed, grub for dos version 0.2 cannot run. Version 0.1 does not have this problem,
> and 1.44M floppy read-only emulation is also normal. I suggest that when version 0.2 encounters uncertain places in the
> BIOS interrupt vector table, if possible it should keep the most basic boot function of version 0.1,
> or even keep the standard floppy
> read-only emulation function of version 0.1, rather than simply exiting grub. Such a design may be more comprehensive. Because version
> 0.2 at least gives people the feeling
> that it is an enhancement of version 0.1. If version 0.1 originally worked well,
> but after replacing it with version 0.2 it simply refuses to work, not even allowing the basic boot function,
> then that is not conducive to promoting version 0.2.

As for the situation you mention here where 0.2 cannot run, I feel that it should not have happened in the first place. If 0.1 runs but 0.2 cannot, then this is definitely a BUG. But without further details, it is hard to locate this bug. Could you provide your DOS memory image? That is, capture the 1M memory under DOS control and put it somewhere I can download it.

Update at 4 a.m. on March 2 (Beijing time):

BOOTGRUB and BOOTGRUB.S have just been updated. The download addresses remain unchanged:

http://www.ipdown.com/grub4dos/bootgrub
http://www.ipdown.com/grub4dos/bootgrub.S

The following two files have not changed; they are still the February 29 versions.

http://www.ipdown.com/grub4dos/grldr
http://www.ipdown.com/grub4dos/grldrstart.S

The updated BOOTGRUB is confirmed to be runnable. The original problem was a hidden mistake:

mov ah,8
int 13

The output result of this call is stored in CX and DX, and as a result our BIOS disk number DL got overwritten. Errors like this happen often and are often hard to avoid. It has now been changed to this:

mov ah,8
push dx
int 13
pop dx

Now it's fine.

The following is quoted from 不点 on 2004-3-2 4:31:55:
Update at 4 a.m. on March 2 (Beijing time):

BOOTGRUB and BOOTGRUB.S have just been updated. The download addresses remain unchanged:

http://www.ipdown.com/grub4dos/bootgrub
http://www.ipdown.com/grub4dos/bootgrub.S

The following two files have not changed, and are still the February 29 versions.

http://www.ipdown.com/grub4dos/grldr
http://www.ipdown.com/grub4dos/grldrstart.S

The updated BOOTGRUB is confirmed to be runnable. The original problem was a hidden error:

mov ah,8
int 13

The output result of this call is stored in CX and DX, and as a result our BIOS disk number DL was overwritten. Errors like this happen often and are often hard to avoid. It has now been changed to this:

mov ah,8
push dx
int 13
pop dx

Now it's fine.

Dear TinyBit,

Does the new BootGrub support FAT12/16 partition?

If not, when will it be ready?

It still does not support FAT12/16.

FreeDOS's BOOT code is even harder to understand for FAT12/16 than for FAT32. Because of health problems, I cannot set aside dedicated time to do it.

===========

BOOTGRUB has been updated again. 9:27 in the morning.

The following is quoted from 不点 on 2004-3-2 9:31:17:
It still does not support FAT12/16.

The BOOT code of FREEDOS, for FAT12/16 is even harder to understand than FAT32. Because of health problems, I cannot set aside dedicated time to do it.

===========

BOOTGRUB has been updated again. 9:27 in the morning.

Dear TinyBit,

Health is of No. 1 importance. Take care of your health first!