45 replies to this topic

[Lancelot]

Thanks a lot oriensol, (sorry i cant find much time)

1) having batch is a good idea, so any user with/without wb can use
what about having this batch also with optional parameters
ex: oriensol.cmd 167772160 myDSK.img
==>creates ~160MB image
2) I guess there wont be much problem to implement 1 to 2
3) I prefer inside Bootsdi script with a default selected option "Create Disk Image"
A dirty workaround for a start maybe, mounting bootsdi.img , creating & mounting new bootsdi.img with your batch, copying files....

Step 1

[oriensol]

Thanks Lancelot.

For [1], what I am planning is:

hddimage.cmd test.img 16

will create a 16MB hard disk with a single NTFS unformatted partition. This can be mounted using vdk and formatted, as required.

I am rounding the size (which is only in MB) to the higher multiple of 8 MB with a minimum size of 16 MB (for 255/63 geometry).

I thought just asking for the filename and a size in MB would be the simplest.

Edit: Changed the old GB (typo) to MB

[joakim]

Sounds good oriensol.

I believe it could be wise to have FiraDisk in the same as BootSdi, as to minimize confusion of whether both can be used simultanously.

mbrbatch (modified?) and imdisk would make it easily automated.

Did not quite understand what you meant about unformatted. I would say, make them perfect if you're first gonna make one.

Is there any reason why a ramloaded disk image should not be ntfs compressed?

Joakim

[MedEvil]

Wow a minimum RamDisk size of 16GB! My computer is way to small for this.

[joakim]

Maybe also add some kind of size check on output folder and wanted image size, to make sure there is enough room.

Joakim

[Lancelot]

I thought just asking for the filename and a size in MB would be the simplest.

if possible, a byte option maybe nice too
hddimage.cmd mb 160 myDSK.img
hddimage.cmd byte 167772160 myDSK.img byte

and maybe some more, to enable format option (like joakim wrote) an adding to the end
hddimage.cmd mb 160 myDSK.img ntfs
hddimage.cmd mb 160 myDSK.img ntfsc
hddimage.cmd mb 160 myDSK.img fat32
hddimage.cmd mb 160 myDSK.img fat16
hddimage.cmd mb 160 myDSK.img fat

only ideas

I believe it could be wise to have FiraDisk in the same as BootSdi

Reminding cdob's post 16, I like modular concept on this case. (firadisk will be selected default which will be available for both create iso and bootsdi, and there is a warning on bootsdi script, besides I guess verification of livexp can handle this)
Modular is not a "must" choice, for another case there is a thought of uniting scripts (not relevant to current subject, I just want to give example that besides we like to have modular, we dont strick to modular).

What you think about naming ? (name of batch or title, name of option on bootsdi, or maybe name of a seperate script etc)

[oriensol]

Wow a minimum RamDisk size of 16GB! My computer is way to small for this.

Sorry that was a typo! I meant 16 MB.

[MedEvil]

if possible, a byte option maybe nice too

What for?

[oriensol]

Did not quite understand what you meant about unformatted. I would say, make them perfect if you're first gonna make one.

Is there any reason why a ramloaded disk image should not be ntfs compressed?

Joakim

The idea is to keep the tool simple - we have jaclaz's tool which is comprehensive. As to the formatting etc., we can reuse the existing BootSDI script capabilities.

For non-winbuilder purposes, the user can use vdk or whatever tool and create multiple partitions or whatever. I am not even using vdk in the script.

My idea was to have a quick starting point to create a disk and use other tools later on. I do not think I can make it simpler than what jaclaz has done if I add back various options.

I hope I am able to get my idea across.

As to compression, only NTLDR and NTDETECT.COM I think need to be uncompressed - I also saw a note to that effect from Karyonix somewhere.

[Lancelot]

What for?

I like bytes

The idea is to keep the tool simple ....
My idea was to have a quick starting point to create a disk and use other tools later on.

I agree, forget what i wrote, keep within your strategy

[was_jaclaz]

Last time I checked jaclaz's batches :

What the script does:
1) asks for a file name (for the moment use the same directory where the script and all utilities are)
2) asks for an image size in bytes, Kbytes, Mbytes or Gbytes
3) asks for the desired geometry
4) asks for the desired Partition (filesystem) type
5) asks whether you want to use the (default) mksparse.exe to create a sparse image or fsz.exe to create a full image
6) creates the image
7) autocalculates partition table entries to create the single biggest possible partition for given image size and creates a MBR with this data and 2K/XP MBR code
8) copies this MBR to the image
9) mounts the image with VDK and formats it using "standard" FORMAT
10) opens with Explorer the freshly mounted Virtual Disk

I see no reason (if a size parameter has to be passed to it) to remove the option to express it as "bytes, Kbytes, Mbytes or Gbytes".

It doesn't cost much and keeps everyone happy.



jaclaz

[oriensol]

@jaclaz

Let me clarify.

In my original approach I was using the original batch which was/is fine. I thought a simple interface would make it easier to the user. The advanced user can always use the original batch commands.

Since I am assuming 255/63 geometry, we anyway end up with the same final disk size whether we count in bytes, KB or MB to ensure we have round cylinders (hence the 8 MB increments). Or else, we need to allow other geometries. Just trying to keep it simple. Please correct me, if I am wrong.

[was_jaclaz]

Please correct me, if I am wrong.

You are not wrong, nor right.

It depends on the scope of the .script, if you are making a "general" use tool or a "narrow" one.

My batch has a (known) limit (or feature) :

• It won't check the given size for the image being a multiple of a given geometry, but it will make a partition calculated on the max multiple of the given geometry immediately smaller to the given size.

