From rsnow1 at charter.net  Tue Oct  1 06:55:54 2002
From: rsnow1 at charter.net (Richard Snow)
Date: Mon, 30 Sep 2002 14:55:54 -0600
Subject: [pups] Re: minnie.tuhs.org mailing list memberships reminder
References: <200209301903.g8UJ3SD09107@minnie.tuhs.org>
Message-ID: <3D98BA5A.8010509@charter.net>

now that i've signed up for this list I have forgotten what the topic is?

I am a disabled veteran, I do some work with Linux as a hobby, and some 
web sites, also as
a hobby.  I may be getting a Vaxstation soon.  I don't think is one of 
the ones supported by
Linux yet.  

Richard Snow




From wkt at minnie.tuhs.org  Tue Oct  1 07:43:27 2002
From: wkt at minnie.tuhs.org (Warren Toomey)
Date: Tue, 1 Oct 2002 07:43:27 +1000 (EST)
Subject: [pups] Re: vaxstation
In-Reply-To: <3D98BA5A.8010509@charter.net> from Richard Snow at "Sep 30, 2002
 02:55:54 pm"
Message-ID: <200209302143.g8ULhRi12751@minnie.tuhs.org>

In article by Richard Snow:
> I may be getting a Vaxstation soon.  I don't think is one of 
> the ones supported by Linux yet.  
> Richard Snow

Richard, in that case you might prefer to switch to the TUHS mailing list:
http://minnie.tuhs.org/mailman/listinfo/tuhs

PUPS is mainly for PDP-11s, TUHS is for other old boxen that run Unix.

Mind you, a lot of people are subscribed to both!

	Warren


From rlhamil at mindwarp.smart.net  Fri Oct  4 04:40:16 2002
From: rlhamil at mindwarp.smart.net (Richard L. Hamilton)
Date: Thu, 3 Oct 2002 14:40:16 -0400 (EDT)
Subject: [pups] Req help rebuilding v7 rl2unix with dz driver added
Message-ID: <200210031840.g93IeGq15243@mindwarp.smart.net>

(running under simh V2.9-11)
I wanted to add the dz driver for multi-"terminal" support.  But I'm
a bit stumped figuring out how to rebuild rl2unix, let alone how to add
the dz driver.  (no rlconf/rl2conf file, although mkconf.c looks like maybe
it knows about the rl2 if not about the dz)

Is this do-able?  Is the dz driver in the v7 image usable?

-- 
mailto:rlhamil at mindwarp.smart.net  http://www.smart.net/~rlhamil



From Robertdkeys at aol.com  Fri Oct  4 14:00:31 2002
From: Robertdkeys at aol.com (Robertdkeys at aol.com)
Date: Fri, 4 Oct 2002 00:00:31 EDT
Subject: [pups] Interdata 3220 backup tape found... worth recovering for archives?
Message-ID: <19c.9e2d881.2ace6c5f@aol.com>

I chanced upon some old V7 stuff today, from a
researcher at the Duke University Medical Center
that did not have the heart to just throw them
out.  There was a complete manual set for V7 from
a Perkin-Elmer NMR machine dating from 1984, and
a backup tape of the system (9 track Scotch 700
series 6250bpi) dated 12/17/80.  The machine was
apparently an Interdata 3220 (Perkin-Elmer was
supposed to have bought out Interdata).

The manuals will make for fun reading, but there
may be some worthwhile bits if the tape is OK.
Anyway, I am seriously thinking of trying to
read the contents of the tape, and pass them on
to Warren, for the archives, if he thinks that
is something to do.

As to reading the tape, with the highest chance
for successful recovery, what would the list
folks recommend.  I was thinking of just doing
a retension on the tape to wind it off the reel
and prevent sticking, and then maybe use the
copytape ditty that has been floating around the
net since time began, which should list file
sizes, block sizes, file types, etc., while
reading the files to disk.

I can roll the tape on a VAX or a Sparc system
using a Cipher M995S deck.

Any suggestions from the list?

Thanks

Bob Keys
robertdkeys at aol.com


From drwho8 at worldnet.att.net  Thu Oct 10 15:23:30 2002
From: drwho8 at worldnet.att.net (Gregg C Levine)
Date: Thu, 10 Oct 2002 01:23:30 -0400
Subject: [pups] Can someone advise me regarding a gui for UNIX
Message-ID: <002d01c2701d$34746140$6260580c@who>

Hello from Gregg C Levine
Cross posted to both TUH, and PUPS lists, apologies to all.
Can someone advise me regarding when the GUIs became a standard feature on
UNIX? Or operating systems whose ancestry was indeed UNIX? I know that with
Linux, for example started carrying one, about the same time the kernel
became capable of supporting it. Or at least that's my opinion. With regard
to the materials we discuss here, well, that's what I am attempting to
ascertain.
Gregg C Levine drwho8 at worldnet.att.net
"Oh my!" The Second Doctor's nearly favorite phrase.



From grog at lemis.com  Thu Oct 10 16:25:05 2002
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Thu, 10 Oct 2002 15:55:05 +0930
Subject: [pups] Re: [TUHS] Can someone advise me regarding a gui for UNIX
In-Reply-To: <002d01c2701d$34746140$6260580c@who>
References: <002d01c2701d$34746140$6260580c@who>
Message-ID: <20021010062505.GL87617@wantadilla.lemis.com>

On Thursday, 10 October 2002 at  1:23:30 -0400, Gregg C Levine wrote:
> Hello from Gregg C Levine
> Cross posted to both TUH, and PUPS lists, apologies to all.
> Can someone advise me regarding when the GUIs became a standard feature on
> UNIX?

Well, there are three variables.  GUI, standard and UNIX.

> Or operating systems whose ancestry was indeed UNIX? I know that
> with Linux, for example started carrying one, about the same time
> the kernel became capable of supporting it. Or at least that's my
> opinion. With regard to the materials we discuss here, well, that's
> what I am attempting to ascertain.

If by "GUI" you mean a windowing system, and by "standard" you mean
generally available, then I'd say the late 80s.  I started using X11R3
on Interactive UNIX/386 in early 1990.  I'm sure I didn't count as an
"early adopter".

Greg
--
Finger grog at lemis.com for PGP public key
See complete headers for address and phone numbers


From imp at bsdimp.com  Thu Oct 10 16:54:39 2002
From: imp at bsdimp.com (M. Warner Losh)
Date: Thu, 10 Oct 2002 00:54:39 -0600 (MDT)
Subject: [pups] Re: [TUHS] Can someone advise me regarding a gui for UNIX
In-Reply-To: <20021010062505.GL87617@wantadilla.lemis.com>
References: <002d01c2701d$34746140$6260580c@who>
	<20021010062505.GL87617@wantadilla.lemis.com>
Message-ID: <20021010.005439.54141511.imp@bsdimp.com>

In message: <20021010062505.GL87617 at wantadilla.lemis.com>
            "Greg 'groggy' Lehey" <grog at lemis.com> writes:
: > Or operating systems whose ancestry was indeed UNIX? I know that
: > with Linux, for example started carrying one, about the same time
: > the kernel became capable of supporting it. Or at least that's my
: > opinion. With regard to the materials we discuss here, well, that's
: > what I am attempting to ascertain.
: 
: If by "GUI" you mean a windowing system, and by "standard" you mean
: generally available, then I'd say the late 80s.  I started using X11R3
: on Interactive UNIX/386 in early 1990.  I'm sure I didn't count as an
: "early adopter".

I was using X10R4 on a Sun3/50 in 1987 or so.  I more commonly used
sunview in a similar time frame.  Sunview/OpenWindows has been
standard on Sun machines since that time.  It was surprising snappy
for a 50MHz 68k machine, so long as you didn't swap, but I digress.
There were similar offerings from DEC and I think HP in approximately
the same time frame.

It depends on what you mean by GUI I guess :-)

Warner


From hansolofalcon at worldnet.att.net  Tue Oct 15 08:30:36 2002
From: hansolofalcon at worldnet.att.net (Gregg C Levine)
Date: Mon, 14 Oct 2002 18:30:36 -0400
Subject: [pups] Ultrix-3.1 boot tape inside the PDP-11 distribution directory
Message-ID: <000301c273d1$55446520$685e580c@who>

Hello from Gregg C Levine
This is both my first post from this address, and a couple of questions.
Question 1) Has anyone actually followed the instructions and
description of same, found inside the readme file found in the
directory?
Question 2) Was this on actual hardware? Or inside the Simh simulator?
Or even with one version of E11? 

In my case this will be inside the Simh simulator, and I am basically
working straight from the beginning. If all goes well, I'll move it to
the E11 one.

-------------------
Gregg C Levine hansolofalcon at worldnet.att.net
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."  Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi )
(This company dedicates this E-Mail to Master Yoda )






From Fred.van.Kempen at microwalt.nl  Tue Oct 15 09:08:40 2002
From: Fred.van.Kempen at microwalt.nl (Fred N. van Kempen)
Date: Tue, 15 Oct 2002 01:08:40 +0200
Subject: [pups] Ultrix-3.1 boot tape inside the PDP-11 distribution directory
Message-ID: <7AD18F04B62B7440BE22E190A3F7721407FCE5@mwsrv04.microwalt.nl>

Gregg,

> Question 1) Has anyone actually followed the instructions and
> description of same, found inside the readme file found in the
> directory?
Yes.  They are a cut-and-paste log of my actual screens, although I
can't
remember exactly what was in the file.

> Question 2) Was this on actual hardware? Or inside the Simh simulator?
> Or even with one version of E11? 
I did installs on real hardware (MicroPDP-11/23 and MicroPDP-11/83), and
on Ersatz-11 (V3.0) for DOS. 

> In my case this will be inside the Simh simulator, and I am basically
> working straight from the beginning. If all goes well, I'll move it to
> the E11 one.
Ultrix-11 runs fine on SimH, with the "downs" that because SimH does not
do detailed and correct CPU emulation, Ultrix gets confuzed every now
and
then, which does not happen with E11.

I am preparing a new (V3.2) release of Ultrix-11 which has major
changes,
including:

- full system regeneration off single source tree
- full RAxx support
- addition of VTserver, TDU and compress
- compressed manual pages and documentation
- Y2K support (not just date(1) ;-)

The installation procedure has also changed to a more modern style.  I
don't have much time right now, so progress is slow.  The above is
"done",
though.

If you need help with Ultrix-11, pse contact me off-list.

--fred


From wkt at minnie.tuhs.org  Fri Oct 18 13:06:36 2002
From: wkt at minnie.tuhs.org (Warren Toomey)
Date: Fri, 18 Oct 2002 13:06:36 +1000 (EST)
Subject: [pups] Minnie mail down over the weekend
Message-ID: <200210180306.g9I36aB20475@minnie.tuhs.org>

The machine which hosts this mailing list is scheduled to be down over the
Australian weekend due to power problems. It should be up on Monday
morning Australian time.

	Warren


From wkt at minnie.tuhs.org  Tue Oct  1 07:37:35 2002
From: wkt at minnie.tuhs.org (Warren Toomey)
Date: Tue, 1 Oct 2002 07:37:35 +1000 (EST)
Subject: [TUHS] Re: Making boot disks
In-Reply-To: <20020930214211.5d53a9a0.spyro@f2s.com> from Ian Molton at "Sep
 30, 2002 09:42:11 pm"
Message-ID: <200209302137.g8ULbZH12674@minnie.tuhs.org>

In article by Ian Molton:
> Hi.
> 
> Dunno if you can help me ont this...
> 
> I have an unusual UNIX derived OS called RISCiX, but I cant install it
> because I have no bootdisks.
> 
> I /do/ have scripts to make them, and the kernel + OS files, though.
> 
> I think the filesystem was UFS.
> 
> I can use my Linux box to create a filesystem, but I dont have a copy of
> the right utility (newfs?).
> 
> Can you point me to source?

I'll pass this to the mailing list to see if others can help you.
I'd say that Linux is unlikely to construct the correct filesystem type.
There are severl UFS variants, and you'd need to know the exact layout
details to be sure that Linux (or something else) could create the
boot disks.

	Warren


From wkt at minnie.tuhs.org  Tue Oct  1 07:43:27 2002
From: wkt at minnie.tuhs.org (Warren Toomey)
Date: Tue, 1 Oct 2002 07:43:27 +1000 (EST)
Subject: [TUHS] Re: [pups] Re: vaxstation
In-Reply-To: <3D98BA5A.8010509@charter.net> from Richard Snow at "Sep 30, 2002
 02:55:54 pm"
Message-ID: <200209302143.g8ULhRi12751@minnie.tuhs.org>

In article by Richard Snow:
> I may be getting a Vaxstation soon.  I don't think is one of 
> the ones supported by Linux yet.  
> Richard Snow

Richard, in that case you might prefer to switch to the TUHS mailing list:
http://minnie.tuhs.org/mailman/listinfo/tuhs

PUPS is mainly for PDP-11s, TUHS is for other old boxen that run Unix.

Mind you, a lot of people are subscribed to both!

	Warren


From drwho8 at worldnet.att.net  Tue Oct  1 08:17:01 2002
From: drwho8 at worldnet.att.net (Gregg C Levine)
Date: Mon, 30 Sep 2002 18:17:01 -0400
Subject: [TUHS] Re: [pups] Re: vaxstation
References: <200209302143.g8ULhRi12751@minnie.tuhs.org>
Message-ID: <000f01c268cf$2160b4a0$9d68580c@who>

Hello from Gregg C Levine
Warren?! How do I go about subscribing to the PUPS list? I was not aware
that you host both there, and only found out about just the one.
Gregg C Levine drwho8 at worldnet.att.net
"Oh my!" The Second Doctor's nearly favorite phrase.
----- Original Message -----
From: "Warren Toomey" <wkt at minnie.tuhs.org>
To: "Richard Snow" <rsnow1 at charter.net>
Cc: "PDP-11 Unix Preservation Society" <pups at tuhs.org>; "The Unix Heritage
Society" <tuhs at tuhs.org>
Sent: Monday, September 30, 2002 5:43 PM
Subject: [TUHS] Re: [pups] Re: vaxstation


> In article by Richard Snow:
> > I may be getting a Vaxstation soon.  I don't think is one of
> > the ones supported by Linux yet.
> > Richard Snow
>
> Richard, in that case you might prefer to switch to the TUHS mailing list:
> http://minnie.tuhs.org/mailman/listinfo/tuhs
>
> PUPS is mainly for PDP-11s, TUHS is for other old boxen that run Unix.
>
> Mind you, a lot of people are subscribed to both!
>
> Warren
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> http://minnie.tuhs.org/mailman/listinfo/tuhs
>



From wkt at minnie.tuhs.org  Tue Oct  1 09:39:04 2002
From: wkt at minnie.tuhs.org (Warren Toomey)
Date: Tue, 1 Oct 2002 09:39:04 +1000 (EST)
Subject: [TUHS] Re: Making boot disks (fwd)
Message-ID: <200209302339.g8UNd4B13794@minnie.tuhs.org>

----- Forwarded message from Ian Molton -----

>From spyro at f2s.com Tue Oct  1 09:02:24 2002
Date: Tue, 1 Oct 2002 00:15:35 +0100
From: Ian Molton <spyro at f2s.com>
To: wkt at tuhs.org
Subject: Re: Making boot disks

On Tue, 1 Oct 2002 07:37:35 +1000 (EST)
Warren Toomey <wkt at minnie.tuhs.org> wrote:

> I'll pass this to the mailing list to see if others can help you.
> I'd say that Linux is unlikely to construct the correct filesystem
> type. There are severl UFS variants, and you'd need to know the exact
> layout details to be sure that Linux (or something else) could create
> the boot disks.

Thanks.

I found some ufs code in the HURD source, and VERY crudely hacked it. It
creates filesystems that linux can mount, but it crashed trying to write
big files to it (doh!)

any advice from the list would be appreciated :)

----- End of forwarded message from Ian Molton -----


From grog at lemis.com  Tue Oct  1 09:59:02 2002
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Tue, 1 Oct 2002 09:29:02 +0930
Subject: [TUHS] Re: Making boot disks
In-Reply-To: <200209302339.g8UNd4B13794@minnie.tuhs.org> <200209302137.g8ULbZH12674@minnie.tuhs.org>
References: <200209302339.g8UNd4B13794@minnie.tuhs.org> <20020930214211.5d53a9a0.spyro@f2s.com> <200209302137.g8ULbZH12674@minnie.tuhs.org>
Message-ID: <20020930235902.GP22839@wantadilla.lemis.com>

On Tuesday,  1 October 2002 at  7:37:35 +1000, Warren Toomey wrote:
> In article by Ian Molton:
>> Hi.
>>
>> Dunno if you can help me ont this...
>>
>> I have an unusual UNIX derived OS called RISCiX, but I cant install it
>> because I have no bootdisks.
>>
>> I /do/ have scripts to make them, and the kernel + OS files, though.
>>
>> I think the filesystem was UFS.
>>
>> I can use my Linux box to create a filesystem, but I dont have a copy of
>> the right utility (newfs?).
>>
>> Can you point me to source?
>
> I'll pass this to the mailing list to see if others can help you.
> I'd say that Linux is unlikely to construct the correct filesystem type.
> There are severl UFS variants, and you'd need to know the exact layout
> details to be sure that Linux (or something else) could create the
> boot disks.

On Tuesday,  1 October 2002 at  9:39:04 +1000, Warren Toomey wrote:
>
> Thanks.
>
> I found some ufs code in the HURD source, and VERY crudely hacked it. It
> creates filesystems that linux can mount, but it crashed trying to write
> big files to it (doh!)

Well, it would be nice to know what you're really trying to do.
What's the hardware?  If the file system is UFS, it's unlikely to be a
good fit for Linux.  I'd say "try FreeBSD", but without knowing more
about your software and hardware, it's not clear if that would be any
better.  Google suggests that it runs on ARMs.  Is that correct?

> any advice from the list would be appreciated :)

In that case you should copy us.

Greg
--
Finger grog at lemis.com for PGP public key
See complete headers for address and phone numbers


From spyro at f2s.com  Tue Oct  1 10:37:54 2002
From: spyro at f2s.com (Ian Molton)
Date: Tue, 1 Oct 2002 01:37:54 +0100
Subject: [TUHS] Re: Making boot disks
In-Reply-To: <20020930235902.GP22839@wantadilla.lemis.com>
References: <200209302339.g8UNd4B13794@minnie.tuhs.org>
	<20020930214211.5d53a9a0.spyro@f2s.com>
	<200209302137.g8ULbZH12674@minnie.tuhs.org>
	<20020930235902.GP22839@wantadilla.lemis.com>
Message-ID: <20021001013754.4d51c7ef.spyro@f2s.com>

On Tue, 1 Oct 2002 09:29:02 +0930
"Greg 'groggy' Lehey" <grog at lemis.com> wrote:

> Well, it would be nice to know what you're really trying to do.
> What's the hardware?  If the file system is UFS, it's unlikely to be a
> good fit for Linux.  I'd say "try FreeBSD", but without knowing more
> about your software and hardware, it's not clear if that would be any
> better.  Google suggests that it runs on ARMs.  Is that correct?

The hardware is an obscure british platform from back when the ARM was
young. - The Archimedes.

The CPU is the ARM2 or 3 (either work) and the systems have SCSI,
ethernet, and (up to) 16Mb of RAM.

I dont actually know what the filesystem is, but my guess is UFS based
on the newfs command in the mkkernel script, and a rumour it is BSD
derived.

I have everything from a machines filesystem in a tarball.

I simply have no bootdisk, and cant create one without a suitable newfs
 
> > any advice from the list would be appreciated :)
> 
> In that case you should copy us.

Done. whats the subscribe address, btw?

Well, heres the mkkernel and other scripts (attached).

is it possible for someone else to make a filesystem image for me that I
could dd onto a floppy? I suspect that this system uses an old variant
of ufs.

the system is little-endian, if that helps?

I just had an evil thought...

one way to get this system up would be to finish my port of ARMlinux to
the Archimedes (naerly done but lots to do still). then write a RISCiX
personality and run RISCiX newfs on armlinux ;-)

