TUHS

tuhs@tuhs.org

12 participants
6534 discussions

[Unix-jun72] Invitación a conectarnos en LinkedIn

by Sergio Pedraja

LinkedIn ------------ Me gustaría añadirte a mi red profesional en LinkedIn. -Sergio Sergio Pedraja IT Security Administrator / Information Security Manager en Savings Bank Santander y alrededores, España Confirma que conoces a Sergio Pedraja: https://www.linkedin.com/e/-p9hg1j-gyzit23b-16/isd/6035310103/YCHqBtRa/?hs=… -- Estás recibiendo invitaciones a conectar. Haz clic para darte de baja: http://www.linkedin.com/e/-p9hg1j-gyzit23b-16/pQvcBySBaffs0LLhMMtx8DQb3x_CT… (c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, EE.UU.

13 years, 4 months

Invitación a conectarnos en LinkedIn

by Sergio Pedraja

LinkedIn ------------ Me gustaría añadirte a mi red profesional en LinkedIn. -Sergio Sergio Pedraja IT Security Administrator / Information Security Manager en Savings Bank Santander y alrededores, España Confirma que conoces a Sergio Pedraja: https://www.linkedin.com/e/-amg4ei-gyzit20d-4/isd/6035310080/f1t_FAOT/?hs=f… -- Estás recibiendo invitaciones a conectar. Haz clic para darte de baja: http://www.linkedin.com/e/-amg4ei-gyzit20d-4/IES2kw2WbAK2tgMLcf1q-MI/goo/tu… (c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, EE.UU.

13 years, 4 months

Invitación a conectarnos en LinkedIn

by Sergio Pedraja

LinkedIn ------------ Me gustaría añadirte a mi red profesional en LinkedIn. -Sergio Sergio Pedraja IT Security Administrator / Information Security Manager en Savings Bank Santander y alrededores, España Confirma que conoces a Sergio Pedraja: https://www.linkedin.com/e/-9arw1o-gyzisxbk-15/isd/6035309375/9Ym-js9F/?hs=… -- Estás recibiendo invitaciones a conectar. Haz clic para darte de baja: http://www.linkedin.com/e/-9arw1o-gyzisxbk-15/_SZkCeK7HqzqROuy9YxIdtKYnud5R… (c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, EE.UU.

13 years, 4 months

why the leading under score added to function names?

by arnold＠skeeve.com

Hi All. Recently at work I helped someone figure out that when working with ld, the name of a function "foo" gets turned into "_foo" by the compiler. (It took this old-timer 15 minutes to solve a problem he had been working on for two days!) I'm pretty sure this dates back to PDP-11 days. I'm wondering "why?". Why did the C compiler prepend an underscore to function names? Thanks, Arnold

13 years, 4 months

Yet Another Kernel Description Document

by Warren Toomey

All, I've just received from Poul-Henning Kamp a document entitled "UNIX Program Description", dated January 1976 and written by the UNIX Support Group. It contains detailed descriptions of the functions inside a Unix kernel. Given the date and the USG origin, I'm guessing that the system described is PWB/1.0. Can anybody confirm this at all? The URL is http://minnie.tuhs.org/Archive/PDP-11/Distributions/usdl/unix_program_descr… but I'll move it if it turns out not to be about PWB. I love how new documents and artifacts keep appearing! Thanks phk. Cheers, Warren

13 years, 4 months

Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

by Hendrik Jan Thomassen

If I recall well the /sbin directory first appeared in HP/UX, and the name stood for 'Static binaries'. Its reason for existence was that with the introduction of shared libraries the file with the C-library had become a single point of failure. Therefore this sbin was introduced to hold Statically linked executables for the most important commands needed to fix a broken system (sh, ls, mv, cp, find, tar, fsck etcetera). With this directory earlier than /bin in his PATH the administrator could at least restore a working libc.so file. And, while we are at it, the name 'executable' was not commonly used: they were called 'binaries' (except in IBM mainframe terminology were they were called 'load modules'). Only much later the habit of /sbin = System binaries emerged. An important reason to split /bin vs. /usr/bin and /lib vs. /usr/lib etc. was that the root file system had to be kept small. The fsck program, while at work, builds tables. If possible, they stay in memory, but if memory runs out fsck writes them to disk. However, you don't want them to be written to an untrusted/unchecked file system, and certainly not to the file system currently under repair. Since the root file system has to be checked before the others, it had to be small enough so ensure that fsck could run memory-based only. Therefore: the /bin, /lib and other root-fs based directories held the minimal stuff needed for booting and for repairs/restores, while all the rest had to go into the "overflow" directories /usr/bin, /usr/lib etc (and, obviously, /usr was a separately mounted partition). Remember: those were the days that every reboot included a full fsck on all your partitions. -- Hendrik-Jan Thomassen <hjt(a)ATComputing.nl> AT Computing 6546 BE Nijmegen NL Fax +31 24 352 72 92 info(a)atcomputing.nl www.atcomputing.nl 'If you think education is expensive, then try ignorance.'

