From: bsa@kf8nh.wariat.org Subject: Re: Binary compatibility with other *nix Date: Sun, 14 Mar 1993 15:02:13 GMT
In article <1nj292INNmev@shelley.u.washington.edu> tzs@stein2.u.washington.edu (Tim Smith) writes:
>I think some of the techniques that ISC Unix used to provide 286 binary
>compatibility could be adapted to work on binary compatibility for 386
>programs. To give people ideas, this post will describe how the 286
>binary compatibility worked on ISC Unix. (I sure hope I'm remembering
>two things right: (1) the technical details, and (2) when my non-disclosure
>agreement expired!) Then I'll talk about what might be involved in
>doing 386 compatibility this way.
SCO does it this way as well --- it may even be the same code --- and I didn't
need to look at kernel source to determine it, I just RTFM'ed :-) and played
with it a bit.
I suspect it's not as likely to work for 386 emulation as you think, though:
there are too many chances for collision.
I looked (note: LOOKED. I have no plans to write code) at what it would take
to have Linux run SCO binaries. I cane to the conclusion that, since SCO
binaries almost always use /shlib/libc.sa, the best way to do it at present
would be to load the program, cause a compatibility shared library to be
mapped in place of libc.sa, and just let it run. (A scheme resembling how
Solaris runs SunOS4 binaries, except that a program would be "pushed" in front
of the actual program to be run, as in ISC's 286 emulator, so that I don't
have to teach the kernel how to load COFF files when that's all it would end
up knowing. Unless someone *really* wants native Linux programs in COFF
format... :-) Since all system calls are made via routines in the shared
library, the compatibility library would handle translating data formats
(structure definitions, etc.) between the two and would issue normal Linux
system calls.
This would work only because most programs use the shared library. A program
that didn't use the library would not be able to run (the COFF mapper would
report an error because libc.sa wasn't mapped). This might work with other
commercial 386 *ix'es, as long as libc is a shared library.
Were it supported, it would be better and perhaps simpler to use an executable
switch in the kernel to select system call tables, file formats, etc. Except
that you have to come up with a libc.sa, and I don't think either SCO or ISC
would be happy about theirs being included with the exec-switch package....
++Brandon