On Wed, 12 May 1999, Greg Haerr wrote:
> The point about ELKS being currently limited to 64k code is a very good one.
> I think we're kind of nearing that limit, aren't we?
We've been over this issue many times.
There are many reasons to limiting the size like this, and that is simply
the fact that machines of this era don't have many megs of RAM to waste.
The target machines of ELKS are running on 256k or 512k of RAM, with some
running on 640 or with an extra memory card. If you increase the limit,
by allowing multiple segments then people will start to slacken off a bit
with their code. Also, a few of the ideas being thrown around, such as
swap and stuff are made easier by the fact that only one segment is in use
by a program.
The simple answer is for app developers to write smaller code, not for
kernel developers to handle larger code. If you try and use the argument
about "but I simply can't get it any smaller", then take a look back 10-20
years ago when people were writing programs of similar functionality in a
LOT less ram than 64k. For example, I've got a simple B&W terminal here
with full window manager capabilities, which is running entirely in 640k.
I doubt it needs this much RAM, but it shows that with proper protocol
development, it's possible to do such an application in little RAM.
Come to think of it, this would be a nice target for ELKS. 1024x1024
screen, 68000 CPU and 640k RAM.
Davey
