I have come up with the following ideas that I think ELKS needs. I am prepared
to undertake all these, but thought I'd post to see if anyone else is interested
or has any comments whatever...
1. Currently the ELKS low level interrupt processing seems to work great. I've
never had it crash when just sitting around or running a debugged program. However,
the file system crashes regularly. The following items could be worked on:
a. remove 519K file size limit (ie. implement indirect block lookup)
b. file redirection from the shell doesn't work well (kernel or libc? )
c. pipes don't work well (probably kernel bug)
d. crashes after rm, bad block numbers in fs (I think Alistair may
have just fixed this in 0.0.74)
A big question here: why was the minix fs rewritten for ELKS, rather than just using
the linux-386 code? I realize there was good reason for the buffer rewrites, because
of
86 model considerations, but the original linux minix fs code works.
2. Movement toward self hosting bcc, as86, and ld86. I'm working on this
and have gotten several comments from Rob deBath and Alistair. Thanks. Hopefully
the 64k cseg and dseg limits won't kill us. Bcc requires -Mf to link.
3. What about the idea of adding "char _far *" support to BCC? This would
be relatively easy, and allow far pointer addressing while still keeping totally
8086 compatible, and running in small model. Initial support would include just
pointer declaration and reference, not necesarily compares, etc.
Also, I would like to add the C++ "//" command syntax.
Making the compiler ansi-prototype compliant would be a huge step forward.
With an existing #define, the compiler will compile ansi prototypes. I don't think
it will automatically perform function parameter type casting, which is what's really
needed.
4. Build a standard distribution from the dev86, elks and elkscmds efforts that
completely compiles itself, then produces boot floppies for floppy and hd based systems
that then runs only the code that was just compiled.
Greg Haerr
[EMAIL PROTECTED]
