因此,在工作中我们有大量的遗留组件,用32位VB6编写的COM对象并通过VBScript调用,并且我已经被分配了维护和更新它们的出色工作。我之前从未与COM深入合作,但无论我是否设置好,并尝试运行脚本。我收到以下错误:
" Microsoft VBScript运行时错误:ActiveX组件无法创建对象:' OurDLL.clsMyObj'"
错误出现在该行:
Set myObj = CreateObject("OurDLL.clsMyObj")
该脚本在32位CMD中运行良好,但在64位CMD中运行不正常,因此我有理由相信它是一个架构问题。我喜欢使用Cygwin进行编辑和测试;我可以使用两种不同的版本,但是如果可以的话,我想避免让两者都保持配置的麻烦。
所以,问题是:
答案 0 :(得分:4)
默认情况下,Windows启动与父进程类型匹配的脚本解释器(如果父进程为32位,则为32位解释器,如果父进程为64位,则为64位解释器)。如果您的Cygwin shell是64位,则需要在32位解释器中显式启动VBScript:
C:\Windows\SysWOW64\cscript.exe //NoLogo "C:\path\to\your.vbs"
C:\Windows\SysWOW64\wscript.exe //NoLogo "C:\path\to\your.vbs"
如果您希望在32位和64位安装之间移动呼叫,我可以定义这样的启动功能:
function RunVBS32 {
if [ -f "C:\Windows\SysWOW64\cscript.exe" ]; then
"C:\Windows\SysWOW64\cscript.exe" //NoLogo "$1"
else
"C:\Windows\cscript.exe" //NoLogo "$1"
fi
}
答案 1 :(得分:0)
这取决于您使用的是什么以及如何调用它。
我看到脚本语言的兼容性问题试图绑定到32个对象(比如cygwin 64 python试图使用32位oracle驱动程序)。
对于像vbs或shell脚本这样的命令行脚本,它应该没有任何区别。 IOW,如果你可以在CMD中执行命令,你应该能够在Cygwin中执行它。
在某些情况下,我已经看到Windows实际上会提供两个不同的32/64命令来做某事。在这些情况下,您必须指定可执行文件的完整路径。
我的猜测(我不确定)是否可能需要将vbs解释器的完整路径指定为32位。