questions about BIN files ?

[SmartBoy]

Hello

i have very bigenner question , is this right when i boot to my OS i can switch only (BIN) files ? ::)

[Kemp]

It depends what bootloader you use. It is common for people to use bin files as you don't need to make any changes to it before jumping to it (though you do have to make sure it is linked correctly). Loaders such as Grub can also load various other formats (I believe ELF is in the list, but I don't use it myself), if you write your own loader then you can support any format you want, though you'll have to read up on the formats to see what sort of address fixing they need and etc.

[AR]

Loaders such as Grub can also load various other formats (I believe ELF is in the list, but I don't use it myself)

IIRC, ELF is the only format GRUB supports, a.out/flat binary/anything else all require the "a.out kludge", GRUB can load ELF directly with only the flags header present. (Note that I'm excluding the "hack boots" like Linux, *BSD, chainload, etc)

[Pype.Clicker]

there are plenty of bootloader that all have different expectations. Some want MS-DOS .EXE files, other wants flat binaries (and have a long list of conditions those flat binaries should met), other want the "multiboot header" with a.out kludge, other want ELF files ...

The only thing that is certain is that if you load one of those "format" (PE, COFF, MZ, ELF, etc.) raw in memory and jump to the first byte of the file (or even to the first byte of the init() function), you're very unlikely to run the executable successfully.

See Executables file types on the FAQ for further enlightenment ...

[Colonel Kernel]

A slightly left-field question... Why is the a.out kludge called a "kludge"? From the way I read the Multiboot specification, it sounds like the proper way to do things. IMO, it's kinda silly to force ELF down everyone's throats... I'd rather save a few KB in my kernel image.

[AR]

It's called a kludge in the GRUB source code, IIRC one of the manuals refers to it like that as well, or at least an earlier version.

Code: Select all

struct multiboot_header
{
  /* Must be MULTIBOOT_MAGIC - see below.  */
  unsigned magic;
  
  /* Feature flags - see below.  */
  unsigned flags;
  
  /*
   * Checksum
   *
   * The above fields plus this one must equal 0 mod 2^32.
   */
  unsigned checksum;
  
  /* These are only valid if MULTIBOOT_AOUT_KLUDGE is set.  */
  unsigned header_addr;
  unsigned load_addr;
  unsigned load_end_addr;
  unsigned bss_end_addr;
  unsigned entry_addr;

  /* These are only valid if MULTIBOOT_VIDEO_MODE is set.  */
  unsigned mode_type;
  unsigned width;
  unsigned height;
  unsigned depth;
};

(Note: Above is copyright, GPL to FSF)

The definition of "kludge" is an "unelegant implementation", the executable format's headers should contain the information about how to load the program but presumably it is called a kludge because GRUB doesn't actually know how to read the headers (eg. PE, COFF), or the headers don't give enough information (eg. flat binary).

[Colonel Kernel]

The definition of "kludge" is an "unelegant implementation", the executable format's headers should contain the information about how to load the program but presumably it is called a kludge because GRUB doesn't actually know how to read the headers (eg. PE, COFF), or the headers don't give enough information (eg. flat binary).

That's my point... In the case of a flat binary, there is no header. Or rather, the "a.out kludge" is the header, and a small & tidy one at that. Seems elegant enough to me.

Maybe I just object to the header of my kernel image being called a "kludge".

[Brendan]

Hi,

IIRC, ELF is the only format GRUB supports, a.out/flat binary/anything else all require the "a.out kludge", GRUB can load ELF directly with only the flags header present. (Note that I'm excluding the "hack boots" like Linux, *BSD, chainload, etc)

GRUB will also handle flat binary files without any problems, as long as it can find the multi-boot header. For a (slightly twisted) example see http://bcos.hopto.org/src/boot/grubboot/0init-asm.html - a flat binary file written in NASM that relocates itself and returns to real mode.


Cheers,

Brendan

[AR]

GRUB will also handle flat binary files without any problems, as long as it can find the multi-boot header.

IIRC, ELF is the only format GRUB supports, a.out/flat binary/anything else all require the "a.out kludge", GRUB can load ELF directly with only the flags header present. (Note that I'm excluding the "hack boots" like Linux, *BSD, chainload, etc)

Additional emphasis in bold, ELF does not need the load start, load end, bss length or entrypoint fields, GRUB will get that information directly from the ELF headers making it the only executable format supported directly.

[Brendan]

Hi,

@AR: Sorry - didn't realise that the multiboot header is the "a.out kludge" everyone was talking about .

I guess that's what happens when you ignore GRUB's documentation and use the "Multiboot specification" instead (see http://orgs.man.ac.uk/documentation/grub/multiboot.html).

Specifically (from http://orgs.man.ac.uk/documentation/gru ... .html#SEC7):

Multiboot-compliant OS images always contain a magic Multiboot header (see section 3.1 OS image format), which allows the boot loader to load the image without having to understand numerous a.out variants or other executable formats.

IMHO (as GRUB is meant to be a multiboot compliant bootloader), this makes the "a.out kludge" standard while GRUB's ELF support should be considered an "ELF kludge" ;D...


Cheers,

Brendan