les@chinet.chi.il.us (Leslie Mikesell) (02/13/90)
Can anyone tell me if it is possible to run a '286 Xenix executable linked with the unify libraries under '386 unix SysVr3? Or, is it possible to re-compile and re-link on the 386 (to the 286 version of the library). The 386 linker doesn't seem to like the 286 library files. The original developer of the application isn't around any more and the user is reluctant to switch to the 386 version because he believes the application relies on quirks of that specific '286 version. I don't know enough about unify to be of much help. Les Mikesell les@chinet.chi.il.us
cpcahil@virtech.uucp (Conor P. Cahill) (02/14/90)
In article <1990Feb13.040254.7988@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >Can anyone tell me if it is possible to run a '286 Xenix executable >linked with the unify libraries under '386 unix SysVr3? Or, is >it possible to re-compile and re-link on the 386 (to the 286 version >of the library). The 386 linker doesn't seem to like the 286 library >files. The original developer of the application isn't around any >more and the user is reluctant to switch to the 386 version because >he believes the application relies on quirks of that specific '286 >version. I don't know enough about unify to be of much help. You can probably run the executable without much problems, however your 286 license for unify is not valid for running the database (and associated software) on a 386 unix system. You can probably get a an upgrade to 386 unify (you actually get some trade-in credit for the old version). But barring licensing problems, you should be able to run most Xenix software (both 286 and 386) under System V R3.2. However you can't run any 8086 Xenix binaries. Unify is written for, and ported to, many Unix architectures, so it makes little use of special quirks of the operating system. -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
reg@unify.uucp (Russell Grau) (02/17/90)
In article <1990Feb13.040254.7988@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >Can anyone tell me if it is possible to run a '286 Xenix executable >linked with the unify libraries under '386 unix SysVr3? Or, is >it possible to re-compile and re-link on the 386 (to the 286 version >of the library). The 386 linker doesn't seem to like the 286 library >files. The original developer of the application isn't around any >more and the user is reluctant to switch to the 386 version because >he believes the application relies on quirks of that specific '286 >version. I don't know enough about unify to be of much help. > >Les Mikesell > les@chinet.chi.il.us According to the SCO Xenix System V manual "C Language Guide" pages 2-4 and 2-5 it should be possible. You would need to link with the -Ml and -M2 options so the code that would be produced would be 80286 code. The default for the 386 compiler is to produce the 80386 instruction set. This would explain why it would appear not to like your 286 code. I do have one question though: in the source code that is being used, do you have any special calls to the BIOS or any device drivers that are dependent on your C code? If you do not, then it should go across with just a little effort. In the meantime, the code should work as is. Your user could try the switch and if it appears to work he would definitely be better off. The reason for this is that he has a 386 machine running 286 code. Not quite as efficient in the use of the CPU. Russell Grau (916) 920-9092 reg@unify.UUCP Disclaimer - "There's another dead bishop on the landing Mum!" - Monty Python {{ucdavis,csun,lll-crg}!csusac,pyramid,sequent}!unify!reg -- Russell Grau (916) 920-9092 reg@unify.UUCP Disclaimer - "All opinions are my own, and occasionally someone else's" {{ucdavis,csun,lll-crg}!csusac,pyramid,sequent}!unify!reg
les@chinet.chi.il.us (Leslie Mikesell) (03/02/90)
In article <kll8yp6@unify.uucp> reg@unify.UUCP (Russell Grau) writes: >>Can anyone tell me if it is possible to run a '286 Xenix executable >>linked with the unify libraries under '386 unix SysVr3? >According to the SCO Xenix System V manual "C Language Guide" pages 2-4 and >2-5 it should be possible. You would need to link with the -Ml and -M2 options >so the code that would be produced would be 80286 code. >The default for the 386 compiler is to produce the 80386 instruction set. >This would explain why it would appear not to like your 286 code. 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? >In the meantime, the code should work as is. Your user could try the >switch and if it appears to work he would definitely be better off. The >reason for this is that he has a 386 machine running 286 code. Not quite >as efficient in the use of the CPU. The applications that are straight unify code work fine. The program that has a problem runs up to a point where a number is typed in (possibly a floating point emulation problem in the 'C' portion of the code). 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. 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. Les Mikesell les@chinet.chi.il.us
cpcahil@virtech.uucp (Conor P. Cahill) (03/02/90)
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 | +-----------------------------------------------------------------------+
reg@unify.uucp (Russell Grau) (03/06/90)
In article <1990Mar1.170952.7880@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <kll8yp6@unify.uucp> reg@unify.UUCP (Russell Grau) writes: > >>>Can anyone tell me if it is possible to run a '286 Xenix executable >>>linked with the unify libraries under '386 unix SysVr3? > >>According to the SCO Xenix System V manual "C Language Guide" pages 2-4 and >> ... deleted some items here to shorten it up ... > >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? > > >The applications that are straight unify code work fine. The program that >has a problem runs up to a point where a number is typed in (possibly a >floating point emulation problem in the 'C' portion of the code). >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. >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. > >Les Mikesell > les@chinet.chi.il.us I am unaware of any calls that will allow you to link the items together. This is assuming that you are talking about the Interactive port of Unix and not the SCO port of Unix. There are no flags that are available to change the SCO Xenix libraries into AT&T/Interactive Unix libraries (at least none that I am aware of). Are these bugs in the Unify code or are they in the SCO code? Which version of Unify software are you currently executing? Since the work-arounds are there in the code, what do they work-around? I would strongly suggest that the user consider upgrading to the software that is made for the computer/OS. Performance is not the reason, but the ability to adequately maintain and upgrade your software would be. Please post a followup so I can at least know how you are doing. -- /*****************************************************************************/ /* Russell Grau (916) 920-9092 reg@unify.UUCP */ /* Disclaimer - "I speak for myself, not my company" */ /* {{ucdavis,csun,lll-crg}!csusac,pyramid,sequent}!unify!reg */