Question

I’m trying to call CoCreateInstance(…) via a 64-bit Java library: org.eclipse.swt.internal.ole.win32.COM. The DLL I’m trying to hook into is a DLL for Visual SourceSafe. The point of the project is to port a VSS plugin (http://sourceforge.net/projects/vssplugin/) made for 32-bit Eclipse to 64-bit Eclipse.

The call works fine when I use the 64-bit version of org.eclipse.swt.internal.ole.win32.COM, but with the 32-bit version, the call fails. The call is being used like this:

private void init(GUID guid) {
    long[] ppv = new long[1];
    int result = COM.CoCreateInstance(guid, 0, COM.CLSCTX_INPROC_HANDLER | COM.CLSCTX_INPROC_SERVER | COM.CLSCTX_LOCAL_SERVER,
            COM.IIDIDispatch, ppv);
    if (result != COM.S_OK)
        OLE.error(OLE.ERROR_CANNOT_CREATE_OBJECT, result);
    init(new OleAutomation(new IDispatch(ppv[0])));
}

The call fails and returns -2147221164, which I guess is some kind of error code specifying that the corresponding registry entry can’t be found.

Some things I’ve tried include:

• This registry hack: http://www.gfi.com/blog/32bit-object-64bit-environment/
• Unregistering/Registering the DLL with 32-bit and 64-bit versions of regsvr32.exe

Does anyone have advice on this?

Answer 1

CoCreateInstance is just going to call LoadLibraryEx, and that can’t load 32-bit libs in a 64-bit process. Period, ever. You could, on the other hand:

1. obtain a legitimate 64-bit copy of the com component.
2. create your own not-in-process COM server that in turn calls the one you’ve got, and call CoCreateInstance for the ID of that.
3. Create a web service that wraps this thing and use java to call that.
4. go back to a 32-bit Eclipse.