Why an executable program for a specific CPU does not work on Linux and Windows?

19
votes

An executable problem like exe does not work on Linux (without wine). When compiling source code compiler produce object code which is specific to a particular cpu architecture. But same application does not work with on an another OS with same CPU. I know code may include instructions to specific to the OS that will prevent executable running. But what about a simple program 2+2 ? Confusing part is what the hell that machine code prevents working. Machine code specific to cpu right? If we strip executable file format could we see same machine code (like 2 + 2) for both operating systems?

One more question: What about assembly language? DO windows and Linux use different assembly language for same cpu?.

6
operating-systemexecutable
You can test the answers people have given you by compiling some simple code (int main(int argc, char** argv) {int a = 2; a += 2; return 0;} for example) on both OSs, running objdump -dS on the two .o files and comparing the asm output - you will see the differences in compiler output. - laura
@laura - true, but compiler differences would likely overwhelm the actual platform differences at that level. - codekaizen

6 Answers

19
votes

There are many differences. Among them:

  1. Executable Format: Every OS requires the binaries to conform to a specific binary format. For Windows, this is Portable Executable (PE) format. For Linux, it's ELF most of the time (it supports other types too).

  2. Application Binary Interface: Each OS defines a set of primary system functions and the way a program calls them. This is fundamentally different between Linux and Windows. While the instructions that compute 2 + 2 are identical on Linux and Windows in x86 architecture, the way the application starts, the way it prints out the output, and the way it exits differs between the operating systems.

Yes, both Linux and Windows programs on x86 architecture use the instruction set that the CPU supports which is defined by Intel.

15
votes

It's due to the difference of how the program is loaded into memory and given resources to run. Even the simplest programs need to have code space, data space and the ability to acquire runtime memory and do I/O. The infrastructure to do these low-level tasks is completely different between the platforms, unless you have some kind of adaptation layer, like WINE or Cygwin.

Assuming, however, that you could just inject arbitrary assembled CPU instructions into the code segment of a running process and get that code to execute, then, yes, the same code would run on either platform. However, it would be quite restricted, and doing complex things like even jumps to external modules would fail, due to how these things are done differently on different platforms.

5
votes

Problem 1 is the image format. When an application is launched into execution the Os has to load the applicaiton image, find out its entry point and launch it from there. That means that the OS must understand the image format and there are different formats between various OS.

Problem 2 is access to devices. Once launched an application can read and write registries in the CPU and that's about it. To do anything interesting, like to display a character on a console, it needs access to devices and that means it has to ask for such access from the OS. Each Os has a different API that is offered to access such devices.

Problem 3 is priviledges instructions. The newly launched process would perhaps need a memory location to store something, can't accomplish everything with regiestries. This means it needs to allocate RAM and set up the translation from VA to physical address. These are priviledges operations only the OS can do and again, the API to access these services vary between OSs.

Bottom line is that applications are not writen for a CPU, but for a set of primitive services the OS offer. the alternative is to write the apps against a set of primitive services a Virtual Machine offers, and this leads to apps that are more or less portable, like Java apps.

2
votes

Yes, but, the code invariably calls out to library functions to do just about anything -- like printing "4" to the terminal. And these libraries are platform-specific, and differ between Linux and Windows. This is why it's not portable -- not, indeed, an instruction-level problem.

2
votes

Here are some of the reasons I can think of off the top of my head:

  1. Different container formats (which so far seems to be the leading differentiator in this answer -- however its not the only reason).
  2. different dynamic linker semantics.
  3. different ABI.
  4. different exception handling mechanisms -- windows has SEH -- upon which C++ exception handling is built
  5. different system call semantics and different system calls -- hence different low-level libraries.
1
votes

To the second question: Windows only runs on x86, x64, and IA64 (not sure about the mobile versions). For Linux, see here.