No. too evil. I think best to try easier methods first ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mkkernel
Type: application/octet-stream
Size: 1491 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20021001/32100959/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mkfloppies
Type: application/octet-stream
Size: 1762 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20021001/32100959/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mksystem
Type: application/octet-stream
Size: 8996 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20021001/32100959/attachment-0002.obj>

From pete at dunnington.u-net.com  Tue Oct  1 16:29:56 2002
From: pete at dunnington.u-net.com (Pete Turnbull)
Date: Tue, 1 Oct 2002 06:29:56 GMT
Subject: [TUHS] Re: Making boot disks
In-Reply-To: Ian Molton <spyro@f2s.com>
        "Re: [TUHS] Re: Making boot disks" (Oct  1,  1:37)
References: <200209302339.g8UNd4B13794@minnie.tuhs.org> 
	<20020930214211.5d53a9a0.spyro@f2s.com> 
	<200209302137.g8ULbZH12674@minnie.tuhs.org> 
	<20020930235902.GP22839@wantadilla.lemis.com> 
	<20021001013754.4d51c7ef.spyro@f2s.com>
Message-ID: <10210010729.ZM21799@mindy.dunnington.u-net.com>

On Oct 1,  1:37, Ian Molton wrote:
>
> On Tue, 1 Oct 2002 09:29:02 +0930
> "Greg 'groggy' Lehey" <grog at lemis.com> wrote:
>
> > Well, it would be nice to know what you're really trying to do.
> > What's the hardware?  If the file system is UFS, it's unlikely to be a
> > good fit for Linux.  I'd say "try FreeBSD", but without knowing more
> > about your software and hardware, it's not clear if that would be any
> > better.  Google suggests that it runs on ARMs.  Is that correct?
>
> The hardware is an obscure british platform from back when the ARM was
> young. - The Archimedes.
>
> The CPU is the ARM2 or 3 (either work) and the systems have SCSI,
> ethernet, and (up to) 16Mb of RAM.
>
> I dont actually know what the filesystem is, but my guess is UFS based
> on the newfs command in the mkkernel script, and a rumour it is BSD
> derived.

It is indeed a straight port of BSD 4.x, where x depends in whether is it's
RISC iX 1 or 1.2 (R440 used 4.2, I think; R260 used 4.3).

> I have everything from a machines filesystem in a tarball.
>
> I simply have no bootdisk, and cant create one without a suitable newfs
>
> > > any advice from the list would be appreciated :)

Take a look at James Carter's page at
http://www.jfc.org.uk/documents/riscix_clone.html

James and I worked this out when we rescued half-a-dozen R260's in various
states of disrepair and with various not-quite-complete copies of RISC iX.

> is it possible for someone else to make a filesystem image for me that I
> could dd onto a floppy? I suspect that this system uses an old variant
> of ufs.

It is a standard 4.3 filesystem (at least for the verison for an R260).  It
even says so when it boots:

RISC iX Release 1.2
ARM3 processor, cache enabled
...
...
Root fstype 4.3, name /dev/sd0a
Swap fstype spec, name /dev/sd0S
...


One of us could copy some stuff for you.  I'm not sure you'd be able to get
what you need onto a single floppy, though.  That's not how Acorn did it.

We'd certainly be willing to help, especially if you have any RISC iX stuff
we're missing.

-- 
Pete						Peter Turnbull
						Network Manager
						University of York


From cpg at aladdin.de  Tue Oct  1 18:01:52 2002
From: cpg at aladdin.de (Christian Groessler)
Date: Tue, 1 Oct 2002 10:01:52 +0200
Subject: [TUHS] Re: Making boot disks
Message-ID: <200210010801.KAA03292@panther.aladdin.de>

On 10/01/2002 01:37:54 AM CET Ian Molton wrote:
>
>On Tue, 1 Oct 2002 09:29:02 +0930
>"Greg 'groggy' Lehey" <grog at lemis.com> wrote:
>
>> Well, it would be nice to know what you're really trying to do.
>> What's the hardware?  If the file system is UFS, it's unlikely to be a
>> good fit for Linux.  I'd say "try FreeBSD", but without knowing more
>> about your software and hardware, it's not clear if that would be any
>> better.  Google suggests that it runs on ARMs.  Is that correct?
>
>The hardware is an obscure british platform from back when the ARM was
>young. - The Archimedes.
>
>The CPU is the ARM2 or 3 (either work) and the systems have SCSI,
>ethernet, and (up to) 16Mb of RAM.

I think NetBSD supports these machines. See

http://www.netbsd.org/Ports/acorn26/

regards,
chris



From spyro at f2s.com  Tue Oct  1 19:04:48 2002
From: spyro at f2s.com (Ian Molton)
Date: Tue, 1 Oct 2002 10:04:48 +0100
Subject: [TUHS] Re: Making boot disks
In-Reply-To: <200210010801.KAA03292@panther.aladdin.de>
References: <200210010801.KAA03292@panther.aladdin.de>
Message-ID: <20021001100448.2428d625.spyro@f2s.com>

On Tue, 1 Oct 2002 10:01:52 +0200
Christian Groessler <cpg at aladdin.de> wrote:

> 
> I think NetBSD supports these machines. See
> 
> http://www.netbsd.org/Ports/acorn26/

Indeed it does, and ARMlinux will too, soon - Im porting linux 2.5.30 to
the ARM26.


From jkunz at maja.unixag-kl.fh-kl.de  Tue Oct  1 19:07:54 2002
From: jkunz at maja.unixag-kl.fh-kl.de (Jochen Kunz)
Date: Tue, 1 Oct 2002 11:07:54 +0200
Subject: [TUHS] Re: [pups] Re: vaxstation
In-Reply-To: <200209302143.g8ULhRi12751@minnie.tuhs.org>
References: <3D98BA5A.8010509@charter.net> <200209302143.g8ULhRi12751@minnie.tuhs.org>
Message-ID: <20021001090754.GA26405@unixag-kl.fh-kl.de>

On Tue, Oct 01, 2002 at 07:43:27AM +1000, Warren Toomey wrote:

> > I may be getting a Vaxstation soon.  I don't think is one of 
> > the ones supported by Linux yet.  
> > Richard Snow
> PUPS is mainly for PDP-11s, TUHS is for other old boxen that run Unix.
AFAIK the only "old" unix that runs on a VAXstation is Ultrix. 
None of the CSRG BSD releases runs on (non-QBus) VAXstations.
If you want a "new" Unix on your VAXstation, go with NetBSD:
http://www.netbsd.org/Ports/vax/
(I think Linux will never run well on VAXen. OpenBSD/vax works, 
but still needs some improvement.) 

And don't forget: There is always the dark side of the force: VMS. ;-)
-- 



tsch��,
         Jochen

Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/



From spyro at f2s.com  Tue Oct  1 19:16:59 2002
From: spyro at f2s.com (Ian Molton)
Date: Tue, 1 Oct 2002 10:16:59 +0100
Subject: [TUHS] Re: Making boot disks
In-Reply-To: <10210010729.ZM21799@mindy.dunnington.u-net.com>
References: <200209302339.g8UNd4B13794@minnie.tuhs.org>
	<20020930214211.5d53a9a0.spyro@f2s.com>
	<200209302137.g8ULbZH12674@minnie.tuhs.org>
	<20020930235902.GP22839@wantadilla.lemis.com>
	<20021001013754.4d51c7ef.spyro@f2s.com>
	<10210010729.ZM21799@mindy.dunnington.u-net.com>
Message-ID: <20021001101659.0d0b1ae1.spyro@f2s.com>

On Tue, 1 Oct 2002 06:29:56 GMT
pete at dunnington.u-net.com (Pete Turnbull) wrote:

> > I dont actually know what the filesystem is, but my guess is UFS
> > based on the newfs command in the mkkernel script, and a rumour it
> > is BSD derived.
> 
> It is indeed a straight port of BSD 4.x, where x depends in whether is
> it's RISC iX 1 or 1.2 (R440 used 4.2, I think; R260 used 4.3).

was the only difference between 1 and 1.2 the kernel?

> > I have everything from a machines filesystem in a tarball.
> >
> > I simply have no bootdisk, and cant create one without a suitable
> > newfs
> >
> > > > any advice from the list would be appreciated :)
> 
> Take a look at James Carter's page at
> http://www.jfc.org.uk/documents/riscix_clone.html

wont I need a working installation first?

> > is it possible for someone else to make a filesystem image for me
> > that I could dd onto a floppy? I suspect that this system uses an
> > old variant of ufs.
> 
> It is a standard 4.3 filesystem (at least for the verison for an
> R260).  It even says so when it boots:

Thats good to know - linux can actually write to that (although attempts
so far have led to kernel panics!)

Do you know of generic source for mkfs ?
 
> One of us could copy some stuff for you.  I'm not sure you'd be able
> to get what you need onto a single floppy, though.  That's not how
> Acorn did it.

did you see the scripts I attached?

Apparently the create 3 floppies, which can be used to install a system.

> We'd certainly be willing to help, especially if you have any RISC iX
> stuff we're missing.

You're certainly welcome to any stuff I have.

Id be eternally grateful if you could run those 3 scripts on a riscix
machine though (even better if you could use a disc image - can risciX
do loopback mounted filesystems?)

once you have 3 floppies [which can be imaged], or 3 disc images, could
you email them to me?


From jkunz at maja.unixag-kl.fh-kl.de  Tue Oct  1 19:55:57 2002
From: jkunz at maja.unixag-kl.fh-kl.de (Jochen Kunz)
Date: Tue, 1 Oct 2002 11:55:57 +0200
Subject: [TUHS] Re: Making boot disks
In-Reply-To: <200210010801.KAA03292@panther.aladdin.de>
References: <200210010801.KAA03292@panther.aladdin.de>
Message-ID: <20021001095557.GA26576@unixag-kl.fh-kl.de>

On Tue, Oct 01, 2002 at 10:01:52AM +0200, Christian Groessler wrote:

> I think NetBSD supports these machines. See
> http://www.netbsd.org/Ports/acorn26/
I used NetBSD to create and manipulate on disk file systems as well as 
disk images (see vnconfig(8)) for 4.3BSD-Tahoe (VAX) and 4.4BSD (HP300). 
AFAIK there are some minor differences in the FS layout, but it was 
similar enough to get the old BSD up to the point where I colud iron 
out this differences with fsck. 
-- 



tsch��,
         Jochen

Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/



From pete at dunnington.u-net.com  Wed Oct  2 17:20:15 2002
From: pete at dunnington.u-net.com (Pete Turnbull)
Date: Wed, 2 Oct 2002 07:20:15 GMT
Subject: [TUHS] Re: Making boot disks
In-Reply-To: Ian Molton <spyro@f2s.com>
        "Re: [TUHS] Re: Making boot disks" (Oct  1, 10:16)
References: <200209302339.g8UNd4B13794@minnie.tuhs.org> 
	<20020930214211.5d53a9a0.spyro@f2s.com> 
	<200209302137.g8ULbZH12674@minnie.tuhs.org> 
	<20020930235902.GP22839@wantadilla.lemis.com> 
	<20021001013754.4d51c7ef.spyro@f2s.com> 
	<10210010729.ZM21799@mindy.dunnington.u-net.com> 
	<20021001101659.0d0b1ae1.spyro@f2s.com>
Message-ID: <10210020820.ZM22561@mindy.dunnington.u-net.com>

On Oct 1, 10:16, Ian Molton wrote:
> On Tue, 1 Oct 2002 06:29:56 GMT
> pete at dunnington.u-net.com (Pete Turnbull) wrote:

> > It is indeed a straight port of BSD 4.x, where x depends in whether is
> > it's RISC iX 1 or 1.2 (R440 used 4.2, I think; R260 used 4.3).
>
> was the only difference between 1 and 1.2 the kernel?

I think other things were updated as well, in line with differenet versions
of BSD, but I don't have any sort of definitive list.

> > Take a look at James Carter's page at
> > http://www.jfc.org.uk/documents/riscix_clone.html
>
> wont I need a working installation first?

To clone a disk, yes, you need to start with a good disk :-)

> > > is it possible for someone else to make a filesystem image for me
> > > that I could dd onto a floppy? I suspect that this system uses an
> > > old variant of ufs.
> >
> > It is a standard 4.3 filesystem (at least for the verison for an
> > R260).  It even says so when it boots:
>
> Thats good to know - linux can actually write to that (although attempts
> so far have led to kernel panics!)
>
> Do you know of generic source for mkfs ?

Linux source, especially early versions, or a full BSD 4.x distribution, eg
from the PUPS archive?

> > One of us could copy some stuff for you.  I'm not sure you'd be able
> > to get what you need onto a single floppy, though.  That's not how
> > Acorn did it.
>
> did you see the scripts I attached?
>
> Apparently the create 3 floppies, which can be used to install a system.

I've looked at the scripts (sorry, didn't have time yesterday).  They're
not Acorn's.  They were created by Granada Microcare's Field Service
division when they had to upgrade R140 versions of RISC iX -- 1.13 was a
bugfix release.

They should work, providing the versions of the kernel and other files in
my version will fit on a floppy.  I'm not sure how best to get your tar
file back though; it doesn't look like the minimal system has NFS support.
 You ought be able to do it if you had a spare hard drive, put the tar file
on it, and mount it under /mnt.  Modify the tar command in cpsys so it
doesn't overwrite /mnt, like James and I did.

dsplit is just a utility (written by Acorn?) to split a big file over
several floppies, or extract it again (like bsplit, but probably with
different markers).

> can risciX do loopback mounted filesystems?)

No.  That's a linux invention.  But I can probably create the floppies for
you, when I have time to move my R260 to somewhere I can use it -- probably
not this weekend, maybe the weekend after.

What machine have you got?  R140, R260, or something else?  Is it the same
type as the filesystem you copied came from?

-- 
Pete						Peter Turnbull
						Network Manager
						University of York


From Robertdkeys at aol.com  Fri Oct  4 14:00:31 2002
From: Robertdkeys at aol.com (Robertdkeys at aol.com)
Date: Fri, 4 Oct 2002 00:00:31 EDT
Subject: [TUHS] Interdata 3220 backup tape found... worth recovering for archives?
Message-ID: <19c.9e2d881.2ace6c5f@aol.com>

I chanced upon some old V7 stuff today, from a
researcher at the Duke University Medical Center
that did not have the heart to just throw them
out.  There was a complete manual set for V7 from
a Perkin-Elmer NMR machine dating from 1984, and
a backup tape of the system (9 track Scotch 700
series 6250bpi) dated 12/17/80.  The machine was
apparently an Interdata 3220 (Perkin-Elmer was
supposed to have bought out Interdata).

The manuals will make for fun reading, but there
may be some worthwhile bits if the tape is OK.
Anyway, I am seriously thinking of trying to
read the contents of the tape, and pass them on
to Warren, for the archives, if he thinks that
is something to do.

As to reading the tape, with the highest chance
for successful recovery, what would the list
folks recommend.  I was thinking of just doing
a retension on the tape to wind it off the reel
and prevent sticking, and then maybe use the
copytape ditty that has been floating around the
net since time began, which should list file
sizes, block sizes, file types, etc., while
reading the files to disk.

I can roll the tape on a VAX or a Sparc system
using a Cipher M995S deck.

Any suggestions from the list?

Thanks

Bob Keys
robertdkeys at aol.com


From drwho8 at worldnet.att.net  Tue Oct  8 07:39:34 2002
From: drwho8 at worldnet.att.net (Gregg C Levine)
Date: Mon, 7 Oct 2002 17:39:34 -0400
Subject: [TUHS] E11 later versions and available boot images
Message-ID: <001901c26e4a$09b6b7c0$965b580c@who>

Hello from Gregg C Levine
Has anyone tried out the boot images, in that directory on E11 ver 3.1? It
happens that I can get it to work, under Bochs, that is, I can run E11,
there. I haven't as yet, tried any of the boot images, myself. Right now I'm
downloading the ones that I am interested in.
Gregg C Levine drwho8 at worldnet.att.net
"Oh my!" The Second Doctor's nearly favorite phrase.



From drwho8 at worldnet.att.net  Thu Oct 10 15:23:30 2002
From: drwho8 at worldnet.att.net (Gregg C Levine)
Date: Thu, 10 Oct 2002 01:23:30 -0400
Subject: [TUHS] Can someone advise me regarding a gui for UNIX
Message-ID: <002d01c2701d$34746140$6260580c@who>

Hello from Gregg C Levine
Cross posted to both TUH, and PUPS lists, apologies to all.
Can someone advise me regarding when the GUIs became a standard feature on
UNIX? Or operating systems whose ancestry was indeed UNIX? I know that with
Linux, for example started carrying one, about the same time the kernel
became capable of supporting it. Or at least that's my opinion. With regard
to the materials we discuss here, well, that's what I am attempting to
ascertain.
Gregg C Levine drwho8 at worldnet.att.net
"Oh my!" The Second Doctor's nearly favorite phrase.



From grog at lemis.com  Thu Oct 10 16:25:05 2002
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Thu, 10 Oct 2002 15:55:05 +0930
Subject: [TUHS] Can someone advise me regarding a gui for UNIX
In-Reply-To: <002d01c2701d$34746140$6260580c@who>
References: <002d01c2701d$34746140$6260580c@who>
Message-ID: <20021010062505.GL87617@wantadilla.lemis.com>

On Thursday, 10 October 2002 at  1:23:30 -0400, Gregg C Levine wrote:
> Hello from Gregg C Levine
> Cross posted to both TUH, and PUPS lists, apologies to all.
> Can someone advise me regarding when the GUIs became a standard feature on
> UNIX?

Well, there are three variables.  GUI, standard and UNIX.

> Or operating systems whose ancestry was indeed UNIX? I know that
> with Linux, for example started carrying one, about the same time
> the kernel became capable of supporting it. Or at least that's my
> opinion. With regard to the materials we discuss here, well, that's
> what I am attempting to ascertain.

If by "GUI" you mean a windowing system, and by "standard" you mean
generally available, then I'd say the late 80s.  I started using X11R3
on Interactive UNIX/386 in early 1990.  I'm sure I didn't count as an
"early adopter".

Greg
--
Finger grog at lemis.com for PGP public key
See complete headers for address and phone numbers


From imp at bsdimp.com  Thu Oct 10 16:54:39 2002
From: imp at bsdimp.com (M. Warner Losh)
Date: Thu, 10 Oct 2002 00:54:39 -0600 (MDT)
Subject: [TUHS] Can someone advise me regarding a gui for UNIX
In-Reply-To: <20021010062505.GL87617@wantadilla.lemis.com>
References: <002d01c2701d$34746140$6260580c@who>
	<20021010062505.GL87617@wantadilla.lemis.com>
Message-ID: <20021010.005439.54141511.imp@bsdimp.com>

In message: <20021010062505.GL87617 at wantadilla.lemis.com>
            "Greg 'groggy' Lehey" <grog at lemis.com> writes:
: > Or operating systems whose ancestry was indeed UNIX? I know that
: > with Linux, for example started carrying one, about the same time
: > the kernel became capable of supporting it. Or at least that's my
: > opinion. With regard to the materials we discuss here, well, that's
: > what I am attempting to ascertain.
: 
: If by "GUI" you mean a windowing system, and by "standard" you mean
: generally available, then I'd say the late 80s.  I started using X11R3
: on Interactive UNIX/386 in early 1990.  I'm sure I didn't count as an
: "early adopter".

I was using X10R4 on a Sun3/50 in 1987 or so.  I more commonly used
sunview in a similar time frame.  Sunview/OpenWindows has been
standard on Sun machines since that time.  It was surprising snappy
for a 50MHz 68k machine, so long as you didn't swap, but I digress.
There were similar offerings from DEC and I think HP in approximately
the same time frame.

It depends on what you mean by GUI I guess :-)

Warner


From apgarcia at uwm.edu  Fri Oct 11 02:45:26 2002
From: apgarcia at uwm.edu (A.P.Garcia)
Date: Thu, 10 Oct 2002 16:45:26 +0000
Subject: [TUHS] Can someone advise me regarding a gui for UNIX
Message-ID: <20021010163843.C8A5283144@out0.mx.nwbl.wi.voyager.net>

> Can someone advise me regarding when the GUIs became a standard feature on
> UNIX?  Or operating systems whose ancestry was indeed UNIX?

MIT/LCS/TR-368, _The X Window System_, by Scheifler and Gettys, is dated
October 1986.  Here are a couple paragraphs from the introduction:

