Jump to content











Photo
* * * * - 3 votes

WinVBlock


  • Please log in to reply
623 replies to this topic

#301 Sha0

Sha0

    WinVBlock Dev

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

Posted 21 January 2011 - 01:59 PM

...Many thanks for your nice work WinVBlock.

You're welcome, I'm sure.

Kindly, could you have a look at the Server 2003 installation issue?

Installing Server 2003 into an .img file with Firadisk or Winvblock :

http://reboot.pro/13546

I tried the latest version of WinVBlock, V0.0.1.8 but I could not install Server 2003 on the .img file.

Yes. While I read that thread, perhaps you could be interested in trying the latest development version? I'm trying to release development binaries with each development cycle, as mentioned a few posts ago. There has been a ton of work since 0.0.1.8, but I'm not yet satisfied for a 0.0.1.9 release (soon, though).

#302 Vortex

Vortex

    Frequent Member

  • Advanced user
  • 239 posts

Posted 21 January 2011 - 02:00 PM

Hi Wonko,

Yes, I noticed it. Thanks. I corrected the link.

#303 Vortex

Vortex

    Frequent Member

  • Advanced user
  • 239 posts

Posted 21 January 2011 - 02:13 PM

Hi Sha0,

Thanks for the latest development version. I will try it and report the result.

#304 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1568 posts
  •  
    American Samoa

Posted 21 January 2011 - 03:14 PM

WinVBlock doesn't support giant RAM disk images so your 6 GB image won't work as a RAM disk. I don't even know if GRUB4DOS could load such an image to RAM, though karyonix has done some PAE work for it, if I recall correctly.

Vboot seems to promise supporting parsing to RAM & caching to a local hard drive method to allow booting from RAM as I understand large system images thus avoiding the missing drivers issues. It seems to imply NTFS write support as well. Would you improve WinVBlock to work on pair with Vboot in this app?

#305 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 21 January 2011 - 03:33 PM

Beecause she is a Lady, and it is such a rare thing among us geeks to have a female member that at the time it was chosen as a distinctive sign, and a special "Group" was created for them.

See me confused :cheers:
Attached File  sara.gif   11.06KB   32 downloads
:cheers: ?

Maybe we create a group incognitolady

Peter

#306 Sha0

Sha0

    WinVBlock Dev

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

Posted 21 January 2011 - 04:09 PM

Vboot seems to promise supporting parsing to RAM & caching to disk method to allow booting from RAM as I understand large system images thus avoiding the missing drivers issues. It seems to imply NTFS write support as well. Would you improve WinVBlock to work on pair with Vboot in this app?

I thought that I'd written somewhat of a general road-map for WinVBlock in this thread... Maybe not. Here're some plans:
  • Implement counterpart functionality to Linux' device-mapper. That includes RAID and Copy-on-Write. For example: You could have a master HDD image attached via WinVBlock's recent HTTPDisk incorporation as a read-only backing, then use the internal HDD as the COW overlay. That would essentially mean no more re-imaging for those computers with a permanent network connection. All such systems would begin in a fresh "master" state, then run through Mini-Setup and begin to establish themselves as unique while storing their deltas on their local HDDs.
  • Support Olof Lagerkvist's fine devio protocol for disks, so one can cheaply serve disks and attach to them (and boot from them). The fine sockets work by Bo Brantén is already in the code-base due to my incorporation of his fine HTTPDisk driver.
  • Allow for a user to establish paged and non-paged RAM disks on an already running system.
  • Add a feature to "cover up" other disks and make them available as resources for the device-mapper functionality mentioned above. For example: You could take the local HDD and a RAM disk and an iSCSI disk and mash them together.
  • Add a "Registry disk" feature for storing disk images in the Registry. Might be handy for the Recovery Console, right Wonko the Sane? :cheers:
  • Implement a better means of obtaining parameters from GRUB4DOS.
  • Add support for burning virtual CDs/DVDs (RAM or file-backed).
  • Maybe I'm forgetting some. Oh well. EDIT: Yes I forgot to include: Incorporating VDK's fine .VMDK disk image format support.
I didn't read anything that implied NTFS write support in the thread you linked to, but will admit that I didn't read the entire thread.

