MBRBatch 0.01 ALPHA, [Release] External links Rating Options

[was_jaclaz]

Ok, peeps, here is the ALPHA 0.01 Release of MBRBatch.cmd.

You will need an awful lot of command line utilities to go with it (and even more when the missing features will be added), for now:

dsfo/dsfi from the DSFOK package:
http://members.ozemail.com.au/~nulifetv/freezip/freeware/

gsar:
http://home.online.no/~tjaberg/

dumphex:
http://rbach.priv.at/DumpHex/

The files need to be in the same directory where MBRBatch.cmd is or in the PATH, the batch will prompt you for missing files.

Here is a main screen, to let you have an idea of what it (hopefully) does:

CODE

mbrbatch.cmd batch file to manage MBR's Release 0.01 Pre_ALPHA 1st Oct. 2007
by jaclaz, this file is licensed under my "CAREWARE" license:
http://home.graffiti.net/jaclaz:graffiti.net/careware.html

General syntax is mbrbatch.cmd COMMAND [parameters], commands are:

CREATE targetfile Creates MBR from a 2K/XP file saving it as targetfile
VIEW source Shows partition entries in source MBR
COPY source targetfile Copies a MBR from source, saving it as targetfile
EDIT sourcefile [params] Edits one partition entry in MBR file
UPATCH sourcefile Patches sourcefile with "HP" USB/int13 modification
(sourcefile must contain 2K/XP MBR code)
WRITE source target [/F] Writes a MBR file to target
MKIMG filesize Creates an image of given size, complete of MBR
(NOT YET AVAILABLE)
HELP command Displays help for the given command

Notes:
[source] can be a file or a drive number, [sourcefile] must be a 512 bytes file
[target] can be a file or a drive number, [targetfile] must be a NEW file

If any non-optional parameter is missing, it will enter interactive mode.

The command is relatively safe, as it operates mainly on files, the only exception is the WRITE command that can write to disk (writing to \\.\PHYSICALDISK0, i.e. boot drive needs to be forced, however).

It is ALPHA, a LOT of corners still need to be rounded, and temp files and variables are not (yet) managed completely in the proper way, but it appears to be working.

Your suggestions, bug reporting (if any ) and ideas are welcome.

jaclaz

Attached File(s)

 mbrbatch001.zip ( 8.63K ) Number of downloads: 896

 

[ktp]

@jaclaz.
Congratulations, another tool for boot lover :-). Following are few quick remarks:
1) view source: should check that the source file is exactly 512 bytes.
2) need to provide examples to illlustrate syntax of source/target for a drive. for example same syntax as dsfo/dsfi ..\.\physicaldrive1.
dsfo/dsfi does provide examples on the command line without parameters. Otherwise the user does not know if he/she must enter c: or 0x80 etc...

[was_jaclaz]

@jaclaz.
Congratulations, another tool for boot lover :-). Following are few quick remarks:
1) view source: should check that the source file is exactly 512 bytes.
2) need to provide examples to illlustrate syntax of source/target for a drive. for example same syntax as dsfo/dsfi ..\.\physicaldrive1.
dsfo/dsfi does provide examples on the command line without parameters. Otherwise the user does not know if he/she must enter c: or 0x80 etc...

1) No, it is "by design": "source" can be ANY file or PhysicalDrive number, the batch extracts just the first 512 bytes of "source".
Rather obviously, if "source" does not has a MBR as first sector, results of the VIEW command will be pretty much garbage.

2) try mbrbatch HELP VIEW

mbrbatch.cmd VIEW [source] Shows partition entries in source MBR

Source can be either a MBR file or a drive number.

Drive numbers begin with 0.

Please use some common sense for filenames:
NO spaces in name, extension or path, the batch has been tested
ONLY with "pure" DOS 8.3 names

EXAMPLES:
mbrbatch.cmd VIEW C:\MBRBATCHDIR\my_MBR.mbr
mbrbatch.cmd VIEW 0

or just MBRBATCH (with no parameters):

