Does anyone know of the existence of source code written in B (C's predecessor?)
I have encountered a few snippets here and there, but nothing
substantial. The only "real" program that I know of is AberMUD-1. It
looks like there exists a physical print-out of it:
https://dropsafe.crypticide.com/article/12714
Could it be that this is the only artifact left of this most important
"missing link" of C and Unix History? How can this (and any other B
source) be gathered and preserved?
> What a pain, almost like Unix, and not quite. l It was a clone of Unix for the 68k.
Funny, I was just poking through some ccpm68k source/tools, which happened to contain
the Alcyon C compiler source, and one of the files is:
$ cat v103/doc/files/Sectioname
.fo 'REGULUS Reference Manual'- % -'FILES'
$
The same system?
DF
Was there ever a UNIX or even the thought of porting one to a PDP-10?
36-bit machine, 18-bit addresses (more on KL10 and KS10), and:
*0 would return register 0 instead of a SIGSEGV ;)
8-bit bytes would have been a wasteful exercise, but you never know.
(losing 4 bits of every 36-bit word)
thanks!
art k.
> That makes sense if it's '73. That would be the Ritchie front end and
> v5/v6 syntax as I remember=20
Here:
http://publications.csail.mit.edu/lcs/specpub.php?id=717
is the TR describing it (well, this report covers one by him for the Honeywell
6000 series, but IIRC it's the same compiler). I didn't read the whole thing
slowly, but glancing quickly at it, it sounds like it's possible a 'from
scratch' thing?
Noel
> From: Alec Muffett
> "threaded code" in the old sense could be smaller than the equivalent
> CISC binary on the same machine
One can think of 'threaded code' as code for a new virtual machine, one
specialized to the task at hand.
> https://en.m.wikipedia.org/wiki/Threaded_code
For those who really want to delve in some depth, see the chapter "Turning
Cousins into Sisters" (Chapter 15, pg. 365) in "Computer Engineering: A DEC
View of Hardware Systems Design", by Bell, Mudge and McNamara.
Interesting factoid: The PDP-11 initially used a threaded FORTRAN
implementation. In line with the observation above (about a new virtual
machine), DEC actually looked into writing microcode for the -11/60 (which had
a writeable control store) to implement the FORTRAN virtual machine.
Noel
On 2017-09-17 18:33, Arthur Krewat <krewat(a)kilonet.net> wrote:
> Was there ever a UNIX or even the thought of porting one to a PDP-10?
Definitely a thought. An attempt was started on NetBSD for the PDP-10,
and it sortof got halfway of getting into single-user, but I'm not sure
if the person who worked on it just got distracted, or if he hit
problems that were really hard to solve. I certainly know the person,
and can find out more if people really are interested.
> 36-bit machine, 18-bit addresses (more on KL10 and KS10), and:
>
> *0 would return register 0 instead of a SIGSEGV ;)
Yes. Not the first machine that would be true for. You don't have
address 0 unmapped on a PDP-11 either.
> 8-bit bytes would have been a wasteful exercise, but you never know.
> (losing 4 bits of every 36-bit word)
Uh... Why 8 bit bytes? That way lies madness. There exists a really good
C compiler for TOPS-20 - KCC. It uses 9 bits per byte. Works like a
charm, except when some people write portable code that is not so
portable. ;-)
KCC was written by KLH, unless I remember wrong. Same guy who also wrote
the KLH-10 emulator.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
What a pain, almost like Unix, and not quite. l It was a clone of Unix for the 68k. The APIs were ever so slightly different because the authors were concerned about copyright infringement. libc calls had different argument orders or types and in general it was just off enough that you wanted to claw at the screen every time something went wrong.
To top it off, the system we were hosting it on was so slow that a full rebuild of our meager (10k lines) software took overnight.
I eventually ported all the software to a SparcStation-2 cross compiling to the 68k target we were embedded on.
> To kick a more relevant thread off, what was the "weirdest" Unix system you used & why? Could be an emulation like Eunice, could be the hardware e.g NULL was not zero, NUXI byte ordering etc.
>
> Cheers, Warren
On Thu, Sep 14, 2017 at 4:09 PM, Jon Steinhart <jon(a)fourwinds.com> wrote:
>
> Well, I'd suggest that a lot of this has to do with people who have vision
> and people who don't. When you look at UNIX, you see something created by
> a bunch of very talented people who had a reasonably shared vision of what
> they were trying to achieve.
>
Jon - I mostly agree, but would twist it a little differently (hey, we've
been arguing since the 1970s, so why stop now).
I think you are actually touching on an idea that has been around humanity
for a long time that is independent of the computer field. We call it
"good taste." Part of acquiring good taste is learning what is in bad
taste, a heavy dose of experience and frankly the ability to evaluate your
own flaws. What I always love about Dennis, Ken, Doug, Steve and the rest
if the team is their willingness to accept the shortcomings and compromises
that were made as the developed UNIX as a system. I never saw them trying
to claim perfection or completeness, much less and end state had been
reached. Always looking for something better, more interesting. And
always, standing on the shoulders of others...
What I really dislike about much of the crowd that has been discussed is
that they often seem more contented to kick people in the shins that
standing on their shoulders.
I used to say, when we were hiring people for some of my start-ups, what we
wanted was experienced folks that had demonstrated good taste. Those are
people you can trust; and will get you pretty close to where you want to be.
In fact, to pick on one of my previous employers, I have always said, what
DEC got wrong, was it was always striving to be perfect. And lots of
things never shipped, or when they did (like Alpha) it was wonderful, but
it did not matter. The opportunity window had passed.
Part of "good taste" is getting the job done and on time. Being "good
enough" and moving on to the next thing. Sun (certainly at the beginning)
was pretty good at this idea. The UNIX team clearly got a lot of it right.
It is easy to throw stones at others. It is hard to repeatedly get so much
right for so long and UNIX has and did.
Clem
On Sep 15, 2017, at 1:32 AM, tuhs-request(a)minnie.tuhs.org wrote:
>
> From: "Steve Johnson" <scj(a)yaccman.com>
> To: "Dan Cross" <crossd(a)gmail.com>, "Bakul Shah" <bakul(a)bitblocks.com>
> Cc: "TUHS main list" <tuhs(a)minnie.tuhs.org>
> Subject: Re: [TUHS] really Pottering vs UNIX
> Message-ID:
> <d92047c5a36c6e72bd694322acb4ff33e3835f9f(a)webmail.yaccman.com>
> Content-Type: text/plain; charset="utf-8"
>
>
>
> More to do with a sense for quality. Often developed through
> experience
> (but not just that). I think what we need is a guild system for
> programmers/engineers. Being an apprentice of a master craftsman is
> essential for learning this "good taste" as you call it.
>
> Back when I was writing FORTRAN, I was
> working for a guy with very high standards who read my code and got me
> to comment or, more usually, rewrite all the obscure things I did.
> He made the point that a good program never dies, and many people
> will read it and modify it and try to understand it, and it's almost a
> professional duty to make sure that you make this as easy as possible
> for them.
>
When I taught at UCSD I always made it a point to inform the students
that the person who will be maintaining their programs in the future will
all be reformed axe murderers. These nice folks learned C (at the time)
on MS-DOS 3.1 and weren’t as homicidal as they used to be. They would
however be given your home address and phone number in case they
had questions about your code.
It was always good for a laugh and I went on to explain how code outlives
the author and so you should take care to make it easy for someone else
to work on your code.
The other thing I did was to have students give their programs half
way through the project to a randomly chosen (by me) other student.
They were not allowed to assist the recipient and grades were based
on how well the final program met the requirements given at the beginning
of the project. Code quality went way up on the second project compared
to the first.
David
I had almost wiped any memory of DG/UX from my memory. Now I’m
quite sure I must resume therapy for it.
I wrote device drivers for that . . . thing to drive graphics cards for
Megatek and its custom version of X11 that buried about 1/2 of the
server in the hardware.
David
> On Sep 17, 2017, at 12:01 PM, tuhs-request(a)minnie.tuhs.org wrote:
>
> From: Chet Ramey <chet.ramey(a)case.edu>
> To: arnold(a)skeeve.com, wkt(a)tuhs.org, tuhs(a)tuhs.org
> Subject: Re: [TUHS] And now ... Weirdnix?
> Message-ID: <58b4bb3e-1b94-0e3d-312d-9151e8a057a6(a)case.edu>
> Content-Type: text/plain; charset=utf-8
>
> On 9/17/17 3:28 AM, arnold(a)skeeve.com wrote:
>
>> Whatever Data General called their Unix layer on top of their native
>> OS for the Eclipse or whatever it was (32 bit system).
>
> I think they called it DG/UX -- just like they called their wretched
> System V port.
arnold(a)skeeve.com:
> This not true of ALL the GNU project maintainers. Don't tar everyone
> with RMS's brush.
John Steinhart:
What are we supposed to to then? cpio?
===
I guess we're supposed to tp his house.
Norman Wilson
Toronto ON
On Fri, Sep 15, 2017 at 11:21 AM, Noel Chiappa <jnc(a)mercury.lcs.mit.edu>
wrote:
>
>
> Why not just write a Unix-native one? They aren't that much work - I
> created a
>
> uassembler overnight (literally!) for the QSIC project Dave Bridgham and I
>
> have been working on.
Agreed Terry Hayes, tjt and I hacked an assembler and loader for Masscomp
together years ago pretty fast. We actually, made all those tools look a
lot like the DEC ones because a lot of same HW people were writing the
uCode for the Masscomp FP/APs as had written the much of the 11 and Vax
code.
[Fun story, that a few other tools that had been written for UNIX that
patriots older RSX/VMS support tools were quietly traded to DEC WRL for
some HW libraries. We both were using the same brand CAD system and our
HW guys wanted some design rule stuff WRL had done for Jupiter, and they
wanted UNIX based tools to run on Ultrix].
As for Tektronix earlier, we did not know much about the WSC unit and
basically the CSAV/CRET stuff was supposed to be a one shot thing. We
just wanted to use the tool that came with it; cause we did not think we
were going to do much with it. In hind sight and knowing what I would
learn 3-5 years later, writing our own would have made more sense; but I'm
not sure it was very well documented.
Clem
> From: Dave Horsfall
> Did anyone actually use the WCS?
Well, the uassembler was a product for a while, so they must have..
> I had visions of implementing CSAV and CRET on our -60, but never did
> get around to it.
I recently had the idea of programming them into an M792 ROM card (100nsec
access time); user programs couldn't have used it without burning a segment
(to map in the appropriate part of the I/O space), but it might have sped up
the kernel some (and it would have been trivial to add, once the card was
programmed - with a soldering iron - BTDT, BITD :-).
Haven't gotten to it yet - still looking for an M792 (I don't want to trash
any of my pre-programmed M792-xx's :-).
> From: Clem Cole <clemc(a)ccc.com>
> A big issue, again IIRC, was the microcode compiler/tools for the WSC
> ran on RSX so it meant UNIX was not running, which was not popular.
Why not just write a Unix-native one? They aren't that much work - I created a
uassembler overnight (literally!) for the QSIC project Dave Bridgham and I
have been working on.
It's been improved a lot since the first version (e.g. the entire uengine
description is now read in from a config file, instead of being compiled in),
but that first version did work fine...
Or was the output format not documented?
Noel
I been watching and thinking a bit about this exchange particularly, since
I had a paper accepted in "Unix in Europe: between innovation, diffusion
and heritage" Symposium which touches on this topic. I think it is
really gets to the core of the problem that UNIX was caught with and I
certainly did not understand at the time.
The issue here is were are all technologist and as such, we think in terms
of the technology and often forget that its the economics that is the long
pole in the tent. *Simply, computers are purchased as a tool to help to
solve problems for people*. And the question remains who controls the
money being spend.
*UNIX was written originally by a group of people for themselves.* The
problem that they were solving, *was how to build better programs and
systems for those programs*. Vendors, particularly hardware centric
vendors, really only care that you buy their (HW) product which is where
they make their money. As it turns out applications software vendors,
don't care about operating systems - as we used to say Larry Ellison never
cared for VMS, UNIX, Solaris, or MVS, he cared how many copies of Oracle's
DB he sold.
So UNIX comes on the scene and strange thing happens. First AT&T is
required by 1956 consent decree to make the IP available, they have
processes and procedures to do so, so they do. So in the 70s certainly,
when the HW delivery platform for UNIX is a DEC, the people that want it
are the same type of people that it was originally written -- programmers.
UNIX is a hit.... by the 80s and 90s, now we have two different group of
peoples working with UNIX. As Steve and Larry point out, those same type
of developers that originally had used UNIX in the first place [which was
cool... I'm one of them too]. The problem was the economics started
getting driven by a different group, the people that did not care - it was
purely a means to get a job done (we the programmers lost control of the
tiger in return for a lot of money to start to develop the systems).
As Larry pointed, most of the care takers of the second class of UNIX
customer, did not give a hoot about the programmers or many of the 'norms'
from the previous world. Sun, Masscomp and eventually DEC did make SunOS,
RTU, and Ultrix sources available to university customers (IBM may have
also I'm not sure), but the hoops to get it could be painful; because they
did not really understand that customer base as Steve pointed out (which
turns out to have been an undoing).
But that was the issue. Sun was able too see that trying to help the
programmer was a good thing, but in the end, they could not sustain it
either. In the end, they got sucked in the same economics of cutting at
deal with AT&T to create Solaris SVR4 etc. Opposed Sun Forever, might
have made it if they had actually make OSF 'Open Source' but they were too
caught in fighting with each other. Imagine if the Mach based OSF1/386
has been released, which was running before Linux with a window manager and
you had IBM, DEC, HP, et al working to make it 'FOSS' - how different the
world might have been.
But that would have gotten back to my point... they made their money
selling an application delivery vehicle. They had liked to the control it,
because it was easy to keep the customer if they did, but in the end, they
really did not care.
Now they have seeded the field to Linux and just left the OS to the SW
developers and fallen back to what they really care about. A place to run
applications.
Clem
> I really kind of liked that toolkit, it was all key/value like so:
>
> panel = xv_create(
> frame, PANEL,
> XV_WIDTH, WIDTH,
> XV_HEIGHT, 30,
> PANEL_LAYOUT, PANEL_HORIZONTAL,
> XV_SHOW, FALSE,
> NULL);
>
> So the order of the args didn't really matter, I think the first one
> maybe did because that was the parent but not sure, the rest could
> be any order you wanted. Pretty simple.
The first two were fixed; the prototype was
Xv_object xv_create (Xv_opaque owner, Xv_pkg *pkg, ...);
The keywords (XV_WIDTH etc) contained a bitfield encoding the type and
cardinality of the value argument(s) so that the argument list could
be traversed without knowing every package's keywords.
Using NULL as the terminating argument looks unportable.
-- Richard
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
> Check out: ybc: a compiler for B <https://github.com/Leushenko/ybc>
>From a historical standpoint, a plain B compiler lacks a very important
attribute of B in Unix. Yes, B presaged some C syntax. But its shining
property was that it produced threaded code, for which both compact
and expanded runtime support was available. The latter had software
paging. Thus B transcended the limited physical memory of the early
PDP-11s.
If you can't compile something, you can't run it. A prime example was B
itself. Without software paging it would not have been able to recompile
itself, and Unix would not have been self-supporting.
Doug
> The rest of your story is great, just one small correction. SunView started
> as something Sun specific but it pretty quickly became a library on top of
> X11. I'm not sure if it ever worked on X10, I think it did but I'm not sure.
As I recall it, SunTools (the original Sun window system) was renamed
SunView, and the API was ported to X11 under the name XView.
> Source: I've hacked up GUI interfaces for the SCM I did at Sun in Sunview.
> This would have been around 1990, is that still X10 or X11?
X11 came out in 1987. I The first version I remember using is X11R3,
which came out in 1988.
See https://www.x.org/wiki/X11R1 (and .../X11R2 etc)
-- Richard
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
Here is a BibTeX entry for a book on the NeWS system:
@String{pub-SV = "Spring{\-}er-Ver{\-}lag"}
@String{pub-SV:adr = "Berlin, Germany~/ Heidelberg,
Germany~/ London, UK~/ etc."}
@Book{Gosling:1989:NBI,
author = "James Gosling and David S. H. Rosenthal and Michelle
Arden",
title = "The {NeWS} Book: an introduction to the {Network\slash
extensible Window System}",
publisher = pub-SV,
address = pub-SV:adr,
pages = "vi + 235",
year = "1989",
ISBN = "0-387-96915-2",
ISBN-13 = "978-0-387-96915-2",
LCCN = "QA76.76.W56 A731 1989",
bibdate = "Tue May 25 07:20:00 1999",
bibsource = "http://www.math.utah.edu/pub/tex/bib/unix.bib",
keywords = "NeWS (computer file); Windows (computer programs)",
}
It is the only book that I have recorded on NeWS (I have it on my
office bookshelf). If there is interest, I can post links to 10 or
so journal articles and conference proceedings about NeWS from
1986 to 1990.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu -
- 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
Trying a one solution fits all approach was always Microsoft's approach.
Back over a decade ago when I was big into MFC development, it was amazing
how much of the Windows bloat was present in WINCE (or Windows Moble as they
later styled it). It's almost impossible to differentiate a desktop and
mobile on the Windows side. They tout it as an advantage.
Oddly, Android gives an indication of how to do it right. Sure, you can
take the essentials out of the common system, but you don't have to move
inappropriate bloat over.
> On the programming side, there wasn't either the memory capacity or
> processing power to implement a modern disk file system. One of the
> first computers I worked with was a System/360 model 25 running
> DOS/360. The machine had 48K of core memory, 12K of which was for the
> OS, leaving 36K for programs. No virtual memory.
Unix was a counterexample. Recall that v1 worked on a 24K
machine, 16K of which was OS and 8K user. And it had a modern
file system. Programming was so much easier that it lured
people (e.g. me) away from big mainframe computers.
Doug
> From: Dave Horsfall <dave(a)horsfall.org>
> Just think, if it wasn't for him and Ken, we'd all be running Windoze,
> and thinking it's wonderful.
It's actually worse than that.
We'd be running a Windows even worse than current Windows (which has managed
to pick up a few decent ideas from places like Unix).
Noel
Evening,
Okay - now that I've completed moving and settling in, I am slowly
bringing some stuff back up. UCBVAX should come back in the next few
weeks (now much closer to Berkeley...).
One advantage of the new location: cheaper power so my PBX runs all the
time now. ;)
Once I acquire a second modem I will accept UUCP at 115200 and 2400 baud
via telephone :)
--
Cory Smelosky
b4(a)gewt.net
> does anyone know anything about the 1961 DoD 8-bit
> character set standard it refers to?
>
> This does not appear to say anything about LF vs "Newline" (as either a
> name or a function), though the 1986 version of ASCII deprecates it, so
> was most likely acknowledged in versions between these in response to
> practices on OSes such as Multics. ECMA-6:1973 acknowledges it
I wouldn't say the "practices" of Multics influenced the recognition
of NL in the ASCII standard, for Multics didn't go into use until
1970, while NL was specified by 1965 (see below) with direct
reference to the properties of equipment, not operating systems.
Just what equipment, I don't know. IBM Selectric perhaps?
I recall Multics discussions that specifically cited the standard,
in particular Joe Ossanna's liaison between Multics and the TTY 37
design team at Western Electric, circa 1967. Thus it is my
understanding that Multics was an early adopter of ASCII's NL
convention, not an influencer of it.
Quotation from "Proposed revised American standard for information
interchange", CACM 8 (April 1965) 207-214:
The controls CR and LF are intended for printer equipment
which requires separate combinations to return the carriage
and feed a line.
As an alternative, for equipment which uses a single combination
for a combined carriage-return and line-feed operation
(called New-Line), NL will be coded at FE 2 [LF]. Then FE 5
[CR] will be regarded as Backspace BS.
If the latter type of equipment has to interwork with the
former, it may be necessary to take steps to introduce the
CR character.
One might read the preceding paragraph as advice not only to
writers of driver software but also to a future standards
committee to undo the curious notion of regarding CR
as BS. Unix effectively took it both ways, and kept the
original meaning of CR.
doug
> troff has a substantial history. Significant
changes in troff could invalidate most of the old documents leaving troff
with no usage base, and a poor tool at rendering all of the troff documents
out there.
As a living example, I have troff files from as far back as 1975 that
still work, and perhaps some even older that have lost their dates due
to careless copying. The only incompatibility with groff is easy to
fix: inserting a space before the arguments of a troff request. The
few other incompatibilities I've encouuntered have been graciously
corrected by groff maintainers. You get no such help for old Word files.
doug
