Externals and libraries ( was externals with MacOS)
dsc at swcp.com
Thu Jul 4 10:41:01 EDT 2002
On Thursday, July 4, 2002, at 03:31 AM, Ben Rubinstein wrote:
> on 3/7/02 4:46 pm, Scott Raney at raney at metacard.com wrote:
>> The CODE resource needs to be placed *in the stack file*, not in a
>> separate file. Note that this is only true for MacOS: all other
>> platforms (including the Mach-O OS X engine) the external is stored as
>> a separate file which is found using the "externals" property of the
> Interestingly, this means that the externals system is more flexible on
> MacOS than on the other platforms (unless I've got the wrong end of the
> stick) because you can put the external into a stack, and then
> 'start using'
> that stack at any time during the life of your standalone; whereas
> on the
> other platforms the externals are only located at startup.
Well, since Brian and Scott mentioned what needed to be done I've
been forming a question of style or common practice, so I'm glad
you brought this up. This fits into my questions about libraries
Because of this MACOS requirement, I wonder if every external might
best have its own stack. Or in other words, every library is a
stack whether it uses an external or not.
I think this has some advantages:
1. Some platforms and/or future versions of Revolution may not
need the stack.
2. A library stack is used on all platforms.
3. The stack can provide some sugar coating and range & syntax
checking. (I'm just getting started with externals and the best I
can tell only binary strings that might have nulls cannot be passed
or returned directly used with external functions or commands;
indirect communication through variables is needed. A handler can
4. The library stack can include the test and diagnostic cards for
5. This allows the developer to mock up some designs in Transcript
and then move those portions to the external as needed.
6. The stack can handle the setup and shutdown functions for the
external. (Hmmm. What handlers? preOpenStack? OpenStack?
startup? libraryStack? And closeStack? Some other handler to
shutdown the external?)
I there something that would keep this from working?
Ben, I, too, have been thinking of the idea of the standalone
creating needed files if they are not there. They can be
compressed and stored in properties. This can be generalized to
all files whether dlls, stacks, text files or whatever. To the
stack of the standalone, maybe these can be simply files; it
doesn't have to know that some are DLLs. If the files get big, it
might be better to create an installer that does this.
It is not completely clear to me when the DLL external is loaded on
Windows. I think when stack is opened. I'm not sure what this
means, but I would guess that "start using" will do that. Is that
true? Does a stack have to be visible to be opened? I don't know
whether this is before or after the startup handler is called, but
I would assume before. Based on all those assumptions, I would
guess your idea might work. It might require spitting out the
library, too. (As you can see, I'm being too lazy to run the
experiments, preferring to hear from experience first.)
More information about the Use-livecode