Return to BSD News archive
Newsgroups: comp.os.386bsd.apps Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msuinfo!agate!headwall.Stanford.EDU!kithrup.com!sef From: sef@kithrup.com (Sean Eric Fagan) Subject: Re: Will BSD run BIN files from other OP sys. Organization: Kithrup Enterprises, Ltd. Message-ID: <Csn4Ct.2Hw@kithrup.com> References: <2vf01r$ffn@herald.indirect.com> Date: Fri, 8 Jul 1994 21:14:52 GMT Lines: 43 In article <2vf01r$ffn@herald.indirect.com>, Data Cal Corp. <datacal@indirect.com> wrote: >I would like to know if I can take a bin from a SCO box and have it run >on BSD? I thought that I had seen this somewhere. Just mainly out of >couriosity. No and yes. I and one other person in the FreeBSD camp have gotten some SCO programs to run. The job is not, by any means, complete -- I can, for example, run an SCO gcc (the driver program), but there is something not quite right with it. I have also been able to run a SysVr4 ELF program -- if I could get an ELF shared library compiled up, and an ELF ld.so.1, that would probably end up being easier than the SCO one. BSDi apparanly has some commercial SCO applications running, but their code isn't released yet (well, neither is mine and Soren's :)). We hope to be able to put it out on the net soon, so that we can get other people to make it work, instead of slaving over it ourselves. But we want to be able to run some real programs, first. (If I can ever run gcc correctly, I think that will qualify well enough for a beta release. It doesn't help that our SCO machine at work is now dead :).) From a technical point of view, the hard part is doing the system call wrappers and the execution environment. Some things are just subtly different (signal numbers and errno values, for example); other things are extremely different (signal semantics). Some things just don't exist in BSD but do in SCO (shared memory, semaphores, NSL/TTI networking, etc.), and I cannot do them very well or easily. And the ioctl stuff is a nightmare in and of itself (slightly to wildly different semantics, things not implemented in BSD, etc.). We currently have, I believe, 20 system calls that are "unimplemented". They include message IPC and RFS stuff, non-iBCS2 shared libraries, and a few other things. Soren Schmidt has done an incredible job is writing a lot of wrappers (including ioctl and getdents, both of which are a real pain). Anyway, about 70% of the job is done, I'd say. Which means it'll take about five years to do the remaning 30% 8-).