Agreed. Although it seems like a lot of these processor “bits” beyond 32 are now put to
use into senseless saccharin AI endeavors like autocorrect. I type “its” and it comes out
as “it’s” when clearly it should have been “its” and it’s depressing, even more so when I
miss it.
Truly,
Bill Corcoran
On Oct 13, 2019, at 3:36 PM, Henry Bent
<henry.r.bent@gmail.com<mailto:henry.r.bent@gmail.com>> wrote:
On Sun, 13 Oct 2019 at 14:54, William Corcoran
<wlc@jctaylor.com<mailto:wlc@jctaylor.com>> wrote:
Today, working with v7m, SVR1, and bsd2.11 all PDP11 ports, for example, will stay booted
and operational for long periods under simulation.
This has certainly been my experience as well with mature, for the era, BSD ports. Most
of the problems I have encountered have been with TCP/IP issues in 2.11BSD and Ultrix 3.1
related to traffic they were never expecting.
With these older UNIX variants, working with awk and even the classic shell tools is often
problematic. Moreover resource constraints seem to be a persistent annoyance under
simulation.
I think our expectations of a 16 bit Unix are going to be well out of proportion now.
When 16 and 32 bit Unix systems existed side by side it was easy to consider the resource
limitations of both when programming. Now that 16 bit systems have moved completely out
of general end user space we only consider the constraints of the 32 and 64 bit systems
that exist side by side.
Some of my interests lie in preserving early '90s hardware with original operating
systems, and working within their constraints. Porting modern tools to SunOS 4 or Ultrix
4 or IRIX 4 (huh, everyone really was stuck on the same version) is a challenge but it can
be done, as long as those tools do not necessarily rely on shared libraries. Backporting
C99 to C89 is often not as difficult as it would seem, though it can sometimes be
laborious. On the other hand, porting modern tools to my PDP 11/23 running 2.9BSD is a
total non-starter for reasons that I am sure I do not have to elaborate upon here.
-Henry