or, if not, anyone feel like helping me port a contemporary line printer daemon to 2.11bsd?

--jake p.s. sorry for the previous subject misfire.

On 11/30/2014 07:45 PM, Toby Thain wrote: Umm, I'm "pretty sure" I had TeX running on RSX-11M. It was glacially slow, as in taking minutes per page, but it did get the job done.

It ran a lot better, of course, on a VAX.

Word processing doesn't get any better than TeX, I still use it under Linux. Jon

On 12/02/2014 07:20 AM, Mark Wickens wrote: > Is there any general agreement on what the 'best' programming language

> for PDP-11 for this kind of application, if I'm getting what you're

> 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

had a passion for Pascal, also got a Modula 2 compiler but never really moved to it.

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

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

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

but the main thrust of FPC was to handle DEC and Borland Pascal

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

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

to think logically, structure well, and doesn't have all the insane

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 yesterday. 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

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 sorts of gotchas. Jon

On 02/12/14 1:45 PM, Holm Tiffe wrote: Less than 5% of the *kernel* is at that level, and NONE of userland. The rest needs as much static checking as it can get (which is where C and "worse is better" entirely fails people doing "systems programming"). Viz: Thousands of CERT notices. --Toby

On 12/03/2014 09:42 AM, ben wrote: PL/1 anyone?

And ADA seems to be pretty much dead.

Ha! It is to laugh. The DoD closed the AJPO many years ago, and issued waivers to the Ada requirement at the drop of a hat. At some point they did away withthe requirement so that they no longer need to issue waivers.

PL/1 anyone?

I think I had asked some of the friends, and they though it was pretty much dead.

Many years ago when I was a Honeywell L66 GCOS systems programmer I was on a course for a new release of GCOS.... ...Around the time there was an "Issue" with WWMCCS reportedly become close to launching an attack without proper authority.... Those of us on the course, who were having issues getting work run on GCOS, which was , we were told the core of WWMCCS at the time were somewhat disbelieving.. .. we said it couldn't happen. Some bright spark said even they want to they can't, the Secret Service will wake the President, and he will log into WWMCCS and type "Launch Missiles" and it would respond "Thank you Mr. President, your job is at position 9 in queue .bang1, estimated time for execution 1 day 4 hours..."

PL/1 anyone?

Rich Alderson <RichA at livingcomputermuseum.org> wrote:

As someone who has written a two-pass cross-assembler in Perl, it is my considered opinion that Perl consists almost entirely of dark corners.

Hmm. What C compiler did this, on what distro? I'm pretty sure that this throws a compiler warning in gcc with -Wall...

So on systems where sizeof(int) <= sizeof(int32_t) -- which is everything that matters

On Dec 4, 2014, at 1:50 PM, Peter Corlett <abuse at cabal.org.uk> wrote:

2009. The kernel went default 64-bits in Snow Leopard (10.6) in 2010. OS X on x86 has always supported mixed 32/64 bit applications (as long as the CPU did) regardless of what the kernel was (a 32-bit kernel could run 64-bit applications).

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

So, should the compiler optimize that to MOV X,0 or NOP ?

On Dec 2, 2014, at 11:08 AM, Jon Elson <elson at pico-systems.com> wrote: still discovering new ways that C code that looks perfectly correct can screw up horribly. Last one was yesterday. 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 sorts of gotchas.

Now that I use Linux pretty exclusively, I have grudgingly accepted C.

But is there necessarily a win in turning a crack C programmer into a novice {Smalltalk, LISP, insert your favorite language here...} programmers?

Given a short time frame, perhaps it's more effective to spend those hours writing code in a language with which you're already

rather than spending them picking up a new language...

Clearly you're on a religious crusade here.. I just don't buy the line

were it not for everyone using this pesky C language, we could live in

mythical world where exploits don't exist...

You must be a professional programmer? Certainly you have strong ideas of what's right and what's wrong in programming practice... but I feel like you are faulting the language here while giving what are essentially (sorry, strong language) hack programmers a pass... Why should it be the responsibility of the language to save programmers from themselves?

