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] |
| [reply] |
I agree with you. Let's see what the Administrators say.
| [reply] |
| [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] |
| [reply] |