----- Original Message -----
From:
"Clem Cole" <clemc@ccc.com>

To:
"Paul Winalski" <paul.winalski@gmail.com>
Cc:
"The Eunuchs Hysterical Society" <tuhs@tuhs.org>
Sent:
Thu, 29 Mar 2018 20:40:36 -0400
Subject:
Re: [TUHS] shared objects in Unix

....

​Unless it came from a place like Sun or Sun where Larry or Charlie might remember, I suspect that Steve Johnson is probably best to answer this part of your question -- assuming that it was created during his time in the compiler team in Summit.



I think shared libraries were already in the code base (although perhaps not released) when I came to Summit in 1982.   One of my main motivations was to make a product out of C++, which already looked like a winner in Research.  One of the first things I did was to ship cfront -- this was a RATFOR like extension that translated C++ into C and then compiled it.   Writing C++ with it wasn't too bad, because it mapped the C++ line numbers into the C file, but debugging it was ghastly.  The mapping to C involved long names that had encoded information about the type and class membership and other gook, making the debugger almost worthless.  (We were also shipping Pascal, Ada, and Fortran, which had lesser versions of the same problem).  So we immediately set off to improve the debugging.  I think shared libraries was based on an implementation done in a development area rather than Research, but it and COFF got a lot of tweaking to support Elf and Dwarf.  A real C++ compiler, based on the PCC2 backend, came along as well, about the time we got the debugging figured out, and the final product was, IMHO, pretty respectable.

A word about why I went to Summit.  When I started managing, my interest in technology transfer ramped up quickly.  As far as AT&T was concerned, the research culture and the development culture were very different.  And the only technology transfer that seemed to work involved moving people.  Reseach people had the best job in the world, and didn't want to move. But I found that, more and more, I was enjoying writing code that people liked to use much more than I enjoyed giving papers to 200 people who couldn't wait for me to sit down so they could talk about what they were doing.  So I decided to give it a try.

I still remember my first staff meeting with my department's supervisors.  In 15 years in Reasearch, I never had heard anyone commit to deliver a given feature at a given time!  And this happened many times in that meeting.  By the end, I realized that I wasn't in Kansas any more...   I learned tons from my supervisors, and I think they learned a lot from me.  It was altogether a wonderful experience, except for the fact that AT&T continually demonstrated its complete ignorance of the software marketplace by hiring clueless people.  At one point, a documentation person wrote up so documentation based on fodder we have given them.  When it came back, it was completely incoherent.  I gave it to my supervisors and they didn't get it either.  Suddenly one said.  "My God!  They think the Fortran Optimizer is a piece of hardware!"   Sure enough, from that point of view it made sense despite its total isolation from the real world.

Steve