13 years, 5 months

Re: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

by Pepe

"Jose R. Valverde" <jrvalverde(a)cnb.csic.es> said: > Beyond that, the original articles and comments complained also about > directory naming (/bin /etc /lib) as "unintuitive". I fail to > understand in > what way is it easier for someone new to a computer to learn a "/bin > /etc /var /lib" alien terminology and what it means, than to learn > "System Config Libraries > etc..." or "Windows Windows32 Windows64 Temp Users and Settings, > etc..." In SCO Xenix/UNIX, the home directory is usually mounted on /u. I was amused the first time I saw it.

13 years, 5 months

Re: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

by Norman Wilson

Lyndon Nerenberg: A well designed system without library bloat can pump out some pretty skinny static binaries. ======= V6, for example. Or even V7 if carefully pruned. Once upon a time, I made an RK05 disk (5MB) with a stripped-down post-V7 for an 11/45. It had just enough programs to allow basic file manipulation and text-processing. We used this compact system to allow our secretaries (in a small university department in the early 1980s) to continue typing up papers and letters on the day the machine-room air conditioning was being replaced. With the doors standing open and a big fan, we were willing to leave the 11/45 running, but not the VAX-11/780. Due to contractor screwups (when the chilled water was turned on, it rained up and down the hall--many poorly-soldered joints in the copper pipes), we actually needed this for a couple of days, so for safety I shut the system down every evening, removed the RK05 cartridge, and took it downstairs to the 11/34 that had a tape drive, where I booted RT11 and took an image backup with ROLLOUT. Norman Wilson Toronto ON

13 years, 5 months

Re: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

by arnold＠skeeve.com

> http://www.osnews.com/story/25556/Understanding_the_bin_sbin_usr_bin_usr_sb… Cute, but most of the history is wrong. The distinction between /bin and /usr/bin is true - / held the things need to boot the system. Other things were on /usr. The Berkeley guys did NOT invent shared libraries. Shared libraries as we know them came originally from Sun, on SunOS 4.x for sure, possibly on SunOS 3.x. (Larry?) Many commercial vendors adopted the design (Ultrix, I think, and maybe others) and finally around 4.4 they found their way into "pure" BSD. /home and /opt came into the picture circa 1989 with SVR4 when Berkeley, AT&T and Sun (and maybe a few others?) got together to standardize the layout and make diskless booting possbile and reasonable with NFS sharing of home directories. /sbin & /usr/sbin came into the picture at this point also, to hold executables that until then had lived in /etc. The idea was that /etc should only have per-machine configuration files. The general point of the article and of some of the postings, that the proliferation doesn't make a lot of sense today, is well taken. The Bell Labs guys themselves recognized this when they did Plan 9. The problem is even worse on 64 bit Linux systems, which can handle two different architectures. /lib and /lib64 confuse a lot of the older 'configure' programs. Personally, I hate reading articles by "experts" where 85% of the facts are wrong. I lived through all of it, and I know better... :-) Arnold

13 years, 5 months

xv6

by A. P. Garcia

saw this on osnews under 'related articles'; it's a rewrite of sixth edition for x86: http://pdos.csail.mit.edu/6.828/2011/xv6.html

13 years, 5 months

History of man pages

by Greg 'groggy' Lehey

I've received a link http://manpages.bsd.lv/history.html claiming to be about man pages; in fact, it's a lot more than that, including the prehistory of troff. Interesting stuff. Greg -- Sent from my desktop computer Finger grog(a)FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua

13 years, 5 months

awkcc source code available

by Aharon Robbins

