Now that Office also comes in a 64bit install, where in the registry do you find out if the version of Office installed is 32bit or 64bit?
相关问题
- Converting byte array output into Blob corrupts fi
- Are reads/writes of 64-bit values atomic on a 64-b
- Passing a namespace into a function
- How to name and reference an Excel range using off
- Using a 32bit COM object in a 64bit environment
相关文章
- Why windows 64 still makes use of user32.dll etc?
- Directly signing an Office Word document using XML
- Excel merge cell date and time
- What Component IDs should I search for to detect w
- Change jdk path in IntelliJ 13 when compiling from
- Set InstallPath registry key using Visual Studio S
- How to check 64/32-bit in Inno setup
- Clear Microsoft Office Add-Ins cache
Search the registry for the install path of the office component you are interested in, e.g. for Excel 2010 look in SOFTWARE(Wow6432Node)\Microsoft\Office\14.0\Excel\InstallRoot. It will only be either in the 32-bit registry or the 64-bit registry not both.
I've found a much easier way. Using Powershell, we can hook Excel as a COM object.
When requesting the OperatingSystem this way, we get strange results, have a look here. PC3 is mine.
I hope this works for you guys. Sorry for the lack of code; my scripts are mostly functional.
Edit: Don't forget to add the code to close Excel after you're done retrieving the data.
After testing this code yesterday I had tons of Excel opening and crashing all of a sudden..
This will make sure you'll keep users and admins happy (:
Attention: querying the bitness of the Outlook Application does NOT reliably work if called in .NET environment.
Here, we use GetBinaryType() in a DLL that can be called by any application:
With exactly the same DLL code and exactly the same Outlook binary path ("c:/Program Files (x86)/...") on the same computer.
Meaning that you might need to test the binary file yourself using "IMAGE_NT_HEADERS.FileHeader.Machine" entry.
God, I hate the incorrect return values of some Windows APIs (see also GetVersion() lie).
I've found a secure and reliable way in my InnoSetup-based script to understand whether a particular application is 32-bit or 64-bit (in my case I needed to test Excel), by using a Win32 API function. This function is called
GetBinaryType()
, it comes from `kernel32' (despite the name it comes in 32 and 64 bit flavor) and looks directly at the exe's header.NOTE WELL: The detectVersion function listed above does not work. I have a 64 bit version of Office, and a separate one with 32. Both versions using this function return "32 bit".
Checking the registry manually leads to the same conclusion: both 64 and 32 bit (Office 2010 x64 and Office 2013 32 bit) report 32 bit.
Personally I think the Office team should simply write and maintain an easy to obtain registry key somewhere. All add-in's need to reference this, and currently "guessing" is a poor approach for developers to be forced to use.
Outlook Bitness registry key does not exist on my machine.
One way to determine Outlook Bitness is by examining Outlook.exe, itself and determine if it is 32bit or 64bit.
Specifically, you can check the [IMAGE_FILE_HEADER.Machine][1] type and this will return a value indicating processor type.
For an excellent background of this discussion, on reading the PE Header of a file read this (outdated link), which states;
The IMAGE_NT_HEADERS structure is the primary location where specifics of the PE file are stored. Its offset is given by the e_lfanew field in the IMAGE_DOS_HEADER at the beginning of the file. There are actually two versions of the IMAGE_NT_HEADER structure, one for 32-bit executables and the other for 64-bit versions. The differences are so minor that I'll consider them to be the same for the purposes of this discussion. The only correct, Microsoft-approved way of differentiating between the two formats is via the value of the Magic field in the IMAGE_OPTIONAL_HEADER (described shortly).
An IMAGE_NT_HEADER is comprised of three fields:
typedef struct _IMAGE_NT_HEADERS { DWORD Signature; IMAGE_FILE_HEADER FileHeader; IMAGE_OPTIONAL_HEADER32 OptionalHeader; } IMAGE_NT_HEADERS32, *PIMAGE_NT_HEADERS32;
and you can get the c# code here.
The Magic field is at the start of the IMAGE_OPTIONAL_HEADER structure, 2 bytes at offset 24 from the start of the _IMAGE_NT_HEADERS. It has values of 0x10B for 32-bit and 0x20B for 64-bit.