freeman@argosy.UUCP (Jay R. Freeman) (07/27/90)
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.
I want the "fancy" version to shut itself down gracefully when some
poor user ignores the "READ ME" file and tries to run it on a Mac with
no 68020/68881. I know to set the MPW C compiler flags to generate
plain vanilla 68000 code when compiling the files related to startup,
but there is a problem with MPW C library routines: What I want to do
is use library routines from the "plain vanilla" C libraries for
exiting gracefully, but use library routines from the libraries
compiled to use 68881 hardware during the rest of the program. (After
all, the purpose of having a "fancy" version of the application is to
use all that good stuff.) I can't figure out a way to do this with
the linker. Am I missing something obvious? Something subtle?
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 could always write my own glue in assembler, and perhaps I will get
around to doing that sooner or later, but I thought the problem might
be sufficiently generic that someone on the net would have a way to
solve it from MPW C or from the MPW linker.
(For the record, I would also be curious as to whether Think C
provides a way around this kind of problem.)
-- Jay Freeman, Crufteur Magnifique
<canonical disclaimer -- I speak only for myself>jackiw@cs.swarthmore.edu (Nick Jackiw) (07/31/90)
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