This will always return the host's native DLL directory (e.g. 64-bit DLLs on a 64-bit system and 32-bit DLLs on a 32-bit system). If the software is 32-bit on a 64-bit operating system, this "SystemDllName" seems rather not the "Full dll path" as the log claims - the DLL appropriate for the running architecture will be found in the Wow64 directory rather than the location listed.
You can open that file from a 32-bit piece of software and Windows is going to silently redirect everything to SysWow64. But this doesn't feel right. If you use that file name in a log, there's no way to distinguish it from the 64-bit version - that is NOT its fully-qualified name.
Logically, I would expect to see something more like this:
This properly handles the very common case where a 32-bit piece of software is running on a 64-bit OS. If you are going to fully-qualify these DLLs, it would make sense to do so without relying on FS redirection.
On line 733 of detouring.cpp, we have:
This will always return the host's native DLL directory (e.g. 64-bit DLLs on a 64-bit system and 32-bit DLLs on a 32-bit system). If the software is 32-bit on a 64-bit operating system, this "SystemDllName" seems rather not the "Full dll path" as the log claims - the DLL appropriate for the running architecture will be found in the Wow64 directory rather than the location listed.
You can open that file from a 32-bit piece of software and Windows is going to silently redirect everything to SysWow64. But this doesn't feel right. If you use that file name in a log, there's no way to distinguish it from the 64-bit version - that is NOT its fully-qualified name.
Logically, I would expect to see something more like this:
This properly handles the very common case where a 32-bit piece of software is running on a 64-bit OS. If you are going to fully-qualify these DLLs, it would make sense to do so without relying on FS redirection.