45

I understand that each CPU/architecture has it's own instruction set, therefore a program(binary) written for a specific CPU cannot run on another. But what i don't really understand is why an executable file (binary like .exe for instance) cannot run on Linux but can run on windows even on the very same machine.

This is a basic question, and the answer i'm expecting is that .exe and other binary formats are probably not Raw machine instructions but they contain some data that is operating system dependent. If this is true, then what this OS dependent data is like? and as an example what is the format of an .exe file and the difference between it and Linux executables?

Is there a source i can get brief and detailed information about this?

Mohamed_Ezz
  • 453
  • 4
  • 5
  • 4
    Who says they can't? Windows binaries run on Linux and Mac with help from Wine. Also you might have to compromise on the brief *and* detailed requirement. – David Heffernan Mar 29 '11 at 18:56
  • Actually it usually can with a compatibility layer such as WINE. The issue is at least twofold: file format and interfaces to the operating system. The latter tends to be the bigger problem. For example an ELF file from a BSD system will not run on a Linux system, although the other way it can run (depending on some factors) through a compatibility layer that maps the system calls. – 0xC0000022L Mar 29 '11 at 18:59
  • First, thanks a lot for your answers. My question was why they do not work (without any workarounds), but since you've mentioned WINE and after knowing the answers, i have to ask the obvious question : If we can run .exe on Linux using WINE, then it should be practically possible to have a program that converts from .exe file to Linux executable FILE (and i suppose vice versa). This can be done by an easy direct mapping of instructions/system calls/file structure. So do we have such conversion programs? – Mohamed_Ezz Mar 31 '11 at 13:48
  • Linux specific version: http://stackoverflow.com/questions/1030238 – Ciro Santilli OurBigBook.com May 23 '15 at 13:41
  • Telling windows executables can run on Linux using WINE is like telling Commodore instructions can run on Windows using a fully fledged emulator imitating every function of Commodore hardware inside Windows. – upperdim Feb 04 '21 at 06:42

6 Answers6

23

In order to do something meaningful, applications will need to interface with the OS. Since system calls and user-space infrastructure look fundamentally different on Windows and Unix/Linux, having different formats for executable programs is the smallest trouble. It's the program logic that would need to be changed.

(You might argue that this is meaningless if you have a program that solely depends on standardized components, for example the C runtime library. This is theoretically true - but irrelevant for most applications since they are forced to use OS-dependent stuff).

The other differences between Windows PE (EXE,DLL,..) files and Linux ELF binaries are related to the different image loaders and some design characteristics of both OSs. For example on Linux a separate program is used to resolve external library imports while this functionality is built-in on Windows. Another example: Linux shared libraries function differently than DLLs on Windows. Not to mention that both formats are optimized to enable the respective OS kernels to load programs as quick as possible.

Emulators like Wine try to fill the gap (and actually prove that the biggest problem is not the binary format but rather the OS interface!).

Alexander Gessler
  • 45,603
  • 7
  • 82
  • 122
  • 14
    But Wine is not an emulator! – mike3996 Mar 29 '11 at 19:03
  • So program logic is fundamentally different between platforms? The kernel doesn't just manage threads and pass instructions to the cpu? Does this have anything to do with why ascii text files are formatted slightly differently? Maybe this is an example of OS dependent libraries? So many questions. sorry – GPSmaster Oct 21 '12 at 03:37
5

.exe and other binary formats are [definitely] not Raw machine instructions but they contain some data that is operating system dependent.

what this OS dependent data is like? and as an example what is the format of an .exe file and the difference between it and Linux executables?

Well, I guess Google failed you utterly. .EXE formats are very well-defined by Windows documentation.

http://support.microsoft.com/kb/65122

The Linux ld application loads an executable into memory prior to "exec" to that file. You could read up on ld format or even the famous a.out file.

http://linux.die.net/man/1/ld

http://en.wikipedia.org/wiki/A.out

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

S.Lott
  • 384,516
  • 81
  • 508
  • 779
5

Apart from the executable format that must be recognized by the system loader (i.e. that part of an OS that brings the executable into memory) the real problem is the interface to the OS. You can think of an OS as a kind of API that provides entry points one must call for doing specific things, like for example, writing a character to the console.

These details are usually more or less hidden from the end user, so that you can achieve writing a character to the screen with the same source code in higher level languages. But often, things are more different, like for example the Windowing environment. Not all high level languages provide a windowing layer that abstracts even over those differences.

Ingo
  • 36,037
  • 5
  • 53
  • 100
3

A very naive answer:

  1. Their structure are different because of different process loaders;
  2. The use os-dependent features like syscalls, which vary from OS to OS.
user237419
  • 8,829
  • 4
  • 31
  • 38
khachik
  • 28,112
  • 9
  • 59
  • 94
3

I can't comment too much on *nix but yes, the code part of the binary is typically happy to run on either environment, but it is the OS that places certain demands on the binary. In windows you should read up on PE Headers.

The second part is simply up to the developer, many times the code part will reference libaries that are OS specific - which is why you can have both portable and non-portable C++ code before being compiled into a binary.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
Stephen Bailey
  • 1,931
  • 13
  • 20
1

Programs need to know how to invoke operating system services. How this is done depends on the operating system: some use interrupts, some use the x86 lcall instruction, some (notably Windows) have distinguished shared libraries and don't document how to directly invoke services. Old 680x0 Macs and some other 680x0 operating systems used a reserved instruction set area and trapped the resulting "invalid CPU opcode" exception. Moreover, even when the mechanism is the same, the order and argument format of system calls differs between operating systems (and sometimes different versions of the same operating system; see stat() in the Linux kernel for an example of an interface that has changed several times).

There is some ability to deal with other operating systems' conventions: FreeBSD has the "linuxulator" which handles the Linux-specific kernel interface, NetBSD similarly has emulators for the system call formats of other operating systems using the same hardware (say, Ultrix on MIPS or OSF/1 on Alpha), Linux used to have iBCS2 to handle the UnixWare/SCO Unix kernel interface, Wine provides replacement shared libraries and a binary loader for PE-style Windows executables. (I don't recall if Wine also supports OS/2-style LX .exes; it probably does handle original format .exe; and then there's .com which is a raw memory dump with a header slapped on.) Even so, there is always some format that uses different conventions, and sometimes the conventions are similar enough to require hints to the OS as to how to deal with it. (See bless on FreeBSD, for example.)

geekosaur
  • 59,309
  • 11
  • 123
  • 114