Hi. I announced this in comp.lang.awk in December and tried to BCC the TUHS list but it didn't seem to happen. Here's the announcement I posted. Arnold ----------------------------------------------- From: arnold(a)skeeve.com (Aharon Robbins) Newsgroups: comp.lang.awk Subject: AWKCC source now available Date: Fri, 16 Dec 2011 12:27:39 +0000 (UTC) Message-ID: <jcfdfr$qt9$1(a)dont-email.me> [ BCC to TUHS list, Brian Kernighan & Chris Ramming ] awk 'BEGIN { print "Sherman, set the wayback machine for 1988" }' Hello All. This note is to announce that through the valiant efforts of Brian Kernighan, Alcatel-Lucent has been persuaded to make the source for awkcc available. It can be found at: https://open-innovation.alcatel-lucent.com/projects/awkcc You have to register (no cost) before being able to download, but it's easy. The license terms are at the site. It's a straightforward "for personal use" kind of license. For those who don't know, awkcc is an adaptation of Unix awk to translate nawk programs into C. It was originally implemented by Chris Ramming (then at Bell Labs, although no longer) circa 1988, and the source dist includes some doc that Chris wrote. Given how fast machines are these days, this program is mostly of historical interest. But it's nice to have this bit of Unix / awk history generally available. And, if you really need to turn an awk program into C, this may provide a starting point. Enjoy! -- Aharon (Arnold) Robbins arnold AT skeeve DOT com P.O. Box 354 Home Phone: +972 8 979-0381 Nof Ayalon Cell Phone: +972 50 729-7545 D.N. Shimshon 99785 ISRAEL

13 years, 5 months

uunet ftp sources archive available

by arnold＠skeeve.com

Hi All. I announceced this some years ago but it's been renewed, so I'll announce it again. In 2004 sometime I downloaded all the comp.sources stuff I could from uunet.uu.net, which was still making it available for anonymous ftp. I've made a tarball of it available from http://www.skeeve.com/Usenet.tar.bz2 Warren, if you don't have this in the TUHS archives, maybe you could add it? Thanks, Arnold

13 years, 6 months

qemu and virtualbox

by Andrzej Popielewicz

Hi, For those who want to refresh old memories. Hans Bezemer has made big progress as far as performance of qemu is concerned. His specific experience concerns Coherent, but other old unixes could use it. Details can be found in comp.os.coherent news group http://groups.google.com/group/comp.os.coherent/topics The older tuhs message can be mentioned : http://minnie.tuhs.org/pipermail/tuhs/2008-July/001815.html I have also noticed , that Coherent boots well and is very fast in newest virtualbox 4.1.8, running in XP. Dell Optiplex 755 was used with Core 2 Duo. Details can be found in forums for "Other quests" http://www.virtualbox.org It suggests , that other old Unixes could benefit in new virtualbox. Regards Andrzej

13 years, 6 months

hello, world

by Norman Wilson

Rather a nice tribute to Dennis and C, published in the New York Times Magazine: http://www.nytimes.com/interactive/2011/12/22/magazine/the-lives-they-lived…

13 years, 6 months

Re: [TUHS] hello, world

by David Barto

A long time ago at the University that I graduated from. . . Shell scripts had just added the ability to have functions in them, so I wrote a script to do some processing of files that I had, and then logged off to let it run in the background. The shell script was named 'A'. In the script was a function, named 'A' When the script ran, instead of calling 'A' the function, it called 'A' the script, and you can see where this goes from here. 2 days later I received an email from the admin (thankfully a friend) who enclosed the 'ps -axl' output from the machine. It showed thousands of copies of my script running and a load that indicated that the machine was useless for almost everything. With the admonishment: "Don't ever do this again." I haven't. David David Barto barto(a)kdbarto.org barto(a)ucsd.edu

13 years, 6 months

Re: [TUHS] hello, world

by Tim Newsham

On Mon, Dec 26, 2011 at 8:15 PM, Dave Horsfall <dave(a)horsfall.org> wrote: > On Tue, 27 Dec 2011, Warren Toomey wrote: >> Yes, a good reminder on the power that programming brings us. A question >> though: what command would "bring the system down"? > > It's right here: "Programmers were free to poke around to see and directly > manipulate what was in the computer's memory." http://minnie.tuhs.org/pipermail/unix-jun72/2008-May/000250.html > -- Dave -- Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com

13 years, 6 months

early version of top

by Oliver Lehmann

Hi, I wonder if someone has an early version of top lying around? I'd like to try getting it to work on my ZEUS clone. I'd start with 1.0 from 1984 if possible ;) Regards, Oliver

