And it's one of the two UN*X platforms that most of the CAD software listed in the Wikipedia "Comparison of CAD software" page runs on if it runs on any UN*X at all; the other is, not entirely surprisingly, Linux. Most of them, according to that page, at least, only run on Windows, however.

As did the BSD part of the kernel (the kernel is more than "the micro-kernel"; "the micro-kernel" is the stuff in the osfmk directory of the XNU source, the BSD part is the stuff in the bsd directory, and there's also I/O Kit in the iokit directory).

The BSD part of the kernel, and much of the Darwin userland, is as much "unix", in the sense of being derived from AT&T code, as are the *BSDs. (It's also "unix" in the sense of passing the Single UNIX Specification test suite, but you presumably already knew that and weren't using "unix" in that sense.)

Or kinda sorta VLIW, if you mean "CISC has been implemented in microcode atop not-so-CISCy microengines from the very beginning", although it's also been implemented purely in hardware (in, for example, the IBM System/360 Model 75, the GE 600 series, and the Honeywell 6000 series, although that was in an era before the term "CISC" had been coined).

Or, if you're just talking about instruction set architectures, you end up with an operating system whose API model works Just Fine for both instruction set architectures (and ISAs other than the one ported from or the one ported to) and a legacy of language and system design choices that work Well Enough for both.

So presumably you're referring to system architectures, not instruction set architectures such as SPARC, MIPS, POWER/PowerPC/Power ISA, Alpha, and x86, as they really don't differ, at least in the way Windows or UN*X use them, in ways that make much of a difference.

Same for Solaris 11, same for AIX 6, same for HP-UX 11i V3. Does this indicate that those OSes have not adopted any of the subsequent API changes, or does it indicate that the Open Group haven't updated their conformance suites so that you can't test anything better than v4 for the command-line tools and v2 for the C API?

(And do "V4" and "V2" refer to Issues 4 and 2, respectively, of the SUS, or do they refer to something else?)

What are some of the significant things present in the C APIs of Linux and the *BSDs that are not present in the C API of OS X, and which, if any, of them were introduced in issues of the SUS later than 2?

Where have they stated that (in a way indicating that "all" includes not only the folks writing Mac Applications(TM) but also the people doing UN*X apps that work on OS X)?

One of these things is not like the others, given that Oracle bought Sun and are still selling their servers and their Unix. (SGI's still around, too, but good luck buying a MIPS-based server running IRIX from them.)

Wrong.

Well, in fact, legally speaking, they're not Duck(R) waterfowl. The point is that, given that they walk enough like a Duck(R) waterfowl, and quack enough like a Duck(R) waterfowl, people are willing to treat them the same way they treat Duck(R) waterfowl even though they cannot legally be called Duck(R) waterfowl. (I.e., people are willing to use Linux distributions as a substitute for Unix(R) systems because, legally speaking, even though they're not Unix(R) systems, they're enough like it that the differences aren't worth spending the extra money for a Unix(R) system.)

Well, yeah, I suspect most sites with Unix applications - oops, sorry, that's "applications for Unix(R) systems" :-) - are probably not going to port them to z/OS (the certification for which is for a standard that's almost 20 years old, BTW; are there any geese that have been certified as a recent version of a Duck(R)? The only recent Ducks(R) I see are all stuff that could reasonably be considered Real Unix), given that if their apps assume they're using ASCII, they're in for a rude surprise....

In the "dead" list, given that DEC^WCompaq^HP aren't coming out with new releases and given that it runs on an instruction set architecture of which no more implementations are being made and it isn't being ported to new architectures.

In the "dead" list, given that SGI aren't coming out with new releases and given that the only instruction set it supports these days, MIPS is now targeted for various flavors of embedded computing rather than general-purpose computing, and it's not being ported to other instruction sets.

These days, it's called "Linux".

Wow, they're still around, not that they're players in the same "enterprise server" market as Oracle/HP/IBM and their respective proprietary Unixes.

Limiting yourself to Unixes that are still around, if the topic is the decline of "Unix", is, however, a rather reasonable standard.

Since the 360 line - all but the Model 75 and Models 91, 95, and 195 were microcoded.

You could add new instructions with new microcode, but you aren't going to get Shiny Newer Faster Machines (at least not past a certain point) with new microcode on top of the Same Old Boring Hardware, and, with Shiny Newer Faster Hardware, you're going to need Shiny Newer Microcode to run atop that hardware to implement the instruction set. (And, with recent generations of hardware, most of the instructions are, I think, implemented in hardware, with some instructions implemented by trapping to PALcode^Wmillicode.)

Which specific parts of the Single UNIX Standard cannot possibly be implemented by Linux+glibc due to those architectural differences? Be specific, please.

You're thinking of SunOS 3.2-3.5 and 4.x; the first SVisms were added in 3.2, and a bunch more were added in 4.0 (and RFS was added in, I think, 4.1). The "Solaris" name wasn't used until SunOS 4.1.1 (Solaris 1 = SunOS 4.1.1 + the corresponding versions of OpenWindows and maybe the desktop applications) and SunOS 5.0 (Solaris 2 = SunOS 5.0 + the corresponding versions of OpenWIndows and desktop applications).

SunOS 5.0 was Sun's version of System V Release 4. SVR4 was the result of AT&T and Sun combining the SV code base with the Sun code base, with a bunch of things (such as the VM subsystem) picked up from SunOS 4 with some changes (one of the most important VM subsystem changes was the renaming of the routine to look for an unmapped region in the address space from as_hole() to as_gap(); yes, I'm serious, do a Web search for them).

I.e., it didn't conform to the System V Interface Definition? (That's the only form of "System V compliance" there is.) If so, could you provide a citation for that claim?

And 4) differs from 3) how? As far as I know, the low-level parts of Android are the Linux kernel and the Bionic libc, which give you a Unix-like API; Dalvik sits atop those (and possibly other things).

The "POSIX API layer" is 4.4-Lite-derived kernel code plopped atop Mach's platform support, task/thread, and VM code; it's not part of the Mach layer. The Mach code knows nothing about networking or file systems; that's all BSD code (or Apple code). (There's also I/O Kit, which is neither BSD nor Mach, and is what's used for drivers that actually talk to devices, rather than "pseudo-drivers" such as the pseudo-tty driver and the BPF driver. The osfmk directory of the XNU source is the Mach code, the bsd directory is the 4.4-Lite-derived code, and the iokit directory is the I/O Kit code.)

Well, actually, Sun's OS originally announced itself in the boot message as "Sun UNIX 4.2BSD Version {version number}", or something such as that, until AT&T got cranky; "SunOS" first appeared in the boot message in, as I remember, 4.0 (at which point it was also more "4.3BSD" than "4.2BSD").

Define "used"/"uses". They don't use it in the OS's brand name, but they sure use it on, for example, the Solaris 11 overview page ("Brings the reliability, security and scalability of the #1 UNIX OS to the enterprise cloud"). Apple doesn't use "UNIX" in the name of their OS, either, but they used it in various advertising materials, e.g. "sends all other Unix boxes to /dev/null", and The Open Group told them they had to certify (Mac) OS X in order to use the trademark.

It still costs money:

Annual fees apply, which are referenced by the Trademark License Agreement:

• License fee for the TMLA to remain in place
• Product registration fees
• Program fees (royalties)

Separate fees apply for the test suites.

There was also Digital UNIX, which was the new name for DEC OSF/1 after it passed the test suite for SUS conformance. (It was later renamed Tru64 UNIX when there was no longer a "Digital Equipment Corporation".)

...as long as they stop calling Solaris "the #1 UNIX OS" (or anything else with "UNIX" in it).