in reply to Re: Integration with 64 Bit Office installs
in thread Integration with 64 Bit Office installs

Hi there, thanks for the suggestion, but as stated, this is not an option as this would require a lot of time. Just looking for a quick fix to get the Outlook.pm functional with 64 bit installs

  • Comment on Re^2: Integration with 64 Bit Office installs

Replies are listed 'Best First'.
Re^3: Integration with 64 Bit Office installs
by marto (Cardinal) on Mar 21, 2025 at 17:35 UTC

    Not going to happen. The issue is with Win32::OLE compiled against a 32 bit perl, it won't have access to 64bit COM objects. You can't just package your app, provide a 32 & 64 bit version?

[reply]

      Could you explain then why others seeking to solve the same problem worked around it by simply manually editing their registry keys? See https://stackoverflow.com/questions/25509960/how-to-make-win32ole-work-on-64bit-ms-office-installation for an example. However this is not an option for me as I cannot edit the registry of every machine this app needs to be used.

      As stated, I am looking for pointers to a quick n dirty hack of the module files to make progress without having to recompile the entire app against a 14 or 16 versions later code base. I'll be there for much longer than I have access to with nothing to show for it.

[reply]

        You're comparing apples with oranges. The thread you link to isn't trying to solve the same problem at all. That's about 64 bit perl, literally not what you're asking about. The quick fix is to do it properly.

[reply]

        The Stackoverflow questions are about a 64bit Perl, as discussed in the comments to the question.

[reply]
        Well here's a creative hack - you could install a second 64-bit perl and have it wrap COM objects with a quick and dirty REST web service, then replace the COM calls in the 32-bit perl with web requests to the web service!

        Of course if the whole program is all about COM calls, that isn't very practical, but if you only need COM for a few edge features, like exporting to MS Word, this could be faster than fully debugging the app on a new perl environment with new module versions.

        Am I guessing correctly that you don't have a copy of the perl environment that this app runs in? Because otherwise you could locally build a whole new 64-bit windows perl environment with all the same module versions, and bring that to them on a thumb drive to quickly replace the existing perl environment in a short visit.

        If you don't have a copy of that perl environment, you should probably ask if you can make one. It's in the customer's best interest if the versions are known and recorded somewhere.

[reply]
[reply]

In Section Seekers of Perl Wisdom