Jump to content











Photo
* * * * - 3 votes

WinVBlock


  • Please log in to reply
617 replies to this topic

#201 supaJ

supaJ

    Member

  • Members
  • 51 posts
  •  
    Canada

Posted 16 May 2010 - 11:08 AM

I've read the entire thread and I can't seem to get an answer to this question: Is it possible to create an HDD image of a working XP installation w/ WinVblock installed and boot that image with grub4dos without loading the image to RAM - no MAP -mem or memdisk ...? In other words I want to be able to work directly on the 'filedisk', like Win7 and VHD. Can this be achieved with WinVBlock?

BTW, great work Shao.

#202 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1682 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 16 May 2010 - 12:43 PM

Not yet, but please keep checking... I'm pouring a lot of time into WinVBlock these days and hope to have some neat improvements soon. :cheers:

Such a thing is extremely tricky; GRUB4DOS' file-backed disks use BIOS drive numbers, but Windows doesn't. Thus, there's no direct correlation for a Windows driver to use. On top of that, consider this boot sequence order of events:
  • Disk objects are produced
  • Volume objects are produced
  • Boot volume is found
Since you want to use a virtual disk that's from a file, you need to wait until volumes are made so you can access the file, but you want to provide a disk, which happens earlier!
  • Disk objects are produced
  • Volume objects are produced
  • Now I can provide the boot disk, but after the stage where disks were produced
  • Now I need for volumes on this boot disk to be produced, after the stage where volumes were produced
  • Boot volume is found
So you see the complication there, I hope... In order to prevent an .HDD hard disk image on your filesystem from being moved around, you'd want a filesystem lock on the file.

#203 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1682 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 16 May 2010 - 10:31 PM

WinVBlock 0.0.1.7 released. The WinVBlock-0.0.1.7.zip archive's MD5 hash is 9B1FAECF96E0CA5ACA1627BB94C8219D. Also see the ReadMe.txt file for driver installation instructions. The AMD64 (x64) drivers are included again.

[version] Up version to 0.0.1.7

This version sees a couple of changes:

- AoE has been split off as a separate driver that depends
on the WinVBlock bus driver. This removes the bus driver's
dependency on NDIS.SYS. You can boot from an AoE disk still,
but pay attention to the service load order; you want NDIS to
load first, then your NIC's driver, then WinVBlock, then AoE.

- Geometry detection has been added for file-backed disks, so
you can hopefully do:

winvblk attach c:\foo.hdd h 0 0 0

and get the right geometry.

- We now always create a root-enumerated bus device. There's
no longer a need to add the /WINVBLOCK=BUS=1 option to the
BOOT.INI or TXTSETUP.SIF files.


- Shao Miller

Attachment removed -- Obsolete due to newer version; check post #1 for download link.
58 downloads at time of removal.


#204 Galapo

Galapo

    Platinum Member

  • .script developer
  • 3841 posts
  •  
    Australia

Posted 16 May 2010 - 11:50 PM

Hi Shao,

Is the AOE driver needed for PE? I'm looking at updating the WinVBlock.script with your new package.

Thanks,
Galapo.

#205 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1682 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 17 May 2010 - 12:20 AM

Good day Galapo,

I should probably clarify that a bit.

The WinVBlock driver provides:
  • A "bus" device (an "HDD controller" or "SCSI adapter")
  • MEMDISK RAM disks (as a boot disk: supported)
  • GRUB4DOS RAM disks (as a boot disk: supported)
  • File-backed disks
The AoE driver:
  • Provides AoE SAN disks
  • Depends on NDIS
  • Depends on the WinVBlock bus being available
  • Depends on NDIS, NIC driver, WinVBlock all being started before it (AoE) is started
So if you just want RAM and file-backed disks, you don't need to install the AoE driver.

#206 Galapo

Galapo

    Platinum Member

  • .script developer
  • 3841 posts
  •  
    Australia

Posted 17 May 2010 - 12:44 AM

Hi Shao,

Thanks for the added details. That's clarified things for me.

Thanks,
Galapo.

#207 liuzhaoyzz

liuzhaoyzz

    Newbie

  • Members
  • 19 posts
  •  
    China

