OSDev.org

Hello, I need some assistance. How do I copy boot.bin to empty HDD?
Any suggestions?
Sincerely, Tim.

Hi

Use something like HxD if you are using a PC as it will allow you to copy and paste from a bin file to the HD. It's how I get my code on to a boot HD in VirtualBox.

Bipman

EDIT: I noticed several serious errors in the earlier version of this, which I have now fixed (I hope). Mea culpa.

Any version of dd(1) (including WinDD or the Cygwin and MinGW ports) should work, pretty much the same way you would for a floppy image, except that sector 0 would need to be the MBR, and the boot block would be in whichever sector you define in the MBR's Partition Table as the start of the partition to use (probably sector 1, for a simple single-partition layout).

Note that if you have VirtualBox set to use UEFI booting (which it usually will if the underlying platform does, I think - corrections on this are welcome), you will want to use a GPT rather than a legacy partition table.

To actually create the image with a command-line dd(1), you might use something like:



Keep in mind that bs, ibs and obs are in bytes, while seek, skip and count are in blocks of the ibs or obs sizes. Technically, both bs defaults to 512, and can be skipped here, but you probably want to have it explicitly despite this.

You can use suffixes to indicate the sizes as well. So, for a 100M image and a 1M kernel, you would have the MBR count as 200K and the kernel count as 2K.

Note also that /dev/zero is a part of Unixoid OSes like Linux; I am not sure offhand what to use in Windows instead. I have seen that some dd implementations for Windows mock up /dev/{null|zero|random|urandom} for cases like this, but I don't know if all of them do.

FYI, I use Windows. I need a special program in order to write it to the HDD not the floppy

Are you writing to an actual HDD, or to a disk image file? If it is a disk image, a Windows version of dd will work just fine as I described - it is what I was assuming (of stands for 'output file', and is used both for raw devices and for files).

If you are writing to a physical HDD, then... well, you'll need to use a partition manager first anyway, unless you are using an unformatted drive (which means, among other things, a drive other than the one you are developing on), in which case you are basically creating the partitions manually.

If you have already created a separate partition on the disk (whichever disk it is), then you should be able to use WinDD or something similar, though you may run into problems with Windows preventing it from touching an unformatted partition, or writing to the boot block of a formatted one.

For a real HDD, where a partition already exists, I think you would use something like



But don't take my word on it until at least one other person here confirms this.

Can anyone who knows Windows HDD partitioning and disk writing restrictions add anything?

Writing into the HDD image, my mate.

dd will also write to a disk image.

But WinDD does not work with my Windows (NT 10.0, 14393)

I'm not sure what you mean by 'HDD image" here, as 'image is somewhat overloaded. The term 'image' can refer to a simulated disk as a file, or as the raw disk data without taking into consideration of the format.

Let me put it another way: is this going onto the HDD itself as raw bytes, or as a file on the HDD in your parent file system (presumably C:\ or whatever drive you are developing on)?

Most of the time, you only use 'disk image' to refer to a raw copy of the hard disk when discussing backups - most of the time in OS dev, you are using a file to simulate the disk in something like VirtualBox or Bochs.

Careful and conscientious OS devs won't work with a real HDD until they have developed a utility for formatting the disk in their preferred file system format (FAT32, ext4, JFS, whatever it might be). By the time you are there, you aren't really talking about a disk image, you are generating the formatting based on the partition's structure.

Mind you, for either case you could use a Windows version of dd as described earlier, or something like RaWrite32 or the aforementioned HxD. They all should be able to do the trick for anything - disk images, floppies, hard drives, anything that can be written to as a file or block device, really.

Huh. I didn't know that, but looking at the SF page, I see that it was last updated some time just before Windows 10 (which is the same as NT 10, but you probably knew that) was in general release. It seems HxD is even older (2009), so there's a good chance it won't work, either. Rawwrite32 is up to date as of last May, though, and Cygwin is as well if you don't mind messing around in the BASH shell emulator it provides (you could use Cygwin/X for some Unixoid things, but I don't think there are any graphical front ends on it for dd).

Since all you are trying to do is install a boot record to a disk image, why not just write a custom utility for doing it? It is trivial to write and can be extended later to detect the file system and automate the installation process. You already know what bytes need to be copied, so why not just write the code to do just that?

Agreed. Just write your own. That's what I did.

If you can write an OS, you can probably write a Windows utility to copy some bytes to a file.

I agree as well; as I said, this is what a sensible developer does once they are at the point of installing a live version of their OS on a hard drive, as it gives you full control over the process and the drive formatting.

That having been said, I am still not certain that you are actually at that stage, yet - it sounds as if you are just starting off still, and haven't gotten to the part where you are using a file system in your disk image (a more-or-less necessary first step before installing a bootable OS on a hard drive, or even a floppy that you want other OSes to be able to read).

Indeed, this is usually done when developing your second stage loader but before developing your actual kernel, because the usual practice is to have the kernel in an executable Object File format (e.g., ELF, PE) rather than a raw binary image, and have the second stage of the boot loader to read the file system directory structures and load the kernel as a normal executable file.

This is also part of why we recommend using an existing boot loader in the first place, if only because developing a boot loader yourself is a detour on the road to OS dev rather than a path to it, but you seem committed to this direction so I won't belabor the point.

However, using a file image as a scratch monkey when developing such a tool is also wise, anyway, so it would make a great deal of sense to go ahead and write your own disk utility well in advance of working with a real hard drive partition.