Universal Program UNPACKer

From Atari Wiki
Revision as of 12:37, 12 October 2011 by Admin (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
UPUNPACK.APP - Universal Program UNPACKer v1.08á (92/06/08)
Copyright ½ 1992 STS Software.

This program is intended to do just what it's name implies.  It will try to
unpack any recognized formats that it can.

Currently, the recognized formats are:
Pack-Ice, Pack-Fire, LArc's PFXPAK, 4PAK/PACK ENGLISH, DCSquish, BRAsoft,
"POPI" (POmpey PIrates?), JAM Packer, Paradox Packer, Unnamed Packer I, 
RNC Packer, VMAX/MCS, and the "HAPPY COMPUTER PACKER".

The program itself does not know how to unpack anything.  It merely recognizes
and (where neccessary) adapts the unpack code already present in packed
programs, and utilizes them.

You should be in medium, high, or equivalent resolution before running this
program.  No ill effects should happen if you happen to run it on a 40 column
screen except that any out-of-bounds text will simply be clipped (aka: you
won't see all of the text if you run the program on a 40 column screen...).

After loading the program you will be bored by the program's signon message
(hence the "Zzzzz." button therein).

You then will be asked if you wish to have the destination (path and) filename
default to the selected source (path and) filename.  This is merely for
convienience.  Answer yes if you will be overwriting the input file(s).  If
you instead want the program to remember both paths, because you plan on
reading your packed files from one path and writing them to another, answer
no.

You will be prompted by a fileselect box requesting you to locate an input
file.  The input file should be an executable file.  If it is not
(don't worry) you will be presented with a message to that effect and will
have the opportunity to try again.

You will now be informed of the current file size (as it sits on disk),
and the file will then be read into memory.  You will be informed of the
current program flags (see below) and their meanings, then the program
will attempt to recognize (and adapt) different schemes to match it's
expectations.

If all goes well, in a few seconds the program will be unpacked and you
will then be prompted by a fileselect box requesting you to locate an output
file.  You would then (of course) select the (path if neccessary and) filename
for output and press OK.

If you plan on overwriting the source file(s), you needn't worry if the source
file was Read-Only or not.  The program can overwrite Read-Only files just as
well as Read-Write files.

The time and date stamp as well as the original file attribute (and flags)
will be preserved in the unpacked program, except that the archive bit will
now be set.

What do I mean by "(and flags)"?
Starting with (Rainbow) TOS 1.04 (aka TOS 1.4), a formerly reserved area of
the executable file header (file offset $18, 24 decimal, word size) now holds
a number of flags representing different abilities of the file in question. 
As far as I can tell, only 3 bits are currently used.  Bits 2..0 of the flags
are arranged as follows:
         BIT #              Ability if set (to 1):
         2                  Program CAN USE TT FAST RAM
         1                  Program CAN EXECUTE IN TT FAST RAM
         0                  Program CAN FAST LOAD

Most commonly, you will see a %001 (word $0001, 1 decimal) flag which simply
means that a program can fast load (memory beyond the BSS segment is not
cleared, so users of machines with larger memories will not experience the
delay required to clear all their memory.)

------------------------------------------------------------------------------
~~~ Version 1.08á (92/06/08) ~~~

The VMAX/MCS scheme is now supported.

~~~ Version 1.07á (92/05/31) ~~~

A newer form of Pack-Ice is now recognized.

~~~ Version 1.06á (92/04/01) ~~~

A nasty little bug in gfn has now been fixed.  The program now also supports
the RNC packer format (only for programs resulting as a $601A std. file).

~~~ Version 1.05á ~~~

oops! the multi-unpack was flawed in 1.04á.  It's fixed now...

~~~ Differences between Version 1.03á (92/01/08) and 1.04á (92/02/07) ~~~
Bugs in JAM Pack setup now fixed.  Now supports Paradox Packer, and an
unidentified packer I call simply, "Unnamed Packer I".

~~~ Differences between Version 1.02á (92/01/03) and 1.03á (92/01/08) ~~~

Program now cleaned up a bit.  Programs that have been (for whatever reason)
packed more than once will now be fully unpacked (you no longer need to write
the file out, then read it back in).

4PAK/PACK ENGLISH setup now improved even further.

Program is now 153 bytes shorter than 1.02.

~~~ Differences between Version 1.01á (92/01/02) and 1.02á (92/01/03) ~~~

Small bug in the "HAPPY COMPUTER PACKER" unpack setup has now been fixed.

The pack format "JAM Packer" is now regognized.

Also, I have switched to unsized hex number output (Binary and Decimal were
already unsized previously).  If you liked the longword hex output better,
let me know.

~~~ Differences between Version 1.0á (92/01/01) and 1.01á (92/01/02) ~~~

I re-arranged screen format somewhat.

A small bug in the 4PAK/"PACK ENGLISH" unpack setup has now been fixed.

The pack formats, "BRAS" (BRanch Always Software) and "HAPPY COMPUTER PACKER"
are now recognized in this version.
------------------------------------------------------------------------------

If you should encounter program(s) that you feel are packed (some have verbose
messages printed to the screen prior to unpacking, while others flash colours
like crazy whilst unpacking) and UPUNPACK does not recognize them, and you
would like to see UPUNPACK do so, send the (packed) program
(and if possible the program that generated it, if it is Shareware/PD) to:

STS Software,
BOX 76, Site 2, RR1
Grande Prairie, AB
T8V 2Z8

Comments and suggestions can also be sent to the above address.


Back to Packer/Depacker