Talk:Comparison of executable file formats

new columns

The table here could use columns indicating which formats support executable files, which support relocatable files, and which support shared libraries. Unfortunately, doing so would seem to require introducing pages to describe these concepts and there's already a page for "relocatable object module" which is being used for something else. Sorting this out is beyond my wikipedia skills right now and I can't even get a login assigned so... <rich@noir.com>

Another suitable column would be "explicit addressing" or some such. By which I mean, a.out had implied addresses for load address, address alignment, and in some cases start address. One of the benefits that COFF brought was the ability to create executables that could be aligned, loaded, and/or started at arbitrary addresses. This is critical to creating things like stand alone executables which are a virtual requirement of embedded work. Elf, mach-o, and the coff derivatives all support this. A.out does not. I can't speak to the others. <rich@noir.com>

linux vs formats

Linux can support many object file formats for various special purposes. Scratchbox is a cross development system wherein a linux kernel is taught to execute a foreign format, perhaps even a foreign processor through the use of qemu. The result is the illusion of a native foreign system running on a host linux box. This can be used for cross development. However, I don't think any standard Linux distribution comes with these facilities standard. <rich@noir.com>

Linux can also still support a.out if configured to do so. <rich@noir.com>

neither of which are of any interest with respect to this article since it is as simple comparison of executable file formats. — Preceding unsigned comment added by 80.162.60.16 (talk) 23:52, 31 October 2011 (UTC)

Operating System Support?

I'm not sure about the others but I think Linux can run Amiga binaries in addition to ELF. —Preceding unsigned comment added by 112.200.149.249 (talk) 11:45, 8 October 2009 (UTC)

Icon?

What does the "Icon" column mean? An executable image on OS X is displayed with a particular icon, although, as executable images on UN*Xes don't normally have a suffix, the choice of icon is based on whether the file has execute permissions (given the way UN*X command-line interpreters work, any file with execute permissions can be run from the command line, although if it's neither an executable image nor a script in some language that the shell can interpret nor a script with a #! line, the attempt to execute it will probably not produce useful results), so an executable script has the same icon. In GNOME, the icon is determined not only by the file suffix but by a quick examination of the file contents, so executable images and scripts have different icons. Guy Harris (talk) 08:05, 28 August 2010 (UTC)

It indicates whether the file format has built-in support for icons. PE32 on Windows are executables that can have an icon that represents the application. -- Frap (talk) 14:12, 28 August 2010 (UTC)

Thanks. I changed the column title to clarify that. Guy Harris (talk) 20:15, 28 August 2010 (UTC)

I think "can contain" is a bit superfluous, as it doesn't say can contain metadata, can contain digital signature, etc. -- Frap (talk) 00:38, 29 August 2010 (UTC)