13 years, 6 months

recreating C source from binary

by Oliver Lehmann

Hi, I'm trying to re-create the source files for the Z8000 UNIX I have on my Z8000 system (it is a S8000+ZEUS clone). Easy programs like sync.c where easy. But when argc/argv is involved, I'm not able to generate 1:1 matching binary code. I'm working on /etc/unlink for now. I tried the following C file: char whatstr[] = "@[$]unlink.c 2.1 07/23/82 21:19:30 - 87wega3.2"; main(argc, argv) int argc; char **argv; { if(argc!=2) { write(2, "Usage: /etc/unlink name\n", 24); exit(1); } unlink(argv[1]); exit(0); } The original ASM code for the beginning of main() until the argc check is: 0042 abf3 dec r15,#4 0044 5df60000 ldl %0000(r15),rr6 0048 0b070002 cp r7,#%0002 The ASM code my C file generates is: 0042 abf3 dec r15,#4 0044 1df6 ldl @r15,rr6 0046 0b070002 cp r7,#%0002 keep in mine, that r15 is considered as the "stack pointer". I wonder how to get the ldl from the original binary. I also tried to declare argv with "char *argv[]" which resulted in the same code. Forcing the compiler to store argv into a register by using the "register" keyword results in completly different code: (sp = stack pointer = r15) #17 adb unlink ADB: P8000 1.6 ? 0x0042/i %0042: dec sp,#6 ? %0044: ld %0004(sp),r14 ? %0048: ld %0002(sp),r7 ? %004c: ld r14,r6 ? %004e: cp r7,#%0002 ? $q #18 Maybe the C compiler used to compile /etc/unlink differs from the C compiler shipped with the system (maybe an older version) but I don't want this to be true for now ;) Anyone with deeper ASM and C knowledge than me sees what could be done here? Before someone asks - yes I'm sure the source file was in C and not ASM based on the whatstr. Symboltable of the original /etc/unlink is empty as well (striped binary). Regards, Oliver

13 years, 6 months

Re: [TUHS] Command line post-arguments with #!

by Norman Wilson

Sven Mascheck: With "original implementation (post 7th ed", I meant the undistributed BellLabs-internal further development of 7th, the first system ever to implement #!, leading to 8th ed, etc. (4BSD just incorporated this). Not System V or other relatives, though. ======= Can you cite a reference? I'm quite familiar with what went on inside the system that was later called 8th Edition, having been on the inside at Bell Labs starting in mid-1984. But that was after the original research group's general move to VAXes--they had no PDP-11s left by then, except a few LSI-11s running special-purpose systems rather than UNIX. In fact the VAX kernel they had adopted, I think sometime earlier that year, was derived from that of 4.1 BSD. (It diverged quite a bit from that start later, for which I am appreciably to blame, but that has nothing to do with #!). So if #! was implemented in an earlier kernel I don't know just what was done. I'd assumed it was no different; if I'm mistaken I'd love to see just how it really was. Alas, the person I know was on the spot and was likely to remember just what happened in what order can no longer answer questions ... Norman Wilson Toronto ON

13 years, 6 months

Re: [TUHS] Command line post-arguments with #!

by norman＠oclsc.org

Sven Mascheck: Well the original implementation (post 7th ed and 4.0/4.1 BSD) didn't allow arguments at all ;-) ====== I believe you're mistaken. All the implementations I've ever used allowed a single argument in the #! line, and inserted the name of the script between that (if present) and the arguments given to exec. e.g. if ./lipsum began with #!/usr/bin/awk -f awk would be invoked with `/usr/bin/awk -f ./lipsum ...'. Without allowing one argument for -f or the like, #! wouldn't have been useful for much but the shell. Norman Wilson Toronto ON

13 years, 6 months

speak.c, or sometimes the bits are under your nose

by Warren Toomey