Notes:
[source] can be a file or a drive number, [sourcefile] must be a 512 bytes file
[target] can be a file or a drive number, [targetfile] must be a NEW file

If any user thinks that c: is a drive number, the only command he should use would be the command:

CODE

MBRBATCH HELP HELP

jaclaz

[ktp]

OK
I agree that my "c:" example was a little exaggerated :-).

mbrbatch help help =>
mbrbatch.cmd HELP Shows the HELP info

Basically, if you need help to use the HELP command,
I am afraid you won't be able to appreciate the use
of this batch file.

Try the HELP command with some other command, it might
be more useful than this lame notice.


mbrbatch help view => (user error) but maybe (suggestion) you accept it and use mbrbatch view help as below
(same for other commands).

mbrbatch view help =>
mbrbatch.cmd VIEW [source] Shows partition entries in source MBR

Source can be either a MBR file or a drive number.

Drive numbers begin with 0.

Please use some common sense for filenames:
NO spaces in name, extension or path, the batch has been tested
ONLY with "pure" DOS 8.3 names

EXAMPLES:
mbrbatch.cmd VIEW C:\MBRBATCHDIR\my_MBR.mbr
mbrbatch.cmd VIEW 0


OK, the user provides only a number (e.g. 0), and the batch will complete with \\.\physicaldrive0 to dsfo/dsfi.
This is the point I missed when I quickly try the batch. I was afraid that the user has to type \\.\physicaldrive0 syntax as
required by dsfo/dsfi. In fact your batch hide this "complicated" syntax from the user and requires only a "drive number" (0, 1, 2...).

[was_jaclaz]

mbrbatch help view => (user error) but maybe (suggestion) you accept it and use mbrbatch view help as below
(same for other commands).

Well, the general syntax is
MBRBATCH COMMAND [parameters]

So, if you type:
MBRBATCH HELP
You are telling it that you want to use the HELP command, and you see :

Input the command you need help on or press [ENTER] to view ALL commands help:
Available commands: CREATE VIEW COPY EDIT UPATCH WRITE HELP

If you type
MBRBATCH HELP VIEW
you are passing to the command HELP one of the accepted parameters, i.e. one of the available COMMANDs, but which, in this case, is a parameter

In other words, first argument passed to the batch is ALWAYS a COMMAND, second and further arguments are ALWAYS [parameters].

The way you suggest it, it would be "non-standard", and really I cannot see the reason why you would like having it in a reversed logic.

I am attaching version 0.02, which has two small bugs fixed.
OE instead of 0E in a for loop and a couple of "trailing spaces" in variables assignments that caused errors.
I also added Partition Types 01 (FAT12) and 04 (FAT 16 <32 Mb - obsolete)

jaclaz

Attached File(s)

 mbrbatch002.zip ( 8.67K ) Number of downloads: 484

 

[ktp]

@jaclaz

The way you suggest it, it would be "non-standard", and really I cannot see the reason why you would like having it in a reversed logic.

I understand your point of view. It was only a suggestion (and I mentioned "user error"), since other tools or batch have this reverse logic, and "habits are a second nature". For example take the famous 'net' (and 'net help') command, you will see it adopts another approach:, help-centric (help of what command) and not command-centric (what parameters to the command, including help parameter).

But I agree that if the user reads the syntax as displayed by the batch (RTFM), there is no problem (and again "mbrbatch help view" is an user error in this case).

On the same idea, usually I expect copy command with first parameter as source, and second parameter as target. copy source_from target_to.
So at first with dsfo/dsfi I had some errors (could be dangerous) since by habits I assumed that source is always the first parameter. This is OK for dsfo
but not for dsfi.

Usage: dsfi destination offset size source
Usage: dsfo source offset size destination

Other: I like mkbt syntax (single command, mkbt <switches> (source) (target), while source/target could be file or drive). dsfi/dsfo would be merged into one executable and adopt same syntax source [source_param] target [target_param]. But as wisdom said, "When In Rome, Do As The Romans Do".

[was_jaclaz]

OK, please find attached an ALPHA version of the MKIMG comand.