Posted 17 May 2010 - 02:51 PM

Shao,thank you!Great job!
I successfully booted my "full" WIN XP PE with winvblock0.0.1.7.
I saw all external programs and MEMDISK optical disk.
The following way will work:
1.Added txtsetup.oem,WinVBlk.INF,wvblk32.sys to winvblock.ima with wimimage.
2.menu.lst
title tongyong WINPE by Uepon(TonPE.iso+winvblock)
map --mem (pd)/winvblock.ima (fd0)
map --mem (pd)/TonPE.iso (0xff)
map --hook
chainloader (0xff)
boot
3.Use tftpd32+grldr+winvblock to boot WINPE from PXE.

Another way will work either:
1.Added wvblk32.sys to inner RAM winpe.im_ WXPE\SYSTEM32\DRIVERS.
2.Modified txtsetup.sif just like the way ramdisk.sys worked.
[SourceDisksFiles]
...
ramdisk.sys=100,,,,,,5_,4,1,,,1,4
wvblk32.sys=100,,,,,,5_,4,1,,,1,4
...

[ScsiClass.Load]
...
ramdisk=ramdisk.sys
wvblk32=wvblk32.sys
[ScsiClass]
...
ramdisk="RAM Disk Driver"
wvblk32="wvblk32 driver"
3.\pxelinux.cfg\default
UI menu.c32
prompt 0
allowoptions 0
timeout 30
menu title pxelinux boot from PXE
label WINPE by uepon(TonPE.iso)
kernel memdisk raw iso initrd=TonPE.iso
4.Used tftpd32+pxelinux.0+memdisk+winvblock to boot WINPE rom PXE.

When I saw the changelog of syslinux3.84(2009.12.18),I saw that it is you who patched MEMDISK and made it support ISO format.
I am still looking forward to your memdisk.c32 that support multi-images,which ICECUBE have mentioned .I am sorry for I don't know how to use it.Perhaps your main attention isn't on it or it is not stable.That is,I still want to use winvblock like this in PXELINUX:
label WINPE by uepon(TonPE.iso)
kernel memdisk raw floppy initrd=winvblock.ima
kernel memdisk raw iso initrd=TonPE.iso

#208 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1682 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 01 June 2010 - 07:38 AM

WinVBlock 0.0.1.8:

Date: Tue Jun 1 03:19:42 2010 -0400

[version] Up version to 0.0.1.8

This release introduces initial support for GRUB4DOS
sector-mapped disks. Currently, only HDD images with MBRs
are supported.

Please note that this is an early stage in supporting this
scenario, so you might find quirks. Also be aware of the
limitations:
- If your booted-from disk image file gets _moved_ while you
are booted from it, expect terrible things to happen. Try
to avoid such things as defragmenting the filesystem with
the disk image on it!
- There isn't really a good way to know which Windows disk a
GRUB4DOS backing disk corresponds to! Not enough information
is available to make the right decision. BIOS drive numbers
have no relevance in Windows, so we cannot exactly identify
which backing disk is correct for a disk image
- WinVBlock is not capable of magic; your booted disk image
_must_ have drivers and device ID associations so that the
_real_ disks are found at boot time!


I'm open to discussion about how to best associate which GRUB4DOS backing disk is which Windows disk. It is very tricky, in my opinion.

Enjoy.

- Shao Miller

Attached Files


  • abcd1232 and mr_jrt like this

#209 karyonix

karyonix

    Frequent Member

  • Advanced user
  • 453 posts
  •  
    Thailand

Posted 01 June 2010 - 10:45 AM

Nice. :)

I'm open to discussion about how to best associate which GRUB4DOS backing disk is which Windows disk. It is very tricky, in my opinion.


