623 replies to this topic

[Sha0]

WinVBlock is a free and open source Windows driver for using virtual disks. These disks appear in the Device Manager and Disk Management. It was originally derived from WinAoE, courtesy of V.

Currently supported are:

• RAM disks
  • Supported for booting from
  • MEMDISK-established
    • Floppies
    • Hard disks
    • Optical discs
  • GRUB4DOS-established
    • Floppies
    • Hard disks
    • Optical discs
• File-backed disks
  • Using the winvblk.exe command
  • Floppies
  • Hard disks
    
    • Supported for booting from via GRUB4DOS mapping
  • Optical discs
    
    • Supported for booting from via GRUB4DOS mapping
• AoE disks
  • Supported for booting from as established by gPXE or another SAN-booting mechanism, or
  • Using the winvblk.exe command
  • Hard disks

You'll find the WinVBlock and AoE drivers attached to my most recent post.

Source code should be available at the Etherboot & gPXE projects, courtesy of their project leader, Marty Connor.

Work on this driver was and is prompted by the discussion found in this thread.

See also: FiraDisk by karyonix. Fine work.

Examples:

Using PXELINUX and the MEMDISK included in the .ZIP file to create a hard disk in RAM
Directory layout:

/tftpboot/

/tftpboot/pxelinux.cfg/

/tftpboot/pxelinux.cfg/default

/tftpboot/memdisk

/tftpboot/RamXP.HDD

/tftpboot/pxelinux.cfg/default file:

DEFAULT ramxp

LABEL ramxp

  KERNEL memdisk

  APPEND raw

  INITRD RamXP.HDD

SYSLINUX, EXTLINUX, and ISOLINUX config-files could be the same as above

Using GRUB4DOS to create a hard disk in RAM
Directory layout:

/menu.lst

/RamXP.HDD

MENU.LST file:

default 0



title RamXP

  map --mem (hd0,0)/RamXP.HDD (hd0)

  map --hook

  root (hd0,0)

  chainloader /ntldr

Using WinVBlock in a Windows XP/2003 PE environment (such as BartPE)

Make sure you include:

• \I386\System32\Drivers\WVBlk32.SYS (or WVBlk64.SYS)

Make sure TXTSETUP.SIF includes:

...

[SCSI.Load]

wvblk32 = wvblk32.sys,4

...

---ORIGINAL POST FOLLOWS---

I swear that I read something about this before, but I am really lame with searching Boot Land. Way, way, too many posts to sort through and never find what I'm looking for. Then again, maybe it's because I never really read it. I guess I'll have to search on searching to find out what I'm doing incorrectly.

Anyway, yeah: Has anyone experimented with establishing a RAM disk from GRUB4DOS, booting that RAM disk to some flavour of XP (full/"PE") and having any version of RAMDISK.SYS pick up the GRUB4DOS-established RAM disk and provide it as the boot volume, thus avoiding our favourite friend STOP 0x...7B?

FYI, I'd really like to start working on an XP driver with just such support, but have to balance the time investment out with some practicality, meaning testing such equivalent functionality, if it already exists in another form.

I don't mean with ramdisk(0) and /rdpath= entries, thanks.

As an aside, there appears to be a blend of .SDI users and others, but I find a plain partition image to be way easier.

Some other "words" for future searchers:

map --mem blah
map blah (rd)
RAMDISK.SYS
Unmountable Boot Volume Prevention

- Sha0 Miller

[maanu]

if u r after to get rid of 0x7b error , a while i came across a ntldr combined with ntdetect.com from a chinese site ( znpc ) . i have not yet played with it but its mainly for that error i guess coz setup ll not have to look for ntedetect atfer 1st time of boot .

let me know if u want it .

sorry for being a little off topic but i thought u might be interested .

[Sha0]

if u r after to get rid of 0x7b error , a while i came across a ntldr combined with ntdetect.com from a chinese site ( znpc ) . i have not yet played with it but its mainly for that error i guess coz setup ll not have to look for ntedetect atfer 1st time of boot .

let me know if u want it .

sorry for being a little off topic but i thought u might be interested .

