Why is software OS specific?

user139929 asks:

I'm trying to determine the technical details of why software produced using programming languages for certain operating systems only work with them.

It is my understanding that binaries are specific to certain processors due to the processor specific machine language they understand and the differing instruction sets between different processors. But where does the operating system specificity come from? I used to assume it was APIs provided by the OS but then I saw this diagram in a book.

As you can see, APIs are not indicated as a part of the operating system.

If for example I build a simple program in C using the following code:

#include

main()
{
printf("Hello World");

}

Is the compiler doing anything OS specific when compiling this?

System calls are OS specific

Charles E. Grant answers (44 votes):

As you can see, APIs are not indicated as a part of the operating system.

I think you are reading too much into the diagram. Yes, an OS will specify a binary interface for how operating system functions are called, and it will also define a file format for executables, but it will also provide an API, in the sense of providing a catalog of functions that can be called by an application to invoke OS services.

I think the diagram is just trying to emphasize that operating system functions are usually invoked through a different mechanism then a simple library call. Most of the common operating systems use processor interrupts to access OS functions. Typical modern operating systems are not going to let a user program directly access any hardware. If you want to write a character to the console, you are going to have to ask the OS to do it for you. The system call used to write to the console will vary from OS to OS, so right there is one example of why software is OS specific.

printf is a function from the C run time library and in a typical implementation is a fairly complex function. If you search on Google you can find the source for several versions online. (See this page for a guided tour of one.) Down in the grass though it ends up making one or more system calls, and each of those system calls is specific to the host operating system.

Related: Understanding the levels of computing

Different OS, different programs

Adam Davis answers (7 votes):

From another answer of mine:

Consider early DOS machines, and what Microsoft's real contribution to the world was: Autocad had to write drivers for each printer they could print to. So did Lotus 1-2-3. In fact, if you wanted your software to print, you had to write your own drivers. If there were 10 printers, and 10 programs, then 100 different pieces of essentially the same code had to be written separately and independently. What windows 3.1 tried to accomplish (along with GEM, and so many other abstraction layers) is make it so the printer manufacturer wrote one driver for their printer, and the programmer wrote one driver for the windows printer class. Now with 10 programs and 10 printers, only 20 pieces of code have to be written, and since the Microsoft side of the code was the same for everyone, then examples from MS meant that you had very little work to do. Now a program wasn't restricted to just the 10 printers they chose to support, but all the printers whose manufacturers provided drivers for in windows. So the OS provides services to the applications so the applications don't have to do work that is redundant.

Your example C program uses printf, which sends characters to stdout—an OS specific resource that will display the characters on a user interface. The program doesn't need to know where the user interface is—it could be in DOS, it could be in a graphical window, it could be piped to another program and used as input to another process.

Because the OS provides these resources, programmers can accomplish much more with little work.

However, even starting a program is complicated. The OS expects an executable file to have certain information at the beginning that tells the OS how it should be started, and in some cases (more advanced environments like android or iOS) what resources will be required that need approval since they touch resources outside the "sandbox"— a security measure to help protect users and other apps from misbehaving programs.

So even if the executable machine code is the same, and there are no OS resources required, a program compiled for Windows won't run on an OS X operating system without an additional emulation or translation layer, even on the same exact hardware.

Early DOS style operating systems could often share programs, because they implemented the same API in hardware (BIOS) and the OS hooked into the hardware to provide services. So if you wrote and compiled a COM program—which is just a memory image of a series of processor instructions - you could run it on CP/M, MS-DOS, and several other operating systems. In fact you can still run COM programs on modern windows machines. Other operating systems don't use the same BIOS API hooks, so the COM programs won't run on them without, again, an emulation or translation layer. EXE programs follow a structure that includes much more than mere processor instructions, and so along with the API issues it won't run on a machine that doesn't understand how to load it into memory and execute it.

Find more answers or leave your own answer at the original post. See more Q&A like this at Programmers, a question and answer site for professional programmers interested in conceptual questions about software development. If you've got your own programming problem that requires a solution, log in to Programmers and ask a question (it's free).