What is UNIX, Anyway?

Lieutenant writes "Technology professionals have loosely used the term "UNIX" since the first person had to explain the difference between the Berkeley and AT&T flavors, so it's not surprising to find as many UNIX standards as there are versions of the operating system. Peter Seebach wades through the wellspring of UNIX standards and sorts them out for you, concluding that the rumors of the death of UNIX are (as usual) greatly exaggerated."

Comments

Re:Not a bad article.

[(Score:1)]

For the history of Unix (timeline), read this one:
http://www.levenez.com/unix/

Mirrordot has it

[oglueck]

Mirrordot

Re:Unix is in everything

[stx23]

Huh? Unix isn't remotely related to VMS.

Re:Not a bad article.

[seebs]

Hosted by IBM just because it's a regular column on standardization. In all the years I've written for IBM, the only edit they've ever made on such grounds is that they changed the word "Belkin" to the name "Company X" in my article about Belkin's packet-hijacking routers. Oh, wait; I think they disliked a couple of comments I made about Verisign once. Mostly, if there's no obvious liability, they don't get involved.

Re:First Sale Doctrine

[larry bagina]

You can (legally) get it for free at unix.org and opengroup.org. An individual paying a $974 annual fee for it has more money than brains.

MISQUOTE

[Anonymous Coward]

"There are two major products that came out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson

Correction

[XanC]

That's ISBN 0-201-54777-5, or 978-0-201-54777-1.

Re:UNIX ?

[koinu]

I have more reliable sources than wikipedia: Linux.
I know why I'm using FreeBSD.

Re:old paradigms

[Cow Herd (Anonymous)]

...the concept of setuid (which gives you *all* the privileges available)...

The setuid bit on an executable file gives you the privileges of the owner of the file. It is mostly used as setuid-root, but doesn't have to be.

setuid(2) is a different matter of course, because you need to have uid 0 for it to work at all.

Re:Define it by its limitations

[moranar]

It is a mindless bashfest. Nevertheless, it is interesting. There is some truth in their madness. But they themselves admit that it's over the top and to be taken with a grain of salt. At least the book, I'm not sure about the mailing list/newsgroup.

Re:Not a bad article.

[drsmithy]

I especially like the author's point about the liquidity of the Microsoft "standard" API which is so touted as a counterpoint to *nix implementation -- DOS, Win16, OS/2, Win32, WinNT, WinXP, .NET, Vista... versus POSIX. Yeah, he's right, it sounds pretty ridiculous when you put it that way.

Particularly since the "Win32, WinNT, WinXP" part of it are all the same thing, so the real progression is:

DOS, Win16, OS/2, Win32, .NET.

Re:Not a bad article.

[peragrin]

Um what are you smoking?

16-bit windows and dos apps only work if they are non-trivial. I can't upgrade our work computers out of windows 95 and windows 98 because we depend on non-trivial software that doesn't run on the NT line. So MSFT is just as bad as everyone else. Try running some of the early versions of word in XP or win2k3 it doesn't work, and the modern versions can't read the older formats. been there. tried that, considered it lost.

Most linux problems aren't binaries but library and their various and multitude of locations.

Re:Single Unix Standard, Version 3

[Octorian]

Yeah, you'd have to stretch things to make those comparisons. VMS may have some syntactic similarities to DOS, but not as many as you'd think. Let's take a complete file path, for example:
UNIX: /files/stuff/foo.txt
DOS: C:\FILES\STUFF\FOO.TXT
VMS: SYS$SYSDEVICE:[FILES.STUFF]FOO.TXT;1

Though DOS and VMS both use "DIR", while UNIX uses "ls". However, both DOS and UNIX use "cd", where VMS uses "SET DEFAULT". DOS and UNIX also use "mkdir", where VMS uses "CREATE/DIRECTORY". Though UNIX uses "-foo" for command switches, where both DOS and VMS would use "/FOO", but VMS doesn't require a space between the command and the switches.

If only that were true!

[Anonymous Coward]

Clearly you were never forced to program anything to the Win32 API.

There's a common subset of functions available on both 9x and NT flavors of Windows. (With different bugs and sometimes different supported flags, different restrictions on use, etc). Then there's a bunch of functions that only work on NT-based flavors of Windows, not 9x-based. And the opposite is also true. Then XP came along, then Server 2003, each adding a bunch of new stuff to the API that Microsoft (unfortunately) did not go back and also add to the earlier versions of Windows.

There really are at least 3 distinct flavors of the Win32 API, and you have to be careful what functions you use if you want your program to run on all three of them.

For an example, check out the documentation for the CreateWindowEx function.

If you scroll to the bottom, they describe several of the differences in the behaviour of this function on different versions of Windows ranging from 95 to XP.

This situation could have been avoided if Microsoft had had the foresight to separate the Win32 API implementation from the rest of the OS so it could be upgraded independently.

Re:If only that were true!

[Quantam]

Then there's a bunch of functions that only work on NT-based flavors of Windows, not 9x-based. And the opposite is also true. Then XP came along, then Server 2003, each adding a bunch of new stuff to the API that Microsoft (unfortunately) did not go back and also add to the earlier versions of Windows.

I can only think of one feature that's available on Windows 9x but not NT, which isn't part of the Internet Explorer toolkit, and it's a very rarely used feature (although it's just the kind of thing I use). Almost universally, the API on NT is a superset of that available on 9x; though it is true that occasionally some small implementation details different between the two.

Then XP came along, then Server 2003, each adding a bunch of new stuff to the API that Microsoft (unfortunately) did not go back and also add to the earlier versions of Windows.

Correct. The Windows API evolves over time, adding new and often useful features to new versions, often involving new features of the kernel. In nearly all cases these changes are backwards compatible.

There really are at least 3 distinct flavors of the Win32 API, and you have to be careful what functions you use if you want your program to run on all three of them.

Windows 9x, Windows NT, and..? Well, I suppose you could call the ANSI/Unicode versions different, even though the differences between the implementations are usually very clear-cut (i.e. path strings are always handled in certain different ways).

For an example, check out the documentation for the CreateWindowEx function.

If you scroll to the bottom, they describe several of the differences in the behaviour of this function on different versions of Windows ranging from 95 to XP.

That serves as an excellent demonstration of what I've said: the differences are usually minor enough to not be a concern, and that new features are added in a backward compatible way. Take a look: one of those differences refers to a feature that was added in XP (WS_EX_COMPOSITED), another refers to a kernel limitation of 9x, and the third refers to a feature that was added in 2000. Of those, the only "serious" one is the 9x kernel limitation, and even then it's not particularly important.

Re:UNIX hater's handbook.

[marcosdumay]

It was done to the extent that was possible. The CLI isn't there to let the user write, it is there to automate stuff. When you want to automate stuff, you use lots of rarely used functions that your system would neglet (making the user RTFM anyway) and monitor space is extremly important. Also, you don't want some weard program messing up with the streams.