TUHS

tuhs@tuhs.org

6515 discussions

Re: [TUHS] v6tar from v7 on v6, too large?

by jnc＠mercury.lcs.mit.edu

> From: Mark Longridge > I've never been able to transfer any file larger than 64K to Unix V5 or > V6. Huh? # hrd /windows/desktop/TheMachineStops.htm Mach.htm Xfer complete: 155+38 # l Mach.htm 154 -rw-rw-r-- 1 root 78251 Oct 25 12:13 Mach.htm # 'more' shows that the contents are all there, and fine. ('hrd' is a command in my V6 under Ersatz11 that reads an arbitrary file off the host file system. Guess I need to set the date on the system!) V6 definitely supports fairly large files; see the code in bmap() in subr.c, which shows that the basic structure on disk can describe files of 7*256 (1792) + 256*256 (65536) blocks, or 67328 blocks total (34MB). (In reality, of course, a file can't reach that limit; first, a disk partition in V6 is limited to 64K blocks, but from that one has to deduct blocks for the ilist, etc; further, the argument to bmap() is an int, which limits the 'block number in file' to 16 bits, and in fact the code returns an error if the high bit in the 'block number in file' is set.) > I also don't recall seeing any file on V5 or V6 larger than 65536 > bytes I don't think there is one; the largest are just less than 64KB. I don't think this is deliberate, other than in the sense that they didn't put any huge files in the distro so it would fit on a couple of RK packs. > dd if=/dev/mt0 of=cont.a bs=1 count=90212 > .. > 24676+0 records in > 24676+0 records out > Now, if we take 90212 and subtract 65536 we get 24676 bytes. So there > definitely seems to be some 64K limit here Probably 'count' is an 'int' in dd, i.e. limited to 16 bits. No longs in V6 C (as distributed, although later versions of the C compiler for V6 do support longs - see my 'bringing up Unix' pages). Noel

9 years, 5 months

Re: [TUHS] v6tar from v7 on v6, too large?

by jnc＠mercury.lcs.mit.edu

