Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!xanth!mcnc!rti!sas!walker
From: walker@sas.UUCP (Doug Walker)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Help.  Lattice & UnHunk
Message-ID: <1282@sas.UUCP>
Date: 16 Oct 89 13:53:18 GMT
References: <1602@tellab5.tellabs.CHI.IL.US> <6437@ingr.com> <1259@sas.UUCP> <6713@ingr.com>
Reply-To: walker@sas.UUCP (Doug Walker)
Distribution: na
Organization: SAS Institute Inc, Cary NC
Lines: 33

In article <6713@ingr.com> phil@ingr.UUCP (Phil Johnson) writes:
>Doug; I called SAS about two years ago and ask if they were considering the
>port.  I was told that there was no reason to port the SAS product to an Amiga
>class machine.  When I asked the gentleman what he meant, he replied "The
>Amiga is a nice game machine, but not business quality."  If it were not for
>the quality of John's compiler I would never do business with any business
>unit of the SAS institute.   [When I mentioned the above conversation to
>Jay Denebem, I was told that it was probably some suit that just picked up the
>phone.  Still seems to reflect a strange attitude]

Two years ago hardly anyone had heard of the Amiga, and fewer had seen one.
Even today, the stigma of a game machine lingers.  However, if enough people
called and requested an Amiga port, marketing could not ignore the interest.
There is already sufficient interest in the technical area to get it done,
but we can't do it without enough end-user interest;  and the ONLY way we
have to determine if there's end-user interest is via requests from end-
users.  Unfortunately, these requests must come through marketing, which is
(obviously) not the most competant group to evaluate a machine's possibilites.

>converting to C, but the code generated just wasn't right.  I didn't use the
>Amiga startup code, but maybe I screwed up my libraries.  Another problem
>could be in the linking process.  Any suggestions.

You can't modify any extern or static data;  check your library for that.
If you try, you're trying to modify the ROM.  This pretty much rules out
using malloc/free for memory management, at least if it adheres to the
full UNIX spec, since all memory must be returned on exit and this 
requires a global.  Similar problems exist with many other library
routines.  Best thing to do is to avoid using library routines.  Since this
is not entirely practical, when you do use them, BLINK your object modules
with the MAP option and look at what externs are getting pulled in.

--Doug