> On Tue, Nov 28, 2017 at 2:36 PM, Paul Winalski <paul.winalski(a)gmail.com>
> wrote:
>
>> MS/DOS patterned its command line
>>
>> syntax after RT-11 and inherited the slash as a command option
>> introduction from there.
>
> Minor correction... To do a CDC style patient zero history ;-) RT11 took
> it from DOS/8, CP/M took it from RT11, then finally DOS-86 which became
> PC-DOS ney MS/DOS took it from CP/M.
I think Gary Kildall was very much into the PDP-8 when teaching at the
Naval Post Graduate School in the early 70's (doing the FORTRAN/8 compiler
for instance). Can't find the link now, but I read somewhere that his
work with the 8008 and 8080 was guided by the idea of having a PDP-8 like
machine in his home office. For CP/M's command syntax RT11 probably did
not come into it. I just had a quick glance through the CP/M 1.4 - 2.2
manuals, and I did not see slash options (or any other option character).
Microsoft bought QDOS as a base for PC-DOS/MS-DOS. The QDOS system calls
were done such that converting existing 8080 CP/M code with Intel's source
level 8080-to-8086 asm converter would generate the correct code. The FAT
file system was modeled after the one used by MS Disk BASIC for the 8086.
Not sure where the QDOS command line came from, other than CP/M. MS did a
lot of its early development on a PDP-10: perhaps that was an inspiration
too.
Sorry for getting off-Unix-topic...
> From: Doug McIlroy
> But if that had been in D space, it couldn't have been executed.
Along those lines, I was wondering about modern OS's, which I gather for
security reasons prevent execution of data, and prevent writing to code.
Programs which emit these little 'custom code fragments' (I prefer that term,
since they aren't really 'self-modifying code' - which I define as 'a program
which _changes_ _existing_ instructions) must have some way of having a chunk
of memory into which they can write, but which can also be executed.
> Where is the boundary between changing one instruction and changing them
> all? Or is this boundary a figment of imagination?
Well, the exec() call only overwrites existing instruction memory because of
the semantics of process address space in Unix - there's only one, so it has
to be over-written. An OS operating in a large segmented single-level memory
could implement an exec() as a jump....
BTW, note that although exec() in a single address-space OS is conventionally
something the OS does, this functionality _could_ be moved into the user
space, provided the right address space primitives were provided by the OS,
e.g. 'expand instruction space'. So the exec() code in user space would i)
find the executable, ii) see how much of each kind of memory it needs, iii)
get the OS to give it a block of memory/address space where the exec() code
can live while it's reading in the new code, iv) move itself there, v) use
standard read() calls to read the new image in, and then vi) jump to it.
Yes, it's probably simpler to implement it in the OS, but if one's goal is to
minimize the functionality in the kernel...
Noel
In case you missed it:
https://www.spectrum.ieee.org/view-from-the-valley/tech-history/silicon-rev…
It is important to keep the conversations alive and not to file your
memory boxes away in the attic. Thanks for sharing what you know and
especially for making your documents and bits available.
-will
--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
OK, we were discussing terminals this morning with some other old guys. If
I knew the answer to this I've forgotten.
Every PDP-11 UNIX I ever used had the console KL-11 as /dev/tty8. The
question is why. My guess is that for some reason
an 8 terminal multiplexor (DZ-11?) was stuck at tty0, but why?
> From: Larry McVoy
>> they aren't really 'self-modifying code' - which I define as 'a program
>> which _changes_ _existing_ instructions
> Isn't that how dtrace works?
I'm not familiar with dtrace(), but if it modifies some other routine's code,
then it would not be "self" modifying, right?
Oh, another category, sort of like biological viruses (which are in a grey
zone between 'alive' and not): the PDP-11 paper tape bootstrap:
http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/bootloader.mac
in which the program's own code _is_ modified - but not by program
instructions, but by data on the paper tape it is reading in. It's
entertainingly convoluted (the copy above should be well-enough commented to
make it pretty easy to understand what's going on).
Noel
We lost J.F. Ossanna on this day in 1977; he had a hand in developing
Unix, and was responsible for "roff" and its descendants. Remember him,
the next time you see "jfo" in Unix documentation.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
> From: Kevin Bowling
> The earliest stuff may be covered by Novell's grant of early code.
> ...
> Would be fun to run *ix on any of them.
Alas, the Bell port of Unix to the /370 needs that underlying layer of code
from IBM, and that's probably not going to escape. Too bad, it would be pretty
cool.
Noel
I am curious about how the Harvard Architecture relates to Unix,
historically. If the Harvard Architecture is predicated on the
separation of code from data in order to prevent self-modifying code (my
interpretation), then it would seem to me to be somewhat at odds with a
Unix philosophy of extreme abstraction (code, data, it's all 0's and
1's, after all). In my naive understanding, the PDP-11 itself, with the
Unibus and apparently agnostic ISA seem to summarily reject the Harvard
Architecure...
My question is - was there tension around Harvard and Von Neumann
architectures in Unix circles and if so, how was it resolved?
Thanks,
Will
--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
There are some little bits in the public V7 source code that
suggest that it had support for Datakit, but that it was scrubbed
from the public release:
There is a Datakit header file:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/include/dk.h
and Datakit state bits are defined in 'sys/tty.h':
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/include/sys/tty.h
Does anyone know if this assumption (Datakit support in V7) is correct?
Perhaps more specific, was there a remote login program for V7/Datakit,
of for V6/Spider? For V8/Datakit there was 'dcon', but perhaps this
was built on earlier programs.
(I'm aware of 'cu' of course, but that does not support Datakit or
Spider).
Being able to login to another host on the network seems so useful
that it is hard to believe that a precursor to 'dcon' did not exist for
V6 and/or V7.
Thanks for explaining that. I think it may be for 10th edition though.
I searched for ipcopen() and 'gated' in the 8th edition source and could
not find them. In that search I did find a few bits that strongly suggest that
IP over Datakit was what was used in late '85 (when dmr posted about this).
In /usr/src/cmd/inet/READ_ME there is an example configuration that seems
to match with dmr's example. In that file an IP over a Datakit channel
appears to be configured.
(see http://chiselapp.com/user/pnr/repository/v8unix/artifact/6d09b05c7f06a2cc?l…)
The program 'dkipconfig' sets up a circuit and pushes the IP discipline on
the stream, both on the local end and on the remote end. It sets fixed local
and remote addresses, much the same as with a 'slip' line.
(see http://chiselapp.com/user/pnr/repository/v8unix/artifact/6c5f3267b58721a6?l…)
On Sat, Nov 25, 2017 at 4:50 PM, William Cheswick <ches at cheswick.com> wrote:
>
> Nope, not IP over Datakit, as I recall. It was quite interesting to work at
> a site (Bell Labs) where there were two distinct network technologies.
>
> [--snip--]
>
> This library was socks about seven years before socks, originally written by
> Presotto and Howard Trickey. The relay program was originally called
> “gated”, but that wouldn’t do after a while. I renamed it “proxyd”, and
> that is the first use of “proxy" in this context that I am aware of.
>
> If you were on AT&T’s intranet and wanted to connect externally, you ripped
> out the entire socket dance and replaced it with an ipcopen call. I also
> distributed common modified clients, like ptelnet, pftp, pfinger, etc.
>
> I still have all this code, and I suppose it ought to go in an archival
> repository. I can’t imagine that AT&T/Lucent/Alcatel/Nokia would care at
> this point. Anyone want it?
>
