China DOS Union

I know there are many DOS/BIOS experts here. Everyone, let's work together and see what is going on.

The new version of GRUB has brought many new features. For example, it can emulate a floppy or hard disk image of any size; it can not only read from the emulated disk, but also write to the emulated disk; in addition, it can enable the "in-place emulation" function, so that emulation can be used right at GRUB's command line state.

However, a strange thing has appeared, described in detail below:

First case, I use

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

chainloader (hd0)+1

boot

This boots win98 from the C: drive. After booting this way, the contents of the emulated floppy can be accessed normally inside win98.

Second case, using

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

map --hook

(the above command enables the in-place emulation function)

chainloader (hd0)+1

boot

As a result, after entering win98, I found the floppy could not be accessed. The first sector of the floppy had been rewritten; the other sectors all seem still to be there and were not damaged.

Third case, using

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

map --hook

map --unhook

(the above command disables the in-place emulation function)

chainloader (hd0)+1

boot

This also does not work; the first sector of the floppy image is still destroyed.

Fourth case, using

map --read-only (hd1,0)/dos98.img (fd0)

(the above command forbids writing to the floppy image with int13/AH=03h or int13/AH=43h)

map --hook

chainloader (hd0)+1

boot

Booting win98 this way, the floppy is no longer destroyed.


Based on the above situation, we can preliminarily determine that some very hidden int13/AH=03h or int13/AH=43h wrote to the floppy.

First, win98 is in vmware, and I did not install any extra software, so it cannot have a virus; second, even if win98 were infected with a virus, think about why it does not destroy the floppy in the first case? So it should not be caused by operating systems like win98.

Then the problem is concentrated on GRUB's code. However, GRUB has very few disk-writing operations, and especially I cannot find any operation that writes to a floppy. GRUB writes to disk only in very rare cases, such as installing GRUB to the MBR, etc. We could not possibly be involved with these operations at all, so how could an action like writing to a floppy suddenly appear?

I am really completely baffled!!

Try it.. then talk..

Wow! I originally suspected there was a problem with the GRUB code, so I added a check at the beginning of the biosdisk function: if it is a disk-write operation, print an error message and enter an infinite loop. I was fully expecting it to die this way, but as a result, it did not die, and still booted win98 all the way. Once in win98, I checked the floppy, and of course the first sector was still damaged.

Therefore, I guessed that win98 wrote to the floppy. If switching to DOS, perhaps it would no longer write to the floppy. Sure enough, when booting WIN98, pressing F8 to bring up the menu and choosing Safe Mode Command Prompt Only, this time the floppy had no problem.

As for when win98 writes to the floppy, this still needs to be studied. Does this count as a win98 BUG? Or is it its secret? Also, could it damage the hard disk?

If it damages the first sector of the hard disk (even if only once by chance), that would simply be unbearable. The first sector of a floppy does not contain important data, but the first sector of a hard disk has the partition table. If this is lost, wouldn't the whole hard disk be finished?

Also, strangely, win98 does not damage the floppy every time. In the first case above, it never damages it. Only after using --hook does it damage it.

There probably are not many people here who understand programming. Supporting the software you create.

After I used GRUB's map command to "in-place emulate" a virtual floppy drive, and then used the chainloader/boot commands to boot into MS-DOS 7.1 (DOS installed with the “MS-DOS 7.10 full installation edition”) and run Win98, an "Unable to write to Drive C" blue screen error appeared, or it directly went to a black screen and crashed, so it could not continue booting into the Win98 interface. After rebooting, I found this IMG image had already been damaged and could not be read; but if I do not first use the map command to virtualize the floppy, then after using the chainloader/boot commands to boot DOS+Win98, these phenomena do not occur, and it boots normally.

Afterwards I disabled the “Use 32-bit disk access” function in Win98's “System Properties”, then used GRUB with the same commands as above to call and boot MS-DOS 7.1+Win98. As a result, the problem was indeed solved: not only did it boot into the Win98 interface, but the floppy had no damage at all! It can be seen that GRUB's current virtual floppy “in-place emulation” function seems not yet compatible with Win98's 32-bit IFSMGR subsystem function, causing Win98 to be unable to boot/use normally if “32-bit disk access” is enabled.

Many thanks, Wengier! Thank you for your important discovery. The situation is still very complicated; please continue to pay attention to this problem and try to give it a complete solution.

Let me report the new situation from my testing. I booted with in-place emulation, pressed F8 to bring up the menu, and chose command prompt only. At this point, accessing the floppy under DOS was normal. Then, at the DOS command line, I typed win to start win98. As a result, the first sector of the floppy turned into garbage.

This further confirms that GRUB does not have an operation that writes to the floppy; it was win98, not any other program, that wrote to the floppy.

Combining this with what Wengier just said, can we think that win98's “32-bit disk access” itself has a BUG? Earlier I already confirmed that by forbidding int13/ah=3h/ah=43h, the floppy can be ensured not to be damaged. Therefore, this “32-bit disk access” also writes to the floppy through int13/ah=3/ah=43. My question is: why does it do this? What is the intention? Could it be that “32-bit disk access” must call these disk-writing functions? In fact, when in-place emulation is not used, “32-bit disk access” does not call the disk-writing function. So at present I feel this is either a BUG in “32-bit disk access”, or some undisclosed secret.

