Hello everybody,

I want to make a new MBR which can do a more task: copying D partition to E partition.

Could some one give me help or show me where I can found a Base frim I can start ?

Thank you very much.

NB: C, D and E partitions are 50Go exactly each one.

You can start with GRUB loader, which is open source (Grand Unified Bootloader).
Find more here

http://en.wikipedia.org/wiki/GNU_GRUB

Sorry, I didn't inform that the new MBR (or modified one) size must be less that 440 Bytes (max 446 Bytes). GRUB as I see, use two parts (may be 3 if we count the 105 stage) and it's more sophisticated than this basic need.

Where can I found a code of a "working" MBR ? may be I have to start from there to understand it, and then try to modify it ?

Thx in advance for a link or an existing and working MBR code. (in this site, I see just beta codes)

You can take a look at commercial MBRs here http://thestarman.pcministry.com/asm/mbr/#win2kxp

Copying one partition into another is not MBR job and will be very slow but might be possible within 440 bytes if both partitions have same filesystem. "Commercial" MBRs don't do this. (maybe you are using English incorrectly to express what you need?)

Thank you for information that copying one partition to another can be done by MBR in respect of the max size of MBR (440 to 446 Bytes).

I've found some important example of writing particular Boot record there (in french but Google translation can give help):
http://a.michelizza.free.fr/pmwiki.php?n=TutoOS.Bootsect
http://a.michelizza.free.fr/pmwiki.php?n=TutoOS.Bootloader
http://a.michelizza.free.fr/pmwiki.php?n=TutoOS.ProtectedMode

Doing this task by MBR is an alternative solution to a first one which is: a modified BIOS! yes, it's possible if I believe what I read
It seems more simple and secure since it's written hardly in ROM (by manufacture), or in EPROM in our case.
We can found Open BIOS and Boot their:
http://www.openfirmware.info/OpenBIOS
http://www.openfirmware.info/OpenBOOT

We can also do a reverse engineering to lot af actual BIOS and add in it all what we need:
http://sites.google.com/site/pinczakko/pinczakko-s-guide-to-award-bios-reverse-engineering
http://sites.google.com/site/pinczakko/pinczakko-s-guide-to-ami-bios-reverse-engineering-1
http://sites.google.com/site/pinczakko/preliminary-bios-modification-guide-

My question: could BIOS copy partition D to partition E (same size same file system) more quickly than MBR ?

I'd recommend against the BIOS idea - purely for the risk involved in damaging the machine, as well as the non-portability of it.. an MBR-based bootloader will run on any x86 machine with a BIOS, whereas a BIOS would be specific to the machine/motherboard.

As for speed - its unlikely to be faster. Your main limitation(s) is because of the limit on size. In the size you're asking for, you're unlikely to be able to fit code to set DMA access modes for the drives (probably the biggest factor in fast disk access), as well as buffered read/writes (although those buffers would be in ram, but you still have to set them up in the code).

You should maybe look at Tomasz's old bootloader code for a fasm example of a bootloader.. and even just use his code as a base (although you can remove all the actual OS booting stuff.., which is most of it).

Depending whether you're actually wanting to write this (to learn), or if you just want something that works.. then theres also the option of using (for example) a linux livecd or similar, and modifiying it to automatically copy one drive to another at boot (look into dban.. its not what you want, but its a modified linux livecd that does "secure" deleting of hard drives.. yours would be similar, just copy instead of delete).

Thx gunblade.

The use of a Live CD/USB for booting and executing this task (copying D to E partitions) is the 3 alternative. The 4th is to do this via Network using BIOS configuration (NDLR To copy an image to PC from a foreign server). I preferred to go step by step to understand and have a maximum of helps of each alternative. But you was more careful and went straight a head to my other alternatives

An other alternative is to use the RAID BIOS (material RAID card) It permits to add codes in to do this also:
http://en.wikipedia.org/wiki/RAID#Hardware-based_RAID

So, if we treat just the BIOS solution, you said that it will not be faster because of size limitations, and the use of RAM. But I tnhik it will be faster than if any other application or OS try to do it? am I wrong ?

Ah, well I was just suggesting because a livecd is what I would use for that kind of task (but i would be using it interactively/for rescue rather than a constant task the computer should run).

