3

Not withstanding that there is currently no tool that can create one, is it possible to have put both x64 and x86 symbols into a DLL, and have it work on both x64 and x86?

Creating one would be possible if there is some sort of specification/hack that would allow the Windows DLL loader to skip over incompatible symbols etc...

rubenvb
  • 74,642
  • 33
  • 187
  • 332
  • 1
    What would be needed would be support from the OS loader that is not presently available. – David Heffernan May 01 '11 at 17:58
  • are there no hacks that can be performed that either invalidate the other bitness symbols or "hide" the other bitness section from it. I was kind of hoping some obscure experiment had revealed such a "bug/feature" somewhere in the last 10 years :) – rubenvb May 01 '11 at 18:26
  • 1
    No there are no hacks. Life is easiest if you just go with the flow. Have separate 32 and 64 bit versions of your DLLs. – David Heffernan May 01 '11 at 18:27
  • The Sysinternals tools combine 32-bit and 64-bit EXEs into one, but that approach wouldn't work for DLLs: http://stackoverflow.com/questions/4327228/combine-x86-and-x64-executables-in-single-executable-like-sysinternals-tools – bk1e May 01 '11 at 22:11

2 Answers2

4

No, a DLL contains only one header, IMAGE_FILE_HEADER in the SDK. Which contains the Machine field, it indicates what kind of code the DLL contains. There's no way to specify more than one machine type.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Specifically, it's not possible for PE format DLLs, and the OS hasn't ever bothered to support a format supporting sections for multiple architectures, except... – Ben Voigt May 01 '11 at 17:18
0

Files on an NTFS filesystem are perfectly capable of containing multiple PE binaries, using NTFS alternate data streams. However, a google search suggests that attempts to use LoadLibrary with streams have met with failure.

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720