Some idea
  • If host disk is installed in Windows and have its registry subkey in Enum key. There can be a flag value in its key that tell you "this is host drive".
  • Identify host disk by MBR signature.
  • Store host disk MBR signature in registry inside disk image.
    You can store it in driver service subkey or any other place.
    This is my plan for DiskMod "crop" feature. DiskMod reads first sector of all disks. If MBR signature match a subkey in DiskMod's parameters key, it will read options from that subkey.
  • Add host disk signature to boot.ini parameter.
    It is text file. It can be modified easily if you move image to another host drive.
    It can even be modified by GRUB4DOS script at boot time.
  • GRUB4DOS user (or script) allocates some RAM to provide "additional information" for WinVBlock.
    This can be done from menu.ls without modifying GRUB4DOS.
    One way is to use "map --mem" command to create a small RAM drive with a special drive number 0x55 (or other number) and contain "WinVBlock parameter" structure that will be recognized by WinVBlock.
    User or script copy host disk's MBR signature into "WinVBlock parameter" structure by using dd command.
    WinVblock recognize this structure and read "additional information" from it and know that this is not real RAM drive.


#210 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13750 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 01 June 2010 - 11:07 AM

- There isn't really a good way to know which Windows disk a
GRUB4DOS backing disk corresponds to! Not enough information
is available to make the right decision. BIOS drive numbers
have no relevance in Windows, so we cannot exactly identify
which backing disk is correct for a disk image

