linkers - next frontier?

[Tony L. Hansen]

> 	  The problem really is unfixable in the context of old systems.
> The best we can do is to make sure that *new* systems do it right.

Interesting. How do we make sure that *new* systems do it right? By
standardizing on the old methods or standardizing on the new methods of
thinking? 

If you standardize on the old method, then no one will consider having to
upgrade their loaders. When building new compilers/loaders/linkers, who will
stop and think "Gee, this doesn't conform to the non-standard. I'd better
think about this some more." Instead, they'll stop and think "Gee, this
conforms just fine to the standard of 6 characters, monocase. I'm doing a
great job!"

One possible way around the problem it is to go to a dual-standard: a
standard, preferred way of doing things (32 characters, dualcase) and a
sub-standard way of doing things (6 characters, monocase). Those compilers
which only support the sub-standard can be billed as supporting the ANSI
sub-standard version of C. Those that support global names of 32 characters
and dualcase can be billed as supporting the full ANSI standard.

Unless something is made an official part of the standard, there's no way
we're going to make new products conform to something that isn't a part of
the standard. If you embrace an out-dated standard, there's no way that the
out-dated stuff will disappear and we will always be haunted by it.

					Tony Hansen
					pegasus!hansen

P.S. A tool to consider writing would be a program to convert C source from
the full standard to the proposed sub-standard. One easy way of generating
unique global names would be to prepend an underscore followed by 5 digits
to every global name defined and called by the user's program. That
shouldn't be too hard to write.