FoxPro EXE DCOM Configuration on 64 Bit Systems

Visual FoxPro is a 32 bit application and when you register a VFP EXE COM server it gets registered in the 32 bit DCOM registry.  If you recall, you can create a FoxPro EXE server by creating a class and marking it as OlePublic:

DEFINE CLASS TestServer as Custom OLEPUBLIC

FUNCTION Foo()
RETURN "HELLO FOO!"

ENDDEFINE

You can then add the PRG to a FoxPro project and compile the server with:

BUILD EXE TestServer FROM TestServer

At this point you have a working DCOM server on your local machine that you built the project on. In order to register the server on another machine you'll have to explicitly register it with the following command:

TestServer.exe /regserver

Whenever you register an EXE COM server it is actually a DCOM server - meaning it can potentially be launched remotely from another machine. DCOM stands for Distributed COM but realistically any EXE server (out of process server) is essentially a DCOM server even if it's called locally - the same exact APIs are used to launch it and manage the RPC COM interface.

DCOM Configuration: Doing the Bitness Dance

If you register your EXE COM server on a 32 bit system you can easily access DCOM Configuration manager in Component Services with:

DCOMCNFG

by typing the above into the Windows Run box or typing Component Services and drilling to the DCOM Config section of Component Services. The Windows Component Manager will pop up and show you all your DCOM servers and their individual settings including (hopefully) your EXE COM server.

Remember that by default your server will show up by the ProgId (ie. TestServer.TestServer) unless you change the server definition. If you have more than one COM server in your EXE only one will show up. For this reason it's a good idea to always add an explicit name to your server in the project's Project Info | Server's | Description property.

All this is fine and dandy on a 32 bit system. However, if you type DCOMCNFG into the Run box on a 64 bit system you will find… well, you won't actually find your server entry there. That's because when you type DCOMCNFG on a 64 bit machine you only see COM servers registered for 64 bit, which VFP COM servers are not.

To get around this you can explicitly launch the 32 bit version of Component Services with this more verbose command that you can type into the Windows Run box or command prompt:

mmc comexp.msc /32

Once you do this, you should again see your server show up in the configuration.

Why does this happen?

Windows registers 32 and 64 bit components in different places and DCOMCNFG only displays the 64 bit servers that are written into the 64 bit registry hive. VFP's COM registration code predates that and so it doesn't write some of the corresponding registry keys. DCOMCNFG works the same way for 32 and 64 bit components so any registration performed in the editor actually sets the same settings regardless of the bitness, but due to the registry differences VFP COM servers don't show up there.

If you're using West Wind Web Connection 5.60 and later, the COM registration tools actually provide proper registration for VFP servers so they do show up in the 64 and 32 bit DCOM registry. You can use the Server Configuration Wizard or the programmatic or command line COM registration tools provided with Web Connection via the Console.exe application to get this functionality.