From the early days of UNIX, the OS has used the C programming language
as it's primary development language. The OS always provided C bindings
for it's system API, and application development tended to use C for
all the compiled language requirements. Thus, in those times, the C API
/was/ the UNIX API, and the UNIX API /was/ the C API.

Back in the early 1980's, UNIX systems proliferated and mutated. All
provided similar services and a mostly-consistant API, but there were
enough differences between the various species of Genus UNIX that
compatability became an issue. Some species provided API definitions
in one #include file, while others scattered the API definitions into
other #include files. API definitions varied in minor details, taking additional arguments, or returning different values than others. There
was chaos on the horizon.

In the 1990's, the IEEE stepped up to the plate and started an effort
to standardize a single, common UNIX specification. (While the IEEE
casted about for an appropriate name for this effort, Richard Stallman,
who was intimately involved in similar efforts, suggesed the name
"POSIX", for "Portable Operating System Interface".) They settled on
a definition called IEEE-1003, which ISO adopted as ISO/IEC 9945.

The IEEE-1003 standard initially addressed only the API (POSIX-1) and
a validation suite, but, later, was extended to include common utilities,
shell language, auxiliary libraries, and other "essential" components.
In 2008, much of these extensions were rolled back into the IEEE-1003
standard as IEEE-1003.1-2008, AKA POSIX.1-2008.

The US Government had an outside role in this standardization effort;
in all areas, including the military, the government spent a /lot/ of
money on software. Most of this software was written by programmers
using UNIX systems of one species or another. And, the government
procuration process would not only have to purchase this software, but
also the specific UNIX OS that it was written to run on. This got
/very/ expensive.

So, the US Government, through the Federal Information Processing
Standard (FIPS-151), decreed that all operating systems purchased
in support of purchased software must support a minimum common API.
FIPS settled on POSIX-1 as that API.

Now, Microsoft didn't support POSIX in any form and it realized that
it would lose a lot of government contracts because of this lack of
support. So, in it's newest Windows NT operating systems, it bolted
in a subsystem (the NT POSIX subsystem) that supported the POSIX-1
API, and thus could handle programs coded to that level of UNIX API.
According to Wikipedia, "Windows NT versions 3.5, 3.51 and 4.0 were
certified as compliant with FIPS 151-2."

Later, Microsoft would replace the NT POSIX subsystem with first
"Windows Services for UNIX" (WSU), and later "Windows Services for
Linux" (WSL). But, even with these changes, Windows supported, in
some form or another, the basic UNIX API.

All this to say that, Windows, since the 1990's has supported, in
one form or another, the basic UNIX API with C bindings. We've had
thirty years of UNIX and UNIX-compatable C under Windows.



--
Lew Pitcher
"In Skills We Trust"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

All this to say that, Windows, since the 1990's has supported, in one
form or another, the basic UNIX API with C bindings. We've had thirty
years of UNIX and UNIX-compatable C under Windows.

The difference being that POSIX was careful to spell out exactly how
the API worked (including error codes and when they could occur), so
it could be implemented as a proper standard. The same was not true of
the Windows API. Which is why people get into such a mess trying to
program for Windows.

Jeremy “Samba” Allison made this point many years ago <https://www.samba.org/samba/news/articles/low_point/tale_two_stds_os2.html>.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lew Pitcher wrote:

From the early days of UNIX, the OS has used the C programming language
as it's primary development language. The OS always provided C bindings
for it's system API, and application development tended to use C for
all the compiled language requirements. Thus, in those times, the C API
/was/ the UNIX API, and the UNIX API /was/ the C API.

Back in the early 1980's, UNIX systems proliferated and mutated. All
provided similar services and a mostly-consistant API, but there were
enough differences between the various species of Genus UNIX that compatability became an issue. Some species provided API definitions
in one #include file, while others scattered the API definitions into
other #include files. API definitions varied in minor details, taking additional arguments, or returning different values than others. There
was chaos on the horizon.

In the 1990's, the IEEE stepped up to the plate and started an effort
to standardize a single, common UNIX specification. (While the IEEE
casted about for an appropriate name for this effort, Richard Stallman,
who was intimately involved in similar efforts, suggesed the name
"POSIX", for "Portable Operating System Interface".) They settled on
a definition called IEEE-1003, which ISO adopted as ISO/IEC 9945.

The IEEE-1003 standard initially addressed only the API (POSIX-1) and
a validation suite, but, later, was extended to include common utilities, shell language, auxiliary libraries, and other "essential" components.
In 2008, much of these extensions were rolled back into the IEEE-1003 standard as IEEE-1003.1-2008, AKA POSIX.1-2008.

The US Government had an outside role in this standardization effort;
in all areas, including the military, the government spent a /lot/ of
money on software. Most of this software was written by programmers
using UNIX systems of one species or another. And, the government
procuration process would not only have to purchase this software, but
also the specific UNIX OS that it was written to run on. This got
/very/ expensive.

So, the US Government, through the Federal Information Processing
Standard (FIPS-151), decreed that all operating systems purchased
in support of purchased software must support a minimum common API.
FIPS settled on POSIX-1 as that API.

Now, Microsoft didn't support POSIX in any form and it realized that
it would lose a lot of government contracts because of this lack of
support. So, in it's newest Windows NT operating systems, it bolted
in a subsystem (the NT POSIX subsystem) that supported the POSIX-1
API, and thus could handle programs coded to that level of UNIX API. According to Wikipedia, "Windows NT versions 3.5, 3.51 and 4.0 were
certified as compliant with FIPS 151-2."

Later, Microsoft would replace the NT POSIX subsystem with first
"Windows Services for UNIX" (WSU), and later "Windows Services for
Linux" (WSL). But, even with these changes, Windows supported, in
some form or another, the basic UNIX API.

All this to say that, Windows, since the 1990's has supported, in
one form or another, the basic UNIX API with C bindings. We've had
thirty years of UNIX and UNIX-compatable C under Windows.

interesting, i'm glad i really never had to deal with any
of that, but i did write a few C programs here or there and
they worked for what was needed to be done.


songbird

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:

From the early days of UNIX, the OS has used the C programming language
as it's primary development language. The OS always provided C bindings
for it's system API, and application development tended to use C for
all the compiled language requirements. Thus, in those times, the C API
/was/ the UNIX API, and the UNIX API /was/ the C API.

[...]

Great writing, great reading. Thank you for posting. Thank you for
being on the USENET for so long. In skills we trust.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)