TUHS May 2025

tuhs@tuhs.org

43 participants
25 discussions

Re: What is the intermediate code generated by the bc interpreter?

by jnc＠mercury.lcs.mit.edu

> From: Tom Teixeira > before the RTS group at Project MAC (Called the DSSR group at that point om time, if anyone wants to look anything up.) > I got a BCPL compiler from somewhere and made some enhancements - such > as direct support for external variables and routines using a linker > rather than the pure BCPL global array. This entire toolchain, including all the source, has been preserved; the BCPL compiler, the linker ('bind', itself written in BCPL), and a number of tools (including an extra one, 'ldrel', written by the CSR group on the 5th floor). I have in the past put up some pieces for download, but I never got around to doing the whole thing, as there didn't seem to be any interest. We (CSR) started working with the toolchain because it included support for MACRO-11 (the BCPL compiler could produce either MACRO-11 or UNIX assembler source as output). That toolchain used a relocatable formet, .rel': http://ana-3.lcs.mit.edu/~jnc/tech/unix/man5/rel.5 that I think was based on one DEC had done. CSR was working with a semi-real-time operating system, called 'MOS': https://gunkies.org/wiki/MOS_operating_system for the PDP-11, that we'd gotten from SRI. (MOS was used a lot in early work on the Internet; e.g. all the BBN 'core' routers used in the early Internet used it, after the very first ones [written in BCPL, oddly enough], which had used ELF: https://gunkies.org/wiki/ELF_operating_system but BBN soon switched to MOS.) MOS was written in MACRO-11; we started working with MOS with the same toolchain SRI had used for it, which ran on TOPS-20. I soon decided I'd rather work on our group's PDP-11, initially a PDP-11/40 running a clone of the DSSR system (the first UNIX at MIT). So, we started working with the MACRO-11, and bind, on UNIX. I then decided I'd rather write code for our PDP-11 packet switches in this nifty language called C, used on UNIX, which nobody else knew about (at that point). The first step was to write 'ldrel', to convert a.out files (produced by the C compiler) to .rel files, so 'bind' could work with them. After a while, we decided we'd rather use 'ld' as our linker (I think because it supported demand loading from binary libraries, so we didn't have to manually specify every file to link). The DSSR group had long ago written 'relld', which converted .rel files (produced by MACRO-11) to a.out files, so that was pretty easy. There seems to be a version of the BCPL compiler which produces 8080 code. It looks like that pre-dates the 8086 C compiler from MIT (the 8080 C compiler was not done at MIT). (I just ran across a 6502 emulator written by Rae McLellan of DSSR; he and they seem to have done a lot of work with various micros. It may not have all the pieces it needs to work, though; it seems to need "/usr/simulators/s6502/s6502.body" from the DSSR machine.) Pity I didn't save a dump of that machine too; I was once looking for the source of the Algol interpreter, written on the Delphi machine, and made to run under UNIX, and I asked Steve Ward if any dumps of the DSSR/RTS machine still existed, and he thought not. So we have the binary of that Algol interpreter, but not the source. Of course, it was probably written in MACRO-11, so a disassembler would produce a reasonable facsimile. And I should ask Lars if the backup tapes of the DSSR/RTS machine went to the MIT archives - they might well have done, and Prof. Ward just didn't know that. Noel

1 week, 2 days

What is the intermediate code generated by the bc interpreter?

by Jackson Helie G

I checked Dennis M. Ritchie's "Users' Reference to B" and found an example of implementing a B program at the bottom of the manual. It said that bc generates intermediate code suitable for ba, and then ba generates assembly code. So, I am curious about what the intermediate code generated by bc is?

1 week, 2 days

Unix Reverse Engineering

by Thalia Archibald

Hello everyone, I'm working on building a decompiler from PDP-11 assembly to C to ease studying old pre-C Unix sources. To start, I'm translating V5 `as` to period-idiomatic C and have finished most of pass 1. Then I'll port it to Rust with a design better suited to static analysis, while keeping exact fidelity to the original. I'll do the same for `cc` and `ld`, after. I stumbled upon Warren's disaout[0] today, which made me wonder: What tools have people for reverse engineering Unix assembly sources or a.out binaries? Things like disassemblers or decompilers. I assume there's some versions of programs which are now only extant as binaries? Are there enough such binaries that were written in C to warrant writing a decompiler that understands the specific codegen of `cc` to improve accuracy? For now, I'm focusing on decompiling hand-written assembly, but I'm keeping this case in mind. Thanks! Thalia [0]: https://github.com/DoctorWkt/unix-jun72/tree/master/tools/disaout

1 week, 2 days

Off topic: Books on Unix security?

by Aharon Robbins

