BPL vs. DLL in Delphi Programming Applications

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 (DLLs). 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 applications executable file. Your application is a standalone program and doesnt require any supporting files (like DLLs) - thats why Delphi exes are so big. One way of creating smaller Delphi programs is to take advantage of Borland package libraries or BPLs in short. Whats a Package? special dynamic-link library used by Delphi applications 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 Delphis 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. Design packages 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 - theyll get better understanding of how packages and Delphi work. When and when Not ot Use Packages 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 applications 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 doesnt 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 dont 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 projects code will be linked dynamically to runtime packages rather than having units linked statically into your executable file.