Program Imports
When a program is built the linker works which DLLs to load that contains the required functions. The list of imported functions is then embedded in the PE file. Functions can be referenced by name or by number (ordinal). It is somewhat faster to load if functions are referenced by ordinal rather than name (e.g. I want function 46 of GDI.dll) as there is no need to look up names when loaded. There lies madness as the DLL you call may be upgraded and these numbers might be reassigned and the program will then almost certainly crash. However, with the invention of manifests it is now feasible to use ordinals again as the manifest will guarantee the correct version of a DLL will be used.
When the program loads, the loader 'fixes up' the functions declared in the import table with the actual function in the DLL. It replaces the call address in the loaded program with the actual function entry address. If the loader can not find a DLL or function that the program needs it will abort the loading and you may get an error message saying 'Faild to Load'.
Within Windows you'll see that the same set of Microsoft® system DLLs crop up again and again. The reason for '32' in these DLL names is historical it distinguishes the 32bit version from the previous 16bit version that did not have this number at the end.
| Kernel32.dll | All Windows programs must import this DLL. Kernel32 contains all the process and memory management that a program needs to operate. Without it a program could not run. It also contains file management functions as these are also essential to running programs. |
| User32.dll | This DLL contains the 'user interface' elements which include support for displaying dialog boxes, message boxes and all 'user' interface windows. A program that does not link to User32 is a 'console' application that does not have a Windows user interface. A minimal Windows application will have imports from Kernel32 and User32, many installation programs will have only these imports so that an installer will always be able to load even on systems that it can't work with - a user at very least deserves to be given a message to say it can't install on that particular system. |
| Gdi32.dll | If a program does any graphical or text drawing in Windows it will normally use GDI (Graphical Device Interface) to do the drawing operations. This is written to be graphics device independent, a program does not need knowledge of which graphics card is installed in order to draw on the screen. In addition the same interface can be used for printing and this greatly simplifies the process of writing applications that both draw on the screen and produce printed paper output. Basics line and text drawing functions are contained in it. |
| Comdlg32.dll | For some historical reason Microsoft put the interface to the standard dialog screens for opening files; printing files; selecting a font or colour into a separate DLL rather than incorporating them into User32. These 'Common Dialogs' offer little flexibility to applications. |
| Advapi32.dll | When 16bit Windows started growing beyond the categories of Kernel/User and GDI, Microsoft, chose the rather obvious name of 'Advanced API' for these 'extra' functions. The first set of functions that went in here were the System Registry access functions. |
| Comctl32.dll | Another enhancement to Windows came in the form of 'Common Controls' which added such things as list controls, property sheets, spin buttons and image lists. These were not standard with Windows NT 3.5 and had to be included as an upgrade. |
| Shell32.dll | If a program needs to be integrated into Windows in an intimate fashion it acts as part of the system rather than just an 'addition' it will probably use the 'shell' functions. The term 'shell' is borrowed from UNIX it represents the direct user experience as opposed to the 'kernel'. Within the Shell are functions to register file extensions; call up an editor based on file type (e.g. Internet Explorer for .htm files); or make any changes to the Shell (default printer, start menu, desktop...). It also contains the standard icons used in the user interface. |
| Mfc42.dll | Many windows programs you use (including parts of Windows itself) were written in C++ rather than C and used the Microsoft Foundation Classes (MFC) to provide a convenient C++ wrapper for the Windows functions. It also contains some intrinsic classes like text string manipulation. If a developer is silly enough to release a debug version of a program you may see an import dependency on mfc42d.dll (and msvcrtd.dll). Version 4.2 of Microsoft Visual C++ introduced this DLL and that is the reason for the name. |
| Msvcrt.dll | Back in the mists of the early days (1960s and 1970s) of the 'C' programs on UNIX systems a set of basic functions for string handling, file access, time functions grew up. Many windows programs use them as they are considered an integral part of the 'C' language, some programs have them statically linked and others save some space by linking to a shared Microsoft Visual C Run Time dynamic link library (hence MSVCRT). |
| Ntdll.dll | Most programs are designed so that they will run on either Windows 95/98/Me family of systems or the Windows NT/NT4/XP/Vista family. If a program uses some 'NT' (standing for New Technology) features it will link against Ntdll and not be able to be run on the 'old' versions. |
| Ole32.dll | One of the occasions that Microsoft took a wrong turn with the over-enthusiastic adoption of OLE (Object Linking and Embedding). It seemed a neat idea, if you want a spreadsheet in a document or a document within a spreadsheet then this wasn't originally possible. With OLE1.0 support was added so that an 'Excel' object could exist within a 'Word' document and vice-versa. To edit the spreadsheet within Word just double click and the application would turn itself into Excel for the duration of the spreadsheet editing and reverts back to Word when complete. Unfortunately at the time (twenty years ago) this turned out unreasonably slow and as often or not crashed or locked up the computer. From this OLE2.0 was born. Instead of documents you could have containers full of 'objects' with a much simpler and general interface than for OLE1.0. Once again it's a neat idea and for some, rather rare applications this turns out useful though it proved iendishly difficult to develop and debug large applications using it. So you'll see an import for OLE2.0 for quite a few Microsoft applications. |
Viewing Imports with InspectExe
InspectExe lets you list all the imported functions from any of the DLLs that a program needs :