> From: Noel Chiappa > the most likely is that 'v6tar' is linked to be split I+D, and your V6 > emulation is on a machine that doesn't have split I+D (e.g. an 11/40) Now that I think about it, the linked systems that are part of the V6 distro tape are all linked to run on an 11/40. They will boot and run OK on a more powerful machine (/45 or /70), but they will act like they are on a /40 - i.e. no split I+D support/use (user or kernel). So to get split I+D support, you need to build a new Unix binary, with m45.s instead of m40.s. If you haven't done that, that's probably what the problem is. Aside: V6 comes in two flavours: no split I+D at all, or split I+D in both the kernel and user. For some reason that I can't recall, we actually produced an 'm43.s', BITD at MIT, which ran the kernel in non-split-I-D, but supported split I-D for the users. I wish I could remember why we did this - it couldn't have been to save memory (the machine didn't have a great deal on it when this was done - although I have this vague memory that that was why we did it), because running split I+D in the kernel does not, I think, use any more physical memory (provided you don't fiddle with the parameters like the number of buffers) than running non-split. Or maybe it does? One possible reason was that the odd layout of memory with split I+D in the kernel made debugging kernel code harder (we were doing a lot of kernel hacking to support early networking work); another was that we were just being conservative, didn't need to extra space in the kernel that I+D allowed, and so didn't want to run it. Noel

9 years, 5 months

TUHS Mail Server: upcoming change

by Warren Toomey

All, in the next few days I'm migrating minnie.tuhs.org from one VM to another, so as to upgrade the OS and clean out the system. I think I've got the mail subsystem up and running, but as usual there may be bugs. I'll send out another message when the system is cut over. If things don't seem to be right, e-mail me at: wkt at tuhs.org, or warren.toomey at tafe.qld.edu.au if the tuhs.org one fails. Cheers all, Warren

9 years, 5 months

Re: [TUHS] Happy birthday, Grace Hopper!

by Dave Horsfall

On Tue, 8 Dec 2015, Brantley Coile wrote: > We were indeed lucky that admiral hooper was with us. I know people who > still cherish their "nano" seconds. Ah yes, the 1ft piece of wire... Got a photo of it? > By the way, she wouldn't have said she coined the term "debugging". That > is at least as old as Thomas Edison. She said she was the first to a > actually find a real bug! For those who may be new around here: https://en.wikipedia.org/wiki/Grace_Hopper#/media/File:H96566k.jpg Yes, that is a real bug, found inside a real computer. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

9 years, 5 months

v6tar from v7 on v6, too large?

by Will Senn

All, According to "Setting Up Unix - Seventh Edition", by Haley and Ritchie: The best way to convert file systems from 6th edition (V6) to 7th edition (V7) format is to use tar(1). However, a special version of tar must be prepared to run on V6. The document goes on to describe a reasonable method to make v6tar on v7 and copy the binary over to the v6 system. I successfully built the v6tar binary, which will execute in the v7 environment. I then moved it over to the v6 system and did a byte compare on the file using od to dump the octal bytes and then comparing them to the v7 version. The match was perfect. The problem is this, when I attempt to execute the v6tar binary on the v6 system (it works in v7) it errors out: v6tar v6tar: too large on the v7 system, it works: v6tar tar: usage tar -{txru}[cvfblm] [tapefile] [blocksize] file1 file2... I don't think the binary is too large, is is only 18148 bytes. ls -l v6tar -rwxrwxrwx 1 root 18148 Oct 10 14:09 v6tar Help. First, what does too large mean? Second, does this sound familiar to anyone? etc. Thanks, Will

9 years, 5 months

Happy birthday, Grace Hopper!

by Dave Horsfall

OK, slightly OT... Rear Admiral Grace ("Amazing") Hopper PhD was given unto us in 1906. She was famous for coining the term "debugging", whereby a moth was removed from a relay contact in a *real* computer[*]. However, she must be condemned for giving us COBOL; yes, I know that vile language, but I carefully leave it off my CV, as it seemed to be designed for suits (Business Studies of course, but nothing technical) to spy upon their programmers. [*] Defined, of course, where you could open a door and step inside it; I actually did that once. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

9 years, 5 months

Re: [TUHS] Scan of "Edition 0" manual

by Doug McIlroy

> It might not be so much a set of macros as just using a > subset of raw groff. Yes, there were no macros back then. If you format the document using raw groff, the odds are that you will be speaking the same roff that Dennis did. > Doug having been there, might know/remember the actually lineage. Aside from some fuzziness about who wrote what and in what language, here's what happened: To port Jerry Saltzer's Runoff (presumably written in MAD) to Multics, either Dennis or Bob Morris or both together reimplemented it (presumably in PL/I). To coexist with Saltzer's version on CTSS, the new program needed a distinct name, hence roff. The early Multics PL/I compiler was far from a production tool. Justifiably, the Bell Labs comp center didn't support it. To get roff into general use at the Labs, I undertook yet another implementation in BCPL. I added functionality (number registers, three-part headings, etc) and kept the new name. Molly Wagner added hyphenation. Eventually, I added macros that were usable either as commands or (when parameterless) embedded in text. Almost as soon as Unix was up on the PDP-11 one of Ken, Dennis or Ossanna reimplemented a pre-macro version of roff (presumably in assembler or B). I'm quite sure roff never ran on the PDP-7. Ossana had a grander plan and undertook nroff. When he learned of the availability of the Graphic Systems CAT phototypesetter, he promptly generalized nroff to handle it. Joe replaced the CAT's paper tape reader with a direct wire to the computer. It all worked swimmingly--nothing like the travails when the CAT was replaced by the more capable Merganthaler Linotron. An interesting question of priority is whether nroff or BCPL roff was first to have a macro capability. Though I don't remember for sure, the fact that BCPL roff unified registers, macros, strings and diversions suggests that I abstracted from nroff facilities. Doug

9 years, 5 months

Installing and Using Research Unix Version 7 in SimH PDP-11/45 Emulator

by Will Senn

All, In the same vein as my prior note, I have made a note available on the process of getting up and running on Unix Seventh Edition in a SimH PDP-11 environment. The text is located at: http://decuser.blogspot.com/2015/12/installing-and-using-research-unix.html I welcome comments, suggestions, and even criticisms. While I have learned a lot since my last blog entry (many thanks to Hellwig Geisse, Nelson Beebe, Noel Chiappa, Clement Cole and several others), I am still learning about these environments. I originally invested time in getting v7 running so that I could more easily work with v6, after having gone there, I believe that it was time very well spent. I know a lot more about special devices, tape formats, and so on than I did before as a result of taking the fork in the road. Thanks for everyone's help. Oh, and by the way, there appears to be quite a bit of active interest in this topic - the blog post has been viewed several thousand times since I posted it, two weeks ago. Kind regards, Will

9 years, 5 months

Adding an RP06 disk to a running V7 instance

by Will Senn

I have set up v7 following [1] and I would like to better understand the process of adding a disk to the environment. Here is what I know: The system has one RP06 with two partitions rp0 and rp3 which correspond to the two block devices rp0, rp3, and the two character devices rrp0, and rrp3. The special files look like so: brw-r--r-- 1 root 6, 0 Dec 31 19:05 /dev/rp0 brw-r--r-- 1 root 6, 7 Dec 31 19:04 /dev/rp3 crw-r--r-- 1 root 14, 0 Dec 31 19:01 /dev/rrp0 crw-r--r-- 1 root 14, 7 Dec 31 19:01 /dev/rrp3 This meshes with the device classes switches in c.c: The block device switch: struct bdevsw bdevsw[] = { ... nulldev, nulldev, hpstrategy, &hptab, /* hp = 6 */ ... } The character device switch: struct cdevsw cdevsw[] = { ... nulldev, nulldev, hpread, hpwrite, nodev, nulldev, 0, /* hp = 14 */ ... } I would like to add another RP disk to the environment. After I attach an RP04/05/06 to the system, what should I use as the major/minor device numbers? To put it differently, it doesn't seem correct to me to use 6,1 for the block device or 14,1 for the character device on the new drive as it's a completely different disk from rp0 and rp3 which are just partitions on the first drive and have 6,0, 6,7, and 14,0, 14,7. If each RP can have 8 partitions and there can be 8 drives, what is the correct major, minor numbers to use with v7 for multiple devices? c.c only lists one vector each for the hp device (one block vector where hp = 6, and one char vector where hp = 15). Thanks, Will [1] Haley, C. B. & Ritchie, D. M. (1979). Setting Up Unix – Seventh Edition (pp. 497-505) in UNIX programmer's manual, Vol. 2, Revised and Expanded Version. Bell Laboratories: NY.

9 years, 6 months

boot block in v7 bootable on rp06 in simh

by Will Senn

In exploring v6, I have found some uses for having a running v7 instance... When I try to install the RP bootblock during the installation procedure for installing Version 7 Unix following the original documentation: ftp://ftp.uvsq.fr/pub/tuhs/PDP-11/Documentation/v7_setup.html I am unable to boot from the RP06 disk that I installed into the boot block onto via: dd if=/usr/mdec/hpuboot of=/dev/rp0 count=1 No error, it just hangs. I compared hpuboot to the bootblock at it matches byte for byte. I also compared it to the hpuboot file in Henry Spencer's tape image (I am using Keith Bostic's tape) and it matches that as well. I am asking this list because I thought y'all might know if there was a problem with: 1) the hpuboot binary on the tapes 2) v7 using RP06 3) something else helpful :) (maybe it's not supposed to be loaded to byte 0 on the disk image, although that's how it works with v6?) I am aware that the system can be booted from tape, but that seems hokey (obviously it works, since that's how the installation process works in the first place, but I think it is reasonable to expect to be able to boot from the RP06). Interestingly, there are and RL02 and RK05 v7 images that boot from disk available, but not RP. I will ask on the SimH list, if y'all don't think it's appropriately directed. Thoughts? Thanks, Will

9 years, 6 months

Some notes on running UNIX v6 in 2015, using SimH and a healthy dose of documentation

by Will Senn

All, I am studying Unix v6 using SimH and I am documenting the process, as I go, as part of my own learning process. I have much to learn about Unix, Unix v6 in particular, the PDP architecture and its relationship with v6, and SimH's emulation of the PDP, so, I am taking notes... I thought that I would share the notes in raw form as occasional blog posts in the hope that the knowledge that I work to obtain, might be made available and useful to others. I also believe that these forms of communication, as insignificant as they may seem individually are part of helping to preserve the knowledge of our computing history, in the aggregate. Here is a link to the first post, a run at an installation walk-through: http://decuser.blogspot.com/2015/11/installing-and-using-research-unix.html I am open to feedback and criticism, but please keep in mind that I am a relative newbie to v6 and PDP land, some of my assumptions are probably/undoubtedly wrong, but definitely fixable :). Regards, Will

9 years, 6 months

Re: [TUHS] Some notes on running UNIX v6 in 2015, using SimH and a healthy dose of documentation

by jnc＠mercury.lcs.mit.edu

> From: Will Senn <will.senn(a)gmail.com> > a deeper read will require the reader to have knowledge beyond what is > required of most modern software developers (PDP-11 architecture, > assembly language, and UNIX are prerequisite). Well, for pretty much any _operating system_ (as opposed to applications), one will need to know something about the details of the machine it is intended to run on; depending on which part of the OS one is looking at, it will be more or less. E.g. switching processes probably requires a fair amount, since one needs to know about internal CPU registers, etc; whereas working on the file system, one probably doesn't need to know very much about the machine. > It will also require access to a lab where the ideas covered can be > experimented with. Actually, Lions/V6 was used in operating systems courses using simulated machines; one at MIT, 6.828 "Operating Systems Engineering": https://pdos.csail.mit.edu/6.828/ used it for a while before the students started complaining about being forced to learn an obsolete machine. They thereupon wrote a V6 clone for the x86 architecture, 'XV6' (see the top of that page), which is apparently now used for similar courses at quite a few other universities. > The v6 kernel ... packs in features that were either unavailable in > larger more established systems or may have been present in some form, > but were orders of magnitude more lines of code and attendant > complexity. It was and remains an amazing operating system and worthy > of contemporary study. I don't think you will find too many people here who disagree! ;-) > So, I was thinking that next up, I would write up notes to help the > modern reader engage with v6 more easily in order to follow works like > Lyons. Check around online to see what exists, first; there has been stuff written since Lions! ;-) Noel

