|
#1
|
|||
|
|||
Well I am running a run script VBP step. I can not see a setting to force the step to execute using the 32-bit cscript.exe. It defaults to the 64-bit version. I can of course write my own script, save the vbs file, and use a run program to launch the correct cscript but this is functionality that worked in the 32-bit version and now is not working. I have no problem making modifications to the step to make it use a different cscript but changing the step entirely is more serious.
This is the difference between 64-bit and 32-bit apps. Further, I had issues with all of my Microsoft Visual Source Safe steps since the ss.exe could not be automatically determined. Likely, VBP is looking at the registry in a location but since VSS is a 32-bit program with a 32-bit installer, the appropriate registry key is in the 32-bit portion of the registry. This would be under the WOW3264Node. The lookup fails so I assume that VPB does not take into account that the lookup is being performed in the 64-bit portion of the registry. This is a fundamental difference between different bitness processes. |
#2
|
|||
|
|||
Quote:
Quote:
|
#3
|
|||
|
|||
Yes, for the Source Safe action I did enter the path manually.
As far as the scripting goes, I was not aware that VBP was executing the script in process. Many times I notice that some steps generate temp files and execute those out of process so I though this may have been the case here. Running a .bat file comes to mind for example. I will use the 32-bit version for now until I can get a 64-bit automation API from Acresso.(not likely soon) What are Kinook's plans for 32-bit support? |
#4
|
|||
|
|||
You are correct that actions which run other programs are executed in another process, but ActiveX scripting integration is in-process.
We don't have any plans to change or reduce support for the 32-bit edition. |
|
|