Filename:  mpack152.zip
Size:      58605 bytes
One Line:  Mpack/Munpack 1.5.2 public beta (beta 4) MIME encoder/decoder
Multiline:

MIME encoder/decoder.  Munpack also decodes UUCode and binhex.  Handles
files split over several messages, copes with parts in any order.  Wimp
GUI front end.
          
Directory: /pub/archimedes/utils

-----------------------------------------------------------------------

Ported by Olly Betts (olly@mantis.co.uk) - here is his original
announcement:




Mpack/Munpack 1.5.2 public beta (beta 4)

This version is a public beta release.  It's better than the previous
release (1.5) in every way, and this would be a full release except that
I've recently been sent the development sources for the next cross-platform
version.  So I've tidied up all the loose ends in this version and released
it unofficially (i.e. not through Mpack's maintainer).  Please reports any
bugs/comments, as otherwise they are likely to be present in the next
official release.

Why would you want it?

Mpack/Munpack's main purpose is to create and decode MIME messages.  Notable
features:

* Munpack can decode MIME, uuencode, and binhex.

* Munpack handles MIME and uuencoded files which have been split over
  several messages.  You can drag on the messages in any order: Munpack will
  hold onto all the fragments and reassemble the file when it has them all.

* Munpack knows about application/riscos, which ANT's !Marcel uses to
  preserve filetype and timestamp information.  It also knows how to unpack
  the directory structures !Marcel creates.

* The underlying MIME engine is cross-platform, and so has been very well
  tested.

How can you get it?

You can get it from:
  ftp://ftp.barnet.ac.uk/pub/Acorn/munpack/mpack152.spk
or:
  ftp://195.152.134.2/pub/users/olly/mpack152.spk

(The second machine is currently prone to random rebooting during office
hours, but may be much faster from non-ac.uk sites).  If someone wants to
upload the archive to other ftp sites, I have no objections (but don't have
the time to do it myself at present).

If you prefer to use command line tools, you'll find the executables mpack
and munpack inside !Mpack and !Munpack respectively.  I've added a "-w"
switch to each which if specified starts it up with the wimp frontend,
otherwise they work pretty much as before.

Summary of changes since 1.5:

General:

* Rewritten to not use UnixLib, which means the executables are noticeably
  smaller and probably a bit faster.

* Added Wimp interfaces.  At present, mpack's is lacking in many ways --
  output filename is fixed, message subject is fixed, etc.  The latest
  development sources have a new, more flexible library for creating MIME
  messages, so (provided I have time) !Mpack's GUI should be greatly
  improved in the next release.

* Fixed a number of filename handling bugs (e.g. FOO.GIF would only unpack
  as file GIF in directory FOO before).  Should truncate names if necessary,
  but won't if the filing system supports long names (or if LongFiles or
  similar is running).

Munpack:

* Brief instructions for Wimp interface: drag message to icon to decode;
  click SELECT on icon to view unpacking directory; click ADJUST on icon to
  get setup dialog.

* Code to create store directory for multiparts now chooses DOSFS-friendly
  names.

* Wimp interface allows options to be changed during run, and also stored
  on disk.

* "^" is more carefully checked for in output filenames.  Before it couldn't
  be sneaked in to produce output in a higher level directory, but in some
  circumstances it could get into leafnames producing illegal filenames.

* File-suffix counter is now reset after each file (change copied back from
  development sources for next cross-platform release).

* Warning given if application with !Boot is unpacked.

Mpack:

* Brief instructions for Wimp interface: drag file(s) to icon to encode,
  which produces one text file for each message; click SELECT on icon to
  view packing directory.

* Mpack now uses RISC OS filetype in helping choose a MIME content-type.

* Added auto-filetyping by extension and/or content-type.

As always, bug reports and other comments are greatly appreciated (just in
case you missed me saying that the first time).

Olly