hull@hao.UUCP (Howard Hull) (11/05/86)
I just got through trying to compile iffdump.c and iffencode.c
using Lattice C 3.03 and got a couple of undefined link tags for
my trouble :-) I can't find checkbreak() or resetbreak() anywhere
in lib/include/ and they evidently are not in my.lib, amiga.lib or
lc.lib, either. There is a reference to them in Shell 2.01 "help".
Are these things in Lattice 3.04 (Arrrgh?).
I also checked both 3.20a Manx disks, but since my.lib (which has always
before been referenced by Matt with respect to the Lattice compiler) was
mentioned, I didn't think it would be in the Manx stuff.
I did get the iffencode.uue and iffdump.uue decoded and downloaded with
Kermit using Wecker's Wonder VT100 (Thanks, Dave - VT100 is the best little
piece of software in *or* out of Texas!). However, I was curious about the
missing routines. Another (probably related) difficulty is that the
sources distributed on the the net for my.lib seem to compile to a
different byte count than the uudecoded my.lib included in the package.
The compiled library is 11680 bytes, whereas the decoded library is
12052 bytes. I have done the compile twice (all day job, guys), and
finally even made a somewhat awkward monster lmk makefile to assure
that I didn't leave something out, and to assure that the process
would be not only repeatable, but subsequently easier.
Shell V2.01, when compiled with the shorter library, just hangs with the
disk drive light on when I try to do a cat of a text file. It works
ok with the longer library. Curiously enough, the working shell is 26864
bytes, whereas the one that hangs is 26860 bytes (both were generated on
the Amiga). So you are wondering, since I have a copy of shell that works,
what am I complaining about? Well, if I want to learn by tinkering with the
code, I can't do so well with the one for which I have the source, since
from the start, it doesn't work.
Annnyway, as an additional matter, if someone would be kind enough, I'd
appreciate an e-mail copy of the Thomas Spencer et. al. btoa.c SOURCE from
the compress directory on Fred Fish #6. Only one of the machines I work with
here has Kermit, and Xmodem pads downloaded binaries so that they can't
be recognized by the Amiga loader. I don't have fixobj from Fish Disk #10
with which to clean up the ends. According to Mike (I'll be mellow when
I'm dead && Don't have the strength to leave) Meyer, it may not work anyway.
He states that his binary downloads have a difference of only 1 byte by count
from the decoded ones, yet they won't load. They don't seem to respond after
treatment by fixobj, either. If he hadn't gotten this problem consistently
through both Xmodem and Kermit, I would have sworn that the transfer program
was dropping an entire block out of the start or the middle, then padding
the end with the dreaded dinosaur CP/M CR/LF+7E^Z's.
With btoa.c, I could compile on the Integrated Solutions machine
and download the binaries from any machine on which I might generate them.
(I already have the Amiga executables for atob and btoa that a friend got
for me from Fish Disk #6, and I got the atob.c source from the Usenet
distribution of Toebes' Hack. Too bad he didn't throw in btoa.c, too,
but probably excluded it because it wasn't necessary and might have confused
someone).
Thanks in advance for any help...
Howard Hull
[If yet unproven concepts are outlawed in the range of discussion...
...Then only the deranged will discuss yet unproven concepts]
{ucbvax!hplabs | decvax!noao | mcvax!seismo | ihnp4!seismo} !hao!hull