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.
Related
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.
I have the source code of an windows service which is written in VB.NET
I came through various methods to debug this service using development environment (Visual Studio). But the challenge is, I need to deploy it in one of our servers as other application on that server need to access it. The server doesn't contain any development or debug tools. I am not allowed to install visual studio in it.
Is there any other way to debug the windows service on this server?
My intention is to understand the method call hierarchy, as this is a very complex code and I didn't write it. It has a very complex architecture and it is not possible to track the data flow only by looking at it.
If the only restriction is you can't install Visual Studio, I'd suggest you get the Remote Tools for VS 2012, which don't even need to be installed to the server, just a machine with a share accessible from the server. Then follow the instructions.
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 have a com server(written in C++, ATL) that runs out of process. In one of my computers I am able to debug the server code easily just by starting the COM under the debugger, setting breakpoints and connection to the server from a client process.
On my another computer this does not happen, if I start the COM server under the debugger from start, the client uses another instance of the same server and the only way to debug the server is to attch to it after the client already started it. How can this be configured ?
The problem was the fact that under the Vista and up when you start the com server elevated (so that the registry part gets in registry at the end of the build) the COM client will launch another COM server instance (at the same integrity level as he was, e.g. medium and not high)
So I had to run Visual Studio for the server as normal user (not run as admin) and had to do the COM registration from command line.
Start your processes normally. Make the debugger stop at a break point in your COM client. Launch another instance of Visual Studio (I am assuming you are running Visual Studio), and attach to the out of proc server process. In Visual Studio 2008, you do it by selecting Attach to process... in the Tools menu. Then simply select the process you want to debug, and there you go. You may want to open the source code files manually to set break points, because you are not debugging within the context of the original project.
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.