WinVBlock is a Windows driver. It is my understanding that the product you are comparing it with includes a pre-OS component. WinVBlock will not include a pre-OS component; that's what Syslinux and GRUB4DOS are for. Having said that, I did write the MEMDISK code specifically responsible for WinVBlock and Firadisk to find MEMDISK RAM disks, so it's not impossible that some nice Syslinux COM32 modules for Windows boot-related things will be developed.

What do you mean about the "missing drivers issues"? If the drivers required for the backing disk are not available at boot time, that's that. Their driver cannot magically find the backing disk unless they implement all of those storage drivers' functions in their driver OR they would have to know in advance and pre-cache enough of the HDD image to allow it to boot and establish the backing disk. That would seem to be a complex undertaking. Could you please clarify what your take on the matter is?

#307 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1568 posts
  •  
    American Samoa

Posted 21 January 2011 - 05:19 PM

You referred to RAM booting as an advantage since RAM Disk driver is included by default, while other HW drivers may be missing at boot. Yet the size of disk image is a restrictive factor. Vboot seems to promise to "pre-cache enough of the HDD image to allow it to boot from RAM and establish the backing disk" on the hard drive or simply write unused at the moment pre-cached data back to the hard drive, thus allowing for larger images to parse and boot on PCs with limited RAM. I assume NTFS write support is required for that?

You said WinVBlock doesn't support large image booting. Since Vboot Bootloader seems to go in that direction, may be WinVBlock can co-operate with it similar to co-operating with Grub4DOS to support large image booting that G4D doesn't. Did I get it right? :cheers:

#308 Sha0

Sha0

    WinVBlock Dev

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

Posted 21 January 2011 - 07:18 PM

You referred to RAM booting as an advantage since RAM Disk driver is included by default, while other HW drivers may be missing at boot. Yet the size of disk image is a restrictive factor.

I don't recommend using a RAM disk OS image for anything other than utilitarian purposes. For example, I use a 220 MiB image and boot it on every new kind of hardware I come across, then install any interesting hardware using Device Manager. I can then apply this image to any of those computers' HDDs and expect it to boot, also. But such a small image only has so many features... I wouldn't be offering such an image to an end-user, but to technical folks desiring diagnostic abilities or emergency recovery, etc.

Of course, one can use such an image as a sort of "inventory" for all models' devices, too, and the drivers that are required for them. You can also use the image and perform an upgrade install to wind up with a much fuller image, but still having all of the devices and drivers intact.

Vboot seems to promise to "pre-cache enough of the HDD image to allow it to boot from RAM and establish the backing disk" on the hard drive or simply write unused at the moment pre-cached data back to the hard drive, thus allowing for larger images to parse and boot on PCs with limited RAM. I assume NTFS write support is required for that?

Why would you be writing to the disk at pre-OS time at all? Booting is pretty well going to be a read-only operation right up to the point where the system is capable and stable enough to undergo normal operation. What are you thinking about, exactly? Their boot-loader component having NTFS write support or their driver having NTFS write support? Their boot-loader component wouldn't need to write anything because booting should be read-only. Their driver component wouldn't need to write anything, because Windows has an NTFS driver for writing! So this NTFS write business you've mentioned is confusing.

When I typed "pre-cache," I meant to RAM, not to disk. Sorry about that. What I was trying to say was that they would need to know, while their boot-loader component is loading stuff, what sectors from the disk to cache to RAM, if they want to provide that cache later on after the OS is running. If your storage controller is driven by iaStor.sys and that file is not available to the OS to drive that storage controller, what magic would allow you to find iaStor and access the internal HDD? In other words, how would any product know which disk sectors to cache to RAM so that those sectors are available to the OS? What would distinguish iaStor.sys from any other file?

So I really think that huisinro is talking about a simple performance feature, not anything to do with "missing drivers issues." The solution to missing drivers is to inject drivers.

You said WinVBlock doesn't support large image booting.

Not quite. WinVBlock doesn't support large, non-paged RAM disks. That has nothing to do with sector-mapped or file-backed disks. RAM limitations do not apply when physical disks are involved as the backing store. Disk sectors != RAM. You can boot from any size of sector-mapped or file-backed disk you like; the limitation would not be with WinVBlock.

Since Vboot Bootloader seems to go in that direction, may be WinVBlock can co-operate with it similar to co-operating with Grub4DOS to support large image booting that G4D doesn't. Did I get it right? :)