Thanks, maanu. I believe that you are referring to I386\OSLOADER.NT_, which uncompressed is an OSLOADER with NTDETECT.COM attached. I certainly appreciate your response, but I'm not certain that it helps me out for this particular situation.

[maanu]

Thanks, maanu. I believe that you are referring to I386\OSLOADER.NT_, which uncompressed is an OSLOADER with NTDETECT.COM attached. I certainly appreciate your response, but I'm not certain that it helps me out for this particular situation.

i very much doubt about this . bt anyways i have forwarded u the link in pm . coz im not sure if it is right to share in public .

use boot.ini with it if it gives any error .

[ilko]

@Andy Tim

If you make this happen, you have no idea how many people will be thanking you

[gth]

Considering how I/O constrained XP is, you'd be definitely a creator of something special if you managed to get a RAM disk running that XP trusts as a normal hard disk without stop errors.

Best wishes and good luck with all your efforts.

[was_jaclaz]

@Andy Tim

It's years I'm trying to induce any programmer to take this challenge, though I do not really ( please read completely NOT) agree with your approach.

Let's talk about it (or about the other possible ways), would you like to?



jaclaz

[xclimbing]

there is a shareware driver named wdsys.sys from diskless angel team by bean123.

the driver can do what you want.

Website: http://disklessangel.com/
Forum with examples: http://windrv.net

[was_jaclaz]

there is a shareware driver named wdsys.sys from diskless angel team by bean123.

the driver can do what you want.

Website: http://disklessangel.com/
Forum with examples: http://windrv.net

Which, just like several others possibilities, is listed on the reference thread:
http://www.boot-land...?showtopic=1507

jaclaz

[joakim]

Although shareware, the diskless angel driver, as demo, is supposed to accept images up to 640 Mb without restrictions when used with PE.

The bad part (for me), is that I have not been able to load any images with it yet.

Joakim

[Sha0]

I didn't mean to post and run. Thanks for the feedback, folks. I think it's worth pursuing.

The original post must be describing a poor memory on the original poster's part regarding having read about it.

Anyway, since I've recently done some MEMDISK .ISO-booting work with the Syslinux project, and plan on adding mapping functions, as well, a goal is to have an HDD MEMDISK image boot Windows [full or PE] and have a driver find the MEMDISK and attach it as a full-blown HDD (yes, in Device Manager and Disk Management).

The GRUB4DOS developer already has mapping and .ISO support, as everyone knows, so it'd be great to get MEMDISK to the same place.

I've spoken with the developer of WinAoE, who has given me some tips for making such a Windows driver.

.SDIs suck (too OS-specific with tools, format), and to a lesser extent, so do /RDPATH= and friends, because of the dependencies on WinSrv2003SP1.

The first idea is so that you can boot the RAM disk from a non-MS source, such as gPXE, GRUB[4DOS], [SYS|EXT|PXE|ISO]LINUX (via MEMDISK) or whatever, but then have the MS boot-loader chained-to. This allows for the image to be transferred by whatever means you like, and not restricted to an MS RIS TFTP transfer, for example. Flat images of a writable filesystem and padded to a desired "working environment" length and then compressed with GZip are cool, too. FAT images can practically be built dynamically.

The second idea is that it would cost nearly twice as much RAM if you packed an image for use with /RDPATH= into an enveloping image (.ISO or whatever), because the enveloping image takes up RAM (maybe from 64 MB down to 48 MB), but then the NTLDR/SETUPLDR/OSLOADER loads the embedded image into RAM again (maybe from 48 MB to a touch over 32 MB).

jaclaz: What were some of your thoughts of disagreement in regards to? Discussion is goooood.

- Sha0

P. S. Probably doesn't belong here, but: I also recently put together a SAN protocol for gPXE called "HTTPDisk" (not-yet-mainline), which works about the same way that httpdisk for Windows does... You can use gPXE to SAN-boot an HDD image via HTTP. The HDD image can then do whatever, such as loading a RAM-based PE environment. There are lots of firewalls everywhere, but good old HTTP is usually allowed, versus iSCSI. Another goal would be to have a loaded Windows re-attach httpdisk for Windows to the original source. HTTPDisk is read-only, so this might only be handy with .ISOs or disk/filesystem filter drivers.