Brother Wengier, please take another look: that damaged hard disk, exactly how many sectors were damaged? I guess it may also be exactly one MBR sector that was destroyed.

Also, if the root of the problem is like this, then everyone please suggest how our program should deal with this situation? Thanks.

Searching for “32-bit disk access” in google gives this result:

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

Second, when operating the CD-ROM under the Windows environment, it displays “32-bit disk access failed” and then crashes?

Clearly, Windows' 32-bit disk access has a certain effect on CD-ROMs. Most CD-ROMs are connected to the hard disk's IDE interface, and do not support Windows' 32-bit disk access function, causing Windows to produce an internal error and crash. After entering Windows, double-click “Control Panel” in the “Main” group, go into the “386 Enhanced Mode” settings, click the “Virtual Memory” button and then click “Change”, turn off the “32-bit disk access” checkbox at the lower left, confirm, then restart Windows. When accessing the CD-ROM in Windows again, there will be no error.

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

This shows that Microsoft's “32-bit disk access” itself is immature; it is a BUG in its program. I think there is no need to look for other causes.

Found another very good web page, talking about various win98 startup failures and solutions:
http://tech.sina.com.cn/c/2001-12-13/7856.html

Excerpt:

　　Startup failures

　　The causes of crashes when Windows 98 starts are relatively complex, because Windows 98 must go through a thorough hardware and software detection process when the system boots, and any link in it may cause the system to work abnormally.

　　1. The system crashes on first startup

　　If the system crashes on first startup, suspect a problem with hardware installation or settings. At this time, when "Start Windows 98" appears during system boot, immediately press the F8 key and select "Safe mode" to start the system. Click "Start/Run", enter "msconfig" in the box that opens, and click "OK". Then choose different tabs according to the different situations below.

　　① Disable 32-bit disk access

　　If the hard disk does not support 32-bit access mode, then the system will hang during startup. At this time, click "Advanced", select the "Force compatibility mode disk access" checkbox, and press "OK". The system prompts you to restart the computer; click "Yes" to restart the system. If the computer starts normally, it means the hard disk is too old and cannot support 32-bit access mode, and it should be replaced.

　　If the system cannot use "Safe mode" to enter safe mode, you can press F8 and enter DOS state through the "Command prompt only" item. When the DOS prompt appears, type "WIN/D：F" to start Windows 98. If successful, it also shows that the system refuses to use 32-bit disk access mode to run Windows 98.

　　② Ensure BIOS-based disk operation

　　If the above method is unsuccessful, then Windows 98 may require the use of a BIOS-based disk operating system. Click "Advanced", select the "Disable virtual HD IRQ" checkbox, click "OK", then click "OK" again, and restart the system.

　　If the system cannot use "Safe mode" to enter safe mode, you can press F8 and enter DOS state through the "Command prompt only" item. When the DOS prompt appears, type "WIN/D：V" to start Windows98. If startup succeeds, then the following setting can be added after the item in the SYSTEM.INI file:

　　VirtualHDirq=0

　　③ Disable Windows 98 from using ROM breakpoints

　　A ROM breakpoint is an address in the PC BIOS that contains the instruction used by Windows 98 when switching from safe mode to real mode. Under normal circumstances, Windows 98 looks for those breakpoint instructions at the specified address. However, if a third-party memory manager is used, use of ROM breakpoints must be disabled. Click "Advanced", select the "Disable system ROM breakpoint" checkbox, click "OK", then click "OK" again, and restart the computer. If startup succeeds, it means the system cannot use ROM breakpoints.

　　If the system cannot use "Safe mode" to enter safe mode, you can press F8 and enter DOS state through the "Command prompt only" item. When the DOS prompt appears, type "WIN/D：S" to start Windows98. If startup succeeds, then the following setting can be added after the item in the SYSTEM.INI file:

　　SystemROMBreakPoint=0

　　2. Crash after the "Starting Windows 98……" message appears

　　This failure is mostly because the DOS startup part of Windows 98 has been damaged. If you have the boot disk created when installing Windows 98, insert this disk into the floppy drive and restart the machine. After booting, use the "SYS C：" command to transfer the system to drive C. If no boot disk was created during installation, you can create a boot disk on another machine through "Control Panel/Add Remove Programs/Create Startup Disk". But note that the transferred system version must be the same as the original system version, otherwise the system cannot start.

　　3. Automatic shutdown immediately after startup

　　The cause of this failure is that, when Windows 98 starts, there is an error loading a device driver, causing the system to think the hardware cannot work normally. When "Start Windows 98" appears during system startup, press the F8 key and use the "Step-by-step confirmation" option in startup mode to confirm. If the system runs to "Load all Windows drivers" and, after pressing Enter, a safe shutdown message appears, then this is definitely the cause.