Such an image, unless the size given by the user already is a multiple of the given geometry, will create an image with "spare" sectors (difference between multiple of geometry and size), which will produce a warning when mapped in grub4dos.

If you "fix" a geometry of 255/63 and you want to make an image of the "exact" size, respecting Cylinder boundaries, whatever the user gives as size needs to be "trimmed" down to the nearest smaller multiple of 255x63x512=8 225 280 bytes.

And it doesn't make any difference to this additional check if the size was given by the user was expressed in bytes, Kbytes, Mbytes, Gbytes.

But if it's a "narrow" tool, only intended to be loaded via grub4dos and firadisk, and with a partition to be formatted as NTFS, there should be no need to respect the Cylinder boundary.

Respecting the Cylinder boundary was introduced in the batch to:

• comply with "old" standards/OS and with any partition type, being it CHS or LBA mapped
• comply with "bad" BIOSes

Some tests need to be made to confirm this, but theoretically there should be no need for this compliance with Win2K/XP/2003/Vista/2008/7 on NTFS, and again, no difference depending on the unit of measure the size is given.



jaclaz

[oriensol]

Thanks a lot jaclaz for the clarification.

Now I am confused as to what should be the scope and whether we should not bother about the cylinders. I know that we do get the warning from grub4dos while mapping.

Any advice from anyone? ; basically this is a choice between simplicity with least warnings vs. complete flexibility.

Not sure whether we even need a new batch then!

[Lancelot]

lets say "hddimage.cmd Release maybe v0.1"

[oriensol]

I have posted the batch tool in this link : http://www.boot-land...?showtopic=9033

I modifed the program this way:

E:\MBRBatch>hddimage



Usage: hddimage.cmd targetfile diskimagesize [round-to-cylinder=/R]



   targetfile is the path of the Disk Image File to be created



   diskimagesize is the image size in bytes - add a suffix K, M or G for Kilo,

Mega or Giga



   Optionally, specify '/R' to round the disk image size to cylinder boundary

Now with this done, will move on to the script part.

Hope this is fine. Have taken all the feedback into account.

[oriensol]

So who's gonna take the challenge?

Joakim

@joakim,

I am working with Lancelot on the BoodSDI stuff.

Now it looks like we have many combinations using which we can boot livexp into RAM.

[was_jaclaz]

@oriensol
OT, but not much , check this:
http://www.boot-land...?...ic=6492&hl=
a VSStorage mounted image can be accessed by Disk Management (or diskpart) allright. (and is given a 255/63 geometry)



jaclaz

[oriensol]

@oriensol
OT, but not much , check this:
http://www.boot-land...?...ic=6492&hl=
a VSStorage mounted image can be accessed by Disk Management (or diskpart) allright. (and is given a 255/63 geometry)



jaclaz

Thanks jaclaz. I had seen the post but haven't studied it.

I am sorry I was prematurely jubilant about the firadisk boot. I made a mistake. I selected the wrong menu option and thought it worked. Needs some more work

[devdevadev]

Here's the update. Also updating the info in the first post.

Tested the following:

BootSDI NOT used. ImDisk B: drive is part of the build.

With XP sources (versions 0.0.1.10 and 0.0.1.12) :
1. Booting Livexp from a Firadisk Livexp Iso (menu.lst):

title LiveXP-Firadisk

map --mem (hd1,0)/test_img.img (hd3)

map --mem (hd1,0)/pmagic-4.3.iso (hd32)

map --mem (hd1,0)/minlex/ISO/LiveXP.iso (0xFF)

map --hook

chainloader (0xFF)

2. Booting Livexp from cd with non-boot Firadisk defined using grub4dos.
3. Booting firadisk LiveXP.iso over network using tftpboot/grub4dos.

With Win2k3 sources (version 0.0.1.12):
1. Booting Livexp from a Firadisk Livexp Iso

Here's what works:

1. Booting Livexp from RAM Disk
2. Exlporer works, all partitions are recognised with drive letters
3. Non-boot RAM CD Rom works
4. Non-boot RAM Disk Works
5. Device Manager shows FiraDisk Virtual Disk Enumerator and the RAM CDRom and Disk.
6. Disk Management recognises the drives
7. Formatting the RAM hard disk works
8. Check http://www.boot-land...hl=livexp tips for Disk Management Partitioning workarounds.
8. "sc query firadisk" shows firadisk is running
9. PXE booting with tftpboot works with LiveXP.iso.


What needs to be noted:

1. The firadisk driver date and version info is suppressed from the Device Manager (to prevent frequent changes to the script). User needs to click on Drive Details to get that information.
2. When you click on the Firadisk Virtual Disk Enumerator, you get an error message before you can continue.
3. When booted from a Firadisk iso, there will be a dummy cdrom RAM drive in addition to X:.

When a newer version of firadisk is released, please download into %GlobalTemplates% or any other location and point the script to the location of the zip, using the interface.

Latest script in first post.

 

 

Hi oriensol'

 

For lots of thanks for providing 'Script for Karyonix's FiraDisk'.

 

Actually current version of firadisk is 'firadisk-driver-0.0.1.30'. And I highly need a Script of latest 'firadisk-driver-0.0.1.30' for 'Win8.1SE'.

 

Please give a favor and update it for 'Win8.1SE' as soon as possible............

 

Thanks in Advance

[Wonko the Sane]

Actually current version of firadisk is 'firadisk-driver-0.0.1.30'. And I highly need a Script of latest 'firadisk-driver-0.0.1.30' for 'Win8.1SE'.
 
Please give a favor and update it for 'Win8.1SE' as soon as possible............

When a newer version of firadisk is released, please download and use the custom file or use the available 0.0.1.12 version included in script.

Hmmm.

I wonder what could be the hidden message in the above oriensol's statement. 



Wonko