X is the result of the simultaneous need for a window system from two
separate groups at MIT.  In the summer of 1984, the Argus system [15]
at the Laboratory for Computer Science needed a debugging environment
for multi-process distributed applications, and a window system seemed
the only viable solution.  Project Athena [4] was faced with dozens,
and eventually thousands of workstations with bitmap displays, and
needed a window system to make the display useful.  Both groups were
starting with the Digital VS100 display [13] and VAX hardware, but it
was clear at the outset that other architectures and displays had to
be supported.  In particular, IBM workstations with bitmap displays of
unknown type were expected eventually within Project Athena.
Portability was therefore a goal from the start.  Although all of the
initial implementation work was for Berkeley Unix, it was clear that
the network protocol should not depend on aspects of the operating
system.

The name X derives from the lineage of the system.  At Stanford
University, Paul Asente and Brian Reid had begun work on the W window
system [3], as an alternative to VGTS [12, 21] for the V system [5].
Both VGTS and W allow network-transparent access to the display, using
the synchronous V communication mechanism.  Both systems provide "text"
windows for ASCII terminal emulation.  VGTS provides graphics windows
driven by fairly high-level object definitions from a structured display
file; W provides graphics windows based on a simple display-list
mechanism, with limited functionality.  We acquired a Unix-based version
of W for the VS100 (with synchronous communication over TCP [23]) done
by Asente and Chris Kent at Digital's Western Research Laboratory.  From
just a few days of experimentation, it was clear that a network-
transparent hierarchical window system was desirable, but that restricting
the system to any fixed set of application-specific modes was completely
inadequate.  It was also clear that, although synchronous communication
was perhaps acceptable in the V system (due to very fast networking
primitives), it was completely inadequate in most other operating
environments.  X is our "reaction" to W.  The X window hierarchy comes
directly from W, although numerous systems have been built with hierarchy
in at least some form [10, 14, 17, 27, 30, 31, 32, 33, 34, 35].  The
asynchronous communication protocol used in X is a significant improvement
over the synchronous protocol used in W, but is very similar to that used
in Andrew [9, 19].  X differs from all of these systems in the degree to
which both graphics functions and "system" functions are pushed back
(across the network) as application functions, and in the ability to
transparently tailor desktop management.



3. Asente. P. W Reference Manual. Stanford University, 1984. internal document.

4. Balkovich, E., Lerman, S., and Parmelee, R.  "Computing in Higher
Education: The Athena Experience". _Communications of the ACM 28_,
11 (Nov. 1985).

5. Cheriton, D. "The V Kernel: A Software Base for Distributed Systems".
_IEEE Software 1_, 2 (April 1984).

9. Gosling, J. and Rosenthal, D. A Window-Manager for Bitmapped Displays and
Unix. In _Methodology of Window-Managers_, F.R.A. Hopgood et al, Eds., 
Springer-Verlag, 1986.

10. Hawley, M. J., and Leffler, S. J. Windows for Unix at Lucasfilm.
Summer Conference Proceedings, Portland, USENIX Association, 1985.

12. Lantz, K.A. and Nowicki, W.I. "Structured Graphics for Distributed
Systems". _ACM Transactions on Graphics 3_, 1 (Jan. 1984).

13. Levy, H.  "VAXstation: A General-Purpose Raster Graphics Architecture".
_ACM Transactions on Graphics 3_, 1 (Jan. 1984).

14. Lipkie, D.E., Evans, S.R., Newlin, J.K., and Weissman, R.L. "Star Graphics:
An Object-Oriented Implementation."  _Computer Graphics 16_, 3 (July 1982).

15. Liskov, B. and Scheifler, R.  "Guardians and Actions: Linquistic
Support for Robust, Distributed Programs".  _ACM Transactions on
Programming Languages and Systems 5_, 3 (July 1983).

17. _Microsoft Windows: Programmer's Guide_.  Microsoft Corporation, 1985.

19. Morris, J., et atl. "Andrew: A Distributed Personal Computing Environment".
_Communications of the ACM 29_, 3 (March 1986).

21. Nowicki, W. _Partitioning of Function in a Distributed Graphics System_.
Ph.D. Th., Stanford University, Stanford, CA, 1985.

23. Postel, J. Transmission Control Protocol. RFC 793, USC/Information
Sciences Institute, Sept. 1981.

27. Stallman, R., Moon, D., and Weinreb, D.  Lisp Machine Window System
Manual.  MIT Artificial Intelligence Laboratory, Aug., 1983.

30. _Programmer's Reference Manual for SunWindows_.  Sun Microsystems, Inc.,
1985.

31. Sweet, R. "Mesa Programming Environment". _ACM SIGPLAN Notices 20_, 7
(July 1985).

32. Sweetman, D. A Modular Window System for Unix.  In _Methodology of
Window-Managers_, F.R.A. Hopgood et al, Eds., Springer-Verlag, 1986.

33. _Programming the User Interface_. Symbolics, Inc., 1986.

34. Teitelman, W. The Cedar Programming Environment: A Midterm Report and
Examination. CSL-83-11, Xerox PARC, June, 1984.

35. Trammel, R.D. A Capability Based Hierarchic Architecture for Unix Window
Management.  Summer Conference Proceedings, Portland, USENIX Association, 1985. 


two other references, not mentioned in the above text, that are worth noting:

11. _Information Processing: Graphical Kernel System (GKS) - Functional
Description_. DIS 7942, International Standards Organization, 1982.

22. Pike, R. "The Blit: A Multiplexed Graphics Terminal". _AT&T Bell
Laboratories Technical Journal 63_, 8 (Oct. 1984).



From apgarcia at uwm.edu  Fri Oct 11 11:52:08 2002
From: apgarcia at uwm.edu (A.P.Garcia)
Date: Fri, 11 Oct 2002 01:52:08 +0000
Subject: [TUHS] c coding standards
Message-ID: <20021011014529.B5019DAA9F@out6.mx.nwbl.wi.voyager.net>

check out this old post I found on Google Groups.
this kind of stuff makes me giddy.  :-)

-=-=-=-

Message-ID: <bnews.mit-vax.149>
Newsgroups: net.sources
X-Path: utzoo!decvax!harpo!eagle!mit-vax!mp
From: mit-vax!mp
Date: Tue Jun 29 08:07:31 1982
Subject: C coding standards
X-Google-Info: Converted from the original B-News header
Posted: Sun Jun 27 18:24:20 1982
Received: Tue Jun 29 08:07:31 1982


In my message in net.misc about coding standards, I offered to
send out the Stanford Network Graphics project's C style sheet.
Since almost everyone who responded to my query requested a copy
of that document, I decided to post it to the net.

In fact, thanks to JBrookshire at USC-ECLB, I now have 3 different C style
standards to give you.  Each is separated by a line of "*********"s.

	Mark Plotnick, MIT

************************************************

INGRES CODING CONVENTIONS FOR C/UNIX PROGRAMMING
University of California, Berkeley

	"The Ingres data base system encompasses about 75,000 lines of code 
