Is there a true 64-bit version of msvcr80.dll? If not, why not?

I have read the link that answers the question of whether there is a 64 bit version of Visual Studios ( Visual Studio 64 bit? ). The simple answer is No, but the 32 bit Visual Studio development environment can produce 64-bit executables.

Questions:

1) Is there a 64 bit version of the Microsoft redistributable library msvcr80.dll? I have installed the redistributable package on my Windows 7, 64 bit machine, and all the copies (7 in all) found in the winsxs sub-directory indicate in their header sections that they are 32 bit.

2) Isn't it true that:

a) 32-bit executables cannot load a 64-bit dll?

b) 64-bit executables cannot load a 32-bit dll?

c) if it is true that all versions of msvcr开发者_如何学编程80.dll are tru ) 32-bit, as indicated in the header sections of each, how can a 64-bit application built with Visual Studio use any of the functionality of this redistributable?

If someone has found a true 64-bit version of this file (msvcr80.dll) i.e. one in which the header section actually states that it is a 64-bit library, please point me to the link.

New: Added image of BeyondCompare Viewer to show contents of msvcr80.dll header section, indicating dll is targeted for 32 bit use...

Beyond Compare isn't using the PE headers for what it's displaying - it's using version resources, and the FILEOS version resource for the x64 msvcr80.dll has the value VOS_NT_WINDOWS32 (as far as I know there isn't a VOS_NT_WINDOWS64).

Use dumpbin /headers (or link /dump /headers) to get your information about the PE headers. You'll see that the x64 DLLs have the following info:

FILE HEADER VALUES
            8664 machine (x64)

I would like to point out that msvcr80.dll is the crt runtime for visual studio 2005, not visual studio 2010 as indicated by your tag.

The dll in the winsxs amd64_xxx is a win64 dll. Here is a dumpbin of the dll on my system:

C:\Windows\winsxs\amd64_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.1833_none_88de3f632fb047bc>dumpbin /headers msvcr80.dll Microsoft (R) COFF/PE Dumper Version 10.00.40219.01 Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file msvcr80.dll

PE signature found

File Type: DLL

FILE HEADER VALUES
            8664 machine (x64)
               6 number of sections
        482BAB54 time date stamp Thu May 15 15:17:40 2008
               0 file pointer to symbol table
               0 number of symbols
              F0 size of optional header
            2022 characteristics
                   Executable
                   Application can handle large (>2GB) addresses
                   DLL

Here is a dumpbin of the 32bit version:

C:\Windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.1833_none_d08b763a442c70c2>dumpbin /headers msvcr80.dll
Microsoft (R) COFF/PE Dumper Version 10.00.40219.01
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file msvcr80.dll

PE signature found

File Type: DLL

FILE HEADER VALUES
             14C machine (x86)
               5 number of sections
        482BB294 time date stamp Thu May 15 15:48:36 2008
               0 file pointer to symbol table
               0 number of symbols
              E0 size of optional header
            2102 characteristics
                   Executable
                   32 bit word machine
                   DLL

And for the answer to 2)

32bit applications can not load 64bit dll's and 64bit applications can not load 32dll's.

See MSDN 64bit Process Interoperability for details.

1. There is no 64-bit version of Visual Studio yet, all VS are 32-bit only.
2. VS is capable of building and debugging 64-bit executables.
3. If your OS is 64-bit, it does NOT mean you need 64-bit VC runtime for running the apps. If application is 32-bit, you need 32-bit runtime, and not 64-bit runtime. If application is 64-bit, yes, definitely you need 64-bit VC Runtime.
4. The VC runtime must match with the version you used to build the binaries (VC8, VC9 or VC10). And it must also match the service pack.
5. 32-bit binaries have 4 bytes addressing, and therefore it is not possible for 32-bit process to load 64-bit DLL. It goes true other way around also.