China DOS Union

I am using GRUB4DOS version 08-5-2
Booting with MBR+GRLDR

title GhostXP_SP3 Computer Company Special Edition_v9.0 Official Version
map (hd0,1)/ISO/GhostXP_SP3_v9.iso (hd32)
map --hook
chainloader (hd32)

This ISO has been added with drivers and can successfully simulate and install the system.

But when I copy this ISO to other places, no matter where it is, using the above command to simulate the copy of this ISO will result in error 60. What's the matter?


And the original ISO can be normally booted when placed in any directory. The MD5 is obviously the same. Why can the original ISO be successfully booted, but the copy cannot?

Using Avlgomgr or ISOEMU can successfully boot the copy of the ISO.

I have been lurking for an entire night and rummaged through several forums but couldn't find the answer I want, so I post this to expect everyone to give me an accurate statement.

[ Last edited by fey1988 on 2008-5-24 at 07:27 AM ]

Changed several versions of GRLDR with the same result, even the latest test version of Lianbudianshi is the same, confused

You forgot to search "File for drive emulation must......" in the Google search box.

The newly created file has fragments on the disk. You need to use the contig tool to defragment your ISO file. A fragmented ISO cannot be emulated by grub4dos unless you add --mem.

Well, thanks to Master Budian for the guidance. Just now, I used
title GhostXP_SP3 Computer Company Special Edition_v9.0 Official Version
map --mem (hd0,0)/GHOSTXP.iso (hd32)
map --hook
chainloader (hd32)
It was indeed successful, but loading such a large ISO into memory is really time-consuming, and some computers simply don't have that much memory, so this method is not very practical. It's 700M...
Why can't it be like ISOEMU?
Does GRUB4DOS have less emulation capability than ISOEMU?

I'm sorry, this issue has been discussed many times before. grub4dos is grub4dos, don't think of it as omnipotent. You can still use ISOEMU. We have no intention of replacing the advantages of other software. Functions that can be introduced will be introduced, and functions that are not suitable for introduction or may bring other hidden problems after introduction will not be introduced. This is not the place for discussion, you can search for previous discussions online.

The prerequisite for using the emulation function of grub4dos is that your image file has been defragmented by contig. Most people know this, but you may be new to it, so you find it difficult to understand. Contig now belongs to Microsoft and is a tool for defragmenting disks, which can defragment individual files.

I'm sorry, there are still 2 questions.
Does the ISO file need to be sorted by contig every time it's copied? I've reorganized the ISO with WINcontig, and it hasn't been completed for more than an hour now.
Will the development of GRUB4DOS in the future cancel this bad condition?

You know, BIOS can't directly recognize the file system, and grub4dos's emulation depends on BIOS. So, you can't pass a file name to the int13 emulation program of GRUB4DOS, but you need to pass the starting address and length of the file to the int13 emulation program. This processing is different from that of ISOEMU. ISOEMU is related to the file system (I seem to remember that it uses DOS calls in a certain way, so it only seems to be applicable to FAT), while the emulation of grub4dos can be used for more file systems. In principle, there are no restrictions on the type of the file system. Each has its own advantages and disadvantages. You can choose according to your needs.

I've never heard of the wincontig tool. I think you might need contig because everyone generally uses this one.

Thanks for the guidance,
I spent the whole night researching the problem and finally got the answer,
But the time required to use contig to organize a 700M ISO on a USB flash drive is really astonishing, 1.5 hours,
If each time I copy the ISO, there will be fragments, and I have to use contig to organize them, it really feels a bit not worth it, heh heh

There is a way to try: first quickly format your USB flash drive to make it an empty USB flash drive, and then copy the ISO from the hard drive to the USB flash drive. At this time, the ISO file is generally continuous.

That is to say, under a file system without fragmentation (or under a file system that has been defragmented), newly created files are generally continuous.

Oh, so that's how it is.
I didn't know where those fragments came from before and couldn't find the key to the problem. Now I suddenly see the light.
The disk has fragments, so the newly created files also have fragments. Oh, that's how it is. I've learned something new again.

Thank you again, Master Budian, for taking the time to answer my little question.

Okay, I won't bother you during your precious working time. Keep working hard for the more and more powerful GRUB4DOS!

Originally posted by fey1988 at 2008-5-24 12:25 PM:
Thanks for the guidance,
I've been researching the problem all night and finally have an answer,
However, using contig to organize a 700M ISO on a USB flash drive takes an amazingly long time, 1.5 hours,
If ...

The long time taken by contig to organize on a USB flash drive is related to the read-write characteristics of the USB flash drive. Disk defragmentation tools are designed for hard drives, and disk defragmentation operations are extremely inappropriate on flash drives because small-file read-write speeds on flash drives are very slow, and the number of write operations during disk defragmentation operations is very large, which will affect the lifespan of the USB flash drive.

Therefore, contig is only suitable for use on hard drives. For USB flash drives or solid-state drives, formatting + copying is more appropriate.