Exploring A Single File Deploy on Windows

[Mark Waddingham]

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 ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps