Bundling an External into a Windows EXE?
ambassador at fourthworld.com
Mon Nov 21 17:43:12 CET 2016
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
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
> 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?
More information about the use-livecode