Leaving out a >>lot<< of
detail, but under ASA was their directive: the Accredited
Standards Committee X3
This means that the US government,
particularly the US War Department (late DoD), would
accept their recommendations. However, a published set of
rules for how standards would be created, agreed upon, etc.,
for the USA became established.
One of their early roles was creating
standards for the computer industry, such as what would
become ASCII, a.k.a., ASA X3.4-1963, and ASA
X3/INCITS 40-1966 - 9-track mag tape.
One of the things the folks at X3 had
started working on we standards that allowed program
interchange between different manufacturers,
although allowing manufacturers to be independent and add
their own features but keep a core that a programmer could
rely upon. So, their purvey included creating standards
for FORTRAN, Algol, Cobol, and later C. They also
developed test suites for many of their standards and
offered services to firms like computer manufacturers to
certify that their products meet the standard. Thus, a
program that worked when compiled under different
manufacturer compilers could be written.
Note that AIEE/IEEE was a founding member
of ASA, but it eventually became an accredited standards
body independent of ASA/ANSI. The subtle difference was
the idea of "sameness," which said this is functionally
the same as something else made by two different
electrical manufacturers and, as a result, could
interoperate between them. This was important to the US
DoD because they wanted more than one place to get similar
products, at least ones that could play well together.
So, they became where things like networking, power, etc.,
were defined and agreed upon. Of note, independent of
IEEE, we were testing groups, but if you made an error, it
was basically self-correcting -- people stopped using your
product when it was discovered you could not handle
back-back ethernet packets at full speed.
So what happened...
We graduated a bunch of young engineers of
my generation who know C and UNIX. AT&T has made the
sources to both technologies "open" and freely available
(libre as opposed to beer). We take the knowledge with
us, and they both start to be cloned. Since the
microprocessor came in vogue around the same time,
retargeting the C compiler at many places like
Universities made sense - I did it (poorly) for the
Dennis' compiler for what would become the 68000
@Tektronix in the summer of 1979. But if you look at the
USENIX tapes from those times, you will see many different
developer tools for those processors. However, since
the AT&T tools were licensed, several implementations
grew that were mostly, if not 100%, clean of any
AT&T's IP.
Since there was no standard for the
language itself, and the processors were not PDP-11, many
differences crept into the different compiler
implementations. The biggest was support for the x86 and
target platforms such as CP/M and DOS, which did not store
files in the same format as UNIX and differentiated
between text files and binaries like earlier
12/18/36-bit systems from DEC had.
In the early 1980s, a group of compiler
firms, originally from the PC business, applied to set up
and create the ANSI X3.159 committee. [Thank the Lord,
Dennis agreed to join it too, as he could rein in several
of the worst proposals like near/far pointers, although
the terrible text file support leaked]. It was a very
slow process since a standard did not come about a vote
until 1989 and was agreed upon until 1990.
Meanwhile, in UNIX land there, USENIX had
started [see my paper: C.T. Cole, UNIX: A View from
the Field as We Played the Game, October 19, 2017,
Le CNam – Laboratoire, Paris France], but that was
primarily an academic organization. Firms like
manufacturers DEC, HP, Tektronix, and IBM, as well as ISVs
such as Heinz's Interactive System Corporation and
Microsoft, needed an organization that focused more on
their needs as commercial ventures. /usr/group (which was
later re-branded as Uniforum) was created. For many
reasons (many of which have been discussed here), the
manufacturer's versions of UNIX had begun to differ. But
they had a common language C, since many, if not most,
used AT&T licensed C compilers, the compilers' input
syntax was already mostly common, but one of the things
that this group realized was it was still "work" for an
ISV to move their UNIX based application between systems
and they needed something more than just a language
standard.
To address this need /usr/group, formed a
standard committee under Heinz's leadership. In 1985, we
published the first UNIX standard. One of the members of
the group, Jim Issak, who then was from another small
manufacturer building a system with a UNIX-like OS,
Charles River Data Systems (CRDS - BTW: pronounce that and
smile -- marketing people are wonderful), realized that a
/usr/group created standard was helpful to us in the USA
marketplace since /usr/group was not accredited and thus
our work would not be useful to be sent to the US Gov much
less and alter International standards body such as ECMA
or ISO.
BTW: since our OS's were already getting
different beyond the system call layer, we decided to
start with just the system call API which was mostly
common, plus agree to an interface standard to exchange
magnetic media. But this is where things like the file
<unistd.h> come from to help make the differences
contained in a manner that a recompile allowed code to
move from one vendor's system to another.
By the early 1980 my
former colleague, Maurice Graubie from Tektronix, had been
the chair of the IEEE 802 committee, which had published
its set of standards. BTW the number.X stuff raised huge
hackles at IEEE at the time. It had never been done.
Maurice had come up with
solution as a way to keep the
801 standard together when it was beginning to diverge and
fall apart with the Ethernet folks on one side and the IBM
token ring folks on the other.
Since the OS was similar to other
electrical standards, allowing one manufacturer to build
something the US government buys and knowing they could
get something similar from someone else, Maurice
introduced Jim to the folks at IEEE. Jim succeeded in
putting together all of the paperwork, getting the proper
sponsorship from IEEE institutional members, and forming a
committee to create IEEE Proposal 1003.
As the next /usr/group meeting approached,
we were already starting to work on a revision. Jim
explained the formal IEEE process. We officially voted to
disband that meeting and reconvene as IEEE P1003, where
Heinz graciously handed the gavel to Jim. It also set us
back a bit because the /usr/group document was not in a
form that IEEE could accept. So the first task was the
rewrite (and use their voting process) to have it
accepted. But because of Maurice's great compromise for
the 802 committee, we started by saying this would be the
first of N standards, i.e., 1003.1 for the system
calls, and we would (like 802) create later standards for
things like the commands. I know that both Maurice and
Jim had a little pushback by IEEE NYC, but I am thankful
that a good idea prevailed.
It's possible ANSI might able to do the
same thing that IEEE did. But the difference is that
members of the/usr/group were all institutional members of
IEEE, and the style of things we needed to do at the time
was really the sort of thing IEEE was already accustomed
to doing. As for the language, since ASA/ANSI was already
doing things there - that made sense.
BTW: it has been observed that IEEE is
behind VHDL - which is a hardware description language.
But against this more in their world -- it pushed to
silicon manufacturers, so you know IP can be moved between
different fabs. We can argue that it's a language, and
ANSI would have been a good place for it.