For the moment I made it in a separate batch, planning to integrate it in MBRBATCH.CMD later.

Other utilities you will need (besides MBRBATCH.CMD and the utilities it already requires):
mksparse:
http://www.acc.umu.se/~bosse/

fsz from the DSFOK package:
http://members.ozemail.com.au/~nulifetv/freezip/freeware/

vdk.exe/vdk.sys:
http://chitchat.at.infoseek.co.jp/vmware/vdk.html

The script is safe in the sense that already has the major part of needed checks, but it DOES NOT check (at least for the moment) for available space on the drive for the creation of the image.

This is not a problem if you are using it on a NTFS volume (as you should) with mksparse.exe as program to create the image (which is the default), but if you use it on a non-NTFS volume and/or use fsz.exe for creating the image, there are NO limits to the size of the image that can thus be bigger than your available space.

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

The script works both in interactive mode and invoked from command line with all parameters, in this case it accepts a further switch "/np" for "NO PROMPTS" that COMPLETELY REMOVES any confirmation to delete existing files and to format the Virtual Disk.

In my testing it did work rather well, and, as said, unless you use the /np switch, any destructive operation needs to be confirmed.

Enjoy!

jaclaz

P.S.: Many thanks go to Peter (psc) for his "internationalizing" idea:
http://www.boot-land.net/forums/Internatio...AT-Y-t3229.html

Attached File(s)

 mkimg001.zip ( 4.47K ) Number of downloads: 363

 

[Galapo]

Hi jaclaz,

I've been trying to test MKIMG, but have been unsuccessful in creating an image. I receive an error stating "The image is unmountable, please check given parameters..."

Steps complete until the error:

1. enter image size of 122880 bytes.
2. enter geometry of 16/63
3. enter partition type 07
4. either use mksparse or fsz

The .pln file I notice has the line "CYLINDERS 0" which cannot be correct and is likely the reason the image is unable to be mounted.

Thanks for your time.

Regards,
Galapo.

[was_jaclaz]

@Galapo
You joking right?

122,280 is roughly 1/12th of a 1,44 floppy.

There is NO way it can fit in a 16/63 image.

Even if it would, experiments made a few years back by Mark Russinovich, showed that formatting a floppy with NTFS was possible but that the filesystem structures occupied almost half of it!

So this is bug #1, I have to put some lower limits to the batch , actually I had thought about that, but later completely forgot to put them in.

In the meantime, find here a small spreadsheet file with minimum sizes for different geometries:
http://www.boot-land.net/forums/index.php?...=3226&st=11

Those represent the absolutely smallest images of HD type that can be mounted with a .pln file, though the spreadsheet is made for 06 type - FAT16 - (that will later become however 01 FAT 12) you can experiment with different filesystems.

jaclaz

[was_jaclaz]

Version 0.02 attached:
- Added 64/63 geometry
- Introduced minimum size limits:

CODE

SET Geometries=255/63 128/63 64/63 16/63 64/32
::If image is smaller than 16,450,560 bytes, i.e. of 32,130 sectors, it cannot be used with 255/63
IF %Totsectors% lss 32130 SET Geometries=128/63 64/63 16/63 64/32
::If image is smaller than 8,257,536 bytes, i.e. of 16,128 sectors, it cannot be used with 128/63
IF %Totsectors% lss 16128 SET Geometries=64/63 16/63 64/32
::If image is smaller than 4,128,768 bytes, i.e. of 8,064 sectors, it cannot be used with 64/63
IF %Totsectors% lss 8064 SET Geometries=16/63 64/32
::If image is smaller than 2,097,152 bytes, i.e. of 4,096 sectors, it cannot be used with 64/32
IF %Totsectors% lss 4096 SET Geometries=16/63
::If image is smaller than 1,032,192 bytes, i.e. of 2,016 sectors, it cannot be used with 16/63
IF %Totsectors% lss 2016 SET Filesize=&ECHO Image FileSize is TOO SMALL for ANY geometry...&GOTO :Begin

jaclaz

Attached File(s)

 mkimg002.zip ( 4.67K ) Number of downloads: 409