9 years, 6 months

Re: [TUHS] Some notes on running UNIX v6 in 2015, using SimH and a healthy dose of documentation

by SZIGETI Szabolcs

Hi, Don't forget the Zuse machines, which were later proven to be Turing complete. It is certainly fascinating to see handling binary floating point numbers in a purely mechanical device (check it out if you happen to be in Berlin). Later machines were electromechanical and electronics. Regards, Szabolcs > > 2015.12.04. 15:52 ezt írta ("John Cowan" <cowan(a)mercury.ccil.org>): >> >> Greg 'groggy' Lehey scripsit: >> >> > Take a look at CSIRAC in the Melbourne museum, the oldest computer in >> > the world. It's worth it, even if they don't have it running. >> >> Well, there's the Antikythera mechanism. >> >> -- >> John Cowan http://www.ccil.org/~cowan cowan(a)ccil.org >> In the sciences, we are now uniquely privileged to sit side by side >> with the giants on whose shoulders we stand. --Gerald Holton >> _______________________________________________ >> TUHS mailing list >> TUHS(a)minnie.tuhs.org >> https://minnie.tuhs.org/mailman/listinfo/tuhs

9 years, 6 months

Re: [TUHS] Installing a large set of files into v6 from a modern host

by Clem Cole

below On Fri, Dec 4, 2015 at 12:02 AM, Will Senn <will.senn(a)gmail.com> wrote: > 1. a utility on the host that is capable of copying a directory and its > contents, recursively, onto a blank magtape/dectape/rk image that is then > readable in the v6 environment > Right - you want a common archive format between the two systems that talk to the tape device. You can either create your own or better take on the old ones that exist. > 2. a tar and unzip binary for v6 that is capable of dealing with the > tarball (but isn't the tarball going to exceed the max file size anyway, if > so this won't work) > I think you have a many to chose from off the top of my head I can think of each with different advantages (more in a minute): - tar - cpio - tp/stp - ar (new format) You seem to also want a compression tool, but you might try compressing on the modern system - but there are solution here also. - pack/unpack was the old v5/v6 compression tool - I've forgotten where it was sourced check the first USENIX tape in 77 - porting a modern zip/gzip/bzip > 3. an alternative archiver that runs on FreeBSD or Mac OS X, that can > create a single file archive from a subdirectory's contents on the host > (the resultant file would need to be extractable on v6, and if file size is > too limited, won't work either). > That is a lot of work and unless this is going to be a very long term thing, I'm not so sure it's worth it. Basically you want a virtual FS on the v6 system and the simulator. If you are going to do this alot, then its worth it. Think the VFS that vmware and like offer. > 4. some kind of directory transfer utility that works over telnet that can > be executed from a FreeBSD or Mac OS X host and that can be executed on the > v6 system as well. > the original unix kermit will compile using the v6 compiler (maybe the v5) compiler. You have to dig in the archives, but you want a version from Columbia circa 1977 and you be fine. The latest version will use things in the language first described in the white book - aka Typersetter C (Dennis was wrote the book starting with v6, but's not published until v7). If you a later compiler running on v6 you'll be fine. > 5. a utility capable of creating an empty magtape/dectape/rk image and > another capable of making a filesystem on the image and another of > populating the image (analogous to fdisk rkimage; mkfs rkimage; rkcopy dir > rkimage) > You could move the file system creation tools and set of a virtual v6 FS. It's a lot of work and unless this is going to be a very long term thing, I'm not so sure it's worth it. As for the archivers which in the short term is likely to be your best bet: 1. tar - there a couple of versions of tar for v6 including binaries. I personally would start there. 2. cpio was written for PWB 1.0 which is v6 kernel based. That binary should run. But IIRC correctly the original cpio was only binary headers (the -c/ascii headers was added later). So you'll need to be careful on the modern computer and make sure you set the switches so that he created the proper endian/byte swapping -- ness in the header 3. tp/stp - on the original USENIX tape is a "super tp" that replaced the original one. The binary should run as is. The code for it is pre-K&R so compiling it with a modern compiler will be a little bit of work. Also, IIRC the "directory" which is on the front of the tape is binary, so you'll need to make sure you write everything in PDP-11 format. 4. ar - was updated by the community. Eventually, V7 took the "new ar" from original USENIX tape. Again that binary should just run fine. Although I don't think its directory is recursive so it may fail that requirement for you Clem

