Executables and the operating system

[DwithQs]

Hello,

I am curious about compiled. executable computer programs. That can be in any format, EXE, ELF, etc. I am not referring to IL code or Bytecode, but files that are considered to be in "Native" code or "Binaries".

Are executable files in a format intended for use by the OS or by the CPU? I know executable files are not portable from one OS to another, so I am assuming that an executable really isn't machine code, but is instead code meant to be interpreted by an OS and formed into machine code. Otherwise, is there a combination of OS level interpreted code and actual machine code in an executable file?

I'm also curious of how you could go about issuing actual commands to a CPU from inside of an OS, or is that impossible and always up to interpretation by the OS?

 

[jtbell]

Consider a program that asks for some input from the user, reads that input, does some calculations, and then displays the results or writes them to a file.

The binary code for the calculations depends on the type of processor being used, and in principle at least, does not depend on the operating system. However, all the input and output goes through the operating system, via calls to subroutine libraries that are part of the OS. So that stuff depends on the OS.

In the early days of computers, you could access input and output devices by writing data to specific memory locations, and/or executing specific machine-language instructions, but those days are long gone, at least for general-purpose computers. Maybe it's still done with small processors that are embedded into hardware systems.

 

[rcgldr]

Are executable files in a format intended for use by the OS or by the CPU?

This depends on the OS and CPU. For Windows / Intel, an executable file contains some tables used by the OS, data sections and code sections. The code sections contain mostly machine language code left unmodified unless there's an addressing conflict (this normally only happens when using DLLs (dynamic link libraries)). Example wiki article:

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

 

[harborsparrow]

A native executable file does contain machine code, but it is packed in a way that the linking loader (which is arguably a part of the operating system) can figure out how to create a process (that is load the program into memory, initialize it's variables, and schedule a thread of code to start executing). So the .exe file, just for example, is input to the linking loader, which "interprets" its "instructions" in order to create a process and start it running. The "code" inside the executable file is the instructions for the linking loader. The "data" inside the executable file is the machine code for the program you wrote.

 

[harborsparrow]

It is difficult to find, but if you can find it, read the documentation for the operating system's linking loader. I figured this all out, once a long ways back, by spending a few days wrestling to understand the linking loader documentation for UNIX. It solved a thousand mysteries. I'm sure it's still very similar for Linux, and somewhat different for Windows, but the basic principles still apply. A native executable file is input to a loader program, whose job it is to create a process and schedule it for execution (with the code to the executed). Hope this helps.

 

[d3mm]

In the early days of computers, you could access input and output devices by writing data to specific memory locations, and/or executing specific machine-language instructions, but those days are long gone, at least for general-purpose computers. Maybe it's still done with small processors that are embedded into hardware systems.

It's called "direct to metal" or coding "close to the metal". As you say it has fallen out of favour with PC developers but it's certainly alive and kicking on game consoles (they all have the same hardware) and embedded devices. I think there's a couple of PC game studios that live close to metal, Crytek for example. The reason it's not liked on PC is that you'd do it for graphics performance but they all have different graphics cards. Having said this I have seen some very dirty hacks used to save power on mobile devices and there's increasing crossover between mobile and desktop code.