sullivan@vsi.UUCP (Michael T Sullivan) (07/14/88)
We have an AT&T 6386 that we _need_ Informix's C-ISAM for. Problem
is that Informix has ported C-ISAM to Microport V/386 but not to
Interactive 386/ix. They're not sure whether to Microport package
will run on the Interactive but are shipping it to us so we can
give it a try (obviously if it doesn't work we just send it back).
This brings up a question or two:
1) CAN the two be compatible if things are done a certain way
or is it just impossible?
2) How does this relate to the whole ABI concept?
3) (Just to be picky) Why doesn't Informix know whether they are
or not? I assume they should be much more in touch with these
things than some sleazy programmers in Santa Ana.
Send your answers and comments to me directly. If you'd like to know
what I received send me mail and if there's enough interest I'll post
a summary, otherwise I'll reply directly.
--
Michael Sullivan {uunet|attmail}!vsi!sullivan
V-Systems, Inc. Santa Ana, CA sullivan@vsi.com
ons, workstations, workstations, workstations, workstations, workstations, worksullivan@vsi.UUCP (Michael T Sullivan) (08/18/88)
On July 13 I posted the following: > We have an AT&T 6386 that we _need_ Informix's C-ISAM for. Problem > is that Informix has ported C-ISAM to Microport V/386 but not to > Interactive 386/ix. They're not sure whether to Microport package > will run on the Interactive but are shipping it to us so we can > give it a try (obviously if it doesn't work we just send it back). I'd like to summarize answers to the questions I raised: > 1) CAN the two be compatible if things are done a certain way > or is it just impossible? The two are compatible. We have been running the uPort package on the 6386 for several weeks and it is running just fine. The concensus was that since uPort and 386/ix were based on Intel's port of Unix, the binaries should be compatible. This appears to be the case. > 2) How does this relate to the whole ABI concept? To paraphrase someone who responded, ABI is planned compatibility--this (uPort vs. 386/ix compatiblity) is just coincidence. > 3) (Just to be picky) Why doesn't Informix know whether they are > or not? I assume they should be much more in touch with these > things than some sleazy programmers in Santa Ana. Who knows. We had the salesperson check with the techie people (allegedly) and they were still unsure. Guess we're not so sleazy after all (I'd like to think I still am, though :-). Thanks to all who responded and apologies to those who asked for this summary for my slowness in posting it. -- Michael Sullivan {uunet|attmail}!vsi!sullivan V-Systems, Inc. Santa Ana, CA sullivan@vsi.com "Your mother was a hamster and your father smelled of eldeberries! Pbbbt!"
woods@gpu.utcs.toronto.edu (Greg Woods) (08/20/88)
[ I'm getting VERY tired of rn stripping the "Toronto.EDU" from my address, and putting ".UUCP" there. This is WRONG. ] In article <802@vsi.UUCP> sullivan@vsi.UUCP (Michael T Sullivan) writes: > The two are compatible. We have been running the uPort package on the 6386 > for several weeks and it is running just fine. The concensus was that > since uPort and 386/ix were based on Intel's port of Unix, the binaries > should be compatible. This appears to be the case. > > > 2) How does this relate to the whole ABI concept? > > To paraphrase someone who responded, ABI is planned compatibility--this > (uPort vs. 386/ix compatiblity) is just coincidence. I wouldn't call it coincidence. I would have been VERY suprised if something didn't work. Anything using "standard" device drivers, and SVID calls/routines (ie no sysi86()!), and ignoring incompatabilities possible between version of shared libraries, should work. In other words, anything that was written on a 68K, for Sys V, and only needed a re-compile to port to the 386, should work, irregardless of on which version it was compiled on. After all they are the SAME kernel (?). If it also worked on the Sun 386i, I'd be somewhat suprised. That isn't the same kernel, though, knowing Sun, they probably do have binary compatability for the Sys V/386 stuff. > > 3) (Just to be picky) Why doesn't Informix know whether they are > > or not? I assume they should be much more in touch with these > > things than some sleazy programmers in Santa Ana. > > Who knows. We had the salesperson check with the techie people (allegedly) > and they were still unsure. Guess we're not so sleazy after all (I'd like > to think I still am, though :-). Because Informix is to cheap to buy a copy of each and try it? -- Greg Woods. UUCP: utgpu!woods, utgpu!{ontmoh, ontmoh!ixpierre}!woods VOICE: (416) 242-7572 [h] LOCATION: Toronto, Ontario, Canada
plocher@uport.UUCP (John Plocher) (08/20/88)
In article <802@vsi.UUCP> sullivan@vsi.UUCP (Michael T Sullivan) writes: >> 2) How does this relate to the whole ABI concept? > >To paraphrase someone who responded, ABI is planned compatibility--this >(uPort vs. 386/ix compatiblity) is just coincidence. Since the Microport V/386 code is based on (and is identical at the system call level) to the 386/ix code, the ABI is there by default (and design). This (386) feature *is* what ABI is all about - the ability to take a package from one 386 machine and run it on another one, even if the Unix OS was bought from another vendor. uPort vs. 386/ix compatiblity is there by DESIGN. -John Plocher Microport Systems
sullivan@vsi.UUCP (Michael T Sullivan) (08/23/88)
In article <429@uport.UUCP>, plocher@uport.UUCP (John Plocher) writes: > In article <802@vsi.UUCP> sullivan@vsi.UUCP (Michael T Sullivan) writes: > > Since the Microport V/386 code is based on (and is identical at the > system call level) to the 386/ix code, the ABI is there by default (and > design). This (386) feature *is* what ABI is all about - the ability > to take a package from one 386 machine and run it on another one, even > if the Unix OS was bought from another vendor. > > uPort vs. 386/ix compatiblity is there by DESIGN. I don't think the fact that both of your OS's are based on the same code is enough to call it an ABI, or even say the compatibility is there by design. An ABI is a standard, not a coincidence. The idea is that even if one Unix isn't based on the same port as yours, programs will still run on both without recompiling. Also, if the compatibility is there by design, why don't we hear more about it. After I made the original posting I received a lot of requests to post whether the two were compatible. Seems to me if they were _by design_ then there'd be a lot more made of it. -- Michael Sullivan {uunet|attmail}!vsi!sullivan V-Systems, Inc. Santa Ana, CA sullivan@vsi.com "Your mother was a hamster and your father smelled of eldeberries! Pbbbt!"
ok@quintus.uucp (Richard A. O'Keefe) (08/25/88)
In article <819@vsi.UUCP> sullivan@vsi.UUCP (Michael T Sullivan) writes: >In article <429@uport.UUCP>, plocher@uport.UUCP (John Plocher) writes: >> uPort vs. 386/ix compatiblity is there by DESIGN. >I don't think the fact that both of your OS's are based on the same code >is enough to call it an ABI, or even say the compatibility is there by >design. It is definitely the case that the compatibility is there by design. We sell a tool that now runs on 386s, and it was important to us that there was *ONE* V.3 for the 386. (Of course, we also have to deal with Dynix on Sequents and SunOS on RoadRunners, but BSD takes the pain out...) Intel were closely involved in the 386 port of V.3, and were *very* interested that applications developed on Brand X machines should run on Brand Y machines.
woods@gpu.utcs.toronto.edu (Greg Woods) (08/27/88)
In article <819@vsi.UUCP> sullivan@vsi.UUCP (Michael T Sullivan) writes: > In article <429@uport.UUCP>, plocher@uport.UUCP (John Plocher) writes: > > In article <802@vsi.UUCP> sullivan@vsi.UUCP (Michael T Sullivan) writes: > > uPort vs. 386/ix compatibility is there by DESIGN. > > Also, if the compatibility is there by design, why don't we hear more about > it. After I made the original posting I received a lot of requests to > post whether the two were compatible. Seems to me if they were _by design_ > then there'd be a lot more made of it. I'd guess (from experience) that often when things "are" _by design_, it seems obvious to those involved that it will be obvious to everyone else, and when it's so important a factor, it should be so blatantly obvious to scream out its existence. Finally, to alleviate a lot of apparent confusion and ignorance, Interactive Systems has begun plugging this "design feature". Their advertisement on p. 15 of the Sept. Unix World should help quite some what. [ I just realized that it's Sept. NEXT month... the publishing world is always trying to trick me! ] I assume that they will continue this trend in the future. Thank {god, whomever} that they have a reasonably good advertising agency (that gets paid I hope), and that they have finally started to do some market research. Is there an actual ABI standard (which is the same as the current (apparent) de-facto standard) for the 386 Unix? (ie: does everyone agree on one thing for once?) :-) [ Look I learned how to spell "compatibility". Why doesn't SysV DWB have look? ] -- Greg Woods. UUCP: utgpu!woods, utgpu!{ontmoh, ontmoh!ixpierre}!woods VOICE: (416) 242-7572 [h] LOCATION: Toronto, Ontario, Canada
wes@obie.UUCP (Barnacle Wes) (08/27/88)
In article <819@vsi.UUCP>, sullivan@vsi.UUCP (Michael T Sullivan) writes: > I don't think the fact that both of your OS's are based on the same code > is enough to call it an ABI, or even say the compatibility is there by > design. You have missed the point - all the System V Release 3's for the 386 are based on the same port - the AT&T/Intel/Interactive port, which interactive sells for 386 AT-bus machines as 386/ix. You should be able to take a 386 COFF file and run it on ANY V.3/386, like, for instance, a Sequent, or an Acer Sys 32/20, which are NOT AT-bus machines. That IS an ABI. > ....... An ABI is a standard, not a coincidence. The idea is that even > if one Unix isn't based on the same port as yours, programs will still run > on both without recompiling. Right. They all ARE for the 386. See the above paragraph. > Also, if the compatibility is there by design, why don't we hear more about > it. After I made the original posting I received a lot of requests to > post whether the two were compatible. Seems to me if they were _by design_ > then there'd be a lot more made of it. Probably because it is such an unheard-of idea in the Unix world. Until now, that is. And it happened on an Intel processor - what a revoltin' development! -- {hpda, uwmcsd1}!sp7040!obie!wes "Happiness lies in being priviledged to work hard for long hours in doing whatever you think is worth doing." -- Robert A. Heinlein --