Path: news.weeg.uiowa.edu!news.uiowa.edu!uunet!wupost!waikato.ac.nz!comp.vuw.ac.nz!actrix!David.Empson
Newsgroups: comp.sys.apple2
Subject: ShrinkIt GS 1.1 (cont.)
Message-ID: <1992Oct12.134022.13760@actrix.gen.nz>
From: David.Empson@bbs.actrix.gen.nz
Date: Mon, 12 Oct 1992 13:40:22 GMT
Sender: David.Empson@actrix.gen.nz (David Empson)
Organization: Actrix Information Exchange
Lines: 36

Further to my previous posting [which, knowing UseNet, most of you
will probably see as my NEXT posting :-)] I've managed to get a
working copy of GSHK 1.1 by copying just the NuFX archive out of
the SEA file, and using the existing version of GSHK to extract it.

I then used this to create a new self extracting archive of GSHK,
which launched perfectly happily.  My first assumption was that the
original had a corrupted header (the self extracting code).

However, doing a byte-by-byte comparison of the original archive and
replacement one, the only differences were in the NuFX segment header
(dates?) and file length.

BINGO - GSHK11.SEA was 9 bytes too long.  It turns out that SSCII had
rounded the file up to the nearest 16 byte boundary.  In effect, there
was a partial header for an extra segment, which means the IIgs System
Loader didn't like the file.

This problem only applies to SSCII.  The archive was the correct length
when extracted with GSCII+ (the NDA) or BINSCII (the ProDOS-8
application).


Derek Taubert, where are you?  Fix this problem in SSCII, please!!!
I'm running version 2.3 - March 1992.


Andy - a slight bug in the SEA file: in the header for the 'archive'
segment, the 'displacement to data' field has a value which is one too
high (it should be $3E, not $3F).  This made DumpOBJ miss the $F2
(LCONST opcode) and it got very confused.
-- 
David Empson

Internet: David.Empson@bbs.actrix.gen.nz    EMPSON_D@kosmos.wcc.govt.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand