Externals and libraries ( was externals with MacOS)

[Dar Scott]

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
>> stack.
>
> 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 
(thanks, folks!).

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 
hide that.)

4.  The library stack can include the test and diagnostic cards for 
the external.

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.)

Dar Scott