At this point you are probably curious why you would choose a run-time package versus a DLL, or the other way around.

Packages differ from DLLs in that they are specific to Delphi, that is, applications written in other languages can't use packages created by Delphi. Even though a package is a special dynamic-link library used by Delphi applications, it provides more functionality to a Delphi developer.

In general we built DLLs in Delphi to store collections of custom procedures and functions that can be used by many applications and/or different environments. Packages can contain units with code, components and forms, but also Delphi classes - this enables us to write object oriented code. What Packages can and DLL's cannot is to store your complete custom Delphi components inside them.

Both DLLs and BPLs play a great role in code reduction. A primary reason behind using packages or DLL's is to reduce the size of your applications. This should lead to caution, of course. The packages and DLLs that you need to ship with your application can be quite large. Note that the you still have to distribute your packages; the primary VCL package, vcl50.BPL, is almost 2MB in size alone.

However, if you distribute several Delphi applications that share the same package, you might end up distributting less code. Consider the benefit of giving users the option of downloading smaller versions of the application when pieces of the application might already exist on their system (like standard Delphi BPLs).

This should certainly urge you to start deploying your project's over the Internet.

Packages save memory. As a result of dynamic linking, only one copy of the VCL resides in memory for all Delphi applications that use run-time packages.

Package Versioning Problem

When you want to update your DLL (change some function's implementation), you simply compile it, export some new routines and ship the new version. All the applications using this DLL will still work (unless, of course, you've removed existing exported routines).
On the other hand, when updating a package, you cannot ship a new version of that package without also updating the executable. As you will see, a package is nothing more than a collection of units. All the DCU files (compiled units) contain version information. This is why we cannot use a unit compiled in Delphi 7 in a Delphi 2006 project unless we have the unit's source. When we change something in the interface part of the unit all the units listed in the uses clause need to be recompiled. The compiler checks the version information of DCU's and decides whether an unit has to be recompiled. You cannot provide a package written in Delphi 2006 to be used by an application written in Delphi 7. Any package that you provide for your application must be compiled using the same Delphi version used to compile the application.

Therefore, when giving names to packages be sure to include the version of Delphi in the package name (like 'AboutDP_70' vhere 70 stands for Delphi 7). This will prevent any confusion with your package users as to which version of the package they have and to which version of the Delphi compiler they apply.

If you distribute run-time or design-time packages to other Delphi developers, be sure to supply both .DCP and .BPL files as well as all the .DCU files of the units contained in your packages.

Creating a Package

Creating a package is easy, but before creating a new package, you'll need to decide on a few things. Firstly, you need to know what type of package you're going to create: runtime or design or both. Second, create, debug, test and test again all the units you want to place in a package. Finally, you need to decide what will be the name of your newly created package and where you want to store the package project.
To create a new run-time package, folow these steps:

1. Start Delphi - this will result (by default) in an empty form and a new project (prior Delphi 2006). Select File | Close All to start from "nothing".
2. Select File | New... This will call the "New items" dialog box. On the "new" page double-click the Package icon. This will call the Package Editor. As you can see the Package Editor contains two folders: Contains and Requires.
3. Click the Add button, to add a unit (with custom component or a simple code unit). Notice that you add the PAS file, that is the unit's source not the compiled version of it (DCU). Add as many units as you want to the package. While you are adding units, their names are showing in the Contains folder. For this purpose try adding FindFile and PictureClip units.
4. Open the Requires folder. This list indicates the packages required by your package. At the minimum, your package need to refer to vcl.dcp which contains most of the standard VCL components.
5. When you are done adding units, click the Options button. In the Usage options group you select whether this package is design-time, run-time or both. Select Runtime only. This will create a run-time package. Other developers (users of this package) will not be able to install those two component on the IDE.
6. Use File | Save As to save Packages project file (DPK). Save the package as AboutDP70. The package naming is very important as you'll see later.
7. In the Package editor, click the Compile package speed button to compile your package.
8. If everything goes well your package is compiled and a package library (BPL file) is created. If you get a message indicating that you have to add some other packages (like VCLDB70), simply do so. Those packages will be listed under the Requires folder.
9. That's it. The Borland package library is created and waiting to be used.

In the Package Editor there is an Install button - used to install the current package as a design time package. Since our package is run-time only clicking on the Install buttton will not install those two components in the IDE.