Single .INF supporting both 64-bit and 32-bit (maybe not what you're thinking)

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.

I think your existing solution is pretty darn good already.

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”.

Why make trouble for yourself? Seriously.

You don’t know what’s going to be satisfactory going forward, or if this requirement for providing PDBs with for attested signing will ever even happen.

Unless you simply don’t have enough to do, or you enjoy trying to solve problems like this, just “hold your horses” until the whole PDB requirement becomes clear.

Peter

> Why make trouble for yourself? Seriously.

Thanks for the input, Peter. And understood regarding the suggestion.
What probably helps me gravitate towards “fix it before it’s broke” is
because if someone DID happen to have a smart suggestion on how I can
get back to having “subdirectories” making the file name spaces unique
instead of “renaming the source files” to make them unique… “I kinda
want that anyway”, even if the .PDB requirement weren’t coming down
the road and giving me concerns about the rename approach as well.

So we’ll see if this catches anyone who has solved it a different or
better way. In the mean time I have to construct a test to see if
maybe the INF2CAT Windows Dev Center uses now is any more relaxed
about subdirectory references in the [file-list-section] entries.

Alan Adams
Client for Open Enterprise Server
Micro Focus
alan.adams@microfocus.com