We have a network redirector product that installs via a NetClient-class .INF. As you would expect, our [Manufacturer] section references an install section “OurService” for installation on 32-bit machines, and a decorated “OurService.ntamd64” for installation on 64-bit machines. Within the respective install sections there are CopyFiles, AddReg, DelReg, etc., necessary for implementing the service for the 64-bit versus 32-bit platforms.
On a 64-bit machine though, our NetClient-class product must provide both 64-bit support and 32-bit support for applications. e.g. The MPR network provider DLL needs to be provided in both 64-bit form and 32-bit form, so that both 64-bit applications and 32-bit applications can invoke WNet-based APIs that employ our MPR provider. We actually have a bunch of supporting library DLLs to deliver via the .INF which have the same requirement; but focusing on the MPR network provider DLL gives a clear and non-negotiable example.
Our default position is that “we want to do it like Microsoft does it.” Which is to register a single “ProviderPath” value under [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\NetworkProvider] which names the MPR provider DLL. (“%SystemRoot%\System32\ntlanman.dll”) 64-bit applications read that configuration and load a 64-bit version of NTLANMAN.DLL from the SYSTEM32 directory, and 32-bit applications read that exact same configuration and end up loading a 32-bit version of NTLANMAN.DLL from the SYSWOW64 directory. Perfect.
The hurdle is that I can’t reference or deliver to “two different versions of a file named NTLANMAN.DLL” within a single .INF file. Because the namespace becomes “flat” when you reach [SourceDisksFiles], and there is only a single entry that that represents “the file named NTLANMAN.DLL among the source files”. The fact that you can decorate [SourceDisksFiles] per-platform doesn’t solve it, because we’re talking about an issue that will still occur entirely within [SourceDisksFiles.x64]. The issue is not “when I’m installing on 32-bit machines versus 64-bit machines”, but rather “when I need to install both 32-bit and 64-bit files on a 64-bit machine.”
Note also in the earlier “ProviderPath” configuration there is only a single registry value to name the MPR provider .DLL. i.e. It “must” be a path that works for both 64-bit and 32-bit, because there is no alternate Wow6432Node redirection going on for CurrentControlSet to give me “a separate 32-bit ProviderPath registry value” for 32-bit applications to consume. So I can’t have an provider .DLL that literally has a unique file name for each platform, because I can’t squeeze two unique file names into the single CurrentControlSet “ProviderPath” configuration value.
My current workaround has been to make all source file names unique within the .INF, by renaming them to “OurProvider_x64.dll” and “OurProvider_x86.dll”. And then in the respective “CopyFiles” sections reference the correct source file name with the destination file name as just “OurProvider.dll”. This works; I’m able to put the 64-bit “OurProvider.dll” in the SYSTEM32 directory, and the 32-bit “OurProvider.dll” in the SYSWOW64 directory.
I’m revisiting this looking for smarter ideas because of the new (future) .PDB requirement for attested signing. I’m expecting that renaming “OurProvider.pdb” to be “OurProvider_x64.pdb” is not going to be satisfactory, when the embedded PDB reference in the binary file is still going to have SYMSRV looking for “OurProvider.pdb”, not “OurProvider_x64.pdb”.
The approach we used to use & liked better was being able to specify source directory prefixes within the CopyFiles section. i.e. Our source file names were not “OurProvider_x64.dll” and “OurProvider_x86.dll”, but rather were “x64\OurProvider.dll” and “x86\OurProvider.dll”, from separate .\x64\ and .\x86\ directories in the source media. Also, a perfect solution to the issue, and is what we did on Vista through Windows 8.1. But INF2CAT and Microsoft Attested Signing both balked at this (at least back in 1507 time frame) saying you can’t have directory specifications in the source file specification. So we had to abandon this and use the “OurProvider_x64.dll” and “OurProvider_x86.dll” approach instead to get through attested signing for Windows 10.
Note I’m talking about a path within [file-list-section] of the CopyFiles entries themselves; not a source directory specified for [SourceDisksFiles]. e.g. My provider .DLL’s CopyFiles directive in the [file-list-section] is “OurProvider.dll,OurProvider_x64.dll” or “OurProvider.dll,OurProvider_x86.dll”. And used to be “OurProvider.dll,x64\OurProvider.dll” or “OurProvider.dll,x86\OurProvider.dll”.
I suppose I need to revert and see if maybe INF2CAT and Microsoft Attested Signing relaxed about using the "x64" and "x86" subdirectory specifications in the CopyFiles entries. Why am I not very hopeful.
But I wanted to describe the scenario in case someone is already using a smarter solution for delivering same-named 64-bit and 32-bit support files from an .INF to a Windows 64-bit machine; or remembers having tackled a similar issue in the past. Thanks.