POSIX and the POSIX API

Imagine a dozen carmakers who all decided, by agreement, that the brake pedal goes on the right, the gas in the middle, the wheel turns the same way. Cars still differ wildly under the hood, but a driver who learned on one can sit in any of them and drive. POSIX is that agreement for Unix-like operating systems: a published standard for what the interface to the OS should look like, so a program written to it can run on many systems.

POSIX stands for Portable Operating System Interface, and it is a formal standard that specifies the names, arguments, and behavior of a core set of operating-system services as seen by a C program - functions like open(), read(), write(), fork(), and pthread_mutex_lock(), plus shell behavior and command-line utilities. The POSIX API is that defined collection of function signatures and their promised behavior. Crucially, POSIX standardizes the interface, not the implementation: Linux, macOS, the BSDs, and others each implement POSIX their own way internally, but they agree to expose the same calls with the same meaning. Linux in particular is largely POSIX-compatible, which is why so much Unix software builds and runs across these systems with little or no change.

Why it matters: POSIX is the practical reason a single body of C systems code is portable across Unix-like platforms. If you stick to POSIX-specified functions, you can reasonably expect your program to compile and behave the same on Linux and macOS. Step outside POSIX into a system's own extensions and you trade portability for whatever that platform uniquely offers. Note the honest limits: POSIX is a large standard with optional parts, real systems implement it imperfectly and add non-standard extras, and Windows is not natively POSIX - so 'POSIX-compatible' is a useful expectation, not an ironclad guarantee.