Looking for "System V Interface Definition"
Steven King, Software Archaeologist
across many different platforms. One thing I'm investigating is how
well defined is "SVR4"? If I code for one platform that claims to be
SVR4, what are the odds of simply being able to recompile on another
vendor's system, which also claims to be SVR4?
I've found a couple veiled references (in the Unixware FAQ, of all
places) to something called "AT&T's System V Interface Definition
SVIDIII" and "Spec1170". Can anyone give me a pointer to more
information about these? Where can I find these specs; or at least,
where can I find summaries of them?
What does it take to get certified to legally use the names "Unix" or
"System V"? Knowing that may answer my questions right off.
--
----------------------------------------------<Steven King, ki...@cig.mot.com>--
Nothing is more conducive to peace of mind than not having any opinions at all.
(Georg Christoph Lichtenberg [1742-1799])
James Vlcek
>If I code for one platform that claims to be
>SVR4, what are the odds of simply being able to recompile on another
>vendor's system, which also claims to be SVR4?
Quite good, I would say. I code for both Solaris 2.x (SVR4.0) and
UnixWare (SVR4.2) and find a near-perfect match. The only differences
I've encountered are in Makefiles and the like.
Of course, everything depends on what you are trying to do. If you
end up using one vendor's extensions for whatever reasons, you might
suffer when it comes time to perform the port.
>I've found a couple veiled references (in the Unixware FAQ, of all
>places)
Why "of all places"? UnixWare is, after all, built atop UNIX System V
Release 4.2, the latest and greatest of the SVR4s.
>to something called "AT&T's System V Interface Definition
>SVIDIII" and "Spec1170". Can anyone give me a pointer to more
>information about these? Where can I find these specs; or at least,
>where can I find summaries of them?
Loosely speaking, SVID was an AT&T Unix Systems Labs definition of the
system interfaces for System V Unix. I don't know where you might
find a copy of SVIDIII, and suspect it might be very tiresome reading
if you did.
Spec1170 is the name of a more recent interface definition (which
originally consisted of 1170 APIs; now somewhat fewer) constructed
under the auspices of X/Open Co. Ltd, UK. X/Open is now _the_
standards branding body for "open systems", after the dissolution of
Unix International, the streamlining of the goals of OSF, and the end
(let's hope) to the idiotic "UNIX wars" of the past few years.
You _can_ get a copy of Spec1170 from X/Open (unfortunately, I don't
have the contact information with me right now ... I should include it
in the UnixWare FAQ I guess), but again I'm not sure you really want
to read it. Probably more useful is to get a copy of Donald Lewine's
book "POSIX Programmer's Guide" and W. Richard Stevens' "Advanced
Programming in the UNIX environment" (ISBNs for both are to be found
in the UnixWare FAQ, URL
ftp://rtfm.mit.edu/pub/usenet/news.answers/unix-faq/unixware/general)
and work from those excellent texts.
>What does it take to get certified to legally use the names "Unix" or
>"System V"? Knowing that may answer my questions right off.
As you may know, Novell acquired Unix Systems Laboratories from AT&T
in 1993; along with USL came the UNIX trademark. Soon after
finalizing the acquisition, Novell announced its intention to deed the
UNIX trademark to X/Open, a transaction which was completed earlier
this year*. X/Open is now the owner of the UNIX trademark, and one
must deal with them in order to legally use it.
I don't know about "System V"; I suspect that this remains with
Novell's Unix Systems Group.
Jim Vlcek
*Arguably the one smart thing Novell has done with UNIX so far.
Sort of like Dukakis choosing Bentsen.
Terry Lambert
] In <32oo6i$e...@delphinium.cig.mot.com> ki...@wildebeest.cig.mot.com writes:
] >If I code for one platform that claims to be
] >SVR4, what are the odds of simply being able to recompile on another
] >vendor's system, which also claims to be SVR4?
]
] Quite good, I would say. I code for both Solaris 2.x (SVR4.0) and
] UnixWare (SVR4.2) and find a near-perfect match. The only differences
] I've encountered are in Makefiles and the like.
Actually, it depends on which SVR4 features one is using, and the
expectations you place on those features near their boundry conditions.
I found 11 differences between Dell UNIX (SVR4) and UnixWare (SVR4)
in the first hour after installing UnixWare and trying to "do my thing".
Since "my thing" happens to be file systems, I view this as atypical. 8-).
I found several major differences, where all three OS's (now including
x86 Solaris) did some rather non-trivial (ie: very important to me)
things very differently, in areas from dynamic library contents (and
therefore the ability to run each others binaries) and SVID III (RT)
compliance.
The best answer in terms of binary portability is to link everything
static and use a minimum of the available interfaces and avoid the
boundry conditions in terms of things like function resoloution, etc.
Terry Lambert
te...@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
David Robinson
Terry Lambert <te...@cs.weber.edu> wrote:
>The best answer in terms of binary portability is to link everything
>static and use a minimum of the available interfaces and avoid the
>boundry conditions in terms of things like function resoloution, etc.
I have just the opposite opinion, link everything dynamically and
stick to the minimal SVID definition. All the various vendors
promise SVID compliance and that implies that the system call
interface is done through dynamic libraries. The advantage
of this is the vendors can do whatever tricks they want under
the covers in the library portion. And example of thisis the Solaris
version of libnsl which uses a name service switch backend, not all
other vendors use this (do any?). If you statiocally link with
the Solaris libnsl.a it is unlikely that it will run on others platforms.
-David
Scott G. Hall
>I found 11 differences between Dell UNIX (SVR4) and UnixWare (SVR4)
>in the first hour after installing UnixWare and trying to "do my thing".
>
>Since "my thing" happens to be file systems, I view this as atypical. 8-).
>
>I found several major differences, where all three OS's (now including
>x86 Solaris) did some rather non-trivial (ie: very important to me)
>things very differently, in areas from dynamic library contents (and
>therefore the ability to run each others binaries) and SVID III (RT)
>compliance.
Have I missed something along time here?... I thought Dell UNIX was SVR4.0-
based, whereas UnixWare and Solaris are SVR4.2 based. There is a *LOT* of
differences between these versions. I will say that we have some research
showing significant differences from USL SVR4.2 (the basis for UnixWare)
and UnixWare 1.1. I would venture to guess that Solaris also departed from
their roots of USL SVR4.2. So you could expect significant differences
between UnixWare and Solaris.
From several other postings that I have read here, each SVR4 (SVR4.2)
vendor adds value and distinguishes their product by either fixing bugs
or adding additional software and options to the product. This, by
definition, means that there are going to be differences in things like
extended library calls and filesystems. I too hate it when existing
library calls are modified (even to help support a vendor's distinguishing
feature), but the panacea of a single set of library calls not changing
from a single spec has been promised for a long time in the UNIX world,
and we are still a long way from this.
--
- sgh We don't play golf to feel bad... We play bad golf to feel good!
- Leslie Nielson "Bad Golf Made Easier"
Scott G. Hall (s...@cbvox.cb.att.com)
AT&T Bell Laboratories - GCBS, Columbus, OH, USA
Wade Scholine
>In article <339c8f$r...@u.cc.utah.edu>,
>Terry Lambert <te...@cs.weber.edu> wrote:
>>The best answer in terms of binary portability is to link everything
>>static and use a minimum of the available interfaces and avoid the
>>boundry conditions in terms of things like function resoloution, etc.
>I have just the opposite opinion, link everything dynamically and
>stick to the minimal SVID definition. All the various vendors
^^^^^^^^^^^^^^^^^^^^^^^
That's the rub! The original poster was trying to get a pointer
that what's SVID-compliant. In fact he was talking about source
portability so shared object issues ought not to concern him...
--
Wade L. Scholine | Once upon a time, four AMPHIBIOUS HOG
c_farer associates, inc. | CALLERS attacked a family of DEFENSELESS,
Delray Beach, FL. | SENSITIVE COIN COLLECTORS and brought DOWN
| their PROPERTY VALUES!!
Bob Palowoda
: Terry Lambert <te...@cs.weber.edu> wrote:
: >I found 11 differences between Dell UNIX (SVR4) and UnixWare (SVR4)
: >in the first hour after installing UnixWare and trying to "do my thing".
: >
: >Since "my thing" happens to be file systems, I view this as atypical. 8-).
: >
: >I found several major differences, where all three OS's (now including
: >x86 Solaris) did some rather non-trivial (ie: very important to me)
: >things very differently, in areas from dynamic library contents (and
: >therefore the ability to run each others binaries) and SVID III (RT)
: >compliance.
: Have I missed something along time here?... I thought Dell UNIX was SVR4.0-
: based, whereas UnixWare and Solaris are SVR4.2 based. There is a *LOT* of
: differences between these versions. I will say that we have some research
: showing significant differences from USL SVR4.2 (the basis for UnixWare)
: and UnixWare 1.1. I would venture to guess that Solaris also departed from
: their roots of USL SVR4.2. So you could expect significant differences
: between UnixWare and Solaris.
Solaris is SVR4.0 based. I would say the difference is Solaris 2.4
x86 kernel is heavly thread. I have run Unixware 4.2 normal binary
utility apps and X based apps and have had no real problem. The
only on I can think of is Unixware includes a function 'dtop' in
one of the Xlibs which Solaris did not put in because it is not
ABI complient.
: From several other postings that I have read here, each SVR4 (SVR4.2)
: vendor adds value and distinguishes their product by either fixing bugs
: or adding additional software and options to the product. This, by
: definition, means that there are going to be differences in things like
: extended library calls and filesystems. I too hate it when existing
: library calls are modified (even to help support a vendor's distinguishing
: feature), but the panacea of a single set of library calls not changing
: from a single spec has been promised for a long time in the UNIX world,
: and we are still a long way from this.
This isn't such a big issue with static compiled programs but yes it
is a problem with shared libs. Still it's no where near as bad as the
old day's when SCO, Interactive and ATT with 3.2 thier ill defined TLI
wrecked havoc amongst networks and shared libs.
---Bob
--
+----------------------------+-----------------------------+
| palo...@fiver.sns.com | Fiver Enterpises Inc |
| bob.pa...@eng.sun.com | x86 Solaris 2.4 |
| palo...@netcom.com | Development and Integration |
+----------------------------+-----------------------------+
Mr James Sainsbury
...deleted
> >to something called "AT&T's System V Interface Definition
> >SVIDIII" and "Spec1170". Can anyone give me a pointer to more
> >information about these? Where can I find these specs; or at least,
> >where can I find summaries of them?
> Loosely speaking, SVID was an AT&T Unix Systems Labs definition of the
> system interfaces for System V Unix. I don't know where you might
> find a copy of SVIDIII, and suspect it might be very tiresome reading
> if you did.
deleted...
The 5 volumes of the SVID 3rd edition are/were published/distributed
by Prentice Hall (in the same dark blue jackets that the original SVR4
docs were published.) These manuals document small parts of SV4.x not
otherwise conveniently documented.
--------- "l'essentiel est invisible pour les yeux...." ---------
Jim Sainsbury ji...@ocean.fit.qut.edu.au +61 7 864 1290 [w]
ji...@ozspace.brisnet.org.au +61 7 844 0285 [h]
Terry Lambert
] In article <339c8f$r...@u.cc.utah.edu>,
First of all, this lets out all X programs because Dell put bcopy in
libX linstead of libc.
Second, you may not have tried to profile anything yet, but I have. If
you have a static libnsl, I'd like to have a copy, please.
Third, I can successfully argue that not even UnixWare meets SVID (I
assume you mean SVID III?).
Fourth, this neglects IBCS2, which guarantees compatability about the
same way SVID would anyway -- "mostly".
Regards,
Terry Lambert
] That's the rub! The original poster was trying to get a pointer
] that what's SVID-compliant. In fact he was talking about source
] portability so shared object issues ought not to concern him...
No vendor will tell you where they fudge standards conformance, period.
Maybe the stupid ones will, but they only get to keep the title "vendor"
for a short period of time. 8-).
They all fudge. Most get by testing with an "acceptable exception list",
if they test at all. You will never see this list, and if you do, the
Men In Black will come and take you away and you'll never tell anyone.
If they are licensees of source from the standard title holder, the can
claim the name without validation (implying but not claiming conformance
directly).
By limiting the interfaces you consume, you limit (but don't eliminate)
your exposure to potential differences.
What is the developement panacea? There isn't one. That's why Visual
BASIC hasn't taken over the world (and why it *won't*).
This is the entire issue of "a unified UNIX". Call Open Systems Today
when you solve it... I hear they pay $$$ for a scoop. Or consider it
the entire issue of "a hetrogeneous environment", and sell the fix to
a PC rag, if it pays more.
How do I personally ensure source portability? ...here are a *few* of
the "secrets":
When I'm programming portable applications code, I generally use system
calls directly (section 2 routines) and try to limit my use of system
supplied libraries as much as possible. When I have to use one, generally
for things like directory searches, I #ifdef it based on the least common
denominator. I avoid compiler dependencies, like prototyping, loop
constructs subject to assumptions requiring the use of volatile (replace
with increment/if/goto). I avoid well known compiler bugs (like the
Berkeley portable C compiler register pop order bug on Sun machines, where
a register variable is assigned the value of a function of the register
variable). I avoid bit fields. I avoid size assumptions on packed
structures (like those in the DIRSIZ() macro, but that one's OK, since
the structure is word-aligned anyway). I avoid structure packing
assumptions (which for the most part means avoiding the use of unions
entirely and ordering elements instructure in descending order of
atomic data type size). I don't assume that enumerated types start at
zero, like you'd expect. I don't assume I'm using MSC5.x everywhere
(I don't assume auto variables start out zeroed). I assume I'm using
MSC5.x everywhere (I don't use things like 'char *foo = "xxxyyy" + 3;',
which because a pseudo-quad isn't generated, loses the "xxx" into the
ether somewhere). I assume I'm using Lattice (now SAS) C everywhere
(I don't declare so many register variables the compiler freaks and
starts reusing registers, and I avoid using dynamic scoping -- I only
declare auto variables at the tops of functions). I assume I'm running
on a stupid OS, like DOS, and don't allocate more than 64k chunks of
data at once. I assume I'm on a 3.x or older Altos Xenix and avoid the
system malloc(), which doesn't let the allocated data get freed properly.
I assume I'm running on a BTOS Wizard C compiler and put my beginning
squiggly brackets at the end of lines instead of on lines by themselves.
I assume I'm using an old Xenix system and don't put semicolons on lines
by themselves as placeholders (I eliminate the need for them by rewriting
or I explicitly use 'continue;'). I avoid using comma operators in
assignment statements. I avoid bitfields. I don't write structures to
files or to the wire. When I'm using auto initialization, I place any
union elements at the end of the structure so that I can leave the fields
empty so the compiler doesn't choke if it can't handle a NULL initializer
without a cast (some compilers can't handle casts). I don't use varargs.
If I prototype at all, it's for type checking because I'm too lazy to
run lint (which is to say, I don't usually do it) and I #ifdef it. When
I #ifdef it, I check for __STDC__ being defined first, then I check to
make sure it's non-zero because Sun intermediate compilers define it
as zero, in violation of the standard.
And this is just the "physicality" ...it says *nothing* about how you
are or aren't allowed to talk to serial ports, read a directory, lock
a file, use particular system calls, etc. -- it says nothing about
interactions between pieces of the OS.
In short (or not in short... 8-)), I do a lot of *crap* to ensure I write
portable code before I even *try* to compile it. I would consider it
to be unprofessional to do otherwise.
The one who dies with the most secrets wins.
Regards,
Simon Ritchie
> ... to something called "AT&T's System V Interface Definition
>SVIDIII" and "Spec1170". Can anyone give me a pointer to more
>information about these? Where can I find these specs; or at least,
>where can I find summaries of them?
The SVID and SPEC-1170 are Applications Programming Interfaces (APIs).
In other words, they describe the interfaces to UNIX that an
application programmer sees - essentially a formal description of the
system calls and the standard functions. If you conform to one of
these then your source code is portable across versions of UNIX which
conform. It does not, by the way, guarantee binary compatibility,
which requires conformance to an ABI as well as an API.
In an earlier follow-up Jim Vlcek explained that SPEC-1170, the new
common UNIX specification is available from X-Open, which is based in
England. (I'm posting this from home, so I don't have the address
and I can't even remember which town.) It's so called because it
defines 1170 interfaces to the operating system.
I understand that SPEC-1170 is not available as a paper document, but
only available via FTP or on CD-ROM. The FTP version is not free: they
charge you a fee for a password which allows you to connect up and pull
the stuff off. The CD-ROM version expects a Windows PC.
I believe that the spec is not yet completely tied down and that this
is a fairly mature snapshot.
(None of this may any longer be true. Check with the X/Open
documentation sales people for the current state of things.)
I've not seen a summary, but an informed source once described it as
``a join of OSF and XPG4''. (OSF is the Open Software Foundation's
version of UNIX and XPG4 is issue 4 of the X/Open Portability Guide,
an earlier standardisation effort.)
By the way, I don't think that anybody yet conforms to SPEC-1170, but
many claim to be working towards it. I've seen announcements of ``97%
conformance'', which I presume means that they conform to all but
thirty-odd interfaces. These could be the ones that are VERY HARD, of
course, and if you are trying to port some software which needs one of
them, then the fact that it's not there might matter a lot.
Simon Ritchie
Darren R. Davis
My the way, what David outlined about is basically the suggestion Novell
UnixWare Developer Support gives. Use dynamic libraries whenever possible.
Darren R. Davis
Novell UnixWare Developer Support
< I admit I did DOS once, but I assure you I didn't inhale. >
Any opinions expressed are my own, and may not represent those of Novell's.
Mats Wichmann
>James Vlcek (vl...@epimbe.com) wrote:
>...deleted
>> >to something called "AT&T's System V Interface Definition
>> >SVIDIII" and "Spec1170". Can anyone give me a pointer to more
>> >information about these? Where can I find these specs; or at least,
>> >where can I find summaries of them?
>> Loosely speaking, SVID was an AT&T Unix Systems Labs definition of the
>> system interfaces for System V Unix. I don't know where you might
>> find a copy of SVIDIII, and suspect it might be very tiresome reading
>> if you did.
> deleted...
>The 5 volumes of the SVID 3rd edition are/were published/distributed
>by Prentice Hall (in the same dark blue jackets that the original SVR4
>docs were published.) These manuals document small parts of SV4.x not
>otherwise conveniently documented.
Just in case anyone _really_ cares, here are the ISBN numbers.
There are 6 volumes now, 1-4 are the base document, 5 is additiona
and corrections, and 6 is a Transaction Processing supplement.
@cite{Volume I, ISBN 0-201-56652-4} ;
@cite{Volume II, ISBN 0-201-56653-2} ;
@cite{Volume III, ISBN 0-201-56654-0} ;
@cite{Volume IV, ISBN 0-201-56655-9} ;
@cite{Volume V, ISBN 0-201-56656-7} ;
@cite{Volume VI, ISBN 0-201-52480-6} ;
@cite{Set, Volumes I-V, ISBN 0-201-58225-2} ;
@cite{Set, Volumes I-VI, ISBN 0-201-58226} .
A shrink-wrapped set of all six volumes will set you back somewhere
in the $240 range (ugh!).
There's a SVID 4th Edition in the works. I'm unclear if that was
going to be fully aligned with SPEC 1170 or not - I'd imagine not.
-- mats
--
Mats Wichmann
Software Consultant
ma...@netcom.com
Evan Leibovitch
>In an earlier follow-up Jim Vlcek explained that SPEC-1170, the new
>common UNIX specification is available from X-Open, which is based in
>England. (I'm posting this from home, so I don't have the address
>and I can't even remember which town.) It's so called because it
>defines 1170 interfaces to the operating system.
X/Open Company Ltd.
Apex Plaza, Forbury Road, Reading, Berks RG1 1AX, United Kingdom
+44 734 508311
1010 El Camino Road, Suite 380, Menlo Park CA 94025 USA
+1 415 3237992
>I understand that SPEC-1170 is not available as a paper document, but
>only available via FTP or on CD-ROM. The FTP version is not free: they
>charge you a fee for a password which allows you to connect up and pull
>the stuff off. The CD-ROM version expects a Windows PC.
At UniForum I saw the CD, which contains *all* X/Open specifications
(including previous XPGs).
Not only does it require Windows, but the files are pre-formatted in a
manner unusable by any known Unix software. I met the jerk (IMO) who
wrote the (TOTALLY PROPRIETARY) software for reading and extracting
documents from the CD. Neither he nor the X/Open bureaucrats I spoke to
there understood the irony of a group whose only business was to promote
standards, having a proprietary non-standard method of accessing its
documents, readable only on a system which meets none of its standards.
IMO the people at X/Open have their heads firmly up their asses.
--
Evan Leibovitch, Sound Software Ltd., located in beautiful Brampton, Ontario
Novell Unix Master Reseller / ev...@telly.on.ca / (905) 452-0504
PCMCIA: People Can't Memorize Computer Industry Acronyms
Mats Wichmann
>In <32oo6i$e...@delphinium.cig.mot.com> ki...@wildebeest.cig.mot.com writes:
>> ... to something called "AT&T's System V Interface Definition
>>SVIDIII" and "Spec1170". Can anyone give me a pointer to more
>>information about these? Where can I find these specs; or at least,
>>where can I find summaries of them?
>The SVID and SPEC-1170 are Applications Programming Interfaces (APIs).
>In other words, they describe the interfaces to UNIX that an
>application programmer sees - essentially a formal description of the
>system calls and the standard functions. If you conform to one of
>these then your source code is portable across versions of UNIX which
>conform. It does not, by the way, guarantee binary compatibility,
>which requires conformance to an ABI as well as an API.
>In an earlier follow-up Jim Vlcek explained that SPEC-1170, the new
>common UNIX specification is available from X-Open, which is based in
>England. (I'm posting this from home, so I don't have the address
>and I can't even remember which town.) It's so called because it
>defines 1170 interfaces to the operating system.
>I understand that SPEC-1170 is not available as a paper document, but
>only available via FTP or on CD-ROM. The FTP version is not free: they
>charge you a fee for a password which allows you to connect up and pull
>the stuff off. The CD-ROM version expects a Windows PC.
>I believe that the spec is not yet completely tied down and that this
>is a fairly mature snapshot.
It's about $120 for ftp access. The spec is complete, but the
completed spec won't be available for about another two months,
the current version is still a pre-approval snapshot.
Jim Vlcek
> [talk of various SVR4 flavors of Intel UNIX]
> This isn't such a big issue with static compiled programs but yes it
> is a problem with shared libs.
IMO, an ABI is useless if you've got to distribute apps compiled
statically. Which, practically speaking, means that all of the UNIX
iABIs are worthless.
Much more important, to me at least, is source compatibility. You
can spend a few thousand to buy another Intel box to run UnixWare
on, or you can spend tens of thousands in support costs trying to
get your SCO binaries to run atop UnixWare.
I've long since given up any hope that an Intel UNIX ABI will do me
any good. I anticipate that the market will bury all but one of
them, or (more likely) NT will bury them all.
--
Jim Vlcek I came,
vl...@byteware.com I saw,
The Black Box of Lowertown I posted.
Beautiful downtown St. Paul
Terry Lambert
[ ... Re: SPEC 1170 ... ]
] It's about $120 for ftp access. The spec is complete, but the
] completed spec won't be available for about another two months,
] the current version is still a pre-approval snapshot.
And we are all saddened at the passing of UNIX International, who had the
draft of SPEC 1170 up for anonymous FTP on uiunix.ui.org before their
sad demise.
A moment of net.slience.
...of course, there are those of us who have squirreled away large pieces
of that archive, but have no place that will give the documents a good
home and maintain them properly.