[was_jaclaz]

jaclaz: What were some of your thoughts of disagreement in regards to? Discussion is goooood.

I am fiercely against the whole idea of a RAMDISK driver for at least two reasons:

• you need LOTS of RAM
• you need to load the whole image in RAM (copying time from a relatively slow media can be huge)

for the reasons above such a setup is practically unuseful for "repair/recovery" purposes on not-so-recent machines.

If one is willing to contribute (and has the "right" knowledge to write a driver which appears like some kind of "misterious art" even among programmers) my suggestion (or better my wish) would be that of attempting to write a "filedisk" kind of driver, i.e. a miniport driver capable of using an image file as if it were a hard disk.

Writing a "pure" bootable RAMDISK should not be that much difficult however, since at the time Dietmar Stoelting (which did a lot of great things/contributions, but which is not a programmer) wrote one, starting from old, public, NT code. (in simple words, what Windows 7 can do with .vhd files)

Traces of the process (and the actually released driver source, very limited in size) can still be found.

If you are interested, I could search and provide you the relevant links.

Another approach that I would favour nonetheless would be that of developing a fully documented way to "split" the system in such a way that only a really minimal "core", I am thinking about something in the 20÷50 Mb size range is loaded in RAM (for example using as base the released, limited to 32 Mb Ramdisk, by Dietmar) then load "all the rest" from an image file loaded through IMDISK, VDK or a similar (currentlly ) non-bootable driver.
In other words, expand the "XP Kansas city shuffle" or "Fake signature method" to use two images, instead one image+one "real" device.

Another direction that is IMHO worth the attention of a programmer is the ReactOS FREELDR, that has been reported to be able to boot "normally" Server 2003.



jaclaz

[dog]

It's not going to be something useful for every machine, but there are plenty of people interested in breaking the 500MB ramdisk barrier.
In case Andy Tim missed it, Joakim reported success using the disklessangel driver:
http://sanbarrow.com...opic.php?t=1560
An open source alternative would be even better

[Sha0]

jaclaz:

Is the usage scenario for what you are referring to do with using a file inside some existing filesystem or simply a range of contiguous sectors? Either way, are you willing to accept the restriction that the file must be contiguous? I would assume that your usage scenario also involes an actual block device with the "file" on it being available, and that you are not referring to the "file" being provided over network. If so, I can imagine MEMDISK and the driver co-operating in the following manner:

MEMDISK is told to map BIOS drive number 0x80 to the real 0x80, sectors XXX through YYY
MEMDISK reads the MBR signature from the real 0x80 and stores it in a MEMDISK table in memory somewhere the Windows driver can find it
MEMDISK stores the range XXX through YYY in the same table
The Windows driver locates and reads the MEMDISK table, then starts looking for an attached disk with the same MBR signature
The Windows driver finds the matching disk, then redirects blocks for I/O to the appropriate blocks on that other attached disk

Note that the driver for the backing block device must be present and must provide the backing block device early on, so the process just described can redirect reads and writes to it.

How does this read? This is obviously not using a RAM disk at all, but using another block device, which you'd see as more useful than a RAM disk driver. What is a specific example of when you'd use it?

[offtopic]
By the way, I came across a post of yours which detailed the time and effort it takes for a programmer to provide pre-built software for the public. I'm not a terrific programmer, but I know that one of my primary concerns whenever offering a build of some code, is compliance with any licenses along the way. Sometimes it might even be tricky to keep track of which licenses need to be complied with! Anyway, if this driver is based on WinAoE, I would certainly hope that offering builds would not be an issue. Of course, using components of Windows Server 2003 SP1 in order to boot a Windows XP PE on any old computer somewhat shows the spirit of license regard in these forums. While the forums are merely instructions, a download of built code is... Somebody in particular offering that code.
[/offtopic]

dog:

Thanks for the link. Open Source would be better, indeed. Does that driver show disks up in Device Manager? If so, and you choose View -> Devices by connection, does it show the disk as attached to anything special in particular?

All:

Let's see about adapting WinAoE to the RAM disk case first, then going from there...

- Sha0

[was_jaclaz]

