have 64-bit client check 32-bit registry hive

[swn1]

Suggestion (apologies if it's been done, I didn't find it). When a 64-bit client attempts to look up a class, interface, or object and can't find it, could we have it check the 32-bit registry hive automatically? Should we?

As long at the IDL stays away from pointers you can do out-of-process COM across bitnesses. But unless the server (or the user) takes special pains to register itself in both hives one won't be visible from the other.

Use the Visual Studio wizard to create a default MFC MDI exe project, check the "automation" box on the advanced tab, build in 32-bit mode. From a 64-bit python process you can't see the (vacuous but valid) document interface and class it exposes. Rebuild in 64-bit mode and you can talk to it successfully.

When you're developing the server side in both bitnesses everything about this is a pain. I end up running a stale "wrong bitness" build via the registry all the time. But for the important case of driving a (possibly legacy) 32-bit installed application from a 64-bit python making it just happen would be nice.

[konstantin-popov]

Looks like I alose a came across this issue - I get a Class not registered error when calling comtypes.client.CreateObject(...) running 64-bit python, while 32-bit python appears to work properly. Is there any solution for this?

[swn1]

I think the problem is tgat comtypes caches the translation of the TLB by name and when you switch impementations the cache is stale. Can cause a more subtle problem when switching between debug ans release. There is a command to clear the cache, or find it and manually remove the entries for your types. Dont just whack the folder, it has some structure that needs to be preserved. On Oct 27, 2016 6:17 AM, "Konstantin" [email protected] wrote:

Looks like I alose a came across this issue - I get a Class not registered error when calling comtypes.client.CreateObject(...) running 64-bit python, while 32-bit python appears to work properly. Is there any solution for this?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/enthought/comtypes/issues/89#issuecomment-256637748, or mute the thread https://github.com/notifications/unsubscribe-auth/AGL1D-Uv9tIPxg3GYi4eKas87zKeOHMVks5q4KRogaJpZM4Gn8ZP .

[konstantin-popov]

Actually my problem seems to be in the underlining windows call CoCreateInstance - it refuses to return interface pointer for 64-bit processes if the object is registered as 32-bit. Python-side can do nothing about it I guess.

[swn1]

We have had successful interoperation between 32 bit python and 64 bit com server. But i've left the company where i was doing that work. On Nov 8, 2016 3:20 AM, "Konstantin" [email protected] wrote:

Actually my problem seems to be in the underlining windows call CoCreateInstance - it refuses to return interface pointer for 64-bit processes if the object is registered as 32-bit. Python-side can do nothing about it I guess.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/enthought/comtypes/issues/89#issuecomment-259111753, or mute the thread https://github.com/notifications/unsubscribe-auth/AGL1D5uW5yPM_Md3GHR2jp68ZwpgGXOjks5q8FsYgaJpZM4Gn8ZP .

[swn1]

If the object requires a proxy the dll implementing the proxy could be a problem too. On Nov 8, 2016 3:20 AM, "Konstantin" [email protected] wrote:

Actually my problem seems to be in the underlining windows call CoCreateInstance - it refuses to return interface pointer for 64-bit processes if the object is registered as 32-bit. Python-side can do nothing about it I guess.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/enthought/comtypes/issues/89#issuecomment-259111753, or mute the thread https://github.com/notifications/unsubscribe-auth/AGL1D5uW5yPM_Md3GHR2jp68ZwpgGXOjks5q8FsYgaJpZM4Gn8ZP .

[junkmd]

@swn1 @konstantin-popov

As similar situation, there is two(32bit and 64bit) VBA dll in the same environment. https://stackoverflow.com/questions/63011181/vba-runtimes-msvbvm60-dll-vs-vbe7-dll

For the above VBA dlls, I was able to create modules from both 32bit and 64bit type libraries by passing their full paths to GetModule in my environment. Of course, I had to clear the comtypes/gen folder once.

I think it would be difficult to use comtypes to use the 32bit version API in some cases and the 64bit version API in others.

Due to no recent activity, I will close this issue. If the issue remains, please re-open.

[vasily-v-ryabov]

I think closing this issue is questionable. It shouldn't be too difficult to reproduce it for any pair of 32-bit and 64-bit app and Python. Clear error message should tell user of comtypes that it is a bitness problem if it is. If this issue doesn't duplicate another one, I would suggest to re-open it.

[junkmd]

@vasily-v-ryabov

OK.

I will re-open this issue with the goal of "raise an error that is more user friendly than the Class not registered error".

If CreateObject or GetModule is passed information such as VersionIndependentProgID that cannot determine the x-bit in the COM library, I think it should return the OS-dependent processing result, without Python additional processing. I think "Auto-detection" seems to be difficult.