"Large image booting" is unqualified in this context. Are you talking about a RAM disk or something else?

#309 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1568 posts
  •  
    American Samoa

Posted 21 January 2011 - 09:31 PM

Sha0

Thanks for your detail explanation. You're obviously way ahead of some guys who are used to say: "OK, this is my program or batch ABC. Try it and post how do you like it". At this point you're left wondering what was it all about??? :)

I take back NTFS write support - wrong assumption, still need drivers. Clear now as well, WinVBlock seems to support large sector-mapped or file-backed image booting from disk. So, apparently, you already done most of these wonders, except VMDK booting. :)

Regarding Vboot promise, it looks like this, so you buy it for what its being sold by the developer:

"Basically a cache, offset->buffer, if there is no memory left, some portions will be discarded and commit to file.

current ram booting only handles small file size, we are trying to see if this can extend to real hard disk image, like the one I have is 250G vhd file from my laptop cloning. Our boot loader can handle reading/parsing a huge file.

... To the best of my knowledge, no other boot loaders can read a large (e.g. 250G) file stored randomly on real hard disk, and treat it as virtual disk
."

May be he just tries to speedup reading & booting large files from RAM and/or disk, so its similar in part to what WinVBlock can do.

#310 sara - pmedia

sara - pmedia

    Frequent Member

  • Lady
  • 180 posts
  • Location:tel aviv
  •  
    Israel

Posted 22 January 2011 - 04:36 PM

Maybe we create a group incognitolady

Peter


Very funny! :unsure:
in most forums I always prefer to register as a male to have a normal and appropriate response, Here, too, I started a few years ago as male and only a few months ago I uploaded the picture and added the first name Sarah.
But apparently I was wrong
I do not like to stand out especially in such a forum that intended for men and appears here as a computer freak from outer space

#311 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 22 January 2011 - 05:09 PM

Very funny! :(
in most forums I always prefer to register as a male to have a normal and appropriate response, Here, too, I started a few years ago as male and only a few months ago I uploaded the picture and added the first name Sarah.
But apparently I was wrong
I do not like to stand out especially in such a forum that intended for men and appears here as a computer freak from outer space


Wait a minute, are you implying that in this Forum you ever had - since you uploaded the image and "changed gender" ;) not a "normal and appropriate" response? :)

The idea of disguising as a male (in order to do things that a female is not supposed to do) is as I see it, a bit old-fashioned :unsure:, expecially if coming from a country where AFAIK no distinction is made based on gender even in the military.

You are appreciated in the same way, no matter if male or female. :cheers:
Mind you, you will also be bashed in the same way. ;)

:cheers:
Wonko

#312 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1568 posts
  •  
    American Samoa

Posted 22 January 2011 - 05:12 PM

Sara

Actually its not that bad to stand out from the crowd, if you can offer fresh views, feedback and new ideas moving the community, company or society forward. :)

Having such a beautiful photo and a special Lady status, you actually standout in the most favorable way (not an alien ;) ), and on top a way ahead of many guys in experimenting with hot staff. In fact software development is quite popular profession for women in some countries (not Samoa ;) ). And system administration represents extra challenge, especially in smaller companies or organizations still having elaborate server infrastructure used for various challenging tasks.

Keep going pls, you're most welcome! :unsure: And demand order too when you think its broken! :cheers:

#313 i

i

    Silver Member

  • Advanced user
  • 539 posts
  •  
    United Nations

Posted 22 January 2011 - 05:52 PM

I first tested winvblock and then firadisk. With NTFS compression ON i found winvblock slow on ramdisk (at that time):unsure: Then again, things may have been changed... or not?




what is this httpdisk? you're working on Sha0? :cheers:

#314 Sha0

Sha0

    WinVBlock Dev

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

Posted 22 January 2011 - 06:09 PM

I first tested winvblock and then firadisk. With NTFS compression ON i found winvblock slow on ramdisk (at that time):unsure: Then again, things may have been changed... or not?

Which version of WinVBlock did you experience this with?

NTFS compression in an HDD image, I assume you mean. Did you mean as a RAM disk or as a file-backed disk or as a GRUB4DOS sector-mapped disk?

what is this httpdisk? you're working on Sha0? :cheers:

