daveb@geac.UUCP (10/23/87)
In article <585@geowhiz.UUCP> karsh@geowhiz.UUCP (Bruce Karsh) writes: > Am I missing something in this argument? Is the argument that vendors >are able to write ANSI C compilers, but they are unable to modify their >linkers to allow long names? Actually its fairly easy to change a linker (you add a record type, however un-unix-like that might sound) What is hard is doing it *quickly*. You have to wait (on average) about three releases before dropping support for the old stuff. I did post the algorithm for switching over semi-transparently, but I think it fell into the nearby black hole. --dave -- David Collier-Brown. {mnetor|yetti|utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.
rick@svedberg.bcm.tmc.edu (Richard H. Miller) (11/03/87)
In article <1678@geac.UUCP>, daveb@geac.UUCP writes: > > Actually its fairly easy to change a linker (you add a record type, > however un-unix-like that might sound) > What is hard is doing it *quickly*. You have to wait (on average) > about three releases before dropping support for the old stuff. > Actually, you probably will not ever be able to drop 'old' stuff. In the mainframe environment I use (OS-1100), we seem to usually get around this by having 'new' language compilers output relocatable files with version numbers in the header. (In this case, 'old' relocatable files would have a lower version number or non-existent version number in them). The linker is smart enough to understand that it is working with old style code and uses the rules established for them to build executable code. Thus we can link in relocatable modules many years old without having to recompile them. (We have some relocatable modules which haven't been compiled for 10 years). This seems like a useful solution to allow the use of 'old' code and still add functionality and take advantage of newer techniques, languages, etc.)