Hello, I've been doing some research on the history of disassembly lately, tools available historically, today, and what sorts of developments have been made regarding utilities and systems for taking a machine-code binary and working it back to some semblance of source code.
So in the early days UNIX had das(I), a PDP-11 disassembler I believe written by Ken (he's OWNER in the manual) with very little information other than "it exists". Fast forward to the UNIX 4.1 manual in 1981 for the 3B20S and there is dis(1), a 3B20 disassembler. Other such manuals feature dis(1) versions for other 3B targets.
Was a disassembler ever considered part of the standard binary objects toolkit with the assembler, linker, etc. or was that the sort of thing that was more niche and therefore just kinda cropped up when/if someone decided to write one? Were there legal concerns to be grappled with when producing a disassembler? Were such tools ever shipped or did they only appear in the manuals as they were technically up in the code base, just not commonly distributed or used? Also, was there any thought given during the development of C to producing "decompilers" as has been becoming more common lately? Or was it a foregone conclusion that C to assembly is a "lossy" conversion and going the other direction couldn't be fully automated.
Thank you for any insights!
- Matt G.
Does anyone collect old Linux drivers? I just found one for the
"Backpack CD" which was a CD-ROM reader that would attach to a PC
via the parallel port. This is from April and May 1997. Before I nuke
the code, I thought I'd ask if there is anyone who collects such things.
Feel free to reply privately.
Thanks,
Arnold
Hello Folks,
A while back I made avaiable a tarball of two directories I had
of Bell Labs CSTRs (Computing Science Technical Reports). There
was some overlap between them, and at the time I didn't have the
free time to go through and weed through the duplicates.
I have now done that. There is a new tar file available at
https://www.skeeve.com/combined-cstr.tar.gz
Warren, please add this to the TUHS archives.
Enjoy,
Arnold
I thought folks on COFF and TUHS (Bcc'ed) might find this interesting.
Given the overlap between SDF and LCM+L, I wonder what this may mean
for the latter.
- Dan C.
---------- Forwarded message ---------
From: SDF Membership <membership(a)sdf.org>
Date: Thu, Aug 24, 2023 at 9:10 PM
Subject: [SDF] Computer Museum
To:
We're in the process of opening a computer museum in the Seattle area
and are holding our first public event on September 30th - October 1st.
The museum features interactive exhibits of various vintage computers
with a number of systems remotely accessible via telnet/ssh for those
who are unable to visit in person.
If this interests you, please consider replying with comments and
take the ascii survey below. You can mark an X for what interests you.
I would like to know more about:
[ ] visiting the museum
[ ] how to access the remote systems
[ ] becoming a regular volunteer or docent
[ ] restoring and maintaining various vintage systems
[ ] curation and exhibit design
[ ] supporting the museum with an annual membership
[ ] supporting the museum with an annual sponsorship
[ ] funding the museum endowment
[ ] day to day administration and operations
[ ] hosting an event or meet up at museum
[ ] teaching at the museum
[ ] donating an artifact
Info on our first public event can be found at https://sdf.org/icf
I finally got an Emacs running on v7--it's on misspiggy at LCML now as "ue".
It's Microemacs 3.6; what I did was to clone
https://github.com/troglobit/MicroEMACS and check out the first commit.
Some experimentation later, it had the usual problem with v7 and DEC
linkers that not all the function names (er, more generally exported
symbols, but in this case, function names) were unique in the first 7
characters (which is 6 if you're working with DEC OSes). So a bit of sed
later and I had something that built, linked, and appears to run with
TERM=vt100 set.
Arrow keys, naturally, don't work, but C-b, C-f, C-p, C-n do.
I think I'm going to just make a GH repo of it, but I'm happy to send the
tarball, or tar.uue, upon request. I find UUCP kinda fragile on my simh
installation, and I don't know how to get to Miss Piggy's (although the
uucp commands are there), so, well, uuencoding, a pasteboard buffer,
iTerm2's "Paste Slowly", and cat will work as a file transfer mechanism.
Adam
[This posting was sent earlier today to some local lists, but may also
be of interest to TUHS members.]
The UofUtah lost one its significant alumni, John Warnock, on Saturday.
John received Bachelor's and Master's degrees from the Department of
Mathematics, and his doctoral degree from the Department of Electrical
Engineering.
After jobs at Evans & Sutherland in Salt Lake City, and Xerox PARC
labs in Palo Alto, CA, he later went on to co-found Adobe Systems with
Chuck Geschke (1939--2021), and the PostScript, PDF, and font
technologies, and many others, that came from their company changed
the publishing model of the entire world.
See
https://www.cs.utah.edu/adobe-co-founder-and-kahlert-school-of-computing-al…https://www.ksl.com/article/50713319/adobe-co-founder-utah-native-john-warn…https://www.adobe.com/https://en.wikipedia.org/wiki/Charles_Geschkehttps://en.wikipedia.org/wiki/John_Warnock
John's doctoral thesis is available at:
https://www.proquest.com/pqdtglobal/docview/302478116/2F149E6F459946B7PQ
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah -
- Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu -
- 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
> From: Paul Ruizendaal <pnr(a)planet.nl>
> a token ring driver (written by Noel Chiappa, if I remember well).
No (unless they took one I wrote for the V6 machine and adapted it); I never
did anything on any Unix after V6 (I think there's nothing of any significant
interest in any later Unix).
Anyway, writing a driver for that board would be about as much work as
writing a driver for an RK11 controller - i.e. a day or so for someone
competent.
Noel
> Date: Thu, 10 Aug 2023 03:17:25 +0000
> From: segaloco
>
>>>> TCP/IP, not datakit
>
>
> All of the files that have timestamps at the top list 83/07/29, except ip_input.c which has 83/08/16 instead. The V8 version has _device (device driver) and _ld (line discipline) components that the 4.1cBSD code does not have. Many other files have analogs between the two. The byte ordering subroutines have been copied into a file, goo.s, from their home in 4.1cBSD in the C library (/usr/src/lib/libc/net/misc). When this work originated someone else would need to answer, [...]
As far as I can tell the history of this code line goes back to 1977, when Jack Haverty at BBN wrote a TCP/IP library (porting earlier work written in PDP-11 assembler) for a slightly modified 6th Edition Unix. Fighting with 64KB core limits, throughput was horrific and he concluded that a bigger PDP-11 was needed. Mike Wingfield then did a re-implementation in C for a PDP-11/70. This worked in early 1979 and is arguably the first Unix TCP/IP stack that can still interoperate with current IPv4. However, it was still mostly a proof of concept user mode design (it was funded as a test vehicle for the later abandoned Autodin-II fork of TCP).
BBN then got a contract to write a kernel mode TCP/IP stack for 4BSD (“VAX TCP” in the old BBN doc’s). This work was performed by Rob Gurwitz under supervision of Jack Haverty. This stack - although all new code - still showed its heritage: it was designed as a loosely bound kernel process providing the NCP-Unix API. Some sources seem to imply that it was developed first as a user mode process and once working in that context changed into a kernel process / thread. Beta releases were available in 1981. It worked (and interoperates with modern IPv4), but in my experiments a few years back it turned out that it is difficult to get the scheduling for this kernel process right at higher system loads.
Bill Joy of CSRG concluded that the BBN stack did not perform according to his expectations. Note that CSRG was focused on usage over (thick) ethernet links, and BBN was focused on usage over Arpanet and other wide-area networks (with much lower bandwidth, and higher latency and error rates). He then in 1982 rewrote the stack to match the CSRG environment, changing the design to use software interrupts instead of a kernel thread and optimising the code (e.g. checksumming and fast code paths). It was a matter of debate how new the code was, with the extremes being that it was written from scratch using the spec versus it being mostly copied. Looking at it with a nearly 50 year distance, it seems in between: small bits of surviving SCCS suggest CSRG starting with parts of BBN code followed by rapid, massive modification; the end result is quite different but retained the ‘mbuf’ core data structure and a BBN bug (off-by-one for OOB TCP segments).
The shift from the NCP-Unix API to sockets is separate from this and was planned. CSRG had the contract to develop a new API for facilitating distributed systems with Unix and this gelled into the sockets interface. The first prototypes for this were done in 1981.
Nearly all of the above source is available in the TUHS online Unix Tree (Wingfield, VAX-TCP and two early versions from CSRG - one in 2.9BSD and one in 4.1cBSD).
Good morning folks, just sharing some eBay sales I spotted that are just not in the cards for me, both in terms of expense and I just don't have the bandwidth to focus on other UNIX lines right now.
That said, someone is selling a very, very large collection of HP-UX documents:
https://www.ebay.com/itm/285425883705https://www.ebay.com/itm/285425882004
As mentioned, quite pricy, and bulky too. However, if anyone knows anyone with a particular eye for HP-UX history, this may interest them. No idea what is and isn't preserved there, non-Bell-and-UCB stuff hasn't been on my radar hardly at all other than acknowledging it exists.
Tangential but I do appreciate the consistency in their documentation appearance. I see HP-UX stuff pop up time to time and the cover motif is identical to the documents they published with analytical equipment like gas chromatographs before spinning that unit off into Agilent.
- Matt G.
> Warner Losh imp at bsdimp.com
> Thu Aug 10 12:45:54 AEST 2023
> wrote:
>
> Yea, I thought it was 4.1bsd + later tcp code but with a STREAMS instead of
> Socket interface...
Please see this old TUHS post for some more background in DMR’s own words:
https://www.tuhs.org/pipermail/tuhs/2019-August/018325.html
On the topic of DMR Streams, I’m increasingly intrigued by its design: recently I’ve been deep diving into classic USB to better understand this class of devices and how to drive them (https://gitlab.com/pnru/usb_host) It would seem to me that Streams would have been a neat way to organise the USB driver stack in a v8 context. Note that an USB analog did exist in 1982: https://en.wikipedia.org/wiki/Hex-Bus
Sometimes I wonder what combining v8 streams with v8 virtual directories (i.e. like Killian’s /proc) could have looked like. Having the streams network stack (or usb stack) exposed as virtual directories would have been quite powerful.
