oster@dewey.soe.berkeley.edu (David Phillip Oster) (08/09/87)
In THINK's haste to be compatible with the possibilities of the
future, they've made LightSpeed C incompatible with the actualities of
the past.
There have been complaints, here on the net, that the start-up code
executed by LightSpeed C before it calls your main() procedure looks
at the high bits of a handle, and that while that works for
all existing Macintoshes, if Apple were to change the format of
handles, it would stop working. Well, THINK changed LightSpeed
C's start-up code, and in the process broke LightSpeed C for old
Macintoshes.
The new start-up code does an HGetState() to find out if a handle is
locked or not. It does this _without_ doing the check that the system
call HGetState() is in fact defined. So, run a program compiled in
LightSpeed C version 2.11 under System file version 2.0, and Boom! You
get the bomb alert with a DS code of 12 = "Unimplemented Core Routine".
THINK, we need a new version fast. Your customers have products to
ship, and those products will crash right now if their customers are still
using the old System file.
You can get the crash on a MacPlus with system file version 2.0,
Finder 4.1. I've tested and traced this one. You can probably also
get the crash on a 512k unenhanced Mac, a 128k Mac or a MacXL, but I
don't have those handy to test on.
--- David Phillip Oster --My Good News: "I'm a perfectionist."
Arpa: oster@dewey.soe.berkeley.edu --My Bad News: "I don't charge by the hour."
Uucp: {seismo,decvax,...}!ucbvax!oster%dewey.soe.berkeley.eduoster@dewey.soe.berkeley.edu (David Phillip Oster) (08/21/87)
References: >From: singer@harvard.harvard.edu (Andrew Singer) To: oster@dewey.SOE.Berkeley.Edu Subject: Re: BUG in LightSpeed C version 2.11 In a previous posting, "oster@dewey.soe.berkeley.edu (David Phillip Oster)" wrote: } In THINK's haste to be compatible with the possibilities of the } future, they've made LightSpeed C incompatible with the actualities of } the past. } } There have been complaints, here on the net, that the start-up code } executed by LightSpeed C before it calls your main() procedure looks } at the high bits of a handle, and that while that works for } all existing Macintoshes, if Apple were to change the format of } handles, it would stop working. Well, THINK changed LightSpeed } C's start-up code, and in the process broke LightSpeed C for old } Macintoshes. } } The new start-up code does an HGetState() to find out if a handle is } locked or not. It does this _without_ doing the check that the system } call HGetState() is in fact defined. So, run a program compiled in } LightSpeed C version 2.11 under System file version 2.0, and Boom! You } get the bomb alert with a DS code of 12 = "Unimplemented Core Routine". } } THINK, we need a new version fast. Your customers have products to } ship, and those products will crash right now if their customers are still } using the old System file. } } You can get the crash on a MacPlus with system file version 2.0, } Finder 4.1. I've tested and traced this one. You can probably also } get the crash on a 512k unenhanced Mac, a 128k Mac or a MacXL, but I } don't have those handy to test on. The fact is that you're not supposed to use a Mac+ with anything less than System 3.0 (or, better yet, System 3.2). System 2.0 knows nothing about the new ROMs, and can only be expected to clash with them at times. In this case, even though bit 15 of ROM85 is clear, the dispatch table entry for HGetState points to code in ROM that does an immediate SysError(12). Yes, HGetState could be specifically checked for like SysEnvirons as described in TN #129, but SysEnvirons is *expected* to be a RAM-based trap whose presence is System-dependent, not ROM-dependent. HGetState is guaranteed to be in every ROM except for the original 64K ROMs. The only reason checking ROM85 fails here is because of a System/ROM incompatibility. Moral of the story: If you want to test for System 2.0 compatibility, you had better test it on a 64K ROMs machine! Jon Hueras THINK Technologies, Inc.