What is UNIX? Re: wanted: UNIX or clone

Eamonn McManus em at dce.ie
Tue Apr 9 03:18:32 AEST 1991


Peter da Silva writes:
>>	access alarm brk chdir chmod chown close creat dup exec
>>	exit fork getpid getuid getgid ioctl kill link lseek mknod
>>	mount open pause pipe read setuid setgid signal stat sync
>>	time umask umount unlink wait write
>>Any operating system that provides these 35 system calls with the semantics
>>described in Section 2 of the PRM is UNIX.

I'm not sure how serious a definition this is supposed to be.  Everyone
could provide their own favourite set of necessary system calls.  For
instance, the omission of getppid from the above list is curious.

Alan Barclay writes:
>This is possibly the worst definition of UNIX I've every seen, hang on
>a minute though, VMS with the right lib supports these calls, does this
>mean we can stop all the UNIX/VMS wars by saying they're both the same?
>If so then I do like this.

VMS cannot support all of these calls with the right semantics.  For
example:
    chmod - cannot set setuid, setgid, or sticky bits, because they
	don't exist;
    exec - likewise no setuid or setgid;
    fork - no equivalent with data duplication, though it could be
	expensively supported with difficulty;
    kill - no VMS concept of signals;
    link - VMS does not support links (properly);
    mknod - VMS does not support device files;
    mount - VMS does not support mounting at arbitrary points in the
	hierarchy;
    open - VMS allows access if any of owner, group, or other permissions
	grants it, while Unix only looks at the permissions of the first
	appropriate set;
    stat - VMS does not have equivalents for some of the information,
	such as inode change time;
    unlink - apart from not supporting multiple links, VMS requires
	delete access to the file.
There are other differences too.  The VMS C library provides emulation of
nearly as much of Unix semantics as it could, but some things are just not
possible without completely layering a new OS on top of VMS.

,
Eamonn, who has spent far more time programming VMS than he would like and
    doesn't intend to do it again.



More information about the Comp.unix.sysv386 mailing list