-=> Quoting Roy J. Tellason to Leonard Erickson <=-

 RJT> I used to watch as Eudora Light pulled in email and,  when it got
 RJT> something bigger than about 64k or so,  it would split it up.  Why? 
 RJT> Beats the heck out of me... 
 
 LE> Easy, dealing with a buffer bigger than 64k is a royal pain
 LE> unless you are in protected mode.

 RJT> I can see where it'd affect your choice of memory model (although you
 RJT> could always declare a far pointer to your buffer,  or whatever) but
 RJT> can't see where protected mode comes into it.  I don't believe that
 RJT> that software kept more than a message at a time in memory at any
 RJT> given point.  Besides,  windoze was already in protected mode... 

Windoze is in protected mode. But it doesn't always let apps running
under it have full access. I don't program in Windows so I can't be
certain, but unless you have sufficient access to the "hardware" to be
able to set up an addressing mode with a segment size bigger than 64k,
you are in trouble, as accessing structures bigger than a segment is
the "royal pain" I was referring to.

 LE> I'd love to see how some of these authors would deal with 
 LE> situations I've had to work with in the past. For example, on 
 LE> an old 8-bit system where the programs only had 32k after the 
 LE> OS and BIOS, I had to sort records in file that filled a 180k 
 LE> disk. 

 RJT> What OS are you talking about here?

The oft-maligned TRSDOS. 
 
 LE> It was a 2-drive system, and one drive was needed for the OS 
 LE> disk. So no way to sort to another drive. I cheated, I used a 
 LE> built-in command for sorting an array in RAM, and just "stepped 
 LE> thru" the file. Sure, it took multiple passes, but it was a 
 LE> hell of a lot faster than trying to sort the records one at a 
 LE> time with the interpreted BASIC!

 RJT> Heh.  I think that there are a lot of programming skills that are
 RJT> either never used or are in the process of being lost,  mostly because
 RJT> of the changes in hardware.  I'll bet that a lot of what's out there
 RJT> could be done,  and done a whole lot smaller,  using a whole lot less
 RJT> in terms of system resources,  if programmers were the way that they
 RJT> used to be. 

Heck, only a few old-timers understand that there actually *is* a
qualitative difference between "assembly programming" and "machine
language" programming.

A good ML programmer will do things no assembler programmer would think
of doing (like use portions of instructions as data, portions of data
as instructions, and "reusing" code by jumping to the second byte of a
2-byte instruction). Me? I'm not *that* old, I just learned to program
on a IBM 360 and a Honeywell system that used 6-bit words (and couldn't
handle more than 32k of them, though I think it didn't have even that
much).  

Heck, some of those oldtimers would do the equivalent of allocating the
clusters by hand so that by the time the program needed to get the next
chunk of code or data off the drive, it'd just be coming up under the
read heads. 

 RJT> Hell,  I ran a PDP-11 system one time that had a *maximum* of 56k
 RJT> (words, not bytes!) of ram in it,  and would support eight users! 

The first multi-user BBS in the area was written in HP 3000 BASIC, and
used half a dozen ports on it (the county was going to sell it at the
end of the summer, so they let some students "play" with it). This was
back in 1981! 

As for supporting multiple users, OS-9 on the Color Computer probably
takes the prize. 64k *bytes* of RAM on an 8-bit CPU (6809), and you can
run a multi-line BBS on it *and* do word-processing or play games, etc
locally. (The trick is that the OS have *decent* service routines, the
routines are *completely* re-entrant, and you are almost *required* to
make your own code re-entrant. So you only need *one* vcopy of a
program in RAM, regardless of how many users are using it. All they
need is space for their *data*, not for another copy of the code. And
the code is lean, because it can do all its I/O (and often many other
things) simply by asking the OS to do it.

Pity it took them so long to port OS-9 to the 80x86. 

... If a circuit cannot fail, it will.