Hi All.
I announceced this some years ago but it's been renewed, so I'll announce
it again.
In 2004 sometime I downloaded all the comp.sources stuff I could from
uunet.uu.net, which was still making it available for anonymous ftp.
I've made a tarball of it available from http://www.skeeve.com/Usenet.tar.bz2
Warren, if you don't have this in the TUHS archives, maybe you could add it?
Thanks,
Arnold
Hi,
For those who want to refresh old memories.
Hans Bezemer has made big progress as far as performance of qemu is
concerned. His specific experience concerns Coherent, but other old
unixes could use it.
Details can be found in comp.os.coherent news group
http://groups.google.com/group/comp.os.coherent/topics
The older tuhs message can be mentioned :
http://minnie.tuhs.org/pipermail/tuhs/2008-July/001815.html
I have also noticed , that Coherent boots well and is very fast in
newest virtualbox 4.1.8, running in XP.
Dell Optiplex 755 was used with Core 2 Duo.
Details can be found in forums for "Other quests"
http://www.virtualbox.org
It suggests , that other old Unixes could benefit in new virtualbox.
Regards
Andrzej
A long time ago at the University that I graduated from. . .
Shell scripts had just added the ability to have functions in them, so I wrote a script to do some processing of files that I had, and then logged off to let it run in the background.
The shell script was named 'A'.
In the script was a function, named 'A'
When the script ran, instead of calling 'A' the function, it called 'A' the script, and you can see where this goes from here.
2 days later I received an email from the admin (thankfully a friend) who enclosed the 'ps -axl' output from the machine. It showed thousands of copies of my script running and a load that indicated that the machine was useless for almost everything.
With the admonishment: "Don't ever do this again."
I haven't.
David
David Barto
barto(a)kdbarto.org
barto(a)ucsd.edu
On Mon, Dec 26, 2011 at 8:15 PM, Dave Horsfall <dave(a)horsfall.org> wrote:
> On Tue, 27 Dec 2011, Warren Toomey wrote:
>> Yes, a good reminder on the power that programming brings us. A question
>> though: what command would "bring the system down"?
>
> It's right here: "Programmers were free to poke around to see and directly
> manipulate what was in the computer's memory."
http://minnie.tuhs.org/pipermail/unix-jun72/2008-May/000250.html
> -- Dave
--
Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com
Hi,
I wonder if someone has an early version of top lying around? I'd
like to try getting it to work on my ZEUS clone. I'd start with
1.0 from 1984 if possible ;)
Regards, Oliver
Hi,
I'm trying to re-create the source files for the Z8000 UNIX I have
on my Z8000 system (it is a S8000+ZEUS clone).
Easy programs like sync.c where easy. But when argc/argv is involved,
I'm not able to generate 1:1 matching binary code.
I'm working on /etc/unlink for now.
I tried the following C file:
char whatstr[] = "@[$]unlink.c 2.1 07/23/82 21:19:30 - 87wega3.2";
main(argc, argv)
int argc;
char **argv;
{
if(argc!=2) {
write(2, "Usage: /etc/unlink name\n", 24);
exit(1);
}
unlink(argv[1]);
exit(0);
}
The original ASM code for the beginning of main() until the argc
check is:
0042 abf3 dec r15,#4
0044 5df60000 ldl %0000(r15),rr6
0048 0b070002 cp r7,#%0002
The ASM code my C file generates is:
0042 abf3 dec r15,#4
0044 1df6 ldl @r15,rr6
0046 0b070002 cp r7,#%0002
keep in mine, that r15 is considered as the "stack pointer".
I wonder how to get the ldl from the original binary.
I also tried to declare argv with "char *argv[]" which
resulted in the same code. Forcing the compiler to store
argv into a register by using the "register" keyword results
in completly different code:
(sp = stack pointer = r15)
#17 adb unlink
ADB: P8000 1.6
? 0x0042/i
%0042: dec sp,#6
?
%0044: ld %0004(sp),r14
?
%0048: ld %0002(sp),r7
?
%004c: ld r14,r6
?
%004e: cp r7,#%0002
? $q
#18
Maybe the C compiler used to compile /etc/unlink differs from
the C compiler shipped with the system (maybe an older version)
but I don't want this to be true for now ;)
Anyone with deeper ASM and C knowledge than me sees what could
be done here?
Before someone asks - yes I'm sure the source file was in C
and not ASM based on the whatstr. Symboltable of the original
/etc/unlink is empty as well (striped binary).
Regards, Oliver
Sven Mascheck:
With "original implementation (post 7th ed", I meant the undistributed
BellLabs-internal further development of 7th, the first system ever
to implement #!, leading to 8th ed, etc. (4BSD just incorporated this).
Not System V or other relatives, though.
=======
Can you cite a reference?
I'm quite familiar with what went on inside the system that was
later called 8th Edition, having been on the inside at Bell Labs
starting in mid-1984. But that was after the original research
group's general move to VAXes--they had no PDP-11s left by then,
except a few LSI-11s running special-purpose systems rather than
UNIX. In fact the VAX kernel they had adopted, I think sometime
earlier that year, was derived from that of 4.1 BSD. (It diverged
quite a bit from that start later, for which I am appreciably
to blame, but that has nothing to do with #!).
So if #! was implemented in an earlier kernel I don't know just
what was done. I'd assumed it was no different; if I'm
mistaken I'd love to see just how it really was.
Alas, the person I know was on the spot and was likely to
remember just what happened in what order can no longer answer
questions ...
Norman Wilson
Toronto ON
Sven Mascheck:
Well the original implementation (post 7th ed and 4.0/4.1 BSD)
didn't allow arguments at all ;-)
======
I believe you're mistaken. All the implementations I've
ever used allowed a single argument in the #! line,
and inserted the name of the script between that (if
present) and the arguments given to exec.
e.g. if ./lipsum began with
#!/usr/bin/awk -f
awk would be invoked with `/usr/bin/awk -f ./lipsum ...'.
Without allowing one argument for -f or the like,
#! wouldn't have been useful for much but the shell.
Norman Wilson
Toronto ON
Hi all, in the past few days I've been getting some
interesting e-mails from a new TUHS member,
Jonathan Gevaryahu. He has been searching for some
lost software, and his story of how he found it
is a good reminder to check through all the zeroes
and ones on the digital media at hand. With his
permission, I reproduce the e-mails below.
Cheers,
Warren
Hi, I'm Jonathan Gevaryahu, one of the developers of MESS but also a
speech synthesis history buff. I've been trying to find a copy of the
old unix 'speak' command source code and rule tables that M. D. Mcilroy
wrote back in 1974ish, but the TUHS archives only have the man pages
for it, and not the actual program or its tables.
As for the "why?" of this, its an important piece of history, and the
phoneme set used on the Federal Screw Works "VOTRAX" Model VS-4 unit
which was used with 'speak' at Bell Labs is compatible with the later
Votrax Model VS-6 unit at CHM, and also with the Votrax "SC-01" chip
used in some arcade/video games, several computer peripherals, and on
the "Type 'N' Talk" and "Personal Speech System" products. So actually
running the old code and having it speak should be quite doable, if we
can recover enough of it to be useful.
[ Jonathan assumed that the 'speak' source code had been lost. ]
I even asked Doug McIlroy about it a few years ago and he didn't have
a copy, and I had assumed it was just plain lost... Until today.
I was poking around in random TUHS files (after reading about
the v1 unix restoration project) and noticed that the size of
recovered files from the ritchie v6 tapes in the .tar.gz files
is actually significantly smaller than the tapes themselves. I
assumed there had to be some other data there, possibly corrupt or
fragmentary, and got down to peeking at the file contents themselves.
There were some mentions of speak.m and .c and .v, but finally, in
http://minnie.tuhs.org/Archive/PDP-11/Distributions/research/Dennis_v6/v6do…
I found the remains of the speak program. See
http://pastebin.com/FdvRYM2T for what I've managed to recover so far
(actually since i pasted that I recovered a good deal more of it, but
a lot is out of order and bits are missing) The file is fragmentary as
far as I can see, and is only speak.c (the .m file containing the rules
I haven't found yet, but since Doug has a scanned copy of the paper
describing speak on his website, hopefully I can just regenerate the
rule tables if needed), but it is there! Hopefully speak.m or .v are
still waiting to be found on that or one of the other tape images.
Also there are other things on that tape like the chess program, and
tic tac toe, which may not exist elsewhere. (Though, for these two I
honestly haven't checked)
Also, in the last 5 minutes I found a chunk of what I'm pretty sure is
either speak.m or speak.v, so there's more than just the .c file there.
Further progress attached of recovering speak from deleted disk pack
sectors: I have all of speak.c in order except for one 512-byte sector,
which was overwritten at some point, in the phoneme table. (This has to
be the least "damaging" sector of the entire program. lucky!) I also
have a good chunk (maybe 50-60%) of what may be a mix of speak.m and
speak.v, both out of order. I did not yet find
a copy of 'speakm', the rule displayer program for speak.m/.v. There is
a program, located after speak.c on the disk image, which looks like it
would convert numbers and months to their full speakable names.
In addition, either slightly more or slightly less of the files may be intact
on the
http://minnie.tuhs.org/Archive/PDP-11/Distributions/research/Ken_Wellsch_v6…
image, which appears to be originally an exact dd-copy of the dennis_v6
disk packs.
Ok, here's the 'repaired' speak.c file, with the missing entries of the
table filled in (this was IMMENSELY helped by the fact that speak.o, the
compiled object file, was also on the disk pack and appears to be fully
intact including the table; the ruleset files are fragmentary so far.)
