China DOS Union

Dear TinyBit,

Please take sufficient rest!

When you do feel well, you could contribute by enlightening us on the technical
aspects of GRUB for DOS. You need not do coding for the moment.

We may follow up if we have time. As it is an open-source project, anybody who
has such expertise is welcome to join in.

Detailed documentation is in need and cannot be done without your enlightenment.

It seems I mentioned before that in some document at LINUX Eden, there is technical documentation for GRUB for DOS. Of course, it is also possible that some issues were not fully considered. But as the person who wrote that document, after all I have limitations in my own ability and perspective, and it may not necessarily reflect every aspect or solve every problem. Perhaps some issues can only be discovered and solved after they have revealed themselves. Right now my mind seems rather blank, and I haven't noticed anything. If you think there is anything else that needs to be said, I will do my best. Thank you for your concern; without you, my health would not have recovered this quickly. Right now I still need to avoid writing programs as much as possible, and can only do it occasionally, like a dragonfly touching the water.

The following is quoted from 不点's post on 2004-4-5 13:41:44:
It seems I mentioned before that in some document at LINUX Eden, there is technical documentation for GRUB for DOS. Of course, it is also possible that some issues were not fully considered. But as the person who wrote that document, after all I have limitations in my own ability and perspective, and it may not necessarily reflect every aspect or solve every problem. Perhaps some issues can only be discovered and solved after they have revealed themselves. Right now my mind seems rather blank, and I haven't noticed anything. If you think there is anything else that needs to be said, I will do my best. Thank you for your concern; without you, my health would not have recovered this quickly. Right now I still need to avoid writing programs as much as possible, and can only do it occasionally, like a dragonfly touching the water.

I think you could also consolidate what you put in 伊甸园 to your
homepage so that people can easily get all the files in one place.

I made pre5. I wonder what plans brother windrv and brother wengier have? Could you provide pre5 for download on the homepages you each made?

http://ipdown.com/grub4dos/grub_for_dos-0.2.0pre5.tar.gz

pre5 fixes a problem raised by ruymbeke: the root device name can now be omitted in the map command line. That is, it can be used like this:

map /file.img (fd0)

At this time it assumes the root device has already been specified.

It also fixes the two BUGs mentioned by tmpid. One is that GRLDR could not run under FAT12 and FAT16; the other is that GRUB.EXE could not run. The former should already have been confirmed by brother tmpid, while the latter still needs to wait for confirmation from brother tmpid. I estimate the problem should not be serious.

The BUG mentioned by brother wengier, shell=c:\grub.exe, still remains unsolved.

http://ipdown.com/grub4dos/

pre6 has also been uploaded.

http://ipdown.com/grub4dos/
http://ipdown.com/grub4dos/grub_for_dos-0.2.0pre6.tar.gz

It fixes the problem that shell=grub.exe could not be used in Config.sys.

At this point, all known BUGs have been fixed. If there are no problems, pre6 should be able to be upgraded directly into the final official version.

My task ought to be finished, and I myself am very satisfied. I can sleep soundly now. The rest is all up to you:-)

TinyBit: could you briefly explain what caused the BUG related to the SHELL command that was fixed in pre6?

Also, didn't I tell you last time that I use GRUB for DOS/NTLDR to disable the second hard disk so that I can boot into WinME normally? Doing this does achieve the purpose of disabling that hard disk after booting into WinME, but the IDE CD-ROM connected to the IDE interface on that same hard disk also gets disabled at the same time under WinME and cannot be seen. But if I disable the hard disk in BIOS, then after WinME boots it cannot see the hard disk but can see that CD-ROM drive. If, with the hard disk disabled by GRUB, I load the CD-ROM driver under pure DOS in WinME (VIDE-CDD.SYS+MSCDEX.EXE) and then enter WinME, then under WinME I can normally see and read the contents of the CD-ROM, but at that point using the CD-ROM under WinME is just like under ordinary DOS: it neither supports long file names on the disc nor can it use software like Nero to burn CDs, because MSCDEX does not support these functions. Is it possible to make the effect of disabling the hard disk with GRUB the same as disabling the hard disk in BIOS, so that under WinME it can also directly recognize that CD-ROM drive connected to the same IDE interface?

The following is quoted from 不点's post on 2004-4-12 11:57:59:
pre6 has also been uploaded. 

http://ipdown.com/grub4dos/
http://ipdown.com/grub4dos/grub_for_dos-0.2.0pre6.tar.gz

It fixes the problem that shell=grub.exe could not be used in Config.sys.

At this point, all known BUGs have been fixed. If there are no problems, pre6 should be able to be upgraded directly into the final official version.

My task ought to be finished, and I myself am very satisfied. I can sleep soundly now. The rest is all up to you:-)

Dear TinyBit,

Don't work too hard! Please leave it until you fully recover.

Bean123 is testing Grub For DOS and is beginning to write up WINGRUB and
we expect it to be out sometime next week.

