: Bcc. I think that its one of the things that needs porting the most. Why?
: Here's why.
:
: ELKS is shaping up quite nicely. We have a useable unixish system. But I
: think that it needs certain things:
:
:
: A C compiler.
I have had as a top priority getting the dev86 kit (bcc, as86, ld86)
to run on ELKS ever since I first found ELKS. I have spent considerable
hours enhancing the bcc compiler (it now compiles ansi without a preprocessor,)
and have got all the dev programs to build and link using bcc. I also ported
a small ar86 just for ELKS. On running them,
there are a number of difficulties. As86 dies for lack of memory thru the brk()
system call, which doesn't seem to work yet. In addition, back in January,
when I did all this work, the ELKS kernel would corrupt the filesystem after any
unlink(), and there was no fsck. So I gave up, ported bcc etc to minix, and started
compiling it's libc.
ELKS now has come a long way, and I think that the filesystem works,
fsck is available, and signals and pipes work, but we need people to run on it,
and do stupid things that break things.
I will volunteer to get all the tools self-hosting and produce a development
distribution of them.
: A nice(ish) way to install it. (ie, distribution)
ELKS needs a distribution that allows the entire kernel and commands
to be built, and then booted from, for hard disk usage. The chief maintainer,
Al, only uses ELKS from floppy. We need more people testing ELKS using
a standard command set compiled from scratch, and we need fsck in the distribution.
In addition, the minix filesystem *must* support files > 512k, something it doesn't do
now. The libc.a file is > 512k so you can't even link anything on ELKS. This
requires supporting > 7 indirect blocks.
I will volunteer to fix the 512k block limit, but I'd like someone to
build a standard distribution, that includes all commands and kernel and
allows *everything* to be built from the top with one "make all".
In addition, being the chief nano-X contributor, I would like to see
ELKS bundled with a nano-X distribution. I ported and maintain
nano-X for ELKS, so I can help with this.
: A decent text editor.
Use levee for now, I've got a vi, but we need to actually
try to use ELKS's filesystem, signals, and pipes before you'll want to edit
anything for keeps.
: Networking.
I think we need ELKS DLL's for this, so that we can run the kernel and
any user programs with separate code and data segments to keep the link
size < 64k. Al has done work on shared libraries, and I have some ideas more
akin to Windows real-mode linking, but we need mods to the development tools
for this. I'll do them if you want.
: Romability. (I think I just invented a new word! 8*)
: More standard unix commands.
Please make a list of commands you want. It would be nice
to list the commands we have, and what doesn't work with them.
: Protected mode stuff. (With Expanded memory support).
We're a ways off from this, but it'd be nice. I'd like to see
support for > 64k segments.
:
:
: Some of these things will be difficult (if possible), but I think that
: this is what we need to make it into a useable system. If people can use
: the thing, then they are a lot more likely to work on it / test it.
I totally agree. Pull down ELKS, and elkscmd, and compile them
and run them and send comments to this list as to what works and what doesn't.
Al said that he got signals working with the latest version, but I don't know
what the number is or where to find it. The version that I last ran, 0.0.74,
couldn't do "ls > file" or "ls | more" without dying or breaking the file system.
Greg
:
:
: Luke(Boo) Farrar.
:
:
:
:
