🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.mac
Article #18298

Re: BUG in LightSpeed C version 2.11 (THINK's answer)

#18298
From: David Phillip Oster
Date: Fri, 21 Aug 1987 00:03
55 lines
3232 bytes
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.
Technical Details
Message-ID: <20198@ucbvax.BERKELEY.EDU>
Path: arc1-ca.pugleaf.net!utzoo!mnetor!uunet!husc6!rutgers!ucla-cs!zen!ucbvax!dewey.soe.berkeley.edu!oster

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: arc1-ca.pugleaf.net!utzoo!mnetor!uunet!husc6!rutgers!ucla-cs!zen!ucbvax!dewey.soe.berkeley.edu!oster
From: oster@dewey.soe.berkeley.edu (David Phillip Oster)
Newsgroups: comp.sys.mac
Subject: Re: BUG in LightSpeed C version 2.11 (THINK's answer)
Message-ID: <20198@ucbvax.BERKELEY.EDU>
Date: Thu, 20-Aug-87 20:03:38 EDT
Article-I.D.: ucbvax.20198
Posted: Thu Aug 20 20:03:38 1987
Date-Received: Sat, 22-Aug-87 12:40:02 EDT
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster)
Organization: School of Education, UC-Berkeley
Lines: 52
Summary: Shows up only with an invalid mix of system and finder