In this first part of a two-part article about Delphi Packages, we are going to discuss what packages are, and how they can aid in designing plug-ins for Delphi applications. We will also look at the disadvantages and advantages of creating a plug-in with Delphi Packages compared to DLLs. I'd like to send a word of thanks to the chaps on the Delphi news groups who pointed me in the right direction and made helpful suggestions.
According to the Delphi Help file: "A package is a specially compiled library used by applications. Packages allow you to rearrange where code resides without affecting the source code." In plain English, it means that a package is a place where you put code that your application can reference when it needs additional functionality. It is similar to a external unit, but with additional storage capacity. And because of that flexibility it allows you to divide or split your Delphi application into different parts, without necessarily diminishing or affecting it's core function. The core application can offer more or less functionality based on the absence or presence of a package.
A good example that demonstrates this point is commercial software that is distributed as a trial version with limited functionality. When the user buys the software, the distributor sends them another piece of software that will restore the application to full functionality. In a scenario like this, the second piece of software can be sent as a package and all that the core application would then do is search for that package to restore the application to a fully functioning state.
Delphi packages come in two types: design-time and run-time packages. If you've been using Delphi for some time, then you've probably used design-time packages at one time or another. Design-time packages are used to install components on the IDE's Component palette and to create special property editors for custom components. So if you've installed a component in the Delphi IDE, then you've used a design-time package. In this article, we will mainly be focusing on run-time packages, because they are the best method of creating plug-ins for our Delphi applications.
Run-time packages are not very different from Dynamic Link Library or DLL files. They usually contain a collection of code that is an integral part of an application, but not included in the application's executable. This has the obvious advantage of letting you update the package without updating the application itself. Another advantage is that the application as a whole becomes smaller in size due to some of its functionality and code being stored externally.
Delphi itself ships with run-time packages that are built for the VCL and that enable you to built your own applications. In fact Delphi would not be able to function without a run-time package called vcl70.bpl(for Delphi7); you will get a "cannot load VCL70.bpl" error if you try to run Delphi without it. If you go to Project|Options and then select the "Packages" tab, you will see a list of packages available.
I recently built a simple project with no run-time packages; its size was about 16KB. Then just to see what the size of an executable would be if built with run-time packages, I recompiled the same project with run-time packages included and it went up to 400KB. So you can see for yourself the advantage in using packages.
The only disadvantage to using packages is that the concept of a package is Borland or Delphi specific; the technology cannot be used by non-Delphi applications.