Re: [TUHS] v7, adb, and fcreat

Re: [TUHS] v7, adb, and fcreat

[Noel Chiappa]

    > From: Will Senn

    > I don't think adb was in v6, where the fcreat function and buf struct
    > are used... Were Maranzano and Bourne using some kind of hybrid 6+ system?

In addition to the point about skew between the released and internal development,
it's worth remembering just how long it was between the V6 and V7 releases, and
how much ground was covered technically during that period.

A lot of that stuff leaked out: we've talked about the upgraded 'Typesetter C'
(and compilers), which a lot of people had, and the V6+ system at MIT
(partially sort of PWB1) had both 'adb' and the stdio library. The latter also
made its way to lots of places; in my 'improved V6 page':

  http://www.chiappa.net/~jnc/tech/ImprovingV6.html

it talks about finding the standard I/O stuff in several later V6 repositories,
including a UNSW tape. But it and typsetter C, also on the Shoppa pack, were
clearly quite widespread.

	Noel

Re: [TUHS] v7, adb, and fcreat

[Will Senn]

Noel,

Funny how some things take a while to sink in. I've been messing around 
with my v6 instance for so long now, that I got to thinking it was v6 
:). Sheesh, between you and Clem clueing me in, it finally clicked that 
it is just one (of many) bit buckets out there with the moniker v6.

What confused me initially was that these were built from tapes - never 
mind that the tapes aren't gold standards, it never occurred to me that 
they weren't. I am coming from a world where OS version floppy/cd/dvd 
images are copies of a single master (or very small set of masters). 
Sure, there are OEM disks out there, but for the most part, if I say, 
grab OS X 10.14 and burn it, I'll get the same OS X 10.14 as pretty much 
everybody everywhere. These tape things could be snapshots of the 
systems they originate from at very different times and with different 
software/sources etc. I know I'm basically repeating what y'all said, 
but I'm still in shock :).

Will

On 8/6/20 11:55 AM, Noel Chiappa wrote:
>      > From: Will Senn
>
>      > I don't think adb was in v6, where the fcreat function and buf struct
>      > are used... Were Maranzano and Bourne using some kind of hybrid 6+ system?
>
> In addition to the point about skew between the released and internal development,
> it's worth remembering just how long it was between the V6 and V7 releases, and
> how much ground was covered technically during that period.
>
> A lot of that stuff leaked out: we've talked about the upgraded 'Typesetter C'
> (and compilers), which a lot of people had, and the V6+ system at MIT
> (partially sort of PWB1) had both 'adb' and the stdio library. The latter also
> made its way to lots of places; in my 'improved V6 page':
>
>    http://www.chiappa.net/~jnc/tech/ImprovingV6.html
>
> it talks about finding the standard I/O stuff in several later V6 repositories,
> including a UNSW tape. But it and typsetter C, also on the Shoppa pack, were
> clearly quite widespread.
>
> 	Noel


-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF

Re: [TUHS] v7, adb, and fcreat

[Noel Chiappa]

    > From: Will Senn

    > it finally clicked that it is just one (of many) bit buckets out there
    > with the moniker v6. ... I am coming from a world where OS version
    > floppy/cd/dvd images are copies of a single master ... These tape things
    > could be snapshots of the systems they originate from at very different
    > times and with different software/sources etc.

Well, sort of. Do remember that everyone with V6 had to have a license, which
at that point you could _only_ get from Western Electric. So every
_institution_ (which is not the same as every _machine_) had had to have had
dealings with them. However, once your institution was 'in the club', stuff
just got passed around.

E.g. the BBN V6 system with TCP/IP:

  https://www.tuhs.org/cgi-bin/utree.pl?file=BBN-V6