The current development binaries for WinVBlock include Bo Brantén's HTTPDisk (with changes for WinVBlock). You can now mount HDD and .ISO images via HTTP and have them show up in Device Manager and Disk Management. They are read-only.

Technically, at this point, if you could get your NIC driver and TCP/IP to start at boot time, you could boot a Windows PE .ISO entirely over HTTP. ;) Of course, getting those drivers to start at boot time isn't documented anywhere (yet).

#315 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 22 January 2011 - 06:49 PM

Very funny! :unsure:
in most forums I always prefer to register as a male to have a normal and appropriate response, Here, too, I started a few years ago as male and only a few months ago I uploaded the picture and added the first name Sarah.
But apparently I was wrong
I do not like to stand out especially in such a forum that intended for men and appears here as a computer freak from outer space

Sorry, Sara - PMedia!
I did not want to critisize your account declarations.

I wanted to critisize the forum's admin procedere:
When a member declares something (in this case gender=male) there is NEVER a reason to "correct" this "automatically" due to some assumed facts.
I assume that you did not get a PM / e-mail by forum administration asking you for male / female. The admins just decided spontaneously after "situation".

Peter

#316 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1568 posts
  •  
    American Samoa

Posted 22 January 2011 - 06:54 PM

Sha0

Can you list some popular & possible scenarios when your driver can or should be used for a particular reason with Vboot or Grub4DOS outside of PE environment, and illustrate them with ready-to-go menu examples or links? So to speak, a developer's view on product applicability? Others are welcome to add their working examples too.

#317 Sha0

Sha0

    WinVBlock Dev

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

Posted 22 January 2011 - 07:03 PM

Sorry, Sara - PMedia!...

Every male-dominant, computer-themed forum I've been in that observes a female tends to exhibit the same "roles" sooner or later:
  • The "it's ok to be a woman, here" role.
  • The "to-the-rescue" role. ("Let's just leave her alone about her gender, everyone," they say.)
  • The "points-out-the-roles" role.
Unfortunately, I can't break out of fulfilling one of these roles any more than anyone else, as much as I would like to.

Yay, WinVBlock? Heheh. :unsure:

#318 Sha0

Sha0

    WinVBlock Dev

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

Posted 22 January 2011 - 07:39 PM

...Can you list some popular & possible scenarios when your driver can or should be used for a particular reason

Sure. A digest of the driver is available on the first post of this thread. If you need to attach floppy, HDD, or .ISO image files as virtual floppies, hard disks, or optical discs, respectively, then WinVBlock can help.

You can even boot from such image files, assuming you use one of: MEMDISK or GRUB4DOS.

If you need to boot or establish AoE disks over the Ethernet, WinVBlock can help.

If you need to mount a disk image over HTTP, WinVBlock can help.

Image files are nice in that you can store more than one image file on a single filesystem. So you might have a library of 1,000 floppy images, or a library of HDD images for different hardware models, or a library of software .ISOs that you can attach and install software from without needing the physical media at-hand.

with Vboot

WinVBlock wasn't designed with "Vboot" in mind whatsoever. You can certainly experiment, but I believe that Vboot is an alternative to WinVBlock, not co-operative.

or Grub4DOS outside of PE environment,

When I think "PE," I think "read-only .ISO." When I think "non-PE," I think of a traditional Windows installation. WinVBlock should work with both.

and illustrate them with ready-to-go menu examples or links? So to speak, a developer's view on product applicability?

I'm not really in the mood for that; sorry. I'm trying to make time to develop this product which is completely free and open source, but with a paid job and social life, there's not much time to spare for this sort of write-up request. Most fortuntely...

Others are welcome to add their working examples too.

...the excellent community of this forum has a lot of interesting scenarios and examples.

Why are you asking? Does WinVBlock's applicability seem esoteric? Do you yourself have administration work to do and you are trying to understand how WinVBlock could potentially fit in? Perhaps you have something in particular you're trying to accomplish? Would you like to understand it better so you can type a big write-up about it?

I have to admit that a project like this one is not going to be very shiny; there's no money for polish. It also doesn't require any marketing; nobody should be pressured to use WinVBlock. If someone has a goal and this driver could help to accomplish it, sure it'd be a fair idea to suggest it.

Thanks for your inquiry.

#319 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1568 posts
  •  
    American Samoa

