Is there a good thorough authoritative reference that discusses interoperability between 32-bit and 64-bit processes? Based on googling I have deduced that:
A 32-bit DLL can only reside in a 32-bit process, and a 64-bit DLL only in a 64-bit process.
32 and 64-bit processes can only communicate using loosely coupled message systems, such as network communications, which means they can communicate using COM/DCOM.
32 and 64-bit COM components have different registry entries. A component is typically only registered in one of the two and typically only seen in one of the two worlds.
A 32-bit process can only create something registered as a 64-bit COM component if it uses CoCreateInstance with the 64-bit invocation flag, or (and I am guessing on this one, is it possible?) if the 64-bit component is somehow registered in the 32-bit registry but under the hood is still created as an out of process 64-bit process, or if there is a 32-bit shell COM component which creates the 64-bit component and then redirects calls to it?
This suggests that:
1. A 32-bit application can not use GetObject to get hold of a 64-bit version of Excel that is running? Or can it? How is the running object table (ROT) impacted by 32 versus 64-bit issue? Can a 32-bit process create an instance of Excel if only a 64-bit version of Office is installed? I would think the answer would be "no" unless the 32-bit process uses the 64-bit flag in its CoCreateInstance call, or if Excel somehow registered itself in the 32-bit world as well?
Does Microsoft automatically do anything like having CoCreateInstance from a 32-bit process check the 64-bit registry and try to create an out of process 64-bit component if there is none registered in the 32-bit registry? I have seen some release notes from 64-bit Office where Microsoft warns about access from 32-bit applications to 64-bit Excel not working, yet I know of one instance where it seemed to just work.
Is there a good technical factual reference for this?
It is explained quite well in the MSDN Library docs for CLSCTX. Lots of rules, the default behavior is:
If neither the client nor the server
specifies a preference, then:
If the computer that hosts the server is running Windows XP or
Windows Server 2003 without Service
Pack 1 (SP1) or later installed, then
COM will prefer a 64-bit version of
the server if available; otherwise it
will activate a 32-bit version of the
server.
If the computer that hosts the server is running Windows Server 2003
with SP1 or later installed, then COM
will try to match the server
architecture to the client
architecture. In other words, for a
32-bit client, COM will activate a
32-bit server if available; otherwise
it will activate a 64-bit version of
the server. For a 64-bit client, COM
will activate a 64-bit server if
available; otherwise it will activate
a 32-bit server.
Check the MSDN article if you want to override this behavior.
Related
I'm studying Microsoft COM technology from the book Learning DCOM 1999. I am puzzled with its Hello Universe sample program in Appendex D. The code is available here.
This sample contains a HelloClient.exe and a HelloServer.exe. They can be run on different Windows machines and HelloClient.exe is able to remotely call server's exposed IHello interface.
I tried HelloServer.exe on Windows XP and the HelloClient.exe on Win7 successfully call into the remote object.
However, when HelloServer.exe is run on Windows 7, the remote client always fails on CoCreateInstanceEx(CLSID_Hello, ...) with 0x80040154 (Class not registered).
So I think there must be some change since Windows Vista/7 that causes the failure.
Then what is the change, or, what am I missing?
BTW: I compile the code using Visual Studio 2010 SP1.
I have created program using MSVC++ that besides it's main task calls WCF server functions. Under Windows 7 and Windows 8 everything works fine and I got several problems with Windows XP:
On some machines I have error that webservice.dll is missing and program doesn't starts. Why some Windows XP installations contain webservice.dll while others - not? How to install required dll?
On Win XP computers that has webservice.dll sometimes programm just crashes without any reporting. After recompiling program without WCF client code program runs fine. What might be starting point to look for the problem?
Windows Web Services API (WWSAPI) is an operating-system component of Windows 7 and Windows Server 2008 R2 or later versions of Microsoft Windows.
On Windows XP you need to package it with your app. The reason it works on some boxes is probably caused by one other installed application that uses that the WWSAPI as well.
The final version of the Windows Web Services API for Windows XP, Windows Vista, Windows Server 2003 and Windows Server 2008 is now available
In contrast to the past pre-released version of this API, this final version release can be used in production code and redistributed with the final versions of the product. Because of this, the final version is only available to companies who agree to terms of Windows Master Redistribution License Agreement (MRLA). To acquire the redistributable installers for this release and a copy of the Windows MRLA for review, please email a formal request.
Partially copied and adapted from Windows Core Networking blog, from Ari Pernick, dated Oct 9th, 2009.
First time ever using ColdFusion.
We have a website that uses ColdFusion 9 on our live server. It calls a COM DLL to encrypt certain things. The code on our live server works fine.
Since I may be taking over the project I installed ColdFusion 10 Developer edition on my local machine and copied all the source code and DLL's down to my local machine for testing.
I am getting an error that it can't instantiate the COM object because it is not registered but I KNOW it is registered because the DLL works on other parts of our website that are still in Classic ASP and will run on my local machine. I actually wrote a ASP script inside the the ColdFusion test site on my machine to test the DLL and everything works fine so it IS registered (via regsvr32.exe).
The ColdFusion page was done by an outside company that we are going to be breaking ties with and I don't have the password to their ColdFusion control panel even though it is on one of our servers. I wanted to look at their settings. Is there some setting that I need to set in the control panel on my machine? If there is I haven't found it yet.
Any ideas?
EDIT:
Here is the code:
<cfscript>
objEnc = CreateObject("com", "mycom.myclass");
</cfscript>
Also, I am running the 32-bit version of CF on a Windows 7 Pro 64-bit OS.
EDIT:
Another edit just for some more info:
The Windows 2008R2 server that it runs successfully on is a 64-bit server. So OS shouldn't have anything to do with it.
Should I try to find Version 9 developer edition on adobe's site and see if it works since it matches the CF version on the server? Haven't been able to find that yet and now Adobe just released 11.
After downgrading my local machine to ColdFusion 9 I can now access the COM DLL perfectly. Which is probably for the best since our server is running CF9. My testing will be with same version. Thanks for all you guy's input.
Randy
I am going to develop an ATL COM for my device. We are using Win CE 6.0. My doubts are
What threading models are supported by COM dll in WInCE?
What threading models are supported by COM EXE in WInCE?
Does WIN CE have support for DCOM?
How can I check whether DCOM support is available in the WIN CE device I have?
COM in Windows CE supports only in-process, free-threaded automation objects
DCOM supports all threading models
DCOM Remoting is not supported (removed as of 6.0 IIRC)
To see if your device has support, look in the \Windows folder at ceconfig.h and see if it contains SYSGEN_OLE (for COM support) and/or SYSGEN_DCOM (for DCOM support).
More info can be found here.
I recently installed SQL Server 2008 Express on my Windows 7 Ultimate x64 home machine. I also have IIS 7.5 with PHP 5.3, and I was trying to connect to SQL via ADODB, but kept getting this error:
[Microsoft][ODBC Driver Manager] The specified DSN contains an
architecture mismatch between the Driver and Application
After doing a small amount of digging on the internet, I think this is because the SQL Server ODBC driver is meant for 32-bit operating systems, and mine's 64. First of all, am I correct? Is this the reason I'm running into trouble? Secondly, if so, how do I fix this? Are there any updated ODBC drivers that work with 64-bit operating systems? I looked but was unable to find any...
You're right in that it has to do with the bits.
Hope this helps:
--From MSDN --
To manage a data source that connects to a 32-bit driver under 64-bit
platform, use c:\windows\sysWOW64\odbcad32.exe. To manage a data
source that connects to a 64-bit driver, use
c:\windows\system32\odbcad32.exe. If you use the 64-bit odbcad32.exe
to configure or remove a DSN that connects to a 32-bit driver you will
receive this message.
I've been having the same problem trying to link a 64 bit SQL 2012 server to 'Sage Timberline' using Pervasive ODBC Client Interface.
I can set up the 32 bit DSN, but SQL Server keeps giving me the "architecture mismatch" error when trying to create a linked server using the 32 bit DSN.
I tried the C:\Windows\SysWOW64\odbcad32.exe to add the driver. But when I set up a linked server between MAS90 and SQL Server 2008 R2 I still get the architecture mismatch error. Just spoke to a guy from Sage and he says it won't work with 64-bit edition of Sql Server. The linked server works with MAS90 only if the edition of Sql Server is 32-bit.
I'm betting you are working with User DSNs.
Depending on your perspective, there's a "feature" or "bug" in the 64-bit Windows environment --
32-bit User DSNs show up in the 64-bit Administrator and when 64-bit client applications ask for all available DSNs -- even though the 32-bit DSNs cannot be used by the 64-bit client app and Adminstrator.
64-bit User DSNs show up in the 32-bit Administrator and when 32-bit client applications ask for all available DSNs -- even though the 64-bit DSNs cannot be used by the 32-bit client app and Adminstrator.
The error message you describe comes up anytime there's such a bitness mismatch between the DSN and the client trying to work with it.
Microsoft's recommendation is to name your User DSNs with _32 or _64, depending on the bitness of the driver on which they're based ... or stick with System DSNs.
There are 32-bit and 64-bit solutions for the connection you want. The bitness of your client application(s) -- IIS & PHP, in this case -- dictate the bitness of the solution you require.
if 32 bit application on 64 bit operating system (the application you are installed under [program files (X86)] use the following
C:\Windows\SysWOW64\odbcad32.exe
otherwise 64 bit application and 64 bit operating system use the following
C:\Windows\System32\odbcad32.exe
otherwise you will get a error like "Architectural mismatch"
Hope this will save someone's day :)
This worked for me:
Updated solution, make sure the IIS application is NOT set to 32-bit on x64 Windows. More info:
http://forum.gpsgate.com/topic.asp?TOPIC_ID=13711
from:
http://forum.gpsgate.com/topic.asp?TOPIC_ID=13622