home *** CD-ROM | disk | FTP | other *** search
-
- *NOTE*: to compile the library you will need the header files in mntinc16.zoo
-
- This will likely be the last version of mntlib in its present form. I plan
- (time allowing!) to produce a more portable version of mntlib that will
- work with Sozobon and maybe other compilers (like Laser) as well as gcc;
- this will necessarily involve considerable changes in the names of functions
- and variables (to satisfy the DRI 8 character external name rules) and
- will likely take a long time to complete.
-
- ============================================================================
-
- Here is mintlib, a library for the gcc which produces programs usable under
- either MiNT or TOS (of course, some features, e.g. pipe(), are only available
- under MiNT). This version has been reasonably well tested under both TOS
- and MiNT, and with 16 and 32 bit integers, but no doubt bugs remain. Please
- report any that you find.
-
- There are no docs ("Use the Source, Luke"), but most of the library should
- be pretty self-explanatory. MiNT specific features are active when the
- external variable __mint is non-zero; this variable is set automatically
- by the startup code in main.c. Some things to watch out for:
- (1) MiNT has a blocking fork(), i.e. the parent waits for the child to
- relinquish its address space rather than continuing in parallel.
- (2) Using the spawn functions instead of fork/exec means that your programs
- will work under TOS as well as under MiNT. vfork() also works under
- TOS now, so vfork/exec is another viable alternative.
- (3) The longjmp() code has a call to Psigreturn() embedded in it; this means
- that most signal handlers will work without changes, but in some very
- bizarre circumstances this could cause a problem (if the sig handler
- longjmps *within* itself, and then returns, for example).
- (4) Under TOS, all terminal reads are assumed to come from the console
- (5) You'll note that there is only minimal support for UNIXMODE;
- this is because MiNT 0.9 supports symlinks in the kernel.
- (6) A function call, tfork(), is provided to start a new thread of
- execution in the same address space. The declaration is
- int tfork( int (*func)(), long arg ).
- A new process is started, which executes concurrently with the parent
- process and in the same address space (but a different stack).
- The child begins at the address in func, with the stack set up as though
- the call (*func)(arg) was made (in fact, this call *is* made!).
- The child will exit when func returns, with the exit status being the
- return code of func. The parent continues to execute concurrently;
- in the parent, the value returned from tfork() is the process id of the
- child.
- (7) The library is not set up to handle multiple threads of execution in the
- same address space, so you'll have to provide semaphores for critical
- library calls (e.g. malloc) yourself if you have multiple threads.
-
- NOTE: If you already have a gcc library, make sure that you do *not* use
- its header files to build the mint library. Some headers (signal.h and
- ioctl.h) have changed significantly, and are no longer compatible. The
- environment variable GNUINC should point to the include directory obtained
- from this zoo file whenever you make any MiNT related stuff. (I've completely
- replaced my TOS library with this one, because it can produce TOS programs
- too.)
- Note to the note: recent versions of the gcc library have header files that
- are compatible with mntlib. I can't vouch for the compatibility 100% (and you
- definitely need a *very* recent version of the include files to get complete
- compatibility with mntlib16).
-
-
- The library is based on the gcc library that Jwahar Bammi and I put together.
- Lots of people have contributed to it, including (but not limited to):
-
- Jwahar Bammi, Kai-Uwe Bloem, John R. Dunning, Doug Gwyn, Dave Gymer,
- Allan Pratt, Arnold D. Robbins, Edgar Roeder, Rich Salz, Dale Schumacher,
- Eric Smith, Henry Spencer, and Stephen Usher.
-
- I've hacked on things quite a bit, so if they're broken don't blame the
- original authors, blame me.
-
- Eric R. Smith
- eric.smith@uwo.ca
- ersmith@uwovax.bitnet
-