Posted 22 January 2011 - 08:51 PM

Thanks! Essentially, just trying to figure out where I can use it given tasks at hand. For example, your Readme seems to imply, it should be installed in Windows just like any device driver (SCSI MiniPort) via its .inf file. If Grub4DOS is installed in a drive's MBR, and there is no OS installed on that drive, only images are copied to it, can WinVBlock be used? By installing it into each image OS install? Or a BIOS ROM can be used instead?

#320 Sha0

Sha0

    WinVBlock Dev

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

Posted 22 January 2011 - 09:19 PM

Thanks! Essentially, just trying to figure out where I can use it given tasks at hand. For example, your Readme seems to imply, it should be installed in Windows just like any device driver (SCSI MiniPort) via its .inf file.

Sure. Or, more recently in 0.0.1.8 and newer, the ReadMe.txt explains how to install it with sc. Once in Device Manager, it's also possible to Update driver... it and choose the .INF file. Both ways are ok.

If Grub4DOS is installed in a drive's MBR, and there is no OS installed on that drive, only images are copied to it, can WinVBlock be used?

Yes.

If you use GRUB4DOS to map --mem that image as a RAM disk, WinVBlock will drive that RAM disk.

If you use GRUB4DOS to map that image as a sector-mapped disk, WinVBlock will look on every disk for that range of sectors. Additional requirements are:
  • The image file must have the MBR magic number 0xAA55 (which is 55 AA in a hex-editor) at the expected slot. If the image already has an MBR, that takes care of that. If you had a completely blank, unpartitioned, unformatted image file, you'd have to add in the magic with a hex-editor or some equivalent means.
  • Any drivers required to produce the backing (physical) disk must already be installed in the image file's OS. There must also be associations between those drivers and the devices on the target system; either through CriticalDeviceDatabase Registry values, or by pre-installing the target system's devices into the image file's OS before copying the image file to the target system.
  • The most recent, 32-bit development binary (WVBlk32.sys).

By installing it into each image OS install?

Installing what? WinVBlock? WinVBlock should already be installed into the image file's OS before copying it to a new target system, yes.

Or a BIOS ROM can be used instead?

Use a BIOS ROM used for what? WinVBlock must be installed either:
  • While running the very OS that it should be installed to, OR
  • Injected into an OS installation by "the usual" offline means: Copying the driver file(s) and manually creating a service entry with RegEdit -> File -> Load hive...
  • Both of these [generally] require some Windows to be running. You could potentially use Linux or any other OS but the proprietary NTFS filesystem format (if you use NTFS) and the proprietary Registry hive format would be challenges to overcome.
WinVBlock in its simplest form is a .SYS file to be copied and a Registry key (with some values) to create.

I'm not sure that I understand what you wish to do with a BIOS ROM.

I hope this helps a little bit. :bounce8:

#321 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1568 posts
  •  
    American Samoa

Posted 22 January 2011 - 09:48 PM

Thanks again! Can you clarify a particular situation? For example, I formatted a USB thumb, added Grub4DOS to its MBR, and dropped several disk ISO and IMA images to the thumb without any OS installed to it. I can still boot any of these images right now via Grub4DOS without adding WinVBlock to any of them. How Grub4DOS manages to do just that? :bounce8:

If I add your driver to each or some of these image OSs, how Grub4DOS would know which driver to use: WinVBlock or the driver it always uses (which one)? I don't see in the 1-st post this aspect clarified...

#322 Mikorist

Mikorist

    ▂ ▃ █ ▅ ▆

  • Advanced user
  • 771 posts
  •  
    United Nations

Posted 22 January 2011 - 10:40 PM

I always prefer to register as a male to have a normal and appropriate response


interesting - I'm on a couple of forums registered as a female purposely because that....
Men always wonder how I hardily get into a discussion over there .... hahahah ....

I think these ones here must to calm their passions. :bounce8:

#323 Sha0

Sha0

    WinVBlock Dev

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

Posted 22 January 2011 - 11:42 PM

Thanks again! Can you clarify a particular situation? For example, I formatted a USB thumb, added Grub4DOS to its MBR, and dropped several disk ISO and IMA images to the thumb without any OS installed to it. I can still boot any of these images right now via Grub4DOS without adding WinVBlock to any of them. How Grub4DOS manages to do just that? :bounce8:

