On Mon, 12 Jul 1999, Greg Haerr wrote:
> BTW, the ansi elks console doesn't work. I can rewrite it quickly if
> nobody minds.
You killed my baby?? Exactly how has it stopped working? It's not a very
complete implementation, only half-a-dozen ANSI commands are supported.
> o added TERM=elks to /bin/login exported environment.
It's almost worth making sash source a .profile, and putting TERM in there
instead, since this is where it really should be done.
> This is why elvis, as86, and many, many other large programs have never
> run. Elks never let programs have > 32k data segments!
> With this fix, I plan on self-hosting bcc and as86, which now will
> run...
The reason bcc wouldn't run was because it was too large (> 64k) to even
link. This is where the fat has to be trimmed first, before anyone even
starts to worry about running it. I've wondered if it's possible to use
temporary files in some way, and break down the compiler into multiple
steps. From memory, this is sort of how minix does it (minix runs more
than 2 programs to get .c to .o).
> o all string functions need rewriting, the libc code is *really* slow.
> I will rewrite both of these in assembly for speed
I thought these were already done in assembly? They were the last time I
looked.
> o dircon and bios tty drivers could use some massaging for vt52/ansi.
There's a couple of issues here, the first (that I mentioned above) is
that the code is just scratched up and is rather incomplete. Also there
was a reason for me writing ANSI support into dircon and not bioscon, I
just can't remember what it is at the moment.
> With these mods, ELKS has works alot better, and now runs a full-blown
> editor using a termcap file.
Sounds like you've done an excellent job with these changes. How much
change is actually made in the kernel? Is most of it simply changes, or
new code? If it's new code, how much larger does the resultant kernel
come out to?
Well done.
Davey
