[comp.sys.atari.st] PACK vs. reserved header elements ?

roland@cochise (09/07/89)

In article <4756@brains.UUCP> george_seto%brains@iisat.UUCP writes:
>
>  I have tried both the PACK and the DC Squish(borrowed) on my STadel
>software and PACK would not work on those files at all.

   Just yesterday I also tried PACK and found it really useful - it
reduced e.g. Uniterm from 177 KB to 110 KB without noticable
functional differences.

   However, it did not work on most program, complaining about
"fout in header" ( I don't understand dutch ... )

I found out that most programs _linked by Turbo C ST_ have
a nonzero value in the _first 'reserved' longword_ in the header!


   Can anybody ( Allan, please! ) tell me what is the meaning of this field
   ( the longword following symb_size ) and/or why TC uses it ???


Anyway, I just patched those offending bits to zero, and could then
PACK even the TC-programs, e.g. TC.PRG itself from 202 KB to 148 KB.
Great! ( My HD is 95% full ... )

  -- Roland Rambau

rra@cochise.pcs.com

bammi@dsrgsun.ces.cwru.edu (Jwahar R. Bammi) (09/08/89)

In article <1051@pcsbst.UUCP>, roland@cochise writes:
>In article <4756@brains.UUCP> george_seto%brains@iisat.UUCP writes:
>>
>   Can anybody ( Allan, please! ) tell me what is the meaning of this field
>   ( the longword following symb_size ) and/or why TC uses it ???

if it is the second longword following symb_size that is non-zero, then
TC is using a (yet undocumented i guess) feature of TOS 1.4. If this
long has its lowest bit set, then when launching a process TOS will not
clear all of TPA, just the BSS area. If it is zero, then it will behave
as normal, ie. clear all of TPA including the BSS area of the process.
--
bang:   {any internet host}!dsrgsun.ces.CWRU.edu!bammi	jwahar r. bammi
domain: bammi@dsrgsun.ces.CWRU.edu
GEnie:	J.Bammi

stefan@spcc386.UUCP (Stefan Posthuma) (09/08/89)

roland@cochise writes:
>I found out that most programs _linked by Turbo C ST_ have
>a nonzero value in the _first 'reserved' longword_ in the header!

Programs assembled with DevPack in debugger mode will also give the
same error (which means "error in header" by the way). My guess is that
PACK cannot cope with a symbol table added to the program. I don't know
TurboC, but there must be an option to strip the executable.

BTW, I have a VERY good packing routine which I use to compress my demo
stuff and the ST NEWS stuff (30-35% compression).
If anybody wants to write a new PACK, I can send him the source (in assembler). 
Or maybe I'll do it myself if I can find the time.
-- 
--------------------------------------------------------------------------------
  "Oh my God, it is the attack of the Half-Crazed Mutant Teenage Alien Computer
Junkies!!"                                 +------------------------------------
  "Relax! It are just some SPCC employees" | uunet!mcvax!spcc386!stefan

jonah@db.toronto.edu (Jeffrey Lee) (09/09/89)

I've recently discovered that PACK refuses to work on files that
contain a symbol table.  I have written a simple Unix/C program that
copies a GEM program file stripping out the symbol table.  If anyone
is willing to ST-ify it I'll pass it along.  (I don't do development
on my ST--I cross-compile instead.)

j.