Not necessarily the best metaphor because I totally appreciate languages like Smalltalk, LISP, et

but I'm too old to be restricted to safety scissors! Best, Sean On Wed, Dec 3, 2014 at 3:25 PM, Eric Smith <spacewar at gmail.com> wrote: > On Wed, Dec 3, 2014 at 9:21 AM, Sean Caron <scaron at umich.edu> wrote: > > But is there necessarily a win in turning a crack C programmer into a > > novice {Smalltalk, LISP, insert your favorite language here...} > > programmers? > > Of what use is a newborn baby? Of *course* it's of no value if you

programmer, say programming still a > huge number that have gone undetected so far. > > C advocates always claim that a good programmer will write reliable

> in C, and in a vanishingly small number of cases that's true, but the > reality is that 99.9999% of C code has bugs that either: > > 1) could have been caught by static analysis in a language with even > slightly better semantics (including strong typing) > > 2) could have been caught at runtime if the language semantics could > reasonably support bounds checking. In this case the software would > still have a bug, but at worst it would result in denial of service > rather > than privilege escalation and information leakage. (Then there's

for will > point > out that a lot of the new stuff in C++ is safer than the old C stuff,

plus

I suppose not. Perhaps more that using a language that Isn't C and offers (1) and (2) will ameliorate 99.99% of the problems that follow from using C incorrectly. Certainly that's true. Can't shoot yourself in the foot if you don't own a gun. But that's not much to talk about :) I have a habit of using hyperbole and I guess I really shouldn't because 99.99% of the population of Earth apparently finds it simply discrediting, rather than a come-on for a debate!! I have a lot of hang-ups from my experience in school and in the new-millennium job market... there are so few opportunities these days; the people that get the chance to take them; who get to be real programmers and real engineers; they had better be good. Otherwise you can just play on nights and weekends like I do. To me, part of being a professional and doing the job right is not making mistakes. Certainly that's the standard I hold myself to as a Systems Administrator. People who nail up their shingle as a professional and subsequently ship buggy garbage don't need a new language to save them from themselves; they need a new line of work (whoa, polarizing!) Best, Sean On Wed, Dec 3, 2014 at 6:38 PM, Josh Dersch <derschjo at gmail.com> wrote: > On Wed, Dec 3, 2014 at 3:09 PM, Sean Caron <scaron at umich.edu> wrote: > >> Clearly you're on a religious crusade here.. I just don't buy the line > that >> were it not for everyone using this pesky C language, we could live in > this >> mythical world where exploits don't exist... > > > That's not the line that was given. No one here is claiming there is a > language that prevents all exploits. > > > >> You must be a professional >> programmer? Certainly you have strong ideas of what's right and what's >> wrong in programming practice... but I feel like you are faulting the >> language here while giving what are essentially (sorry, strong >> language) >> hack programmers a pass... Why should it be the responsibility of the >> language to save programmers from themselves? > > > The reality is that we're all "hack programmers." Everyone makes > mistakes. Sometimes these mistakes get caught by others, sometimes they > don't. Some programming languages can help catch more of these mistakes > sooner, or to make some of these mistakes impossible. > > In a perfect world, we wouldn't need languages to take responsibility to > "save programmers from themselves," but we don't live in that world and > it's pretty evident that deficiencies in C have resulted in many > exploits, > even in the hands of experts. > > - Josh > > > >> Not necessarily the best >> metaphor because I totally appreciate languages like Smalltalk, >> LISP, et > al >> but I'm too old to be restricted to safety scissors! >> >> Best, >> >> Sean >> >> >> On Wed, Dec 3, 2014 at 3:25 PM, Eric Smith <spacewar at gmail.com> wrote: >> >>> On Wed, Dec 3, 2014 at 9:21 AM, Sean Caron <scaron at umich.edu> wrote: >>>> But is there necessarily a win in turning a crack C programmer into a >>>> novice {Smalltalk, LISP, insert your favorite language here...} >>>> programmers? >>> >>> Of what use is a newborn baby? Of *course* it's of no value if you > stop >>> at turning them into a novice. But if they're actually a *good* >> programmer, >>> they'll become proficient in another language. I would go so far as to >> say >>> that if they don't become proficient in another language, given a >>> reasonable >>> chance to do so, they aren't actually a good programmer, any C >> programming >>> ability notwithstanding. >>> >>>> Given a short time frame, perhaps it's more effective to spend >>>> those hours writing code in a language with which you're already >>> familiar, >>>> rather than spending them picking up a new language... >>> >>> And continue writing software that has vulnerabilities. When the tools >>> don't >>> provide support for writing reliable software, reliable software >>> mostly >>> doesn't >>> get written. For every CERT advisory of a vulnerability, there are >> still a >>> huge number that have gone undetected so far. >>> >>> C advocates always claim that a good programmer will write reliable > code >>> in C, and in a vanishingly small number of cases that's true, but the >>> reality is that 99.9999% of C code has bugs that either: >>> >>> 1) could have been caught by static analysis in a language with even >>> slightly better semantics (including strong typing) >>> >>> 2) could have been caught at runtime if the language semantics could >>> reasonably support bounds checking. In this case the software >>> would >>> still have a bug, but at worst it would result in denial of >>> service >>> rather >>> than privilege escalation and information leakage. (Then there's > the >>> problem of people that use runtime checking during software >>> testing >>> to protect their valuable test data, but turn runtime checking >>> off >> for >>> production, but that's an argument for another day.) >>> >>> There has been a huge amount of research into how to solve those >>> problems in C, with only partial results. It's a difficult and perhaps >>> intractable problem because C is a portable assembly language, with >>> correspondingly low level semantics The "easy" way to solve the >>> problem >>> is not coming up with bandaids for C, or trying to better train C >>> programmers; it is to abandon C for a reasonable language. >>> >>> This doesn't happen at least in part due to managers seeing a huge >>> glut of C programmers on the market. When all you've got is a >>> hammer... >>> >>> Note that the same arguments apply to C++. While C++ is no longer >>> a proper superset of C, it still is close to being one. C++ advocates >> will >>> point >>> out that a lot of the new stuff in C++ is safer than the old C stuff, > but >>> unfortunately as long as the old C stuff is in there, it gets used and >>> causes the same old problems. Rather than C++ being a better language >>> than C, it's a worse language, because it has *all* of the C defects, >> plus >>> additional new ones. >>> >> >