I got that by driving over to BBN, and talking to Jack Haverty, and he gave us
a tape (or maybe a pack, I don't recall exactly). But we had a V6 license, so
we could do that.

But my particular machine, it worked just the way you described: we got our V6
from the other V6 machine in the Tech Sq building (RTS/DSSR), including not
only Bell post-V6 'leakage' like adb, but their local hacks (e.g. their TTY
driver, and the ttymod() system call to get to its extended features; the
ability to suspend selected applications; yadda, yadda). We never saw a V6
tape.

   Noel

[TUHS] v7, adb, and fcreat

[Will Senn]

[-- Attachment #1: Type: text/plain, Size: 1270 bytes --]

I've done research on this, but I'm confused and would appreciate some 
help to understand what's going on. In the 7th edition manual, vol 2, 
there's an ADB tutorial (pp. 323-336). In the tutorial, the authors, 
Maranzano and Bourne, walk the reader through a debugging session. The 
first example is predicated on a buffer overflow bug and the code includes:

struct buf {
int fildes;
int nleft;
char *nextp; char buff[512]; }bb;
struct buf *obuf;

...
if((fcreat(argv[1],obuf)) < 0){
...

Well, this isn't v7 code. As discussed in the v7 manual vol 1 (p. VII):

Standard I/O. The old fopen, getc, putc complex and the old –lp package 
are both dead, and even getchar has changed. All have been replaced by 
the clean, highly efficient, stdio(3) package. The first things to know 
are that getchar(3) returns the integer EOF (–1), which is not a 
possible byte value, on end of file, that 518-byte buffers are out, and 
that there is a defined FILE data type.

The buffers are out, fcreat is gone, etc. So, what's up with this? I 
don't think adb was in v6, where the fcreat function and buf struct are 
used... Were Maranzano and Bourne using some kind of hybrid 6+ system?

Thanks,

Will

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF


[-- Attachment #2: Type: text/html, Size: 1791 bytes --]

Re: [TUHS] v7, adb, and fcreat

[John Cowan]

[-- Attachment #1: Type: text/plain, Size: 1639 bytes --]

The manual came out in editions, but the code, man pages, etc. changed
continuously.  So what you hear about in a particular paper is not
necessarily correlated with a particular state of the manual.

On Thu, Aug 6, 2020 at 12:49 AM Will Senn <will.senn@gmail.com> wrote:

> I've done research on this, but I'm confused and would appreciate some
> help to understand what's going on. In the 7th edition manual, vol 2,
> there's an ADB tutorial (pp. 323-336). In the tutorial, the authors,
> Maranzano and Bourne, walk the reader through a debugging session. The
> first example is predicated on a buffer overflow bug and the code includes:
>
> struct buf {
> int fildes;
> int nleft;
> char *nextp; char buff[512]; }bb;
> struct buf *obuf;
>
> ...
> if((fcreat(argv[1],obuf)) < 0){
> ...
>
> Well, this isn't v7 code. As discussed in the v7 manual vol 1 (p. VII):
>
> Standard I/O. The old fopen, getc, putc complex and the old –lp package
> are both dead, and even getchar has changed. All have been replaced by the
> clean, highly efficient, stdio(3) package. The first things to know are
> that getchar(3) returns the integer EOF (–1), which is not a possible byte
> value, on end of file, that 518-byte buffers are out, and that there is a
> defined FILE data type.
>
> The buffers are out, fcreat is gone, etc. So, what's up with this? I don't
> think adb was in v6, where the fcreat function and buf struct are used...
> Were Maranzano and Bourne using some kind of hybrid 6+ system?
>
> Thanks,
>
> Will
>
> --
> GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF
>
>

[-- Attachment #2: Type: text/html, Size: 2303 bytes --]

Re: [TUHS] v7, adb, and fcreat

[Will Senn]

[-- Attachment #1: Type: text/plain, Size: 2040 bytes --]

Thanks, John. That is one concise answer that explains the problem quite 
well. Now that I think about it, it explains quite a bit about quite a 
bit :).

Will

On 8/6/20 12:00 AM, John Cowan wrote:
> The manual came out in editions, but the code, man pages, etc. changed 
> continuously.  So what you hear about in a particular paper is not 
> necessarily correlated with a particular state of the manual.
>
> On Thu, Aug 6, 2020 at 12:49 AM Will Senn <will.senn@gmail.com 
> <mailto:will.senn@gmail.com>> wrote:
>
>     I've done research on this, but I'm confused and would appreciate
>     some help to understand what's going on. In the 7th edition
>     manual, vol 2, there's an ADB tutorial (pp. 323-336). In the
>     tutorial, the authors, Maranzano and Bourne, walk the reader
>     through a debugging session. The first example is predicated on a
>     buffer overflow bug and the code includes:
>
>     struct buf {
>     int fildes;
>     int nleft;
>     char *nextp; char buff[512]; }bb;
>     struct buf *obuf;
>
>     ...
>     if((fcreat(argv[1],obuf)) < 0){
>     ...
>
>     Well, this isn't v7 code. As discussed in the v7 manual vol 1 (p.
>     VII):
>
>     Standard I/O. The old fopen, getc, putc complex and the old –lp
>     package are both dead, and even getchar has changed. All have been
>     replaced by the clean, highly efficient, stdio(3) package. The
>     first things to know are that getchar(3) returns the integer EOF
>     (–1), which is not a possible byte value, on end of file, that
>     518-byte buffers are out, and that there is a defined FILE data type.
>
>     The buffers are out, fcreat is gone, etc. So, what's up with this?
>     I don't think adb was in v6, where the fcreat function and buf
>     struct are used... Were Maranzano and Bourne using some kind of
>     hybrid 6+ system?
>
>     Thanks,
>
>     Will
>
>     -- 
>     GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF
>


-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF


[-- Attachment #2: Type: text/html, Size: 3456 bytes --]