The Portable Operating System Interface, better known as POSIX, is a set of standards specified by the Institute of Electrical and Electronics Engineers (IEEE). It helps maintain portability and compatibility between different operating systems.
This means that if your source code is POSIX compliant, it should be portable for any POSIX certified operating system.
What does POSIX compliance mean?
Being POSIX compliant massively reduces the time and effort required to port your application from one POSIX certified OS to another.
An OS developer needs to license their code from the IEEE Computer Society to get a POSIX trademark.
Since its inception in the 1980s, many OS like the macOS, UNIX, and Linux distros have become POSIX certified.
While others like Windows closely following the standards despite not holding a certification. Hence, developers need to familiarize themselves with POSIX.
How did POSIX become a standard in the industry?
Back in the early days, programmers created every application from scratch to suit specific computer models. As the requirement for higher-end computers increased, programmers had to continually develop operating systems to run on these systems.
A few years later, in around 1964, IBM introduced the world to OS/360.
With this, IBM started to reuse the same operating system when manufacturing new computer models.
This was the beginning of manufacturers using a standard OS across different computer models. It allowed software portability for the first time. At the end of that decade, UNIX arrived on the scene. It had the ability to run across different computer models by multiple manufacturers.
With an increasing variety among operating systems, manufacturers, and hardware, porting your software was becoming a nightmare. Hence, in the 1980s IEE Computer Society introduced POSIX to manage the compatibility challenge. This standard took inspiration from BSD, Unix, and System V.
What changed in the OS industry after POSIX?
This standard regulates the way operating systems were built by basing them on the interface between software and operating system.
Now, programmers had the freedom to create operating systems with any functionality so long as they complied with POSIX.
This made software portability between two POXIX compliant OS much easier, as the standard eliminated the need for considering hardware or the manufacturer when developing applications.
The year 1988 saw the release of the first POSIX standard, officially named IEEE Standard 1003.1-1988 Portable Operating System Interface for Computer Environments.
Initially, POSIX comprised four major standards:
- Core Services
- Real-time extensions
- Thread extensions
- Shell & Utilities.
There have been multiple iterations since their initial draft of the POSIX standards.
Pillars of POSIX
POSIX has seen many improvements aimed at making application portability simpler. While it is a common perception that POSIX is synonymous with the UNIX and UNIX-like operating systems, POSIX-compliant systems form a much larger group.
The specifications of the POSIX standard have nothing about how the development of an operating system or an application should work. Its sole focus lies on the relationship between the application and the operating system.
We address the POSIX standard at the source code level.
This means the source code for a POSIX compliant application should be able to run across any POSIX operating system. However, this need not be true for its binary executables.
The language used for POSIX is Standard C. However, developers are free to choose any language while implementing the standard.
The specifications only apply to the aspects where applications and the operating system interact.
The specifications mentioned in the POSIX standard are brief, yet they hold a broad scope to allow a large variety in systems and software.
Developing with POSIX
The POSIX standard was developed to improve the portability of software across different operating systems. When the source code for your software is based on POSIX, it massively simplifies the process of compiling and running it on a separate system.
But the POSIX standard is not a must for developing your software. The standard presents a wide variety of specifications, applicable to over a thousand different interfaces.
This makes trying to implement everything an inefficient development choice.
Hence with each project, you need to define the aspects of POSIX which meet your specific needs.
There is a general misunderstanding in the community about POSIX being an outdated and deprecated standard for software. However, while it was devised more than 35 years ago, POSIX is still relevant to this day.
The rules and specifications are constantly worked upon and updated by the Austin Group.
It is open for everyone who wishes to work towards making the standard better.
And the standard finds widespread application in the fields of embedded systems, mobiles, LINUX & UNIX systems, servers, and workstations.
I hope this article helped you understand POSIX compliance better. This article covers the theoretical aspects of the POSIX compliance and you certainly need to understand the compliance better to be able to implement it in your development better.