When we write and compile a Delphi application, we typically generate an executable file - a standalone Windows application. Unlike Visual Basic, for example, Delphi produces applications wrapped in compact exe files, with no need for bulky runtime libraries (DLL's).
Try this: start Delphi and compile that default project with one blank form, this will produce an executable file of about 385 KB (Delphi 2006). Now go to Project - Options - Packages and check the 'Build with runtime packages' check box. Compile and run. Voila, the exe size is now around 18 KB.
By default the 'Build with runtime packages' is unchecked and every time we make a Delphi application, the compiler links all the code your application requires to run directly into your application's executable file. Your application is a standalone program and doesn't require any supporting files (like DLLs) - that's why Delphi exe's are so big.
One way of creating smaller Delphi programs is to take advantage of 'Borland package libraries' or BPL's in short.
What's a Package?Simply put, a package is a special dynamic-link library used by Delphi applications, the Delphi IDE, or both. Packages are available in Delphi 3(!) and higher.
Packages enable us to place portions of our application into separate modules that can be shared across multiple applications. Packages, also, provide a means of installing (custom) components into Delphi's VCL pallete.
Therefore, basically two types of packages can be made by Delphi:
- Run-time packages - provide functionality when a user runs an application - they operate much like standard DLLs.
- Design-time packages - used to install components in the Delphi IDE and to create special property editors for custom components.
From this point this article will deal with run-time packages and how they can help Delphi programmer.
One wrong mit: you are not required to be a Delphi component developer to take advantage of packages. Beginner Delphi programmers should try working with packages - they'll get better understanding of how packages and Delphi work.
When and when Not ot Use PackagesSome say that DLL's are one of the most useful and powerful features ever added to the Windows operating system. Many appplications being run at the same time causes memory problems in operating systems such as Windows. A lot of these programs perform similar tasks, but each contains code to do the job itself. That’s when DLLs become powerful, they allow you to take all that code off the executables and put it in a shared environment called a DLL. Probably the best example of DLLs in action is the MS Windows operating system itself with it's API - nothing more that a bunch of DLLs.
DLLs are most commonly used as collections of procedures and functions that other programs can call. Besides writing DLLs with custom routines, we can place a complete Delphi form in a DLL (for example an AboutBox form). Another common technique is to store nothing but resources in DLLs. More information on how Delphi operates with DLLs find in this article: DLLs and Delphi.
Before going on to comparison between DLLs and BPLs we have to understand two ways of linking code in an executable: static and dynamic linking.
Static linking means that when a Delphi project is compiled, all the code that your application requires is directly linked into your application's executable file. The resulting exe file contains all the code from all the units that are involved in a project. Too much code, you might say. By default, uses clause for a new form unit list more than 5 units (Windows, Messages, SysUtils, ...). However, the Delphi linker is smart enough to link only the minimum of code in the units actually used by a project. With static linking our application is a standalone program and doesn't require any supporting packages or DLLs (forget BDE and ActiveX components for now). In Delphi, static linking is the default.
Dynamic linking is like working with standard DLLs. That is, dynamic linking provides functionality to multiple applications without binding the code directly to each application - any required packages are loaded at runtime. The greatest thing about dynamic linking is that loading of packages by your application is automatic. You don't have to write code to load the packages neither you have to change your code.
Simply check the 'Build with runtime packages' check box found on the Project | Options dialog box. The next time you build your application, your project's code will be linked dynamically to runtime packages rather than having units linked statically into your executable file.