Hi all, in the past few days I've been getting some interesting e-mails from a new TUHS member, Jonathan Gevaryahu. He has been searching for some lost software, and his story of how he found it is a good reminder to check through all the zeroes and ones on the digital media at hand. With his permission, I reproduce the e-mails below. Cheers, Warren Hi, I'm Jonathan Gevaryahu, one of the developers of MESS but also a speech synthesis history buff. I've been trying to find a copy of the old unix 'speak' command source code and rule tables that M. D. Mcilroy wrote back in 1974ish, but the TUHS archives only have the man pages for it, and not the actual program or its tables. As for the "why?" of this, its an important piece of history, and the phoneme set used on the Federal Screw Works "VOTRAX" Model VS-4 unit which was used with 'speak' at Bell Labs is compatible with the later Votrax Model VS-6 unit at CHM, and also with the Votrax "SC-01" chip used in some arcade/video games, several computer peripherals, and on the "Type 'N' Talk" and "Personal Speech System" products. So actually running the old code and having it speak should be quite doable, if we can recover enough of it to be useful. [ Jonathan assumed that the 'speak' source code had been lost. ] I even asked Doug McIlroy about it a few years ago and he didn't have a copy, and I had assumed it was just plain lost... Until today. I was poking around in random TUHS files (after reading about the v1 unix restoration project) and noticed that the size of recovered files from the ritchie v6 tapes in the .tar.gz files is actually significantly smaller than the tapes themselves. I assumed there had to be some other data there, possibly corrupt or fragmentary, and got down to peeking at the file contents themselves. There were some mentions of speak.m and .c and .v, but finally, in http://minnie.tuhs.org/Archive/PDP-11/Distributions/research/Dennis_v6/v6do… I found the remains of the speak program. See http://pastebin.com/FdvRYM2T for what I've managed to recover so far (actually since i pasted that I recovered a good deal more of it, but a lot is out of order and bits are missing) The file is fragmentary as far as I can see, and is only speak.c (the .m file containing the rules I haven't found yet, but since Doug has a scanned copy of the paper describing speak on his website, hopefully I can just regenerate the rule tables if needed), but it is there! Hopefully speak.m or .v are still waiting to be found on that or one of the other tape images. Also there are other things on that tape like the chess program, and tic tac toe, which may not exist elsewhere. (Though, for these two I honestly haven't checked) Also, in the last 5 minutes I found a chunk of what I'm pretty sure is either speak.m or speak.v, so there's more than just the .c file there. Further progress attached of recovering speak from deleted disk pack sectors: I have all of speak.c in order except for one 512-byte sector, which was overwritten at some point, in the phoneme table. (This has to be the least "damaging" sector of the entire program. lucky!) I also have a good chunk (maybe 50-60%) of what may be a mix of speak.m and speak.v, both out of order. I did not yet find a copy of 'speakm', the rule displayer program for speak.m/.v. There is a program, located after speak.c on the disk image, which looks like it would convert numbers and months to their full speakable names. In addition, either slightly more or slightly less of the files may be intact on the http://minnie.tuhs.org/Archive/PDP-11/Distributions/research/Ken_Wellsch_v6… image, which appears to be originally an exact dd-copy of the dennis_v6 disk packs. Ok, here's the 'repaired' speak.c file, with the missing entries of the table filled in (this was IMMENSELY helped by the fact that speak.o, the compiled object file, was also on the disk pack and appears to be fully intact including the table; the ruleset files are fragmentary so far.)

13 years, 6 months

Provenance of the documents used to restore 1st Ed Unix

by Warren Toomey

