grub4dos: map --mem is too slow for large iso External links Options

[somanystars]

Hi all! I've got a trouble with mapping iso image. It's size is 120 Mb and it takes 7 minutes (grub4dos-0.4.5a-2010-01-08) to load. I have 2 questions:
1) Is there any way to speed up map --mem (maybe some specific options...)? Because it's rather troublesome to defragment each iso, and I saw many times Windows placed iso in 2 fragments while there was space to place file in 1 fragment.
2) Is it possible to update map --mem functionaly so that it'll not be actually reading all the iso file contents to the memory, but instead will redirect queries on-the-fly inside the int13 handler? I mean something like this:

CODE

struct DriveCoords
{
unsigned char cylinder;
unsigned char head;
unsigned char sector;
};

struct MapItem
{
DriveCoords firstVirtual;
DriveCoords lastVirtual;
DriveCoords firstReal;
};

#define MAX_FRAGMENTS 100

//Return values:
// 0 - Mapped OK
// 1 - Error
int VirtualToReal(DriveCoords& coords);

MapItem[MAX_FRAGMENTS] g_fragMap;
unsigned long g_fragCount = 0;

//Return values:
// 0 - Mapped OK
// 1 - Error
int PushMapItem(MapItem& mapItem)
{
if (g_fragCount < MAX_FRAGMENTS - 1)
{
g_fragMap[g_fragCount] = mapItem;
++g_fragCount;
return 0;
}
return 1;
}

#define ABS_COORDS(coords) (((unsigned long)coords.cylinder << 16) | ((unsigned long)coords.head << 8) | ((unsigned long)coords.sector << 8))

//Return values:
// 0 - Mapped OK
// 1 - Error
int VirtualToReal(DriveCoords& coords)
{
for (int i = 0; i < MAX_FRAGMENTS; ++i)
if (ABS_COORDS(mapItem.firstVirtual) <= ABS_COORDS(coords)
&& ABS_COORDS(coords) <= ABS_COORDS(mapItem.lastVirtual))
{
coords = g_fragMap[i];
return 0;
}
return 1;
}

[Wonko the Sane]

Because it's rather troublesome to defragment each iso, and I saw many times Windows placed iso in 2 fragments while there was space to place file in 1 fragment.

Please define troublesome :
http://wincontig.mdtzone.it/en/
http://technet.microsoft.com/en-us/sysinte...s/bb897428.aspx



Wonko

[somanystars]

Yes, I know these utilities but they are inconvenient. I have USB stick with my data files on it. Free space is enough for iso. But after copying it and running contig.exe I get the message:

There is not enough room on the disk for a defrag of this file.

WinContig yields the same result, too. It means I must move some files off the USB drive, then defragment it using full-featured defragmenter (otherwise there may be no contiguous chunk to fit the whole iso) and then copy iso again. It IS troublesome, isn't it?

And, after that, if it would be my own troubles only, I would accept the situation. But my aim is to create utility that will make bootable USB drives WITHOUT extracting files from iso image, as programs like Unetbootin do. (I know that not every iso image will work without changes, but many will do.)

It would be interesting to know is there any real technical difficulties with "virtual map --mem", or grub4dos authors just had no time to implement more advanced technique.
It would be great if tinybit, cheenall or karyonix clarify this question...

[Wonko the Sane]

It would be interesting to know is there any real technical difficulties with "virtual map --mem", or grub4dos authors just had no time to implement more advanced technique.
It would be great if tinybit, cheenall or karyonix clarify this question...

From what I understand, the problem is NOT easily solvable.

The map --mem works because data is copied into a contiguous chunk of memory.

As is, the only things that grub4dos "understands" are:

• mapped device starts at address xxxxxx
• mapped device is yyyyyy long

Let's hope that the good grub4dos developers find a solution, but most probably it is not one of the top priorities.

WinContig yields the same result, too. It means I must move some files off the USB drive, then defragment it using full-featured defragmenter (otherwise there may be no contiguous chunk to fit the whole iso) and then copy iso again. It IS troublesome, isn't it?

Since USB sticks are generally of "little" size, a not too bad way is to use the good ol' poorman's way:
http://www.msfn.org/board/index.php?showto...131017&st=3

I mean, you have to have a backup of the stick anyway, don't you?



Wonko