Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

On a compiled code standpoint what is the difference between a program compiled for one os vs another (Linux vs windows for instance). Doesn't the program run directly on the cpu? Or is it because the program needs to reference OS specific libraries?

share|improve this question

Ordinary compiled programs do "run directly" on the CPU, but a program doesn't run in a vacuum:

  1. Many programs rely on external, dynamically loaded libraries (DLLs or .so libraries). The way to link them up is up to the compiler/linker, and each OS has different standards. However, there are also "statically linked" programs that provide all their own code.

  2. A modern OS doesn't give complete control of the computer to a running program. Programs rely on "system calls" for i/o, access to hardware, and things like signals and entering a sleep state. The available services and interface are defined by the OS. The OS also controls which parts of the system (memory, registers, interrupts) the program is allowed to use.

  3. A GUI program must also work through the graphical user environment in order to draw itself on the screen. But you've probably thought about this already.

For these reasons, OS-independent applications must rely on a "virtual machine" of some sort, like the one provided by the java runtime. Crucially, a VM provides a standard interface to OS resources (i/o, signals, etc). Of course, java or python also interpret "bytecode" instead of dealing with the quirks of Intel's instruction set; but that's a different story.

share|improve this answer
In addition, different OSes have different standards for stack layout, memory alignment practices, etc, so even purely numeric/computational code may need to differ from one OS to the next. – Daniel R Hicks Jan 30 '13 at 1:49
Would these differences prevent statically compiled code from executing? Didn't know that.. – alexis Jan 30 '13 at 19:23
It's probably just a theoretical problem, since some other incompatibility would get you first. But OSes often have expectations for how stack frames are aligned, where registers are stored, etc. These may vary from one OS to the next for the same hardware architecture. You might in theory be able to RUN "foreign" code that is purely computational, but you'd never be able to get it started and never be able to end it cleanly. – Daniel R Hicks Jan 30 '13 at 20:55

Different OSes have different functionality as well. Windows has I/O completion ports, Linux does not. FreeBSD has kqueue, Linux does not. Linux has futexes, Windows does not. They also have different ways of doing the same thing -- what parameters do you pass to open a file? What order do they go in? How specifically do you invoke the operating system's "open a file" function?

share|improve this answer
ok that makes sense, but in general, does the program load into memory and run on the cpu, or does the os "have control" over the program – agz Jan 29 '13 at 23:50
@agovizer: Both. They're not mutually exclusive. Typically, the OS will set up a controlled environment and arrange for the hardware to interrupt the program in a particular amount of time and then turn the core over to the program. But as soon as the program hits any number of conditions (such as a page fault, I/O operation, or the like), the OS takes over again. – David Schwartz Jan 29 '13 at 23:52

In general, programs are not compatible due to the differences in their application binary interface (ABI).

Doesn't the program run directly on the CPU?

NO! That's the job of the operating system, to prevent applications from running "directly" on the CPU. Typically, at the lowest level (i.e. the one the OS API is built on), an application interfaces with the operating system's kernel.

Is it because the compiled program itself needs to reference OS specific libraries?

Yes. Many OS libraries are written to facilitate interfacing with the operating system itself, but there's just as many that are written to be cross-platform. These hide the low-level OS interfacing from the developer, and assumes the compiled version for that OS will be available at runtime (see below).

Although libraries can be written in a cross-platform manner, when compiled they can't be run cross-platform. They still need to be recompiled for the specific target operating system, again to utilize the particular underlying components of the operating system (kernel).

What is the difference between a compiled program for one OS vs another?

Finally, executable files themselves often contain very specific binary loading headers and so-forth (e.g. the PE Executable file format [.exe, .dll, etc...] for Windows, or ELF for Linux [none, .o, .so, etc...]). These can also include code to load the compiled OS-specific binaries for a particular software library.

Lastly, from a programmer's perspective: calling convention. Compiled code passes variables to functions in a given manner (i.e. through registers, or on the stack) in a very particular order. Even then, it also needs to be agreed upon who's responsible to "clean up" function calls (the caller or the callee?). Although there are several standard and widely used x86 calling conventions, some may not be supported by certain operating systems (this is part of the ABI).

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.