9 years, 6 months

Installing a large set of files into v6 from a modern host

by Will Senn

All, I am trying to figure out how to get parts of 1BSD added into a pristine v6 install, but the question I have relates to moving more than a handful of files from a host system into v6, which lacks several capabilities that are taken for granted from v7 onward (tar, unzip, and so on). For background, in looking at the 1bsd tarball, exploded out, I saw that ex was available on the tape in a binary form that is suitable for a PDP-11/40 and I thought it would make life easier in v6 to have ex. So, I used dd to move the a.outNOID file onto a file, which can be used as a raw RK image and then off the RK image loaded in the PDP-11 into the v6 system as the executable file ex, and that worked. I was able to run ex (well, sort of, I get the colon prompt anyway... I haven't figured out how it actually works yet). Yeeha! Having had success of a sort with a single executable from the 1BSD tape, I would like to see if other parts of 1BSD will work in the environment and if I can properly install those parts. Individually moving files using dd is tedious in the extreme (there are many files in the tarball). I know there has to be a better way. Since v6 doesn't have tar, or unzip, it doesn't seem likely that using dd to move the tarball into v6 will be help matters. But, if there was a way to dd a subdirectory and its contents onto an RK image and get them off again into a useable v6 file system, that would work. My question for the group is based on the preceding discussion and the following assumption: 1. given a tarball such as 1bsd.tar.gz from the TUHS archive located at: /PDP-11/Distributions/ucb 2. with a running SimH PDP-11/40 instance with a virtual TU10 magtape with a virtual TU56 dectape with a virtual RK05 hard drive 3. running v6 as the operating system What is an efficient method of moving the files of the 1bsd distribution, or any other set of files and directories, into the v6 operating environment? Here are some approaches that seem reasonable, but that I haven't been able to figure out, if you know better, please do tell: 1. a utility on the host that is capable of copying a directory and its contents, recursively, onto a blank magtape/dectape/rk image that is then readable in the v6 environment 2. a tar and unzip binary for v6 that is capable of dealing with the tarball (but isn't the tarball going to exceed the max file size anyway, if so this won't work) 3. an alternative archiver that runs on FreeBSD or Mac OS X, that can create a single file archive from a subdirectory's contents on the host (the resultant file would need to be extractable on v6, and if file size is too limited, won't work either). 4. some kind of directory transfer utility that works over telnet that can be executed from a FreeBSD or Mac OS X host and that can be executed on the v6 system as well. 5. a utility capable of creating an empty magtape/dectape/rk image and another capable of making a filesystem on the image and another of populating the image (analogous to fdisk rkimage; mkfs rkimage; rkcopy dir rkimage) If I am asking the wrong questions, or thinking badly, I would appreciate a steer in the right direction. Regards, Will

