A-Level Computer Science / Unit 5: System Software and Program Translation

5.1.4 Reusing Code with Program Libraries and DLLs

🔒 Lesson slides are available to signed-in users. Sign in

5.1.4 Reusing Code with Program Libraries and DLLs

Large programs are rarely created by writing every instruction from the beginning. Developers combine their own code with existing routines that already solve common or specialist problems. These reusable components are organised into program libraries.

By the end of this section, you should be able to:

  • Describe a program library as a collection of reusable routines.
  • Explain how code reuse can reduce development and testing time.
  • Outline how object code and library code are connected during a compiled build.
  • Compare including library code in an executable with using a Dynamic Link Library.
  • Evaluate the storage, memory, maintenance and reliability implications of DLLs.
Program library: an organised collection of reusable program routines that can be called by other software.

Why Reuse Code?

Imagine a school develops three programs: an event-booking system, a certificate generator and a club-registration portal. Each program needs to create a QR code. Writing three separate QR-code routines would repeat the same design, coding and testing work.

Writing the feature repeatedly Using one library routine
Each team designs its own algorithm. The teams call the same documented routine.
The same feature is tested several times. Testing effort can focus on integration and unusual inputs.
Different versions may behave inconsistently. The programs can produce results using one shared implementation.
Fixes must be repeated in several code bases. A maintained library can provide a common correction.
Exam tip: Explain the developer benefit, not only the technical feature. For example, reusable code reduces the amount of new code that must be written and tested, so development can be completed more quickly.

Program Libraries and Library Routines

A library contains components designed to perform defined tasks. A component may be a function, procedure, class or another compiled routine, depending on the programming language and library.

Library routine: a reusable block of code with a defined purpose and interface that another program can call.

The programmer normally needs to know the routine’s interface—its name, required arguments and returned result—but does not need to rewrite its internal algorithm.

Example library area Possible routine What the calling program supplies or receives
Date and time Format a date for display Supplies a date; receives a formatted string.
Graphics Resize an image Supplies an image and dimensions; receives a resized image.
Security Calculate a cryptographic hash Supplies data; receives a fixed-length hash value.
Data processing Sort a list Supplies a collection; receives or produces an ordered collection.
Common mistake: A library is not normally a complete application. It provides components that other programs use.

Benefits to the Developer

Benefit How it helps Important qualification
Faster development Less new code must be designed, written and debugged. The developer must still learn how to call the routine correctly.
Previously tested code A mature routine may already have been exercised with many inputs. “Previously tested” does not mean “guaranteed to contain no faults”.
Specialist implementation Developers can use complex features written by subject specialists. The routine must be suitable for the program’s requirements.
Consistency Several programs can use the same rules and produce compatible results. A change to a shared routine can affect every dependent program.
Reduced maintenance duplication A correction can be made in one maintained component rather than rewritten repeatedly. This advantage is strongest when programs use an updated shared library.
Common misconception: Library code is not automatically reliable simply because it has been reused. Its source, testing, version and compatibility still matter.

Including Library Code in Each Executable

One approach is to place the required library routine inside the executable during the build. This is commonly called static linking. The resulting program carries its own copy of the routine.

Consequence Explanation
More self-contained The program does not need that routine to be supplied as a separate DLL at run time.
Larger executable The routine’s code is stored inside the program file.
Duplicated storage Several programs may each store an identical copy of the same routine.
Possible duplicated memory use Several running programs may load separate copies of the routine.
Updates require rebuilding or replacing programs A corrected routine is not automatically inserted into existing executables.
Static linking: including the required library code in the executable before the program runs.

Dynamic Link Libraries

A Dynamic Link Library (DLL) keeps compiled library routines in a separate file. The executable contains references that are resolved when the program is loaded or while it is running.

Dynamic Link Library (DLL): a separately stored library of compiled routines that programs can link to at run time.
Potential benefit Why it occurs
Smaller executable files The full routine does not need to be copied into every executable.
Reduced duplication in storage Several programs can refer to the same separately stored library.
Reduced memory duplication Several processes may share one loaded copy of a DLL routine.
Central update Replacing a compatible DLL can provide a correction or improvement to dependent programs.
Exam tip: Do not write only “DLLs save space”. Explain that programs refer to one separately stored routine instead of each containing a full copy.

Worked Comparison: Three Programs Use One Routine

A school software suite contains three executables. Their own code occupies 680 KiB, 760 KiB and 910 KiB. Each program also needs the same 140 KiB report-export routine.

Approach Illustrative storage calculation Total
Routine copied into every executable (680 + 140) + (760 + 140) + (910 + 140) 2770 KiB
One separate DLL 680 + 760 + 910 + 140 2490 KiB
Illustrative saving 2770 − 2490 280 KiB

This simplified calculation ignores the small references stored in each executable. The saving arises because one routine is stored once instead of three times.

Common mistake: A DLL does not remove the routine from storage. It reduces duplication by storing one separate copy that several programs can use.

Dependencies, Versions and Failure Risks

Dynamic linking creates a dependency: the application expects a suitable DLL to be present and to provide the routines it requires.

Problem Possible consequence
DLL is missing The application may fail to start or a feature may be unavailable.
DLL is corrupted Calls to the routine may fail or produce incorrect behaviour.
Incompatible version is installed The expected routine name, arguments or behaviour may not match.
A faulty update is distributed Several dependent programs can be affected at the same time.
Security weakness in a shared routine Every program that uses the vulnerable routine may inherit the risk.
Common mistake: “Updating one DLL updates every program” is only an advantage when the replacement remains compatible and works correctly.

Interactive: Static Linking vs DLL

The existing widget has been retained. Switch between a copied routine and a shared DLL, then test what happens when programs run, the routine is updated or the shared library develops a problem.

Common Mistakes and Misconceptions

  • Library = application: a library supplies routines to applications; it is not usually a complete user program.
  • Object code = finished executable: external references may still need to be resolved by linking.
  • DLL copied everywhere: a DLL remains separate and is linked to at run time.
  • DLL removes all copies: it reduces duplication, but the DLL still occupies storage and must be loaded for use.
  • Shared update is always beneficial: a missing, faulty or incompatible update can affect several programs.
  • Reused code cannot contain bugs: prior testing improves confidence but does not provide a guarantee.

Practice

Try these original questions

  1. Define the term program library.
  2. Explain two benefits to a developer of using a previously tested library routine.
  3. Distinguish between object code and a complete executable program.
  4. Explain why linking may be needed after compilation.
  5. Describe one benefit and one drawback of copying a routine into every executable.
  6. Explain two ways in which a DLL can reduce duplication.
  7. Explain why replacing one DLL can be both convenient and risky.
  8. Four applications use the same 95 KiB routine. Calculate how much routine storage is avoided by storing one DLL instead of four separate copies. Ignore reference data.
  9. A program works on one computer but reports that a required library cannot be found on another. Explain the likely cause and identify the linking approach being used.
  10. A student writes, “Libraries remove the need to test software.” Correct the statement.
Exam tip: In a comparison answer, organise points under storage, memory, updating and dependency. This produces clearer development than an unstructured list.

Review

Concept Secure understanding
Program library A collection of reusable routines with defined interfaces.
Developer benefit Less code to create and test, access to mature or specialist implementations.
Linking Resolves references between object modules and required library routines.
Static linking Copies required library code into the executable before execution.
DLL Keeps routines separate so several programs can link to them at run time.
DLL trade-off Reduced duplication and easier central updates, but dependence on a compatible working library.
Final check: Can you explain why a shared DLL may save resources and also create a single point of failure?