Are compiled programs actually in true binary?

For example, when I compile a C application is the outputted file read as binary or does the OS then interpret the compilation? Is the "machine language" pure binary?

EDIT: Yes, everything on a computer is pure binary. Im asking if the processer directly interprets the file outputted by 开发者_运维百科the compiler or does the OS process it first?

A compiled program usually contains a header followed by the actualy CPU instructions (what you might call "binary") + various other data.

When you try to tell the OS to load your program the header will be read by the OS, and it is used to check that the executable file is really an executable file meant for this OS and this architecture. I.e. so that you don't accidentally run a Linux program on Windows or similar.

The header also contains various other bits of information on where the actual CPU instructions are located in the exeutable file, where data segments (text, strings, graphics) are located and so forth.

Once the OS is happy that the executable file is what it's supposed to be, then the OS will load the different segments from the executable file into memory and instruct the CPU to start running the "binary" code segment. This code is "pure" in a sense that it is straight CPU assembly code.

However the operating system can sill interrupt the CPU (for example to switch to another program, or just kill the program from memory and so forth). So there are a lot of things going on around this running program, and the OS kind of "manages" it and makes sure it behaves like a nice boy, but the code itself when it is running is executing pure CPU instructions as fast as possible..without the OS having to interpret the code in between.

Also note that the running program may call the OS in various ways while it is running. For example to request the OS to open a window on the display, open a network connection, allocate memory, and so forth. All that actually is happening is that the CPU just jumps to executing code at a different location (i.e. it jumps from running the code in the executable, to running some piece of code in the OS, and then jumps back).

That's it in a nutshell. There are many other ways to run programs though. There are virtual machines, interpreted languages (like Java or Ruby for example), and so forth. And they all run programs in different ways from the traditional "pure binary" languages like C/C++, but hopefully this helped you understand how it works a bit better.

I think what you're really asking is, do compiled programs run on bare metal (do they execute independent of the OS). The very short answer is, no. Although the program itself does execute native CPU instructions, the OS is capable of confining it and controlling its behavior. Furthermore, during the loading phase, certain external (dll) symbols need to be resolved. Finally most programs rely on various operating system abstractions (memory access, for example -- writing your own swap functionality is exceedingly difficult and pointless). In this sense, no binaries are not autonomous bare-metal machine code.

However they are pure binary. Everything on a computer is.

EDIT

Another way to interpret your question is: are compiled programs actually native CPU instructions. The answer is yes (aside from loading the binary, which the OS has to help with). Compilers output assembly language in which each line corresponds with exactly one CPU instruction. This is still text. The assembly is compiled by an assembler into actual binary.

What do you mean "true binary"? All data in a computer is 1s and 0s, although the CPU "interprets" the opcodes according to the layout of the internal gates and transistors. There's no platonic ideal of binary language.

Should also consider that interpreted languages have virtual machine code. (It's still in binary.) They are turned into machine code by a virtual machine, a class of software. (Also binary.)

Applications like this are generally compiled into machine code, instructions directly executed by the processor:

http://en.wikipedia.org/wiki/Machine_code

x86 ASM is one of the most common. Think of it as your code being compiled down into a very low level language. It's a layer above just 1's and 0's being sent straight along the metal if that's what you mean, and the OS still has control over what's executed. But yes, at the end of the day it all boils down to binary - everything on a PC will do!

I wonder why no one mentioned the concept of a linker.

Basically, the output of the compiler is actually a binary file, but there is a catch to this. This compiled binary file is often called an object file which contains object code. Now, don't confuse yourself here. Object Code is nothing but machine code or binary code as you call it, but only a part of it. The compiler usually outputs multiple such object files from the source of a single program. So essentially, each of these object files contain a part of the complete executable machine code for that program. This is where, the linker comes in. It basically links all these object files into a complete executable that the machine can run as a program.

• http://en.wikipedia.org/wiki/Object_file
• http://en.wikipedia.org/wiki/Object_code