On Sat, Jun 6, 2009 at 2:10 PM, Kirn Gill <segin2005 at gmail.com> wrote:
Ethan Dicks wrote:
On Fri, Jun 5, 2009 at 3:58 PM, Kirn Gill
<segin2005 at gmail.com>
wrote:
Well, out of curiosity, I'm going to attempt
to build gzip and
wget on it. I hope it doesn't crash.
It probably won't crash, but the compiler might or might not be
able to wedge all that code into the available code space.
I can just about guarantee that you'll have Makefile issues for
projects large enough or new enough to use configure scripts...
I've messed with Minix on a 286; I used to keep a copy of i86 Minix
with the DOSMINIX laucher on a flash drive because it would run on
NTVDM (Windows NT's DOS VM).
OK. Some of that experience is relevant.
I've also messed with DOS programming.
It's a pain and a half and I avoided it like the plague;
Me, too. I only ever had one job programming in DOS and it was
horrible (one of my assigned tasks was to implement overlays because
we had exceeded the available application size at about 525KB - yes
"DOS" has 640K, but your program doesn't get to snarf it all up -
there are a few things that users tend to have - even a clean DOS
setup for gaming left noticeably less than the full 640KB.
DOS is dead
and not of any intristic value unless you enjoy playing corny-looking
games or running horrid multitasking GUIs made by Microsoft.
I happen to enjoy playing corny-looking games, but I happen to own
original copies and was playing them when they were the latest thing.
I still have Master of Orion I close at hand, plus a few others.
I know
enough C to make compilers shut up when porting code;
Also a handy skill, but different environments provide different
challenges. DOS pointers are not really like UNIX pointers if you do
anything more than reference and dereference them.
I have tried
writing software on my own and I can show you some failed attempts I
just left behind (also due to lack of motivation, I get tired of doing
all the work myself)
Back in the comp.sources.games days, it was *very helpful* (nearly
essential) to be an accomplished C programmer if you were trying to
build something as complex as Larn on something that wasn't one of the
3-4 common environments (BSD on a VAX being very, very common, other
environments at varying degrees).
If the /pointers/ on a PDP-11 are 16-bit as well, then
I know what I
am up against. I've done a bit of coding with ELKS and
(aforementioned) Minix for pre-386 chips.
Yes. Pointers are 16 bits. There's none of this x86 segment register
twiddling. 16 bits. On a large machine like an 11/73, you can have 16
bits for data and 16 bits for code, and don't you dare try to twiddle
the MMU yourself.
I wouldn't write any software on the machine,
there's nothing useful I
can think of writing that I would actually deal with using.
2BSD on a PDP-11 was much more compelling in 1992 when PDP-11s were
affordable by mortals and 32-bit UNIX ran on hardware we could never
hope to own ourselves with licenses we could never hope to afford.
Even in the early days of Linux, products like Interactive UNIX on a
386 was more "useful".
I had plenty of PDP-11 gear (over $1000 out-of-pocket in addons plus
lots of freebies) and I had problems marshalling the resources to load
2BSD. Fast-forward to when most serious computer types had a 386 or a
486 w/16MB of RAM and 80-200MB of disk (1994-1995, say), and Linux
started to look mighty attractive, if still a little rough around the
edges.
2BSD on an -11 is viable when your alternative is an 80286 or 8086.
Not so much when a 32-bit x86 costs less than the -11 gear, even at
reseller and rescue prices.
The fact
that the local 'vi' doesn't respond to ANSI/VT100 directional keys,
and only responds to h, j, k, l instead is enough to make me hate it.
It's vi, not vim. That's all we had for a long time.
And no, that's not going to motivate me to write a
better editor. I
don't know how. If I did, I would have already done it and the holy
Emacs vs. Vi war would have been over, both sides having both lost.
I use both. I guess that makes me a heretic.
-ethan