For the speed.. you'd be surprised.. chances are, you'd do it slower than an OS would.. for several reasons:
- As mentioned before, DMA, modern drives are clever and just because you're accessing the hardware at a lower level doesnt mean you'll get more speed, not if you dont use their available acceleration methods.
- You want to do large reads/writes to/from the device.. hard drives do not like being read byte-by-byte, you want to instead execute larger (size depends on the hardware, but not really any downside to going for bigger except more RAM usage) reads and writes.
- Theres also features in harddrives such as "read-ahead" where it'll cache the next data, you may want to check that its enabled (not sure if its enabled by default.. under linux i use a tool called hdparm to check/set these settings such as DMA, 32-bit read/write support and the read-ahead setting).

One thing I havent checked with you.. I'm assuming you're wanting to do a direct-copy of one hard drive to the other.. without reading/opening file systems.. this would require both hard drives to be the same size (which I believe you said they are, so thats fine), but it means that you're just making an exact mirror.. overwritting anything that was on the destination drive, including the filesystem and bootloader...? If so, its fine - its just if you wanted to do recursive file copying, then you'd also need code to read the filesystem.. and there was very little chance you'd get something like that implemeted in ~400 bytes.

Another thing I realised - at the point of executing the bootloader - you'd be in 16-bit real-mode.. limiting your instruction set and the ability to address more memory at once, unless you switch into unreal or protected mode..

Not to put you off doing this in assembly (it is an assembly forum - and assembly rules ) - but I'd still suggest the easiest/fastest(both for implementing and execution speed) would be using a floppy/usb pendrive/third harddrive/cdrom to boot a livecd and execute a dd if=/dev/sdb of=/dev/sdc bs=1M or similar.. (the bs sets the block size.. so it reads 1M from your source drive, writes that 1M, then goes back to read.. faster than byte-by-byte.. i think anything above the block size of the device is a safe choice (to get the best speed.. i doubt >64k makes a big difference.. but might as well if you have the ram)).

Keep in mind that in near future (about 1 year I think) UEFI will come together with WIN 8 and will accept only signed drivers / software with certification. This can be switched off but will be a safety feature in the future against boot exploits.

http://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface

I think they would have problems with EU law, the UK will say yes as they did many times to M$ in the past, now Tony Blair, ex PM of UK works for M$ .

GParted Live CD. PERIOD. http://gparted.sourceforge.net/livecd.php

This live cd has saved my life, literally. (My data is my life.) It's insanely simple, whereas programming something like that is not something I would trust myself to do.

Also, if you're going to do this in a boot sector, you're almost surely going to have to use int 13h (http://helppc.netcore2k.net/interrupt/bios-disk-services), which is limited by cylinders and sectors. I'm not exactly sure how many sectors that limits you to. Ie, there may be some sectors towards the end of the disk that are unreachable by cylinder/sector addressing. Idk for sure, someone else may be able to clarify.

@ gunblade, shutdownall, Dex4u, Tyler, asmdev : thank you for all the very interesting practical informations.

I think that now I see better how I can make this in different practice cases:

1- Directly from a modified BIOS or UEFI,

2- By a modified material RAID firmware,

3- By a modified MBR. In this case:

a. if I use the 013h Init (AH=42 and 43) it’ll be done, but very slowly (to copy 50 Go of D partition or hard disc to 50 Go space of the E partition). I don’t have idea about the time it will take? 5 minutes? 15 min? 1 hour?

b. If I start in 16 bits mode, and than pass to 32 bits, and protected mode, It’ll be faster. If I use Direct Access Memory « DMA » and « read-ahead » (this is a Linux command, it's not ? can we have similar just by using interruptions ?), It will more faster. But this will be possible just in case if it’s supported and activated. By BIOS? By UEFI? could DMA and read-ahead be executed from MBR by mov, push, pop, etc ?

4- By booting on a secure media (live CD/USB, network, external HD), charging a little OS (DOS, small Linux, etc.) and then execute the copy (dd in Linux, copy in DOS, etc.)

Could you please confirm that I understand all the case, or I’m wrong somewhere?
Thx in advance.

3a. no idea about time. But sector by sector copying is easy to implement and test.

3b. I am not aware of any read-ahead features provided by bios. Maximum what you can have is reading multiple sectors at once instead one(512b) by one(512b). But the rumor has it that it won't work everywhere.

AND if you ever decide to ignore bios and use native disk driver then first "small" problem for you to solve is: Which device on pci(or isa) bus corresponds to bios drive number in DL. (everything won't fit in 440 bytes)

I actually don't see anything good in making identity copy of a partition from a hidden program so I'll stop posting.

Using extended BIOS INT13h which has been around for quite a while, it's not a problem.