Article View: comp.soft-sys.andrew
Article #2063Suggestion for future releases
From: Nathaniel Borenstein
Date: Tue, 13 Feb 1990 14:23
Date: Tue, 13 Feb 1990 14:23
46 lines
3013 bytes
3013 bytes
Here is a suggestion that probably wouldn't be overwhelmingly difficult
to incorporate into a future release, and that might help promote the
spread of Andrew throughout the world.
I'll start with the following observation: 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 believe that you could make life better in all these situations almost
without writing a single line of C code, though a significant amount of
Imakefile hackery will be required. It seems possible that you could
have an variable that can be set in site.mcr that permits
non-dynamic-linking builds. In other words, it skips all the makedo
commands and builds a set of normal runnable binaries. (Actually, with
a wee bit more work, it could just build a single monster binary
("maxrunapp"?) that linked in EVERYTHING -- all the insets, AMS, the
whole shebang.) This would probably NOT be the preferred way for people
to run Andrew when dynamic linking is available, but it would serve to
make Andrew instantly available on almost any reasonable UNIX box, and
would provide a nice guarantee that if you buy the latest hot new
machine, you can get Andrew running on it without a lot of effort. (As
an aside, the maxrunapp idea might even be more efficient than dynamic
loading for running Andrew in a large timesharing-with-X-terminals
situation, as the entire Andrew code would then be shared in the text
space.) People who bought the new boxes could use statically-loaded
Andrew until someone gets around to porting the dynamic loader.
As I said, this feature would require virtually no C coding, but would
take some work on the Imakefiles. I think it would offer significant
benefits to the current and potential user communities, the most
important of which is the elimination of the fear of future portability
problems with new and unsupported machines. (You could even set up a
default machine type, "unknown", which compiled this way.)
Any comments? -- Nathaniel
Technical Details
Message-ID:
<kZq1Vuy0M2Yt0oIJMm@thumper.bellcore.com>Path:
arc1-ca.pugleaf.net!utzoo!attcan!uunet!jarthur!usc!zaphod.mps.ohio-state.edu!uwm.edu!dogie.macc.wisc.edu!decwrl!ucbvax!THUMPER.BELLCORE.COM!nsbShow Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!jarthur!usc!zaphod.mps.ohio-state.edu!uwm.edu!dogie.macc.wisc.edu!decwrl!ucbvax!THUMPER.BELLCORE.COM!nsb From: nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) Newsgroups: comp.soft-sys.andrew Subject: Suggestion for future releases Message-ID: <kZq1Vuy0M2Yt0oIJMm@thumper.bellcore.com> Date: 13 Feb 90 14:23:54 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 46