These tables were added to the image in order to support a uniform mechanism for applications to delay the loading of a DLL until the first call into that DLL. The layout of the tables matches that of the traditional import tables (see Section “6.4. The .idata Section“ for details), so only a few details will be discussed here.
The Delay-Load Directory Table is the counterpart to the Import Directory Table, and can be retrieved via the Delay Import Descriptor entry in the Optional Header Data Directories list (offset 200). The Table is arranged as follows:
| Offset | Size | Field | Description |
| 0 | 4 | Attributes | Must be zero. |
| 4 | 4 | Name | Relative virtual address of the name of the DLL to be loaded. The name resides in the read-only data section of the image. |
| 8 | 4 | Module Handle | Relative virtual address of the module handle (in the data section of the image) of the DLL to be delay-loaded. Used for storage by the routine supplied to manage delay-loading. |
| 12 | 4 | Delay Import Address Table | Relative virtual address of the delay-load import address table. See below for further details. |
| 16 | 4 | Delay Import Name Table | Relative virtual address of the delay-load name table, which contains the names of the imports that may need to be loaded. Matches the layout of the Import Name Table, Section 6.4.3. Hint/Name Table. |
| 20 | 4 | Bound Delay Import Table | Relative virtual address of the bound delay-load address table, if it exists. |
| 24 | 4 | Unload Delay Import Table | Relative virtual address of the unload delay-load address table, if it exists. This is an exact copy of the Delay Import Address Table. In the event that the caller unloads the DLL, this table should be copied back over the Delay IAT such that subsequent calls to the DLL continue to use the thunking mechanism correctly. |
| 28 | 4 | Time Stamp | Time stamp of DLL to which this image has been bound. |
The tables referenced in this data structure are organized and sorted just as their counterparts are for traditional imports. See Section 6.4. The idata Section for details.
As yet, there are no attribute flags defined. This field is currently set to zero by the linker in the image. This field can be used to extend the record by indicating the presence of new fields or for indicating behaviors to the delay and/or unload helper functions.
The name of the DLL to be delay loaded resides in the read-only data section of the image and is referenced via the szName field.
The handle of the DLL to be delay loaded is located in the data section of the image and pointed to via the phmod field. The supplied delay load helper uses this location to store the handle to the loaded DLL.
The delay IAT is referenced by the delay import descriptor via the pIAT field. This is the working copy of the entry point function pointers that resides in the data section of the image and initially refer to the delay load thunks. The delay load helper is responsible for updating these pointers with the real entry points so that the thunks are no longer in the calling loop. The function pointers are access via the expression pINT->u1.Function.
The delay INT has the names of the imports that may need to be loaded. They are ordered in the same fashion as the function pointers in the IAT. They consist of the same structures as the standard INT and are accessed via the expression pINT->u1.AddressOfData->Name[0].
The delay BIAT is an optional table of IMAGE_THUNK_DATA items that is used along with the timestamp field by a post process binding phase.
The delay UIAT is an optional table of IMAGE_THUNK_DATA items that is used by the unload code to handle an explicit unload request. It is initialized data in the read-only section that is an exact copy of the original IAT that referred the code to the delay load thunks. On the unload request, the library can be freed, the *phmod cleared, and the UIAT written over the IAT to restore everything to its pre-load state.