If you're building a large Windows application, you've probably placed portions of your code in Dynamic Link Libraries (DLLs). You may also be using the DLL version of the ObjectWindows Library (OWL).
Unfortunately, when it's time to ship the product, you
may not be clear about which DLLs you need to distribute with
your application. In this article, we'll show how you can
use TDUMP, a file-analysis tool that ships with Borland C++, to
determine which DLLs your application really requires.
If you're unfamiliar with TDUMP, it's a handy tool for analyzing several types of files. For example, TDUMP will display the symbolic debugging information in OBJ, EXE, COM, LIB, DLL, or TDS files.
The general syntax for using the TDUMP.EXE program is quite simple.
To display a full report about an executable file, DOH.EXE, you'd
enter
tdump doh.exe
When TDUMP displays information about an application, it parses the data into several sections. One of these sections, the Module Reference Table, contains the names of the DLLs that the application uses.
Once you've identified the names in the Module Reference Table that refer to DLLs that are part of Windows, you'll know the rest of them refer to DLLs you need to distribute with the application. For example, if you create a program that uses only the Borland Custom Controls DLL, you'll see that the table mentions the file BWCC.DLL, as shown in Table A.
Table A: Module Reference Table
| Module Reference Table | offset: 01BDh |
| Module 1: BWCC | |
| Module 2: GDI | |
| Module 3: KERNEL | |
| Module 4: USER |
If you don't distribute BWCC.DLL with this application,
the program will generate errors as soon as it tries to use one
of the Borland Custom Controls. Now let's see how you can
use TDUMP to analyze an application's DLL requirements.
Instead of creating an application and then analyzing it using
TDUMP, let's use TDUMP to generate a report about the Borland
C++ Integrated Development Environment (IDE) itself. (First, make
sure you're not running the Borland C++ IDE.) To create
the report, enter cd \bc45\bin to make the main Borland
C++ directory the default directory (you'll use cd \bc4\bin
for version 4.0 or 4.02). Then, enter
tdump bcw.exe > bcw.dmp
at a DOS prompt.
When the TDUMP utility finishes creating the report, launch the
IDE, choose Open... from the File menu, and enter
\bc45\bin\bcw.dmp
in the File Name entry field of the Open A File dialog box. Then, click OK. (If you're using version 4.0 or 4.02, you'll need to change the directory path of this command accordingly.)
When the new file editing window appears, choose Find from the Search menu. In the Find Text dialog box, enter Module Reference Table and click OK. Choose Search Again from the Search menu to locate the beginning of the Module Reference Table, as shown in Figure A.
Figure A - The Module Reference Table for BCW.EXE displays the names of all the DLLs that the Borland C++ IDE uses.
If you examine the DLLs that appear in the WINDOWS\SYSTEM directory,
you'll find the following files, which correspond to the
names in the Module Reference Table:
Of these files, only BWCC.DLL doesn't ship with Windows.
Therefore, if you were shipping the Borland C++ IDE as your product,
you'd need to redistribute that file along with the other
files that appear in the same directory as the BCW.EXE file. (By
the way, KERNEL is the module name for the KRNL286.EXE and KRNL386.EXE
files. Windows determines which of these files to use as it analyzes
your system at startup.)
Over the life of a project, you may use many different DLLs to
provide the project's functionality. By using TDUMP to
display a Windows application's Module Reference File,
you can be sure you know which DLLs to distribute with your application.
Copyright (c) 1996 The Cobb Group, a division of Ziff-Davis Publishing Company. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of Ziff-Davis Publishing Company is prohibited. The Cobb Group and The Cobb Group logo are trademarks of Ziff-Davis Publishing Company.