I'm sorry if this has been done before, but I could find no indication
this was the case in the unix archive itself or in any of the months I
checked in the mailing list.
I have figured out what the first 50176 bytes of s1-bits are.
It is an "INIT Tape" as described in Dennis_v1 Boot Procedures(VII) and
Dennis_v3 bproc.8. It is apparently contemporary with s2 [all of the
files on it /etc/getty /bin/ls and so on match up exactly with their
counterparts on s2], and this would seem to make s2 the "/bin-/etc-/lib
tape" described in bproc.8.
Also - is there any other known copy of the "bos" bootloader? I'm
partway through hand-disassembling the one on the tape.
Anyone know how to get SIMH to send ^J for return?
Anyway - with the KE-11A enabled you need to use "d system sr" to set
the switch register [which must be set to 1 to cold boot, 73700 to come
up in single user mode, and any random value other than the special ones
0 57500 10 20 40 1 2 to come up normally]
The RF disk is not even large enough to contain the whole s2 tape, and
while even v1 supported mountable filesystems, there is no mkfs or mount
on the tapes.
I was looking at several NetBSD manual pages and saw that some HISTORY
sections had wrong .Bx or BSD reference like:
HISTORY
The xstr command appeared in 3.0BSD.
I looked at a few and saw this was in 4.4BSD manual pages. By the way,
when were these history sections added? (They aren't in 4.2BSD manual
pages. I should look at 4.3 before asking ...)
I didn't see any that refered to original Berkeley UNIX Software Tape
nor 2BSD.
But from looking at the 1BSD and 2BSD, I see:
apropos was in 2bsd
colcrt was in 1bsd but not in 2bsd
even though 2BSD iul, soelim, and ssp manuals referenced it
(why missing from 2BSD?)
colrm was in 1bsd but not in 2bsd
csh was in 2bsd (even 1bsd referenced the upcoming "csh")
ctags was in 2bsd, but as a shell script using ed
expand was in 1bsd and 2bsd
finger was in 2bsd
fmt was in 2bsd
from was in 2bsd
head was in 1bsd and 2bsd
lock was in 2bsd
last was in 1bsd and 2bsd
mkstr was in 1bsd and 2bsd
msgs was in 2bsd
printenv was in 2bsd
soelim was in first BSD and 2BSD
tset was in 1bsd and 2bsd
w was in 2bsd as finger -sf
whatis was in 2bsd
whereis was in 2bsd
xstr was in 2bsd
lastlog file format was in 1bsd and 2bsd (?? maybe different format??)
Any comments on the above?
Or is this simply because "2BSD" is not a operating system release per
se, so "3.0BSD" is correct?
But this makes me wonder if my 2BSD versions are newer than first
2BSD, so really 3BSD is correct for some of this.
I was going to ask a NetBSD list about this to fix these histories, but
decided to consult TUHS instead. Okay to change history to fix history?
:)
I don't know if this is interesting to anyone, but I thought I'd share that
386BSD will install on Bochs (although slowly, and it's prone to crashing),
however once the first patchkit is installed, it'll then run on Qemu!
(0.11.0, it seems the new bios layout of 0.12 is incompatible)
If anyone is interested, here is a link to a hard disk image that I've
prepared for Qemu:
http://vpsland.superglobalmegacorp.com/install/386BSD/bsd386.qcow2.gz
I run it like this:
qemu.exe -L pc-bios -hda bsd386.qcow2 -M isapc -net nic -net user -no-reboot
-m 256
And I can run lynx/irc as a test of the TCP/IP.
At any rate, I figure this kind of brings 386BSD back out of it's grave.
Is anything likely to happen to the status of various historical
Unices? Is Novell likely to keep the Ancient Unix license intact or
are they likely to lock things back up? Is there any chance that
SysIII and early SysV might finally get opened up? Does anybody have
any ideas here?
Mike
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
Hi, doesn't anybody know if there is a disk size limit on Unix 6? I wrote a
C program to create a file and it won't go above around 1.5Mb. It doesn't
crash or report any errors but the file size never exceeds around that size.
Maybe it's a disk size limitation?
Also, is it possible to add other devices? like using an ISO file perhaps.
Regards,
Andrew.
On Thu, Apr 8, 2010 at 7:40 PM, John Holden <johnh(a)psych.usyd.edu.au> wrote:
>
>> Well I found the ar specification (in ar.5 not ar.1).
>>
>> struct ar_hdr {
>> char ar_name[14];
>> long ar_date;
>> char ar_uid;
>> char ar_gid;
>> int ar_mode;
>> long ar_size;
>> };
>
> Endian should not be a problem on a Intel/AMD processor. More likely your C
> compiler is padding out the array for alignment. Try a '-fpack-struct' or
> more safely, read the elements individually rather than a structure.
>
In the PDP-11 long is 32 bits, int 16 bits. And the PDP-11 is
determinedly little-endian if you stick to integers.
They got floating-point software right in 1971, but somebody screwed
up the word order when building FP hardware, which led to the
middle-endian mess.
carl
--
carl lowenstein marine physical lab u.c. san diego
clowenstein(a)ucsd.edu
> Well I found the ar specification (in ar.5 not ar.1).
>
> struct ar_hdr {
> char ar_name[14];
> long ar_date;
> char ar_uid;
> char ar_gid;
> int ar_mode;
> long ar_size;
> };
Endian should not be a problem on a Intel/AMD processor. More likely your C
compiler is padding out the array for alignment. Try a '-fpack-struct' or
more safely, read the elements individually rather than a structure.
PS
To check, see what 'sizeof (struct ar_hdr_)' returns.
John
Bob Eager:
The 'ar' format of that vintage is trivial, and documentation easily
found. I wrote programs to read it back in 1976!
======
That's nothing. Either Ken or Dennis wrote such a program
years before that!
Warren even has a binary somewhere to prove it!
Seriously, it's a binary format, so I don't know that
it would be easy to process in awk. (At least not in
awk-classic; stuff that works only in ghootandwaveawk
is not all that interesting to me.) But the format is
simple, and any language new or old that can handle
binary data without tears should do.
If I didn't have an overfull plate already (and a
visit to the Auto-Electrocution Consultant tomorrow,
and one to the Canal Rooting Clinic Monday--proving
that one should follow Father's advice and Stay Away
>From The Canal, Neddie) it would be interesting to
collect the different specifications for ar headers
over the years, and write a small suite of programs
to read them. Perhaps in Python, just to be difficult.
(Why isn't there a language called Goon, Warren?)
Norman Wilson
Toronto ON
(owwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww)
On Thu, 8 Apr 2010, Michael Davidson wrote:
> Your modern compiler is almost certainly inserting two bytes of padding
> after ar_name[]
> so that the int32_t ar_date is aligned on a 4 byte boundary - that shifts
> everything else
> down by 2 bytes and means that ar_size lines up with the last 2 bytes of the
> size in
> the header which, as luck would have it, is the low order 16 bits of the
> size as it would
> have been stored in a 32 bit long.
>
> Something like this should work on a modern little endian processor"
>
> struct {
> char ar_name[14];
> int16_t ar_date_16_31;
> int16_t ar_date_00_15;
> char ar_uid;
> char ar_gid;
> uint16_t ar_mode;
> uint16_t ar_size_16_31;
> uint16_t ar_size_00_15;
> } ar_buf;
Thank you! That works for me! I can now get correct sizes, names, and
data. I will clean up my little ar extractor over the next few days and
share it.
I want to look in some .a files identified by file(1) as "old PDP-11
archive".
Anyone know what tool I can use on a modern *BSD or Linux system to
extract the files from an "old PDP-11" ar archive?
GNU ar complains "File format not recognized". ar tells me:
ar: supported targets: elf64-x86-64 elf32-i386 a.out-i386-netbsd
coff-i386 efi-app-ia32 elf64-little elf64-big elf32-little elf32-big
srec symbolsrec tekhex binary ihex netbsd-core
But I have no idea how to try different targets. The GNU ar manual page
doesn't tell me much.
Or how can I use modern pcc or gcc to compile old pre-ansi ar.c?
Any suggestions?
Now I found a simtools.zip via http://simh.trailing-edge.com/ which is
"a collection of tools for manipulating simulator file formats and for
cross-assembling code for the PDP-1, PDP-7, PDP-8, and PDP-11." But I am
not sure if this is related. On that note, any ideas how to extract
files from a ".tap" file used by simh? (For now I use view or strings to
look at it.)
Thanks,
Jeremy C. Reed
echo 'EhZ[h ^jjf0%%h[[Zc[Z_W$d[j%Xeeai%ZW[ced#]dk#f[d]k_d%' | \
tr '#-~' '\-.-{'
I forgot to mention that I had a friend help me out, and he got SYSIII
running on SIMH.......!
I don't know if there would be any interest in this... I don't have a good
layout of 'steps' as it was so... chained from 32v, and from within itself
as it can't boot from the tape..
But I can supply a working disk image to anyone that wants it... or should I
send it to Warren 1st, and he can send it to all the ancient/sysv licenses?
sorry if i'm not all that coherent.
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
Several people have noticed that the web archive for the TUHS mailing list
had stopped at June 2009, which was when I migrated over to another box.
Looks like I had a perms problem, which should be now fixed, but this e-mail
is just to test that it is indeed fixed. Please ignore, and/or browse the
old mail at http://minnie.tuhs.org/pipermail/tuhs/ :-)
Cheers,
Warren
Is anything likely to happen to the status of various historical
Unices? Is Novell likely to keep the Ancient Unix license intact or
are they likely to lock things back up? Is there any chance that
SysIII and early SysV might finally get opened up? Does anybody have
any ideas here?
Mike
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
I was idly going through the 1999 Swartz memo
(http://www.groklaw.net/pdf/Swartz.pdf) wherein the source code of
RedHat 5.2 and UnixWare are compared for similarities. Most of those
are either bogus (just some #includes) or BSD-derived code. There is
one file which is concerning: drand48.c. The RedHat 5.2 file is very
similar to the UnixWare file, including headers and #ifdef's e.g.
/* @(#)drand48.c 2.2 */
/*LINTLIBRARY*/
/*
* drand48, etc. pseudo-random number generator
* This implementation assumes unsigned short integers of at least
* 16 bits, long integers of at least 32 bits, and ignores
* overflows on adding or multiplying two unsigned integers.
* Two's-complement representation is assumed in a few places.
* Some extra masking is done if unsigneds are exactly 16 bits
* or longs are exactly 32 bits, but so what?
* An assembly-language implementation would run significantly faster.
*/
#include <stdlib.h>
#ifndef HAVEFP
#define HAVEFP 1
#endif
As far as I can determine, drand48() arrived in SysVR1 and is defined
in the first SVID. It doesn't appear in SysIII, nor in the early BSDs.
Can anybody shed some light on drand48()? Could it have been written
elsewhere and made available e.g on a Usenix tape or comp.sources.*,
and included into SysV, or is SysV the origin of the code?
I'm sure the algorithm comes from elsewhere, e.g. Knuth, but the
strong code similarity is a worry.
Thanks,
Warren
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
Hi,
has someone ever tried to grab the old BSD sources where TCP/IP showed up
first and tried to use them to implement TCP/IP support for an old SYSIII
UNIX (ZEUS comp.)?
I tried this but I got scared by so much things which would need to be
done, inter-process communication, pseudo terminal support are just the
"starting points" and at the end it is also the kinda old C compiler
which has problems with the BSD sources (#defs to long for the cpp for
example)...
Has someone experience with this kind of topic?
--
Oliver Lehmann
http://www.pofo.de/http://wishlist.ans-netz.de/
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
All, I've spent a bit of time re-writing my "Unix Tree" website, where
you can browse the source code trees and compare related files. The
file comparison now uses colour to show similar lines.
The initial version is at http://minnie.tuhs.org/cgi-bin/utree.pl
but I will probably move the URL at some point.
Have a look and see what you think. I would gladly accept suggestions on
better or more accurate descriptions for each of the releases, also checking
of dates and other information.
Cheers,
Warren
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
Do repositories of MNOS and DEMOS operating system source
code or binaries exist? Do either of these run on simh
or other simulators? (were the PDP11 and VAX11 knockoffs
close enough matches to the originals?)
Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
Cool just downloaded it.... seems whoever put it together really liked
gzip... ;)
On Sun, Mar 7, 2010 at 7:26 PM, Warren Toomey <wkt(a)tuhs.org> wrote:
> http://minnie.tuhs.org/Z/demos.tar.gz
>
> Let me know when you got it.
> Warren
>
Yeah, that'd be great! I've heard it's v6 with lots of bsd.. But it'd be cool to look at it!
-- Sent from my Palm Prē
On Mar 7, 2010 7:23 PM, Warren Toomey <wkt(a)tuhs.org> wrote:
On Sun, Mar 07, 2010 at 07:06:28PM -0500, Jason Stevens wrote:
> Seems to not include full source... I haven't gotten SIMH to boot the thing,
> nor some of the... "interesting" Russian PDP-11 emulators.. I ran strings
> through the disks, and I got some basic header files, oddly all in English,
> but no kernel or system source code, just some Fortran example....
> I'll have to ask someone in Russia if they have any real solid leads on
> DEMOS... It seems that once the Soviet Union fell, everyone abandoned DEMOS
> for any of the BSD's...
I can put up a tarball of the stuff I have for you, if you want.
Warren
I hate to say it but the demos stuff I found here
http://pdp-11.ru/mybk/pdp11/DEMOS.RAR
Seems to not include full source... I haven't gotten SIMH to boot the thing,
nor some of the... "interesting" Russian PDP-11 emulators.. I ran strings
through the disks, and I got some basic header files, oddly all in English,
but no kernel or system source code, just some Fortran example....
I'll have to ask someone in Russia if they have any real solid leads on
DEMOS... It seems that once the Soviet Union fell, everyone abandoned DEMOS
for any of the BSD's...
On Sun, Mar 7, 2010 at 5:00 PM, Warren Toomey <wkt(a)tuhs.org> wrote:
> On Sun, Mar 07, 2010 at 12:17:26PM -0500, Jason Stevens wrote:
> > I found some disk images online that say it's for the PDP-11 version...
> let
> > me see what I can pull from them for you.
> > The UWISC stuff is here:
> > http://minnie.tuhs.org/Archive/4BSD/Distributions/thirdparty/UWisc4.3/
>
> Thanks Jason!
> Warren
>
I found some disk images online that say it's for the PDP-11 version... let
me see what I can pull from them for you.
The UWISC stuff is here:
http://minnie.tuhs.org/Archive/4BSD/Distributions/thirdparty/UWisc4.3/
<http://minnie.tuhs.org/Archive/4BSD/Distributions/thirdparty/UWisc4.3/>
On Sun, Mar 7, 2010 at 8:47 AM, Warren Toomey <wkt(a)tuhs.org> wrote:
> On Sat, Mar 06, 2010 at 09:30:42PM -0500, Jason Stevens wrote:
> > I'd probably ask about that 4.3 Uwisc the wisconson one with the SUN NFS
> > stuff... and maybe the soviet DEMOS stuff...?
>
> Do you have the demos stuff? I have a pile of files, but it's all a jumble.
> If you have it, could you sit down a create a sensible tree of text-only
> files (i.e. no binary files) which I could add to the Unix Tree?
>
> I'll see if I have 4.3 Uwisc here too.
>
> Thanks,
> Warren
>
Hi, all!
Once, I was dismantling very old very long dead rusty box, which once
ran some version of SCO UNIX.
And I've got a strange device I've seen nowhere else - floppy-attached
tape drive, labelled Irwin, model 285. Drive looks
OK visually, motor wiring is perfect, so I can't see why it won't work.
I tried to make it run with old and new versions of Linux, but failed.
Do anybody have any documentation
regarding this?
Also - how wide these devices were used? I've never met one before
while I can't say I have little IT experience.
All the best,
S.
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
I don't know where the Groklaw posting came from,
but the info is garbled in two ways:
1. It's not E_GREG, any more than it was ever E_NXIO
or E_IO or E_ACCES. It's EGREG.
2. The associated message is not and never was Greg
did it but It's all Greg's fault.
The Greg in question is indeed Greg Chesson; the saying
was part of the culture when I arrived in 1127 in 1984.
I knew the story once but have forgotten.
EGREG was put into the system initially half as a joke,
half as a spare error code for debugging kernel code.
Then, as I vaguely recall, Andrew Hume started using it
for real in his WORM-device driver, rather than inventing
a new code if he really needed it. This is how software
grows and why it must be pruned, or even razed to the
ground, now and then.
The phrase It's all so-and-so's fault, and variations
on that theme, appeared now and then in other ways in
the culture. My favourite was when Tom Duff augmented
the simple code (just a shell script, I think) that
sent printer-status warnings to the UNIX Room voice
synthesizer so that it didn't just say Please add paper,
it said Please add paper, dammit t d (if the current job
was td's). Except that for a while, for reasons that
now escape me, it was deliberatly changed to say dammit
andrew (Hume) no matter who's stuff was printing. It
took a week or two before Andrew noticed.
It was a kindergarten there, but a fun and productive one.
I don't miss living in northern New Jersey (which is why
I left the group in 1990) but I do miss the group as it
then was, and no longer is nor ever again shall be.
Norman Wilson
Toronto ON
(Actually typing this whilst sitting
somewhere northeast of Emeryville CA)
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
I just saw this on Groklaw:
There were not many machines which ran Version 10. They were all
at Murray Hill and some of them were donated to Auburn University
when AT&T closed up shop. We got some old MicroVAX machines and
a couple of printed manuals. One of the printed manuals lists
various error codes. One of them is
E_GREG Greg did it.
Poor Greg. who was he, really?
Anybody know the answer? Norman?
P.S Merry Xmas to all.
Cheers,
Warren
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