Hi All. In a book I'm updating, I have the following references for Unix security. 1. Practical UNIX & Internet Security, 3rd edition, by Simson Garfinkel, Gene Spafford, and Alan Schwartz, O’Reilly & Associates, Sebastopol, CA, USA, 2003. ISBN-10: 0-596-00323-4, ISBN-13: 978-0596003234. 2. Building Secure Software: How to Avoid Security Problems the Right Way, by John Viega and Gary McGraw. Addison-Wesley, Reading, Massachusetts, USA, 2001. ISBN- 10: 0-201-72152-X, ISBN-13: 978-0201721522. 3. “Setuid Demystified,” by Hao Chen, David Wagner, and Drew Dean. Proceedings of the 11th USENIX Security Symposium, August 5–9, 2002. http://www.cs.berkeley. edu/~daw/papers/setuid-usenix02.pdf. One of my reviewers asked if these weren't "dusty references". So, before I just refer to them as "classics", can anyone recommend more recent books? Feel free to answer in private. Thanks, Arnold

1 week, 5 days

Re: Ken Thomson's email address?

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > The first "C" compiler wa an ephemeral state some time in the process > of its evolution. Dennis started with his B implementation and began to > add features he needed See: The Development of the C Language https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.html for detail on the evolution. Noel

1 week, 5 days

Re: Ken Thomson's email address?

by Jackson Helie G

If this is true, it's a pity. Otherwise, I would like to ask Ken Thompson if he has the first C compiler.

1 week, 6 days

Re: Ken Thomson's email address?

by jnc＠mercury.lcs.mit.edu

> From: Jackson Helie G > I would like to ask Ken Thompson if he has the first C compiler. He wouldn't; he didn't do much work on C. Dennis Ritchie (who created C) posted two very early ones here: https://www.nokia.com/bell-labs/about/dennis-m-ritchie/primevalC.html Noel

1 week, 6 days

Ken Thomson's email address?

by Jackson Helie G

Oh, sorry guys, please forgive me for the off-topic question. I was wondering if anyone knows Ken Thomson's email address? I was wondering if he has any more archives of Unix from 1972 and before.

1 week, 6 days

Fwd: An Announcement about the USENIX Annual Technical Conference

by Rik Farrow

