At AT&T, the evolution from B to C was quite smooth, as was the evolution of C itself.   Most B programs were converted to "nb" (the first C incarnation) by hacking on the character strings and putting in some types where needed.   It wasn't a big deal.  So I'd be surprised if there were substantial B programs that survived.

One lesson learned that I've never forgotten is how smooth it is to evolve a language using the following process:
  1. Announce that the change is coming and explain why
  2. Change the compiler to accept both the old and new syntax
  3. Produce a simple warning message when the old syntax was used, but make it still work
  4. Produce a more complicated, verbose message, but still make it work
  5. Produce a message that says "After date xxxx, the old stuff won't work any more"
  6. On the date, change the warning to fatal, but keep recognizing the old syntax and emit "Error: You used the old xxx, change to the new one"
  7. Eventually, stop recognizing the old syntax and remove the message.

Dennis was a master at this strategy, so things like the otherwise painful evolution of changing =+ to += went well.

Steve


----- Original Message -----
From:
"Robert Swierczek" <rmswierczek@gmail.com>

To:
"Toby Thain" <toby@telegraphics.com.au>
Cc:
<tuhs@minnie.tuhs.org>
Sent:
Fri, 7 Apr 2017 17:51:03 -0400
Subject:
Re: [TUHS] Non-US Unix Activities


>
> Yes, there's always SOME way to avoid it, but obviously significantly more
> work. Just depends what the priorities are... Preserving fanfold seems like
> a strange priority, wouldn't it be more practical bound book-like anyway?
>
> Or, similar to your suggestion, load it into a compatible printer (so that
> it can be sprocket fed), with some kind of takeup spool, then form feed
> pages through, snapping each one between feeds.
>

Fully agree! If there is anything I can do to help get that online
(in whatever form) let me know.

Are there any other surviving examples of B code from that era in this
ballpark of complexity?