[comp.sources.apple2] v01_ADM_5: Re: v01_ADM_2: Packaging of Source Code

jac@sparky.rutgers.edu (Jonathan A. Chandross) (09/05/90)

Submitted-by: jac
Posting-number: Volume 1, Administrivia: 5

I bundled up the comments.  The problem seems to have been solved.
Doug Gwyn sent me a C program that does packing and unpacking of
archives.  I've enclosed the readme.

The only problem is that the program is written in C, so it is only
of use to those with a C compiler.  As far as I know, it used to be
difficult to redistribute Apple // C compiler binaries because you
needed special run-time packages, libraries, etc.  Is this still
the case?

It should be fairly easy to write the equivalent in Basic or Assembly
if a C binary can't be distributed for some reason.  Any volunteers?

-- jac


From: Doug Gwyn (VLD/VMB) <gwyn@brl.mil>

	apack -- pack text files into archive for convenient shipment

	last edit:	04-Sep-1990	D A Gwyn

	Usage:	apack files... > archive

	The specified files are written into the archive, preceded by a header
	containing a form-feed, the filename, and a new-line.  Carriage-return
	characters are replaced by new-lines, on the assumption that they are
	intended to represent line delimiters.  Form-feeds at the beginning of
	lines are doubled in order to prevent those lines being mistaken for
	filename headers.  All other characters are copied literally, so it is
	a good idea not to use control characters in the files, as they may be
	mangled during transmission of the archive.

	The archive is printable as it stands; the companion program "aunpack"
	may be used to unpack the archive into files having the same names as
	the original files.  "aunpack" reverses the form-feed mapping, but not
	the carriage-return mapping.  Thus, files intended to overstrike lines
	on a printer will not look correct on the target system.  Note that
	filenames are not checked for "funny" characters, and "aunpack" merely
	attempts to open the named files for writing, which can fail if the
	names are not suitable for the target system.  Simple names like
	"foo.bar" are recommended.

[ What more could you ask for? ]


From: Larry W. Virden <osu-cis!chemabs!lwv27>

Personally, I still think that source should be binscii'd and shrinkit'd.
Otherwise, you will have a tough time finding software that will run on
an Apple II with 16k thru an Apple IIgs.  And that is what you are going
to need.

Note that (arc, zoo)/uuencode -the REAL way IBM, etc post their code has
the same problems as shrinkit and binscii - you cannot look at the internals.

There is available a format which is pretty standard.  Unfortunately,
I forget the name of the program!!  Contact rsalz@uunet.uu.net for the
name and code for the Software Tools archiving program.

P.S.  someone will need to write a 6502 or Applesoft archiving and dearcing

[ I think you are referring to SHAR.  I have this already. ]


From: David Kopper <dave@mystie.webo.dg.com>

   There are two choices: port shar from unix to all apples or
                          create a new utility on both platforms.

   If there is going to be a new utility, then it will need to
   meet the following requirements to be successfull:
    o  Run under ProDOS 8 (with a desktop version in the future).
    o  Must bundle/unbundle sources in the same program (can't
       have two seperate programs).
    o  The bundle process must not produce files bigger than
       about 60k or so (some mail systems can't handle a bigger
       size than that).
    o  A good user interface - similar to standard file dialogs.
       (although a command line interface that accepted templates
       would work - you would be requiring a shell of some sort...
       maybe that would be acceptable - however new people won't
       understand the shell...)
    o  Both the apple and unix versions must be put out very
    o  These tools should automagically map control-M and control-J
       in an intelligent fashion.
    o  One last blurb, post the source to these tools when they
       are ready to be used.

[ Well, Unix-only tools, like the Apple // simulator, the versions of
  binscii, blu, and shrinkit for Unix, etc. will be posted in SHAR

  Why can't there be 2 separate programs?

  The 60k limit will have to be done by hand.  A program could be
  written to decide which files to pack together.

  In general, it looks like Doug's program does what is needed.

  And my intent was to begin posting small source as soon as the
  archive name business has been straightened out.


Jonathan A. Chandross
Internet: jac@paul.rutgers.edu
UUCP: rutgers!paul.rutgers.edu!jac