中国DOS联盟

The following is a quote from Budian at 23:35:09 on November 11, 2003:
The address provided by the brother cannot be uploaded, and multiple attempts have been made without success. It has been uploaded here:

ftp://ftp.cosoft.org.cn/incoming/grub_t01.exe

I will test this in a few days. I hope the author can fix more bugs. I am also testing in a virtual machine. GRUB is not very secure, so I'm a bit worried.

The following is a quote from cba-xyz on 2003-11-14 20:16:22:
I tested it these days. I hope the author can fix more bugs. I also tested it in a virtual machine. GRUB is not very safe, so I'm scared.

Scared, that's right. I'm most afraid of people who are bold. I approve of people who are careful and serious.

It can be said that this recently discovered bug is really very frustrating. I'm afraid it won't be completely solved for who knows when. So I don't want to encourage everyone to test now. Before providing it for public testing, I should first solve all the problems I have discovered by myself.

I hope the next official version will be widely tested and should be very stable.

It feels like the problem with GRUB mainly seems to belong to the BUG of Win98. I carefully checked the code of the GRUB emulation part and found no suspicious places. So, treat this situation as a special case, that is, when the sector does not end with 55 AA, prohibit writing it to the first sector of the emulated drive. Okay, let's test again.

ftp://ftp.cosoft.org.cn/incoming/grub_t04.exe

Buddy: Just tried this T4 version. But when I boot Win98 with GRUB on my computer, if I don't disable "32-bit (protected mode) disk access", there's still a blue screen or black screen error and it freezes. Although compared with the T1 version, I found that the floppy disk IMG is not damaged after restarting.

I also discovered this problem, and felt that the problem was quite serious and rather strange.

I used

map (hd0,0)+1 (fd0) This is mapping drive A: to drive C:; all operations on drive A: will be redirected to drive C:

chainloader (hd0,0)+1

boot

to boot. As a result, drive C: was fine, but all even-numbered bytes on drive A: were displayed as 00.

Let's take a look at this:

ftp://ftp.cosoft.org.cn/incoming/grub_t06.exe

That should be about it.

I use

map (hd0,0)+1 (fd0)

chainloader (hd0)+1

boot

To boot into win98 on drive C:. In win98, when I check drive A:, I find that the size of drive A: is 4G and the content is exactly the same as drive C:.

The size of drive A: can be arbitrary, which should be quite exciting.

I just now downloaded the T6 version of GRUB and tried it, but I found that in my VMWare environment, as long as I use GRUB to virtualize the floppy drive (whether it's map (hd0,0)/xx/xx (fd0) or map (hd0,0)+1 (fd0), etc.), and then use chainloader+boot to start DOS (at this time everything is normal), and then enter the WIN command to start Win98 (without shielding "Protected Mode Disk Access"), there is always a blue screen error like "Unable to write to Drive C" and it crashes. What is the reason?

Can you try this:

map (hd0,0)+1 (fd0)

chainloader (hd0)+1

boot

See if this can boot Win98?

Don't click, I tried this way last time, but unfortunately it didn't work.

On my VMware, starting in two ways results in different outcomes.

As mentioned above, the first successful boot from the hard disk:

map (hd0,0)+1 (fd0)

chainloader (hd0)+1

boot

The second boot from the floppy disk fails.

map (hd0,0)+1 (fd0)

map --hook

chainloader (fd0)+1

boot

There is no blue screen, but the machine is locked up and cannot enter Win98.

=====================

Let's guess. The first successful boot is because C: is the boot disk. Win98 implements "protected mode disk access" for this disk and "real mode disk access" for drive A:, which passes, so it succeeds.

The second boot fails because drive A: is the boot disk. Win98 attempts to implement "protected mode disk access" for drive A:, but since the disk emulated by GRUB cannot perform Win98's "protected mode disk access", or Win98 itself does not support "protected mode disk access" for the emulated disk, Windows dies.

After disabling Win98's "protected mode disk access", the problem is solved, which confirms the above guess.

I feel this has reached a dead end, there's no way. Unless someone can improve the driver for Win98's "protected mode disk access".

===========

The above two boots are essentially different, one from drive C: and one from drive A:. They seem similar on the surface but are essentially different (the key is which disk it boots from). Brother Wengier, would you try again.

If the above conjecture holds, we can basically call it a day.

After booting the system with vfloppy, how to use the floppy drive?

Report the new test results again.

This time, win98 was actually booted from a floppy disk, and the "protected mode disk access" of win98 was not disabled.

map (hd0,0)/dos98.img (fd0)

chainloader (hd0,0)/dos98.img

boot

After entering win98, the first access to the floppy disk was normal, the second access to the floppy disk was extremely slow.

The third access to the floppy disk, win98 reported that the floppy disk was not formatted. Using debug to look at the content of the floppy disk, as a result, all sectors of the floppy disk had 00 at even bytes.

It seems that win98 is still difficult to handle.

The overall impression is that win98 did not fully test the disk operations compatible with real mode, and it has serious hidden bugs. In order to serve win98 as much as possible, we may need to write a large section of processing programs to avoid its bugs as much as possible.

Budian: Since it has basically been determined that it is a bug in Win98's "Protected Mode Disk Access" itself, why not add a note in the GRUB documentation, saying that when using GRUB to virtualize a floppy disk and then booting DOS->Win98, do not enable that mode, or add a piece of code to GRUB to automatically disable Win98's "Protected Mode Disk Access" function when it detects that Win98 is starting, so as to avoid having to deal with that troublesome "Protected Mode Disk Access" of Win98 anymore.

What Brother Wengier said is exactly what I want to do. If this difficult problem can't be finally solved, then this is a fallback option.

But I really don't want to give up. The reason why the developers of the early GNU GRUB added the map command was to deal with the weakness that Windows couldn't boot from the D: drive. Unfortunately, after using the map mapping, Windows on the D: drive still couldn't boot. The dangerous indication in the GNU GRUB code shows that this mapping is not safe. I once used the map mapping to boot DOS on the D: drive on a real machine, but I didn't use it to boot Windows on the D: drive. Some people reported that Windows on the D: drive couldn't boot.

However, in the early days, the developers didn't have emulators like VMWARE. Today we have such convenient tools, and it's time to stick to making the technology perfect. If in the end Windows can't be safely booted, I will feel disappointed, and I will think that the previous efforts were all in vain. I want to try again, do my best, and don't want to surrender easily. With the help of all you lovely Chinese people, we have reached this point today. Our success lies in the fact that we have discovered the root cause of the problem. This is very important. If the root cause of the problem can't be discovered, there is no hope at all. Now that we have discovered the root cause of the problem, there is only the need to find a solution. Although it's about serving Win98, it's also worth doing. After all, Win98 is good in other aspects. I believe there will be a satisfactory solution in the end.

Another one made, let's try again.

ftp://ftp.cosoft.org.cn/incoming/grub_t07.exe

This time there shouldn't be no progress at all, right?

My test, can boot win98 from floppy image. No other problems found on my virtual machine.