System V release 3.2

[Tim W Smith]

< In theory this should be very easy. You can create a directory tree,
< containing, say Xenix 286 on a Unix 3.2 machine. After logging in (as root)
< you chroot to the root of that tree and from then on you should get
< 100% identical Xenix behaviour except for speed differences. That is
< what my understanding of this binary compatibility is. In this isolated
< directory tree you could run the Xenix compiler (without messing around
< with filename problems), to generate Xenix binaries.

I used to do this when I worked at ISC, except that it was not a 3.2
machine, since those didn't exist yet.  We did it on a 1.05 machine,
since all that x286emul needs to run most 286 Xenix code is the kernel
hooks that let x286emul get control when a system call is executed.

The x286emul emulation is pretty good.  It passes Microsoft's Xenix
validation programs.  That is, if you take these programs from a
286 Xenix system, and put them under such a chrooted environment,
and run them just like you would to validate a 286 Xenix system,
it will pass, except for certain tests that are not expected to
pass.

I don't recall exactly which tests will not pass, but they tended
to be tests of the type where a real Xenix system would return
the error ETXTBSY.  Because of the way Xenix emulation works, the
text is in fact not busy when a Xenix binary runs under x286emul.

My memory is getting hazy here, and I may be confusing some details
with i286emul, but I think that there will also be failures when
execute-only programs are used.  x286emul is a user mode program,
and so it needs read permission on the Xenix binary to access it.
I seem to recall some discussion of various ugly kludges to get
around this, but I don't recall if they were used or not.

						Tim Smith