Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!apple!dan
From: dan@Apple.COM (Dan Allen)
Newsgroups: comp.sys.mac.hypercard
Subject: Re: Creating very large XCMDs
Message-ID: <17106@apple.Apple.COM>
Date: 14 Sep 88 07:08:26 GMT
References: <16848@apple.Apple.COM> <498@poseidon.UUCP>
Reply-To: dan@apple.com.UUCP (Dan Allen)
Organization: Apple Computer Inc, Cupertino, CA
Lines: 28

In article <498@poseidon.UUCP> ech@poseidon.UUCP (Edward C Horvath) writes:
>- a driver in a stack is NOT a driver in "an application."  I still have the
>problem that if I ship a driver (say ID 28) in my stack, and next week
>Apple ships HC 2.0, with its own printer driver at...OOPS! ID 28! then I'm
>broken.  No doubt MacDTS will take a "strict interpretation" of IM 2.

If HyperCard ever has a DRVR 28 (and I doubt that it will, but you never
know) and you had a DRVR 28 in a Stack, your driver would be found first
via the Resource Manager's search path.

>- IM 5 mentions expanding the Unit Table to 64, or even 128, entries "to
>drivers go there, nor how those unit table entries are assigned.

The Unit Table is expanded on the Mac II, perhaps the SE, and I don't
think it is on a Plus.  I need to check for sure... But in any case I do
not see a problem: use say, ID 28 in your stackware product and as long
as your stack is in use, HyperCard will find and use ID 28.  Perhaps we
should guarantee that certain DRVR IDs will never be used by HyperCard
so that stackware developers will always have a free DRVR slot.

Your comments about DRVR IDs in general are good, but I do not know when
we will be able to change the situation.

I wish I could make some official statement that would fix your problem
but I am not an official spokesperson on the subject.

Dan Allen
Apple Computer