Are you typing about DOS .ISOs and .IMAs, Windows .ISOs and .IMAs, or other OS? GRUB4DOS has an INT 0x13 hook, which is a driver for INT 0x13 users. Windows' boot-loader is an INT 0x13 user. Windows is not an INT 0x13 user, so it needs a Windows driver. WinVBlock is a Windows driver that finds the GRUB4DOS INT 0x13 "driver" and takes over. Thus GRUB4DOS can drive a virtual disk for NTLDR, but a Windows driver must then take over providing that virtual disk once the Windows kernel is running.

If you are talking about Windows image files specifically, I think what you are confused by is that many of the popular projects in this forum use Windows' own RAM disk driver and RAM disk loading feature. SETUPLDR and NTLDR can both load a RAM disk image themselves, without any GRUB4DOS! Windows' RAMDISK.SYS can drive it once the kernel is running.

Here is a common Windows PE example with {a physical HDD with G4D}, {an .ISO on that disk}, {a Windows PE image inside the .ISO}:
  • GRUB4DOS maps an .ISO image ("outer image") file as a sector-mapped disc.
  • GRUB4DOS boots the Windows boot-loader on that virtual disc.
  • The Windows boot-loader loads another image ("inner image") as a RAM disk/disc.
  • The Windows boot-loader starts the Windows kernel.
  • The Windows RAM disk/disc driver drives the "inner image." The "outer image" is unavailable, because nothing is there to find the G4D sector-mapped disc (the .ISO).
If you had burned the .ISO to a physical CD, you'd simply shave off the first two steps above, plus Windows could likely find the physical CD (instead of a G4D sector-mapped .ISO).

An advantage to WinVBlock and Firadisk is the riddance of "inner" and "outer" image complications. You'd just have {a physical HDD with G4D}, {an .ISO or HDD image with Windows PE inside}.

Asking about multiple images without specifying what is in those images yields this limited answer, I'm afraid. Every case/project will have specific details.

If I add your driver to each or some of these image OSs, how Grub4DOS would know which driver to use: WinVBlock or the driver it always uses (which one)? I don't see in the 1-st post this aspect clarified...

You might consider splitting your understanding of the boot process into pre-kernel and post-kernel. Pre-kernel (and DOS) use INT 0x13. Post-kernel requires an OS driver. If one wishes to use the same virtual disk pre-kernel and post-kernel, there must be a hand-over protocol for the post-kernel driver to find the pre-kernel virtual disk.

GRUB4DOS and MEMDISK provide pre-kernel "drivers" for their virtual disks. They adhere to specific hand-over protocols so that Firadisk and WinVBlock can find their virtual disks.

NTLDR and SETUPLDR also can provide a single pre-kernel RAM disk. They then follow a Windows-specific hand-over protocol so that the post-kernel driver (RAMDISK.SYS) can find the RAM disk.

GRUB4DOS knows nothing about WinVBlock, but it does have a protocol for saving information about its virtual disks. GRUB4DOS always has/uses its own pre-kernel driver only.

You only "need" WinVBlock (or friends like Firadisk) for booting your images if: You are booting a Windows XP/2003 (others untested) and you want that Windows to find the booted virtual disk(s) made by MEMDISK or GRUB4DOS.

Now in regards to using WinVBlock for a G4D sector-mapped image file on USB storage: The OS inside the image file must be ready to drive all devices along the path to the USB storage. If the image has not been booted on that hardware before, most likely this is not the case. That is not USB-storage-specific.

If you have your image file on a SATA HDD inside a computer: The OS inside the image file must be ready to drive all devices along the path to the SATA disk. There are fewer branches on this path (Device Manager -> View -> Devices by connection) so it is easier than the USB storage scenario.

If you have your image file on an IDE HDD inside a computer: Most likely the OS inside the image file is already capable of driving all devices along the path to the IDE disk. Very simple.

For a G4D RAM disk: Storage controller and USB drivers don't matter. WinVBlock will find and drive the RAM disk.

#324 sambul61

sambul61

    Gold Member

  • Advanced user
  • 1568 posts
  •  
    American Samoa

Posted 23 January 2011 - 01:02 AM

Sha0

Thanks for in-depth yet simple explanation. One must know this complicated subject very well to be able to explain it in simple terms. Ppl can learn a lot from this thread, me including.

