Jump to content











Photo
* * * * - 3 votes

WinVBlock


  • Please log in to reply
623 replies to this topic

#251 TheK

TheK

    Frequent Member

  • Advanced user
  • 141 posts
  • Location:Germany (BW)
  •  
    Germany

Posted 08 June 2010 - 03:08 AM

FSCTL_GET_RETRIEVAL_POINTERS can help to make sure that you are using the right image file.

Sorry, I don't have time to explain it in more details at the moment.

#252 Sha0

Sha0

    WinVBlock Dev

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

Posted 08 June 2010 - 03:29 AM

That's ok, an Internet search works just fine. :D Seems useful in conjunction with a filename, volume offset and the image file's offset. If you're going to pass any information beyond what's already built into GRUB4DOS though, mightn't you pass enough to avoid the need for this? Thanks a lot for sharing; definitely a good note to have.

#253 karyonix

karyonix

    Frequent Member

  • Advanced user
  • 474 posts
  •  
    Thailand

Posted 08 June 2010 - 06:43 AM

Thought about that. Parameter block could have multiple MBRs filling additional sectors past the header... But not relevant for non-MBR disks, such as .ISOs/CDs/DVDs, empty disks, APM/GPT/other-partitioned disks (though GPT's legacy MBR is there).

In case of GPT disk, disk GUID is in sector LBA1. We can copy 1024 bytes to RAM drive to cover for it.
For ISO-9660 CD-ROM, its structure begin at 32KB. We can copy 1 sector (2048 bytes) at 32KB to RAM drive for comparison with CD-ROM volume in Windows.
And we need some way to tell the driver how to compare the signature.
How about we use sector number and number of sector instead of byte offset
@2 or @2+1 -- for MBR copied to LBA2 of RAM drive
@4+2 -- for MBR+LBA1 copied to LBA4-LBA5 of RAM drive
@6+4 -- for CD-ROM sector copied to LBA6-LBA9 of RAM drive
How to compare them is up to the driver. It can just compare MBR signature, GPT disk GUID or compare the whole sector.

If you could suggest a character guaranteed illegal in a filename for every filesystem, sure.

We have choice :
  • use null character.
  • use non-null character and tell user not to use it in filename even if filesystem support it.
    ( Now that I think about it, '|' should not be used because "||" has special meaning in GRUB4DOS. )
  • use non-null character and use escape sequence for special characters.

I started that way, but drive 0x00 is not distinguishable from ASCII NUL. What does one search for to determine end-of-record?

Write ASCII string "0x00","0x80" for drive number and Null-character for end of record.

I might have a disk image "stub" but actually wish to hot-swap to a file on... A network filesystem. UUID or partition offset seems appropriate, otherwise, but not sure that it helps any more than "try each FS until found."

It is useful when you have 2 volumes that contain disk images with same name in them and you want to format one of them.

When would a relative filepath ever be meaningful? I think the initial '/' could be implicit.

'/' indicate that the following string is filepath not other optional field.

#254 TheK

TheK

    Frequent Member

  • Advanced user
  • 141 posts
  • Location:Germany (BW)
  •  
    Germany

Posted 09 June 2010 - 03:09 AM

If you're going to pass any information beyond what's already built into GRUB4DOS though, mightn't you pass enough to avoid the need for this?


If you pass any information then there's no need for it. But I would try to keep it as simple and easy as possible for the user.
If the filename is enough, why making it more complicated?

#255 Sha0

Sha0

    WinVBlock Dev

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

Posted 11 June 2010 - 03:03 PM

Another fun idea would be two simple contraints:
  • menu.lst must begin with #!GRUB4DOS
  • For each choice that boots Windows, use a different drive number to memory-map the menu.lst file
Example:
#!GRUB4DOS

title foo

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

  map --mem /menu.lst (0x55)

  map --hook

  root (hd0,0)

  chainloader /ntldr

title bar

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

  map --mem /menu.lst (0x56)

  map --hook

  root (hd0,0)

  chainloader /ntldr
Then a driver could theoretically recognize menu.lst and know which choice was made, based on the very drive number being processed. Heheh.

#256 karyonix

karyonix

    Frequent Member

  • Advanced user
  • 474 posts
  •  
    Thailand

Posted 11 June 2010 - 03:23 PM

I think "write" command is more flexible.
But it would be better if grub4dos save filename in its int13 routine.

#257 tinybit

tinybit

    Gold Member

  • Developer
  • 1175 posts
  •  
    China

Posted 13 June 2010 - 10:44 AM

In reply to Icecube' PM,

Sorry I have no time to join in the discussion.

I will come here later once possible.

#258 tinybit

tinybit

    Gold Member

  • Developer
  • 1175 posts
  •  
    China

Posted 13 June 2010 - 12:30 PM

erh... how about nested images?

map /image1 (hd13)
map --hook
map (hd13,6)/image2 (hd14)
map --hook
.............

and this?

map (hd0)12345+6789 (fd0)
map (hd0,0)1234+567 (fd1)
map (fd0)12+34567 (hd0)
........

Can Windows lock a series of sectors? If yes, then the protected mode drivers can do a lock on the sectors used by grub4dos mappings. Only the driver is allowed to access the locked sectors. And then, the only thing left, is to determine which BIOS drive number correspond to which Windows drive. And thus, the filenames are not needed any more.

#259 Sha0

Sha0

    WinVBlock Dev

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

Posted 13 June 2010 - 05:27 PM

erh... how about nested images?

map /image1 (hd13)
map --hook
map (hd13,6)/image2 (hd14)
map --hook

I'd like to support nested images. Does GRUB4DOS point (hd14) at the same backing disk as (hd13), but different sector range? If so, that would be a problem for me.

...and this?

map (hd0)12345+6789 (fd0)
map (hd0,0)1234+567 (fd1)
map (fd0)12+34567 (hd0)

If the user doesn't specify a filename, they take their chances using just the sector-mapping.

...Can Windows lock a series of sectors?

I don't know about returning a locked status, but one could certainly return read-only or bad sectors. I'll look into this. The consumer trying to access those sectors might not be happy about it, though.

If yes, then the protected mode drivers can do a lock on the sectors used by grub4dos mappings. Only the driver is allowed to access the locked sectors.

The only problem with a sector-inaccessible approach is for the surrounding filesystem. Whenever the filesystem tries to access those sectors, there will be some kind of problem. The filesystem itself or some integrity-maintenance process might attempt some kind of repair action (uselessly). If there's no "locked" status and we have to return "bad", then I would expect delays for retries on I/O to those sectors (other than our driver).

And then, the only thing left, is to determine which BIOS drive number correspond to which Windows drive. And thus, the filenames are not needed any more.

Particularly difficult when you have no guarantees about the contents (could be empty). However, the .VHD fixed-disk footer will certainly help, since you can match the length, at the very least.

Thanks, tinybit. Here's the relevant commit to WinVBlock[1] (not yet in the current release here at Boot-Land).

[1] [filedisk] Support hot-swapping to another file

#260 tinybit

tinybit

    Gold Member

  • Developer
  • 1175 posts
  •  
    China

Posted 14 June 2010 - 01:44 AM

Yes, your 0x55 approach is quite good. I think you can add similar info for BIOS DRIVEs. If you would think that it should be implemented by grub4dos internally, you may give a patch. The patch may provide an option for the user to create drive (0x55) and info needed in it for a mapping.

e.g., for drive 0x80, you may add a field to hold the MBR signature(dword at offset 0x1B8) of drive 0x80. other info can also be provided, such as the starting sector number of the partition and the length of the partition. See part_start and part_length in asm.S:

. = EXT_C(main) + 0xA0



VARIABLE(saved_drive)

		.long   0

VARIABLE(no_decompression)

		.long   0

VARIABLE(part_start)

		.long   0, 0



		. = EXT_C(main) + 0xB0



VARIABLE(part_length)

		.long   0, 0



VARIABLE(fb_status)

		.long   0



VARIABLE(is64bit)

		.long   0

Also from README_GRUB4DOS.txt:
******************************************************************************

***			access some internel variables at a fixed location		  ***

******************************************************************************



Address		 Length		  Description

=========	   ========		==============================================

0000:82A8	   8 (QWORD)	   part_start (start sector of last accessed partition)

0000:82B0	   8 (QWORD)	   part_length (total sectors of last accessed partition)





I'd like to support nested images. Does GRUB4DOS point (hd14) at the same backing disk as (hd13), but different sector range? If so, that would be a problem for me.


Unluckily, it is yes.

#261 sebus

sebus

    Frequent Member

  • Advanced user
  • 360 posts

Posted 16 June 2010 - 07:25 PM

Thanks guys for all the work put into this project!

It would be just great to be able to boot XP/2003 from .vhd

sebus

#262 Sha0

Sha0

    WinVBlock Dev

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

Posted 16 June 2010 - 07:38 PM

Thanks guys for all the work put into this project!

It would be just great to be able to boot XP/2003 from .vhd

sebus

Well the version currently available in the development tree is capable of booting a fixed-disk .VHD. (You'd have to build it, though.) I'm trying to group a couple more features in for a new release. Booting from any other type of .VHD would require:
  • Hard work to implement the logic for delta-style images, who have ancestor images.
  • A boot-loader capable of booting a .VHD. That is, you're still limited by the boot-loader even if WinVBlock has full .VHD support. That's what member supaJ is strongly interested in[1]

[1] Boot-loader for INT 0x13 mapping non-contiguous files

#263 sebus

sebus

    Frequent Member

  • Advanced user
  • 360 posts

Posted 16 June 2010 - 08:12 PM

Thanks, will wait for the new release

sebus

#264 maanu

maanu

    Gold Member

  • Advanced user
  • 1134 posts
  •  
    Pakistan

Posted 19 July 2010 - 02:18 PM

possible Bug :


booting the install ISO of server 2003 32bit, along with the winvblock floppy image ,gives BSOD with 0x7B code . appears just before the hard disk partitions are shown (setup is starting windows) .



following winvblock versions was tested


0.0.1.18

same results . and i made sure at every test with and without pressing F6 just to make sure that the winvblock driver is being loaded or not.

it was tested successfully XP 32bit based ISO images.

map --mem /WINV.IMA (fd0)
map --hook
map --mem /2K3.ISO (0xff)
map --rehook
chainloader (0xff)

(is the above method is correct?)

anyone who can cross check it ?

(cross posted in firadisk's thread with same error)

#265 zhaohj

zhaohj

    Newbie

  • Members
  • 10 posts
  •  
    China

Posted 03 August 2010 - 12:54 AM

I the wibvblock drivers simulation am the A plate, the SRS drivers simulation am the B plate, after entered PE the AB plate to exchange.
Tests the FIRADISK drivers, then cannot have the AB plate exchange.

The exchange situation only occurs in non-standard floppy disk form time
If the A plate contains the WINVBLOCK drivers, A plate capacity 10M, B plate 1.44M, after entered PE then can have the exchange.

winvblock versions 0.0.1.18

#266 zhhsh

zhhsh
  • Members
  • 4 posts

Posted 01 October 2010 - 11:23 AM

excuse me,i have something to ask you.
could winvblock.exe support mount non-fixed vhd?
could winvblock support grub4dos's map(non --mem) function?

thanks.

excuse me,my poor english

#267 dog

dog

    Frequent Member

  • Expert
  • 236 posts

Posted 01 October 2010 - 11:37 AM

could winvblock support grub4dos's map(non --mem) function?

The current version can do this, but it doesn't lock the mapped file, so you have to be careful not to move it or alter it.

#268 zhhsh

zhhsh
  • Members
  • 4 posts

Posted 01 October 2010 - 12:06 PM

The current version can do this, but it doesn't lock the mapped file, so you have to be careful not to move it or alter it.


Could WinVblock support boot from a Dynamic vhd or mount a Dynamic vhd?

Thanks.

#269 lemarec

lemarec

    Newbie

  • Members
  • 13 posts
  •  
    France

Posted 23 October 2010 - 09:46 AM

Hello

I'm a little bit novice

I use GRUB4DOS : (UBCD CD on an USB HD)

title Winteranals ERD Commander\n Winteranals ERD Commander.
map --mem (pd)/ubcd/custom/WinVBlock.IMA (fd0)
map --mem (pd)/ubcd/custom/WintERD2007.iso (0xff)
map --hook
root (hd32)
chainloader (0xff)
boot

When I boot, i had an error message

ERROR 23: Error while parsing number

I create WinVBlock.IMA with winimage (Good method ?)

Thanks for any help

Edited by lemarec, 23 October 2010 - 09:47 AM.


#270 Icecube

Icecube

    Gold Member

  • Team Reboot
  • 1063 posts
  •  
    Belgium

Posted 23 October 2010 - 07:29 PM

@ lemarec
root (hd32)

chainloader (0xff)
Use the same drive number for the mapping, setting root drive and chainloading command.
So use (hd32) in all cases or (0xff), but don't mix them.

#271 lemarec

lemarec

    Newbie

  • Members
  • 13 posts
  •  
    France

Posted 24 October 2010 - 08:38 AM

thanks

Now :

title Winteranals ERD Commander\n Winteranals ERD Commander.
map --mem (pd)/ubcd/custom/WinVBlock.IMA (fd0)
map --mem (pd)/ubcd/custom/WintERD2007.iso (hd32)
map --hook
root (hd32)
chainloader (hd32)
boot

but the same error, I think the error come from WinVBlock.IMA

#272 lemarec

lemarec

    Newbie

  • Members
  • 13 posts
  •  
    France

Posted 24 October 2010 - 09:47 AM

Hello can anyone tell me exactly how
to made WinVBlock.ima ?

#273 Sha0

Sha0

    WinVBlock Dev

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

Posted 29 October 2010 - 02:28 AM

possible Bug...

Thanks, maanu. I hope to get back into WinVBlock soon; I have lost a few months and have little to show for it. I'll have to make sure to test the Windows Server 2003 installation .ISO. I appreciate the report and the test details. Perhaps it's a bug that's already been fixed in the development tree, but perhaps not.

#274 Sha0

Sha0

    WinVBlock Dev

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

Posted 29 October 2010 - 02:31 AM

Could WinVblock support boot from a Dynamic vhd or mount a Dynamic vhd?

Thanks.

The logic for dynamic .VHDs is more complex than the simpler, flatter .VHD support that WinVBlock currently has. I wish there was more time for development. Right now, the answer is "yes, it could" but also "no, it currently doesn't".

#275 Sha0

Sha0

    WinVBlock Dev

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

Posted 29 October 2010 - 03:03 AM

Hello can anyone tell me exactly how
to made WinVBlock.ima ?

Try typing each of those commands from the GRUB4DOS CLI. Then you will know which line has the error. Since you're not booting the floppy disk image (WinVBlock.ima), the error message should be from GRUB4DOS (I recognize it anyway).




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users