I've assembled some notes from old manuals and other sources
on the formats used for on-disk file systems through the
Additional notes, comments on style, and whatnot are welcome.
(It may be sensible to send anything in the last two categories
directly to me, rather than to the whole list.)
I have been doing some language exploration in v7/4.3bsd and came across
Software Tools (not the pascal version). It's written using ratfor,
which I had seen in the v7 UPM. I fired up v7 and tried my hand at the
# copy - copy input characters to output
while(getc(c) != EOF)
The first thing I noticed was that it read more like C than Fortran (I
know C quite well, Fortran just a smidge)... awesome, right? So I ran
the preprocessor on it and got the following f77 code:
c copy - copy input characters to output
23000 if(.not.(getc(c) .ne. eof))goto 23001
Cool. The way it translated the EOF test is weird, but ok. Trying to
compile it results in complaints about missing getc and putc:
$ f77 copy.f
Ah well, no worries. I know that they're in the c lib, but don't about
fortran libs... Meanwhile, over on 4.3BSD, it compiles without issue.
But running it is no joy:
This is a test
I remembered that the authors mentioned something about EOF, so I
tweaked the code (changed EOF to -1) and rebuilt/reran:
This is a test
This is a test
Fascinating. Dunno why no complaints from F77 about the undefined EOF
(or maybe mis-defined), but hey, it works and it's fun.
I'm curious how much ratfor was used in bell labs and other locations
running v6, v7, and the BSD's. When I first came across it, I was under
the impression that it was a wrapper to make f66 bearable, but the
manpage says it's best used with f77, so that's not quite right. As
someone coming from c, I totally appreciate what it does to make the
control structures I know and love available, but that wasn't the case
back then, was it? C was pretty new... Was it just a temporary fix to a
problem that just went away, or is there tons of ratfor out there in the
wild that I just haven't seen? I found ratfor77 and it runs just fine on
my mac with a few tweaks, so it's not dead:
ratfor77 -C copy.r | tee copy.f
C Output from Public domain Ratfor, version 1.0
C copy - copy input characters to output
23000 if(getc(c) .ne. eof)then
What's the story? Oh, and in v6 it looks like it was rc - ratfor
compiler, which is not present in v7 or 4.3BSD - is there a backstory
I'm reading in, Kernighan & Plauger's 1981 edition of Software Tools in
Pascal and in the book, the author's mention Bill Joy's Pascal and Andy
Tanenbaum's as being rock solid. So, a few related questions:
1. What edition of UNIX were they likely to be using?
2. What versions of "Standard Pascal" were in vogue on UNIX at the time
3. What combinations of UNIX/Pascal were popular?
Some of the folks here might like this FB group...
Internet Old Farts Club
> This group is for self-declared Internet Old Farts, who want to discuss any aspect of the the Internet or its history. People in this group had their bits walk up hill both ways.
> Welcome to the Internet Old Farts group.
The purpose of this group is both social and technical. Feel free to revisit the past, explore the future, grouse about technical problems that you or others created. Feel free to self-aggrandize, complain about your least favorite standards organization or its politics, and how those young whippersnappers are running the show today.
By participating in this group you are admitting or proclaiming that you are indeed an Internet Old Fart. Perhaps we should give a prize for the youngest and oldest Old Fart.
Has anyone seen Fraser's original ratfor source for the s editor for unix on the PDP-11. It was a screen editor front-end built on top of Software Tools's edit. I've seen a c version, but I'm interested in the 375 line version :).
Sent from my iPhone
Resending this as realised accidentally replied off list
On 30 Jan 2022, at 18:39, silas poulson <silas8642(a)hotmail.co.uk<mailto:firstname.lastname@example.org>> wrote:
On 30 Jan 2022, at 18:07, Dan Stromberg <drsalists(a)gmail.com<mailto:email@example.com>> wrote:
And is Java? They both have a byte code interpreter.
My understanding is Java is both a compiled and interpreted language -
with javac compiling java code to byte code and then JVM interpreting
and executing the byte code.
And then there's the CPython implementation of Python. <snip>
Granted, it has an implicit, cached compilation step, but is it less compiled for that?
I would so no - in my mind compiling analyses the entire source and
then translates it whilst interpreters only explore a single line or
expression. Simply because the compilation happens only Just In Time,
doesn’t make it any less of a compilation step.
Hope that helps,
One of architechture supported by 4.4BSD, luna68k's compiled binary is
luna68k is OMRON LUNA, m68k cpu workstation. This binary set works on
"nono" emulator software.
It's author, Isaki-san have done some minor modification for 4.4BSD,
binary set for luna68k run rather well.
OMRON, already dropped thier workstation products. LUNA-I, LUNA-II
equipped with m68k, same CPU as CSRG's main target arch hp300.
So userland programs may binary compatible.
I'm working through 4.3BSD setup and configuration and came across this:
"There is no equivalent service for network names yet. The full host and network name databases are normally derived from a file retrieved from Internet Network Information Center at SRI... use gettable to retrieve the NIC host database and htable to convert it to the format used by the libraries."
Does this mean I should expect functionality like resolv.conf and ping yahoo.com not to work in 4.3, or by some miracle is gettable still a functional system?
Sent from my iPhone
I've been hard at work on my retro-fuse project over the past few
months, and so I thought I'd update the list with my progress.
I have just released version 7 of retro-fuse on github
(https://github.com/jaylogue/retro-fuse). This version adds support for
initializing and mounting 2.9 and 2.11BSD filesystems on modern
systems. It also includes fixes for a number of bugs in v6 and v7 support.
Beyond the work on 2.11 support, I also spent a significant amount of
time building an automated test framework. I'm a pretty big fan of
automated testing. So I'm happy to say that the project now includes a
series of tests verifying basic file I/O functionality as seen from the
modern system. While not exhaustive (because filesystem testing is
/hard/) the new tests give me reasonable confidence that things are
behaving as they should.
Additionally (in what was perhaps the most fun part of the project to
date) I have also created tests to verify the integrity of the generated
filesystems as seen from the historical systems. In particular, for each
of the supported Unix versions I've built tests that: launch the os
under simulation (simh), mount the generated filesystems, verify the
filesystems using the original integrity check tools (icheck/fsck), and
enumerate and compare the filesystem contents to that generated on the
modern system. As you might imagine, this involved a lot of
learning--from how to build size-reduced system images from the original
distribution tapes, to how to implement a modern POSIX cksum command
with old dev tools. All thoroughly enjoyable.
With this under my belt, I'll probably take a break from retro-fuse to
concentrate on other things. If anyone has any problems (or successes!)
using it, please drop me a line.