Program Imports

When a program is built the linker will work out which DLL contains which function. 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 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 which version of a DLL will be used.

When the program then loads, the loader 'fixes up' the functions declared in the import table with the actual function in the DLL. It replaces the call instruction address in the loaded program with the actual function entry address. If the loader can not find a DLL the program needs or a function it will abort the loading and if you are lucky report an error message.

Within Windows you'll see that the same system DLLs crop up again and again. The reason for '32' being present in the name 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 program must have this imported 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. This is because you want an installer always 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. 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. Such basics as line drawing and text drawing 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, inspirationally, chose the name of 'Advanced API' for some '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 and had to be included as an upgrade.
Shell32.dll	If a program wants to be integrated into Windows in an intimate fashion so 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 of 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 turns itself into Excel for the duration of the spreadsheet editing and reverts back to Word when complete. Unfortunately at the time (over ten 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 generalised interface than for OLE1.0. Once again it's a neat idea and for some, rather rare applications this turns out useful in general though it proved fiendishly difficult to develop and debug large applications that use 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 :