Status Of Binary Compatibility Between Intel-Based UNIX
Sean Eric Fagan
>I don't believe that the FSF is endorsing any Open System Standards
>(POSIX, etc.) much less any binary compatibility specs--their goals
>are significantly different than those companies which are properly
>UNIX System vendors.
Now, as much as I hate to accuse SCO of deliberately spreading
misinformation, that's what springs to mind here. RMS and the FSF have
claimed, since time immemorial, that they would support POSIX; take a look
in comp.std.unix, about three weeks ago, for a bunch of postings related to
that. In addition, they have stated, publicly, several times, that GNU HURD
(their OS) would be binary compatible with BSD 4.4. While this is only of
minor import for the '386, it *is* a binary compatibility issue -- and a
fairly standard one at that. Note also that, since HURD is based on
Mach3.0, it would not be impossible to write a XENIX or iBCS-2 server --
given all the code you'll be able to borrow from the GNU code, it should
even be almost easy.
I hope Tim's statements were made out of ignorance, not out of an attempt to
mislead people.
--
Sean Eric Fagan | "I made the universe, but please don't blame me for it;
s...@kithrup.COM | I had a bellyache at the time."
-----------------+ -- The Turtle (Stephen King, _It_)
Any opinions expressed are my own, and generally unpopular with others.
Tim Ruckle
In article <46...@cup.portal.com> Wi...@cup.portal.com (Will E Estes) writes:
} Can someone give me the status of the Intel-proposed standard for
} binary compatibility for programs run on UNIX implementations
} that run on the Intel architecture?
}
} When will the following vendors supply a UNIX implementation that
} complies with this standard:
}
} - SCO
} - Interactive
} - Sun (i.e., the PC-based SunOS that SunSoft just announced)
} - GNU (Free Software Foundation)
}
Intel issued a press release during the SCO Forum91 announcing the
availability of the iBCS-2 (Intel Binary Compatibility Specification
Edition 2). iBCS-2 was announced in August '90 by Intel, SCO, and USL
as a consolidated effort to define a specification which will enable
binary application compatibility and migration between SCO-based
SVR3.2 and SVR4 platforms.
iBCS-2 captures the common SCO interfaces which are included in the
base release of SCO SVR3.2, and details a common and consistent
set of binary interfaces for SCO-based SVR3.2 and compatible SVR4
offerings for industry-standard i386 and i486 hardware platforms.
It is compliant with the X/Open XPG3, IEEE POSIX 1003.1, and FIPS 151-1
POSIX standards. Operating systems which conform to the specification
are fully compatible with the over four thousand applications currently
running on SCO UNIX and XENIX. Applications compliant with the iBCS-2
give developers access to an installed base of more than 500,000 systems.
Edition 2 extends the binary compatibility of iBCS-1 (the so-called
"merged" product capable of running either UNIX System COFF or XENIX
OMF formats) to include the way applications are installed, the way
they interface with the hardware, and the way their runtime behavior
is controlled by the operating system.
According to the Intel press release, iBCS-2 Test Suites are under
development and will be available in early '92.
The iBCS-2 specification itself is available right now for system and
software developers through Intel's toll-free number, 1-800-548-4725
(Literature Order Number 468366-001). The spec will be published by
McGraw Hill and available in Q4 '91.
Only development systems based on UNIX System V Release 3.2 (including
any release of SCO UNIX System V/386 or SCO Open Desktop) or SCO XENIX
currently support the creation of iBCS-2 compliant binaries.
SCO UNIX Release 3.2 operating system is already in conformance with most
of the standard and will be wholly compliant in the next release.
ISC is currently iBCS-1 compliant, and has announced that their customer
shipment of SVR4.0.4 will be iBCS-2 compliant.
To date there has been no specific commitment from the other companies
with SVR4 offerings (DELL, UHC, Microport, certain OEMs) regarding support
for iBCS-2. USL has committed to making the technology available to SVR4
licensees.
SunSoft has announced that Solaris 2.0 for Intel will be compliant with
the iABI. They have not announced any specific commitment to iBCS-2.
SVR4 does support the iABI specification (the Intel Application Binary
Interface). iABI is one of several ABIs specified with SVR4, each
processor reference port having its own ABI. iABI differs from iBCS-2
in that it is limited to only the SVR4 operating system and thus is not
backwards compatible.
iBCS-2, in addition to specifying all the applications layers included
in the iABI, describes the standard devices and input/output controls
required for application portability.
I don't believe that the FSF is endorsing any Open System Standards
(POSIX, etc.) much less any binary compatibility specs--their goals
are significantly different than those companies which are properly
UNIX System vendors.
OSF is a member of the iBCS-2 Review Group, and has announced its
commitment to establish compatibility with XENIX System V and UNIX
System V/386 environments in the OSF/1 operating system.
The goal of "shrink wrap" software for the open systems marketplace will
not be possible without the commitment of the entire industry to achieve
full binary compatibility. This requires more than just the ability for
binaries to run on a given kernel--it must address system installation
scripts, I/O control instructions to devices, and the availability of
standard system commands.
For the benefit of the entire user base, as well as the industry as a
whole, SCO encourages all UNIX System vendors for Intel processors to
join SCO, USL, Intel, ISC and OSF in supporting the iBCS-2 standard for
x86 applications.
Tim Ruckle
--
Usenet: !{uunet,ucbvax!ucscc,decvax!microsof}!sco!timr, ...!mcsun!ukc!scol!timr
Internet: [MX handlers] ti...@sco.COM [others] timr%sco...@ucscc.UCSC.EDU
USPS: The Santa Cruz Operation, 400 Encinal Street, Santa Cruz, CA 95061-1900
PSDN: [voice] (408) 425-7222 [fax] (408) 458-4227 [twx] 910-598-4510 SCO SACZ
Guy Harris
>in that it is limited to only the SVR4 operating system and thus is not
>backwards compatible.
And also thus:
1) has 32-bit inode numbers in "stat" structures and the like (and yes,
plenty of file systems out there have >65535 files on them);
2) is based on dynamic linking to procedures rather than traps to the
kernel, so that kernel functions aren't the only ones whose
implementation can be changed out from under an application (e.g.,
you could have the same binary run on a system whose "getpwnam()"
scanned "/etc/passwd", or whose "getpwnam()" used NIS, or whose
"getpwnam()" used Hesiod, or..., and use the system's native
"getpwnam()" automatically);
among other things.
Tim Ruckle
In article <1991Sep25....@kithrup.COM>
s...@kithrup.COM (Sean Eric Fagan) writes:
} In article <20...@scorn.sco.COM> ti...@sco.COM (Tim Ruckle) writes:
} >I don't believe that the FSF is endorsing any Open System Standards
} >(POSIX, etc.) much less any binary compatibility specs--their goals
} >are significantly different than those companies which are properly
} >UNIX System vendors.
}
} Now, as much as I hate to accuse SCO of deliberately spreading
} misinformation, that's what springs to mind here. RMS and the FSF have
Nothing deliberate Sean: I didn't know that to be the case, and obviously
did not do my homework well enough on that one.
I'm very glad to learn that they will support POSIX.
} [...]
} Note also that, since HURD is based on Mach3.0, it would not be impossible
} to write a XENIX or iBCS-2 server -- given all the code you'll be able to
} borrow from the GNU code, it should even be almost easy.
Are you volunteering? ;^)
} I hope Tim's statements were made out of ignorance, not out of an attempt to
} mislead people.
Entirely the former. Thank you for setting me straight,