... *All* programmers. "A sufficiently smart programmer" does not exist.

40 years ago would never dream of doing since they would be thinking of how this translates into machine code much more. So in the end, with people getting less proper education, a stricter language is our only hope. But for people who are good at programming, the obstacles of stricter languages becomes annoying and reduces productivity, for much less gain.

In the end, no one size fits all.

40 years ago would never dream of doing since they would be thinking of how this translates into machine code much more. So in the end, with people getting less proper education, a stricter language is our only hope. But for people who are good at programming, the obstacles of stricter languages becomes annoying and reduces productivity, for much less gain.

In the end, no one size fits all.

But is there necessarily a win in turning a crack C programmer into a novice {Smalltalk, LISP, insert your favorite language here...} programmers?

You can give it up any time. There are dozens of far better languages that have cropped up in the 40 years since C was invented for a particular environment (that doesn't resemble anything much we do today).

Is there any general agreement on what the 'best' programming language is for PDP-11 ...

On 02/12/14 1:26 PM, Johnny Billquist wrote: *Which* PDP-11 C?

The PDP-11 ISA is sane enough that one could create a LLVM backend and cross-compile to it using any of the LLVM-supported languages. It'd be quite

Bonus points for running Java on it :)

or, if not, anyone feel like helping me port a contemporary line printer daemon to 2.11bsd?