In my view, which mind you is not necessarily "right" or "accurate , we already have grub4dos mapping a disk image to BIOS device feature, as used, among the others, in "XP Kansas City Shuffle", we need NOT anything else as far as "real mode" is concerned.

As known, when the NTLDR (or SETUPLDR.BIN) through NTDETECT.COM re-scans the hardware, the mapping created by grub4dos gets "lost in translation".

Now, if we have a Miniport kind of driver capable of:
- starting as boot device
- connecting somehow (either statically - i.e. with hardcoded path or dynamically - i.e. reading a setting in the Registry or in a .ini file) to the same "source" image mapped by grub4dos
- being somehow detected/forced/whatever by NTDETECT.COM or however used as bootdevice

My approach would be to experiment (something that I have been planning to do since a lot of time, but that I simply couldn't find the time to do) with the only available (limited to 128 Mb, but enough to experiment with a minimal build or even with Recovery Console) "full" Miniport driver I could find, the PERISOFT Minifile:
http://www.perisoft....iport/index.htm

Another source for inspiration could be the cooldev apps (courtesy of the Waybck Machine):
http://web.archive.o...oolsockets.html
http://web.archive.o...oolstorage.html
http://web.archive.o...m/download.html
http://web.archive.o...orageoverip.zip
http://web.archive.o...ol/ksockumh.zip

Not one single programmer among the members of boot-land appeared to be interested to this:
http://www.eterlogic...alDriveSDK.html

As well, noone AFAIK took this project:
http://sourceforge.n...cts/virtualdisk
from where it's Author, Primoz Beltram left it.

It may be possible, if this approach works, to later expand it to use a similar to "XP Kansas city shuffle" approach, using it to boot the "kicker" image and then re-loading the "full" image though an unlimited (though not fully "miniport" driver) such as VDK.EXE.

Even better, a willing programmer could start from the already more than tested VDK code and enchance it to add the missing features, i.e. completing the things listed in it's todo:
http://chitchat.at.i...e/vdk.html#todo
taking it from where Ken Kato left it and "complete" it.

About RAMDISK approach, as said, we already have sources for the 32 Mb bootable Ramdisk by Dietmar, AND those for Gavotte's RRamdisk.sys, my guess is that a knowledgeable programmer could somehow "merge" the two rather than start from scratch.




jaclaz

P.S.: Just found another RAMDISK that seems to have a lot of nice features:
http://www.boot-land...?...=4064&st=52

[Sha0]

jaclaz: I have to ask though, what is the advantage to having Windows boot and attach a file as an HDD and continue booting from that virtual HDD? One needs the driver(s) to speak to the device which the file actually resides on. If you have those drivers available, why not simply boot from a partition on the device itself? Where BIOS uses INT 0x13 to talk to drives, thus capable of being spoofed, Windows cannot talk to drives through that same mechanism. Could you describe a situation where it would be useful to boot from an HDD image, instead of a partition itself? It will help me to understand.

I do see a useful purpose for software RAID or device-mapper-like abilities, where one could amalgamate HDDs (or their partitions) and/or have copy-on-write functionality.

The copy-on-write scenario is interesting... Consider two partitions; one is 3 GB and one is 77 GB. Suppose you had a driver that obeyed the following logic:

Read request -> Does our map on the 77 GB volume show that these sectors have been written before?

  No -> Do the requested sectors fall inside our 3 GB volume?

	No -> Return zero-filled sectors

	Yes -> Return the sectors from our 3 GB volume

  Yes -> Return the sectors from our 77 GB volume

Write request -> Write the sectors to the 77 GB volume, mark our map accordingly

You can see that it is a bit ugly due to the map of previously written sectors... Where should this map go? How much space should we reserve for it? Does it depend on the sizes of the volumes involved? For copy-on-write, I'd rather have a filesystem filter do the work. Then your master read-only volume (3 GB in the example above) could even be an ISO9660 filesystem. The delta filesystem would obviously have to be read/write. A filesystem filter's logic could go:

Read file request -> Does the file exist in our delta filesystem?

  No -> Does it exist in our master filesystem?

	No -> File not found, fool!

	Yes -> Return file

  Yes -> Return file

Write file request -> Use the delta filesystem

That seems nicer to me (maps are already part of filesystem logic). The essential problem seems to be that all of these drivers (block or filesystem-filtering) either cost money, or are part of a product for which you must have a license (cost money).

I've taken a look at most of the links you posted, jaclaz, and the ones I've seen are proprietary. I really think we could benefit by deriving from WinAoE, instead.

- Sha0

[was_jaclaz]

jaclaz: I have to ask though, what is the advantage to having Windows boot and attach a file as an HDD and continue booting from that virtual HDD? One needs the driver(s) to speak to the device which the file actually resides on. If you have those drivers available, why not simply boot from a partition on the device itself? Where BIOS uses INT 0x13 to talk to drives, thus capable of being spoofed, Windows cannot talk to drives through that same mechanism. Could you describe a situation where it would be useful to boot from an HDD image, instead of a partition itself? It will help me to understand.

Let's do it the other way round.
What can go wrong when booting from a partition a PE 1.x or "full" XP/2003?

• You need to actually partition/re-partition the device (and this may be tricky/creating something failing to boot)
• You need to actually create a new filesystem by formatting the newly created partition (and this may tricky/creating something failing to boot)
• You need to copy system files to the newly created partition.(and this may tricky/creating something failing to boot)
• You then have a problem with "hardcoded" names, such as \I386 or \minint, that makes you need to hexedit binary files (and this may tricky/creating something failing to boot), and if you use newish sources, like 2003 you need to also modify checksum verification.
• You then have problems with "common" locations, such as "Program Files" or "Documents and settings".

In other words, if you have just one PE or XP on a device partition there are not much problems, though for example cloning/duplicating it would still remain a bit complex.

When you are going multiboot, things stack one over the other unless you are very careful.

If and when we will have a bootable miniport virtual disk driver, things will get much simpler since EACH of the multiboot items will be self-standing and self-contained.

Just think of the nightmare it was (and still is for those not compatible) having multiple Linux Distros on same device before grub4dos (and now memdisk too) came out with .iso mapping.

I've taken a look at most of the links you posted, jaclaz, and the ones I've seen are proprietary.

Sure they are , they were given as examples, just to show that it is possible to write the said "miniport virtual disk driver", come on, if there already was a Freeware/Open Source solution, why would I be talking to you, and everyopne else, pointing out that such a driver does NOT exist, AFAIK?

I really think we could benefit by deriving from WinAoE, instead.

Well, that is yours (programmer's) problem . I don't care much from where the "base code" comes or whether you have to write it from scratch assembling it byte by byte, nibble by nibble or bit by bit , the main thing is the result , I was just trying to help in giving a list of possible sources of inspiration.



jaclaz

[Sha0]

Ok, well I'm already working on the driver for the last couple of days...

tinybit or bean123: Do you folks:

• have any suggestions for magic or signature behaviour I could rely on from GRUB4DOS for finding and establishing the memory-mapped drive in Windows?
• mark the memory in the E820 map?
• lead exactly 63 sectors when "leading the boot sector" for a partition image? What geometry calculation?
• have any tables in well-defined locations I could parse?

I could read the code, but a friendly discussion would be great

- Sha0

[karyonix]

1. You can read real mode interrupt vector 13h in physical address 0x0000004C and convert from segment:offset form to flat address. Look at the location where INT13h point to. It should be GRUB4DOS's hook code there if no one has modify INT13h vector between the time GRUB run and the time driver run.

I think GRUB4DOS can be modified to create some structure at that location to help protected mode code to recognize its existence and its data including mapping table or memory address.
But if we chainload and create ramdrive in GRUB4DOS, another ram drive in MEMDISK before loading NTLDR, would that still work?

In the old days, Microsoft's suggested structure of INT13h is like this -- http://www.osronline...torage_5l6g.htm
That structure allow Windows 95-98 and drivers to recognize real-mode disk driver that has equivalent protected-mode driver installed and allow 32-bit disk access.

I think all real-mode INT13h hooks (GRUB4DOS, MEMDISK, ...) should also use same structure, so protected mode drivers can traverse the hooks chain to find a matching id instead of just checking only the last hook.
Additional data can be placed next to the SafeMBRHook structure.

GRUB4DOS should also hook INT15h E820 function to prevent OS from overwriting ramdrive memory. I don't know whether GRUB4DOS already does this or not.

Sorry for my poor English language.

[tinybit]

Ok, well I'm already working on the driver for the last couple of days...

tinybit or bean123: Do you folks:

• have any suggestions for magic or signature behaviour I could rely on from GRUB4DOS for finding and establishing the memory-mapped drive in Windows?
• mark the memory in the E820 map?
• lead exactly 63 sectors when "leading the boot sector" for a partition image? What geometry calculation?
• have any tables in well-defined locations I could parse?

I could read the code, but a friendly discussion would be great

- AndyTim

Great work doing so. Thanks, Tim.

asm.S is a good start point.

The int13 handler data structure begins at "int13_handler:", which will be at offset 0 of the CS segment.

Drive map table begins at offset 0x20:

. = int13_handler + 0x20 /* drive map table begins at 0x20 */

ENTRY(hooked_drive_map)
.space (DRIVE_MAP_SIZE + 1) * DRIVE_MAP_SLOT_SIZE

/* The size of the drive map. */
#define DRIVE_MAP_SIZE 8

/* The size of the drive_map_slot struct. */
#define DRIVE_MAP_SLOT_SIZE 24

Each map entry occupies DRIVE_MAP_SLOT_SIZE=24 bytes. There are DRIVE_MAP_SIZE=8 mappings at most, and the nineth(ending) mapping is filled with zeroes. See below for details of the drive_map_slot structure.

The handler code begins at offset 0x100(Surely, this is where the int13 vector should point to):

. = int13_handler + 0x100 /* real int13 handler entry at 0x100 */

At offset 0x103 there is a 16-byte signature which can be used to locate and confirm the grub4dos int13 handler:

. = int13_handler + 0x103
.ascii "$INT13SF" /* Win9x use this! Don't touch! */
.ascii "GRUB4DOS" /* 8-byte Vender ID */

The drive_map_slot struct is defined in shared.h:

struct drive_map_slot

{

	/* Remember to update DRIVE_MAP_SLOT_SIZE once this is modified.

	 * The struct size must be a multiple of 4.

	 */



	  /* X=max_sector bit 7: read only or fake write */

	  /* Y=to_sector  bit 6: safe boot or fake write */

	  /* ------------------------------------------- */

	  /* X Y: meaning of restrictions imposed on map */

	  /* ------------------------------------------- */

	  /* 1 1: read only=0, fake write=1, safe boot=0 */

	  /* 1 0: read only=1, fake write=0, safe boot=0 */

	  /* 0 1: read only=0, fake write=0, safe boot=1 */

	  /* 0 0: read only=0, fake write=0, safe boot=0 */



	unsigned char from_drive;

	unsigned char to_drive;		/* 0xFF indicates a memdrive */

	unsigned char max_head;

	unsigned char max_sector;	/* bit 7: read only */

					/* bit 6: disable lba */



	unsigned short to_cylinder;	/* max cylinder of the TO drive */

					/* bit 15:  TO  drive support LBA */

					/* bit 14:  TO  drive is CDROM(with big 2048-byte sector) */

					/* bit 13: FROM drive is CDROM(with big 2048-byte sector) */



	unsigned char to_head;		/* max head of the TO drive */

	unsigned char to_sector;	/* max sector of the TO drive */

					/* bit 7: in-situ */

					/* bit 6: fake-write or safe-boot */



	unsigned long start_sector;

	unsigned long start_sector_hi;	/* hi dword of the 64-bit value */

	unsigned long sector_count;

	unsigned long sector_count_hi;	/* hi dword of the 64-bit value */

};

map (TO_DRIVE)START_SECTOR+SECTOR_COUNT (FROM_DRIVE)

From_drive is the virtual drive. To_drive is the real media for the virtual drive. If To_drive==0xff and bit14 of to_cylinder==0, then the mapping is for --mem.

INT15 already handled(if necessary) in int15_e820_handler. So you needn't do this any more.

lead exactly 63 sectors when "leading the boot sector" for a partition image?

Likewise, you needn't take this into consideration. The work had been already done before the preparation and establishment of the mapping data.

[Sha0]

karyonix: I will certainly review that information.

tinybit: Excellent information; that's great.

Regarding my question about 63 sectors: One possible strategy I had in mind was to look at the E820 map and look for a range that matches a Registry-defined value, or that value plus 63. For example, a user makes an NTFS partition image and knows it's XXX sectors. They put XXX into the Registry as a value for the RAM disk driver. However GRUB4DOS has automagically prepended 63 sectors and marked XXX + 63 as a range in E820, so I'd also have the driver search for a range of XXX + 63.

Anyway, it appears that I can directly parse your table, so it's a non-issue.

Great!

- Sha0

[karyonix]

Thanks tinybit for the detailed information. That means GRUB4DOS does not need any change.

Tim: That's one possible way to find data in RAM, but it's a little risky. The sector's data can be coincidentally copied into memory block reserved by other boot programs or BIOS. How can we differentiate it from GRUB4DOS's memory.

Now that we know GRUB4DOS has all the structure required to be detected easily.
There is no need to scan INT15h E820's memory blocks for disk signature.
Just read interrupt vector. Verify that it points to GRUB4DOS (or another $INT13SF handler). That address - 0x100 + 0x20 is the drive_map_table. That should be enough to get RAM drive's address.

We don't need number 63. First partition doesn't always begin at sector 63. Just read partition table in RAM drive's first sector to see where its partitions are.

[tinybit]

karyonix: I will certainly review that information.

tinybit: Excellent information; that's great.

Regarding my question about 63 sectors: One possible strategy I had in mind was to look at the E820 map and look for a range that matches a Registry-defined value, or that value plus 63. For example, a user makes an NTFS partition image and knows it's XXX sectors. They put XXX into the Registry as a value for the RAM disk driver. However GRUB4DOS has automagically prepended 63 sectors and marked XXX + 63 as a range in E820, so I'd also have the driver search for a range of XXX + 63.

Anyway, it appears that I can directly parse your table, so it's a non-issue.

Great!

- AndyTim

In my previous post I have mentioned that you need not consider the "63 sector" issue. In fact, there is no such issue, because the memory-image of the mapping has been (re-)built with a track(usually 63 sectors) already prepended.

[tinybit]

That address - 0x100 + 0x20 is the drive_map_table.

Thanks, karyonix.

I should correct that the drive_map_table array begins at offset 0x20, not 0x100 + 0x20.

[Sha0]

Heheh, I apologize that I wasn't clear...

Before your post (tinybit) saying there was an easy-to-get-at table that GRUB4DOS makes, I had a worst-case scenario in mind for how to find any RAM disk established by any boot-loader, as long as that boot-loader marked the E820 map.

Suppose a user has a partition image (not HDD image with an MBR) that is XXX sectors. The user tells my driver to look for a RAM disk with XXX sectors. However, a boot-loader like GRUB4DOS which prepends an MBR and 62 sectors of padding would likely make an E820 region that would be ( ( XXX + 63 ) * 512 ) bytes. So I was simply saying that my driver should look for an E820 region that is XXX sectors, and if it doesn't find one, look for a region that is XXX + 63 sectors.

But anyway, like I said, it's a non-issue (not an issue). I was only asking because I wanted to know if GRUB4DOS always prepended 63 sectors to a partition image. You said "usually", tinybit. It really doesn't matter, because I am going to use your table. Hopefully, your assembly doesn't change and that table stays where it is forever.

I would like to adopt a different strategy for MEMDISK. I'd like MEMDISK to establish an "mBFT" resembling the "iBFT" for iSCSI and the "aBFT" for AoE. Once implemented, it might be nice if GRUB4DOS implemented it too, but that discussion can wait for another time. An "mBFT" would be an alternative to the current mechanism that karyonix suggested, and which GRUB4DOS currently implements.

jaclaz: Have you ever tried making a contiguous HDD image in an EXT2/3 filesystem and booting that image with GRUB4DOS? A large HDD image with DOS on it, for example?

Thanks for the discussion, everyone. Eventually, I'd like this driver to offer some crazy features.

- Shao