The following is quoted from Wengier's post on 2004-4-15 10:27:48:
TinyBit: could you briefly explain what caused the BUG related to the SHELL command that was fixed in pre6?

Also, didn't I tell you last time that I use GRUB for DOS/NTLDR to disable the second hard disk so that I can boot into WinME normally? Doing this does achieve the purpose of disabling that hard disk after booting into WinME, but the IDE CD-ROM connected to the IDE interface on that same hard disk also gets disabled at the same time under WinME and cannot be seen. But if I disable the hard disk in BIOS, then after WinME boots it cannot see the hard disk but can see that CD-ROM drive. If, with the hard disk disabled by GRUB, I load the CD-ROM driver under pure DOS in WinME (VIDE-CDD.SYS+MSCDEX.EXE) and then enter WinME, then under WinME I can normally see and read the contents of the CD-ROM, but at that point using the CD-ROM under WinME is just like under ordinary DOS: it neither supports long file names on the disc nor can it use software like Nero to burn CDs, because MSCDEX does not support these functions. Is it possible to make the effect of disabling the hard disk with GRUB the same as disabling the hard disk in BIOS, so that under WinME it can also directly recognize that CD-ROM drive connected to the same IDE interface?

Dear Wengier,

Could you explain why you have to disable the secondary hard disk for booting up
WinME?

wengier:

The command line passed by shell=grub.exe to grub is /d /k AUTOEXEC, and this command line could not be recognized by grub.exe. The fix is very simple: just make grub.exe ignore this command line by changing the first space character in /d /k AUTOEXEC into a carriage return, then it's OK.

As for the IDE CDROM issue you mentioned, I haven't looked at it carefully yet. My initial feeling is that it is not an easy problem to solve.

windrv:

If brother bean123 releases it, then I will treat his release as the latest version, and if I release again in the future, it will be based on the final version. In the future I may release, or I may not release again. If I stop releasing, then I will submit patches to brother bean123. If brother bean123's release includes wingrub, then my future releases (if any) will also include wingrub. My releases are not official; they are only put on that draft page for everyone's convenience in downloading. But brother bean123's release will be the official one. The work is gradually being transferred to brother bean123.

Please thank him for me for freeing me.

--------

Thanks to you, I am much better now than I was a month ago. I still have not fully recovered, and I am trying to participate in writing code as little as possible. Thank you again.

wengier:

What the grub for dos disk emulation parameters --disable-chs-mode and --disable-lba-mode do is only to make the program fail when trying to execute through interfaces such as int13/ah=02/03/42/43 and so on, and return a failure message of "media not present".

WinME may probe hard disks through int13, and only if it also probes CDROMs through int13 would the problem you described occur. However, CDROMs do not seem ever to have had an int13 interface, so how could a CDROM be probed through int13? So this can only be attributed to Windows' secrets; Microsoft does not want to disclose some details of its operating system. I feel that with this problem, there is nowhere to start and no way to continue investigating it.

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

As for the int13 CDROM probing just mentioned, perhaps it is also possible. For example, int13/AH=4b is for CDROM. At most I can only do a little more research on this.

The following is quoted from windrv at 2004-4-15 11:20:21:
Dear Wengier,

Could you explain why you have to disable the secondary hard disk for booting up
WinME?

Here’s the situation. When I originally installed WinME, it was installed with only one hard disk present, in the E:\WINME文件夹下。后来又加挂了一个小硬盘，有一个主分区和一个扩展分区。两个硬盘在DOS下均可以正常使用。然而，由于两个硬盘均存在主分区，造成了盘符交错的问题，结果启动WinME前结果不禁用第二个硬盘的话，WinME根本无法正常启动。而如果启动DOS的话则可以通过LetterAssign来解决此问题。我不想删除第二个硬盘中的主分区来取消盘符交错，因为它也是一个可以独立使用的硬盘。我也试过用LetterAssign等软件的DOS版和WIN版来应付WinME，但都无法成功，WinME不是无法启动就是启动后发现新硬件（即第二个硬盘）后死机。由于我的系统是多启动的（用的是WinXP的启动菜单+GRUB folder. Later I added another small hard disk, with one primary partition and one extended partition. Both hard disks can be used normally under DOS. However, because both hard disks have primary partitions, this caused a drive letter interleaving problem. As a result, if I do not disable the second hard disk before booting WinME, WinME simply cannot start normally. If booting DOS, however, this problem can be solved through LetterAssign. I do not want to delete the primary partition on the second hard disk to eliminate the drive letter interleaving, because it is also a hard disk that can be used independently. I also tried using the DOS and Windows versions of software such as LetterAssign to deal with WinME, but none of them worked. Either WinME would not boot, or after booting, once it detected new hardware (that is, the second hard disk), it would hang. Since my system is multi-boot (using WinXP’s boot menu + GRUB for NTLDR), and under the various DOS systems both hard disks can be used normally, while only when entering WinME do I disable the second hard disk, I do not want to disable it directly in the BIOS (otherwise all systems would be unable to see this hard disk). Instead, I use GRUB for DOS/NTLDR to temporarily disable it before booting WinME.

