学步园

There are two distinct types of mapping, direct and memory. Direct mapping is generally used for larger images/devices. If using direct mapping to create a virtual device from a disk image, then the image file must be contiguous (not fragmented). Either of the following programs can be used to defragment a file that is contiguous - contig or wincontig. Attempting to directly map a non-contiguous file will result in  Error 60: File for drive emulation must be in one contiguous disk area , in which case memory mapping or defragmenting the file, and then retrying, should be attempted.

Memory mapping, which copies the mapped device/image into memory, is generally used for smaller images - e.g. floppy disk images. In memory mapping the image file can be non-contiguous. Available system RAM will restrict the size of any image mapped to memory.

The "map" process is implemented using INT 13 - any disk emulation will remain accessible from an OS that uses compatible mode disk access, e.g. DOS and Windows 9x. The emulation can't however, be accessed from an OS which uses protected mode drivers (Windows NT/2000/XP/Vista, Linux, FreeBSD) once the protected mode kernel file(s) take control.

Direct Mapping

Booting Disk Image Files

An example of direct mapping of a floppy disk image was given in the Boot Options section of this guide -

Grub4dos feedback when entering the above commands from the command line -

When directly mapping a hard disk image the image file must have a valid MBR. An image with multiple partitions should be mapped as a (hd) type device. If the hard disk image file is of a single partition (without MBR), then it should be mapped as a floppy disk.

There are a number of examples of direct mapping in the README_GRUB4DOS.txt file.

Disk Swapping

An example of when you might use the map command to change the disk order occurs when booting from a USB device (e.g. flash drive, or external hard drive). As the BIOS settings are changed to boot from the USB bus, the internal hard disk would become (hd1). DOS and Windows 9x will not boot from a non-first hard disk, although Windows NT based systems will theoretically boot from a non-first disk the arcpaths in boot.ini will have become invalid when booting from the USB device. If a windows OS is installed on the internal device it will therefore no longer boot.

Another example would be adding a new hard disk to an existing system. If for example the old disk had Windows XP installed - and was moved from 'master' to 'slave' (becoming (hd1)), whilst the new disk was set as 'master' (hd0) and Windows Vista was installed to it, it would no longer be possible to boot Windows XP from the slave disk.

It is possible to boot these systems from a non-first hard disk by using the map command to change the disk order (e.g. remapping (hd1) to (hd0)).

(hd0,0) contains the marker file hd0.tag and (hd1,0) contains the marker file hd1.tag. The MBR Wizard program has been added to (hd1,0), to check which disks are accessible from dos after using various map commands.

results in the following error,

NOTE - using the above sequence of commands, the mapping of (hd1) to (hd0) does not take effect until after the boot command has been issued. Although (hd1) has been mapped as (hd0), all references to the actual device remain (hd1) in Grub4dos. Entering the command find /hd0.tag from the Grub4dos command line will return the device (hd0,0), whilst entering the command find /hd1.tag from the Grub4dos command line will return the device (hd1,0) - see box below.

Note the output following the chainloader command ...from drive=0x81. After booting into DOS the command mbrwizd.exe /list was executed. As you can see from the disk size and filesystem type parameters in figure 1. - the device (hd1) is listed as Disk:0 and Disk:1 - the device (hd0) is not visable.

figure 1.

NOTE - using the above sequence of commands, the mapping of (hd1) to (hd0) takes effect immediately after the map --hook command has been issued. Entering the command find /hd0.tag from the Grub4dos command line will result in a "File not found" error, whilst entering the command find /hd1.tag from the Grub4dos command line will return the devices (hd0,0) and (hd1,0) - see box below.

Note the output following the chainloader command ...from drive=0x80. After booting into DOS the command mbrwizd.exe /list was executed. The results were the same as in the previous example, with the device (hd1) listed as Disk:0 and Disk:1 - and the device (hd0) not visible.

NOTE - After entering the commands map (hd1) (hd0) and map (hd0) (hd1), entering find /hd0.tag from the Grub4dos command line will return the device (hd0). Entering find /hd1.tag will return the device (hd1). Once DOS has booted both disks will be accessible, however the physical device (hd1) will be listed as Disk: 0, and the device (hd0) will be Disk: 1 - see figure 2.

figure 2.

Remember that disk emulation will only remain accessible from an OS that still uses INT 13. In the examples used above, Windows NT based systems would see device (hd0) as "disk 0" and device (hd1) as "disk 1", as soon as the boot process was complete.

When mapping a partition the syntax (hdm,n)+1 is used to represent the whole partition (where m=disk number, and n=partition number), not just the first sector.

Grub4dos feedback when mapping a partition using the above commands -

A cautionary note from the README_GRUB4DOS.txt file

Memory Mapping

Memory mapping uses the same command syntax as the direct mapping examples above, with the addition of the --mem switch.

When memory mapping is used the disk image file can be non-contiguous. Devices can also be mapped to memory - e.g. map --mem (hd0,0)+1 (fd0) (as explained previously, the +1 notation is used in the map command to denote the whole partition). If mapping a disk image of a partition without a MBR to memory, it can be mapped as a (hd) device as the MBR will be created within Grub4dos - based on the partition data.

Compressed images can also be used when memory mapping. The images must be compressed with gzip (.gz file extension), which is a freeware opensource compressor. Since many disk images are not "full", their contents can be compressed with a noticeable compression ratio. A standard floppy image (1440 Kb) can usually be reduced to a fraction of its original size. The use of compressed images is therefore recommended, as it allows for faster loading and less usage of disk space.

gzip can be downloaded from here. Using gzip to compress the floppy disk image bcdl201a.ima, the image was compressed from 1440kb to 10.4kb.

Although Grub4dos only supports the .gz format natively, the memdisk kernel (part of the syslinux project) can be loaded to support .zip compressed images - e.g. the Winimage .imz format. The memdisk kernel can be gzip'ed and loaded from Grub4dos.

or,

or,

NOTE - in the above examples win98.ima would need to be on the same partition as memdisk.gz

Booting from .ISO Images

There are different types of CD boot emulation, including floppy emulation - in which the boot sector of the CD is a bootable floppy disk image. The boot sector is not accessible when viewing the CD in a file manager such as Windows Explorer and might appear to be a blank disk if no files are contained on the disc root.

In the following test an image was taken of a CD containing a DOS boot disk based bootsector, with various DOS utilities on the CD (not in the boot sector image). When booting this setup from a real CD, the bootsector image is allocated as the A: drive, and the CD-ROM (and files at the root of the CD) is allocated the next available drive letter. The CD image file (hd0,0)/dos.iso was booted using the commands above, this resulted in the following Grub4dos output -

The CD appeared to boot normally. The CD bootsector image was loaded and allocated the A: drive letter and the CD-ROM was allocated as E: drive. Unfortunately attempting to access any files on the E: drive (the root of the CD image) resulted in an error.

NOTE - if mkisofs 杋so-level 4 command has been used to create the .iso image (as is normal with PE builds), MSCDEX.EXE should not be used - replace with SHSUCDX (see here).

Edited config.sys and autoexec.bat and injected the amended files (and eltorito.sys) into the boot image, before rebuilding dos.iso. The remastered CD-ROM was booted, as before the bootsector itself was accessible however the root of the CD was not.

When mapping the .iso containing eltorito.sys in the bootsector as device (0xFF), the CD-ROM booted and both the bootsector image and the root of the CD were accessible.

The above example illustrates some of the complexities of CD-ROM Emulation. For working examples see this thread here

Nested Mapping

    PREVIOUS    INDEX    NEXT