17 Dec
2015
17 Dec
'15
9:13 p.m.
Ok, not sure if anyone will want to do this but I've just compiled
ed.c from Unix v6 on Unix v5.
It's not much bigger than the assembled ed, with 1314 lines of C code
the compiled executable is only 6518 bytes vs 4292 for the original. I
was looking at the source code and didn't see anything that the v5 cc
couldn't handle. I trimmed the source a bit, there's a function at the
end called getpid() which is commented out.
The comment says:
/* Get process ID routine if system call is unavailable. */
but my version of v5 does have that system call so it's all good.
It's been run a few times and it seems to work just fine. It may even
have a few more features than the v5 ed, I'm not sure yet :)
Mark
19 Dec
19 Dec
8:27 a.m.
On Thu, 17 Dec 2015, Mark Longridge wrote:
It's not much bigger than the assembled ed, with
1314 lines of C code
the compiled executable is only 6518 bytes vs 4292 for the original. I
was looking at the source code and didn't see anything that the v5 cc
couldn't handle. I trimmed the source a bit, there's a function at the
end called getpid() which is commented out.
If your V5 has getpid(), then it's a... strange version...
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
2:34 p.m.
> I trimmed the source a bit, there's a
function at the
> end called getpid() which is commented out.
If your V5 has getpid(), then it's a... strange
version...
I went back to the original uv5swre.zip file which was what I started
with and had another look to be sure.
It's not listed on tuhs under v5 but if one looks at /lib/libc.a via
'ar t getpid.o' you can see the object file getpid.o
There's no other trace of getpid in v5 as it's not in the v5 manual
and there's no getpid.s in the disk image. I'm not sure if having
getpid in v5 is anomalous or not, perhaps you or someone else can
actually remember as I'm a johnny-come-lately to the party. There's
even some commands mentioned in the v4 manual that don't exist in the
v5 disk image.
It's possible that there's another Unix v5 that really doesn't have
it, perhaps an older one.
Mark
On 12/18/15, Dave Horsfall <dave(a)horsfall.org> wrote:
> On Thu, 17 Dec 2015, Mark Longridge wrote:
>
>> It's not much bigger than the assembled ed, with 1314 lines of C code
>> the compiled executable is only 6518 bytes vs 4292 for the original. I
>> was looking at the source code and didn't see anything that the v5 cc
>> couldn't handle. I trimmed the source a bit, there's a function at the
>> end called getpid() which is commented out.
>
If your V5 has getpid(), then it's a... strange
version...
>
> --
> Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
> suffer."
>
8:57 p.m.
Mark Longridge <cubexyz(a)gmail.com> writes:
Plus, you know, the syscall itself.
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/sys/ken/sys4.c
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/sys/ken/sysent.c
There are four (well, five with ctime) objects in libc.a with no
matching source file in /usr/source/s4: alloc, getpid, ladd, and
snstat. Also, mon and qsort have assembly versions in s3 and C
versions in s4, and ctime is in s3 despite the fact that almost
every other libc file is in s4.
jnc(a)mercury.lcs.mit.edu (Noel Chiappa)
writes:
getpid.o consists of two instructions: sys getpid; rts pc. So it
unconditionally returns whatever the syscall puts in r0.
Non-existent syscalls map to nosys, which sets u_error to 100
(so, in principle, it will return 100, but), which causes the
process to be sent a signal SIGSYS.
> I trimmed
the source a bit, there's a function at the
> end called getpid() which is commented out.
If your V5 has getpid(), then it's a...
strange version...
I went back to the original uv5swre.zip file which was what I started
with and had another look to be sure.
It's not listed on tuhs under v5 but if one looks at /lib/libc.a via
'ar t getpid.o' you can see the object file getpid.o From: Mark
Longridge <cubexyz(a)gmail.com>
if one looks at /lib/libc.a via 'ar t
getpid.o' you can see the object
file getpid.o
Library, schlibrary! The important question is 'is it in the kernel source'?
(Although now that I think about it, if the library routine tries to use a
non-existent system call, it should return an error. It would be interested
to disassemble the library routine, and see what it thinks it is doing.) 
10:18 p.m.
Mark Longridge scripsit:
There's no other trace of getpid in v5 as
it's not in the v5 manual
and there's no getpid.s in the disk image. I'm not sure if having
getpid in v5 is anomalous or not, perhaps you or someone else can
actually remember as I'm a johnny-come-lately to the party. There's
even some commands mentioned in the v4 manual that don't exist in the
v5 disk image.
The manuals were versioned, but the tapes were not: each tape represents
a snapshot of the research system on that particular day, so what you find
there isn't closely correlated with any manual version.
--
John Cowan http://www.ccil.org/~cowan cowan(a)ccil.org
Long-short-short, long-short-short / Dactyls in dimeter,
Verse form with choriambs / (Masculine rhyme):
One sentence (two stanzas) / Hexasyllabically
Challenges poets who / Don't have the time. --robison who's at texas dot
net
20 Dec
20 Dec
2:05 a.m.
Craig Lennox <clennox(a)cosmic.com> writes:
Can we at least tell which day?
Craig
Assuming the clocks were set correctly, then to the extent it's
relevant, it'd be the latest timestamp. In Dennis_V5, that is the
kernel (and specifically conf.c, low.s, and mch.s as the most
recently modified source files), on Mar 21 1975.
The next newest files are dump, restor, and (kernel source) rkf.s
and nami.c... but there's no associated object file or change to
lib2. The latest objects in lib1 and lib2 (and therefore
presumably the kernel) are:
lib1: sysent.o and sys4.o (Nov 21 1974) / maybe this change is getpid?
lib2: kl.o (Dec 2 1974)
12:36 a.m.
Right. Obviously Doug can supply the details, but I recall that around 1972
or so Dick Haight used to go over from Piscataway to Murray Hill to get a
new system, and there would be some sort of indication about whether it was
a good day or a bad day to make a tape.
--Marc
On Sat, Dec 19, 2015 at 9:18 AM, John Cowan <cowan(a)mercury.ccil.org> wrote:
Mark Longridge scripsit:
There's no other trace of getpid in v5 as
it's not in the v5 manual
and there's no getpid.s in the disk image. I'm not sure if having
getpid in v5 is anomalous or not, perhaps you or someone else can
actually remember as I'm a johnny-come-lately to the party. There's
even some commands mentioned in the v4 manual that don't exist in the
v5 disk image.
The manuals were versioned, but the tapes were not: each tape represents
a snapshot of the research system on that particular day, so what you find
there isn't closely correlated with any manual version.
--
John Cowan http://www.ccil.org/~cowan cowan(a)ccil.org
Long-short-short, long-short-short / Dactyls in dimeter,
Verse form with choriambs / (Masculine rhyme):
One sentence (two stanzas) / Hexasyllabically
Challenges poets who / Don't have the time. --robison who's at texas
dot net
3290
days inactive
3292
days old
7 comments
6 participants
participants (6)
-
Craig Lennox -
Dave Horsfall -
John Cowan -
Marc Rochkind -
Mark Longridge -
Random832