jrg@Apple.COM (John R. Galloway) (03/16/89)
(I am not sure that abi is the right name, but I am talking about the binary standard for unix executables, supposedly allowing any (e.g.) 88K abi format progam to run on any 88k unix box supporting abi). I keep hearing about how abi is going to make software available for unix systems like it has been for DOS/Mac systems (i.e. which by virture of running on a sinlge architecture have their own abi so to speak). The one thing no on seems to be able to tell me is how does this relate to someting like X? Clearly I will want to run X on my Froboz architecture, but all those who build their systems on the Froboz cpu will certainly not have identically compatible X libraries and toolkits which would seem to remove the possibility of taking a binary X program in the Froboz abi format and having a chance of running it on any Froboz workstation? right? apple!jrg John R. Galloway, Jr. contract programmer, San Jose, Ca These are my views, NOT Apple's, I am a GUEST here, not an employee!!
edw@oakhill.UUCP (Ed Wiencek) (03/17/89)
I worked on the BCS(Binary Compatability Standard) for the 68k/88k here at Motorola. I also dabble in X so maybe I can help answer your question. > Clearly I will want to run X on my Froboz architecture, but all > those who build their systems on the Froboz cpu will certainly not > have identically compatible X libraries and toolkits which would seem to > remove the possibility of taking a binary X program in the Froboz abi format > and having a chance of running it on any Froboz workstation? right? Wrong. The Motorola BCS--Binary Compatability Standard--doesn't care what high level libraries you include or don't include. IT DOES CARE WHAT THE OS INTERFACE LOOKS LIKE. The BCS describes what the unix system call interface looks like. So if one manufacturers 88k box runs a BCS compliant version of Unix and a different manufacturers system also has an 88k but some other version of Unix that is also BCS compliant, you should easily be able to take any X application and run it, instantly on either system. Toolkits are built on top of the X library and both of these can be built on top of Unix library subroutines but eventually all of these are built on top of Unix system calls. So long as you have X running on your BCS compliant system your BCS based executable X application can be picked up, moved and run on another BCS compliant system that is using the same microprocessor. > (I am not sure that abi is the right name, but I am talking about the > binary standard for unix executables, supposedly allowing any (e.g.) 88K abi > format progam to run on any 88k unix box supporting abi). And now for a word on terminology. Motorola started calling their binary interface standard the BCS. AT&T calls their interface the ABI-- Application Binary Interface. As far as I know, the ABI is a specification AT&T chooses to apply only to System V Release 4. On the other hand, Motorola felt the need to begin binary standards work and apply it to System V Release 3. Hence Motorola has a BCS for System V Release 3. Motorola also plans to work with AT&T and have an ABI for the 88k and 68k families for System V Release 4. The BCS and ABI documents are different and perhaps someone from AT&T can talk about the ABI. Either way, I expect that the answers for the ABI will be the same as I have given for the BCS. I hope that clears up the terminology confusion. Sincerely, Ed Wiencek Ed Wiencek MD 0E37 {sun, im4u}!oakhill!edw Microprocessor Products Group oakhill!edw@cs.utexas.edu Motorola, Inc. 512-891-2283 6501 William Cannon Drive West Austin, TX, 78735-8598
jrg@Apple.COM (John R. Galloway) (03/17/89)
In article <1909@oakhill.UUCP>, edw@oakhill.UUCP (Ed Wiencek) writes: > > Clearly I will want to run X on my Froboz architecture, but all > > those who build their systems on the Froboz cpu will certainly not > > have identically compatible X libraries and toolkits which would seem to > > remove the possibility of taking a binary X program in the Froboz abi format > > and having a chance of running it on any Froboz workstation? right? > > Wrong. The Motorola BCS--Binary Compatability Standard--doesn't care what high > level libraries you include or don't include. IT DOES CARE WHAT THE OS INTERFACE > LOOKS LIKE. The BCS describes what the unix system call interface looks like. So > Toolkits are built on top of the X library and both of these can be built on > top of Unix library subroutines but eventually all of these are built on > top of Unix system calls. So long as you have X running on your BCS > compliant system your BCS based executable X application can be picked up, Well maybe. The problem here is that there is no standard for local X communication. There is the X protocol standard but at a level below this I have seen several very different ways of talking to your local server (i.e. shared memory, streams, socket libraries that use streams, socket libraries that use a pseudo tty driver, etc.). Which one was a BCS compliant X app built for? Which one does the local server accept? This is likely less of a problme on BSD since there eveyone uses real sockets (or do they?). apple!jrg John R. Galloway, Jr. contract programmer, San Jose, Ca These are my views, NOT Apple's, I am a GUEST here, not an employee!!
guy@auspex.UUCP (Guy Harris) (03/21/89)
>And now for a word on terminology. Motorola started calling their binary >interface standard the BCS. AT&T calls their interface the ABI-- Application >Binary Interface. As far as I know, the ABI is a specification AT&T chooses to >apply only to System V Release 4. On the other hand, Motorola felt the need to >begin binary standards work and apply it to System V Release 3. Hence Motorola >has a BCS for System V Release 3. Motorola also plans to work with AT&T and >have an ABI for the 88k and 68k families for System V Release 4. The BCS and >ABI documents are different and perhaps someone from AT&T can talk about the >ABI. Either way, I expect that the answers for the ABI will be the same as I >have given for the BCS. I expect the bottom line - namely, an ABI-conformant program using X11 should run on any ABI-conformant system (assuming the CPU for which the program was built, and the CPU that the system uses, are in the same family) - will be the same. I do *not*, however, expect the answers to be the same in detail; at least, I very sincerely hope they won't be. If the S5R4 ABI's are done right, they *will* care what high-level libraries you use, at least for some libraries, and *won't* care as much what the OS interface looks like. They will not be done at the system call trap level; they'll be done at the library level, with the ABI specifying 1) the way ABI-compliant applications dynamically link to routines in a library and 2) the way particular procedures in those libraries are called. The advantage of this is that the ABI is specified at a much higher level; for instance, "getpwent"/"getpwnam"/"getpwuid" are interfaces in the ABI, so an ABI-conformant program can run on systems with "getpw*" implemented as dumb routines scanning "/etc/passwd", routines using a 4.3BSD-style "ndbm" index, routines using Hesiod/BIND, routines using the Apollo Registery, or routines using Sun's YP, and will use the appropriate routines on the appropriate systems. The routines will not be incorporated into the binary image of the program. The dynamic linking technology in question wasn't in S5R3, but will be provided for S5R4, based on the technology in SunOS 4.0 and later releases; that's why they only apply to S5R4. In the particular case of the X11 libraries, I would expect Xlib to be one dynamically-linked library included in the ABI specification, so that an ABI-conformant application would e.g. fill a rectangle by making a call to a procedure named "XFillRectangle" in a library named "X" (or "X11" or whatever), passing it the appropriate arguments. The layout of any structures to which the declarations of those arguments refer will also be specified by the ABI. The net result is the same, so that any ABI-conforming program should run on any ABI-conforming implementation (as long as the machine architectures are the same, of course - no guarantees that an 80*86 program will run on an 88K implementation, even if both are ABI-conformant!), since the ABI-conforming program will link to the right dynamically-linked library and make ABI-conforming calls, and the ABI-conforming implementation will supply an ABI-conforming library that behaves (or should behave - one would hope the implementation isn't buggy) properly when ABI-conforming calls are made to routines in the library.
guy@auspex.UUCP (Guy Harris) (03/21/89)
>Well maybe. The problem here is that there is no standard for local X >communication. There is the X protocol standard but at a level below this >I have seen several very different ways of talking to your local server (i.e. >shared memory, streams, socket libraries that use streams, socket libraries >that use a pseudo tty driver, etc.). Which one was a BCS compliant X app >built for? Which one does the local server accept? If the ABI is done right (see my previous message), this will not be a problem with the ABI. XOpenDisplay will be part of the ABI, as will, presumably, some specification of what strings are valid display names in which circumstances; the ABI application will call Xlib routines to do the work, and as long as the Xlib implementation does the right thing, the code in the application's binary image will neither know nor care what mechanism is used to talk to the server - that'll all be hidden in Xlib, which will *not* be part of the application's binary image (note: "application's binary image" is not what ABI stands for).