in the programming language `C' and runs on top of the Unix operating system.
Over the past six years, Ingres has evolved into a functionally complete and
usable prototype.  Development required 25 to 30 programmer-years by a total 
of 19 people, and the systems is now in use at over 125 sites around the world."
		Allman, Eric.; and Stonebreaker, Michael "Observations on the
		  Evolution of a Software System." COMPUTER 15, 6 (June 1982),
		  27-32.

	The following represents the current C coding conventions that have
evolved from and during the development of the Ingres system.  This document
has been provided by Joe Kalash of Berkeley <INGVAX.kalash at Berkeley> in
response to a general enquiry distributed via Arpanet BBOARDS.

/*
**  CODE_CNVNTNS.C -- A Program to Display the INGRES Coding Style
**
**	This hunk of code does virtually nothing of use.  Its main
**	purpose is to demonstrate the "official" ingres coding style.
**
**	This demonstrates comments.  There should be a block comment
**	at the beginning of every file and/or procedure to explain
**	the function of the code.  Important information to put here
**	includes the parameters of the routines, any options that the
**	user may specify, etc.
**
**	The first line of the comment should be a one-line description
**	of what's going on.  The remainder should be more detailed.
**	Blank lines should seperate major points in the comments.  In
**	general, ask yourself the question, "If I didn't know what this
**	code was, what it was for, how it fit in, etc., and if I didn't
**	even have the documentation for it, would these comments be
**	enough for me?"
**
**	Some general guidelines for the code:
**
**	*****  GENERAL SYNTAX  *****
**
**	- Commas and semicolons should always be followed by a space.
**		Binary operators should be surrounded on both sides by
**		spaces.  Unary operators should be in direct contact
**		with the object that they act on, except for "sizeof",
**		which should be seperated by one space.
**
**	- Two statements should never go on the same line.  This includes
**		such things as an if and the associated conditionally
**		executed statement.
**		In cases such as this, the second half of the if
**		should be indented one tab stop more than the if.  For
**		example, use:
**			if (cond)
**				statement;
 
**		never:
**			if (cond) statement;
**		or:
**			if (cond)
**			statement;
**
**	- Braces ({}) should (almost) always be on a line by them-
**		selves.  Exceptions are closing a do, and terminating
**		a struct definition or variable initialization.  Braces
**		should start at the same indent as the statement with
**		which they bind, and code inside the braces should be
**		indented one stop further.  For example, use:
**			while (cond)
**			{
**				code
**			}
**		and never:
**			while (cond)
**				{
**				code
**				}
**		or:
**			while (cond) {
**				code
**			}
**		or:
**			while (cond)
**			{
**			code
**			}
**		or anything else in that line.  Braces which match
**		should always be at the same tab stop.
**
**	- Do statements must always be of the form:
**			do
**			{
**				code;
**			} while (cond);
**		even if "code" is only one line.  This is done so that
**		it is clear that the "while" is with a do, rather than
**		a standalone "while" which is used for the side effects of
**		evaluation of the condition.
**
**	- There should always be a space following a keyword (i.e.,
**		for, if, do, while, switch, and return), but never 
**		between a function and the paren preceeding its
**		arguments.  For example, use:
**			if (i == 0)
**				exit();
**		never:
**			if(i == 0)
**				exit ();
**
**	- Every case in a switch statement (including default) should
**		be preceeded by a blank line.  The actual word "case" or
**		"default" should have the indent of the switch statement plus
**		two spaces.  It should be followed by a space (not a
**		tab) and the case constant.  Multiple case labels on
**		a single block of code should be on seperate lines, but
 
**		they should not be seperated by blank lines.  The
**		switch statement should in general be used in place of
**		such constructs as:
                    if (i == 1)
**				code1;
**			else if (i == 34)
**				code2;
**			else if (i == -1643)
**				code3;
**		which can be more succinctly stated as:
**			switch (i)
**			{
**			  case 1:
**				code1;
**				break;
**
**			  case 34:
**				code2;
**				break;
**
**			  case -1643:
**				code3;
**				break;
**			}
**		In point of fact the equivalent switch will compile
**		extremely efficiently.  (Note that if you had some
**		instance where you could not use a case, e.g., checking
**		for i < 5, else check for j > 3, else whatever, then
**		the above ("if") code is in the correct style.  However,
**			if (i < 5)
**				code1;
**			else
**				if (j > 3)
**					code2;
**				else
**					code3;
**		is acceptable.
**
**	- A blank line should seperate the declarations and the code
**		in a procedure.  Blank lines should also be used freely
**		between major subsections of your code.  The major
**		subsections should also have a block comment giving
**		some idea of what is about to occur.
**
**	*****  PREPROCESSOR USAGE  *****
**
**	- Fields of #defines and #includes should line up.  Use:
**			# define	ARPA		25
**			# define	MAXFIELDS	18
**		and not:
**			#define ARPA 25
**			#define MAXFIELDS 18
**		Conditional compilation (#ifdef/#endif) should be used
**		around all trace information, timing code, and code
**		which may vary from version to version of UNIX.  See
**		the code below for an example of conditional compila-
**		tion use.
 
**
**	*****  VARIABLES AND DECLARATIONS  *****
**
**	- Defined constants (defined with the # define feature) must
**		be entirely upper case.  The exceptions to this are
**		compilation flags, which begin with a lower case "x",
**		and some sub-types for parser symbols.  In any case,
**		the majority of the symbol is upper case.
**
**	- Global variables should begin with an upper case letter and
**		be otherwise all lower case.  Local symbols should be
**		entirely lower case.  Procedure names are all lower
**		case.  The only exception to this is the trace routine
**		"tTf".  You should avoid user non-local symbols (globals
**		or # define'd symbols) which are one character only;
**		it is impossible to distinguish them.  Capitalization
**		may be used freely inside global names so long as they
**		are primarily lower case; for example, "ProcName" is
**		an acceptable name (and preferred over either Proc_name
**		or Procname).
**
**	- Use descriptive variable names, particularly for global var-
**		iables.  "IEH3462" tells me nothing; nor does "R".  On
**		the other hand, "Resultid" tells me quite a lot,
**		including what it might be, where I might go to see
**		how it is initialized, etc.  Try not to use variables
**		for multiple purposes.  Variable names like "i" are
**		acceptable for loop indices & temporary storage
**		provided that the value does not have long-term
**		semantic value.
**
**	- When the storage structure or type of a variable is
**		important, always state it explicitly.  In particular,
**		include "auto" if you are going to take the address
**		of something using the ampersand operator (so that
**		some wayward programmer doesn't change it to register),
**		and declare int parameters as int instead of letting
**		them default.
**
**	*****  GENERAL COMMENTS  *****
**
**	- It is quite possible to name a file "printr.c" and then
**		put the code for "destroydb" in it.  Try to arrange
**		the names of your files so that given the name of a
**		routine, it is fairly easy to figure out which file
**		it is in.
**
**	- Sometimes it is really pretty much impossible to avoid doing
**		something tricky.  In these cases, put in a comment
**		telling what you are doing and why you are doing it.
 
**	- Try to write things that are clear and safe, rather than
**		things which you think are easier to compile.  For
**		example, always declare temporary buffers as local,
**		rather than as global.  This way you can another
**		routine accidently when it still had useful info
**		in it.
**
**	*****  COMMENTS  *****
**
**	- The importance of comments cannot be overemphasised.
**		INGRES is primarily a research vehicle rather than
**		a program product.  This means that there will be
**		many people pouring over your code, trying to
**		understand what you have done & modify it to do
**		other things.  Try to make life easy for them &
**		maybe they will be nice to you someday.
**	
**	- Try to keep an idea of the flow of your program.  Put
**		block comments at the beginning of major segments,
**		and use one-line comments at less major junctures.
**		A person viewing your code at ten paces should be
**		able to tell where the major segments lay.
**
**	- The preferred format for block comments is to begin with
**		a line containing slash-star alone, followed by a
**		number of lines all beginning star-star containing
**		the comment, and terminating with a line containing
**		star-slash alone.  Comments without the double-star
**		at the beginning of each line should be avoided,
**		since it makes the comments seemingly disappear into
**		the body of the code.
**
**	- The beginning of each routine should have a comment block
**		in parametric form as demonstrated below.  The fields
**		"Parameters", "Returns", and "Side Effects" should
**		be considered mandatory.  Mark parameters as being
**		(IN), (IN/OUT), or (OUT) parameters, depending on
**		whether the parameter is used only to transmit infor-
**		mation into the routine, in and out of the routine,
**		or only to return information; the default is (IN).
**
**	Remember, it is easy to write totally incomprehensible code in
**	C, but we don't go in for that sort of thing.  It isn't too
**	much harder to write brilliantly clear code, and the code is
**	worth a lot more later.
**
**	For efficiency reasons, you should always use register variables
**	when possible.  A simple and extremely effective tip is to define
**	a register variable, and assign an oft-used parameter to it,
**	since it is particularly inefficient to reference a parameter.
**	Another particularly inefficient operation is referencing arrays
**	of structures.  When possible, define a register pointer to the
**	structure, and then say:
 
**		struct xyz structure[MAX];
**		register struct xyz *p;
**		...
**		for (i = 0; i < MAX; i++)
**		{
**			p = &structure[i];
**			p->x = p->y + p->z;
**			(diddle with p->???)
**		}
**	and not:
**		struct xyz structure[MAX];
**		...
**		for (i = 0; i < MAX; i++)
**		{
**			Structure[i].x = Structure[i].y + Structure[i].z;
**			(diddle with Structure[i].???)
**		}
**	Remember, the nice things about register variables is that they
**	make your code smaller and they run faster.  It is hard to
**	lose with registers.  There are three restrictions which you
**	should be aware of on register variables, however.  First,
**	The only types which may be registers are int's, char's,
**	and pointers.  Second, there may only be three register
**	variables per subroutine.  Third, you may not take the address
**	of a register variable (i.e., you may not say "&i" if i is
**	typed as a register variable).
**
**	Usage:
**		example [flags] argument
**
**	Positional Parameters:
**		argument -- this gets echoed to the standard
**			output.
**
**	Flags:
**		-n -- don't put a newline at the end.
**		-x -- don't do anything.
**		-b -- echo it with a bell character.
**
**	Return Codes:
**		0 -- successful
**		else -- failure
**
**	Defined Constants:
**		XEQ1 -- maximum number of simultaneous equijoins.
**
**	Compilation Flags:
**		xTRACE -- enable trace information
**
**	Trace Flags:
**		5 -- general debug
**		6 -- reserved for future use
 
**	Compilation Instructions:
**		cc -n example.c
**		mv a.out example
**		chmod 755 example
**
**	Notes:
**		These comments don't apply to the code at all,
**			since this is just an example program.
**		Also, it is wise to avoid this many comments
**			except at the head of main programs and
**			at the head of major modules.  For example,
**			this sort of commenting is appropriate at
**			the top of ingres.c (system startup) and
**			view.c (virtual view subsystem), but not
**			in small utility routines, e.g., length.c.
**			This sort of routine should be limited to
**			"Parameters:", "Returns:", "Side Effects:",
**			and anything else that seems relevant in
**			that context.
**		A fairly large comment block should exist at the
**			top of modules [files] which contain many
**			procedures; this block should clarify why
**			the procedures are grouped together, that
**			is, their common purpose in life.  A small
**			block should occur at the top of each
**			procedure explaining details of that proce-
**			dure.

**		Procedures should be on seperate pages (use the
**			form feed character, control-L).
**		A program will help you generate this comment block.
**			In ex, go to the line where you want to insert
**			a block and say "so /mnt/ingres/comment".  It
**			will ask you for a block type, e.g., "main"
**			for main program, "modfn" for a file which
**			contains only one function, "function" or
**			"procedure" for a procedure within a module,
**			"module" for a module header (e.g., as a
**			seperate comment block for a major module
**			[check .../qrymod/view.c for an example] or
**			in header files.
**		SCCS should be considered an essential tool, if only
**			to maintain history fields.
**
**	Deficiencies:
**		It should handle pseudo tty's.
*/

/* the following macro is defined by <sccs.h> */
SCCSID(%W%);	/* %W% is replaced by a version number by SCCS */
 
# define	XEQ1		5

struct magic
{
	char	*name;		/* name of symbol */
	int	type;		/* type of symbol, defined in symbol.h */
	int	value;		/* optional value.  This is actually
				 * the value if it is type "integer",
				 * a pointer to the value if it is a
				 * string. */
};

struct magic	Stuff;

main(argc, argv)
	int argc;
	char *argv[];
{
	register struct magic *r;
	register int i;
	register int j;
	int timebuf[2];
	auto int status;

	/*
	** Note that in the declarations of argc and argv above, all
	** parameters to any function should be declared, even if they
	** are of type int (which is the default).
	*/

	r = &Stuff;
	/* initialize random # generator */
	time(timebuf);
	srand(timebuf[1]);

	/* scan Stuff structure */
	for (i = 0; i < XEQ1; i++)
	{
#		ifdef xTRACE
		if (tTf(5, 13))
			printf("switch on type %d\n", r->reltype);
#		endif
 
		switch (r->type)
		{

		  case 0:
		  case 1:
		  case 3:
			/* initialize */
			printf("hi\n");
			break;
		  case 2:
			/* end of query */
			printf("bye\n");
			break;

		  default:
			/*
			** be sure to print plenty of info on an error;
			** "syserr("bad reltype");" would not have been
			** sufficient.  However, don't make syserr's
			** overly verbose; they take much space in the
			** object module, and it will probably be
			** necessary to look at the code anyway.
			*/
			syserr("main: bad type %d", r->type);

		}
	}

	/* resist the temptation to say "} else {" */
	if (i == 5)
	{
		i++;
		j = 4;
	}
	else
		i--;

	/* plot the results */
	do
	{
		i = rand() & 017;
		plot(i);
	} while (j--);

	/* wait for child processes to complete */
	wait(&status);
	/* end of run, print termination message and exit */
	for (i = 0; i < 2; i++)
		printf("bye ");
	printf("\n");
}
 
**  PLOT -- Plot a Bar-Graph
**
**	Does a simple plot on a terminal -- one line's worth.
**
**	Parameters:
**		n (IN) -- number of asterisks to plot
**
**	Returns:
**		none
**
**	Side Effects:
**		none
**
**	Deficiencies:
**		Should allow scaling.
*/

plot(n)
	int n;
{
	register int i;

	for (i = n; i-- > 0; )
	{
		printf("*");
	}
 printf("\n");
}
**************************************************************************
 

BBN PROGRAMMING STANDARDS FOR C

	The following document was provided by Dan Franklin <DAN at BBN=UNIX>
in response to a general enquiry distributed to Arpanet BBOARDS:



Here's a short set of guidelines that represents a combination
of the thoughts of two groups within BBN. I was its last editor.
Hope you find it useful. If you come across something more 
comprehensive (which this certainly isn't), I'd appreciate it
if you let me know.


		PROGRAMMING STANDARDS AND PRACTICES
		     FOR THE UNIX COST CENTER

This memo proposes a set of practices that might be followed in
the cost center, in order to have a consistently organized and
written, readable, understandable, and ultimately maintainable
software package.  Qualifying each of the items below is an (S)
or (P):  the former indicates that, once agreed-upon, the rule
must be adhered to rigorously and consistently--a Standard; the
latter items are more of the flavour of "good programming
Practice"--once agreed-upon, programmers should follow the
practice to the extent that common sense dictates. 

1. DOCUMENTATION OF ROUTINE INTERFACES

(S)  Every routine should be prefaced by a standard header
     which describes the routine and its interface precisely, so that
     the routine could be used by someone without reading the code.

The rationale for such a header is that it concentrates the critical document-
ation in one place, making it easy for someone (including the original
designer/coder) to use the routine correctly, and allows for the possibility
of automatically stripping off all headers to form an Internal Documentation
document.

In some cases a routine may do a small amount of processing and then
call another routine. (As an example, a routine may provide a 
"special case" interface to another more general routine with
a more cumbersome calling sequence.) In this case, a routine's header
may refer the reader to the header of another routine for further information.

The format suggested is illustrated below: comments are surrounded by
< > symbols. Any item that is irrelevant, e.g., no parameters,
no return value, no error conditions, may be omitted.
 

/*------------------------ E P R I N T -----------------------------------*/
/* <a brief description of the routine...also, put the routine name in
 * caps in the line above. The description should give, in general
 * terms, the routine's function, including an overall description of its
 * parameters, return values, and effect on global databases. It should also
 * describe any error conditions that may occur and be reflected to the
 * caller. The return value must be described precisely.>
 */
int eprint(estrucp, istart, ilength)
	struct estruct *estructp; /* Pointer to eprint's structure */
	int istart;               /* Place in structure to start from */
	int ilength;              /* # things in struct to print */
{

}

Note that each parameter gets its own declaration line, and has a
comment to convey its exact meaning. 

Each file in a program or subsystem consisting of multiple files
should start with some additional information, giving (essentially)
the justification for putting all these routines in one file.
That is, it should include a description of the common function
they all perform, the related functions they all perform, the database
they have in common and which is contained only in this file, etc.
In the last case, especially, a detailed description of the database
should be included; otherwise, since the database is not part of any
one routine, it will not get described in any other comment field.
The detailed description may require reading comments associated 
with the actual declarations in order to be complete.

This header should include a history list describing all modifications
to functions in this file. Each entry in the list should give the 
person, the date, the names of the functions (or database elements)
changed, and the reasons.

For the file containing the main routine of a program, the following
standards should be observed:

1. The main routine should be the first routine in the file.

2. Before the main routine should appear an overall comment field
describing the calling sequence in some detail. Generally, the
program will also be described in a manual page as well; this
comment field need not duplicate the entire contents of the
manual page, but it should include information about the overall
structure of the program which would be useful to a maintainer.

3. The main routine should exit by calling exit(0) explicitly.
All programs, however, must return an exit status of zero on success,
and nonzero on error.
 
2. FORMATTING

(S) All programs must be indented, at least 4 spaces per
indentation level.  Statements at the same nesting level should
be at the same indentation level; statements at deeper nesting
levels should be indented more. (For the purposes of this
standard, the keyword "else" is regarded as having the same
nesting level as the "if" it corresponds to.) For example, the
following indentation practices are not permitted:

	if (condition)
	statement-group;

	if (condition)
		statement-group; else
		statement-group;

	if (condition)
	for (init; test; step)
		statement-group;

	if (condition) statement-group; 
        else statement group;

(S) Nesting the trinary conditional operator (?:) is not permitted.

(P)  For internal formatting and indenting style, the following is recommended:

     . 4-space indentations at each level;
     . braces delineating blocks used in the style of    
        if (exp)
        {
	    code
	}
     or
        if (exp)
            {
	    code
	    }
     . a separate declaration statement for each pointer,
       due to the confusion that can arise when reading
       and modifying a declaration like
	   char *a, b, *c;
     . comments lined up systematically;
     . spaces between reserved words and their opening parentheses,
       e.g., if (condition) rather than if(condition);
     . no deep nesting (greater than 4 levels deep)
     . statement blocks less than 1 page long
     . one statement per line
     . parentheses around the objects of sizeof and return.

(P)  Concerning internal comments:

     . Full English sentences are recommended.
 
     . It is often clearer and more readable to make
       small blocks of comments as "paragraph headers" to a block of
       code than to comment every line or so, especially if the code
       is straightforward and untricky (which most of it should be,
       especially if the programmer is conscientious about variable
       naming and datatype compatibility).
     . Anything non-obvious should be well-commented.
(P)  Concerning white space and other aids to readability and debugging:
     . blank lines should be used between blocks of code that are
       functionally distinct

     . in expressions, operators should be surrounded by blanks
       (but not operators which compose primaries, specifically
       ".", "->")

     . in a function definition, the function name and its datatype
       should appear on one line. Examples:

int pread(...)

SOMESTRUCT * function(param1, param2)

       This latter practice aids readability and the comparison of
       the definition of a routine with its uses.

(P)  Other suggestions for improving readability:
     . Side effects within expressions should be used sparingly.
       It is recommended that no more than one operator with a side
       effect (=, op=, ++, --) appear within an expression. Function
       calls with side effects count as operators for this purpose.
     . In an "if-else" chain, the form
        if (condition)
            statement;
	else if (condition)
	    statement;
	else if (condition)
	    statement;
       should only be used when the conditions are all of the same basic
       form: e.g., testing the same variable against different values.
       If the conditions are qualitatively different, the additional
       "if" statements should start on new lines, indented, as in
	if (cond)
	    statement;
	else
	    if (cond2)
		statement;
	    else
                statement;
     . In the condition portion of an if, for, while, etc., side effects
       whose effect extends beyond the extent of the guarded statement
       block should be minimized. That is, in a block like
            if ((c = getc(file)) != EOF)
            {
                guarded-stmts
            }
            other-stmts
 
       it is natural to think of "c" being "bound" to a value only within
       the guarded-stmts; use of a variable set or modified in a condition,
       outside the range of the statements guarded by the condition, is
       quite distracting.
     . The use of || and && with right hand operands having side effects
       is discouraged. Also, whenever || and && are mixed in the same
       expression, parentheses should be used for clarity.

3. MODULARITY

3.1.  Routine Length

(P) Routines should be kept reasonably short. In general, a routine
    (or command) processes one or more inputs and generates one or
    more outputs, where each of the inputs and outputs can be concisely
    described. Usually a routine should only perform one function. Signs
    that a routine is too long, and ought to be split up, are: length
    greater than two pages; heavy use of "internal" variables (variables
    whose scope is less than the entire routine).

3.2.  Shared Data and Include Files

(S) Declarations of variables that are to be shared among several routines
    in a package should be placed at the beginning of the file containing
    the routines. If they are entirely internal to the package, they should
    be declared "static" to hide them from other files.

(S) Declarations of structures and global variables used for communications
    between a package and its callers should be placed in an appropriately
    named .h file. Shared global variables should be declared extern in the
    .h file so that if the package which sets/uses them is accidentally not
    loaded, a diagnostic will be issued by the loader.

(S) Definition and optional initialization of such globals should reside in
    one and only one file for each program. If a global is clearly associated
    with a specific package, it may be defined in the file for that package;
    otherwise, it should be placed in a file called data.c which is
    compiled and linked with the other routines when a program is
    being built.

(P) Use of globals should be minimized by judicious use of parameters.

Note that while static and extern designators in C both yield "common"
storage allocation, static allows the named variable to be known only
within the context in which it is declared;  thus, an identifier declared
static at the top of a file will only be known within the file.

In addition, local symbolic constants (#defines) may occur anywhere within
a routine, and may be placed below the #include directives if the writer
feels that this aids readability.
 
(S) Include files should contain all and only all of the following items
    necessary for a given program and shared among two or more of its files:
    . #defines
    . typedefs
    . extern declarations

(S) Include files may also contain nested #include directives.  However, this
    practice should be kept to a minimum. It is recommended that
    include files which may be embedded in this way contain a check
    to see whether they are being included twice, to avoid unnecessary
    preprocessor and compiler complaints when the user includes them
    both implicitly and explicitly. The simplest way to do this is to 
    check for a special hidden #define, as in

    #ifdef _INCLUDEFILENAME
    #define _INCLUDEFILENAME
    .
    .   Contents of include file
    .   
    #endif _INCLUDEFILENAME

3.3 Routine interfaces

(P) In general, a routine should be designed with a "natural",
    easily-remembered calling sequence. Routines with more than
    five arguments are not recommended. Routines with "op-code"
    arguments, where one argument determines the interpretation
    and functions of the others, are also not recommended (though
    they may prove useful as internal routines to a package,
    they should NOT be part of a package's documented interface).

4.  PORTABILITY

(P) Adherence to datatype compatibility should be practiced where
    reasonable. This can be facilitated by liberal use of C's typedef
    facility and explicit casting of types, as well as by the
    use of the union datatype.
   
(P) The following violation of strict adherence is permitted: a package
    which returns a pointer to a structure whose format need not be known
    outside that package may return a "generic" pointer, of type (char *).
    It is recommended that the typedef PTR be used for this purpose; this
    typedef will be provided in some standard system file. Note that char*
    is specifically chosen because the language guarantees that any pointer
    may be converted to a char* and back again without harm.

(S) Liberal use of #defines should eliminate "magic numbers", whether
    machine dependent or implementation dependent or arbitrary/random.
 
(S) To the extent that the conditional compilation facility of C allows, non-
    portable constructions can use this facility.  Failing this, machine or
    implementation dependent constructs should be visibly commented in the
    code. 

    When using conditional compilation for portability purposes, be sure
    to use appropriate parameters, rather than machine type, wherever 
    possible. For example, code which handles the C machine's 20 bit wordsize
    or 10 bit bytesize should use the parameter BYTESIZE in cpu.h rather
    than being ifdeffed on "mbb". 

(P) Up to six register variables can be declared (with some effect)
    on the C70 machine, but only three on the 11/70 (where additional ones
    are assigned regular automatic storage). Therefore, the first three
    register variables declared (in lexicographic order) should be ones
    for which the most gain can be gotten.

Note that register variables, judiciously chosen, can be very good space/time
savers, but the compiler is not overly smart about them, and can give you
irritating "expression overflow" messages.  In general, as with any
"optimization", it is wise to design, code and debug first, and then add in
register storage to one's declarations.

5.  NAMING

(P) Names should be chosen for their mnemonic nature.  Recall that although
    there is a limit on the number of initial characters of a name that must
    be distinct in C (and for a given machine), this does not prevent any
    name from being longer if such length will aid readability.

(S) It is a useful C convention to use upper-case for #defines and typedef
    names.

(S) One exception to the above is for parameterized #defines.
    These may be in lower-case.
**************************************************************************
 
	The following was provided via FTP by Keith A. Lantz at Stanford
	<CSL.LANTZ at SU-SCORE> via FTP following the enquiry distributed via
	Arpanet BBOARDS.

                                                      1
                        NETWORK GRAPHICS C STYLE SHEET 

                             Andrew Shore, et al.
                          Computer Systems Laboratory
                              Stanford University
                              Stanford, CA 94305

                                 18 June 1982

1. Names
  Don't use capital letters in file names (except for V !?).

  Avoid the underscore.

  Global  variables,  procedures, structs, unions, typedefs, defined constants,
and macros all begin with a  capital  letter,  and  are  logically  capitalized
thereafter  (e.g.  MainHashTable).   A global variable is one defined outside a
procedure, even though it may not be exported from the  file,  or  an  external
variable.    The  motivation for treating macros and constants this way is that
they may then be freely changed to procedure  calls  or  (global  or  external)
variables.

  Local variables begin with a lower-case letter, but are logically capitalized
thereafter  (e.g.  bltWidth, power, maxSumOfSquares).  Fields within structures
or unions are treated in this manner also.

2. Comments
  There are generally two types of comments: block-style comments, and  on-the-
line  comments.  Multi-line, block-style comments will follow the UNIX style of
/* and */ appearing on lines by themselves, and the body of  the  comment  will
start  with  a properly aligned *.  The comment should usually be surrounded by
blank lines as well.  The motivation for this is that it is easy to  add/delete
first  and  last lines, and it is easier to detect the common error of omitting
the */ and thus including all code up to and including the next */ in a comment
(Yapp helps with that too).

    /*
     * this is the first line of a multi-line comment,
     * this is another line
     * the last line of text
     */

On-line comments are used to detail declarations, and to explain  single  lines
of  code.  And,  I  suppose,  for brief (i.e. one line) block-style descriptive
comments.

               

  1
   This work was supported by the Defense  Advanced  Research  Projects  Agency
under contract number MDA903-80-C-0102.
                                        2


  Procedures  are preceded by block-style comments, explaining their (abstract)
function in terms of their parameters, results, and side effects.    Note  that
the parameter declarations are indented, not flushed left.

    /*
     * Unblock:
     *              unblock the process pd
     */

    Unblock( pd )
        register Process    pd;     /* the process to unblock */
      {
        register Process    *currPd,
                            *tmpPd;
        register unsigned   prio;

        prio = pd->priority;
        Disable;
        pd->state = Ready;

        /* Add pd to the ready queue */

        currPd = (Process *) &ReadyqHead;
        while ((tmpPd = currPd->link) != Null)
          {
            if (tmpPd->priority > prio)
                break;
            currPd = tmpPd;
          }
        pd->link = tempPd;
        currPd->link = pd;

        Enable;
      }

3. Indenting
  The  above example shows many of the indenting rules.  Braces ( "{" and "}" )
appear alone on a line, and are indented two spaces from the statement they are
to contain the body of, the body is indented two more spaces  from  the  braces
(for  a  total  of  four  spaces).    else's  and  else if's line up with their
dominating if statement (to avoid marching off to the right, and to reflect the
semantics of the statement).
                                        3


    if ((x = y) == 0)
      {
        flag = 1;
        printf (" the value was zero ");
      }
    else if (y == 1)
      {
        switch (today)
          {
            case Thursday:
                flag = 2;
                ThursdayAction();
                break;

            case Friday:
                flag = 3;
                FridayAction();
                break;

            default:
                OtherDayAction();
          }
      }
    else
        printf(" y had the wrong value ");

4. File Contents
  I think we agreed on the following order for file contents.

   1. initial descriptive comment (see example below) which contains:

         a. file  name,  with  indication  of the relative path to it when
            relevant

         b. brief descriptive abstract of contents

         c. a list of all defined procedures in their defined order

         d. list of authors

         e. list of current maintainers

         f. list  of   recent   and   major   modifications   in   reverse
            chronological order with indication (initials) of who made the
            change.

   2. included files (use relative path names whenever possible)

   3. external definitions (imports and exports)

   4. function declarations (externals and forward references)
                                        4


   5. constant declarations

   6. macro definitions

   7. type definitions

   8. global variable declarations

   9. procedure and function definitions

  Here is an example of the header comment:

    /*
     * FILE: libc/vkstuff/malloc.c
     *
     * CONTENTS:
     *      C storage allocator stolen and hacked up from UNIX for the SUN
     *      (NOTE: these were stolen and have the wrong naming conventions)
     *              malloc
     *              free
     *              realloc
     *              allock          DEBUG ONLY!
     *              SetBrk          ! our routine to fake up sbrk()
     *
     * AUTHORS: stolen and hacked by Andrew I. Shore (shore)
     *
     * MAINTAINER: shore
     *
     * HISTORY:
     * 03/05/82 AIS replaced calls to UNIX sbrk() with calls to own version
     *          SetBrk() for the sun/Vkernel
     */

5. Parenthesis ()
  We  seem  to have decided on the following conventions for parentheses.  When
parentheses enclose the  expression  for  a  statement  (if,  for,  etc.),  the
parentheses `belong to' the expression, so there is a space between the keyword
and  the  parenthesized expression.  For function calls the parentheses `belong
to' the call, so there is no space between function name and open paren  (there
may  some  inside  the  parentheses to make the expression list (argument list)
look nice).

    if (Mumble())
      {
        Grumble( (a = b) == 0 );
        return (Nil);
      }
    else
      {
        Fumble( a, b, c );
        return (ToSender);
      }
                                        5


It  is  unclear  what to do with return.  Note, then, that it is operators that
cause spaces on the outside of parentheses --  (a + b) * c.

6. General

   1. One statement/declaration per line.

   2. Make judicious use of blank lines.

         a. At least 3 blank lines between individual procedures.

         b. Blank lines surround "large" comments.

   3. Make sure comments and code agree!

   4. Don't just echo the code with comments -- make every comment  count!
      i.e. nix on:

          /* add foo to bar */
          bar += foo;
                                        i


                               Table of Contents
1. Names                                                                      1
2. Comments                                                                   1
3. Indenting                                                                  2
4. File Contents                                                              3
5. Parenthesis ()                                                             4
6. General                                                                    5
**************************************************************************
 

-------

Date: 27 Jun 1982 11:48:50-PDT
From: mo at LBL-UNIX (Mike O'Dell [system])
To: JSol at USC-ECLC
cc: Header-People at MIT-MC
Subject: Re: Unexplored Topic -- Length of Mail Message
In-reply-to: Your message of 25 Jun 1982 1715-PDT (Friday).

Yes indeed mail can be BIG!!  If you don't have FTP to some 
random system (again, not ARPAnet, most likely), but DO have
mail, you do a LOT with it, like abuse it into make-do FTP.
It is crass, but it beats not getting the bits there!
This can often be the case with site 2 networks away in
the internet (note small "i").

While this shouldn't impact ARPAnet sites too much, if 733 is
indeed something the larger world might look to for guidance,
I would advocate JSol's position: Mail is another form of
machine-machine communications, complete unto itself.

As an example, the "net.sources" news topic on USENET
routinely posts fixes and entire source listings of quite
complex programs; and this is on a network with 300 or 1200 baud
hop-by-hop links!!  I am not saying this is the ulitimate solution,
or that we should advocate such things, but it does indicate
the tremendous utility of Mail in reducing the isolation of 
sites.

	-Mike


Date: 27 Jun 1982 0929-PDT
From: JBROOKSHIRE at USC-ECLB
Subject: Re: C programming standards
To:   mp at MIT-MC

In response to your message sent  Saturday, 26 June 1982, 23:56-EDT

Thanks for the note - if you have any pointers it might help.  I have received
three pretty good sets of stuff that I am enclosing here if you are interested.
They are separated by lines of ******** which you can search on if you just 
want to read the sources of each.
Regards,
Jerry Brookshire

INGRES CODING CONVENTIONS FOR C/UNIX PROGRAMMING
University of California, Berkeley

	"The Ingres data base system encompasses about 75,000 lines of code 
in the programming language `C' and runs on top of the Unix operating system.
Over the past six years, Ingres has evolved into a functionally complete and
usable prototype.  Development required 25 to 30 programmer-years by a total 
of 19 people, and the systems is now in use at over 125 sites around the world."
		Allman, Eric.; and Stonebreaker, Michael "Observations on the
		  Evolution of a Software System." COMPUTER 15, 6 (June 1982),
		  27-32.

	The following represents the current C coding conventions that have
