OS and Programming Language

Login to a Linux system and look at /usr/include/sys. That should tell you all you need to know.

OSes don't have anything to do with source code or vice versa, basically. OSes are only used to make your computer hardware 'perform' a task, be it save a file, load a program (coding language), transmit a email, etc. OSes take the COMPILED coded program that is for THAT OS and uses it to 'perform' what it is programmed for.

When you code, it all depends at what level and coding language are you are using to what level your outputted source code is saved to. If you don't (for example) use .NET Framework to help COMPILE the code properly, then it wouldn't work with Windows based OSes as that is a interpreter for multiple coding languages (Fortran, Pascal, etc. etc.). But if you do it all in Binary or near binary, then your talking that it can then be recoded / recompiled into multiple OSes.

Any time that an application wishes to do anything that involves shared system resources it must make a system call to do so. The system call elevates the context's privilege to that of the kernel and jumps to the appropriate routine for handling the system call; once handled, the privilege de-elevates back to that of the caller and returns to the caller's code.

Programmers rarely need to drill down into the details of system calls, these are abstracted by the programming language's libraries.
User-mode programs that are written in C or C++ are linked at load time against the C standard library and/or C++ standard library (it's possible to compile most valid C programs using a C++ compiler, but it's also possible to link compiled C and compiled C++ with a little bit of work). On rare occasions these libraries may be compiled into the program itself (monolithic binary), but most of the time the program will link to versions of these libraries that ship with the application or are provided by the system. It is the responsibility of the library maintainer to create a relation between the portable behaviour of the standard libraries and the behaviour of the operating system.
For example, the stdio.h component of the C standard library (cstdio for C++) handles IO streams that can be used for file and console manipulation. The function fopen() is used to [try to] open a file for some operation. On POSIX platforms such as Linux, the fopen() function internally wraps the open() system call. If you're familiar with C you'll notice that fopen() returns a pointer to a FILE structure, while open() returns a file descriptor (a handle, implemented as an integer). Take a look at the FILE structure defined in stdio.h, you'll see that there's a location for a file descriptor in the FILE structure itself. This is due to the fact that the program-facing IO functions abstract the system-specific function calls which allow those portable IO functions to be realized; this abstraction allows the C and C++ standard libraries to behave in the same fashion regardless of what operating system the program is being compiled for.
Note that it is possible to make many system calls directly (some such as open() are implicitly defined in C, but they're nothing more than enumerations so it's just a matter of looking at the OS documentation). An enterprising programmer would be capable of writing a functioning program without linking against the C or C++ standard libraries. In this case the programmer would have to make the system calls manually, as well as implement all wrapping behaviour.
In the case of non-language-standard libraries and system libraries (eg unixstd, pthread, anything in /usr/include/sys) the behaviour of the programming interface is typically more tightly coupled to that of the operating system. Despite this, the program still needs to make a system call to perform any function that it doesn't have permission to do on its own.