中国DOS联盟

The following is a quote from Budian at 18:25:37 on September 4, 2004:
I haven't encountered a situation where the simulation of the C: drive failed.

To simulate (hd0), the img file used must contain an MBR as the first sector. An IMG without an MBR cannot be simulated.

In fact, it's also possible without an MBR. For example, an img file with all 00 bytes can also be used to simulate a hard disk:

map --unsafe-boot --sectors-per-track=63 --heads-per-cylinder=255 HD.IMG (hd0)

But after you use chainloader (fd0)+1 and the boot command to enter the operating system, the operating system will think that the disk is not partitioned, so it will not recognize the existence of the logical disk.

After you enter DOS with a floppy disk, you can run FDISK and FORMAT to partition and format HD.IMG.

Dear Tinybit,
Contrary to what you have said about mapping a disk file as C:, we have been able to boot from such disk file as C: and use it both under DOS and Win9x. And the disk file is bootable and formatted beforehand.

We have been successful in some occasions of using the 'map' command on NTFS partition. But there are errors sometimes.
Could
you tell us in which source file and where therein the 'map' command
can be found as well as the NTFS support module so that we understand
more about how the bug comes about?

The 'map' command is in the builtins.c file, but this command has no direct relation to NTFS, so there may be no need to modify it.


The NTFS support module is the fsys_ntfs.c file. I guess that if there is a BUG, it is very likely in this file.


Contrary to what you have said about mapping a disk file as C:, we have
been able to boot from such disk file as C: and use it both under DOS
and Win9x. And the disk file is bootable and formatted beforehand.


Yes, as long as there is an MBR in the img file, you can indeed use it smoothly to simulate a hard disk.

The following is a quote from Budian at 17:35:50 on September 10, 2004:

We have been successful in some occasions of using the 'map' command on NTFS partition. But there are errors sometimes.


Could
you tell us in which source file and where therein the 'map' command
can be found as well as the NTFS support module so that we understand
more about how the bug comes about?


The 'map' command is in the builtins.c file, but this command is not related to NTFS (no direct relationship), so there may be no need to modify it.


The NTFS support module is the fsys_ntfs.c file. I conjecture that if there is a BUG, it is very likely in this file.


Contrary to what you have said about mapping a disk file as C:, we have
been able to boot from such disk file as C: and use it both under DOS
and Win9x. And the disk file is bootable and formatted beforehand.


Yes, as long as there is an MBR in the img file, you can indeed use it smoothly to simulate a hard disk.

Dear Tinybit,
Thank you for your advice.
Is it possible that the routine of checking contiguous file for the 'map' command cannot handle big numbers when the partition size of the hard disk is too large?
We are in fact able to boot up such contiguous files on partitions of several gigabytes.

Yes, there is indeed a BIG NUMBER problem.

GRUB once defined the total number of sectors as int, which is a signed integer. In recent versions, it has been corrected to unsigned int.

However, GRUB always uses 4 bytes to represent integers. So, if your sector number exceeds the representation range of 4 bytes, various errors will occur.

This is a problem of GNU GRUB, and I haven't fixed it. All related BUGs are to be fixed by the managers of GNU.

The following is the statement by Budian at 19:20:34 on September 11, 2004:
Yes, there is indeed a BIG NUMBER problem.

GRUB once defined the total number of sectors as int, which is a signed integer. In recent versions, it has been corrected to unsigned int.

However, GRUB always uses 4 bytes to represent integers. So, if your sector number exceeds the representation range of 4 bytes, various errors will occur.

This is a problem of GNU GRUB, and I haven't corrected it. All BUGs related to this are to be corrected by the managers of GNU.

Dear Tinybit,
According to your advice, I have used the 'blocklist' command to check that file which fails to be'mapped', the result is:
blocklist (hd0,0)/part.img
(hd0,0)24810224+11671
The 'blocklist' commands seems to implement correctly and indicates that the image file is in one contiguous block. But the'map' command fails to load the file.
Is it related to the GNU GRUB problem you referred to above?
Could the'map' command handle this issue just like the 'blocklist' command does?

Oh! I got the answer: There should only be letters within the filename and no numerals are allowed!

Is that so? So surprising!

Only letters are allowed, no numerals for filenames. I've never noticed this before, first time hearing about it. Going to try it out. I thought numerals might be allowed, but spaces might not be.

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

Regarding the continuity processing of the map command, due to your continuous reporting, I'm also researching the root cause of the problem. I just discovered a flaw, maybe it will be fixed after modification, but I'm not sure yet. This might be an oversight after I improved the algorithm. Thanks.

The following is a quote from Budian's post on September 13, 2004, at 15:02:17:
Oh! I got the answer: There should only be letters within the filename and no numerals are allowed!

Is that so? So surprising!

Only letters are allowed, no numerals for file names. I've never noticed this before, first time hearing it. Going to try it out. I think numerals should be allowed, but spaces might not be.

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

