rogersh%t5j@uk.ac.man.cs (Huw J. Rogers) (03/05/91)
I have a new version of UnixLib which seems reasonably stable and now
provides the following features:
0) Almost all the V7 UNIX system calls plus:
1) Implementation of vfork(), execve(), and pipe().
2) Inheritance by child processes of FD set, proc structure, etc. as
per V7 UNIX allowing full I/O redirection.
3) A rewrite of the SYS V termio interface, including the
ability to use RS423 or console as tty, and control it fully using ioctl().
4) Contiguous stack - gcc here we come!
5) Improved RiscOS interface.
6) Very stable (heavily tested) (and fast) stdio.
7) Much faster qsort() and various other optimizations.
8) Common UNIX C libraries: All the stuff that was copied into the
ANSI standard (qsort() etc.) and also:
getpwent(3)
directory(3)
termcap(3)
random(3) / lrand48(3)
I want to put GNU curses on top of termcap, but haven't got the
source... I also want to add getcwd(3) and some other stuff to the list
but there are some implementation problems with that. The missing system
calls are almost all root only calls.
Of course the major advantage is 1) - this allows the compilation
of GNU bash, and the use of pipelined command sets etc. as per UNIX (given
that the subprograms thus called by the shell are also UnixLib programs).
Although execve() calls OS_CLI at the lowest level and will execute
any RiscOS program/command, only programs compiled with UnixLib will
be able to inherit the FD set, actual argv[] array and proc structure of the
caller, thus allowing I/O redirection and proper argv handling amongst
other things. Note the fork provided is VFORK *not* FORK. vfork() is
different, but as far as shells and pipelines are concerned there's no
real problem with a #define fork() vfork(). pipe() is implemented as
a write, read, delete to Wimp$Scrap (pipe() fails if it isn't defined).
Please don't ask exactly how I manage to call subprograms and
return nicely to an uncorrupted parent - it's horrible... :-(
In order to avoid the small amount of chaos that was generated when
I posted the last version of this software, I would like to hear from as
many people as possible with UNIX s/ware they want to port to the Arch.
(perferably complex/large) who would be willing to put up with the odd bug,
and report it. These brave volunteers will receive the recognition they
deserve... :-) I need people with a fair understanding of C, UNIX, and ARM
code and they will be in possession of the source code. I only possess a
2Mb A3000 + 1 FD, hence I can't really test the library out on large s/ware
myself. However I will personally be attending to NetHack 3.0 PL10.
This period of testing would last for a month or so, then I would post
a stable release to comp.binaries.acorn (which should by then exist). Between
now and then I will also rewrite the filename conversion routine (which needs
an overhaul: It needs to be able to be customised more by the user, and also
to address multiple drives/FS from within the UNIX naming domain).
I will surface mail disks to testers in a week's time, all being well.
Thanks for listening...
Huw
[ H.J.Rogers (INTERNET: rogersh%p4%cs.man.ac.uk@cunyvm.cuny.edu) ]
[ ,_, (BITNET/EARN: rogersh%p4%cs.man.ac.uk@UKACRL.BITNET) ]
[ :-(_)-o (UUCP: ...!uunet!cunyvm.cuny.edu!cs.man.ac.uk!p4!rogersh) ]
[ _} {_ (JANET: rogersh%p4@uk.ac.man.cs) ]