I received this earlier today, and wondered if cross-posting it would be appropriate. Here goes... Rik ---------- Forwarded message --------- From: Casey Henderson-Ross <casey.henderson(a)usenix.org> Date: Tue, May 6, 2025 at 2:12 PM Subject: An Announcement about the USENIX Annual Technical Conference To: Rik Farrow <rik(a)rikfarrow.com> Read on for important news. [image: USENIX, the Advanced Computing Systems Association] <https://s.usenix.org/acton/ct/2452/s-0514-2505/Bct/l-sf-cl-7018Y000001JtF6Q…> Hello, Rik, USENIX celebrates its 50th anniversary in 2025. We celebrate decades of innovations, experiments, and gatherings of the advanced computing system community. And in the spirit of our ever-evolving community, field, and industry, we announce the bittersweet conclusion of our longest-running event, the USENIX Annual Technical Conference in July 2025, following USENIX ATC '25. Since USENIX's inception in 1975, it has been a key gathering place for innovators in the advanced computing systems community. The early days of meetings evolved into the two annual conferences, the USENIX Summer and Winter Conferences, which in 1995 merged into the single Annual Technical Conference that has continued to evolve and serve thousands of our constituents for 30 years. For the past two decades, as more USENIX conferences have joined the USENIX calendar by focusing on specific topics that grew out of ATC itself, attendance at ATC has steadily decreased to the point where there is no longer a critical mass of researchers and practitioners joining us. Thus, after many years of experiments to adapt this conference to the ever-changing tech landscape and community, the USENIX Board of Directors has made the difficult decision to sunset USENIX ATC. USENIX ATC in its many iterations has been the home of an incredible list of "firsts" in our industry: - In 1979, ONYX, the first attempt at genuine UNIX hardware, was announced. - In 1982, DEC unveiled the creation of its UNIX product. - In 1983, Eric Allman presented the first paper on Sendmail, "Mail Systems and Addressing in 4.2BSD." - In 1985, Sun Microsystems presented the first paper on NFS, "Design and Implementation of the Sun Network Filesystem." - In 1988, the first light on Kerberos and the X Window system was presented. - In 1989, Tom Christiansen made his first Perl presentation as an Invited Talk. - In 1990, John Ousterhout presented Tcl. - In 1995, the first talk on Oak (later JAVA) was given as a Work-in-Progress report. - In 1998, Miguel de Icaza presented "The GNOME Desktop Environment." These examples represent just a few of the many contributions presented at USENIX ATC over the years, with hundreds of papers that account for thousands of citations of work that the community has presented, discussed, learned from, and built upon as the community evolved. Part of that evolution involved the continued development of subcommunities, as has been the case with USENIX Security, which began as a workshop in 1988 and has since grown to an annual symposium and the largest of our events in terms of both papers published and number of attendees annually, with 417 papers and 1,015 attendees at USENIX Security '24. The LISA (Large Installation System Administration) Conference, which also started as a workshop in 1987, grew in a similar fashion to its peak of over 1,000 attendees, but like USENIX ATC declined as its community changed until its own sunset in 2021. Papers on file and storage systems that would have previously been presented at USENIX ATC in the early 2000s began to find homes at FAST when it was founded in 2002. Networked systems papers started flowing to NSDI in 2003. As the biennial OSDI continued to grow alongside ACM's SOSP, OSDI became annual in 2021 and SOSP followed suit, providing the community with additional venues. While landmark moments in our community have continued at USENIX ATC, many others have also occurred at these other USENIX conferences, as showcased in the USENIX Test of Time Awards <https://s.usenix.org/acton/ct/2452/s-0514-2505/Bct/l-sf-cl-7018Y000001JtF6Q…> and the ACM SIGOPS Hall of Fame Awards <https://s.usenix.org/acton/ct/2452/s-0514-2505/Bct/l-sf-cl-7018Y000001JtF6Q…>, which celebrate influential works presented at both SOSP and OSDI. Although numerous papers continue to be submitted to USENIX ATC with significant research being reviewed, accepted, and presented, the community has evolved, and now attends conferences other than USENIX ATC. From 1,698 attendees in San Diego in 2000, ATC attendance dwindled to 165 attendees in Santa Clara in 2024—even as we had over 4,000 people attend all USENIX conferences in 2024. USENIX recognizes the pivotal role that USENIX ATC has played in the shaping of the Association itself as well as the lives and careers of its many attendees and members. We also realize that change is inevitable, and all good things must come to an end: if it weren't for ATC being a "victim of its own great success"—a foundry of so many other successful conferences and workshops—USENIX would never have grown and expanded so much over the decades. Thus our hearts are heavy as we celebrate ATC's history and legacy alongside the evolution of its younger siblings and face the financial realities of the post-pandemic world and volatile global economy. USENIX's resources to support its conferences and communities are not unlimited, particularly as we maintain our commitment to open-access publications that are free for our authors to publish. We have been reporting about these challenges via our Annual Meeting and subsequent reports for the past several years (2024 <https://s.usenix.org/acton/ct/2452/s-0514-2505/Bct/l-sf-cl-7018Y000001JtF6Q…>, 2023 <https://s.usenix.org/acton/ct/2452/s-0514-2505/Bct/l-sf-cl-7018Y000001JtF6Q…>, 2022 <https://s.usenix.org/acton/ct/2452/s-0514-2505/Bct/l-sf-cl-7018Y000001JtF6Q…>, 2021 <https://s.usenix.org/acton/ct/2452/s-0514-2505/Bct/l-sf-cl-7018Y000001JtF6Q…>, 2020 <https://s.usenix.org/acton/ct/2452/s-0514-2505/Bct/l-sf-cl-7018Y000001JtF6Q…>). We deeply appreciate the financial support we have received from our community in the form of donations, memberships, and conference registrations. However, we continue to operate at a deficit and ATC continues to shrink. In making this hard choice, accepting the reality in front of us that encourages us to innovate in a different direction under challenging circumstances, we seek to embody the values of this community that was founded on curiosity, persistence, and collaboration. As we celebrate 50 years of both USENIX and ATC in its varying forms, we look towards the future of this vibrant community in the form of the many conferences that ATC continues to help create in its image: welcoming, thoughtful environments for the presentation of innovative work that fellow conference attendees help push forward. We look forward to honoring ATC's legacy alongside USENIX's history and its future in Boston in July of 2025. We would love to hear memories of your experience at the USENIX Annual Technical Conference over the years. Please submit your thoughts <https://s.usenix.org/acton/ct/2452/s-0514-2505/Bct/l-sf-cl-7018Y000001JtF6Q…> in words, video, or both by *Monday, June 2*. We will share your memories both at USENIX ATC '25 and afterwards. We hope that you will join us at USENIX ATC '25 <https://s.usenix.org/acton/ct/2452/s-0514-2505/Bct/l-sf-cl-7018Y000001JtF6Q…>, which will include both a celebration of USENIX's 50th anniversary on the evening of *Monday, July 7*, and a tribute to USENIX ATC on the evening of *Tuesday, July 8*. [image: Casey Henderson headshot] Best Regards, Casey Henderson-Ross Executive Director USENIX Association About this mailing list: You are receiving this email because you are or have been a member of USENIX, have attended USENIX conferences, or have signed up to receive emails from USENIX. USENIX <https://s.usenix.org/acton/ct/2452/s-0514-2505/Bct/l-sf-cl-7018Y000001JtF6Q…> never shares, sells, rents, or exchanges email addresses of its members, conference attendees, and other constituents. Review our privacy policy <https://s.usenix.org/acton/ct/2452/s-0514-2505/Bct/l-sf-cl-7018Y000001JtF6Q…> . We would like to continue sending you occasional email announcements like this one. However, if you no longer want to receive emails from USENIX, please click here <http://s.usenix.org/acton/rif/2452/s-0514-2505/-/l-sf-cl-7018Y000001JtF6QAK…> to opt out of all communications from USENIX. If you have any questions about the mailing list, please email info(a)usenix.org. We may also be reached via postal mail: USENIX Association 2443 Fillmore St, #380-25600, San Francisco, CA 94115-1814, USA