Regarding the continuity of the map command, due to your continuous reports, I'm also researching the root cause of the problem. I just discovered a flaw, maybe it can be fixed, but I'm not sure yet. This might be an oversight after I improved the algorithm. Thanks.

Dear Tinybit,
Thank you for your effort!
I hope that your improvement will bring us great convenience of launching various disk-file based operating systems using boot.ini on NTFS partition. Please give us the update when it is ready.
By the way, we have put up a new webpage on the homepage link of sourceforge.net for the project of GRUB4DOS & WINGRUB. The webpage has pointings to our webpage on our website therein with links to the webpages for GRUB4DOS on linuxeden.com & Wengier's previous link as site 1 and site 2. If you want to put up more links for GRUB4DOS, please email to bean. His address is bean@windrv.net
Also if you have any other ideas about how to design your weblinks or want to have a separate webpage on our site or have a new icon or logo for GRUB4DOS, you are welcome to give us your opinions so that we can serve you.

I have no further suggestions, just feel that the files do not seem to have been released on the SourceForge webpage yet.

The following is a quote from Budian at 10:05:49 on September 14, 2004:
I have no further suggestions, just feel that the files do not seem to have been released on the SourceForge website.

Dear Tinybit,
Bean is writing up the help file for WINGRUB and there may also be some examples of how to use GRUB. As it is ready, files can be uploaded to sourceforge.net or people can download from our site.

0.3 series third test version. This can be regarded as alpha testing, with no version number, just using dates to represent different versions. Corrected a very stubborn BUG that the previous version couldn't boot the CDROM.

The CDROM-related commands in this version can still only be used for some ASUS machine models. For ASUS machines, you can report BUGs. Download:

http://grub.linuxeden.com/wakka.php?wakka=UploadFile/files.xml&action=download&file=grub-2004-09-17.tar.gz
ftp://ftp.linuxeden.com/tinybit/grldr
ftp://ftp2.linuxeden.com/tools/grldr
ftp://ftp.linuxeden.com/tinybit/grub.exe
ftp://ftp2.linuxeden.com/tools/grub.exe

Usage:

map --cdrom=9 This command directly boots the bootable CDROM disc in the optical drive. If successful, the operating system on the disc will be booted, so it is impossible to return to the current GRUB environment. If it fails, it will return to the current GRUB environment.

map --cdrom=8 Similar to the above map --cdrom=9, but just prepares to boot the CDROM, and you need to type a boot command to really start booting the CDROM.

map --cdrom=4 This command mounts the optical drive and makes it BIOS hard disk 0x80. The original hard disk numbers in the machine are correspondingly increased by 1, becoming 0x81, 0x82, etc. If successful, you can use root (hd0)/ (here it means pressing the Tab key) to list the files on the disc. That is, at this time, (hd0) is the optical disc medium, and (hd1) is your original hard disk C:.

map --cdrom=-1 This command unmounts the mount established by map --cdrom=4 and restores the BIOS disk numbers to the original values.

In the case of the Microsoft win98 installation disc, since the position of the 1.44M floppy disk image is at optical disc absolute sector 0x15, and this uses a sector of 2048 bytes, translated into a sector of 512 bytes, it is at optical disc absolute sector 0x54, which is 84 in decimal, so you can simulate the floppy disk like this (note that it is using the sector sequence on the disc to simulate the floppy disk):

map (hd0)84+2880 (fd0)
map --hook

Now you can use root (fd0)/ to list the files in the virtual floppy disk.

In addition, the blocklist command can also be used to verify that any file on the disc is continuous and has no fragmentation. Therefore, the img file on the disc can always be used for disk simulation.

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

Try windrv to see if the error in map judging continuity has been corrected.

Dear Tinybit,

Initial testing shows that the updated version of grldr in relation to the 'map' command does not yet work.

The method for determining the continuity of files in the old version is: read the entire file, check each read sector to see if they are continuous. This method can succeed but is very slow.

The method for determining the continuity of files in the new version is: read the first sector, determine the position of the starting sector, then read the last sector, determine the position of the ending sector. With the physical positions of the starting and ending sectors, and comparing with the length of the file, the conclusion whether all sectors in the file are continuous can be drawn.

I am going to release a debug version tonight, specifically for map continuity check. It is still the above download address, but the file date will change. Please, windrv, pay attention to check and receive.

The following is the speech by Budian on 2004-9-20 15:42:30:
The method for the old version to determine the file continuity is: read the entire file, check each sector that is read, and see if they are continuous. This method can be successful, but it is very slow.

The method for the new version to determine the file continuity is: read the first sector, determine the position of the starting sector, then read the last sector, determine the position of the ending sector. With the physical positions of the starting and ending sectors, and then comparing with the length of the file, the conclusion whether all sectors in the file are continuous can be drawn.

I am going to release a debugging version tonight, specifically for the map continuity check. It is still the above download address, but the file date will change, please windrv pay attention to check and receive.

Thanks a lot!