iBCS(9)

NAME
iBCS - loadable module to allow execution of other x86 Unix binaries

SYNOPSIS
insmod iBCS

DESCRIPTION

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 extensions to SVR3 which are slightly different and incompatible. The iBCS emulator for Linux supports all flavours known so far and some extensions.

With the iBCS module loaded you can run most programs compiled for Intel based Unices other than Linux. This is completely transparent. All you do is run the program as normal.

SUPPORTED CPU ARCHITECTURES

    Intel 386/486/Pentium and compatibles

    Sparc

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 alpha.

    SVR4 (Interactive, Unixware, USL, Dell etc.)

    SVR3 generic

    SCO (SVR3 with extensions for symlinks and long filenames)

    Wyse V/386 (SVR3 with extensions for symlinks)

    Xenix V/386 (386 small model binaries only)

    Xenix 286

SUPPORTED SUBSYSTEM EMULATIONS

    SYSV IPC

    /dev/socksys socket interface as used by the Lachman STREAMS based networking implementation.

    Wyse V/386 system call socket interface.

    /dev/spx STREAMS device for connections to local X server.

    TLI devices for IP.

BUGS

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 networking interfaces. Since Linux does not use STREAMS at all this is something of a kludge. It should be sufficient 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 under Linux.

FILES

/lib/modules/`uname-r`/misc/iBCS
    default location for the iBCS module

SEE ALSO
insmod(1) kerneld(8) modprobe(1)

AUTHOR

Mike Jagdis <jaggy@purplet.demon.co.uk>.

Based on original work by Eric Youngdale, Alfred Longyear, Drew Sullivan, Joseph L. Portman III and others.