TUHS

tuhs@tuhs.org

34 participants
6420 discussions

by Diomidis Spinellis

The document http://www.tuhs.org/Archive/PDP-11/Distributions/research/1972_stuff/Readme discusses the uncertainty regarding the epoch used for the file timestamps. "The biggest problem here is to pin down the epoch for the files. In the early version of UNIX, timestamps were in 1/60th second units. A 32-bit counter using these units overflows in 2.5 years, so the epoch had to be changed periodically, and I believe 1970, 1971, 1972 and 1973 were all epochs at one stage or another." "Given that the C compiler passes, and the library, are dated in June of the epoch year, and that Dennis has said ``1972-73 were the truly formative years in the development of the C language'', it's therefore unlikely that the epoch for the s2 tape is 1971: it is more likely to be 1972. The tape also contains several 1st Edition a.out binaries, which also makes it unlikely to be 1973." "Therefore, Warren's decoding of the s2-bits file, in s2-bits.tar.gz, uses 1972 as the epoch. However, Dennis decoding in s2.tar.gz uses 1973." "Finally, the date(1) a.out on the tape uses 1971 as its archive. How annoying! After a bit of discussion, Dennis and Warren have agreed that 1972 is the most probable epoch for s2-bits." I thought I could validate the epoch by looking at the distribution of weekdays for the three alternative years (1971 to 1973). Here are the results. wget http://www.tuhs.org/Archive/PDP-11/Distributions/research/1972_stuff/Readme for guess in 1971 1972 1973 ; do echo $guess EPOCH=$(date +'%s' -d "$guess/01/01 00:00 UTC") awk '/\/core/,/\/etc\/init/ { if ($9) print strftime("%a", '$EPOCH' + $9 / 60)}' Readme | sort | uniq -c | sort -n done 1971 1 Sat 6 Mon 8 Thu 8 Tue 17 Fri 21 Wed 34 Sun 1972 1 Sun 6 Tue 8 Fri 8 Wed 17 Sat 21 Thu 34 Mon 1973 1 Tue 6 Thu 8 Fri 8 Sun 17 Mon 21 Sat 34 Wed As you can see, unless weekends at the Bell Labs were highly atypical, 1972 has the most probable distribution of work among the days of the week.

8 years, 1 month

Utility of C changes (Was: phototypesetter C)

by jnc＠mercury.lcs.mit.edu

