I've assembled some notes from old manuals and other sources
on the formats used for on-disk file systems through the
Additional notes, comments on style, and whatnot are welcome.
(It may be sensible to send anything in the last two categories
directly to me, rather than to the whole list.)
Does anyone here remember the Adventure Shell?
Doug wrote it back in 83, and I just stumbled across a copy in an RCS directory.
Invoked as ‘ash’ it was pretty clever. I’ve lost the instructions and help files, however I’ve got the main script.
Back when people did weird things because it was fun.
> Browsing the source for "cc" in v6 and v7, if invoked with -2 would
> replace crt0.o with crt2.o. If the -2 were followed by another character
> (probably intended to be -20), it would use crt20.o and use -l2 instead
> of -lc.
> These options seem to be undocumented, and I can't find any source code
> of these libraries or indication as to what the purpose was.
The "scc" man page for System V may be enlightening, as it mentions
scc - C compiler for stand-alone programs
scc [ +[ lib ] ] [ option ] ... [ file ] ...
Scc prepares the named files for stand-alone execution.
/lib/crt2.o execution start-off
/usr/lib/lib2.a stand-alone library
/usr/lib/lib2A.a +A configuration library
/usr/lib/lib2B.a +B configuration library
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
two remarks on the issues around FPSIM and tcsh:
I of course wondered by a line like
is accepted by 'as', I naively expected that this should cause an error.
I didn't locate the 211bsd 'as' manual, so checked 7th Edition manuals,
which can be found under
The assembler manual, see
6.1 Expression operators
The operators are:
(blank) when there is no operand between operands,
the effect is exactly the same as if a
‘+’ had appeared.
So the lexer sees two tokens
$4. --> number
. --> symbol for location counter
and, because the default operator is '+', interprets this as
mov $4. + . , r0
which ends up being a number in the 160000 to 177777 range.
So 'as' is not to blame, works as designed.
Noel Chippa wrote:
> I'm fairly amazed that apparently nobody has run across one of these 4 before!
> (Or, at least, not bothered to report it.)
> I wonder how long that bug has been in the code?
The answer is: this bug was in 211bsd all the time.
Steven Schultz told me that that they simply didn't have a way to
test FPSIM because all machines had FPP, and the only way of testing
would have been to physically remove the FP11 from a 11/70.
With best regards, Walter
Browsing the source for "cc" in v6 and v7, if invoked with -2 would
replace crt0.o with crt2.o. If the -2 were followed by another character
(probably intended to be -20), it would use crt20.o and use -l2 instead
These options seem to be undocumented, and I can't find any source code
of these libraries or indication as to what the purpose was.
I was hoping someone on the list who remembers 'mhit.c' from
the Blit library code could shed some light on some members
of the 'NMitem' structure. I believe that 'mhit' (sometimes
'hmenunit') was written by Andrew Hume.
The structure in question is this:
typedef struct NMitem
struct NMenu *next;
void (*dfn)(), (*bfn)(), (*hfn)();
long data; /* user only */
The three functions are called at different times when a menu
is being traversed, but 'dfn' and 'bfn' are only called before
a submenu is entered, and after a submenu is exited, respectively.
'hfn' is called whenever an item has been selected.
I have never seen 'dfn' and 'bfn' used in any Bell Labs code so
I was wondering what the rationale for their existence was.
Dear THUS list,
I am a recent lurker on this list, also a history and communication
scholar looking at pieces of Unix history for my research. I hope it is
okay if I share with you the news of a historical conference on Unix
that we are organizing in France next Fall with fellow humanities
scholars and computer scientists and engineers involved in the history
and heritage of computing and computers.
You are of course welcomed, even encouraged, to submit a proposal. It
will be a pleasure to meet you at this conference in any case.
Please find enclosed the CFP for the *international conference**"Unix in
Europe: between innovation, diffusion and heritage"* that will take
place in Cnam (Paris, France), October, 19th, 2017.
A one-page abstract (maximum 500 words) with a short biography is
expected for June 30th 2017.
The Cfp is also available at :
The organization comitee : Isabelle Astic, Raphaël Fournier-S'niehotta,
Pierre-Eric Mounier-Kuhn, Camille Paloque-Berges, Loïc Petitgirard
*Call for contributions*
*International symposium *
*Unix in Europe: between innovation, diffusion and heritage*
*/Conservatoire National des Arts et Métiers, Paris, France –
October 19 2017/*
Communications and discussions will be held in French or English.
**The Unix system was born in the 1970s at the crossroads between
two interacting worlds: industry (the Bell Labs at AT&T) and
academia (the University of Berkeley computer science network). Its
fast adoption throughout computer research and engineering networks
across the world signaled the future success of the new system,
fostering software experiments within its open, multi-user and
multi-tasking system running on mini-computers – and later
compatible with a larger part of computer hardware. In the European
context, how was this American innovation propagated, adopted and
adapted? Why was Unix of so much interest in this context, then and
now? A solid culture of Unix users might also explain this success,
as well as subsequent processes of appropriation and inheritance,
due to the long and complex history of Unix versioning. The memory
of Unix users is vivid indeed, fed by early accounts within the
computer world (Salus, 1994) as well as preservation initiatives
(Toomey, 2010). Moreover, the Unix system is a crucial reference in
the history of computing, in particular in the field of free and
open source software (Kelty, 2008), computer networks
(Paloque-Berges, 2017), as well as in programming language
philosophy (Mélès, 2013).
In order to explore the variety of these interrogations, this
symposium encourages contributions from historians as well as
philosophers, social science researchers, and heritage professionals
interested in the history of computer open systems and software with
a focus on Unix or who have a wider perspective. It will also
welcome protagonists and witnesses of Unix culture and carriers of
its memory. We wish to discuss and shed light on several aspects of
the development of Unix in Europe (including in comparison or
relation with the rest of the world) along three main lines:
historical and sociological, philosophical and epistemological, and
heritage- and preservation-oriented.
*1/ Historical and sociological perspectives*
Historically, the Unix system is linked to the promotion and
development in research on open systems and computer networks. How
does this fit in the context of industrial, scientific and
technological policies defined at the national and European level?
The history of Unix thus reaches at least three levels of
interrogations: 1/ the forms, places and practices of innovation
around Unix in R&D labs and computing centers in companies, schools
and universities; 2/ planning, promoting and negotiating open
systems (norms and standards) from the perspective of science and/or
politics; 3/ international geopolitical relations, whether
economical or geopolitical and even geostrategic (for example
between Unix users, with users of other computer equipment or other
hardware and software companies, the role of embargos in the
shipping of mini-computers, of code, and military uses of Unix).
In parallel, how has the world of computer research welcomed,
encouraged, negotiated and propagated uses and innovations related
to Unix systems? This begs the question of how Unix-related research
and development was legitimized - or played a part in the
legitimization of computer science experimentalism in the scientific
field and beyond. We would also like to highlight practices of
resistance, the failure to acknowledge, ignorance of or even the
limits of the Unix system, its software tools and hardware
environment (beginning with the famous PDP and Vax machines from
Digital Equipment where the first Unix versions were implemented).
With a focus on occupational computer uses, we call for analysis
which aims to explore and clarify:
- the role of developers, users, and user associations – from the
point of view of pioneers as well as helpers, maintainers and other
witnesses of the implementation of Unix;
- the context, process, and people who determined its propagation,
appropriation, and development over time;
- the meaning of concepts of Unix philosophy and ethics such as
“openness” and “autonomy”, from a social, political or economic
point of view.
*2. Philosophical and epistemological perspectives*
We will foster research and reflection at the crossroad of the
theoretical foundations of computer systems and engineering
pragmatism, between the philosophy of computer systems and Unixian
Protagonists in the conception and diffusion of Unix often claim to
have a ‘Unix philosophy’ . But beyond statement of principle, what
was the real influence of this idea on the technical choices
underlying the system’s developments? What are the ethical, moral,
and philosophical motivations – alongside the social, political or
economic dimensions discussed earlier – underpinning the adoption of
Unix or pretending to extend it (for instance in relation to the
notions of sharing, modularity or freedom)? How is the idea of
‘openness’ attached to Unix practices and heritage (free software,
open source) conceived? What are the theoretical developments to be
drawn from it (for instance with the idea of open software)?
The logical and mathematical foundations of Unix should be
readdressed. Do the fundamental concepts of Unix have an ontological
or metaphysical significance beyond the sole research aim of
technical efficiency? What role do aesthetics play in the
formulation of general principles and technical choices? How can we
analyze programming languages such as C and its successors, scripts,
software, and generally speaking, the proliferating source codes of
Unix? How do we consider the system, the software environment, as
well as the hardware in which Unix is implemented and executed?
Such philosophical questions also cover the modalities of the
transmission of Unix, extending to the investigation of the
respective roles of theory and practice in the teaching of the
system, the teaching of knowledge and tools underlying the system or
supporting the system.
*3. Unix heritage and ‘heritagization’*
France is now the home to multiple initiatives taking place to build
and preserve a material and immaterial heritage of computer science
and technology – such as ‘Software Heritage’ at INRIA, a global
software archive in progress. The Museum of Arts et Métiers gave
impetus to the MINF initiative (‘Pour un Musée de l’informatique et
du numérique’) and coordinates the ‘Patstec Mission’ dealing with
contemporary scientific and technological heritage preservation,
including computer science. At an international scale and with a
grassroots perspective carried by the community of Unix users, the
TUHS (The Unix Heritage Society) demonstrates the current interest
in the specific heritage linked to Unix. We encourage reflections on
this heritage and its specific features:
- What is the place of Unix in the construction of computer science
heritage? Is it possible to map Unix systems and their heritage,
from the standpoint of machines, languages and software? What has
already been collected? What corpus, data bases, and/or platforms
with a patrimonial mission are concerned with Unix and to what purpose?
- How are the questions of training, constitution and diffusion of a
Unix culture incorporated in the effort to collect heritage? How do
we evaluate and put forward the importance of immaterial heritage
attached to Unix, considering the effects of community and memory in
its history and for the writing of its history?
- What are the practices and modalities advocated by the unixian
heritage itself? What has been its influence on the field of
computer engineering and research as well as diverse fields such as:
popularization of science and technology, ‘hacker’ movements and
many ‘maker’ practices today (Lallement, 2016)?
Please send a one-page abstract (maximum 500 words) with a short
biography by June 30, 2017 to: camille.paloque-berges(a)cnam.fr
loic.petitgirard(a)cnam.fr <mailto:email@example.com>. Accepted
contributions and speakers will be notified by July 15, 2017.
Isabelle Astic (Musée des arts et métiers)
Raphaël Fournier-S’niehotta (Cédric, Cnam)
Pierre-Eric Mounier-Kuhn (CRM, Paris 1)
Camille Paloque-Berges (HT2S, Cnam)
Loïc Petitgirard (HT2S, Cnam)
*Scientific committee *
François Anceau (UMPC-LIP6)**
Pierre Cubaud (Cédric, Cnam)
Liesbeth de Mol (STL, Lille 3)
Claudine Fontanon (CAK, EHESS)
Gérald Kembellec (DICEN, Cnam)
Baptiste Mélès (Archives Henri Poincaré, CNRS)
Pierre Paradinas (Cédric, Cnam, SIF)
Giuseppe Primiero (Middlesex University)
Lionel Tabourier (LIP6, Paris 6)**
*Institutional partners and support: *
- Project « Hist.Pat.info.Cnam », HT2S, Cnam – Research program
supported by the Excellence laboratory History and Anthropology of
Knoweldge, Technics and Beliefs (HASTEC), and in partnership with
the laboratories CEDRIC (Cnam), DICEN (Cnam), and the Center
Alexandre Koyré (EHESS).
- « Histoire de l’informatique » (« History of computing » seminar)
seminar - (Musée des arts et métiers, CRM, Paris 1, UMPC-LIP6)
- « Source code » seminar - (CNRS, Cnam, Université Paris 6).
With support from the DHST/DLMPST for the History and Philosophy of
Kelty, Christopher M. 2008. /Two Bits: The Cultural Significance of
Free Software/. Durham: Duke University Press Books.
Lallement, Michel. 2016. /L’âge du faire, /Seuil.
Mélès, Baptiste. 2003. « Unix selon l’ordre des raisons : la
philosophie de la pratique informatique ». /Philosophia Scientiæ/17
Salus, Peter H. 1994. /A quarter century of UNIX/. Addison-Wesley.
Toomey, Warren. 2010. « First Edition Unix: Its Creation and
Restoration ». /IEEE Annals of the History of Computing/ 32 (3): 74‑82.
> From: "Walter F.J. Mueller"
> the kernel panic after tcsh here documents is understood.
Very nice detective work!
> The kernel panic is due to a coding error in mch_fpsim.s. ... After
> fixing the "$SIGILL." ... and three similar cases
I'm fairly amazed that apparently nobody has run across one of these 4 before!
(Or, at least, not bothered to report it.)
I wonder how long that bug has been in the code?
On 2017-06-11 04:00, "Walter F.J. Mueller" <w.f.j.mueller(a)retro11.de> wrote:
> the kernel panic after tcsh here documents is understood.
> And fixed, at least on my system.
Nice work. Looking forward to patch #250. And to respond to Noels remark
about this being around for a long time without reports - since this is
in FPSIM, and I believe the notes for 2.11BSD even says that this is an
untested piece of code, which are not even know if it works or not, it's
not something that have been used for ages. I'm in a way surprised it
even worked at all. I think I've seen somewhere that it was last tested
around 2.9BSD, and have not been officially tested since.
> The essential hint was Johnny's observation that on his system he gets
> an "Illegal instruction - core dumped" and no kernel panic.
Well, had I had FPP simulated, I would maybe not have gotten a kernel
panic anyway. It would all depend on where the address ended up. With my
current build, the kernel would have been able to read the address,
since it pointed into the boot diagnostics rom. So it's a dicey error at
But the tcsh error was very good that you also figured out. And I guess
it means we now have a known working FPSIM. :-)
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
> Who started this? Why was the change made?
Arrays in Fortran and Algol were indexed from 1 by default, but
Algol (IIRC) generalized that to allow first:last declarations.
NPL used first,last for the SUBSTR operation. But first,last
begets off-by-one errors. The successor slice begins at last+1.
The formula for the position of 1-indexed a[i,j] is a mess.
First,length is much cleaner: the successor begins at
first+length. I convinced the committee of that, so when
NPL became PL/I, first,length was the convention. Zero-
indexing is also a clean first,length notation. BCPL,
where a[i] was synonymous with rv(a+i), had it. Dennis, who
knew a good thing when he saw it, took it over. Dijkstra,
too, often inveighed against 1-indexing, and opined that
zero was the true computer-science way.
1-indexing certainly came into programming languages from
the math tradition for matrix notation. Of course in
math series are often indexed from zero, so one may
pick and choose. Off hand I can only think of one CS
context where 1 comes in handy: heapsort.