The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: cubexyz@gmail.com (Mark Longridge)
Subject: [TUHS] changes for modern -> v7 -> v6 -> v5
Date: Sun, 3 Aug 2014 16:55:59 -0400	[thread overview]
Message-ID: <CADxT5N6veRAk8VSVbpPQaFbc=4VJacsPtj6EANA6=Brdr5s2Dw@mail.gmail.com> (raw)

    >> From: Mark Longridge <cubexyz at gmail.com>

    >> I thought you folks might be interested in looking at the changes I had
    >> to make. It was a bit harder than the port to v6 but porting to v6
    >> first did make things a bit easier.

> To save me from poring over 'diff' output :-), what (at a high level) were
> the changes you had to make to get it to run on v5?

 >       Noel

Briefly the differences were these:

modern to v7: remove all references to void
no vi on v7, v6, and v5 so using ed instead.
no conditional compilation so no way to make a truly universal version
which works on everything.

v7 to v6: use iolib instead of stdio: fopen -> copen, fclose ->
cclose, fgetc -> cgetc, fputc -> cputc
use int (no long or short in v6)
call to srand uses different argument
copen returns an int instead of a file pointer
no strcat in v6 so the function had to be added

v6 to v5: no iolib: fopen -> creat + open, copen -> open, cgetc ->
read, cputc -> write, cclose -> close
no scanf in v5 so I used the source for gets from v7 instead
getchar()  leaves a newline in the buffer so I added an extra call to
getchar() immediately before each call to gets

The size of the unirubik executable was 8K for modern Linux, 10K for
v7, 10K for v6, and 5492 bytes for v5.

Generally I was a lot slower trying to edit files with ed rather than
vi but I'm a lot better with ed now. There wasn't really much unix v5
code to look at and I found the v5 manual a bit spartan.

Mark



             reply	other threads:[~2014-08-03 20:55 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-03 20:55 Mark Longridge [this message]
2014-08-04  2:06 ` John Cowan
2014-08-05 15:24 ` Clem Cole

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CADxT5N6veRAk8VSVbpPQaFbc=4VJacsPtj6EANA6=Brdr5s2Dw@mail.gmail.com' \
    --to=cubexyz@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).