Bundling an External into a Windows EXE?

[Richard Gaskin]

That's one thing I miss from SuperCard:  externals were embedded within 
the executable so we could deliver truly stand-alone standalones.

I'm not necessarily advocating that LC do the same, but for those of us 
whose projects benefit from single-file deliverables it may make for a 
useful community project to find a way to load them from being part of 
the EXE file without requiring them to be first written to disk as a 
separate file.

-- 
  Richard Gaskin
  Fourth World Systems


Bob Sneidar wrote:
 > I'm going to venture to say no. The whole point to having a dynamic
 > linked library is to have it be external to the application, so that
 > any updates to the dll can be accomplished without completely
 > recompiling the exe. Also, they are designed to be used as shared
 > libraries for other apps needing the same functionality.
 >
 > Ideally, Livecode would put these "dll's" in the apData folder of the
 > user, or in a folder where all drivers are accessible, but sandboxing
 > has essentially made that impossible, or at least highly problematic,
 > with the very real possibility that the next OS version will make it
 > impossible.
 >
 > So into the app folder they go, because LC knows that at least it
 > *should* always have access to that one folder. At least that is how
 > I see it.
 >
 > Bob S
 >
 > On Nov 18, 2016, at 10:55 , Paul Dupuis wrote:
 >
 > Does anyone have any tricks to bundle an external (revZip in my case)
 > into the EXE built by the Standalone maker?
 >
 > Once really nice thing about the OSX app bundle (a special folder the
 > OS treats as a bundle) is that if a use drags an app somewhere,
 > everything that belongs to it moves with it. Certain resources, like
 > icons, can be bundled into the EXE, using various Windows resource
 > editor tools, so that has led me to wonder if there are any tricks to
 > folding the dll of an external into the exe in a way that the
 > LiveCode engine can find it?