home *** CD-ROM | disk | FTP | other *** search
/ Atari FTP / ATARI_FTP_0693.zip / ATARI_FTP_0693 / Mint / mntlib25.zoo / readme < prev    next >
Text File  |  1992-12-13  |  4KB  |  71 lines
  1.  
  2. *NOTE*: to compile the library you will need the header files in mntinc25.zoo
  3.  
  4. ============================================================================
  5.  
  6. Here is mintlib, a library for gcc, Sozobon, Pure C, and Lattice C which
  7. produces programs usable under either MiNT or TOS (of course, some features,
  8. e.g. pipe(), are only available under MiNT). This version has been reasonably
  9. well tested under both TOS and MiNT, and with 16 and 32 bit integers, but no
  10. doubt bugs remain. Please report any that you find.
  11.  
  12. The main library has the GNU C version of the library, plus the common
  13. files. See the lattice, purec, and sozobon directories for compiler
  14. specific information.
  15.  
  16. The Lattice C support is definitely a bit rough around the edges (I may
  17. very well have messed up some of the patches, and I don't have Lattice to
  18. test it). Similarly, I can't test the Sozobon and Pure C support myself.
  19.  
  20. There are no docs ("Use the Source, Luke"), but most of the library should
  21. be pretty self-explanatory. If you know ANSI C and/or Posix, then most
  22. of the functions should be pretty clear to you.
  23.  
  24. MiNT specific features are active when the external variable __mint is
  25. non-zero; this variable is set automatically by the startup code in main.c.
  26.  
  27. Some things to watch out for:
  28.  
  29. (1) MiNT has a blocking fork(), i.e. the parent waits for the child to
  30.     relinquish its address space rather than continuing in parallel.
  31.     (Do NOT rely on this, though, since it will be corrected in a future
  32.     version of MiNT!)
  33. (2) Using the spawn functions instead of fork/exec means that your programs
  34.     will work under TOS as well as under MiNT. vfork() also works under
  35.     TOS now, so vfork/exec is another viable alternative.
  36. (3) The longjmp() code has a call to Psigreturn() embedded in it; this means
  37.     that most signal handlers will work without changes, but in some very
  38.     bizarre circumstances this could cause a problem (if the sig handler
  39.     longjmps *within* itself, and then returns, for example).
  40. (4) Under TOS, all terminal reads are assumed to come from the console
  41. (5) You'll note that there is only minimal support for UNIXMODE;
  42.     this is because MiNT 0.9 supports symlinks in the kernel.
  43. (6) A function call, tfork(), is provided to start a new thread of
  44.     execution in the same address space. The declaration is
  45.     int tfork( int (*func)(), long arg ).
  46.     A new process is started, which executes concurrently with the parent
  47.     process and in the same address space (but a different stack).
  48.     The child begins at the address in func, with the stack set up as though
  49.     the call (*func)(arg) was made (in fact, this call *is* made!).
  50.     The child will exit when func returns, with the exit status being the
  51.     return code of func. The parent continues to execute concurrently;
  52.     in the parent, the value returned from tfork() is the process id of the
  53.     child.
  54. (7) The library is not set up to handle multiple threads of execution in the
  55.     same address space, so you'll have to provide semaphores for critical
  56.     library calls (e.g. malloc) yourself if you have multiple threads.
  57.  
  58. The library is based on the gcc library that Jwahar Bammi and I put together.
  59. Lots of people have contributed to it, including (but not limited to):
  60.  
  61. Adrian Ashley, Jwahar Bammi, Scott Bigham, Kai-Uwe Bloem, Howard Chu,
  62. John R. Dunning, Doug Gwyn, Dave Gymer, Michael Hohmuth, Alan Hourihane,
  63. Alex Kiernan, Ulf Moeller, Allan Pratt, Arnold D. Robbins, Edgar Roeder,
  64. Rich Salz, Dale Schumacher, Andreas Schwab, Eric Smith, Henry Spencer,
  65. and Stephen Usher.
  66.  
  67. I've hacked on things quite a bit, so if they're broken don't blame the
  68. original authors, blame me.
  69.  
  70. Eric R. Smith
  71.