MiNT goes Unix

[ekl@sdf.lonestar.org (Evan K. Langlois)]

I think we are preceding from the wrong end.  Instead of working on the
file system structure and the compiler flags for using TOSFS file systems
I think we need to look at the binaries themselves.

We aren't going to know what paths to put the binaries into until we
know what binaries exist.  Then we can decide where to put them.  I'd say
that the TOS Filesystem is not a problem.  Anyone running a Unix-like set-up
is either going to run MINIXFS or somehting similar or is going to get
some sort of fix for the TOSFS, someone mentioned a GEMDOS FS that called
Unix2Dos.  If you want the library to support specific TOS FS naming
then use Dpathconf to find out the limits of the filesystem at run-time and
then decide if the filename needs mangling.

My enviroment is gone crazy.  We need a better way of configuring.  Perhaps
a configuration directory?  So that an ENV var points to a directory where
config files are kept.  A program would then load in its config file from
the directory instead of having a cluttered enviroment.  For speed reasons,
a Binary configuration utility would be best - to modify the executables
to change paths and defaults (perhaps a TOSFS switch if Dpathconf is too
difficult or inefficient to determine file name mangling conventions).

I'm in support of rewriting GEM.  GEM is using up 90% of my CPU time and
that is when my mouse doesn't move and the keyboard doesn't move.  I wrote
my own little mouse tracking facility that used Fselect with /dev/mouse
and /dev/console to track the mouse and work out double-click events and
such.  Not only did it work, and used NO CPU time when I didn't move the 
mouse or type, but I couldn't make it use more than about 5% and I tried
real hard!  If ATARI isn't willing to rewrite GEM, perhaps we should?
How hard could it be to rewrite the AES - perhaps structure it like
NeXT Step (or add more direct X emulation although I think X is too inefficient
for use on an ATARI).  You can add wrapper functions to emulate the older
AES calls or something.  It would be a difficult undertaking, but the
machine is going to be hindered badly unless you remove the OS polling.

I think we should also work on getting a non-blocking fork() and non-blocking
IO too.   If PowerDos can do it, then it can be done.  DMA disk IO doesn't
have to lock up the whole machine does it?

To start, lets get a list of binaries that are available for MiNT.  We
can then decide where these binaries should go in a Unix hierarchy, 
deciding between whatever current ... standard? .. best fits what we've
got and then we can also decide what sorts of binary configuration can be
added to those programs.

Its a place to start.  I'm always in favor of a place to start over
theory.