Originally Posted by vande012
Just to be specific what does this do different that makes it bootable? Does it put the files on a certain way? Does it put an extra file on the disc that tells DOS to boot off it? Im just wondering what it does different to make it a bootable disc
When an image file is created (say .iso), all the "settings" of the disk-to-be-created are saved to the file: disc label, files and directories to be burned to the disc, bootable flags (is it bootable or not) and so on. This is the idea of having image files: they contain the complete contents of a disc (or other data) stored into a single file. Then, when a program uses that image file to create something out of it (like a cd for example), it reads the contents of the file, including the "settings" like "this is bootable", and obeys them while creating the output (a cd, for example).
If you burn the image file as normal data burn
, your recorder just thinks it's a regular file, writes it to a disk (as a single file) and that's it. Instead, to create a bootable disc out of it, you want to have the program open the image file, check it's contents, write the files from the image to the disk and create the disk following the exact way of the image. For this programs have a special way of burning image files; you don't just drag them and burn, but specially tell the program "this is an image file, so treat it as one, and not regular data file".
The difference is that either the program handles the image as data, or it doesn't but instead reads what's inside. Imgburn handles the job nicely because it's created specifically for that. Nero is (tried to be) created for doing pretty much anything you can do with DVDs or CDs; normally people burn data or audio, and that's the basic functionality of it. When you want Nero to handle something as an image and not data, you'll have to use the menu option for that, to distinct the .iso file from normal data.
If you now think "why can't it do that when I double-click on the image file", the answer is this: some might want to burn the image file as data. For example if they had images of smaller mediums, they maybe wanted to burn several of those images onto one large media for something. They could later just mount the images on-the-fly without burning them, or something, but the important part is they wouldn't then want any of the images to be burned as images (it could make the disk bootable, it spreaded the files from inside the image file onto the disk forming a chaos, maybe overwriting files if every one of the images were "exploded"...). They just maybe wanted to have several image files on the medium. That's why images are not automatically handled as images, but the user is left with an option to burn them as images, effectively "extracting the contents" rather than burning the single file.
In addition to burning, you can transfer the whole image file where ever you want, and mount
it (without burning it), to see it's contents. On Linux this happens like this:
mount -o loop /path/to/image.img /mount/place
after which the contents of the image file were visible in /mount/place. Works just like a cdrom, except that you need the option "loop" and use the image file as the "device". On Windows you usually need somekind of extra software that creates a "virtual drive" through which you access the image file.
Image files are also a great way of copying stuff; dd is handy tool in this. For example to create an image out of your USB disk (/dev/sda1) you could
dd if=/dev/sda1 of=/home/me/usbdisk.img
and then live your life and one day copy the image's contents back to the disk:
dd if=/home/me/usbdisk.img of=/dev/sda1
The operation is done to the (umounted) device (file). You can do this with CDs and pretty much anything too. Or copy directly from a stick (sda1) to another (sdb1):
dd if=/dev/sda1 of=/dev/sdb1
Note that when doing this, the target device must be exactly as big (or bigger than) as the image file is (or the device it was created out of). In case the target is smaller, it doesn't work, and if it's larger, the rest of the space is left unused (which usually means you can't use it before formatting and partitioning).
That went a little over this thread's topic..but I hope it helps. Image files are like archives, except that extra information can be stored in them, such as bootable flags etc. It is then the responsability of a program that handles the image file to acknowledge the "extra information" and deal with it.