iBCS - loadable module to allow execution of other x86
The Intel Binary Compatibility Specification, or iBCS,
specifies the interfaces between application programs and
the surrounding operating system environment for i386
based systems. There are however several flavours of iBCS
in use - SVR4, SVR3 plus several vendor specific exten-
sions to SVR3 which are slightly different and incompati-
ble. The iBCS emulator for Linux supports all flavours
known so far and some extensions.
With the iBCS module loaded you can run most programs com-
piled for Intel based Unices other than Linux. This is
completely transparent. All you do is run the program as
SUPPORTED CPU ARCHITECTURES
Intel 386/486/Pentium and compatibles
SUPPORTED BINARY FORMATS
A.OUT (used by Linux and BSD)
ELF (used by SVR4 flavours and SCO OS5)
COFF (used by SVR3 flavours)
XOUT (used by Xenix)
SUPPORTED OS EMULATIONS
i386 BSD (386BSD, FreeBSD, NetBSD, BSDI/386) - very
SVR4 (Interactive, Unixware, USL, Dell etc.)
SCO (SVR3 with extensions for symlinks and long
Wyse V/386 (SVR3 with extensions for symlinks)
Xenix V/386 (386 small model binaries only)
SUPPORTED SUBSYSTEM EMULATIONS
/dev/socksys socket interface as used by the Lach-
man STREAMS based networking implementation.
Wyse V/386 system call socket interface.
/dev/spx STREAMS device for connections to local X
TLI devices for IP.
There are two many bugs. Most people will be unlikely to
encounter any of them however.
Unix variants with non-standard extensions which are not
SVr4, SCO or Wyse will not be recognised and may fail
unexpectedly. A new personality may need to be built.
The recognition of SCO and Wyse binaries is dependent on
comment strings embedded in the binary at compile time. If
these strings are missing or not as expected the binary
may not be recognised correctly and may fail unexpectedly.
It is also possible that binaries from other systems may
be misrecognised although given the strings used this
should be unlikely.
Some Xenix functions are unimplemented, in particular
Xenix semaphores and shared memory.
There is some basic support for STREAMS and XTI/TLI net-
working interfaces. Since Linux does not use STREAMS at
all this is something of a kludge. It should be suffi-
cient for most programs though.
Programs, applications or packages which require modules
or device drivers to be linked in to the kernel will not
work. Linux is not based on SYSV code and does not have
SYSV internals. The driver would need rewriting for use
default location for the iBCS module
insmod(1) kerneld(8) modprobe(1)
Mike Jagdis <email@example.com>.
Based on original work by Eric Youngdale, Alfred Longyear,
Drew Sullivan, Joseph L. Portman III and others.
7 Nov 1995 1