TUHS

tuhs@tuhs.org

6532 discussions

by Doug McIlroy

Early on, when multics was understood to have one big, segemented address space, it was expected that PL/I name qualification ($) would serve to address segments. I do not know whether that idea was actually implemented. Doug

7 years, 7 months

/bin/true (was [TUHS] basic tools / Universal Unix)

by Ron Natalie

My favorite reduction to absurdity was /bin/true. Someone decided we needed shell commands for true and false. Easy enough to add a script that said "exit 0" or exit 1" as its only line. Then someone realized that the "exit 0" in /bin true was superfluous, the default return was 0. /bin/true turned into an empty, yet executable, file. Then the lawyers got involved. We got a version of a packaged UNIX (I think it was Interactive Systems). Every shell script got twelve lines of copyright/license boilerplate. Including /bin true. The file had nothing but useless comment in it.

7 years, 7 months

Re: [TUHS] Dash options

by jnc＠mercury.lcs.mit.edu

> Multics had some kind of `attach' and `detach' of I/O streams, well > known to Ossanna, so perhaps dup(2), and a Thompson-shell syntax to go > with it meant `>' was earmarked early on. According to "The Evolution of the Unix Timesharing System", full path names arrived later than I/O redirection, so by they time they needed a separator, '>' and '<' were gone. '/' also has the advantage of being a non-shift character! Noel PS: Re-reading that, I see that early Unix did not have an exec() call (as I was just discussing); it was done in user mode, with normal read and write calls.

7 years, 7 months

Re: [TUHS] Dash options

by Paul Ruizendaal

> On Tue, Nov 28, 2017 at 2:36 PM, Paul Winalski <paul.winalski(a)gmail.com> > wrote: > >> MS/DOS patterned its command line >> >> syntax after RT-11 and inherited the slash as a command option >> introduction from there. > > Minor correction... To do a CDC style patient zero history ;-) RT11 took > it from DOS/8, CP/M took it from RT11, then finally DOS-86 which became > PC-DOS ney MS/DOS took it from CP/M. I think Gary Kildall was very much into the PDP-8 when teaching at the Naval Post Graduate School in the early 70's (doing the FORTRAN/8 compiler for instance). Can't find the link now, but I read somewhere that his work with the 8008 and 8080 was guided by the idea of having a PDP-8 like machine in his home office. For CP/M's command syntax RT11 probably did not come into it. I just had a quick glance through the CP/M 1.4 - 2.2 manuals, and I did not see slash options (or any other option character). Microsoft bought QDOS as a base for PC-DOS/MS-DOS. The QDOS system calls were done such that converting existing 8080 CP/M code with Intel's source level 8080-to-8086 asm converter would generate the correct code. The FAT file system was modeled after the one used by MS Disk BASIC for the 8086. Not sure where the QDOS command line came from, other than CP/M. MS did a lot of its early development on a PDP-10: perhaps that was an inspiration too. Sorry for getting off-Unix-topic...

7 years, 7 months

Re: [TUHS] Harvard and Von Neumann Architectures and Unix

by jnc＠mercury.lcs.mit.edu

> From: Doug McIlroy > But if that had been in D space, it couldn't have been executed. Along those lines, I was wondering about modern OS's, which I gather for security reasons prevent execution of data, and prevent writing to code. Programs which emit these little 'custom code fragments' (I prefer that term, since they aren't really 'self-modifying code' - which I define as 'a program which _changes_ _existing_ instructions) must have some way of having a chunk of memory into which they can write, but which can also be executed. > Where is the boundary between changing one instruction and changing them > all? Or is this boundary a figment of imagination? Well, the exec() call only overwrites existing instruction memory because of the semantics of process address space in Unix - there's only one, so it has to be over-written. An OS operating in a large segmented single-level memory could implement an exec() as a jump.... BTW, note that although exec() in a single address-space OS is conventionally something the OS does, this functionality _could_ be moved into the user space, provided the right address space primitives were provided by the OS, e.g. 'expand instruction space'. So the exec() code in user space would i) find the executable, ii) see how much of each kind of memory it needs, iii) get the OS to give it a block of memory/address space where the exec() code can live while it's reading in the new code, iv) move itself there, v) use standard read() calls to read the new image in, and then vi) jump to it. Yes, it's probably simpler to implement it in the OS, but if one's goal is to minimize the functionality in the kernel... Noel

7 years, 7 months

A sober reminder of why distributed archiving is important

by Will Senn

In case you missed it: https://www.spectrum.ieee.org/view-from-the-valley/tech-history/silicon-rev… It is important to keep the conversations alive and not to file your memory boxes away in the attic. Thanks for sharing what you know and especially for making your documents and bits available. -will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF

7 years, 7 months

TTY8

by Ron Natalie

OK, we were discussing terminals this morning with some other old guys. If I knew the answer to this I've forgotten. Every PDP-11 UNIX I ever used had the console KL-11 as /dev/tty8. The question is why. My guess is that for some reason an 8 terminal multiplexor (DZ-11?) was stuck at tty0, but why?

7 years, 7 months

Re: [TUHS] Harvard and Von Neumann Architectures and Unix

by jnc＠mercury.lcs.mit.edu

> From: Larry McVoy >> they aren't really 'self-modifying code' - which I define as 'a program >> which _changes_ _existing_ instructions > Isn't that how dtrace works? I'm not familiar with dtrace(), but if it modifies some other routine's code, then it would not be "self" modifying, right? Oh, another category, sort of like biological viruses (which are in a grey zone between 'alive' and not): the PDP-11 paper tape bootstrap: http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/bootloader.mac in which the program's own code _is_ modified - but not by program instructions, but by data on the paper tape it is reading in. It's entertainingly convoluted (the copy above should be well-enough commented to make it pretty easy to understand what's going on). Noel

7 years, 7 months

RIP J.F.Ossanna

by Dave Horsfall

We lost J.F. Ossanna on this day in 1977; he had a hand in developing Unix, and was responsible for "roff" and its descendants. Remember him, the next time you see "jfo" in Unix documentation. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

7 years, 7 months

Re: [TUHS] UNIX on S/370

by jnc＠mercury.lcs.mit.edu

> From: Kevin Bowling > The earliest stuff may be covered by Novell's grant of early code. > ... > Would be fun to run *ix on any of them. Alas, the Bell port of Unix to the /370 needs that underlying layer of code from IBM, and that's probably not going to escape. Too bad, it would be pretty cool. Noel

7 years, 7 months

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