evolved from and during the development of the Ingres system.  This document
has been provided by Joe Kalash of Berkeley <INGVAX.kalash at Berkeley> in
response to a general enquiry distributed via Arpanet BBOARDS.

/*
**  CODE_CNVNTNS.C -- A Program to Display the INGRES Coding Style
**
**	This hunk of code does virtually nothing of use.  Its main
**	purpose is to demonstrate the "official" ingres coding style.
**
**	This demonstrates comments.  There should be a block comment
**	at the beginning of every file and/or procedure to explain
**	the function of the code.  Important information to put here
**	includes the parameters of the routines, any options that the
**	user may specify, etc.
**
**	The first line of the comment should be a one-line description
**	of what's going on.  The remainder should be more detailed.
**	Blank lines should seperate major points in the comments.  In
**	general, ask yourself the question, "If I didn't know what this
**	code was, what it was for, how it fit in, etc., and if I didn't
**	even have the documentation for it, would these comments be
**	enough for me?"
**
**	Some general guidelines for the code:
**
**	*****  GENERAL SYNTAX  *****
**
**	- Commas and semicolons should always be followed by a space.
**		Binary operators should be surrounded on both sides by
**		spaces.  Unary operators should be in direct contact
**		with the object that they act on, except for "sizeof",
**		which should be seperated by one space.
**
**	- Two statements should never go on the same line.  This includes
**		such things as an if and the associated conditionally
**		executed statement.
**		In cases such as this, the second half of the if
**		should be indented one tab stop more than the if.  For
**		example, use:
**			if (cond)
**				statement;
 
**		never:
**			if (cond) statement;
**		or:
**			if (cond)
**			statement;
**
**	- Braces ({}) should (almost) always be on a line by them-
**		selves.  Exceptions are closing a do, and terminating
**		a struct definition or variable initialization.  Braces
**		should start at the same indent as the statement with
**		which they bind, and code inside the braces should be
**		indented one stop further.  For example, use:
**			while (cond)
**			{
**				code
**			}
**		and never:
**			while (cond)
**				{
**				code
**				}
**		or:
**			while (cond) {
**				code
**			}
**		or:
**			while (cond)
**			{
**			code
**			}
**		or anything else in that line.  Braces which match
**		should always be at the same tab stop.
**
**	- Do statements must always be of the form:
**			do
**			{
**				code;
**			} while (cond);
**		even if "code" is only one line.  This is done so that
**		it is clear that the "while" is with a do, rather than
**		a standalone "while" which is used for the side effects of
**		evaluation of the condition.
**
**	- There should always be a space following a keyword (i.e.,
**		for, if, do, while, switch, and return), but never 
**		between a function and the paren preceeding its
**		arguments.  For example, use:
**			if (i == 0)
**				exit();
**		never:
**			if(i == 0)
**				exit ();
**
**	- Every case in a switch statement (including default) should
**		be preceeded by a blank line.  The actual word "case" or
**		"default" should have the indent of the switch statement plus
**		two spaces.  It should be followed by a space (not a
**		tab) and the case constant.  Multiple case labels on
**		a single block of code should be on seperate lines, but
 
**		they should not be seperated by blank lines.  The
**		switch statement should in general be used in place of
**		such constructs as:
                    if (i == 1)
**				code1;
**			else if (i == 34)
**				code2;
**			else if (i == -1643)
**				code3;
**		which can be more succinctly stated as:
**			switch (i)
**			{
**			  case 1:
**				code1;
**				break;
**
**			  case 34:
**				code2;
**				break;
**
**			  case -1643:
**				code3;
**				break;
**			}
**		In point of fact the equivalent switch will compile
**		extremely efficiently.  (Note that if you had some
**		instance where you could not use a case, e.g., checking
**		for i < 5, else check for j > 3, else whatever, then
**		the above ("if") code is in the correct style.  However,
**			if (i < 5)
**				code1;
**			else
**				if (j > 3)
**					code2;
**				else
**					code3;
**		is acceptable.
**
**	- A blank line should seperate the declarations and the code
**		in a procedure.  Blank lines should also be used freely
**		between major subsections of your code.  The major
**		subsections should also have a block comment giving
**		some idea of what is about to occur.
**
**	*****  PREPROCESSOR USAGE  *****
**
**	- Fields of #defines and #includes should line up.  Use:
**			# define	ARPA		25
**			# define	MAXFIELDS	18
**		and not:
**			#define ARPA 25
**			#define MAXFIELDS 18
**		Conditional compilation (#ifdef/#endif) should be used
**		around all trace information, timing code, and code
**		which may vary from version to version of UNIX.  See
**		the code below for an example of conditional compila-
**		tion use.
 
**
**	*****  VARIABLES AND DECLARATIONS  *****
**
**	- Defined constants (defined with the # define feature) must
**		be entirely upper case.  The exceptions to this are
**		compilation flags, which begin with a lower case "x",
**		and some sub-types for parser symbols.  In any case,
**		the majority of the symbol is upper case.
**
**	- Global variables should begin with an upper case letter and
**		be otherwise all lower case.  Local symbols should be
**		entirely lower case.  Procedure names are all lower
**		case.  The only exception to this is the trace routine
**		"tTf".  You should avoid user non-local symbols (globals
**		or # define'd symbols) which are one character only;
**		it is impossible to distinguish them.  Capitalization
**		may be used freely inside global names so long as they
**		are primarily lower case; for example, "ProcName" is
**		an acceptable name (and preferred over either Proc_name
**		or Procname).
**
**	- Use descriptive variable names, particularly for global var-
**		iables.  "IEH3462" tells me nothing; nor does "R".  On
**		the other hand, "Resultid" tells me quite a lot,
**		including what it might be, where I might go to see
**		how it is initialized, etc.  Try not to use variables
**		for multiple purposes.  Variable names like "i" are
**		acceptable for loop indices & temporary storage
**		provided that the value does not have long-term
**		semantic value.
**
**	- When the storage structure or type of a variable is
**		important, always state it explicitly.  In particular,
**		include "auto" if you are going to take the address
**		of something using the ampersand operator (so that
**		some wayward programmer doesn't change it to register),
**		and declare int parameters as int instead of letting
**		them default.
**
**	*****  GENERAL COMMENTS  *****
**
**	- It is quite possible to name a file "printr.c" and then
**		put the code for "destroydb" in it.  Try to arrange
**		the names of your files so that given the name of a
**		routine, it is fairly easy to figure out which file
**		it is in.
**
**	- Sometimes it is really pretty much impossible to avoid doing
**		something tricky.  In these cases, put in a comment
**		telling what you are doing and why you are doing it.
 
**	- Try to write things that are clear and safe, rather than
**		things which you think are easier to compile.  For
**		example, always declare temporary buffers as local,
**		rather than as global.  This way you can another
**		routine accidently when it still had useful info
**		in it.
**
**	*****  COMMENTS  *****
**
**	- The importance of comments cannot be overemphasised.
**		INGRES is primarily a research vehicle rather than
**		a program product.  This means that there will be
**		many people pouring over your code, trying to
**		understand what you have done & modify it to do
**		other things.  Try to make life easy for them &
**		maybe they will be nice to you someday.
**	
**	- Try to keep an idea of the flow of your program.  Put
**		block comments at the beginning of major segments,
**		and use one-line comments at less major junctures.
**		A person viewing your code at ten paces should be
**		able to tell where the major segments lay.
**
**	- The preferred format for block comments is to begin with
**		a line containing slash-star alone, followed by a
**		number of lines all beginning star-star containing
**		the comment, and terminating with a line containing
**		star-slash alone.  Comments without the double-star
**		at the beginning of each line should be avoided,
**		since it makes the comments seemingly disappear into
**		the body of the code.
**
**	- The beginning of each routine should have a comment block
**		in parametric form as demonstrated below.  The fields
**		"Parameters", "Returns", and "Side Effects" should
**		be considered mandatory.  Mark parameters as being
**		(IN), (IN/OUT), or (OUT) parameters, depending on
**		whether the parameter is used only to transmit infor-
**		mation into the routine, in and out of the routine,
**		or only to return information; the default is (IN).
**
**	Remember, it is easy to write totally incomprehensible code in
**	C, but we don't go in for that sort of thing.  It isn't too
**	much harder to write brilliantly clear code, and the code is
**	worth a lot more later.
**
**	For efficiency reasons, you should always use register variables
**	when possible.  A simple and extremely effective tip is to define
**	a register variable, and assign an oft-used parameter to it,
**	since it is particularly inefficient to reference a parameter.
**	Another particularly inefficient operation is referencing arrays
**	of structures.  When possible, define a register pointer to the
**	structure, and then say:
 
**		struct xyz structure[MAX];
**		register struct xyz *p;
**		...
**		for (i = 0; i < MAX; i++)
**		{
**			p = &structure[i];
**			p->x = p->y + p->z;
**			(diddle with p->???)
**		}
**	and not:
**		struct xyz structure[MAX];
**		...
**		for (i = 0; i < MAX; i++)
**		{
**			Structure[i].x = Structure[i].y + Structure[i].z;
**			(diddle with Structure[i].???)
**		}
**	Remember, the nice things about register variables is that they
**	make your code smaller and they run faster.  It is hard to
**	lose with registers.  There are three restrictions which you
**	should be aware of on register variables, however.  First,
**	The only types which may be registers are int's, char's,
**	and pointers.  Second, there may only be three register
**	variables per subroutine.  Third, you may not take the address
**	of a register variable (i.e., you may not say "&i" if i is
**	typed as a register variable).
**
**	Usage:
**		example [flags] argument
**
**	Positional Parameters:
**		argument -- this gets echoed to the standard
**			output.
**
**	Flags:
**		-n -- don't put a newline at the end.
**		-x -- don't do anything.
**		-b -- echo it with a bell character.
**
**	Return Codes:
**		0 -- successful
**		else -- failure
**
**	Defined Constants:
**		XEQ1 -- maximum number of simultaneous equijoins.
**
**	Compilation Flags:
**		xTRACE -- enable trace information
**
**	Trace Flags:
**		5 -- general debug
**		6 -- reserved for future use
 
**	Compilation Instructions:
**		cc -n example.c
**		mv a.out example
**		chmod 755 example
**
**	Notes:
**		These comments don't apply to the code at all,
**			since this is just an example program.
**		Also, it is wise to avoid this many comments
**			except at the head of main programs and
**			at the head of major modules.  For example,
**			this sort of commenting is appropriate at
**			the top of ingres.c (system startup) and
**			view.c (virtual view subsystem), but not
**			in small utility routines, e.g., length.c.
**			This sort of routine should be limited to
**			"Parameters:", "Returns:", "Side Effects:",
**			and anything else that seems relevant in
**			that context.
**		A fairly large comment block should exist at the
**			top of modules [files] which contain many
**			procedures; this block should clarify why
**			the procedures are grouped together, that
**			is, their common purpose in life.  A small
**			block should occur at the top of each
**			procedure explaining details of that proce-
**			dure.

**		Procedures should be on seperate pages (use the
**			form feed character, control-L).
**		A program will help you generate this comment block.
**			In ex, go to the line where you want to insert
**			a block and say "so /mnt/ingres/comment".  It
**			will ask you for a block type, e.g., "main"
**			for main program, "modfn" for a file which
**			contains only one function, "function" or
**			"procedure" for a procedure within a module,
**			"module" for a module header (e.g., as a
**			seperate comment block for a major module
**			[check .../qrymod/view.c for an example] or
**			in header files.
**		SCCS should be considered an essential tool, if only
**			to maintain history fields.
**
**	Deficiencies:
**		It should handle pseudo tty's.
*/

/* the following macro is defined by <sccs.h> */
SCCSID(%W%);	/* %W% is replaced by a version number by SCCS */
 
# define	XEQ1		5

struct magic
{
	char	*name;		/* name of symbol */
	int	type;		/* type of symbol, defined in symbol.h */
	int	value;		/* optional value.  This is actually
				 * the value if it is type "integer",
				 * a pointer to the value if it is a
				 * string. */
};

struct magic	Stuff;

main(argc, argv)
	int argc;
	char *argv[];
{
	register struct magic *r;
	register int i;
	register int j;
	int timebuf[2];
	auto int status;

	/*
	** Note that in the declarations of argc and argv above, all
	** parameters to any function should be declared, even if they
	** are of type int (which is the default).
	*/

	r = &Stuff;
	/* initialize random # generator */
	time(timebuf);
	srand(timebuf[1]);

	/* scan Stuff structure */
	for (i = 0; i < XEQ1; i++)
	{
#		ifdef xTRACE
		if (tTf(5, 13))
			printf("switch on type %d\n", r->reltype);
#		endif
 
		switch (r->type)
		{

		  case 0:
		  case 1:
		  case 3:
			/* initialize */
			printf("hi\n");
			break;
		  case 2:
			/* end of query */
			printf("bye\n");
			break;

		  default:
			/*
			** be sure to print plenty of info on an error;
			** "syserr("bad reltype");" would not have been
			** sufficient.  However, don't make syserr's
			** overly verbose; they take much space in the
			** object module, and it will probably be
			** necessary to look at the code anyway.
			*/
			syserr("main: bad type %d", r->type);

		}
	}

	/* resist the temptation to say "} else {" */
	if (i == 5)
	{
		i++;
		j = 4;
	}
	else
		i--;

	/* plot the results */
	do
	{
		i = rand() & 017;
		plot(i);
	} while (j--);

	/* wait for child processes to complete */
	wait(&status);
	/* end of run, print termination message and exit */
	for (i = 0; i < 2; i++)
		printf("bye ");
	printf("\n");
}
 
**  PLOT -- Plot a Bar-Graph
**
**	Does a simple plot on a terminal -- one line's worth.
**
**	Parameters:
**		n (IN) -- number of asterisks to plot
**
**	Returns:
**		none
**
**	Side Effects:
**		none
**
**	Deficiencies:
**		Should allow scaling.
*/

plot(n)
	int n;
{
	register int i;

	for (i = n; i-- > 0; )
	{
		printf("*");
	}
	printf("\n");
}
**************************************************************************
 

BBN PROGRAMMING STANDARDS FOR C

	The following document was provided by Dan Franklin <DAN at BBN=UNIX>
in response to a general enquiry distributed to Arpanet BBOARDS:



