home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Club Amiga de Montreal - CAM
/
CAM_CD_1.iso
/
files
/
440.lha
/
HunkFix_v1.4
/
HunkFix.DOC
< prev
next >
Wrap
Text File
|
1990-11-13
|
13KB
|
305 lines
HunkFix version 1.4
Friday August 31st, 1990
Copyright © 1990 Arthur Hagen
THIS PROGRAM IS LIMITED DISTRIBUTABLE SHAREWARE
===============================================
Disclaimer:
There are NO warranties, either expressed or implied, with respect to the
software, its quality, performance, or fitness for any particular purpose.
This software is provided "as is" and the entire risk to its quality and
performance is with the user. The author of this software shall NOT be
liable for errors contained in the software or the software's
documentation, or for incidental or consequential damages of any kind in
connection with the performance, use or possession of same.
This program is "ShareWare", i.e. if you find this program useful, the
author would be immensely pleased to find a small cheque in his mailbox.
The suggested sum to send is USD 10.00, but the amount could be whatever
sum you would like to pay. I cannot develop for free, as I need to buy
coffee, tobacco, harddisks etc. to wrestle more programs out of the Amiga.
My address (for cheques, praise, bug reports etc.) is:
Arthur Hagen
Johan Scharffenbergsvei 99, apt 56
N-0694 OSLO 6
Norway, Europe
My bank account:
ABC Bank, Oslo, Norway (SWIFT code: UBNONOKKXXX)
account no: /1600.52.26531
account name: Arthur Hagen
This program is also "limited distributable". That means that you may
give it away under certain conditions. The conditions are as follows:
a) You may NOT charge the receiver any amount for the program itself.
This means that if you are a PD vendor, you may still charge your
customer for disks, P&P et al, but NOT per program.
b) You may NOT remove this documentation file.
This file, called HunkFix.DOC should be included either in the same
directory, or in the same archive as the main program.
c) You may NOT change either this file or the program file.
This includes crunching, translating, changing text, etc.
d) You may NOT include it along with any commercial programs, or as part
of a bargain including such.
HUNKS - AN INTRODUCTION
-----------------------
The following information is useful, but not essential to the use of this
program. If you already know about hunks, or don't bother to read all
this, just skip to the next chapter.
The Amiga computer performs what is called "scatter-loading" of all
programs that is run. This means that programs most often consists of
several small parts that can be loaded anywhere in memory. These smaller
parts are referred to as "hunks". The different hunks in a program are
joined together with some special information to form a loadable file.
Most normal program files consists of these specific hunk types:
Hunk_Header: Containing info about all other hunks.
Hunk_Code : Containing executable code and/or data.
Hunk_Data : Containing data.
Hunk_BSS : Containing "uninitialized" data, i.e. data space that the
program needs, but that isn't filled in before the program
is run. This shortens the load file, although the same
amount of memory is required to run the program.
Hunk_End : Marking the end of other hunks.
The Hunk_Data can also have BSS space appended to it at the end at load
time. There may be zero or more of each hunk type, although (for obvious
reasons) there must be at least one Hunk_Code present to run a program.
There should also be only one Hunk_Header, and this should be located at
the start of the program file.
Since these hunks can be anywhere in memory, AmigaDOS provide means for
the different hunks to know where hunks are located in memory. This info
is appended after each hunk that needs it, and is called a "Reloc-hunk".
Reloc is an abbreviation for "relocatable", and is called this because the
scatter-loading demands that hunks may be placed anywhere in memory.
There are six different types of reloc-hunks, of which three can be used
in executable programs:
Hunk_Reloc32: List of 32-bits modifications to be made to hunks.
Hunk_Reloc16: List of 16-bits modifications to be made to hunks.
Hunk_Reloc8 : List of 8-bits modifications to be made to hunks.
The number specifies the number of bits the data is referenced by, so that
a Reloc16 hunk will reference 16-bit data. As the Amiga has more than 64k
of memory, 32-bits references are almost always used (16-bits can only
address 64k), so we will most likely never see the Reloc16 and Reloc8 hunks
used. The Hunk_Reloc32's tells AmigaDOS which hunks it should modify, and
how to do it.
To further increase chaos, there are three other commonly used hunks that
we may encounter in a program file:
Hunk_Name : Gives a name to the following hunk. This is not really
useful for executable files, but is mainly used during
program development.
Hunk_Symbol: Contains information of the names that was used on data and
program routines during program development. This is only
useful for debugging a program (e.g. using WACK after a
Guru).
Hunk_Debug : Contains information that can be used by a debugger, but it
is not very useful unless you have the same debugger as the
guy who wrote the program.
These three hunks are not needed to run a program, and may be removed if
you don't want them.
Two special hunk types you may see are:
Hunk_Overlay: Specifies that the program should load in segments; that
means the whole file will not be loaded at once, as one
would usually expect. Instead some area of memory may be
overwritten by a new part of the program. This hunk will
then tell how to accomplish just this.
Hunk_Break: Signifies the end of a Hunk_Overlay section.
In addition to all these hunks, there are several more hunk types that
may be encountered, but as these are of no concern here, they will not be
covered by this manual. See the "AmigaDOS manual, Bantam Books" for
further information.
WHY HUNKFIX?
------------
When developing a program, developers usually use a "linker" to bind all
pieces of the program together to form an executable file. As these
linkers (and those who use them) are far from perfect, surplus information
is often stored along with the file. We, the users, often get files that
are bigger and crave for more memory than what is actually needed.
The Lattice development tools often gives us programs that contain empty
hunks, and the Manx development tools automatically adds 4 unused bytes to
all programs, making the load file 16 bytes larger than necessary.
HunkFix will try to remove the parts of load files that are not required
to run a program, thereby making the program smaller. It will also try to
rearrange the program parts so that "think time" during loading is reduced
to a minimum. As HunkFix will remove all unused parts of a program, it can
also be used to "chop" executable files that are received over modem. No
guarantees are given, though.
Note that HunkFix is NOT a cruncher or packer, and that HunkFix does NOT
break any rules made by Commodore (as far as I know). This means that all
programs that have been hunkfixed should function fine under all versions
of the O/S and with no special requirements (i.e. if the programs would do
so in the first place). But, as there is NO way to recover the original
file from an hunkfixed one, consider keeping backups of the files.
HOW TO USE HUNKFIX:
-------------------
To use HunkFix on a program, you have to enter the CLI or Shell environ-
ment of the Amiga. Then make sure that the file you want to fix really is
a loadable file that is NOT crunched or written in BCPL. (You may use
VScan by the same author to do this.) Then, if you decide to go on, use the
following command:
1> HunkFix InFile [OutFile]
Here "InFile" is the name of the file you want to fix, and "[OutFile]" is
the optional name of the file to create. If you don't enter an OutFile
parameter, the original file will be overwritten. NEVER DO THIS if you
don't have a backup of the file! Even though HunkFix will work fine on
almost all files, you MIGHT find files that won't function properly after
HunkFix has been employed on them. These files are most probably not
written after Commodore's specifications, but always keep backups of your
programs no matter what.
If you decide to stop HunkFix during execution, you may do so by holding
the keys CTRL and C down. Entering "HunkFix ?" or just "HunkFix" will give
you some short onscreen instructions.
Some examples of files that HunkFix will optimize:
C:Avail
C:SetPatch
most files in LIBS: (Yes, libraries are loadfiles!)
most files written with Aztec C or Lattice C
Itself :-)
Some files that should NOT be HunkFixed:
C:Install
All files crunched with TurboImploder(TM) 3.0
Files made with MultiForth (TM).
HOW HUNKFIX WORKS:
------------------
If commands are entered correctly, you will see something like this on
screen:
HunkFix version ?.?, ©1990 Arthur Hagen
Loading file XXXX
Filesize: ???? bytes
Runsize: ???? bytes
Program contains ?? hunks
Pass 1
Hunk #0: ???? bytes
Hunk_Code
Hunk_Reloc32
Hunk_Symbol removed
Hunk_End
etc...
Pass 2
Hunk #0:
etc...
Hunk total: ?? hunks
Hunks used: ?? hunks
Pass 3
Hunk #0: Reloc32 sorted
Hunk #4: Reloc32 sorted
Hunk #4: Reloc32 squeezed
etc...
Pass 4
Hunk #0: unchanged
Hunk #1: unchanged
Hunk #2: merged with hunk #1
Hunk #3: removed
etc...
Saving file YYYY
Writing hunk #?
Old filesize: ???? bytes
New filesize: ???? bytes
Task completed.
HunkFix will first load the entire program into memory. If successful,
it will then start working on the program in four passes.
Pass 1:
Here HunkFix will scan all hunks of the program to ensure that it
recognizes them. In addition, Hunk_Name's, Hunk_Symbol's and Hunk_Debug's
will be removed.
Pass 2:
Here HunkFix checks what hunks are actually needed to run the program,
and mark those that are needed with the hunk number they will receive in
later passes.
Pass 3:
Here HunkFix scans through all Hunk_Reloc32's, and sort their contents.
If several Reloc32 sections can be joined together to save memory, this
will also be done in this pass.
Pass 4:
HunkFix will now reshuffle the remaining hunks in the order that HunkFix
established in pass 2. All empty hunks will be removed, and the first hunk
to be loaded will always be hunk #0. If hunk #2 is a BSS hunk, and hunk #1
is a data-hunk, the BSS hunk will be merged with the latter.
After these four passes, if the program was changed in any way, HunkFix
will try to save the modified program hunk by hunk. You will receive a
progress report while HunkFix is saving, and should any error occur, this
will also be told.
ERRORS:
-------
You may find in certain cases that HunkFix aborts with an error message.
These error messages are explained below:
***ERROR - Empty file!
You have tried to use HunkFix on an empty file. Just delete the file
instead.
***ERROR - Hunk_Overlay (segmented program), cannot touch it!
Some programs may be written "segmented", i.e. they will not be loaded
in full at once, but partwise as segments are needed. These files are more
difficult to handle than others, and the current version of HunkFix will
not do anything to them to avoid damage.
***ERROR - Unknown hunk: 0x????????
HunkFix covers only the most commonly used hunks, but if it finds a hunk
that it doesn't recognize, it will abort with this error message. Note
that some programs that are "crunched" to reduce size also will generate
this error message. In this case it is most often because the crunched
programs doesn't follow the normal Commodore-approved file format. The
files themselves may run fine now, but maybe not under future versions of
the operating system.
***ERROR - AmigaDOS error #???
If the AmigaDOS encounters an error during program execution, HunkFix
will abort with this error message. Use 'Fault ???' to determine the exact
cause of the error. Missspelling a filename or having a write-protected
disk can lead to this error.
Greeting to everyone that has bothered to read this far!
*Art