> of course some [of the changes to C in this time period] might have been > driven by general utility (e.g. the ability to initialize structures). I was thinking about this, with my memory of the changes refreshed by re-reading those 'changes to C' notes, and it's interested how many of them were ones I personally (and most of the people working with me) didn't use. Here is a list of the changes described in those 3 documents: 'newstuff': - Longs - Unsigneds - Blocks (locals declared inside a non-top-level {} pair) - Initialization of structures - Initialization of automatic variables - Bit fields - Macro functions - Macro conditionals (#ifdef) - Arguments in registers - Typedefs - 'Static' scope 'Changes': - Multi-line macros - Undefine - Conditional expressions (#if) - Unions - Casts - Sizeof() on abstractions - '=' in initializations - Change binary operators from trailing to leading - 'extern' does not allocate storage (This note also includes unsigneds, blocks, and structure initializations, from the earlier? note.) 'cchanges': - Structure assignment and argument/return-value - Enum Of these, I never really used quite a few: blocks, automatic initializations, typedefs, unions, structure assignment/etc, or enum. I'm not sure if I ever used bit fields, either. Some of these are understandable; e.g. automatic initializations are just syntactic sugar (as are register arguments, but I did use those). Typedef is also effectively syntactic sugar; you can always use a macro and get almost (entirely?) the same result. In fact, I devised an entire system of types to make the code I was working on (almost entirely networking code, so lots of packet headers from other machines, etc) more rigorous - and later it turned out it had made it much more portable; it all used macros, not typedef. I don't think I ever used typedef... (The details of that might be of some interest: instead of int, long, etc we had things of the form {type}{len}, where {type}pe} was 'int', 'uns', 'bit', etc and length was 'b', 's', 'l', or two other interesting ones 'w' and 'f' - 'w' meant the machine's native word length, and 'f' meant whatever was fastest on the machine. So 'unsl' mean '32-bit unsigned'. Depending on the machine, the compiler couldn't always produce them all - e.g. the PDP-11 didn't have unsl - so sometimes you had to live with non-optimal replacements. There were also un-typed types, i.e. 'byte', 'swrd', 'lwrd' - 8, 16 and 32 bits - and 'word' - the machine's native length.) Unions didn't get used much either, in our stuff, although one would think it would be useful in network code - you get a packet with a pile of bits inside it, which can be one of N different formats, seems like a perfect application for a union. The problemis that it tied two different subsystems intimately together. If you have protocol A and protocol B, if you use a union to define the header format, the union has to have both A and B in it. Now if you want to add protocol C, that requires modifying that union definition. It was much easier to just take a pointer to the outer packet's data area, and assign (with cast) it to a new pointer variable which was of the correct type for the header you were trying to process. Some of the new things were incredibly useful, though - or, in fact, one couldn't get by without them. Casts were incredibly useful once the compiler got pickier. Initialization of structures was huge - other than 'bdevsw'-like hacks, there was just no other way to do that. Noel

8 years, 1 month

Re: [TUHS] User maintained programs in the Second Edition

by Doug McIlroy

> Does anyone remember whether at the time these were installed in the > system-wide /bin directory, Those that I remember were in /usr/bin. Doug

8 years, 1 month

Re: [TUHS] Dennis' Draft of the Unix Timesharing System: not so draft?

by jnc＠mercury.lcs.mit.edu

> From: Warren Toomey > Ritchie, D.M. The UNIX Time Sharing System. MM 71-1273-4. > which makes me think that the draft version Doug McIlroy found Not really a response to your question, but I'd looked at that 'UnixEditionZero' and was very taken with this line, early on: "the most important features of UNIX are its simplicity [and] elegance" and had been meaning for some time to send in a rant. The variants of Unix done later by others sure fixed that, didn't they? :-( On a related note, great as my respect is for Ken and Doug for their work on early Unix (surely the system with the greatest bang/buck ratio ever), I have to disagree with them about Multics. In particular, if one is going to have a system as complex as modern Unices have become, one might as well get the power of Multics for it. Alas, we have the worst of both worlds - the size, _without_ the power. (Of course, Multics made some mistakes - primarly in thinking that the future of computing lay in large, powerful central machines, but other aspects of the system - such as the single-level store - clearly were the right direction. And wouldn't it be nice to have AIM boxes to run our browers and mail-readers in - so much for malware!) Noel

8 years, 1 month

User maintained programs in the Second Edition

by Diomidis Spinellis

The Second Edition manual has a section titled "User Maintained Programs" listing the following utilities and games: basic, bc, bj, cal, chash, cre, das, dli, dpt, moo, ptx, tmg, and ttt. In the Introduction, the reader is asked to consult their authors for more information. Does anyone remember whether at the time these were installed in the system-wide /bin directory, or whether they were only available in their owners' home directories?

8 years, 1 month

14 new TUHS members

by Warren Toomey

All, I've just got back from a few days away to find 14 new subscription requests to the TUHS mailing list. Welcome aboard to you all. Normally I only get one request a month, so I have some concerns about the legitimacy of all these requests, so accept my apologies in advance if there is any off-topic e-mails in the next few days. P.S The mail while I was away was very interesting. Noel, you might also be interested in the B interpreter and Robert Swierczick's B compiler the PDP-7 Unix. The original B compiler doesn't exist, so Robert took the 11/20 C compiler and "undid" the code that does types so that it "became" a B compiler. https://github.com/DoctorWkt/pdp7-unix/tree/master/src/other Cheers all Warren

8 years, 1 month

Happy birthday, Tommy Flowers!

by Dave Horsfall

Tommy Flowers MBE was born on this day in 1905; amongst other things he designed Colossus, the world's first programmable electronic computer, which was used to break the German Lorenz cipher (not Enigma, as some think). Relevance to Unix? Well, without the world's first usable computer we would not have the world's first usable OS, and M$ would probably reign supreme by now... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

8 years, 1 month

Re: [TUHS] nm on Third Edition .o files?'

by jnc＠mercury.lcs.mit.edu

> More here: > http://minnie.tuhs.org/pipermail/tuhs/2014-October/005218.html Which sez: There is a second document, untitled, no date, which I have not been able to locate online at all. .. From the content, it seems to be from shortly after the previous one, so say, circa 1977. I poked around in a dump of the CSR Unix which I now have available to me, and found a copy of it. I just checked the Internet (using the canonical search engine) for various phrases from it, but I still could not turn it up. So, here it is in machine-readable form: http://ana-3.lcs.mit.edu/~jnc/history/unix/CChanges.txt Hope this is some use to someone... :-) Noel

8 years, 1 month

phototypesetter C (was nm on Third Edition .o files)

by Doug McIlroy

Amusing, I don't think I ever heard the appellation "phototypesetter C" before. Certainly C and the phottypesetter developed independently, though in the same room. But the explanation that they got linked by appearing in the same tape release makes perfect sense. Thanks for the tidbit. Doug

8 years, 1 month

Re: [TUHS] nm on Third Edition .o files?'

by jnc＠mercury.lcs.mit.edu

> From: "Ron Natalie" > At some point .. and the ability to assign/pass structures got > supported, though I thought that was the compiler that came with V7. That is my vague recollection too. > I'm still annoyed they didn't fix arrays when they fixed structs. Which aspect? The ability to assign/pass/return arrays, or the funky way that array naming worked (I'm trying to remember the details, I think it was something to do with 'arrays' passed as arguments - it was actually a pointer that was passed, but the declaration didn't have to say 'pointer'). Noel

8 years, 1 month

Jump to page:

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