Here's a short set of guidelines that represents a combination
of the thoughts of two groups within BBN. I was its last editor.
Hope you find it useful. If you come across something more 
comprehensive (which this certainly isn't), I'd appreciate it
if you let me know.


		PROGRAMMING STANDARDS AND PRACTICES
		     FOR THE UNIX COST CENTER

This memo proposes a set of practices that might be followed in
the cost center, in order to have a consistently organized and
written, readable, understandable, and ultimately maintainable
software package.  Qualifying each of the items below is an (S)
or (P):  the former indicates that, once agreed-upon, the rule
must be adhered to rigorously and consistently--a Standard; the
latter items are more of the flavour of "good programming
Practice"--once agreed-upon, programmers should follow the
practice to the extent that common sense dictates. 

1. DOCUMENTATION OF ROUTINE INTERFACES

(S)  Every routine should be prefaced by a standard header
     which describes the routine and its interface precisely, so that
     the routine could be used by someone without reading the code.

The rationale for such a header is that it concentrates the critical document-
ation in one place, making it easy for someone (including the original
designer/coder) to use the routine correctly, and allows for the possibility
of automatically stripping off all headers to form an Internal Documentation
document.

In some cases a routine may do a small amount of processing and then
call another routine. (As an example, a routine may provide a 
"special case" interface to another more general routine with
a more cumbersome calling sequence.) In this case, a routine's header
may refer the reader to the header of another routine for further information.

The format suggested is illustrated below: comments are surrounded by
< > symbols. Any item that is irrelevant, e.g., no parameters,
no return value, no error conditions, may be omitted.
 

/*------------------------ E P R I N T -----------------------------------*/
/* <a brief description of the routine...also, put the routine name in
 * caps in the line above. The description should give, in general
 * terms, the routine's function, including an overall description of its
 * parameters, return values, and effect on global databases. It should also
 * describe any error conditions that may occur and be reflected to the
 * caller. The return value must be described precisely.>
 */
int eprint(estrucp, istart, ilength)
	struct estruct *estructp; /* Pointer to eprint's structure */
	int istart;               /* Place in structure to start from */
	int ilength;              /* # things in struct to print */
{

}

Note that each parameter gets its own declaration line, and has a
comment to convey its exact meaning. 

Each file in a program or subsystem consisting of multiple files
should start with some additional information, giving (essentially)
the justification for putting all these routines in one file.
That is, it should include a description of the common function
they all perform, the related functions they all perform, the database
they have in common and which is contained only in this file, etc.
In the last case, especially, a detailed description of the database
should be included; otherwise, since the database is not part of any
one routine, it will not get described in any other comment field.
The detailed description may require reading comments associated 
with the actual declarations in order to be complete.

This header should include a history list describing all modifications
to functions in this file. Each entry in the list should give the 
person, the date, the names of the functions (or database elements)
changed, and the reasons.

For the file containing the main routine of a program, the following
standards should be observed:

1. The main routine should be the first routine in the file.

2. Before the main routine should appear an overall comment field
describing the calling sequence in some detail. Generally, the
program will also be described in a manual page as well; this
comment field need not duplicate the entire contents of the
manual page, but it should include information about the overall
structure of the program which would be useful to a maintainer.

3. The main routine should exit by calling exit(0) explicitly.
All programs, however, must return an exit status of zero on success,
and nonzero on error.
 
2. FORMATTING

(S) All programs must be indented, at least 4 spaces per
indentation level.  Statements at the same nesting level should
be at the same indentation level; statements at deeper nesting
levels should be indented more. (For the purposes of this
standard, the keyword "else" is regarded as having the same
nesting level as the "if" it corresponds to.) For example, the
following indentation practices are not permitted:

	if (condition)
	statement-group;

	if (condition)
		statement-group; else
		statement-group;

	if (condition)
	for (init; test; step)
		statement-group;

	if (condition) statement-group; 
        else statement group;

(S) Nesting the trinary conditional operator (?:) is not permitted.

(P)  For internal formatting and indenting style, the following is recommended:

     . 4-space indentations at each level;
     . braces delineating blocks used in the style of    
        if (exp)
        {
	    code
	}
     or
        if (exp)
            {
	    code
	    }
     . a separate declaration statement for each pointer,
       due to the confusion that can arise when reading
       and modifying a declaration like
	   char *a, b, *c;
     . comments lined up systematically;
     . spaces between reserved words and their opening parentheses,
       e.g., if (condition) rather than if(condition);
     . no deep nesting (greater than 4 levels deep)
     . statement blocks less than 1 page long
     . one statement per line
     . parentheses around the objects of sizeof and return.

(P)  Concerning internal comments:

     . Full English sentences are recommended.
 
     . It is often clearer and more readable to make
       small blocks of comments as "paragraph headers" to a block of
       code than to comment every line or so, especially if the code
       is straightforward and untricky (which most of it should be,
       especially if the programmer is conscientious about variable
       naming and datatype compatibility).
     . Anything non-obvious should be well-commented.
(P)  Concerning white space and other aids to readability and debugging:
     . blank lines should be used between blocks of code that are
       functionally distinct

     . in expressions, operators should be surrounded by blanks
       (but not operators which compose primaries, specifically
       ".", "->")

     . in a function definition, the function name and its datatype
       should appear on one line. Examples:

int pread(...)

SOMESTRUCT * function(param1, param2)

       This latter practice aids readability and the comparison of
       the definition of a routine with its uses.

(P)  Other suggestions for improving readability:
     . Side effects within expressions should be used sparingly.
       It is recommended that no more than one operator with a side
       effect (=, op=, ++, --) appear within an expression. Function
       calls with side effects count as operators for this purpose.
     . In an "if-else" chain, the form
        if (condition)
            statement;
	else if (condition)
	    statement;
	else if (condition)
	    statement;
       should only be used when the conditions are all of the same basic
       form: e.g., testing the same variable against different values.
       If the conditions are qualitatively different, the additional
       "if" statements should start on new lines, indented, as in
	if (cond)
	    statement;
	else
	    if (cond2)
		statement;
	    else
                statement;
     . In the condition portion of an if, for, while, etc., side effects
       whose effect extends beyond the extent of the guarded statement
       block should be minimized. That is, in a block like
            if ((c = getc(file)) != EOF)
            {
                guarded-stmts
            }
            other-stmts
 
       it is natural to think of "c" being "bound" to a value only within
       the guarded-stmts; use of a variable set or modified in a condition,
       outside the range of the statements guarded by the condition, is
       quite distracting.
     . The use of || and && with right hand operands having side effects
       is discouraged. Also, whenever || and && are mixed in the same
       expression, parentheses should be used for clarity.

3. MODULARITY

3.1.  Routine Length

(P) Routines should be kept reasonably short. In general, a routine
    (or command) processes one or more inputs and generates one or
    more outputs, where each of the inputs and outputs can be concisely
    described. Usually a routine should only perform one function. Signs
    that a routine is too long, and ought to be split up, are: length
    greater than two pages; heavy use of "internal" variables (variables
    whose scope is less than the entire routine).

3.2.  Shared Data and Include Files

(S) Declarations of variables that are to be shared among several routines
    in a package should be placed at the beginning of the file containing
    the routines. If they are entirely internal to the package, they should
    be declared "static" to hide them from other files.

(S) Declarations of structures and global variables used for communications
    between a package and its callers should be placed in an appropriately
    named .h file. Shared global variables should be declared extern in the
    .h file so that if the package which sets/uses them is accidentally not
    loaded, a diagnostic will be issued by the loader.

(S) Definition and optional initialization of such globals should reside in
    one and only one file for each program. If a global is clearly associated
    with a specific package, it may be defined in the file for that package;
    otherwise, it should be placed in a file called data.c which is
    compiled and linked with the other routines when a program is
    being built.

(P) Use of globals should be minimized by judicious use of parameters.

Note that while static and extern designators in C both yield "common"
storage allocation, static allows the named variable to be known only
within the context in which it is declared;  thus, an identifier declared
static at the top of a file will only be known within the file.

In addition, local symbolic constants (#defines) may occur anywhere within
a routine, and may be placed below the #include directives if the writer
feels that this aids readability.
 
(S) Include files should contain all and only all of the following items
    necessary for a given program and shared among two or more of its files:
    . #defines
    . typedefs
    . extern declarations

(S) Include files may also contain nested #include directives.  However, this
    practice should be kept to a minimum. It is recommended that
    include files which may be embedded in this way contain a check
    to see whether they are being included twice, to avoid unnecessary
    preprocessor and compiler complaints when the user includes them
    both implicitly and explicitly. The simplest way to do this is to 
    check for a special hidden #define, as in

    #ifdef _INCLUDEFILENAME
    #define _INCLUDEFILENAME
    .
    .   Contents of include file
    .   
    #endif _INCLUDEFILENAME

3.3 Routine interfaces

(P) In general, a routine should be designed with a "natural",
    easily-remembered calling sequence. Routines with more than
    five arguments are not recommended. Routines with "op-code"
    arguments, where one argument determines the interpretation
    and functions of the others, are also not recommended (though
    they may prove useful as internal routines to a package,
    they should NOT be part of a package's documented interface).

4.  PORTABILITY

(P) Adherence to datatype compatibility should be practiced where
    reasonable. This can be facilitated by liberal use of C's typedef
    facility and explicit casting of types, as well as by the
    use of the union datatype.
   
(P) The following violation of strict adherence is permitted: a package
    which returns a pointer to a structure whose format need not be known
    outside that package may return a "generic" pointer, of type (char *).
    It is recommended that the typedef PTR be used for this purpose; this
    typedef will be provided in some standard system file. Note that char*
    is specifically chosen because the language guarantees that any pointer
    may be converted to a char* and back again without harm.

(S) Liberal use of #defines should eliminate "magic numbers", whether
    machine dependent or implementation dependent or arbitrary/random.
 
(S) To the extent that the conditional compilation facility of C allows, non-
    portable constructions can use this facility.  Failing this, machine or
    implementation dependent constructs should be visibly commented in the
    code. 

    When using conditional compilation for portability purposes, be sure
    to use appropriate parameters, rather than machine type, wherever 
    possible. For example, code which handles the C machine's 20 bit wordsize
    or 10 bit bytesize should use the parameter BYTESIZE in cpu.h rather
    than being ifdeffed on "mbb". 

(P) Up to six register variables can be declared (with some effect)
    on the C70 machine, but only three on the 11/70 (where additional ones
    are assigned regular automatic storage). Therefore, the first three
    register variables declared (in lexicographic order) should be ones
    for which the most gain can be gotten.

Note that register variables, judiciously chosen, can be very good space/time
savers, but the compiler is not overly smart about them, and can give you
irritating "expression overflow" messages.  In general, as with any
"optimization", it is wise to design, code and debug first, and then add in
register storage to one's declarations.

5.  NAMING

(P) Names should be chosen for their mnemonic nature.  Recall that although
    there is a limit on the number of initial characters of a name that must
    be distinct in C (and for a given machine), this does not prevent any
    name from being longer if such length will aid readability.

(S) It is a useful C convention to use upper-case for #defines and typedef
    names.

(S) One exception to the above is for parameterized #defines.
    These may be in lower-case.
**************************************************************************
 
	The following was provided via FTP by Keith A. Lantz at Stanford
	<CSL.LANTZ at SU-SCORE> via FTP following the enquiry distributed via
	Arpanet BBOARDS.

                                                      1
                        NETWORK GRAPHICS C STYLE SHEET 

                             Andrew Shore, et al.
                          Computer Systems Laboratory
                              Stanford University
                              Stanford, CA 94305

                                 18 June 1982

1. Names
  Don't use capital letters in file names (except for V !?).

  Avoid the underscore.

  Global  variables,  procedures, structs, unions, typedefs, defined constants,
and macros all begin with a  capital  letter,  and  are  logically  capitalized
thereafter  (e.g.  MainHashTable).   A global variable is one defined outside a
procedure, even though it may not be exported from the  file,  or  an  external
variable.    The  motivation for treating macros and constants this way is that
they may then be freely changed to procedure  calls  or  (global  or  external)
variables.

  Local variables begin with a lower-case letter, but are logically capitalized
thereafter  (e.g.  bltWidth, power, maxSumOfSquares).  Fields within structures
or unions are treated in this manner also.

2. Comments
  There are generally two types of comments: block-style comments, and  on-the-
line  comments.  Multi-line, block-style comments will follow the UNIX style of
/* and */ appearing on lines by themselves, and the body of  the  comment  will
start  with  a properly aligned *.  The comment should usually be surrounded by
blank lines as well.  The motivation for this is that it is easy to  add/delete
first  and  last lines, and it is easier to detect the common error of omitting
the */ and thus including all code up to and including the next */ in a comment
(Yapp helps with that too).

    /*
     * this is the first line of a multi-line comment,
     * this is another line
     * the last line of text
     */

On-line comments are used to detail declarations, and to explain  single  lines
of  code.  And,  I  suppose,  for brief (i.e. one line) block-style descriptive
comments.

               

  1
   This work was supported by the Defense  Advanced  Research  Projects  Agency
under contract number MDA903-80-C-0102.
                                        2


  Procedures  are preceded by block-style comments, explaining their (abstract)
function in terms of their parameters, results, and side effects.    Note  that
the parameter declarations are indented, not flushed left.

    /*
     * Unblock:
     *              unblock the process pd
     */

    Unblock( pd )
        register Process    pd;     /* the process to unblock */
      {
        register Process    *currPd,
                            *tmpPd;
        register unsigned   prio;

        prio = pd->priority;
        Disable;
        pd->state = Ready;

        /* Add pd to the ready queue */

        currPd = (Process *) &ReadyqHead;
        while ((tmpPd = currPd->link) != Null)
          {
            if (tmpPd->priority > prio)
                break;
            currPd = tmpPd;
          }
        pd->link = tempPd;
        currPd->link = pd;

        Enable;
      }

3. Indenting
  The  above example shows many of the indenting rules.  Braces ( "{" and "}" )
appear alone on a line, and are indented two spaces from the statement they are
to contain the body of, the body is indented two more spaces  from  the  braces
(for  a  total  of  four  spaces).    else's  and  else if's line up with their
dominating if statement (to avoid marching off to the right, and to reflect the
semantics of the statement).
                                        3


    if ((x = y) == 0)
      {
        flag = 1;
        printf (" the value was zero ");
      }
    else if (y == 1)
      {
        switch (today)
          {
            case Thursday:
                flag = 2;
                ThursdayAction();
                break;

            case Friday:
                flag = 3;
                FridayAction();
                break;

            default:
                OtherDayAction();
          }
      }
    else
        printf(" y had the wrong value ");

4. File Contents
  I think we agreed on the following order for file contents.

   1. initial descriptive comment (see example below) which contains:

         a. file  name,  with  indication  of the relative path to it when
            relevant

         b. brief descriptive abstract of contents

         c. a list of all defined procedures in their defined order

         d. list of authors

         e. list of current maintainers

         f. list  of   recent   and   major   modifications   in   reverse
            chronological order with indication (initials) of who made the
            change.

   2. included files (use relative path names whenever possible)

   3. external definitions (imports and exports)

   4. function declarations (externals and forward references)
                                        4


   5. constant declarations

   6. macro definitions

   7. type definitions

   8. global variable declarations

   9. procedure and function definitions

  Here is an example of the header comment:

    /*
     * FILE: libc/vkstuff/malloc.c
     *
     * CONTENTS:
     *      C storage allocator stolen and hacked up from UNIX for the SUN
     *      (NOTE: these were stolen and have the wrong naming conventions)
     *              malloc
     *              free
     *              realloc
     *              allock          DEBUG ONLY!
     *              SetBrk          ! our routine to fake up sbrk()
     *
     * AUTHORS: stolen and hacked by Andrew I. Shore (shore)
     *
     * MAINTAINER: shore
     *
     * HISTORY:
     * 03/05/82 AIS replaced calls to UNIX sbrk() with calls to own version
     *          SetBrk() for the sun/Vkernel
     */

5. Parenthesis ()
  We  seem  to have decided on the following conventions for parentheses.  When
parentheses enclose the  expression  for  a  statement  (if,  for,  etc.),  the
parentheses `belong to' the expression, so there is a space between the keyword
and  the  parenthesized expression.  For function calls the parentheses `belong
to' the call, so there is no space between function name and open paren  (there
may  some  inside  the  parentheses to make the expression list (argument list)
look nice).

    if (Mumble())
      {
        Grumble( (a = b) == 0 );
        return (Nil);
      }
    else
      {
        Fumble( a, b, c );
        return (ToSender);
      }
                                        5


It  is  unclear  what to do with return.  Note, then, that it is operators that
cause spaces on the outside of parentheses --  (a + b) * c.

6. General

   1. One statement/declaration per line.

   2. Make judicious use of blank lines.

         a. At least 3 blank lines between individual procedures.

         b. Blank lines surround "large" comments.

   3. Make sure comments and code agree!

   4. Don't just echo the code with comments -- make every comment  count!
      i.e. nix on:

          /* add foo to bar */
          bar += foo;
                                        i


                               Table of Contents
1. Names                                                                      1
2. Comments                                                                   1
3. Indenting                                                                  2
4. File Contents                                                              3
5. Parenthesis ()                                                             4
6. General                                                                    5
**************************************************************************




From norman at nose.cs.utoronto.ca  Fri Oct 11 20:54:16 2002
From: norman at nose.cs.utoronto.ca (Norman Wilson)
Date: Fri, 11 Oct 2002 06:54:16 -0400
Subject: [TUHS] Can someone advise me regarding a gui for UNIX
Message-ID: <200210111055.g9BAtAD23435@minnie.tuhs.org>

  22. Pike, R. "The Blit: A Multiplexed Graphics Terminal". _AT&T Bell
  Laboratories Technical Journal 63_, 8 (Oct. 1984).

Rob described an earlier version of the Blit work in a USENIX talk
at USENIX in January 1982 (Santa Monica CA).  So far as I know it
was just a talk, no paper, though he showed a canned demo on video
tape.

For those who don't know it, the Blit (in later versions called the
Jerq; in official product version, the AT&T 5620 DMD terminal, and
later the 630 and 730) is a separate terminal with a bitmapped display,
keyboard, and mouse.  The window system runs in the terminal; a
multiplexed-channel protocol (one channel per window) is used to
communicate with the host computer; a (user-mode) multiplexer program
on the host passes data for each channel to and from an appropriate
local process (group), one per channel.  Creating a new window in
the terminal tells the multiplexer to create a new process in the host.
By default the window is just a terminal (and the process is a shell),
but it is possible for a host program to download a program into the
terminal (where it can get at the screen and mouse directly) to act
on its behalf just for its own window; that's how graphical programs
work.  This often requires programs to be split into front and back
ends, but often that turns out to be a good idea anyway, keeping
user-interface work and file-manipulation and computation separate.
It also means much less communication bandwidth is needed; in fact
the communication line is RS232 (what else would you expect in 1982?).
It worked fine, even at 1200 bps, except when a large graphical front-
end program had to be loaded, but people tended to load such programs
once and keep them running.

I've been using this window system more or less daily since August 1984,
though only at home since I left Bell Labs in 1990.  (I am using it to
type this message.)  It is Spartan by modern standards--menus are short
and to-the-point, windows are not surrounded by fancy borders and icons,
there is no `desktop' or `graphical user environment'--it's just good
old UNIX in multiple windows, with a terminal window that makes good use
of the mouse for local editing, and provision to run fancier programs
when necessary.  It wouldn't work well for graphics-heavy work unless
the communication line could be greatly sped up--a web browser would be
hard to make work well unless all the pictures were left out.  But it's
well thought out, with a nice balance between spareness and function.  I
still like it better than any other window system I've seen; even Rob's
more recent work in Plan 9 seems to me over-elaborate by comparison.  I
also like much better the overall model that the terminal is a client
rather than a server; X11 always seemed inside-out to me.

I am still disappointed that the process of turning the Blit from a
research tool to a salable product was botched so badly.  If memory
serves, not only did it take several years longer than it should have
done, but when the 5620 hit the streets in early 1984 it cost a mere
$6000, which even in those days was outrageous for a terminal.  (None
of this was Rob's fault so far as I know.)  If things had gone better,
the UNIX windowing world might have turned out quite different.

Norman Wilson
Toronto ON


From cdl at mpl.ucsd.edu  Sat Oct 12 03:43:45 2002
From: cdl at mpl.ucsd.edu (Carl Lowenstein)
Date: Fri, 11 Oct 2002 10:43:45 -0700 (PDT)
Subject: [TUHS] c coding standards
Message-ID: <200210111743.KAA19023@opihi.ucsd.edu>

> From: "A.P.Garcia" <apgarcia at uwm.edu>
> To: tuhs at minnie.tuhs.org
> Subject: [TUHS] c coding standards
> Date: Fri, 11 Oct 2002 01:52:08 +0000
> 
> check out this old post I found on Google Groups.
> this kind of stuff makes me giddy.  :-)

< 2288 lines deleted >

Not to be overly picky, but aren't there two copies of everything.

    carl
-- 
    carl lowenstein         marine physical lab     u.c. san diego
                                                 clowenst at ucsd.edu


From apgarcia at uwm.edu  Sat Oct 12 06:19:33 2002
From: apgarcia at uwm.edu (A.P.Garcia)
Date: Fri, 11 Oct 2002 20:19:33 +0000
Subject: [TUHS] re: c coding standards
Message-ID: <20021011201252.3EAB0836F0@out0.mx.nwbl.wi.voyager.net>

> Not to be overly picky, but aren't there two copies of everything.

yes, sorry.  that's just how it was posted to usenet.



From apgarcia at uwm.edu  Sat Oct 12 08:11:03 2002
From: apgarcia at uwm.edu (A.P.Garcia)
Date: Fri, 11 Oct 2002 22:11:03 +0000
Subject: [TUHS] Can someone advise me regarding a gui for UNIX
Message-ID: <20021011220423.318A5C3E44@out4.mx.nwbl.wi.voyager.net>

> I've been using this window system more or less daily since August 1984,
> though only at home since I left Bell Labs in 1990.  (I am using it to
> type this message.)

!
what other hardware and software do you run, if you don't mind my noseyness?



From apgarcia at uwm.edu  Sat Oct 12 11:33:04 2002
From: apgarcia at uwm.edu (A.P.Garcia)
Date: Sat, 12 Oct 2002 01:33:04 +0000
Subject: [TUHS] rtm
Message-ID: <20021012012625.2213C9338C@out7.mx.nwbl.wi.voyager.net>

I just recently picked up a copy of a book that's been out for some
time, _Cyberpunk_ by Katie Hafner and John Markoff.  The last chapter
is about Robert T. Morris, Jr. and the worm incident (which in itself,
I think, is an important event in Unix history).

The book contains some interesting details, including some Unix folklore
that I haven't seen anywhere else.  For instance, RTM Sr. had a terminal
at home, as did other members of the CSR group at Bell Labs.  So a number
of their kids had accounts!  RTM Sr. comes off as a very likeable fellow,
btw.

At the Atlanta Linux Showcase in 1999, Norm Schryer gave a keynote speech,
in which he told an amusing anecdote about Morris Sr. (I may be slightly
off on some details; such is oral history):

Morris, he said, was the kind of guy who always liked to tinker with
things, and if an object had buttons, Morris just had to push them.
In fact, sometimes Morris was just a little too quick with his fingers.
On one side of a machine room was the light switch, and on the other
side was the power to the machine. 

On at least one occasion, you guessed it -- Morris hit the wrong switch.
Some people hung a disk pack that got ruined around his neck, and someone
put up a big sign as a reminder: "THIS IS THE WEST WALL!"

:-)



From dmr at plan9.bell-labs.com  Sat Oct 12 17:20:41 2002
From: dmr at plan9.bell-labs.com (Dennis Ritchie)
Date: Sat, 12 Oct 2002 03:20:41 -0400
Subject: [TUHS] Re: Can someone advise me regarding a gui for UNIX
Message-ID: <d9ede018886c253ffb43eadd78fa939d@plan9.bell-labs.com>