　　Restart the system and enter Windows safe mode (Safe mode). Open Windows/System.INI and check the boot item in it. Compare each loaded driver with the corresponding drv file under C:WindowsSystem; that is, check whether the driver name on the right side of the equals sign in statements with extension drv after the item is consistent with the filename of the corresponding drv file under C:WindowsSystem. If inconsistent, correct it. If the driver specified by System.INI is missing or damaged, it can be copied from another machine's Windows 98 system. If it cannot be copied, you can temporarily add the comment character "；" before that line to skip it.

I have a few questions I want to mention,

The “32-bit disk access” in Win3.11 and Win98 is somewhat different. In Win98, suppose you run Win98 with “32-bit disk access” not enabled under MS-DOS 7.0, which does not support FAT32 partitions, then Win98 also cannot see FAT32 partitions; but if you run Win98 with “32-bit disk access” enabled under MS-DOS 7.0, then Win98 can see FAT32 partitions. It can be seen that after Win98 runs under DOS, it only uses the 32-bit IFSMGR to redirect disk partitions once during startup.

Regarding IMG not being damaged without using "map --hook", but IMG being damaged after using "map --hook", you can check what slight differences there are in the system after these two methods. Could it be that these subtle differences (or a tiny BUG, or a BUG like FreeDOS Kernel 2030) cause IFSMGR to fail when redirecting disk drives?

I also tried it with a floppy IMG, and the first 512 bytes indeed changed into other contents. I originally wanted to experiment with a hard disk IMG, but it really cannot be done, because GRUB requires the IMG image file space to be contiguous. A floppy IMG is still somewhat easier (I also had to copy it several times before it succeeded), but as for a hard disk IMG image, making it do this is extremely, extremely difficult. I wonder whether GRUB can think of a way to support non-contiguous IMG images, to make it more convenient and practical?

Don't you know how to use a compass, haha, funny.

Another new discovery. I changed to another floppy image, and this time even booting with the first method destroyed the floppy image!

This proves that it is not only --hook that causes the floppy to be destroyed. Not using --hook can also cause the floppy to be destroyed.

So it is definitely not the fault of the "in-place emulation" function itself. This function is very simple and cannot have any problem. It simply hooks int13 so that GRUB itself can use the emulation. Usually, if --hook is not used, the int13 emulation is not hooked until after the boot command is executed. So the difference between using --hook and not using --hook is extremely tiny; or, for the operating system that is about to be booted, this order originally makes no difference, and ultimately the int13 emulation program is hooked.

After this discovery, I confirm the problem is not with --hook itself.

I replied above; I don't know whether you saw it. That may indeed be Win98's own problem. I think let's ignore it for now; as long as DOS can use it normally, that is fine..

Brother Wengier, didn't you once have a hard disk go bad? Please check again exactly how many sectors of that bad hard disk went bad.

＝＝＝＝＝＝

Oh, sorry, I just understood: your hard disk was not damaged; it was the floppy that was damaged.

=========

> I wonder whether GRUB can think of a way to support non-contiguous IMG images, to make it more convenient and practical?

No. For programming simplicity, I do not want to consider something that complicated. In a typical case, a 1.44M file may occupy 1000 or even more non-contiguous areas. If so, who knows how much difficulty the emulation would add, and the program would also easily have hidden errors, causing potential danger. Taking a step back, even if it could emulate this way, its running efficiency would be greatly affected. Just saving these 1000 pointers would require 4000 bytes of space. 4K of space, and this does not include the int13 code. So this is also unfavorable for storage space. Not to mention the emulation of 2.88M or hard disk images.

Actually, producing a contiguous hard disk image is also easy. Format a hard disk, then copy files to this hard disk, and then there will be no fragments on this hard disk.

＝＝＝＝＝＝＝

But you can use (hd0,0)+666666 to directly use the whole partition; here 666666 should be the total number of all sectors in the partition. This notation is definitely contiguous.

I am writing code to interpret (hd0,0)+1 as the whole partition, so that there is no need for a human to calculate the number of sectors in the partition.

All right, I will work on the hard disk image problem myself first; everyone can ignore it for the time being.

The following is quoted from Wengier's speech on 2003-11-15 12:32:28:
That may indeed be Win98's own problem. I think let's ignore it for now; as long as DOS can use it normally, that is fine..

I have already seen the dawn of solving the problem. I especially admire and thank Brother Wengier for pointing out the focus and root of 32-bit disk access. I just searched google for 32-bit disk access, and finally know what “32-bit disk access” means. It should be called “protected-mode disk access”, to avoid ambiguity.

Executing a 16-bit real-mode int13 program in protected mode requires that the code of these programs not use 32-bit registers. My program uses a large number of 32-bit registers, so it caused “protected-mode disk access” to produce erroneous operations.

All right, next it probably will not be hard to solve. Rest for a while now.

The following is quoted from 不点's speech on 2003-11-15 12:56:26:
Actually, producing a contiguous hard disk image is also easy. Format a hard disk, then copy files to this hard disk, and then there will be no fragments on this hard disk.

不点, I wonder whether there is software that can directly copy files contiguously under DOS? After all, if just to produce a contiguous IMG image for GRUB for DOS to use, asking everyone to format a hard disk seems somewhat impractical. Besides, GRUB's final goal is after all to be truly used on real computers, not just played with in a virtual machine.