Binding is a load time optimization that lets windows load executables faster if the bound version of executable is indeed the one that is in use. Binding is sort of like a soft marriage between an application and the DLLs it needs in order to be fast at load time. If the bound version of DLL is not present, the application can still work but a tad bit slower.
Most of the Windows binaries are bound to each other for this reason. For example here is what Windows Explorer (explorer.exe) is bound to (excerpt from output of dumpbin /imports %windir%\explorer.exe) in Windows Vista
If a hotfix updates just shell32.dll to a later version, then Explorer will be a little bit slower to load than before.1 The loader in that case will note that the timestamp on shell32.dll is different from the bound version (which is 46D24057 in the dump above) and therefore will have to ignore the bindings and use regular (unbound) way to resolve import addresses.
Notwithstanding the cases when executables will get out of match with each other over the life of application or the operating system, it is worthwhile to get bindings in place because that helps speed up things for a better out-of-the-box experience. Even afterwards, since number of patched DLLs is generally a few, bound applications get some boost even though not all bound DLLs are around any more.
In Visual Studio 2008 environment, an application can be bound to DLLs by using editbin /bind[:PATH=path]. editbin (referred to officially as Microsoft COFF Binary File Editor) replaces what used to be bind.exe (and rebase.exe which used to be used to change preferred load address of binary and thus avoid address range conflicts among DLLs and speed up load times).
Every application should get faster by binding to its dependent DLLs. Third party DLLs should always be bound to the applications that use them.
Binding to Operating System DLLs (such as kernel32.dll) however gets trickier since if application is bound to Vista system DLLs then there is no speed up when the same application loads on Windows XP or Windows 2000. You may choose to bind to system DLLs of the most likely version of Windows on which application is going to be installed and run, to get the most out of the bindings.
Installers can choose to bind2 after installing the files onto target OS (and rebind everytime they update binaries). However since binding is a binary change, this is not an option for signed binaries. Therefore signed binaries have to bind before they are signed and packaged into installer.
Happy binding or is it prelinking ?
1 Assuming everything else remains exactly the same. Considering all the things that can affect executable load times between two runs, keeping everything same in a preemptive mutithreading OS is largely theoretical.
2 Non-msi installers can use BindImageEx at install time to bind appropriate binaries to their dependencies.