2 weeks

Re: Paragraphs formatted differently depending on previous ones

by G. Branden Robinson

[looping TUHS back in since I'm correcting a message I sent there] Hi Dave, At 2025-05-06T08:36:55-0500, Dave Kemper wrote: > On Fri, May 2, 2025 at 7:35 PM G. Branden Robinson > <g.branden.robinson(a)gmail.com> wrote: > > I guess another way of saying this is that, as I conceive it, a line > > that is "adequately full" contributes to the page's uniformity of > > grayness by definition. > > For an example of less-than-ideal results if this is _not_ considered > the case (groff's behavior before this change), see > http://savannah.gnu.org/bugs/?60673#comment0 (the initial report that > precipitated the commit Doug is commenting on). Yes. In my reply to Doug I incorrectly characterized the resolution of this bug as a "2023" change of mine, but I actually landed the change in 2021. It simply took until 2023 to appear in a released _groff_. To make this message more TUHS-o-riffic, let's observe that input using DWB 3.3 troff and Heirloom Doctools troff (descended from Solaris troff, descended from DWB 2.0 troff [I think]), and both of which descend from Kernighan's device-independent troff circa 1980. $ DWBHOME=. ./bin/nroff groff-60673.roff | cat -s While the example in bug 57836's original report is somewhat contrived and a bit of an edge case in real life, there turns out to be a more innate bug in grotty's balancing algorithm. As mentioned before (and easily observable), when grotty adds spaces to a line in the process of justifying it, the algorithm it utilizes adds spaces from opposite ends of each line. But when it adds this space, it does not take into account lines with no adjustment at all required. Therefore if space only need be added to every other line of the text, all the space ends up being added to the same end of the line, degrading the uniform grayness of the output, as can be seen in this example. There is one fairly simple way to address this: grotty shouldn't "count" lines that don't need to be adjusted; instead, it should apply the alternation pattern only to those lines that do need adjustment. $ ./bin/nroff groff-60673.roff | cat -s While the example in bug 57836's original report is somewhat contrived and a bit of an edge case in real life, there turns out to be a more innate bug in grotty's balancing algorithm. As mentioned before (and easily observable), when grotty adds spaces to a line in the process of justifying it, the algorithm it utilizes adds spaces from opposite ends of each line. But when it adds this space, it does not take into account lines with no adjustment at all required. Therefore if space only need be added to every other line of the text, all the space ends up being added to the same end of the line, degrading the uniform grayness of the output, as can be seen in this example. There is one fairly simple way to address this: grotty shouldn't "count" lines that don't need to be adjusted; instead, it should apply the alternation pattern only to those lines that do need adjustment. They are the same, and differ from groff 1.22.4 and earlier only in that they adjust spaces starting from the right end of the line instead of the left. At the risk of tooting our own horn, here's how groff 1.23.0+ handles the same input. $ ~/groff-1.23.0/bin/nroff groff-60673.roff | cat -s While the example in bug 57836’s original report is somewhat contrived and a bit of an edge case in real life, there turns out to be a more innate bug in grotty’s balancing algorithm. As mentioned before (and easily observable), when grotty adds spaces to a line in the process of justifying it, the algorithm it utilizes adds spaces from opposite ends of each line. But when it adds this space, it does not take into account lines with no adjustment at all required. Therefore if space only need be added to every other line of the text, all the space ends up being added to the same end of the line, degrading the uniform grayness of the output, as can be seen in this example. There is one fairly simple way to address this: grotty shouldn’t "count" lines that don’t need to be adjusted; instead, it should apply the alternation pattern only to those lines that do need adjustment. Three observations: 1. One can find the input at Dave's URL above. 2. The input disables inter-sentence spacing. 3. The adjustment algorithm is a property not of grotty(1) (the output driver), but of GNU troff itself. Regards, Branden

2 weeks, 1 day

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS May 2025