9 years, 6 months

Re: [TUHS] Some notes on running UNIX v6 in 2015, using SimH and a healthy dose of documentation

by jnc＠mercury.lcs.mit.edu

> From: Will Senn <will.senn(a)gmail.com> > I am studying Unix v6 using SimH and I am documenting the process I did a very similar exercise using the Ersatz11 simulator; I have a lot of stuff about the process here: http://www.chiappa.net/~jnc/tech/V6Unix.html It contains a number of items that you might find useful, e.g.: "V6 as distributed is strictly a 20th Century operating system. Literally. You can't set the date to anytime in the 21st century, for two reasons. First, the 'date' command only take a 2-digit year number. Second, even if you fix that, the ctime() library routine has a bug in it that makes it stop working in the closing months of 1999." > the PDP architecture Technically, a PDP-11 - there were a number of different PDP architectures: https://en.wikipedia.org/wiki/Programmed_Data_Processor is a decent listing of them; several (PDP-8, PDP-10, etc) were very popular and successful. A few things I noted in your first post: > I am using the Ken Wellsch tape because it boots and is stated to be > identical to Dennis Ritchie's tape other than being bootable and having > a different timestamp on root. The only differences I could discover between the two are that in the Wellsch versions i) a Western Electric rights notice (which prints on booting) has been added to ken/main.c, and the Unix bootable images; and ii) the RK pack images do have, as you noted, the bootstrap in block 0. > Note: sh is critically important, don't muck it up :). The issue is > that if you do, there really isn't an easy way to recover. One should _never_ install a new shell version as '/bin/sh' until it has been run and tested for a while (for the exact reason you mention). Happily, in Unix, as far as the OS is concerned, the command interpreter is just another program, so it's trivial to name a new binary of the shell 'nsh' or something, and run that for a while to make sure it's working OK, before installing it as '/bin/sh'. > a special file (whatever that is) Special files are UNIXisms for 'devices'. _All_ devices in Unix appear as 'special files' in the file system, usually (but not necessarily) in /dev - that location is a convention, not a requirment of the OS. Noel

