Prev: Support in script
Next: Need no-install (i.e. no admin rights) database to run from HTA on win7 x64
From: tmulcahy on 6 Apr 2010 10:16

I hope some of you still follow this forum -- I realize I am joining the
conversation 2 years late!

I am encountering the exact same issue as Anthony (i.e. com object
instantiation works with an exe but not with a VBScript call). I
appreciate the solution, but can't figure out how to make it work.

Specifically, the solution is to use the wscript version found in the
syswow64 directory. This works fine, when calling that version of
wscript directly from the command line, but how do I force the system to
use this version, instead of the standard one in the system32
directory?

I appreciate your support!

Tom Mulcahy


--
tmulcahy
From: LikeToCode on 6 Apr 2010 13:54
Perhaps you could change the File Type Associations for vbs, vbe, wsh, and
any others to be opened with C:\Windows\syswow64\wscript.exe.
On Win Server 2008 you can do this by going to Control Panel\Default
Programs. THIS NOT A GLOBAL SETTING.
However you can change the File Associations in the registry.
http://www.brianmadden.com/blogs/brianmadden/archive/2004/04/20/creating-custom-file-associations-to-support-side-by-side-applications.aspx
From: tmulcahy on 6 Apr 2010 15:33

Thank you, Brian.

We settled for calling the script using the the 32-bit version on
wscript, without messing about with the file associations or system PATH
environmental variable --

%systemroot%\SysWOW64\wscript c:\mysbscript.vbs

Also, here's a BSOD warning -- DON'T put "%systemroot%\SysWOW64" into
your PATH environmental variable, unless you want a guaranteed BSOD
after your next reboot!

Cheers!

Tom


--
tmulcahy
 | 
Pages: 1
Prev: Support in script
Next: Need no-install (i.e. no admin rights) database to run from HTA on win7 x64