Why Executable files are OS Dependent

In this article, we will discuss Why Executable files are OS Dependent and will discuss the reason in detail. And will also discuss approaches to increase compatibility. Let’s discuss it one by one.

Why Executable files are OS Dependent :
Both the OS and the CPU are required for the execution of executables as follows.

• The CPU decodes the binary instructions in the executable according to one or more instruction sets. The x86 (“32bit”) and AMD64 (“64bit”) instruction sets are supported by the majority of consumer CPUs. It is possible to compile a program for one of these instruction sets, but not both. Extensions to these instruction sets are available, and support for them can be checked at runtime.
• SIMD support is one example of such an expansion. If these extensions are present, optimizing compilers may try to make use of them, but they usually also provide a code path that works without them.
• System APIs: The program may make use of libraries that must be installed on the target system. Software that uses Windows API functions cannot be run on Linux. In the Unix world, the central operating system APIs have been standardized to POSIX: a program written entirely with POSIX functions will operate on any Unix system that supports them, including Mac OS X and Solaris.
• Binary Format: The executable must follow a specific binary format in order for the operating system to load, initialize, and launch the program correctly. The Portable Executable format is widely used on Windows, while ELF is widely used on Linux.

Outcome :
As a result, if two systems have the same system APIs and libraries, run on the same instruction set, and utilize the same binary format, a program was written for one will run on the other.

There are, however, approaches to increase compatibility :
x86 executables are routinely run on AMD64 instruction sets. The binary format specifies which mode should be used. The operating system must put forth an extra effort to handle both 32bit and 64bit apps. Some binary formats allow many copies of a program to be stored in a single file, each coded for a different instruction set. Apple advocated the use of “fat binaries” as they transitioned from the Power-PC architecture to the x86 architecture.

• Some programs are compiled to an intermediate form rather than machine code. This is then turned into actual instructions on the fly, or it may be understood. This allows a program to be independent of its architecture. On the UCSD p-System, this method was utilized.
• A 64-bit CPU is found in 99 percent of modern Windows PCs, which can also execute 32-bit software. The remaining 1% uses 32-bit CPUs. As a result, software written for 32-bit CPUs is widely used. Software designed for 64-bit processors runs on any PC that the software’s designer cares about.

Note –
An executable file contains more than just raw machine code. When the OS loads it, it reads this and determines how it should run. When you compile, you usually specify a target CPU; if you don’t, the compiler will use your current CPU and limit itself to only selecting instructions that are common to your CPU and older versions of it. If you want to use a fancy new instruction that is only available on a specific revision of your target CPU, you can either tell the compiler or manually code it using intrinsic or inline assembly code. However, if you run your program on a CPU that does not support that instruction, it will crash.