All, here's a special Christmas present, especially for those who helped out with the restoration of the 1st Ed Unix system, see http://code.google.com/p/unix-jun72/ To do the restoration we needed a copy of the 1st Ed Unix kernel source code, and Al Kossow had found these two documents and scanned them in: http://minnie.tuhs.org/Archive/PDP-11/Distributions/research/Dennis_v1/Kern… http://minnie.tuhs.org/Archive/PDP-11/Distributions/research/Dennis_v1/Prel… At the time nobody could work out who had studied the kernel source code, why they had done it etc. Nor could we work out who Ted Bashkow was and why he was involved. After my IEEE Spectrum article I was contacted by Jim DeFelice to say thanks for the article. I recognised him as one of the people named in the above documents, and asked him about the kernel study. He has contacted some of the people involved and sent me the e-mail below, which gives a full description of the work! Before I get to it, just an aside. According to Berkley Tague, Ted Bashkow "was a visiting Professor for the summer some time around 1970 or 1971 and worked with me and others in research on various topics. I don't believe he contributed much to UNIX at that time, but was an early user of the early systems." Cheers, Warren [ Jim's story] Here is as coherent a story as I can piece together Let me know if you have any more questions. Jim. The documents that describe the UNIX system as it was implemented on the PDP-11/20 circa 1971 originated as a consequence of a project undertaken within the comptrollers department of the AT&T General Departments. The project was titled the Investment and Cost Information System (ICIS). It was a major new accounting system intended to track detailed cost information for the operating telephone companies of the Bell System. ICIS was a major IBM mainframe based system which was being developed in COBOL. I transferred from Bell Labs in late 1970 to join Chuck Everhart who preceded me from the Labs. In 1971 we were joined by Ron Silacci, Cathy Judge, and later (early '72?) Jerry Conser all from Bell Labs. We formed the core of what would become a much larger Development staff by 1973. In preparation for a major development effort, we wanted to develop a system to maintain the spate of expected ICIS specification and design documents including graphics such as flowcharts. We decided on the PDP-11/20 with a Tecktronix T4002 graphics terminal as the hardware platform for the development of our document maintenance system. For obscure reasons, in order to purchase the PDP-11/20, the ICIS team needed to get approval from the Bell Labs computer aquisition review department headed by Berkley Tague. Berk made the approval for the purchase contingent us agreeing to use UNIX as the operating system.First hearing of this "UNIX" verbally, my mind was filled with scenes from the Arabian Nights. "Eunuchs" seemed a strange name for an operating system. At the time, the only instances of UNIX were to be found in the hands of the developers (Ken Thompson & Co.) at Murray Hill, NJ. We naturally asked for all the documentation. We were told there was none. What we got was a source listing of the PDP-11 assembly language UNIX Kernel. It was virtually without any commentary or external description. In order to proceed we undertook to reverse engineer the listing in order to understand how to modify UNIX to support the T4002. To that end, in late 1971, we set up shop at a Labs facility in Piscataway, NJ. The team got occasional hints and pointers from the UNIX developers at Murray Hill, but they tended to be focussed on their own work (the C programmimg language, troff, etc.). Initial progress was slow, but as the overall design structure emerged and the team became fluent with PDP assembly language and the coding style of the UNIX developers things moved along. Early work was done with paper and pencil resulting in the document named by you as "Kernel Subroutine Description...". Once we took delivery of our PDP-11/20, we were able to make use of the UNIX tools "ed" and "roff" to create a more easily edited digital document "Preliminary UNIX Implementation Document" The detailed timing of all this is uncertain. The hand work was done from late 1971 through March 1972 resulting in the Kernel Subroutine documentation. Chuck Everhart left AT&T in late 1971 and I became the group supervisor. A draft of the machine based Preliminary Implementation document was completed by June 1972 per the date on my cover letter for its first distribution. By June 1972 there was evidently a lot of interest in UNIX inside Bell Labs. The computer commitee was pushing UNIX for all PDP based projects inside Bell Labs. The ICIS owned PDP-11/20 was probably received after March 1972. The hand written cover letter to Ted Bashkow is dated 4/3/72. Once we had use of the PDP-11 we would have entered our work directly. The modifications for the T4002 are not dated in your PDF version and do not appear in the original printout that I still have. I don't know why the date on all the printed pages is 3/17/72. Also, missing in the PDF version of the Preliminary Implementation document that is in the paper version is a subroutine cross reference listing that lists which subroutines are called by which. Regarding the authorship of the documents. Looking at the handwriting it seems at least four people contributed to the Kernel Subroutine document. Myself and Ron have actually reviewed the document and can claim authorship to specific sections. By sections: J. DeFelice H0_01, H0_02, H0_03,H0_04,H0_05, H2-11_sysexec call chain, H2.4,H2_1.7,H2-8, H2-9 H4-3, H5-1, H5-2, H5-3, H5-4, H5-7, H7-1, H7-2, H7-4, H7-5,H7-6, H8-01.2, H8-02, H8-03, H8-05, H8-06, H8-07, H8-08, h8-09-00, h5-6 Ron Silacci sysclose, syscreate, sysent, sysexit, sysfork, sysmdate, sysgetty, sysmdir, error, badsys, sysopen, sysret, sysrele, sysstty, syswait, read, write, ani, sysstat, sysgetuid, sysintr, syslink, sysseek, syssetuid, sysstat, sysstime, systime, sysquit, sysunlink, wdir, fclose, isdir, isown, maknod, mkdir, getf, seektell, sysbreak, syschdir, syschmod, syschown, clear, idle, putlu, swap, tswap, unpack, rswap, wswap, clock, isintr, retisp, sleepo, setisp, tty0, wakall, ttyi, wakeup, itrunc, imap, dskr, cpass, readi, canon, cesc, ctty, ttych, getspl, iclose, iopen, sysmount, sysumount, bread, bwrite, dioreg, drum, preread, rtap, tape, tstdeve, trapt, rw1, intract, otty. Unknown 1 (all caps) H4_00, H4_01, H4_02, H4_2.1, H6_2.2, H6_3.0, H6_6, H7_0.0.4, H7_3.0, H7_3.2 H7_3.3, H9_00.1, H9_01, H9_02, H9_03 Unknown 2 H0_06, H0_07, H2_0.2, H2_3,H2_4, H3_2, H3_4, H5_2.0, H5_2.1,H6_0.9, H6_1.0, H6_1, H6_2.0, H6_2.2, H6_3, H6_4, H8_09, H8_11 The two unknowns would be Jerry Conser and Cathy Judge. I have not been able to track them down. The comments in the listing were made by the people who authored the corresponding man pages. We would comment the listing and as understanding dawned write up the man page. I had a major hand in Section F but can't claim sole responsibility. The people listed in the recipients list in Ted Bashkow's cover letter are the members of the computer aquisition department. According to Joe Maranzano: "Ted Bashkow was a professor from Columbia who was on a 6-month sabbatical in Berkley Tague's department. The other names on the memo are: Dan Clayton David Copp Gwen Hansen Jossie Hintz Ruth Klein Jim Ludwig Georgette Petit Joe Ritacco Berk Tague Dan Vogel Linda Wright This was the composition of the Department in 1972 and most of us were working on Computer Acquisition Reviews for the Computer Centers. The Unix Support Group was formed in 1973." By the time the Tecktronix application was developed, the ICIS development project was ramping up. The developers were using punch cards for their Cobol programs. It occurred to me that we could utilize our UNIX system to eliminate punch cards which were difficult to manage and instead enter and edit the Cobol code using "ed". My management (rotated in from Bell Operating Companies) was not keen on diverting resources towards more tool building but I had enough autonomy to push through the ordering of a PDP-11/45 and a DEC developed Bisync communications interface card. This configuration allowed the UNIX system to emulate an IBM card reader/printer. The PDP11/45 had memory protection, which made committing all the source code for a major project to UNIX thinkable. I did all the development work on a bisync driver myself while my group attacked the main IBM development. The resulting system worked well and over the course of a few months all the die hard card rearder afficianados had converted to the new system. This despite the occasional file system crash. At the time you could go in and edit i-nodes by hand to recover lost files and directories. So with frequent tape backups for insurance we never lost more that a few hours worth of work. The Bell Labs UNIX support department (formed in 1973) eventually took over the maintenance of the system and dubbed it the Programmers Work Bench. Other types of workbench were to follow. I lost track of developments in the UNIX world till I transferred back to Bell Labs in 1982. By then the UNIX support organization was an entire Laboratory. The hardware platform was the DEC VAX system, UNIX was rewritten in C, and Berkely UNIX was a major competitor to the AT&T version. I still have the design and code for the Bisync driver if you are interested.