9 years, 6 months

Re: [TUHS] Scan of "Edition 0" manual

by Warren Toomey

On Sun, Nov 29, 2015 at 08:55:23PM -0800, Paul McJones wrote: > Thanks very much for making the original and the OCR-enhanced versions > of Doug’s scan of the “UnixEditionZero” document available > on tuhs.org. I notice that even with Nelson’s enhanced version, > the file size is still large for a scanned text document, apparently > because it was originally scanned in RGB mode, 24 bits/pixel. The > attached version is 2.5MB, and to my eye is identical looks identical > to UnixEditionZero-OCR.pdf. Paul, I've added your version into the same directory. Thanks! Warren

9 years, 6 months

Portable Pascal and a 1BSD question

by Will Senn

Hi all, In v2 no5 AUUGN Jun-Jul 1980, Andy Tanenbaum announced the availability of a Portable Pascal Compiler for the then proposed ISO standard. A tape was made for v6, v7, and non-unix platforms. Does anyone know if there is a tape image around that has the distro? On a related note, has anyone successfully installed 1BSD on a v6 install running in SImH? 1BSD has the Berkeley Pascal Instructional system on it. Regards, Will Sent from my iPhone

9 years, 6 months

Re: [TUHS] tool (that wnj wrote?) that reduced the data segment size?

by Norman Wilson

I'm too tired to dig for the exact words in the ISO standard, but I had the impression that the official C rule these days is that the effect of writing on a string literal is undefined. So it's legal for an implementation to make strings read-only, or to point several references to "What's the recipe today, Jim" to one copy of the stripng in memory, and even to point uses of "Jim" to the tail of the same string. Or both. It is also legal for every string literal to reside in its own memory and to be writable, but since the effect is undefined, code that relies on that is on thin ice, especially if meant to be portable code. I have used, and even fixed (unrelated) bugs in, a compiler that merged identical strings. I forget whether it also looked for suffix matches. Whether the strings went in read-only memory was up to the code generator (of course); in the new back-end I wrote for it, I made them so. This turned up quite a few fumbles in very-old UNIX code that assumed unique, writable string literals, especially those that called mktemp(3). To my mind that just meant the programs needed to be fixed to match current standards (just as many old programs needed fixes to compile without error in ISO C), so I fixed them. I didn't (and still don't) like Joy's heavy-handed hack, but I see his point, and think it's just fine for the language rules to allow the compiler to do it hacklessly. Norman Wilson Toronto ON