So, WinVBlock is beneficial in providing simultaneous access to both inner and outer image, where more files may be stored. Yet it also beneficial in driving large non-continuous images without RAM booting? I assume WinVBlock doesn't need to load inner image to RAM again ones it takes over from INT 0x13 hook, thus replacing same inner image already loaded by G4D?

"GRUB4DOS knows nothing about WinVBlock, but it does have a protocol for saving information about its virtual disks...Thus GRUB4DOS can drive a virtual disk for NTLDR, but a Windows driver must then take over providing that virtual disk once the Windows kernel is running."

Windows has many drivers pre-installed. What prompts Windows to offer namely WinVBlock to take over an outer image mounted by G4D driver? Especially since Windows has its own RAMDISK.sys, and can also drive VHD disks (hence has a driver for that too)?

Given this WinVBlock ability, how it can help to install Windows from ISO instead of DVD?

Finally, what does it mean in practice to "drive an image"? Does it limited to recalculating access locations of specific files on a mounted image disk? What does an image driver actually do?

#325 Sha0

Sha0

    WinVBlock Dev

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

Posted 23 January 2011 - 01:39 AM

Sha0

Thanks for in-depth yet simple explanation...

You're welcome, I'm sure.

So, WinVBlock is beneficial in providing simultaneous access to both inner and outer image, where more files may be stored.

Actually, the idea is that you don't need an inner image at all... The inner image complication is simply due to the way in which Windows XP/2003's boot-loaders establish RAM disks.

Yet it also beneficial in driving large non-continuous images without RAM booting?

A sector-mapped disk is a contiguous range of sectors. A file-backed disk might or might not be in 1 fragment. By using terminology like "MEMDISK RAM disk," "GRUB4DOS RAM disk," "GRUB4DOS sector-mapped disk," we can avoid misunderstandings. I think you are asking, "Can I boot a large, non-contiguous image file?" The answer is, "Not with GRUB4DOS." G4D's sector-mapped disk is a single, contiguous range of sectors on a backing disk.

karyonix, developer of Firadisk, has this thread (which I see you've read already just a moment ago) in regards to such a G4D feature.

I assume WinVBlock doesn't need to load inner image to RAM again ones it takes over from INT 0x13 hook, thus replacing same inner image already loaded by G4D?

Well we don't need the term "inner image" because we only need one image.

Windows has many drivers pre-installed. What prompts Windows to offer namely WinVBlock to take over an outer image mounted by G4D driver?

One must install WinVBlock in order for it to run. WinVBlock itself claims the MEMDISK/GRUB4DOS virtual disks. In fact, if Firadisk is also installed, there could be a conflict between the two, as they have the same job! :bounce8:

Especially since Windows has its own RAMDISK.sys,

RAMDISK.SYS only knows the Windows hand-over protocol. MEMDISK and G4D do not use that protocol.

and can also drive VHD disks (hence has a driver for that too)?

As far as I know, the RAMDISK.SYS with XP/2003 pre-dates the .VHD disk image format(s). (I could be mistaken.) So I think you are now talking about Windows > 2003. I do believe that Windows 7 natively supports booting from a .VHD file. I do believe that part of Vboot's features is to boot XP/2003 from a .VHD file.

Given this WinVBlock ability, how it can help to install Windows from ISO instead of DVD?

I have no idea what you are asking about, here. An .ISO can be an image file of a CD or of a DVD. You can use physical or virtual media to install Windows XP/2003. For virtual media, you need a driver like this thread's.

Finally, what does it mean in practice to "drive an image"? Does it limited to recalculating access locations of specific files on a mounted image disk? What does an image driver actually do?

That's probably too general a question. A too-general answer might be: When the OS tries to read/write sectors on a virtual disk, the virtual disk driver is responsible for satisfying those requests. If the "sector data" resides in RAM (a RAM disk), the driver must fetch/store to the right RAM. If the "sector data" resides in a file, the driver is responsible for fetching/storing that data from/to that file. If the "sector data" resides on another computer on the network, etc.

A driver drives a device. An image file might be the so-called "backing store" for a disk device.

I still don't know why you mentioned BIOS ROMs earlier. Can you please clarify? Perhaps you have an interesting idea!




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users