Also, after disabling the hard disk with GRUB and booting WinME, there is an exclamation mark in front of the "Primary IDE Controller" device under “Hard disk controllers” in “System Properties” -> “Device Manager”. That IDE HD and IDE CD are both connected to it.

> After disabling the hard disk with GRUB and booting into WinME, there is an exclamation mark in front of the "Primary IDE Controller" device under "Hard disk controllers" in "System Properties" -> "Device Manager". That IDE HD and IDE CD are both connected to it.

This shows that the IDE device cannot be driven.

Your device arrangement is like this, right:

Primary IDE: (hd0)----- hard disk (cd)------ CDROM

Secondary IDE: (hd1)----- hard disk containing winme

Booting winme by disabling (hd0).

The strange thing is that int13 actually affects the IDE device driver, and that is why both the hard disk and CDROM were not detected.

My guess is that if we could solve the IDE device driver problem, then both (hd0) and (cd) would be found by windows, and thus your goal of blocking (hd0) would not be achieved.

So for the moment, the fact that IDE cannot be driven is actually a good thing.

In the previous post I mentioned int13/ah=4b and similar bootable CDROM interfaces. Thinking about it carefully, I still do not see how these interfaces could be used to probe the CDROM port. Besides, what we disable is int13/DL=(disabled disk number), which has no effect on other DL values. That is to say, other DL values can pass through normally and reach the original BIOS program code.

Therefore, the fact that IDE cannot be driven may be the fundamental reason why the CDROM cannot be found.

But why IDE cannot be driven is even harder to know. I can only give up further research.

The following is quoted from 不点's post on 2004-4-15 11:55:53:
wengier:

shell=grub.exe passes the command line /d /k AUTOEXEC to grub, and this command line could not be recognized by grub.exe. The fix is very simple: just make grub.exe ignore this command line by changing the first space character in /d /k AUTOEXEC into a carriage return, then it's OK.

I just tested again and found that in some cases GRUB.EXE still does not work when loaded with commands like SHELL. When pressing F8 for Step by Step confirmation mode, or pressing F5 for Bypass and then the system prompts for the path of the command interpreter and GRUB.EXE is entered, since the parameters passed to SHELL are not necessarily /D /K AUTOEXEC, GRUB.EXE still cannot be loaded as SHELL in those cases. The following is the information that appears on the screen when GRUB.EXE is entered in this case (this is only one of the cases; there are several other similar ones):

The following file is missing or corrupted: COMMAND.COM
Type the name of the Command Interpreter (e.g., C:\COMMAND.COM)
C>grub.exe （

My suggestion is that when GRUB.EXE runs, it should automatically check whether the first two characters of the command-line parameters are "--". If they are, but what follows is not a valid parameter it can accept (such as the currently legal parameter config-file), then it should display GRUB's command-line usage; if the first two characters of the command-line parameters are not "--", then it should just run GRUB directly. How about that?

Also, in the official version of GRUB, those test display messages above (that is, those hexadecimal numbers and so on) probably ought to be removed.

Very good! This displayed debugging information is very useful, and it should also be kept in the official version. Because this debugging information only appears when the command line is not recognized. It will not appear when things are correct. This information is far too useful in helping us determine the root cause of an error.

The root cause of this error this time is:

2F 79 20 0D

The /y parameter does not begin with a space, but with a slash. Rather wordy. This is obviously a Microsoft BUG: the space should be placed before the slash, but it placed it after the slash and y instead.

> My suggestion is that when GRUB.EXE runs, it should automatically check
> whether the first two characters of the command-line parameters are "--".
> If they are, but what follows is not a valid parameter it can accept (such as
> the current legal parameter config-file),
> then it should display GRUB's command-line usage; if the first two characters
> of the command-line parameters are not "--",
> then it should just run GRUB directly. How about that?

If the command line is like this:

--config-file=(hd0,0)/boot/grub/menu.lst/y /p /d /k AUTOEXEC

then it becomes bad. Note: (hd0,0)/boot/grub/menu.lst/y will be treated as a path, and this is a failing path.

So, the slash in "/y" must be changed into a carriage return. But how can the program know that this slash is not a path separator?

So now it's troublesome.

Previously, in " /d /k AUTOEXEC", the first character was a space, which was easy to judge; now there is no space before /y, which adds quite a bit of confusion.

I now have an idea like this, see what you think:

When using shell=grub.exe, require the following format:

shell=grub.exe /
shell=grub.exe --config-file=(hd0,0)/boot/grub/menu.lst /

There must be at least one space before the final slash (this can be written into the GRUB for DOS documentation).

Although this is not pretty, it can perfectly solve this kind of Microsoft BUG.

If everyone can accept this, then no changes are needed now; pre6 is enough.