Technology and Trends
 USENET Archives
Newsgroups: comp.os.linux.announce
From: (Eric Youngdale)
Subject: iBCS2 now in public ALPHA testing.
Message-ID: <>
Followup-To: comp.os.linux.misc
Keywords: iBCS2 SCO SVr4 binaries Kernel
Sender: (Matt Welsh)
Reply-To: (Eric Youngdale)
Organization: Free Software Foundation / Cambridge, MA  USA
Date: Tue, 5 Apr 1994 05:32:18 GMT
Approved: (Matt Welsh)
Lines: 90

	IBCS2 code now in public ALPHA testing.

	I have uploaded the latest snapshots of the code that has been
developed by the iBCS2 team to tsx-11.  Up until now, all of this has
been kept in private directories because things were not sufficiently
mature to be of general use.  With this release, the development code
will now appear in the directory pub/linux/ALPHA/ibcs2, and will be
publicly visible (and mirrored) and be more generally available.
There is one important caveat - THIS CODE IS STILL ALPHA.  It may not
work for some applications, and it may do bad things.  The point of
the more public release is to get more people to try it and see how
well it works, develop a track record, and identify further problem
areas.  Please do not assume that all applications will run for you.

	That being said and my backside being covered, one of the
people on the iBCS2 team has the SCO version of WordPerfect, and he
reported that it runs correctly, even under X.  If nothing else, this
by itself stands as an important accomplishment.  Also a number of
SVr4 binaries (including a handful of X binaries) are known to work
correctly, including some commercial applications, but I would need to
dig through my mail to figure out exactly which ones.

	For those of you that do not know, iBCS2 is the standard that
is used by SVr3 to define the interface betweeen user applications and
the kernel.  It has been extended somewhat, and is used in one form or
another by SCO Unix, the Wyse flavor of Unix and the various flavors
of SVr4.  The goal of the project has been to be able to directly run
binaries from these other flavors of Unix on a linux box.  Some of the
components are already in the distribution kernel as of linux 1.0 -
(i.e. the COFF and ELF program loaders), and has been a stub in the
ibcs2 directory to catch lcall 7,0 instructions for quite some time.
The iBCS2 emulator is the piece that translates these syscalls so that
the linux kernel can do the right thing, and this can be found in the
file ibcs-94????.tar.gz.  There are installation instructions
available inside of the package.  Note: the iBCS2 emulator can be
configured either as a builtin part of the kernel, or as a loadable
module if you do not wish to permenantly bloat your kernel.

	The next point is that many iBCS2 binaries will require shared
libraries.  Many SCO binaries are staticly linked (i.e. WordPerfect),
and in these cases you can skip the rest of this paragraph.  With SVr4
binaries and the ELF format, you will find that the use of shared
libraries will be much more common - perhaps even universal.  Part of
the iBCS2 effort has been to develop a iBCS2 compliant version of libc
which could be built into shared libraries and used for those
applications that require it.  The source tree for the iBCS2 compliant
library should be available in the same directory that the ibcs2
emulator code can be found.  Note that very limited support is
available for networking applicatons that use the network services
shared library libnsl.

	If you need shared libraries for SVr4 binaries, they are
available, and they work with many applications.  Precompiled versions
of, and are available (the library
itself must be built on a SVr4 machine - there are not yet tools for
linking ELF shared libraries under linux).  The networking support is
present and it works as long as the application uses a sockets for
communication, and does not attempt to do anything fancy with
functions in libnsl.  If you need shared libraries for X11, you can
obtain precompiled versions of XFree86 for SVr4 from several ftp
sites.  Applications that use sockets can effectively bypass much of
the stuff that would normally be in as there is direct
support for sockets in the linux kernel, and the ELF shared library directly uses these functions.

	The current status of this writing is that if you need shared
libraries for SCO binaries you may be out of luck.  If your SCO
license permits it (assuming you have SCO), you may copy the shared
library from that machine to your linux box and use it and it will
work.  There are some knotty problems in stdio that are specific to
the SCO version of the shared library, and until these get solved the
shared library that is generated from the source tree may be of
limited use for SCO applications.  Once again, there is no support for
applications that use the shared library.

	A list of applications that are known to work will be
periodically stored on tsx-11 so that you have some idea what the
situation is before you plunk down cash and actually buy something.
If you happen to have some application lying around, and you try it,
please report the results.  Any success stories will be added to the
list.  If you encounter any problems, and wish to dig in and try and
fix it yourself, please feel free to give it a try and report the
results back.  If you have problems please report them, and by all
means feel free to actually solve it (and report the results) instead
of waiting for someone else to do it for you.