wscript - SYSWOW - 32-bit and 64-bit help

[CHiLL]

Wondering if anyone has knowledge on this;

 

In our school we have 32-bit Windows XP and Windows 7 machines. We have bought new 64-bit Windows 7 machines.

 

Our start menus are using common folders, and there aren't application shortcuts, but vbscripts that do checks and make a log into a database to say who ran it, where and when.

 

Now, here's the problem.

 

[Example]

Our 32-bit machines have Office 2007 installed.

 

Word 2007 has an audit log to check who ran the programme, where and when. It is logged to a database on a network share. So instead of a .lnk file to Word, it is a vbscript that makes a log into a database using ODBC. This works fine.

[/Example]

 

Now we have 64-bit machines, but ODBC doesn't work on the normal wscript.exe, so the SYSWOW64\wscript.exe is required.

 

We can't just use SYSWOW64 to run all the scripts, because 32-bit machines don't have SYSWOW64.

 

We don't want one script to check whether it is 32-bit or 64-bit, because that'd make the scripts hard to manage, as there would be two scripts per application, of which we have many.

 

Help?!

[ChuckTesta]

Eek, that's quite the problem. So the syswow64\script.exe returns an error to the DB when someone on a 32 bit machine accesses a program that is logged?

 

I personally would think the best way is to run an if statement for 64 bit systems... or 32, your choice.

[CHiLL]

Eek, that's quite the problem. So the syswow64\script.exe returns an error to the DB when someone on a 32 bit machine accesses a program that is logged?

 

I personally would think the best way is to run an if statement for 64 bit systems... or 32, your choice.

A colleague came up with a good solution.

 

Each application has a script. This script determines whether application is actually installed. If not, quits...if it is, it sets up the database parameters. Then the scripts determines whether the system is 64-bit or 32-bit, to determine which wscript to launch. Then it passes these parameters via command line to a standalone script, launching which ever wscript determined by the original script, while the first script launches the application. The second scripts logs the data into the database.

 

It's quite elegant. We could have dozens and dozens of application scripts, but they all reference the same file to write to a database, and each one passes the lone script different parameters.