Norman Wilson's account of the Jerq/Blit etc. is quite
complete and correct, though there was some recycling
of names.  'Jerq' actually was used quite early, when
Pike got interested in bitmap graphics.  The name
was a takeoff on the Three Rivers Perq, which he (and I)
saw at Lucasfilm Ltd. while attending an early Usenix.
Blit was the slightly more PC version (suggested either
as part of BitBlt or "Bell Labs Interactive Terminal).
The originals used the Motorola 68000, and part of
the development messup was AT&T Computer systems'
decision to switch to the WE32000 processor with
consequent delay for porting and reworking.

The earliest versions were not quite as wonderful
in practice as Norman suggests for the later ones.
They were built by the Teletype corp. model shop
(in quantity of a few hundred) and downloading
the OS took several minutes at 1200bps--necessary
at startup, since they didn't have a ROM for the whole
thing, just enough for doing a download.  They
were also static electricity antennas!  Many
is the time that I would shift in my chair, then
touch the keyboard, only to have the terminal
reset itself.  I developed the habit of putting my
hand on the heavy steel case before moving around.

On the other hand, the basic idea was architecturally
right (and the later commercial versions were not so
subject to static, and had ROM for the OS).  They
were even nicer at 9600bps.

It's good to know that Norman is still using his.

	Dennis





From arnold at skeeve.com  Mon Oct 14 05:58:34 2002
From: arnold at skeeve.com (Aharon Robbins)
Date: Sun, 13 Oct 2002 21:58:34 +0200
Subject: [TUHS] Can someone advise me regarding a gui for UNIX
Message-ID: <200210122001.g9CK1Dj28305@lmail.actcom.co.il>

Another reason the 5620 was botched so badly was that AT&T wanted >=
$2000 for the development kit (read: C compiler and libraries) for it.
Not a good way to get lots of 3rd party application developers
on your bandwagon.

I used one for a year or so; it was the first windowing system I'd
used and the only one I've really liked. For about 10 years I've been
using 9wm, which gives a similar feel (at least to me). Those who want
to go all the way should adopt 9term as well.  (I generally run xterm +
bash these days, although for a long while it was 9term + es/rc.)

Somewhere, I have an X version of the 5620 font.  I found that it
wasn't so pretty. I've been using the pelm-latin1-9 font from the sam
distribution for years.

Norman forgot to mention that the most long-lived split-design application
is Rob Pike's sam editor, still available for X11 and still in use on
Plan 9.

Arnold



From bsw at cuzuco.com  Sun Oct 13 17:03:39 2002
From: bsw at cuzuco.com (Brian S Walden)
Date: Sun, 13 Oct 2002 03:03:39 -0400
Subject: [TUHS] Re: Can someone advise me regarding a gui for UNIX
In-Reply-To: <200210130210.g9D2ALD46305@minnie.tuhs.org>
References: <200210130210.g9D2ALD46305@minnie.tuhs.org>
Message-ID: <20021013070338.GA12787@panix.com>

Another hurdle for the 5620/630/730 lines of terminals was when I
tried getting software support. Teletype being a mostly a "dumb"
terminal manufacturer never considered them more that a way to have
multilple 80 char x 24 line terminals on one display. I had difficulty
in conveying to them that it was a computer in its own right and you
could program it. The marketing was probably just as limited in scope.

Another blow for the BLIT portion on the terminal came when you
cound get an external cartridge for the 730 that turned it
into an X-terminal. I got mine in 1991 and then rarely used
layers after that.
-B



From drwho8 at worldnet.att.net  Mon Oct 14 12:22:01 2002
From: drwho8 at worldnet.att.net (Gregg C Levine)
Date: Sun, 13 Oct 2002 22:22:01 -0400
Subject: [TUHS] Pack found in Tim Shoppa distribution but not listed
Message-ID: <000e01c27328$7bcfd7a0$9573580c@who>

Hello from Gregg C Levine
This is something that is totally different then what I first reported on
regarding this distribution. In the readme for this one, it mentions
everything list inside the directory, except the one marked down as
"Unlabeled", and it originally came on a RL02 type diskpack. It is not
listed in the Readme. Obviously it is what it says it is, an unlabled
diskpack that Tim recovered the same day as the others, and those are indeed
present, and listed. Except obviously the one that I first reported, that
one isn't mentioned, and not there. That subject is done. I am just
reporting on "Unlabeled", as far as everyone is concerned, is there anything
on it? Or is it an empty pack?
Gregg C Levine drwho8 at worldnet.att.net
"Oh my!" The Second Doctor's nearly favorite phrase.



From shoppa at trailing-edge.com  Mon Oct 14 16:11:55 2002
From: shoppa at trailing-edge.com (Tim Shoppa)
Date: Mon, 14 Oct 2002 02:11:55 -0400
Subject: [TUHS] Pack found in Tim Shoppa distribution but not listed
In-Reply-To: <000e01c27328$7bcfd7a0$9573580c@who>
References: <000e01c27328$7bcfd7a0$9573580c@who>
Message-ID: <3DAA602B.nailF6V1HJ5JO@mini-me.trailing-edge.com>

Gregg C Levine wrote:
> [On the contents of the RL02 marked simply "unalbeled" in the RL02
>  V6 set] : is there anything on it?

Yes, some Fortran source files (*.f), executables, and data files, mostly
related to chemistry.  Probably not of great interest all things considered
to TUHS people.

Tim.


From jss at subatomix.com  Tue Oct 15 04:39:33 2002
From: jss at subatomix.com (Jeffrey Sharp)
Date: Mon, 14 Oct 2002 13:39:33 -0500
Subject: [TUHS] rtm
In-Reply-To: <20021012012625.2213C9338C@out7.mx.nwbl.wi.voyager.net>
References: <20021012012625.2213C9338C@out7.mx.nwbl.wi.voyager.net>
Message-ID: <13370062434.20021014133933@subatomix.com>

On Friday, October 11, 2002, A.P.Garcia wrote:
> Robert T. Morris, Jr. and the worm incident (which in itself, I think, is
> an important event in Unix history).

Indeed. One of the things that got me interested in UNIX and computer
history was an article about the Morrises and the worm, titled 'The
Shockwave Rider', in the June 1990 issue of PC/Computing. It was several
years after 1990 when I found the article by chance in the local library of
my small Oklahoma town. I was about 13 years of age.

Yes, I believe I am somewhat younger than most the very respectable members
of this group. :-)

-- 
Jeffrey Sharp



From drwho8 at worldnet.att.net  Tue Oct 15 05:02:01 2002
From: drwho8 at worldnet.att.net (Gregg C Levine)
Date: Mon, 14 Oct 2002 15:02:01 -0400
Subject: [TUHS] Actual names of boot images versus names listed in readme file for boot_images
Message-ID: <001e01c273b4$2e0ce620$bc5a580c@who>

Hello from Gregg C Levine
I found out, on my system, and borrowing the Cygwin tools for file
manipulation, the actual file name for .2,9BSD_rl02_1145.gz, it is
rl02_2.9BSDroot, so I used that name in place of the one suggested inside
the readme file. It works the same way. However, this is just the root
collection. Is there any other pack available that contains the other
members of the entire 2.9BSD system that provided us with this one? Also
this was done with version 2.9-11 of Simh. So, when you get a chance,
Warren, you can update the readme, and upload the appropriate file to the
directory on your server. Oh yes, this came from a mirror of your site, its
the one on ftp.tux.org
Gregg C Levine drwho8 at worldnet.att.net
"Oh my!" The Second Doctor's nearly favorite phrase.



From drwho8 at worldnet.att.net  Tue Oct 15 05:05:05 2002
From: drwho8 at worldnet.att.net (Gregg C Levine)
Date: Mon, 14 Oct 2002 15:05:05 -0400
Subject: [TUHS] rtm
References: <20021012012625.2213C9338C@out7.mx.nwbl.wi.voyager.net> <13370062434.20021014133933@subatomix.com>
Message-ID: <002501c273b4$9d9e4ce0$bc5a580c@who>

Hello from Gregg C Levine
You might be. For me, it was reading "Cuckoo's Egg" by Cliff Stoll, which
activated my interests in things UNIX, his involvement with the elder of the
two, was interesting, and his involvement with stopping the worm was also
interesting.
Gregg C Levine drwho8 at worldnet.att.net
"Oh my!" The Second Doctor's nearly favorite phrase.
----- Original Message -----
From: "Jeffrey Sharp" <jss at subatomix.com>
To: <tuhs at minnie.tuhs.org>
Sent: Monday, October 14, 2002 2:39 PM
Subject: Re: [TUHS] rtm


> On Friday, October 11, 2002, A.P.Garcia wrote:
> > Robert T. Morris, Jr. and the worm incident (which in itself, I think,
is
> > an important event in Unix history).
>
> Indeed. One of the things that got me interested in UNIX and computer
> history was an article about the Morrises and the worm, titled 'The
> Shockwave Rider', in the June 1990 issue of PC/Computing. It was several
> years after 1990 when I found the article by chance in the local library
of
> my small Oklahoma town. I was about 13 years of age.
>
> Yes, I believe I am somewhat younger than most the very respectable
members
> of this group. :-)
>
> --
> Jeffrey Sharp
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> http://minnie.tuhs.org/mailman/listinfo/tuhs
>



From msokolov at ivan.Harhan.ORG  Tue Oct 15 05:15:52 2002
From: msokolov at ivan.Harhan.ORG (Michael Sokolov)
Date: Mon, 14 Oct 02 12:15:52 PDT
Subject: [TUHS] rtm
Message-ID: <0210141915.AA04291@ivan.Harhan.ORG>

Jeffrey Sharp <jss at subatomix.com> wrote:

> Yes, I believe I am somewhat younger than most the very respectable members
> of this group. :-)

I'm about the same. My timeline:

1979 born
1988 first computer: Soviet PDP-11 clone, first language: PDP-11 assembly
1995 first introduced to UNIX
1996 first live encounter with a VAX
1998 started maintaining my own version of VAX UNIX
2000 fully converted to it
2002 thinking about designing and building a new VAX CPU on an FPGA

MS


From dmr at plan9.bell-labs.com  Tue Oct 15 13:40:56 2002
From: dmr at plan9.bell-labs.com (Dennis Ritchie)
Date: Mon, 14 Oct 2002 23:40:56 -0400
Subject: [TUHS] Re: rtm
Message-ID: <50e0dcfc7f2003443c9119382efc35be@plan9.bell-labs.com>

Garcia is correct to praise the Hafner/Markoff account
of the worm incident.  There were some details about
the kids' accounts and exploits that Markoff decided
to elide; by the time he wrote that chapter he had
become rather sympathetic with the Morris family.

