Thanks for that Max. The unfortunit thing IS, the app. HAS to be modular, and using security in one exe is something we have use before, but in this case its not an option. Mainly because we will be adding "Units" as we go along. This is not ideal obviously, but we need a quick and dirty solution thats going to work, and then that will not require us to do more coding to include the menu items or what ever. Thats why the plug in solution will be good. ---Futher to the above, we have decided, screw it, all the places its going to are on ADSL so its not an issue the size of the distributable, so that solves that issue :-)
Jeremy -----Original Message----- From: "Max Nilson" <[EMAIL PROTECTED]> To: Multiple recipients of list delphi <[EMAIL PROTECTED]> Date: Tue, 3 Jun 2003 10:00:25 +1200 Subject: RE: [DUG]: Modulizing Apps. with Packages > Jeremy Coulter bemoaned: > > > SO, can I do the above slightly differently so I can just distribute > the > > EXE without have to also send out the runtime BPL's too? > > Or am I better to use some 3rd party plugin tool? > > I have done some experimenting in this area of distribution and have a > few > observarions that you may be intersted in. > > If you want to do a purely delphi based distribution using minimal > packages > you have only one solution available. The only structure that seems to > work > easily is to create one minimal executable, one (or perhaps more) > shared > library package containg all of the VCL, ADO and other run time DCU's > you > need to share between the executable and other packages, and N modular > packages that utilise the shared library and perform some sorrt of > registration function(s) when loaded. > > I prefer this design as it allows careful control of what goes into the > library and is shared, and what is not and is duplicated when needed > into > each of the packages. > > The down side is that the library package is going to be big, as it > will > need large chunks of the VCL and other support code and will probably > end up > about the same szie of the VCL packages anyway. > > Going with a third party plug in solution, or indeed on of your own, > means > that reuse of any base library code is complicated, oe impossible. If > the > design of a generic plug in one then it will be purely DLL based with > simple > API's that don't allow for Delphi shared libraries, only shared DLL's. > If it > is a Delphi based plugin design that you are just getting some one else > to > do the plumbing. > > The decision between Delphi based packages, or old style DLL (or COM ) > based > is going to hinge on if the extentions are doing GUI extentions to the > application, or purely lofic extentions. The GUI stuff works lost > cleaner if > you let Delphi do the work, and the logic extention are smallest and > cleanest if they are minimal DLL's. > > After looking at all this and doing some work I decided that the best > way > foward was one honking big EXE (well 9MiB isn't all that big) and > internal > code to determine what stuff the user had access to. Makes life very > simple > to manage, is smaller that lots of packages, and means that updates are > one > compressed files that needs to be installed. > > Cheers, Max. > > ----------------------------------------------------------------------- > ---- > New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] > Website: http://www.delphi.org.nz > To UnSub, send email to: [EMAIL PROTECTED] > with body of "unsubscribe delphi" > Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/ --------------------------------------------------------------------------- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz To UnSub, send email to: [EMAIL PROTECTED] with body of "unsubscribe delphi" Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/