I am not sure of the question, let alone of the answer. :(

Can we start using a disambiguated terminology?

I propose (presuming I did actually get the meaning):
GRUB4DOS grub4dos backing disk=Physical disk (whole disk or \\.\PhysicalDrive) containing the image mapped by grub4dos-> Physical Disk Hosting grub4dos Image
grub4dos backing drive=Physical disk partition (parittion ONLY or \\.\LogicalDrive) containing the image mapped by grub4dos-> Logical Drive Hosting grub4dos Image

What happens if using dd --list:
http://www.boot-land...?showtopic=8219

Can you post an actual example of usage (actual grub4dos menu.lst entry or sequence of commands)?

Cannot we use, as sugested by karyonix the MBR signature for the disk and the (uuid) for the partition (or even a simplier "tag-file)? :)

:(
Wonko

#211 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1682 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 01 June 2010 - 12:52 PM

To boot an HDD image file via GRUB4DOS and WinVBlock, do something like:
map (hd0,0)/WinXP.HDD (hd0)

map --hook

root (hd0,0)

chainloader /ntldr

boot
I enjoy karyonix' ideas and had thought of some of them too, so am glad karyonix has validated them by offering them. :) We can certainly use MBR disk signatures to identify... Hard disks. What about a Windows PE .ISO on a CD? How does one tell Windows which CD to use as the backing device for the .ISO? Is this a scenario nobody would be interested in? What about GPT-style HDDs? Should we count on their legacy MBR at all having anything useful?

Another idea is to have well-defined magic in HDD or ODD images, such as appended to an .HDD or .ISO file. This would require minimal work from GRUB4DOS, but complicates image files slightly... HDD images would be best with a whole cylinder added so that they end on a cylinder boundary, and how does one append to an .ISO without wrecking it for burning (I have not yet tried)?

I would prefer that specifics about the backing disk be isolated from the HDD/ODD image files, so that everything still boots if you copy to another HDD, put the file in another .ISO, copy to a different USB stick, etc. So doing things in GRUB4DOS or putting magic in the disk image seems like the best way to achieve that.

Also, Wonko the Sane: Might you be interested in trying this current version using the code section just above? I was under the impression that you were quite interested in a boot-from-file feature.

#212 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7771 posts

Posted 01 June 2010 - 01:11 PM

Just a crazy idea.
How about using the image file itself as a tag file, to identify the backing device?
If it is wanted, for some reason, that image files with the identical name exist on a couple of drives. An extra tag file with a unique number as name would do to.

:)

#213 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1682 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 01 June 2010 - 01:26 PM

...How about using the image file itself as a tag file, to identify the backing device?...

A nice idea, but we are creating a boot disk. Disks come before filesystems, so we cannot reasonably access filesystems until later. We have to decide which disk to use as the backing disk before filesystems are mounted, since filesystems need to sense filesystem structures on boot disks. It's a circular dependency. Hot-swapping to a file later on is possible, and safer too, since it should help to lock the file against being moved by defragmentation, for example. (I think.)

Also, I might not have been too clear... You should currently be able to boot from an HDD image file right now, everyone. I'd like to read about some successes. This other discussion is for future, safer, saner methods.

#214 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13750 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 01 June 2010 - 01:35 PM

Also, Wonko the Sane: Might you be interested in trying this current version using the code section just above? I was under the impression that you were quite interested in a boot-from-file feature.

Yep :), guess why I asked for an example? :(

Though It wil take me some time, I am currently experimenting in an alltogether different direction/field.

UUID for partitions is already supported in grub4dos.

About UUID for CD's, maybe you can use an approach similar to VirtualBOX? :(
http://vbox.innotek....May/001572.html
but most probably, since it is UN-probable that there are more than one CD/DVD devices connected and even if there are, that they will ALL have a same label/creation date, you could use those ISO fields? :(

:(
Wonko

#215 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7771 posts

Posted 01 June 2010 - 03:13 PM

A nice idea, but we are creating a boot disk. Disks come before filesystems, so we cannot reasonably access filesystems until later.

Sorry, i'm completely lost.
If you want to identify the backing device, before even trying to access it, then how should work this:

Another idea is to have well-defined magic in HDD or ODD images, such as appended to an .HDD or .ISO file. This would require minimal work from GRUB4DOS, but complicates image files slightly


:)

#216 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1682 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 01 June 2010 - 03:52 PM

Sorry, i'm completely lost.
If you want to identify the backing device, before even trying to access it, then how should work this:

So the way I currently implement booting a file is by mapping sectors, just like GRUB4DOS does. GRUB4DOS does tell us how large the virtual disk is, so we know nice places like the beginning and end of the disk image (remember that GRUB4DOS requires a contiguous image file for non-RAM disk mapping).

When we wish to validate that some backing disk is the right one, we can try to read some magic sector (which could be at the beginning or end of the G4D disk) and check it. Before filesystems are available, mapping sector read/write I/O is just about the best we can accomplish.

#217 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7771 posts

Posted 01 June 2010 - 05:01 PM

Ok, now i'm completely. :(

GRUB4DOS does tell us how large the virtual disk is, so we know nice places like the beginning and end of the disk image

What good is it to know the beginning of the image, if you still don't know on which device it is? Wasn't to identify the device holding the image, your problem?

Also if you know the beginning of the virtual disk and it's type, you can just read the sector(s) holding the (root)directory, at least for CD and FATx, to check for a tag file. Requiring no special invented magic. :)
But what for would one need to identify an identified image?

But as said, i'm at a complete loss here. I thought i knew what your goal is. Now i doubt it.
Maybe Wonko is right and we should get way more specific then device, disk, and image.


:(

#218 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13750 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 01 June 2010 - 05:38 PM

Maybe Wonko is right ....


Maybe? :(

:)
Wonko

#219 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1682 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 01 June 2010 - 06:10 PM

...What good is it to know the beginning of the image,

You get the following information from GRUB4DOS: The number of the first sector of the disk image on the backing disk and number of sectors in the disk image. You don't get what the backing disk is in Windows.

if you still don't know on which device it is? Wasn't to identify the device holding the image, your problem?

We can read raw sectors from each possible backing disk. For each possible backing disk, we can look at the data where the disk image would be, if this were the right backing disk. We can then choose if we like what we see, "does this look like the disk image?"

Also if you know the beginning of the virtual disk and it's type, you can just read the sector(s) holding the (root)directory, at least for CD and FATx, to check for a tag file. Requiring no special invented magic. :)

Other than a filesystem driver! We can read sectors, not files. Parsing even FAT and ISO9660 files means filesystem logic "invented" within WinVBlock, since the other, full filesystem drivers have not yet attached to their partitions, volumes, whatever.

But what for would one need to identify an identified image?

Your booted file is not a RAM disk, so it's not "floating." It's not magically available. The file is a contiguous range of sectors on another disk. You need to identify which backing disk has that contiguous range of sectors.

But as said, i'm at a complete loss here. I thought i knew what your goal is. Now i doubt it.
Maybe Wonko is right and we should get way more specific then device, disk, and image.

By backing disk I mean the disk that has your booted disk image file on it. The booted disk image file could be called:
  • A sector-mapped disk (a mapping to sectors on another disk)
  • A file-backed disk (it's a contiguous disk image file)
  • A GRUB4DOS non-RAM disk (as opposed to map --mem)


#220 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7771 posts

Posted 01 June 2010 - 09:45 PM

By backing disk I mean the disk that has your booted disk image file on it. The booted disk image file could be called:

  • A sector-mapped disk (a mapping to sectors on another disk)
  • A file-backed disk (it's a contiguous disk image file)
  • A GRUB4DOS non-RAM disk (as opposed to map --mem)

Nice to hear, that i did understand your intentions right.

The point you seem to not get, is that no file-system-driver is needed, to know, if a read raw sector contains a certain string.
For the tag file to work, the tag file itself, does not have to be read, just it's name in the sector containing the root directory!

:)

#221 Icecube

Icecube

    Gold Member

  • Team Reboot
  • 1062 posts
  •  
    Belgium

Posted 01 June 2010 - 10:21 PM

The point you seem to not get, is that no file-system-driver is needed, to know, if a read raw sector contains a certain string.
For the tag file to work, the tag file itself, does not have to be read, just it's name in the sector containing the root directory!

... for which you need to understand the used filesystem (at least partially).

#222 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13750 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 02 June 2010 - 09:59 AM

Ok, now I am losing you all. :(


Talking of a HD or superfloppy kind of backing disk:
  • If the backing disk has a MBR, it has a Disk Signature in first sector.
  • If the backing disk has NOT a MBR, it has (possibly) a volume label AND a volume serial in first sector.
Both the above DATA is available at sector level.
Additionally it has an UUID that grub4dos can "expose". (and that I presume WinvBlock can calculate with the same algorithm)
Additionally, if the filesystem on it is any of the ones supported by grub4dos (FAT12/16/32, NTFS or Ext2/3, - unless I am mistaken), ANY file on it can be found/listed - though cannot say if WinVblock will have this same ability in the initial phases.
ALL the above info is available in Windows.


What is the problem? :)

:(
Wonko

#223 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1682 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 02 June 2010 - 01:19 PM

...Talking of a HD or superfloppy kind of backing disk:

  • If the backing disk has a MBR, it has a Disk Signature in first sector.
  • If the backing disk has NOT a MBR, it has (possibly) a volume label AND a volume serial in first sector.

How do you tell WinVBlock what the backing disk's signature is? How do you tell WinVBlock what the backing disk's volume label/serial is? karyonix already made some suggestions, but it would be nice if we don't have to
  • Put a backing disk's signature in the boot image
  • Put a backing disk's volume label/serial in the boot image
  • Write crazy GRUB4DOS menu.lst logic to chop these bits of info out of the backing disks and put them... Where? An arbitrary location in RAM? karyonix did suggest making a RAM disk just for the sake of passing these parameters, but it is a complex solution in my opinion
Now looking at things the other way around, MBRs are a very simple case for the booted disk image. I currently look for an MBR signature (not disk signature). Since I believe NTLDR passes the booted-from disk signature in RAM, I can read the test sector of each possible backing disk and compare the disk signature. I already have this stronger check planned.

I really brought this up for things like booting an .ISO file which has an actual OD or an HD as the backing disk. There is no MBR involved for the .ISO case (and no backing disk MBR for the OD case) and writing all sorts of ISO9660 filesystem logic to find a tag file or even a UUID would not be very pleasant. I could imagine someone wanting to boot a Windows PE .ISO for repair purposes.

Both the above DATA is available at sector level.

My problem is with writing filesystem logic for a disk driver. Why should disks be dependent at all on what filesystem is on them? Even an MBR check is kind of ugly: Suppose you wish to
map (hd0,0)/scratch_space.hdd (hd1)

map (hd0,0)/os.hdd (hd0)

map --hook

root (hd0,0)

chainloader /ntldr

boot
Where scratch_space.hdd has no MBR (is empty or has an APT or some other partitioning scheme). How do I know which backing disk scratch_space.hdd is on?

Additionally it has an UUID that grub4dos can "expose". (and that I presume WinvBlock can calculate with the same algorithm)

I assume you mean "expose" with the methods karyonix already suggested?

Additionally, if the filesystem on it is any of the ones supported by grub4dos (FAT12/16/32, NTFS or Ext2/3, - unless I am mistaken), ANY file on it can be found/listed - though cannot say if WinVblock will have this same ability in the initial phases.
ALL the above info is available in Windows...

When the Windows kernel starts, there are no disks or anything else. Everything Windows needs to know must be in RAM at that moment. Drivers are in RAM. Then the disk drivers provide disks. I'm enjoying this discussion about what's the best information to pass in RAM and how to pass that information in regards to useful information that can help us to identify the right backing disk for the right sector-mapped disk. Alternatively to passing information in RAM, we could look for well-defined (WinVBlock-specific) information in our test of each possible backing disk, such as a WinVBlock structure at a well-known (beginning or end, since we do know the size of the booted disk image) point.

#224 karyonix

karyonix

    Frequent Member

  • Advanced user
  • 453 posts
  •  
    Thailand

Posted 02 June 2010 - 02:25 PM

We just have to prepare a "boot parameter" file.
Create a 4 - 8 KB file beginning with some "magic" bytes. Zero-fill the remaining bytes.
Write number of sector-mapped drives (1 in simple case) to DWORD at offset 0x40.
Write "drive number" of a sector-mapped drive(s) to DWORD at offset 0x44 (and 0x48, 0x4C if you have 2-3 drives).
Copy sector LBA0-1 of backing disk for 1st sector-mapped drives to offset 2048.
(Copy sector LBA0-1 of backing disk for 2nd sector-mapped drives to offset 4096.)
(Copy sector LBA0-1 of backing disk for 3rd sector-mapped drives to offset 6144.)

Then in menu.lst just creating a small ram drive from "boot parameter" file should be enough.
title Windows XP in aaaa.img

map /aaaa.img (hd0)

map --mem /aaaa.bp (0x55)

map --hook

chainloader (hd0,0)/ntldr



title Windows PE in bbbb.iso

map /bbbb.iso (0xff)

map --mem /aaaa.bp (0x55)

map --hook

chainloader (0xff)
This should provide enough information for sector-mapped disk (or sector-mapped ISO) on backing HDD (or UFD).

If you move image to another backing disk just modify "boot parameter" file.
User can do it manually or use batch file which call dd or special tool created for this purpose.
"boot parameter" file can also be update in GRUB4DOS if you want to do it this way.
title Update boot parameter file for new backing disk

find --set-root /aaaa.img

dd if=()+2 of=/aaaa.bp bs=512 count=2 seek=4

find --set-root /bbbb.iso

dd if=()+2 of=/bbbb.bp bs=512 count=2 seek=4

Sector-mapped ISO on ISO CD-ROM need different mechanism.
You may use 2048 bytes at address 0x8000 (32KB) of backing CD-ROM for identification.

--------

Another method for backing-disk identification by using INT13 drive number (as seen from NTLDR).
  • Save drive number pair in registry
    key = "whatever\BackingDisk", value = drive number of sector-mapped disk, type REG_DWORD, data = drive number of backing disk.
    example. value "80" data 0x90
  • In GRUB4DOS map backing disk as drive number specified in registry
    map (hd0,0)/aaaa.img (0x80)
    map (hd0) (0x90)
  • When driver read drive map slot, it see drive number 0x80.
    Driver read registry value "80". It get data 0x90 which is drive number of backing disk.
    Driver enumerate all disk on system and send IOCTL_DISK_GET_DRIVE_GEOMETRY_EX to each of them.
    If the returned diskdetectioninfo->DetectionType==DetectInt13 and diskdetectioninfo->DriveSelect == drive number of backing disk, we have found the backing disk.


#225 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13750 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 02 June 2010 - 03:17 PM

Well, I would use dd to copy sectors in RAM:
http://www.boot-land...?...c=11558&hl=
(no need to map anything)

(please do understand that I completely fail to understand 1/2 to 2/3 of everything connected with grub4dos use of RAM addressing, so my ideas may be grossly incorrect :()

Cannot we (please read as YOU :)) try talking about the issue with tinybitor Bean? :(

:(
Wonko




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users