In 1995 another big incident occurred: the exploitation
of the SYN TCP-connection takeover attack (Mitnick
etc.)  Markoff got another front-page NYT story out
of this (and a book with Shimomura).  I sent mail
to Markoff at the time of the newspaper coverage reminding
him that RTM had discovered the basic attack
in 1985 (see CSTR 117 at
 http://www.cs.bell-labs.com/cm/cs/cstr.html );
while here during a summer.  Markoff replied in part,

>Interesting how often RTM figures, one way or another, in your front-page
>stories, and of course the [Cyberpunk] book....
>
>        Dennis Ritchie

  yes, this is true. you know i sat there on sunday for about ten minutes and
   thought about whether i should include rtm in my story - it would obviously
  have spiced it up. i finally decided not to on the grounds that 1. i have
  done enough to mythologize him for one decade 2. he is probably entitled
  not to be dragged through all this again. i still wonder whether i did the
  readers a disservice...

Incidentally, "RTM Sr." was (while here) "rhm" by login name,
and always called Bob; I don't think he actually has a middle name (at least
I don't know it.)  I think it's like Harry S Truman.  RTM
is called Robert, and never used Jr.

About

 > [Bob] Morris, he said, was the kind of guy who always liked to tinker with
 > things, and if an object had buttons, Morris just had to push them.
 > In fact, sometimes Morris was just a little too quick with his fingers.
 > On one side of a machine room was the light switch, and on the other
 > side was the power to the machine.

 > On at least one occasion, you guessed it -- Morris hit the wrong switch.
 > Some people hung a disk pack that got ruined around his neck, and someone
 > put up a big sign as a reminder: "THIS IS THE WEST WALL!"

I suspect that we may be dealing with the "Schryer filter" regarding
some of the details.  Norm S. was right about Bob's being
an aggressive investigator and fiddler,  but I don't
connect the west-wall sign with Morris in particular, but my
memory could be failing too.  Norman Wilson
might have been around for advent of the sign.
In the event, it had more to do with circuit breakers
labelled in small print "east wall" and "west wall"
and someone choosing the wrong one.

	Dennis



From grog at lemis.com  Tue Oct 15 14:08:48 2002
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Tue, 15 Oct 2002 13:38:48 +0930
Subject: [TUHS] Weinberger stencil? (was: rtm)
In-Reply-To: <50e0dcfc7f2003443c9119382efc35be@plan9.bell-labs.com>
References: <50e0dcfc7f2003443c9119382efc35be@plan9.bell-labs.com>
Message-ID: <20021015040848.GB12010@wantadilla.lemis.com>

On Monday, 14 October 2002 at 23:40:56 -0400, Dennis Ritchie wrote:
> Garcia is correct to praise the Hafner/Markoff account
> of the worm incident.  There were some details about
> the kids' accounts and exploits that Markoff decided
> to elide; by the time he wrote that chapter he had
> become rather sympathetic with the Morris family.

Interesting stuff.  While you're in historic reminiscences mode, can
you shed any light on the "Peter Weinberger stencil" incident?  My
understanding of the story, gleaned from multiple sources, is
something like this:

  At some point, presumably round the time of the appearance of AT&T's
  death star logo, Peter Weinberger was promoted from techie to some
  kind of management position.  Somebody came across the idea of
  making a large stencil of his face in death-star like technology,
  and used it to paint an image of him on a nearby water tower.
  Allegedly the costs were charged to Peter's department.

  Some years later, this stencil arrived in Greg Rose's office in
  Australia from an anonymous sender.  Greg has a suspicion who the
  sender was, but no proof, so he doesn't want to comment.  He gave it
  to our own Warren Toomey, who still has it in his garage.

  At some point, Peter Salus suggested that the image was of Rob Pike,
  not of Peter Weinberger, but both Rob and Greg R. have denied this
  version.

Things that intrigue me about this story are:

1.  Who made the stencil, and why?
2.  What was the time frame?
3.  Who sent it to Greg Rose, and why?

I suppose that even now it's possible that this information should not
be made public, and I can accept that.  But if there is anything which
can be used to fill it in, I'm sure I wouldn't be the only person to
find it interesting.

Greg
--
Finger grog at lemis.com for PGP public key
See complete headers for address and phone numbers


From hansolofalcon at worldnet.att.net  Tue Oct 15 14:10:22 2002
From: hansolofalcon at worldnet.att.net (Gregg C Levine)
Date: Tue, 15 Oct 2002 00:10:22 -0400
Subject: [TUHS] Re: rtm
In-Reply-To: <50e0dcfc7f2003443c9119382efc35be@plan9.bell-labs.com>
Message-ID: <000001c27400$c897aa80$1f5b580c@who>

Hello from Gregg C Levine

From asbesto at freaknet.org  Tue Oct 15 17:46:35 2002
From: asbesto at freaknet.org (asbesto)
Date: Tue, 15 Oct 2002 07:46:35 +0000
Subject: [TUHS] pdp11/34 can't boot ... HELP ! :(((
In-Reply-To: <13370062434.20021014133933@subatomix.com>
References: <20021012012625.2213C9338C@out7.mx.nwbl.wi.voyager.net> <13370062434.20021014133933@subatomix.com>
Message-ID: <20021015074635.GD4158@freaknet.org>


hi,

we moved our pdp11/34 from 2nd to 3rd floor here. doing so, we have
DISMEMBERED the pdp11, and remounted as we have done many other
times without problems ...

but this time, the pdp11 can't boot :/

pressing ctrl-boot reset the bus (all the light blinks, and he seem
to seek rl01 and rk01) but the boot program dont "RUN" and so there
is nothing on serial port to boot on...

putting in the octal boot code give the same result :/

can someone help me ? can i diag something ? 
:(

asbesto/freaknet medialab

-- 
[asbesto : freaknet medialab : radio#cybernet : GPG key on  keyservers]
[ MAIL ATTACH, SPAM, HTML, WORD, and msgs larger than 95K > /dev/null ]
[http://www.freaknet.org/asbesto :::::: http://kyuzz.org/radiocybernet]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20021015/f891a6d0/attachment.sig>

From dot at dotat.at  Thu Oct 17 06:09:40 2002
From: dot at dotat.at (Tony Finch)
Date: Wed, 16 Oct 2002 21:09:40 +0100
Subject: [TUHS] C reference manual
Message-ID: <20021016210940.K3711@chiark.greenend.org.uk>

I'm looking for a copy of the C reference manual from some time
between the 6th Edition (1975) and the first version that came
with 4.3BSD (1986). The stuff in the TUHS archive mostly seems to
be missing the documentation sets, or in the case of the earlier
BSDs they are ommitted for copyright reasons. There are some
tutorials dating from about 1979 but they aren't much use.

Any help would be appreciated.

Tony.
-- 
f.a.n.finch <dot at dotat.at> http://dotat.at/
DOGGER: NORTHEAST 6 TO GALE 8 BACKING NORTHWEST 4 OR 5. RAIN OR SHOWERS.
MODERATE OR GOOD.


From dmr at plan9.bell-labs.com  Thu Oct 17 12:59:37 2002
From: dmr at plan9.bell-labs.com (Dennis Ritchie)
Date: Wed, 16 Oct 2002 22:59:37 -0400
Subject: [TUHS] Re: Weinberger stencil? (was: rtm)
Message-ID: <3bb0a2272b81a09c90cebb485e65d45a@plan9.bell-labs.com>

Lehey wondered:

>  ....  can
> you shed any light on the "Peter Weinberger stencil" incident?  ...

> Somebody came across the idea of
> making a large stencil of his face in death-star like technology,
>  and used it to paint an image of him on a nearby water tower.
>  Allegedly the costs were charged to Peter's department.

>  Some years later, this stencil arrived in Greg Rose's office in
>  Australia from an anonymous sender.  Greg has a suspicion who the
>  sender was, but no proof, so he doesn't want to comment.  He gave it
>  to our own Warren Toomey, who still has it in his garage.

>  At some point, Peter Salus suggested that the image was of Rob Pike...

I could recover some of the dates, but
not accurately from memory.  Weinberger was promoted,
first to department head, then to being director of a
newly-created but next-door center, then to our own
executive director.  This would have been mid-late 80s,
early 90s.  He was being groomed, it appears.
Shortly before trivestiture, 1994ish, he went to
the business part of AT&T, possibly in preparation
for coming back to a higher management position
at the Labs.  When the Lucent/AT&T split occurred
he was somewhat caught on the AT&T side.
He ended up leaving AT&T and going to a financial
quant company.

His image was particularly striking, and was used
to kid him in various ways, e,g, as a default image
in mail icons.  The image rendering his
face with the Deathstar styling was done by
Tom Duff, and it appeared, for example, on
T-shirts worn publically at venues like Usenix
and elsewhere.  Other versions of it
appear inscribed in concrete now buried
beneath floors at the Labs.  There is a
bitmap version (rendered in 1cm magnets) of the
full image, not death-starred, high on
a steel wall above a landing on a nearby
stairwell.

The large stencilled image of the Deathstar/PJW
rendition did indeed appear suddenly one day on
a water tower; it must have been about 10 feet
tall.  Kernighan had  a photo of it, and Gerard
Holzmann just scanned it:

    http://www.cs.bell-labs.com/who/dmr/pix/watertower.jpg

It was painted over quite rapidly,
a couple of days at most.  (The tower itself
is now gone, though not because of this.)
The image was certainly not of Rob Pike.

After this happened, a voucher was pinned up
on a communal corkboard, claiming expenses
for several cans of blue spray paint.  The voucher
was signed by one G. R. Emlin, a fictitious personage
with his (later her) own history.  Attached to
it was a handwritten note from our then Executive
Director (Vic Vyssotsky) saying approximately
as follows:

	Unfortunately, this voucher cannot be
	approved by me; I am not empowered
	to approve Real Estate improvements.

	If Mr. Emlin would like to arrange a transfer
	to the Building and Grounds department,
	I would be happy to assist.

So: who did it?  If Greg Rose suspects certain
aviation-inclined buddies, I in turn think his
suspicions are likely to be well-founded.

I managed to retrieve the image used to create the stencil;
it's now linked-to near the bottom of

 http://www.cs.bell-labs.com/10thEdMan/v2pix.html

	Dennis



From norman at nose.cs.utoronto.ca  Thu Oct 17 13:45:59 2002
From: norman at nose.cs.utoronto.ca (Norman Wilson)
Date: Wed, 16 Oct 2002 23:45:59 -0400
Subject: [TUHS] Re: Weinberger stencil? (was: rtm)
Message-ID: <200210170346.g9H3kYD06543@minnie.tuhs.org>

This is certainly non-technical UNIX history, which is not to
say it isn't interesting.

I can sharpen up a few details of Dennis's account.  Peter was
already a department head when I first visited the Labs in early
1984.  I believe his face was already a favourite test image for
various graphics experts, but the cult of the face didn't really
get started until the following year.

In particular I think it was in the summer of 1985 that Tom Duff
thought of the deathstar transform (turning a picture into variable-
width horizontal stripes, as the AT&T logo to a highlighted sphere).
Certainly it was later that year that the much-bigger-than-life
image appeared on the water tower: my calendar file still says

	sep 16	btl water tower 1985

Peter was still a department head at that time; he didn't climb
further into management until about 1990.

As I recall, the water tower remained painted for a couple of days.
A two-man team from the Physical Plant department finally covered it
over: one man in overalls wielding paint, another in suit and tie
watching to be sure no trace remained.

Lest people get the wrong idea, Peter took no offense at the
overuse of his face.  In fact a few years later he agreed to
have a plaster cast made.  Someone (Duff?) then made a latex
positive from the plaster negative, intending to digitize it
somehow into a three-dimensional model.  I don't know if that
ever happened, but I did borrow the latex one day, used it to
generate another negative in ice, and cast a large chocolate
truffle which I then set out in the UNIX Room (as the group's
common terminal room was called) for all to enjoy.

That may have been the only really interesting use of the 3d
face.  In any case the plaster cast was presented to me when
I left the Labs in 1990, and I still have it, though I haven't
done anything with it since.

There were also some smaller stencils made of the same deathstar-
Peter face.  (In fact I have it on good authority that the big
one was made by projecting one of the smaller ones on a wall.)
When Bell Labs bought a Cray X-MP in 1986 or 1987 (my records aren't
that complete), one of our group made several visits to Cray to
get a head start on a special network interface we would need.
He took along one of the small stencils and put a few Peter faces
on panels that were normally covered up when the machine was running.
(The Cray was to be shared by Research and the Comp Center, and the
Comp Center were a bit stuffier.)  To everyone's surprise, when the
machine arrived it bore no extra decorations.  Presumably Cray shipped
the painted system to another customer; we never found out who.

The Computing Science Research Center was a fun place to work.

Norman Wilson
Toronto ON


From iking at killthewabbit.org  Thu Oct 17 16:02:26 2002
From: iking at killthewabbit.org (Ian King)
Date: Wed, 16 Oct 2002 23:02:26 -0700
Subject: [TUHS] C reference manual
References: <D8271EBE8528AE4AAD5D71E74D102FE71C1DA1@WIN-MSG-08.wingroup.windeploy.ntdev.microsoft.com>
Message-ID: <001501c275a2$c4ed1a20$450010ac@dawabbit>

I have an original (in print) of the C reference manual from Unix 6th Ed, as
part of a multipart binder titled "Documents for Use With the Unix
Timesharing System", as well as the "UNIX Programmer's Manual", which is a
print copy of the man pages.  I could probably scan the C ref in my copious
spare time, if you're not in a hurry.  Warren, do you want to archive stuff
like this?  -- Ian

-----Original Message-----
From: Tony Finch [mailto:dot at dotat.at]
Sent: Wednesday, October 16, 2002 1:10 PM
To: tuhs at minnie.tuhs.org
Cc: dot at dotat.at
Subject: [TUHS] C reference manual


I'm looking for a copy of the C reference manual from some time between
the 6th Edition (1975) and the first version that came with 4.3BSD
(1986). The stuff in the TUHS archive mostly seems to be missing the
documentation sets, or in the case of the earlier BSDs they are ommitted
for copyright reasons. There are some tutorials dating from about 1979
but they aren't much use.

Any help would be appreciated.

Tony.
--
f.a.n.finch <dot at dotat.at> http://dotat.at/
DOGGER: NORTHEAST 6 TO GALE 8 BACKING NORTHWEST 4 OR 5. RAIN OR SHOWERS.
MODERATE OR GOOD. _______________________________________________
TUHS mailing list
TUHS at minnie.tuhs.org http://minnie.tuhs.org/mailman/listinfo/tuhs



From helbig at informatik.ba-stuttgart.de  Thu Oct 17 17:40:16 2002
From: helbig at informatik.ba-stuttgart.de (helbig at informatik.ba-stuttgart.de)
Date: Thu, 17 Oct 2002 09:40:16 +0200
Subject: [TUHS] C reference manual
Message-ID: <76490f7aec09ba55cb389e1c589ecc4f@informatik.ba-stuttgart.de>

Hallo,
Most, if not all, of the V6-docs was distributed with V6 as troff sources.
At
	http://www.ba-stuttgart.de/~helbig/os/
you'll find postscript versions of these docs.

Have fun,
Wolfgang
-------------- next part --------------
An embedded message was scrubbed...
From: unknown sender
Subject: no subject
Date: no date
Size: 38
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20021017/ce4f8c45/attachment.mht>

From iking at killthewabbit.org  Thu Oct 17 16:02:26 2002
From: iking at killthewabbit.org (Ian King)
Date: Wed, 16 Oct 2002 23:02:26 -0700
Subject: [TUHS] C reference manual
References: <D8271EBE8528AE4AAD5D71E74D102FE71C1DA1@WIN-MSG-08.wingroup.windeploy.ntdev.microsoft.com>
Message-ID: <001501c275a2$c4ed1a20$450010ac@dawabbit>

I have an original (in print) of the C reference manual from Unix 6th Ed, as
part of a multipart binder titled "Documents for Use With the Unix
Timesharing System", as well as the "UNIX Programmer's Manual", which is a
print copy of the man pages.  I could probably scan the C ref in my copious
spare time, if you're not in a hurry.  Warren, do you want to archive stuff
like this?  -- Ian

-----Original Message-----
From: Tony Finch [mailto:dot at dotat.at]
Sent: Wednesday, October 16, 2002 1:10 PM
To: tuhs at minnie.tuhs.org
Cc: dot at dotat.at
Subject: [TUHS] C reference manual


I'm looking for a copy of the C reference manual from some time between
the 6th Edition (1975) and the first version that came with 4.3BSD
(1986). The stuff in the TUHS archive mostly seems to be missing the
documentation sets, or in the case of the earlier BSDs they are ommitted
for copyright reasons. There are some tutorials dating from about 1979
but they aren't much use.

Any help would be appreciated.

Tony.
--
f.a.n.finch <dot at dotat.at> http://dotat.at/
DOGGER: NORTHEAST 6 TO GALE 8 BACKING NORTHWEST 4 OR 5. RAIN OR SHOWERS.
MODERATE OR GOOD. _______________________________________________
TUHS mailing list
TUHS at minnie.tuhs.org http://minnie.tuhs.org/mailman/listinfo/tuhs

_______________________________________________
TUHS mailing list
TUHS at minnie.tuhs.org
http://minnie.tuhs.org/mailman/listinfo/tuhs
--upas-zrpwgyjndendvadweczbzopjxz--


From dot at dotat.at  Thu Oct 17 19:45:10 2002
From: dot at dotat.at (Tony Finch)
Date: Thu, 17 Oct 2002 10:45:10 +0100
Subject: [TUHS] C reference manual
In-Reply-To: <76490f7aec09ba55cb389e1c589ecc4f@informatik.ba-stuttgart.de>; from helbig@informatik.ba-stuttgart.de on Thu, Oct 17, 2002 at 09:40:16AM +0200
References: <76490f7aec09ba55cb389e1c589ecc4f@informatik.ba-stuttgart.de>
Message-ID: <20021017104510.A24540@chiark.greenend.org.uk>

Thanks to those who offered copies of the 6th Edition C reference manual,
but I was after something from the 7th Edition or even later. (There's
already a copy of the 6th Edition doc sources in the TUHS archive.)

Tony.
-- 
f.a.n.finch <dot at dotat.at> http://dotat.at/
SOUTH FITZROY: NORTH BACKING SOUTHEAST 4 OR 5, OCCASIONALLY 6, BECOMING
VARIABLE 3 FOR A TIME. THUNDERY SHOWERS AT FIRST. MODERATE OR GOOD.


From wkt at minnie.tuhs.org  Thu Oct 17 20:40:18 2002
From: wkt at minnie.tuhs.org (Warren Toomey)
Date: Thu, 17 Oct 2002 20:40:18 +1000 (EST)
Subject: [TUHS] C reference manual
In-Reply-To: <001501c275a2$c4ed1a20$450010ac@dawabbit> from Ian King at "Oct
 16, 2002 11:02:26 pm"
Message-ID: <200210171040.g9HAeI610163@minnie.tuhs.org>

In article by Ian King:
> I have an original (in print) of the C reference manual from Unix 6th Ed, as
> part of a multipart binder titled "Documents for Use With the Unix
> Timesharing System", as well as the "UNIX Programmer's Manual", which is a
> print copy of the man pages.  I could probably scan the C ref in my copious
> spare time, if you're not in a hurry.  Warren, do you want to archive stuff
> like this?  -- Ian

Oh yes!
	Warren


From norman at nose.cs.utoronto.ca  Thu Oct 17 23:13:22 2002
From: norman at nose.cs.utoronto.ca (Norman Wilson)
Date: Thu, 17 Oct 2002 09:13:22 -0400
Subject: [TUHS] C reference manual
Message-ID: <200210171314.g9HDE2D11674@minnie.tuhs.org>

To forestall those who haven't looked: the good news is that
the papers from Volume 2 of the manual were included in /usr/doc
on the V7 tape; the bad news is that the C Reference Manual was
omitted.  Here is /usr/doc/cman in its entirety:

  Sorry, but for copyright reasons, the source
  for the C Reference Manual is not distributed.

Presumably the problem was that the Reference Manual was published
as part of the a real book in 1978.

I forget just what Tony was after in the first place, but maybe
some of the stuff on Dennis Ritchie's home page will help:
	http://www.cs.bell-labs.com/who/dmr/index.html
In particular the Sixth Edtion version of the C Reference Manual
is there.

Norman Wilson
Toronto ON


From arnold at skeeve.com  Fri Oct 18 00:19:12 2002
From: arnold at skeeve.com (Aharon Robbins)
Date: Thu, 17 Oct 2002 16:19:12 +0200
Subject: [TUHS] C reference manual
Message-ID: <200210171419.g9HEJCd15376@skeeve.com>

If anyone has one of the SCO Ancient Unix licenses and a copy of the
archive that went with it, then they legally have the source to System
III.  If such a person extracts sys3.tar.gz and looks in usr/src/man/docs
they'll find a file named `c_man' with the actual manual in it.  I quote:

	...
	.SH "1.  INTRODUCTION"
	.PP
	This manual
	.FS
	.ps +1
	\(dg This manual is reprinted, with minor changes, from
	.I "The C Programming Language"
	by Brian W. Kernighan and Dennis M. Ritchie,
	Prentice Hall, Inc., 1978.
	.ps
	.FE
	describes the C language
	...

What the legalities are of redistributing this, and/or generating
postscript from it, are, I don't know.  Similar questions apply
to scanning in the ref man from a copy of K&R-I, which is now
out of print. (I wish Caldera had included System III in their
releasing of Ancient Unix. Sigh.)

I hope this helps, some.

Arnold

P.S. Completely unrelated, but I find it really cool how much of
the System III doc refers to C and Unix on the System/370...

> Subject: Re: [TUHS] C reference manual
> From: norman at nose.cs.utoronto.ca (Norman Wilson)
> To: tuhs at minnie.tuhs.org
> Date: Thu, 17 Oct 2002 09:13:22 -0400
>
> To forestall those who haven't looked: the good news is that
> the papers from Volume 2 of the manual were included in /usr/doc
> on the V7 tape; the bad news is that the C Reference Manual was
> omitted.  Here is /usr/doc/cman in its entirety:
>
>   Sorry, but for copyright reasons, the source
>   for the C Reference Manual is not distributed.
>
> Presumably the problem was that the Reference Manual was published
> as part of the a real book in 1978.
>
> I forget just what Tony was after in the first place, but maybe
> some of the stuff on Dennis Ritchie's home page will help:
> 	http://www.cs.bell-labs.com/who/dmr/index.html
> In particular the Sixth Edtion version of the C Reference Manual
> is there.
>
> Norman Wilson
> Toronto ON


From wkt at minnie.tuhs.org  Fri Oct 18 13:06:36 2002
From: wkt at minnie.tuhs.org (Warren Toomey)
Date: Fri, 18 Oct 2002 13:06:36 +1000 (EST)
Subject: [TUHS] Minnie mail down over the weekend
Message-ID: <200210180306.g9I36aB20475@minnie.tuhs.org>

The machine which hosts this mailing list is scheduled to be down over the
Australian weekend due to power problems. It should be up on Monday
morning Australian time.

	Warren


From asbesto at freaknet.org  Fri Oct 18 21:26:01 2002
From: asbesto at freaknet.org (asbesto)
Date: Fri, 18 Oct 2002 11:26:01 +0000
Subject: [TUHS] C reference manual, another one
In-Reply-To: <200210171419.g9HEJCd15376@skeeve.com>
References: <200210171419.g9HEJCd15376@skeeve.com>
Message-ID: <20021018112601.GA11504@freaknet.org>

Il Thu, Oct 17, 2002 at 04:19:12PM +0200, Aharon Robbins rigurgitava:

> If anyone has one of the SCO Ancient Unix licenses and a copy of the
> archive that went with it, then they legally have the source to System

well,

we at freaknet medialab have a strange copy of a TROFF book. here's
the intro:

----------------------snip--------------------
.fp 3 G
.TL
C Reference Manual
.AU
Dennis M. Ritchie
.AI
.MH
.sp
May 1, 1977
.PP
.SH
.ti 0
1.  Introduction
.LP
C is a computer language which offers
a rich selection of operators and data types
and the ability to impose useful structure
on both control flow and data.
All the basic operations and data objects
-------------------------snip------------------

maybe can be useful for historical purpose ? what about the (C) 
and the rights about this ? 

that come from Martin Guy. can we publish it ? it's useful ? 

om mani padme hum, 

-- 
[asbesto : freaknet medialab : radio#cybernet : GPG key on  keyservers]
[ MAIL ATTACH, SPAM, HTML, WORD, and msgs larger than 95K > /dev/null ]
[http://www.freaknet.org/asbesto :::::: http://kyuzz.org/radiocybernet]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20021018/a3abe8f3/attachment.sig>

From dmr at plan9.bell-labs.com  Mon Oct 21 14:19:41 2002
From: dmr at plan9.bell-labs.com (Dennis Ritchie)
Date: Mon, 21 Oct 2002 00:19:41 -0400
Subject: [TUHS] re: Can someone advise me regarding a gui for UNIX
Message-ID: <90d5aca0a564f1de023fd38f32cd5dab@plan9.bell-labs.com>

Norman Wilson recalled

 >  22. Pike, R. "The Blit: A Multiplexed Graphics Terminal". _AT&T Bell
 >  Laboratories Technical Journal 63_, 8 (Oct. 1984).

 > Rob described an earlier version of the Blit work in a USENIX talk
 > at USENIX in January 1982 (Santa Monica CA).  So far as I know it
 > was just a talk, no paper, though he showed a canned demo on video
 > tape.

By coincidence, one of the two videos made about early Blit
work is newly available in .mpg format: look near the
bottom of Rob Pike's page under Movies:

  http://www.cs.bell-labs.com/who/rob/index.html

This was just now done by Gerard Holzmann.

Be aware that it is 43MB in size.

This version is spoken by actors, although the script
is Rob's.

The other Blit video is in Betacam format, and we don't
currently have a player for it, so it's not digitized.
I think it's silent, and presumably Rob talked during its
showing.  This might be what accompanied the Usenix talk.

(By the way, there are two other, twice-as large
videos there: the Labscam tape, and Rob's appearance
on the David Letterman TV show with Penn and Teller.)

	Dennis



From emu at ecubics.com  Tue Oct 22 05:01:27 2002
From: emu at ecubics.com (emanuel stiebler)
Date: Mon, 21 Oct 2002 13:01:27 -0600
Subject: Blit, was: Re: [TUHS] re: Can someone advise me regarding a gui for UNIX
References: <90d5aca0a564f1de023fd38f32cd5dab@plan9.bell-labs.com>
Message-ID: <3DB44F07.68667FE4@ecubics.com>

Is there still enough information available (schematics, manuals, ...)
so an emulator could be written for it ?

cheers

Dennis Ritchie wrote:
> 
> Norman Wilson recalled
> 
>  >  22. Pike, R. "The Blit: A Multiplexed Graphics Terminal". _AT&T Bell
>  >  Laboratories Technical Journal 63_, 8 (Oct. 1984).
> 
>  > Rob described an earlier version of the Blit work in a USENIX talk
>  > at USENIX in January 1982 (Santa Monica CA).  So far as I know it
>  > was just a talk, no paper, though he showed a canned demo on video
>  > tape.
> 
> By coincidence, one of the two videos made about early Blit
> work is newly available in .mpg format: look near the
> bottom of Rob Pike's page under Movies:
> 
>   http://www.cs.bell-labs.com/who/rob/index.html
> 
> This was just now done by Gerard Holzmann.
>


From mike at ducky.net  Tue Oct 22 05:35:17 2002
From: mike at ducky.net (Mike Haertel)
Date: Mon, 21 Oct 2002 12:35:17 -0700 (PDT)
Subject: [TUHS] re: Can someone advise me regarding a gui for UNIX
In-Reply-To: <90d5aca0a564f1de023fd38f32cd5dab@plan9.bell-labs.com>
Message-ID: <200210211935.g9LJZHKh013011@ducky.net>

 >  22. Pike, R. "The Blit: A Multiplexed Graphics Terminal". _AT&T Bell
 >  Laboratories Technical Journal 63_, 8 (Oct. 1984).

The thing I miss most about the 5620 is Cargill's wonderful little
debugger "pi".  Does anyone know if it was ever ported to X, and
if so, is the source available?

I remain amazed that nobody at Bell Labs ever ported it to Plan 9,
although I suppose both the use of C++ and the completely new symbol
table format in Plan 9 executables would make that a challenge.


From dmr at plan9.bell-labs.com  Tue Oct 22 14:34:57 2002
From: dmr at plan9.bell-labs.com (Dennis Ritchie)
Date: Tue, 22 Oct 2002 00:34:57 -0400
Subject: [TUHS] re: C reference manual
Message-ID: <965a15b4baaf434571dab596f67fe412@plan9.bell-labs.com>

The original question (from Ian KIng) was
 > I'm looking for a copy of the C reference manual from some time between
 > the 6th Edition (1975) and the first version that came with 4.3BSD
 > (1986). 

Some offered pointers to the 6th edition version (which is around
both at TUHS and also on my own home page.)

Norman observed that the standard V7 tapes omitted
the C manual from the documentation set, because
of the publication of K&R 1.  However, it turns out
that in our own paper-published version of the 7th
edition, the then-current spec (very nearly
what became Appendix A of K&R 1) was indeed
printed.  Probably some of these manuals were distributed
to people who got the tapes at that point.

The printed 7th edition also included a 1-page "Recent Pages
to C" addendum, describing the enum type, and
also confirming that structure assignment plus passing
and receiving structures to functions (promised for the
future in K&R 1) were available.  At some point there
may have been an updated version of this--I don't have
it--confirming that the compiler now, indeed, treated
same-named members of different structures as distinct and
non-interfering.

I retyped this addendum, and it's now on my home page.

More lately, Aharon pointed out that SCO had offered
a (for-fee) fairly complete distribution of System III
under an Ancient Unix license, and was kind enough
to send it to me.  It includes (under the name c_man)
a version that looks to be just about the same as
the version with the internal 7th edition.
This also includes the "Recent Changes" as an addendum.
(Amusingly, the enum example switches a color in its
example: "winedark" to "puce".  I don't know who did this;
it could have been me!).

Another interesting complication I turned up in
investigating this is that Brian and I seem to have lost
the machine-readable source for the actual
Appendix A of K&R 1!  (The rest of the text is still
around).

But to turn back to the original question: aside
from the "Recent Changes" page, and perhaps
some tweaking of the table of supported machines
and perhaps a few other fairly minor things,
there wasn't any significantly differing local C Reference
Manual between 7th ed / K&R 1, up to the ANSI
1989 standard.  However, I should try to retrieve
what went into 4.3BSD-- I don't have a complete
copy of it.

	Dennis



From info at aarons-computer-training.com  Mon Oct 28 12:41:00 2002
From: info at aarons-computer-training.com (Quality Computer Training)
Date: Sun, 27 Oct 2002 20:41:00 -0600
Subject: [TUHS] Try Our New Demos
Message-ID: <200210280240.g9S2efn28317@minnie.tuhs.org>

You can now view the latest demos of our quality, fully-interactive
computer training products. Try our product for Free.

Microsoft Office, A+, i-Net+, MCP & hundreds more.

http://www.aarons-computer-training.com/demo_downloads.htm

Call us for an additional 10% off any order with this email.

Computer Training for Your Future - Success Guaranteed


