Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!virtech!cpcahil
From: cpcahil@virtech.uucp (Conor P. Cahill)
Newsgroups: comp.databases
Subject: Re: 386 unix vs. 286 xenix unify
Message-ID: <1990Mar2.130457.23195@virtech.uucp>
Date: 2 Mar 90 13:04:57 GMT
References: <kll8yp6@unify.uucp> <1990Mar1.170952.7880@chinet.chi.il.us>
Reply-To: cpcahil@virtech.UUCP (Conor P. Cahill)
Distribution: na
Organization: Virtual Technologies Inc., Sterling VA
Lines: 50

In article <1990Mar1.170952.7880@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes:
>
>I have AT&T unix SysVr3.2, not Xenix for the 386.  Is there a way to
>convince its loader to handle the xenix library files?

What I did to solve the same problem is:

	copy all of the xenix OS into it's own directory on my unix system
	rm /that_dir/dev
	copy all of /dev to /that_dir/dev
	copy /unix to /that_dir/unix
	use file(1) to deterimine which xenix binaries are 8086 binaries and
		copy the same binary from your unix binaries to replace the
		xenix binary
	chroot to that directory

	and there you go.  You can now compile using the xenix compiler and
	the executable will work under Unix as long as you don't tell the 
	compiler to generate an 8086 executable.

One bad side effect of doing this is that you cannot debug a core file
because the UNIX debuggers do not understand the Xenix binaries and the
Xenix debuggers do not understand the UNIX core files.

>The problem with upgrading is that the application depends on quirks
>in an old '286 version (or as they put it: "works around bugs") and wouldn't
>run when they tried to upgrade to a newer 286 version some time ago
>so they expect the same from the current '386 version.

I would still recommend biting the bullet and upgrading to a current version.  
If you continue to run an old application under a very old version of the
DBMS you can expect to run accross other bugs that have been fixed in the
current versions and you won't be able to take advantage of any new features
that have been added.

>The original programmer is no longer around and no one wants to tackle
>modifications beyond recompiling the C code and re-linking if that is
>possible.  Performance isn't really an issue.

Drop us a line.  We'll do the port (For a fee, of course)

>Les Mikesell
>  les@chinet.chi.il.us


-- 
+-----------------------------------------------------------------------+
| Conor P. Cahill     uunet!virtech!cpcahil      	703-430-9247	!
| Virtual Technologies Inc.,    P. O. Box 876,   Sterling, VA 22170     |
+-----------------------------------------------------------------------+