65 replies to this topic

[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.ozema...eezip/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:

mbrbatch.cmd batch file to manage MBR's Release 0.01 Pre_ALPHA 1st  Oct. 2007by jaclaz, this file is licensed under my "CAREWARE" license:[url="http://home.graffiti.net/jaclaz:graffiti.net/careware.html"][url="http://home.graffiti.net/jaclaz:graffiti.net/careware.html"][url="http://home.graffiti.net/jaclaz:graffiti.net/careware.html"]http://home.graffiti.net/jaclaz:graffiti.net/careware.html[/url][/url][/url]General syntax is mbrbatch.cmd COMMAND [parameters], commands are:CREATE targetfile		Creates MBR from a 2K/XP file saving it as targetfileVIEW source			  Shows partition entries in source MBRCOPY source targetfile   Copies a MBR from source, saving it as targetfileEDIT sourcefile [params] Edits one partition entry in MBR fileUPATCH sourcefile		Patches sourcefile with "HP" USB/int13 modification						 (sourcefile must contain 2K/XP MBR code)WRITE source target [/F] Writes a MBR file to targetMKIMG filesize		   Creates an image of given size, complete of MBR						 (NOT YET AVAILABLE)HELP command			 Displays help for the given commandNotes:[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 fileIf 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 Files

•  mbrbatch001.zip   8.63KB   3563 downloads

[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:

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 Files

•  mbrbatch002.zip   8.67KB   1735 downloads

[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.ozema...eezip/freeware/

vdk.exe/vdk.sys:
http://chitchat.at.i...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...AT-Y-t3229.html

Attached Files

•  mkimg001.zip   4.47KB   1537 downloads

[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...?...=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:
[codebox] 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
[/codebox]

jaclaz

Attached Files

•  mkimg002.zip   4.67KB   1597 downloads

[Galapo]

Hmmm. Yes, made a boo boo. I think I need more sleep, so am going to go and get some now.

Now that I've woken up to my idiocy, I can report that it is now working for me! Great job, this is indeed very handy, and I can put it to automated use creating images to boot with syslinux.

Regards,
Galapo.

[was_jaclaz]

Version 0.03 attached.

Fixed a NASTY bug related to suffixes in the size of the image!

Thanks to Waylorne for pointing this out

jaclaz

Attached Files

•  mkimg003.zip   4.68KB   1507 downloads

[Galapo]

Hi Jaclaz,

I hope you don't mind me modifying your mkimg batch. I've modified it slightly to optionally include specifying a disk label and compression for ntfs:

mkimg.cmd target filesize[k|M|G] Geometry PartType [ImageLabel] [/fsz] [/np] [/C]

See the attached. Maybe this can be improved -- I'm not so good at writing batch files!

Regards,
Galapo.

Attached Files

•  mkimg.zip   4.85KB   1445 downloads

[was_jaclaz]

Hi Jaclaz,

I hope you don't mind me modifying your mkimg batch. I've modified it slightly to optionally include specifying a disk label and compression for ntfs:

MBRbatch.cmd target filesize[k|M|G] Geometry PartType [ImageLabel] [/fsz] [/np] [/C]

See the attached. Maybe this can be improved -- I'm not so good at writing batch files!

Regards,
Galapo.

Of course I do not mind, I find it a great idea.

If you already tested it (after your modification) with both FAT and NTFS and it works, I would call it 0.04 and be done with it.

Of course there are still a lot of small "corners to round" before a real release, like polishing up "remnants" and the like.

jaclaz

[Galapo]

Gday Jaclaz,

Yes, I've tested with fat, fat32, and ntfs. Working fine for me.

I'm actually calling your batch in my personal mofification to the bootsdi script to create an image which syslinux likes, viz. 16x63. This is a great timesaver to me since I don't have to manually create images any more!

Regards,
Galapo.

[cam99]

Sorry I need to read the cmd file before I ask some questions.

[Galapo]

Currently my update is the latest.

It is a batch file and runs as such. I use it in a WB script for my personal use which I haven't released, but I haven't 'translated' the batch to WB syntax.

Regards,
Galapo.

[bilou_gateux]

Hi Jaclaz,

I hope you don't mind me modifying your mkimg batch. I've modified it slightly to optionally include specifying a disk label and compression for ntfs:

mkimg.cmd target filesize[k|M|G] Geometry PartType [ImageLabel] [/fsz] [/np] [/C]

See the attached. Maybe this can be improved -- I'm not so good at writing batch files!

Regards,
Galapo.

@Jaclaz

I have an issue with language detection for auto answer to format prompt.
International FORMAT "Y" Language-Independant

command:

mkimg 320DISK.IMG 335544320 16/63 07 DISK320M /np /C

Edited by bilou_gateux, 27 January 2008 - 04:30 PM.

[Godzilla]

Hi,

I am searching for a solution to restore the boot code of the MBR (the first 446 Bytes) from a file under Windows.
As far as I can see, your tool just handle with the complete MBR (512 Bytes).
Is it possible to use your tool for my demands?
Or does anybody know a program I can use?

Thanks

Godzilla

[was_jaclaz]

Use dsfo/dsfi directly, as I already replied to you here:
http://www.msfn.org/...t...40&start=50

If you ask the same question n times to the same guy , you'll probably get n times the same answer.

What is the problem?

As said in the (also previously referenced) thread here:
http://www.boot-land...?...=3226&st=15

dsfo \\.\PHYSICALDRIVEn 0 512 Diskn.MBR

will produce a backup file of the MBR of Hard Disk n (first disk is 0, second is 1, etc.)

To restore the file to disk:

dsfi \\.\PHYSICALDRIVEn 0 512 Diskn.MBR

Now you just use :

dsfo \\.\PHYSICALDRIVEn 0 446 Diskn.MBR

and

dsfi \\.\PHYSICALDRIVEn 0 446 Diskn.MBR

to copy back and forth 446 bytes instead of 512.

Or if you like the (very few) "bells and whistles" my small batch provides, simply read the commands used in it and modify the 512 length in the dsfo/dsfi commands in the MBRBATCH.

Since, after all, I am a good guy , find attached a modified (simplified version of the batch).

Of course it is an ALPHA 0.01 release, so make sure to test it properly, NO WARRANTIES IMPLIED.

jaclaz

Attached Files

•  mbr0toX.zip   2.3KB   1278 downloads

[Godzilla]

Thank you very much!!

Sorry, that I asked (again).
But I only read about 512 Bytes.
So I thought difo/i could not handle 446 Bytes.

Thx, again!!


EDIT:
I tested your Commandlines.

dsfo \\.\PHYSICALDRIVE0 0 446 Bootcode.mbr

This works well!!!

So I changed just dsfo to dsfi to restore the bootcode.

dsfi \\.\PHYSICALDRIVE0 0 446 Bootcode.mbr

But know I get an error:

\\.\PHYSICALDRIVE0 - Wrong Parameter

If I change the source to a filename that doesn't exist, i get an error

Can't find file

btw: I translated the error from german to english.
So they may not 100% correct.

EDIT2:
Write and restore a 512 Byte file doeas work.

It seems dsfi can only restore MBR with 512 Bytes.

But thanks anyway.
I think I will use a workaround...

[was_jaclaz]

Well, it is possible that direct disk access, since it is working on a "sector" based device only works with a sector (512 bytes) multiple.

Possible workaround is using an intermediate file:

dsfo \\.\PHYSICALDRIVE0 0 512 C:\Fullmbr.mbr

dsfo C:\Fullmbr.mbr 0 446 C:\Bootcode.mbr

dsfo C:\Fullmbr.mbr 446 66 C:\mbrdata.mbr

Now, providing you have another boot code file, 446 bytes in length:

copy /b c:\newbootcode.mbr+C:\mbrdata.mbr C:\NewFullmbr.mbr

dsfi \\.\PHYSICALDRIVE0 0 512 C:\NewFullmbr.mbr

jaclaz

[Godzilla]

My workaround is almost like yours
but fits more to our project.

But thanks.

[was_jaclaz]

My workaround is almost like yours
but fits more to our project.

But thanks.

You're welcome, main thing is that problem is solved.

jaclaz

[reirok]

Hello everyone.
Sorry for my bad English.
I read enough but not write for that reason. In this forum also 911CD and MSFN.
I am using mkimg.cmd but does not work for LBA.
I fixed with mbrbatch.
I was looking at the code and only creates CHS. (Line 126)
The question is? , I can modify the code to add CHStoLBA to mkimg.cmd as mbrbatch?

Greetings to everyone.