The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] v7, adb, and fcreat
@ 2020-08-06  4:49 Will Senn
  2020-08-06  5:00 ` John Cowan
  0 siblings, 1 reply; 6+ messages in thread
From: Will Senn @ 2020-08-06  4:49 UTC (permalink / raw)
  To: TUHS main list

[-- 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 --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [TUHS] v7, adb, and fcreat
  2020-08-06  4:49 [TUHS] v7, adb, and fcreat Will Senn
@ 2020-08-06  5:00 ` John Cowan
  2020-08-06 12:15   ` Will Senn
  0 siblings, 1 reply; 6+ messages in thread
From: John Cowan @ 2020-08-06  5:00 UTC (permalink / raw)
  To: Will Senn; +Cc: TUHS main list

[-- 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 --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [TUHS] v7, adb, and fcreat
  2020-08-06  5:00 ` John Cowan
@ 2020-08-06 12:15   ` Will Senn
  0 siblings, 0 replies; 6+ messages in thread
From: Will Senn @ 2020-08-06 12:15 UTC (permalink / raw)
  To: John Cowan; +Cc: TUHS main list

[-- 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 --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [TUHS] v7, adb, and fcreat
@ 2020-08-06 19:25 Noel Chiappa
  0 siblings, 0 replies; 6+ messages in thread
From: Noel Chiappa @ 2020-08-06 19:25 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > 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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [TUHS] v7, adb, and fcreat
  2020-08-06 16:55 Noel Chiappa
@ 2020-08-06 18:36 ` Will Senn
  0 siblings, 0 replies; 6+ messages in thread
From: Will Senn @ 2020-08-06 18:36 UTC (permalink / raw)
  To: Noel Chiappa, tuhs

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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [TUHS] v7, adb, and fcreat
@ 2020-08-06 16:55 Noel Chiappa
  2020-08-06 18:36 ` Will Senn
  0 siblings, 1 reply; 6+ messages in thread
From: Noel Chiappa @ 2020-08-06 16:55 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > 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

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2020-08-06 19:26 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-06  4:49 [TUHS] v7, adb, and fcreat Will Senn
2020-08-06  5:00 ` John Cowan
2020-08-06 12:15   ` Will Senn
2020-08-06 16:55 Noel Chiappa
2020-08-06 18:36 ` Will Senn
2020-08-06 19:25 Noel Chiappa

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).