Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!rutgers!psuvax1!swatsun!jackiw
From: jackiw@cs.swarthmore.edu (Nick Jackiw)
Newsgroups: comp.sys.mac.programmer
Subject: Re: 68881 / no-68881 MPW C library linker problem
Message-ID: <KHCNYY@cs.swarthmore.edu>
Date: 31 Jul 90 14:29:29 GMT
References: <624@argosy.UUCP>
Reply-To: jackiw@cs.swarthmore.edu (Nick Jackiw)
Distribution: na
Organization: Visual Geometry Project, Swarthmore College, PA
Lines: 83

freeman@cleo.UUCP (Jay R. Freeman) writes:
> I support a shareware application with two versions.  One -- the
> "plain" version --runs on a Mac-Plus-or-better; the other -- the
> "fancy" version -- needs a 68020-or-better and a 68881-or-better.
> Both are written in MPW C, presently in version 3.1 thereof.
> Let me explain in more detail.  The Right Thing To Do would be to have
> the "fancy" routine put up a dialog box explaining why it has to exit,
> politely asking the user to use the "plain" version on that Mac.  So I
> thought "gee, surely the glue for dialog-box routines won't use 68881
> calls", but when I wrote code to put one up and tried to run it on a
> Mac Plus, it crashed with an "unimplemented instruction" error.  The
> same code ran fine on my Mac II.
> After a little experimenting, I found that (evidently) the glue for
> "SysBeep" does not use any non-68000 instructions, so what my "fancy"
> program does now is to beep three times and exit, with no message.
> The user has to read the (*gasp*) documentation to find out what's
> going on.  This "solution" is an unaesthetic kludge.  Clarus would
> surely disapprove.

I'm not sure I can offer a lot of help, but I believe you're incorrect
in diagnosing the dialog-box routines.  My application uses the same
strategy--quit quickly with a dialog if you don't have a chip--and has
no problems, though it took some tinkering to move other code, which the
compiler compiled with 68020 instrux, past the initial check-and-fail.

I'm using THINK Pascal 3.0.  Source code for legit operations (stuff
compiled with 68020 mode "on" but which does not generate 68020 instructions)
follows--note the call to StopAlert (which in turn is a call to ModalDialog).
I had to do the toolbox initialization
by hand (instead of using THINK's built-in initialization) to avoid
initializing a nonexistent math co-processor.

[In the following, "Halt" is a Pascal instruction equivalent to _ExitToShell,
and FPVersion is a compiler flag which is true if the compiler is generating
68020 code; false otherwise.  {$IFC}, {$ELSEC}, and {$ENDC} is your basic
conditional compilation based on the theticity of the FPVersion flag.}

 begin
  InitGraf(@thePort);
  InitFonts;
  InitWindows;
  InitMenus;
  TEInit;
  InitDialogs(nil);
  MaxApplZone;
  for i := 1 to 10 do
   MoreMasters;

{Read machine-specifics; set configuration flags appropriately}
  if SysEnvirons(1, theWorld) = noErr then
   begin
    HasCQD := theWorld.hasColorQD;
    hasChip := theWorld.hasFPU
   end
  else
   begin
    HasCQD := false;
    hasChip := false
   end;

{$IFC FPVersion}
if not hasChip then        	{Check whether the math chip is required}
   begin			{for this version of Sketchpad, or whether}
    i := StopAlert(needsFPU_ALRT, nil);	{a different version of Sketchpad could benefit}
    Halt			{from an installed FPU.}
   end
  else
   InitFPState;

{$ELSEC}
  if hasChip then
   begin
    i := DisplayAlert(hasFPU_ALRT, stopIcon);
    if i = Okay_tITEM then      {Okay means they want to quit and find the}
     Halt                       {version which supports their nice math chip}
   end;
{$ENDC}

-- 
-----Nicholas Jackiw [jackiw@cs.swarthmore.edu|jackiw@swarthmr.bitnet]-----
"Here is how I built this artificial mine. I snatched a female louse from the
hair of humanity. I was seen to lie with her on three successive nights, and
then I flung her into the pit."       _Maldoror_, Canto II