9 years, 6 months

Does anyone know what wnj is doing?

by Larry McVoy

Last I heard, and this is ~25 years ago, he was in Aspen just hanging out. Is he OK? --lm

9 years, 6 months

tool (that wnj wrote?) that reduced the data segment size?

by Larry McVoy

I've gotten sucked into an embedded system project and they are running out of memory. I have a vague memory of some sort of tool that I think Bill Joy wrote (or maybe he told me about it) that would do some magic processing of all the string constants and somehow it de-dupped the space. Though now that I'm typing this that doesn't seem possible. Does this ring a bell with anyone? I'm sure it was for the PDP 11 port. Thanks, --lm

9 years, 6 months

Re: [TUHS] Scan of "Edition 0" manual

by Nelson H. F. Beebe

Thanks, Doug and Warren, for the new files at http://www.tuhs.org/Archive/PDP-11/Distributions/research/McIlroy_v0/ At the TUHS mirror at my site, you can find an additional file http://www.math.utah.edu/pub/mirrors/minnie.tuhs.org/PDP-11/Distributions/r… ftp://ftp.math.utah.edu/pub/mirrors/minnie.tuhs.org/PDP-11/Distributions/re… that is less than half the size, and is (somewhat) searchable, thanks to Adobe Acrobat Pro 11 OCR conversion. Please include that in the TUHS master archive, even renaming it to the original file, if you wish. I like the beginning of "Section 2. Hardware", where Dennis wrote: >> ... >> The PDP-11 on which UNIX is implemented is a 16-bit 12K computer, >> and UNIX occupies 8K words. More than half of this space, however, is >> utilized for a variable number of disk buffers; with some loss of >> speed the number of buffers could be cut significantly. >> ... How much more powerful early Unix was compared to CP/M and MS-DOS, in a small fraction of their memory space! ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

9 years, 6 months

Re: [TUHS] tool (that wnj wrote?) that reduced the data segment size?

by Doug McIlroy

> Woe betide the user if any string was changed at run time... That was then. Now it would be OK to do so for const data. (Unless the tool chain has discarded const indications.) Doug

9 years, 6 months

Re: [TUHS] "Edition 0" manual

by Doug McIlroy

> It's worth noting that Unix was built for troff. Typesetting patents if I recall correctly. This is a stretch. Unix was really built because Ken and Dennis had a good idea. The purchase of a PDP-11 for it was in part justified by the goal of making a word-processing system. The first in-house "sale" of Unix was indeed to the patent department for typing patents--the selling point was that roff could be made (by an overnight modification) to print line numbers as USPTO required, whereas that was not a feature of a commercial competitor. The timeline is really roff--Unix--patent--nroff--troff. Though roff antedated Unix, it did not motivate Unix. > Is this The UNIX Time-Sharing System, or related to it? The same > claim appears in the first paragraph: > https://www.bell-labs.com/usr/dmr/www/cacm.html This draft clearly dates from 1971. Pieces of it were worked into subsequent versions of the manual as well as published descriptions of Unix, including the SIGOPS/CACM paper. Doug

9 years, 6 months

Porting 2.11 BSD

by Oliver Lehmann

Hi, I wanted to at least give it a try porting 2.11 BSD to my Z8001 machine. I din't really wrote any kernel part until now so it will be a huge learning curve for sure. No idea what my spare time permits, but... at least I'm planning giving it a try. I didn't found something like "thing you should do first when porting 2.11 BSD to another architecture" online so I thought myself... maybe it would be good to start with the standalone utilities - more precisely with "disklabel". Is there a good "HOWTO" for "first things first" as implementing disklabel seems to require quite some "device work" before the first "hello world" is there - is there something else which should be could be done first and does not require so much to port (the whole disk subsystem on that machine is different from "usual" disk subsystems as it is handled via a PIO) Regards, Oliver

9 years, 6 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