And I (obviously) think "Icon", by itself, is a bit insufficient, as it says nothing about what the column has to do with icons (otherwise, I wouldn't have asked the initial question in the first place!). And, yes, I think "can contain metadata" is arguably a better title than just "metadata", and "can contain digital signatures" might be better than "digital signature", too. Guy Harris (talk) 06:32, 29 August 2010 (UTC)

"can contain" could be added to all fields, but then the table would get pretty wide. Frap (talk) 15:13, 29 August 2010 (UTC)

Could you explain, how is the "icon" stored in PE? If it's just an other section, like, say, .data.icon, you could do the same with ELF, and most other formats as well. The problem's just with the file managing software that would need to be taught about the feature.AlexeyZaytsev (talk) 14:20, 27 March 2011 (UTC)

The PE format can contain arbitrary resources (which are distinct from sections/segments - more like the resource forks on the old HFS file systems), which are accessible both from code and external inspection. Icons are just a particular type of resource, and the shell understands how to parse the file to look for the first icon image in the file. The column would far better be titled "Resource Storage" because "Icon" equally applies to "Bitmap", "Version Info", "Localisable String Table", etc. Strictly speaking, this is a proper subset of "Metadata". Ozthrox (talk) 03:50, 26 August 2016 (UTC)

The others than?

What about for example

bin exe so —Preceding unsigned comment added by 90.227.53.176 (talk) 14:43, 26 October 2010 (UTC)

Bin just means binary. Exe is a file extension not a file format, it is used by PE and MZ. -- Frap (talk) 16:43, 26 October 2010 (UTC)

so is also just a file extension usually used for shared objects (libraries) on UNIX like operating systems 80.162.60.16 (talk) 13:01, 1 December 2011 (UTC)

Supported binaries?

I think this article should have a table of supported binaries for each executable format. Dread Lord CyberSkull ✎☠ 09:39, 29 December 2011 (UTC)

What you mean? Give an example. Feel free to contribute. -- Frap (talk) 21:40, 29 December 2011 (UTC)

Missing information

There are two major glaring omissions from this table. The first, which has been alluded to in previous comments (though possibly not clearly) is extensions/file-types. For example, the Windows/DOS file type ".EXE". Other extensions I've seen are ".com", ".bin", ".cmd", as well as scripting such as ".bat" or ".sh"

The other glaring omission is which executable types are supported under which operating systems. — Preceding unsigned comment added by 173.228.6.181 (talk) 21:27, 24 February 2013 (UTC)

Only executable images, or also object files, non-archive libraries, etc.?

Almost all, if not all, Un*x "executable" file formats are used for object files as well as executable files, and some are also used for core dumps.

Also, on most Un*xes and on Windows, "executable" code can be in a library that's loaded into the program at start-up time or a plugin that's loaded into the program at run time (and, for kernel mode code, in a loadable kernel module, which could be thought of as the kernel-mode version of plugins loaded into the program at run time).

Given that, should the page note that, and should it include suffixes such as .o, .dll, .sys, .so, and .dylib, as file extensions for some of these file formats? Guy Harris (talk) 21:46, 14 July 2013 (UTC)

Hi. I say just executable files. No library, module, plug-in, snap-in, add-in, COM object, service, driver, hook or anything else. Including those will result an endless list in which two randomly selected items do not even remotely resemble eachother. WP:IINFO. Best regards, Codename Lisa (talk) 22:53, 14 July 2013 (UTC)

OK, so that means no file extensions for the UN*X formats, as UN*X executables have no standard extension, and 99 44/100% of UN*X executables (yes, even the ones in OS X application bundles) have no extension at all (the top-level directory of an OS X app bundles has .app, but the executable image under Contents/MacOS has none). Guy Harris (talk) 23:15, 14 July 2013 (UTC)

Hi. Passing over the filename extensions, I was thinking there are still valid executable formats that we can add; files that run directly and contain machine code. I mean like .NET Framework, Java, Symbian OS, etc. (Android is same as Linux?) Or am I missing something? Best regards, Codename Lisa (talk) 01:14, 15 July 2013 (UTC)

For .NET and Java, there are probably good arguments on both sides. The executable page says

... These instructions are traditionally machine code instructions for a physical CPU. However, in a more general sense, a file containing instructions (such as bytecode) for a software interpreter may also be considered executable; even a scripting language source file may therefore be considered executable in this sense. The exact interpretation depends upon the use; while the term often refers only to machine code files, in the context of protection against computer viruses all files which cause potentially hazardous instruction execution, including scripts, are conveniently lumped together.

so it doesn't make a definitive statement.

For Symbian OS, this page seems to indicate that Symbian OS 9 uses a format called "E32image", with E32image files generated from ELF files. Sadly, the "my previous article" link on that page, which he claims describes the pre-OS 9 format, "links" to a file: URL and thus doesn't actually work. In any case, Symbian OS binaries, as far as I know, contain directly executable code, and would qualify as an executable file format regardless of whether bytecode is considered "executable" or not.

For Android, Dalvik code is bytecode in "Dalvik Executable" format; I assume (possibly incorrectly) that native development kit binaries are ELF, given that Android uses the Linux kernel. Guy Harris (talk) 19:59, 15 July 2013 (UTC)

Entries that make no sense

Hi.

Some of the table entries in Explicit processor declarations make no sense to me at all. For example, P3 entry reads: Unknown (386 and higher). Does that mean the existence of EPD on 386 and higher is known? Or is it supposed to have been {{yes}} (386 and higher)?

How about Flex OS 186? It's entry reads: {{No}} (186/188 and higher only). Does it mean it is no supported on 186? If that is so, I see a lot of other entries beside 186 in the OS column. So, shouldn't it have been {{Partial|Yes, except on 186 or higher}}?

And what is the deal with "Yes by file" and "Yes by section"?

Best regards,
Codename Lisa (talk) 14:27, 10 October 2013 (UTC)

"Yes by file" and "Yes by section" means that these executable files contain headers with explicit processor declarations for either the whole file or only for certain sections in that file (many executable file formats are multi-partite files). Based on its own nature, the loader in the operating system will check the declarations and only load those files or sections in there which are supposed to be used in that environment, and if none can be found, it will return some error instead of executing the code. Files allowing explicit declarations by sections allow for fat binaries, which can be run under multiple types of processors. (Fat binaries are also possible with executables with file-wide declarations (or no declarations at all), but it is much more tricky for them.)

As you mentioned, there are several file format entries declaring no explicit target processor types as indicated by "No". Nevertheless the code in them is still meant to be run on a specific platform only. As an example, .186 executables for FlexOS use instructions for 80188/80186+ processors, and therefore cannot be run on 8088/8086 machines (most of them would work on NEC V20/V30 as well, but this isn't guaranteed). However, the .186 file format is a variation and extension of the CP/M-86 .CMD executable file format and does not contain any explicit processor declarations. That is, if you would rename a .186 file into .CMD, an 8088/8086-based operating system recognizing .CMD executable files might try to execute the code and crash because it has no means to rule out the executable as incompatible beforehand. Same for .286 files, which contain instructions for 80286+ processors, but still come without any explicit processor declarations. Some of these executables may contain some processor type detection code in their init in order to gracefully return to the OS if run on the wrong platform (in very rare cases even for several different platforms by utilizing tricky opstring superposition as often used in fat binary inits), but this is not a requirement, either.

Regarding P3 files, I may be able to look up, if these files contain explicit processor declarations or not, but out of the back of my head I do not remember if they do or don't, therefore "unknown". In either case, the executable code contains 386+ instructions and therefore will not run on 286 or earlier processors. That's why it states "(386 and higher)".

Hope it helps --Matthiaspaul (talk) 15:14, 10 October 2013 (UTC)

ELF signing

Maybe more needs to be written about code signing, for ELF and other formats. There are several systems for signing ELF object files, and the reference leads to a less-known one: a single open-source project called "elfsign". Note that this "elfsign" is not related to or does not even have the same parameters as the more well-known "elfsign" tool on Solaris. I know also of "signelf" and "DigSig" for Linux, but there may be more for various Unix systems. I think also Linux has a system for signing kernel modules. Johan Hanson (talk) 15:11, 18 January 2018 (UTC)