Fwd: is there any word processing software for the pdp11?

Jon Elson elson at pico-systems.com
Tue Dec 2 11:08:31 CST 2014

On 12/02/2014 07:20 AM, Mark Wickens wrote:
> Is there any general agreement on what the 'best' programming language is
> for PDP-11 for this kind of application, if I'm getting what you're after
> it's something like wordstar or WPS-PLUS? A text editor with some word
> processing features. Good system integration and the ability to easily
> control a terminal?
> I know VAX Pascal is highly respected and can do most things - certainly
> Theo De Klerk's book is very comprehensive.
> I don't know *anything* about programming PDP-11's. Would be interested if
> there is one language or it's a case of pick and choose like VAXen.
Our shop at the time (1975-1981 or so, for the PDP-11) used 
FORTRAN.  I had a passion
for Pascal, also got a Modula 2 compiler but never really 
moved to it.  We then got a
VAX 11/780, and I used them until the migration to the Alpha 
systems, and used
those until the end of DEC.  We continued to run one Alpha 
here until it became so
obsolete that nobody would use it anymore.  We were STILL 
mostly a FORTRAN
shop.  I created a few personal apps in Pascal.

Now that I use Linux pretty exclusively, I have grudgingly 
accepted C.  Recently,
the Free Pascal Compiler (fpc) became available on Linux, 
and it is quite
amazing.  I ported over a Turbo Pascal for Windows app that 
ran on Windows
95/Win 2K to run on Linux in a couple days.  It required 
some serious hacking
to remove external hardware-specific parts that were no 
longer applicable,
but the main thrust of FPC was to handle DEC and Borland 
Pascal extensions
to the language well.  They really did a good job!  So, 
after a long time away
from Pascal, it is again a viable language.  I doubt I'd 
ever write a major
app in Pascal again, but I could if I wanted.

Well, none of the above really applies to the PDP-11!  I 
will say that a major
advantage with Pascal is that when I got a program to pass 
the compiler's
syntax checking, it very often ran correctly the first 
time!  It forces you
to think logically, structure well, and doesn't have all the 
insane hidden
syntactic screwups that C does.  I still get called in at 
work to advise
when C programs don't work right.  I'm still discovering new 
ways that
C code that looks perfectly correct can screw up horribly.  
Last one was

Boiling it down, we had :

long long int A;
int B;
A = B << 32;

This means that some field of B gets shifted to the right by 
32 bits, and
fit into the upper 32-bits of A.

Now, any decent compiler should either extend B to the 
length of A, or
as the C rules specify, NOT extend B, and therefor ought to 
warn you
that it is losing significant bits.  No warning, no 
extending the variable
before shifting the bits off the end of the word.  So, A 
always gets
a zero!  UGH!  Stupid!  I could almost write a book of these 
of gotchas.


More information about the cctech mailing list