nulib: NuLib NuFile eXchange (NuFX) Archive Utility (for ShrinkIt/BinaryII/NuFX)
NuLib: A NuFile eXchange (NuFX) Archive Utility (also supporting ShrinkIt/BinaryII)
The original author of NuLib has continued development of NuLib as NuLib2.
NuLib2 (at least out of the box), doesn't attempt to support building on MS-DOS, GS/OS, or most other 16-bit platforms that were contemporary with the Apple IIe.
This version of NuLib is known to be working on CP/M-68000, Xenix[23]86, modern (and ancient) resource constrained embedded systems, as well as modern Linux running on 64-bit processors.
To further complicate matters, there was an upstream NuLib v3.25, which fixed many of the same bugs as this release, which I was not aware of at the time of producing this fork.
Most of the work on that version was done by contributor Devin Reade, with a focus on improving compatibility with older systems and compilers, namely, Orca/C and GNO running on the Apple IIgs.
I do plan to incorporate any applicable changes from that release, as long as the changes do not negatively impact support for CP/M-68K or Xenix.
In short, NuLib2 should be preferred by most users.
If you need to have NuLib working on the Apple IIGS, the upstream v3.25 is likely the best option and probably works as well as v3.24.
If you need NuLib on a modern (but resource constrained) 64-bit or 32-bit embedded system, CP/M-6800, Xenix/286, or Xenix/386, this version is known to have worked somewhat recently, and intends to keep supporting these legacy platforms.
Things work much better if you read the documentation file (now available
on the archive site... sorry I didn't put it up sooner). If you want to
use UNIX compress to store files, READ THE DOCUMENTATION FIRST. Not only
does it tell you how to do it, but it has some warnings about compatibility.
To compile this on a UNIX-type system, edit the file "nudefs.h". Several
systems are predefined; the default is a BSD UNIX system. If you want to run
this on something other than BSD, comment out the #define statements (using
"/*" and "*/"), and uncomment the appropriate statements (several systems are
defined... if yours is an AT&T System V system, try the defines for Amdahl
UTS). Then, type "make" to execute the Makefile. If all goes well, you will
be left with an executable file called "nulib". If all does not go well,
double check "nudefs.h". You may need to deal with the HAS_EFT stuff,
especially if your compiler complains that "mode_t" or "off_t" are undefined.
Send some mail to me if you can't get it to work at all.
To make the MS-DOS version, use the nulib.mak and nulib.lnk files with MS C
(supplied by Bruce Kahn). To make the APW C version (NOT Orca/C), put all
the files in one directory, and make a subdirectory called "OBJ". Put the
"linked.scr" and "linker.scr" files in OBJ, and then "make.apw". This will
compile all the files. When it finishes, change to OBJ and "alink
linked.scr" (standard linker) or "alink linker.scr" (ZapLink). The makefile
used to do this automatically, but with only 1.25MB of RAM you have to exit
APW to purge all the memory used by the compiler, and and then restart APW
and run the linker.
In both cases, BE SURE to modify "nudefs.h" first. If you don't, the
compilation will halt in "numain.c" on a line which reminds you to change
"nudefs.h" (I tended to forget about this). Also, under APW make sure all
the file types are set to SRC, and the auxtype to CC. These are changed with
the commands "filetype" and "change", respectively.
Please send bug reports, ideas, or gripes to [email protected], or to
one of the addresses mentioned in the documentation or under the "-hw"
option.
Under some systems, using UNIX compress on a file which does not compress will cause the archive's EOF to be larger than it should be. This slack space will be used up if you add more files to the archive (with NuLib anyway; no guarantees about ShrinkIt or GS/ShrinkIt, but there's no reason why they shouldn't work).
Just to make things clear: if the file being compressed doesn't get any smaller, the compression halts and the file is simply stored uncompressed. Because of the way compress works, on some systems the space that would have been occupied by more compressed data is left attached to the file. The ShrinkIt compression does not suffer from this problem. If you add more stuff to the file, NuLib will fill the slack space first, NOT just append to the end of the file).
Linux Port
Modern Linux Port