Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!jarthur!elroy.jpl.nasa.gov!decwrl!ucbvax!mtgzx.att.com!jis From: jis@mtgzx.att.com Newsgroups: comp.soft-sys.andrew Subject: Re: Suggestion for future releases Message-ID: Date: 13 Feb 90 15:20:19 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 35 Excerpts from info-andrew: 13-Feb-90 Suggestion for future releases Nathaniel Borenstein@thu (2546) > dynamic loading, though wonderful, is a severe portability problem. > This problem is alleviated for most of us who use Andrew by the fact > that the ITC has ported the > dynamic loader to lots of architectures. However, it is a significant > road block for three situations: > 1. People running on non-ITC-supported machines. > 2. People currently running on supported machines who expect to > upgrade, in the future, to the hottest hardware whenever it comes out > (recall how long it took to get Sun-4 support!) > 3. People who want to base products on Andrew and are scared by the > *future* portability problems the dynamic loader might entail. I agree. These have been our major concerns here, and we came very close to giving up on Andrew altogether when we decided to move to Sun 4s. It seems to me that either it should be easy to build a non-dynamically loded version of Andrew with a selection of modules loaded into static load, or the Art of Porting the Dynamic Loader to new architectures should be better documented, so that someone outside ITC can take a reasonable crack at it. Moreover, even if the latter is done, the former may still be desirable for reasons of use in timeshared machines etc. that Nathaniel has mentioned further on in his message. Jishnu Mukerji, jis@mtgzx.att.com, +1 201 957 5986, AT&T Bell Laboratories, MT 3K-423, 200 Laurel Ave., Middletown NJ 07748