Shari wrote: > This program is going to have several plug ins, or additions to it, > over a long period of time. Additions that will be sold separately > from the program. > > Rather than make someone download a brand new program every time he > wants to add a module, I had planned to set these additions up as > updates, that would patch into the program and make whatever changes > were needed, add images, sounds, and change the scripts etc. ... > That way, if 5 modules use Image AAA, and it's not in the main engine > as it wasn't conceived of until that particular module was created, > the module embeds Image AAA into the engine, and all modules > thereafter can use that image easily. (No I will NOT put images and > sounds into a separate folder for the world to steal. They will be > embedded.) > > As the MAIN CODE of the engine will be affected by each module, the > intention was to update it to include the modules as they came into > being. And the modules themselves would do the updating. Each > script would be versioned. And the latest script would overwrite the > older script. > > To expect someone to download the entire program every time you > release a module they want, is bad programming. That's not how it's > done. > > Any decent program has the ability to be patched. Especially for bug > fixes and so forth. To avoid making your users download the entire > thing. > > Apparently patching is not an option, unless as Scott mentioned you > are making such an amount of money that you can buy some second, > special license in addition to the first license. > > Does anyone have any specific ideas on how to deal with this?
Just move the code that needs to be patched into a separate stack file in your plugins folder. If you suspect you may want to change UI code as well, architect with that approach in mind: have your controls call routines in centralized libraries used as backscripts and/or "start using" stacks, and store those in your plugins folder as well. Most of the major software publishers use patchers that store binary dif info; they almost never patch individual lines of compiled code. And of course EXEs on Win and UNIX can't modify themselves at runtime. If you need to patch your EXE, using an installer like Wise Install (Win) or InstallerVise (Mac) will let you make such patchers. But I've gone that route in the past and it can get confusing for end users to keep track of which patch applies to which EXE. These days I tend to put relatively little code in my standalones, and break out as much as possible into centralized libraries. This can also simplify the day-to-day management of a large code base: I have one backscript for menu routines, one for file I/O, one for printing, etc. These are stored as buttons in a group in a stack file, with a startup handler that steps through the group and inserts each script into the backscripts. A similar approach could be done with "start using" libraries, with the additional benefit that such libraries get a message when they are brought into use and another when they are retired, allowing you conveniently encapsulate initialization and cleanup right into the library itself. The MC IDE does not provide access to libraries or backscripts directly other than in the Message Box (ugh). So I wrote a lil' utility that provides a popup list or current frontscripts, backscripts, and libs from a palette (with a few other conveniences as well): <ftp://ftp.fourthworld.com/MetaCard/mcAuthor2.4.mc.sit> It's very much an internal tool and accordingly lacks the polish I would prefer to put into anything designed for public consumption. Just the same, it can be such a time-saver that I make it available anyway, and update it periodically. -- Richard Gaskin Fourth World Media Corporation Custom Software and Web Development for All Major Platforms Developer of WebMerge 2.0: Publish any database on any site ___________________________________________________________ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc _______________________________________________ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard