General > General Technical Chat

Why do people call an executable file (.exe) a binary file?

<< < (5/14) > >>

Syntax Error:
Leo, historically over 50 years ago, when a human readable computer program was compiled into machine readable code, the compiler output was termed "The Binary". A computer programmer might ask the computer operator to "load and run the binary." This binary file was often held on magnetic tape or  even punched paper tape. Even today, our devices still 'load' the binary file into a process to run.

The term binary has kind of stuck around, even if the file endings are not .bin  Some other common executable binaries to mind include .sys .dll .elf and .hex files.

It's just historic, rather like how we use the term 'cloud' for the internet. Anyone care to explain why we say "the cloud"?

IanB:

--- Quote from: LeoTech on April 25, 2020, 10:47:11 am ---Do any of you guys know a compelling argument for refering to these files as binary? Because if not, let's try to stop that misconception. And just call the exectables, which in my mind is a far more correct and usefull name.
--- End quote ---

Object files and library files are binaries, but they are not executables. And as has been pointed out above, shell files and script files are executable, but they are not binaries. So there isn't a one to one correspondence between binary and executable.

A binary is a file that when opened in a text editor is not human readable.

rsjsouza:

--- Quote from: Syntax Error on April 25, 2020, 02:21:41 pm ---It's just historic, rather like how we use the term 'cloud' for the internet. Anyone care to explain why we say "the cloud"?

--- End quote ---
Just like another term that confused me in my early days of computing: print. To me it made no sense to tell the computer to "print" something on the screen - "show" or "display" made more sense in my mind, even after I was told about how the early computers used paper printers (line printers). Eventually I got over this feeling.

T3sl4co1l:
Alternate view:

It's not what it is, it's what you do with it.

Text is expected to be formatted in device-specific ways.  Excess whitespace may be omitted entirely (e.g., HTML, C, etc.), expanded (e.g., typesetting?), or translated (e.g., utilizing Unicode spaces and joiners, or stripping them as the case may be).  Control characters have specified purposes, and also may be translated or removed as needed (e.g., *nix family CR vs. DOS family CR-LF sequences).  Everything else is given specific textual representation -- i.e., the graphic letters I am presently typing.

Most of these features are implemented by operating systems, sometimes transparently (e.g., opening the CON device as a text file).  If you're writing your own, say, serial terminal / emulator, you must implement these as well (the whole point of a terminal is at least basic text formatting and control, if not full ANSI or VT100 or whatever operating modes).

Whereas, "binary" must be inscrutable and untouchable.  Any accidental change of bits or bytes in the file will likely corrupt it for its intended purpose, and it must always be transferred wholly intact.

Now, it might well be that there's a great many ways a particular binary file could be changed, while remaining equivalent in some useful way to the original.  Examples: EXIF data in JPEG and various other formats; the number and size of chunks in a PNG file; the headers and memory mapping in an EXE file; etc.  But there are so many formats out there that assuming any one of them is a bad idea.  So we just call it "binary" and keep our hands off it.

You wouldn't want your OS going in and recompressing your images willy-nilly, would you?  (Mind, a lot of hosting servers do this for you, and much more -- beware!)

So -- text can always be treated as binary, but the converse is not true.  Text implies a format so standard (i.e., ASCII) that everyone can make the same assumptions about it (printable characters, variable space, meaningful control characters, etc.).

As noted above, these definitions don't need to be exclusive.  A hex file isn't hex as such (i.e., digits restricted to 0-15, in packed or unpacked bytes say), but it's ASCII coded.  Guess I'd say hex is a subset of text, and text is a subset of general binary files.  Don't forget there's always polyglot formats -- someone's devised a plain text version of x86 machine code, what might be considered simultaneously both binary and ASCII.  (Emphasis on binary though, as almost any change in the file will likely corrupt the executable part.)

Tim

bingo600:

--- Quote from: jpanhalt on April 25, 2020, 11:42:51 am ---Here's something to ponder...

Here are a few lines from a .hex file:
[plain]
:100000002F0000EA24F0A0E340F0A0E32CF0A0E3EE
:1000100034F0A0E30000A0E1F0FF1FE5BA00A0E388
:10002000070000EAA800A0E3050000EAAE00A0E394
:10003000030000EAB400A0E304E04EE2000000EA9E
:10004000BF00A0E304E04EE280119FE50120D0E470
:10005000143091E5200013E3FCFFFF0A000052E397
:1000600000208115F8FFFF1A0850A0E39840A0E394
:100070002E0EA0E1002094E7143091E5200013E358
[/plain]

But what you are actually seeing on your monitor is ascii.  Does that make it "stupid" to call it a "hex" file?

--- End quote ---

I'd say this is an iHEX file (Intel hex format)  , but as  DOS alowed 3 letters for the file suffix ... What should they do ?

And some of us even know what a .COM file is ..  :scared:

Edit: And a .S19 file
/Bingo

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod