On 2017-06-21 19:42, Richard Gaskin via use-livecode wrote:
One of the things I liked about SuperCard was that Bill Appleton had written his own resource fork into his data file format. This allowed SC to store any number of data and even code (XCMDs and DFCNs) within the data fork, without relying on the Mac's old file system resource fork.
Mac Classic was a decidedly simpler OS than modern OS's...
Would it be worth considering some means of being able to store externals directly in the stack file?
You mean like storing them in a custom property and spitting them out on startup into an appropriate folder (one which the OS clears out at appropriate times)?
What magic is dependent on having an external be a separate file on disk?
Dynamic linker magic - neither Windows nor Linux (where the 'problem' arises) have system APIs which allow shared libraries to be loaded from sections of a file. This is quite reasonable from an OS maker's point of view - after all, the point of shared libraries is that they can be shared.
Admittedly, systems like LiveCode use shared libraries for extensibility so the sharing aspect isn't actually all that interesting for this case.
However, the systems which don't have a 'bundle' type abstraction (i.e. Windows and Linux) have good stories for installation - there are numerous Windows Installer creators, and all Linux distros have their own package management system.
Couldn't the entry point for that code be found at least as easily (and perhaps slightly more efficiently) if stored within the stack file?
There's a lot more to it than that - a shared library is mostly linked, but the OS does a final link step at the point they are loaded. There are all kinds of things which go on there - resolution of dependent libraries, versioning, rewriting various bits of memory to ensure everything references the right addresses, allocated per-thread storage, etc.
Whilst it would be possible to do, it would be a huge sink of resources to solve a problem which has been solved by the relevant OSes in their own way - i.e. installers / packages. It would also be a huge maintenance burden - i.e. lets spend our time solving problems which haven't already been solved perfectly well.
Since 8, standalones have loaded their externals on startup - so no script runs before the standalone expects them to be where they should. One way to resolve this is to send a message *before* the externals are bound, allowing the 'spit out' solution to work again by intercepting standaloneSaving / Saved and handling an appropriate message on startup.
Warmest Regards, Mark. -- Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/ LiveCode: Everyone can create apps _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
