Когда вы статически связываете модуль EXE с DLL, вы действительно связываете его с библиотекой импорта DLL (.LIB), созданной вместе с DLL при сборке DLL. Это не то же самое, что связывание с библиотекой stati c, что сбивает с толку, потому что это также файлы .LIB.
Первое, что вам нужно сделать, это выяснить, есть ли у вас EXE модуль имеет запись импорта для указанной DLL с помощью такого инструмента, как Dependency Walker , Dumpbin , pelook или вашего любимого инструмента анализатора PE. Если нет записи импорта DLL, вы, вероятно, связали EXE с библиотекой stati c, как описано в ответе @ HAL9000. Если не считать обратного проектирования EXE, лучше всего перестроить модуль, если это возможно.
В противном случае, если вы найдете импорт для указанной DLL, тогда да, вы можете замените недавно созданную DLL при условии, что у вас те же имена экспорта (функции) и / или порядковые значения, что и у оригинала. Библиотеки DLL находят функцию по именам экспорта и / или порядковым номерам, а не по RVA, которые в данном случае являются лишь внутренней деталью. Независимо от того, загружается ли DLL неявно (из-за того, что она статически связана) во время инициализации процесса (EXE) (до вызова точки входа EXE) или явно (через код с использованием LoadLibrary и т. Д. c.), Весь смысл в том, чтобы быть DLL заключается в том, что этот модуль разработан для динамической замены , а Windows был разработан на основе этой концепции. Внутренние RVA как в EXE (ссылающиеся на DLL), так и в самой DLL не обязательно должны соответствовать значениям старой DLL; эта бухгалтерия автоматически обрабатывается загрузчиком Windows во время процесса, также известного как связывание во время выполнения.
В случае, если EXE связан с указанной DLL, а ТАКЖЕ указывает жестко заданные адреса ( RVA) для экспортируемых функций DLL (процесс, известный как stati c binding), Windows по-прежнему будет проверять, что адреса все еще внутренне отражают правильные значения в загруженной DLL, которая может быть другой обновленной DLL. Это делается с помощью проверки отметки времени в разделе импорта для DLL. Если есть несоответствие, загрузчик Windows выбрасывает все stati c RVA и обновляет их текущими значениями, вызывая небольшое снижение производительности, но программа все равно загружается. FWIW инструмент bind.exe для выполнения этой stati c привязки больше не поставляется с набором инструментов Visual C ++, поскольку прирост производительности в современных версиях Windows минимален. Эта оптимизация раньше была обычной практикой для ускорения времени загрузки, особенно в системных библиотеках DLL, поставляемых ОС, но не должна влиять на то, что вы пытаетесь сделать, так или иначе.