13 years, 6 months

Re: [TUHS] E-mail address for Dick Haight?

by Norman Wilson

Arnold Skeeve: Have you asked Doug McIlroy? ======= Actually I did, last night, on Warren's behalf. I had meant to drop Doug a note anyway to apologize for not letting him know I was in his general neighborhood last week. Here's Doug's reply: Pipes were first documented in v3, Feb 1973. At that time my original clumsy shell syntax, cmd>cmd>[file] was still in use. Within a few months, Ken invented today's pipe symbol as something more presentable at a talk he'd been invited to give in England--an Infosys "State of the Art" conference if I remember correctly (not the same Infosys as the current Indian giant). I also remember the very blackboard in the garret lab where I sketched my syntax and Ken exclaimed, "I'll do it". That was late in the day and I'm quite sure it was dark outside. Unlike Ken, I was not in the habit of staying in the lab into the evening. That makes me think that pipe day was not too far off the solstice. It would be nice to believe that pipes preciptated the third edition, but in fact the first four editions came out almost like clockwork at 8-month intervals, so any correlation with pipes is highly speculative. ====== Norman Wilson Toronto ON (actually Ramsey NJ at the moment, a good bit north of Murray Hill)

13 years, 7 months

Re: [TUHS] E-mail address for Dick Haight?

by arnold＠skeeve.com

Have you asked Doug McIlroy?

13 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