sirkm@ssyx.ucsc.edu (Greg Anderson) (09/03/88)
I am working on an XCMD that uses very large libraries. If I tried to link it all into one segment, it would be > 32K, & thus would not fit inside a code resource. I could possibly split up the libraries into XCMDs of their own and use HyperCard callbacks to interface them at runtime. Is there a more elegant solution? Also, I'm a little bit unclear on the restrictions LSC 2.15 places on global variable usage. I thought that LSC would reference globals off of A4, but one part of the manual explicitly states that code resources cannot have any global variables. If this is the case, then what is LSC doing with the string constants I use in my XCMD? XCMDs *are* code resources, aren't they? ---------------------------------------------------------------- Greg Anderson Social Sciences Computing University of California, Santa Cruz email: sirkm@ssyx.ucsc.edu BBS: (408) 462-3832 2400/1200/300 baud
dan@Apple.COM (Dan Allen) (09/06/88)
In article <4695@saturn.ucsc.edu> sirkm@ssyx.ucsc.edu (Greg Anderson) writes: >I am working on an XCMD that uses very large libraries. If I tried to >link it all into one segment, it would be > 32K, & thus would not fit inside >a code resource. > >I could possibly split up the libraries into XCMDs of their own and use >HyperCard callbacks to interface them at runtime. Is there a more elegant >solution? What are you trying to do? For many applications it is better to keep the XCMD small and have it act as a funnel for requests to a DRVR. The XCMD would send the requests to a DRVR that could live in the system heap or wherever. The DRVR would be the grand central station. This method is especially good for controlling various devices like video disk players, CD-ROM drives, etc. Dan Allen Apple Computer
ech@poseidon.UUCP (Edward C Horvath) (09/07/88)
From article <16642@apple.Apple.COM>, by dan@Apple.COM (Dan Allen): > ...For many applications it is better to keep > the XCMD small and have it act as a funnel for requests to a DRVR. The > XCMD would send the requests to a DRVR that could live in the system > heap or wherever... > Dan Allen > Apple Computer OK, Dan, how do I do this legally? I don't see anyplace in "DRVR" space that I can LEGALLY install a driver of my own, at least from a reading of IM 1..5. What DRVR IDs are "legal" for this kind of use? =Ned Horvath=
dan@Apple.COM (Dan Allen) (09/09/88)
In article <488@poseidon.UUCP> ech@poseidon.UUCP (Edward C Horvath) writes: >OK, Dan, how do I do this legally? I don't see anyplace in "DRVR" space that >I can LEGALLY install a driver of my own, at least from a reading of >IM 1..5. What DRVR IDs are "legal" for this kind of use? Drivers 27-31 are reserved for an application's own use. It is somewhere in IM, probably the Driver chapter in volume 2. You could put such a driver in a stack, for example. This is why, by the way, that the Font/DA Mover only allows 15 DAs: 12-26. (These are all from memory-I may be one number off..) The never-shipped MacBasic had its own printer driver, for example, and it was ID 28 and lived inside the app. It worked fine. Dan Allen Apple Computer
ech@poseidon.UUCP (Edward C Horvath) (09/13/88)
Earlier, I'd written: >...I don't see anyplace in "DRVR" space that >I can LEGALLY install a driver of my own... To which dan@Apple.COM (Dan Allen) replied: > Drivers 27-31 are reserved for an application's own use. It is > somewhere in IM, probably the Driver chapter in volume 2. You could put > such a driver in a stack, for example. This is why, by the way, that > the Font/DA Mover only allows 15 DAs: 12-26. (These are all from > memory-I may be one number off..) The never-shipped MacBasic had its > own printer driver, for example, and it was ID 28 and lived inside the > app. It worked fine. Thanks, Dan, and yes, I knew about that. But it doesn't QUITE address the question. Two cases still not covered: - 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. - it has been suggested (in another newsgroup) that one might establish a DRVR at system startup ('INIT') time which could then be managed by a Control Panel ('cdev') item. But a cdev file is neither "installed" in the System file, nor is it an application. - IM 5 mentions expanding the Unit Table to 64, or even 128, entries "to accommodate slot drivers." It's not made explicit whether ONLY slot drivers go there, nor how those unit table entries are assigned. The problem should now be evident: DRVRs provide a convenient "lightweight process" that is generally useful, but there is no "unassigned pool" for non-DA non-Apple-assigned non-application-specific drivers to use. I'd happily remap "owned" resources, or even give them up altogether, in exchange for an arbiter that said something like "slot n of the unit table has been assigned for your use until shutdown (or until freed)." The model of an AppleTalk DDP socket is close to what I want here. I want a unit table slot, and my DCE maintained while I'm open, and my accRun routine called, etc., and I DON'T want to conflict with any other bonafide DRVR usage. Is there any way to be a "nice guy," or do I have to appropriate a unit-table entry and hope not to break anybody else? =Ned Horvath=
dan@Apple.COM (Dan Allen) (09/14/88)
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