32-bit Windows Script Components under 64-bit Windows

We're currently setting up a new suite of 64-bit web and database servers at work all running Windows Server 2003 x64 Edition. We've got quite a few legacy 32-bit Windows Script Components we need to use which by all accounts should run fine in the 32-bit environment provided by WOW64.

Imagine our surprise when, on registering the components, none of them worked - throwing errors at the point of instantiation.

WOW64 is rather an odd beast; residing as it does in it's own SYSWOW64 folder in the Windows directory. This folder essentially contains the 32-bit versions of all the DLLs and things that are available in a 32-bit version of Windows. The caveat being that in order to get your 32-bit fare to work you need to call on the services of these SYSWOW64 versions rather than the ones in the folder still called SYSTEM32 (note the stupid naming convention).

When registering WSC's you actually register the hosting service, scrobj.dll with regsvr32.exe, passing the path to your WSC as the command line for scrobj.dll using the /i switch e.g.

regsvr32 /i:"C:\Components\Display.wsc" "C:\WINDOWS\SYSTEM32\scrobj.dll"

Oddly the Register option in the file association for WSC's seems to mix versions, calling the 64-bit version of regsvr32.exe and the 32-bit version of scrobj.dll.

"C:\WINDOWS\system32\REGSVR32.EXE" /i:"%1" "C:\WINDOWS\SYSWOW64\scrobj.dll"

I'm not sure of the significance of this mixed version thing, however it didn't work in our case so we added a 32-bit Register option which called the 32-bit versions of both files from the SYSWOW64 folder e.g.

"C:\WINDOWS\SYSWOW64\REGSVR32.EXE" /i:"%1" "C:\WINDOWS\SYSWOW64\scrobj.dll"

and a 32-bit Unregister e.g.

"C:\WINDOWS\SYSWOW64\REGSVR32.EXE" /u /n /i:"%1" "C:\WINDOWS\SYSWOW64\scrobj.dll"

which sorted the issue.

Windows Script Components as an alternative to COM

Windows Script Components provide VBScript and JScript developers with the ability to create COM style components. They can wrap up shared functionality into a component which can be registered on a server and instantiated using a CreateObject call just like other COM.

Defining a component

<?xml version="1.0"?>
<component>
   <public>
      <property name="Forename" internalName="strForename" />
      <property name="Surname">
         <get/>
         <put/>
      </property>
      <method name="Save" />
   </public>
   <script language="VBScript">
   <![CDATA[
   
   Dim strForename, strSurname

   Function get_Surname()
      get_Surname = strSurname
   End Function

   Function put_Surname(strValue)
      strSurname = strValue
   End Function

   Function Save()
      If IsEmpty(strForename) Or IsEmpty(strSurname) Then
         Save = False
      Else
         Save = True
      End If
   End Function

   ]]>
   </script>
</component>

Usage

Set myObj = Server.CreateObject("MyApp.MyClass")
myObj.Forename = "Derek"
myObj.Surname = "Fowler"
myObj.Save()
Set myObj = Nothing

Advantages

• You don't need to server-side include anything to use them, once they're registered they're available from anywhere
• Like other COM you can use them Application or Session scoped in ASP which means you can use a tailored object rather than abusing Arrays or a Recordset to create your shopping basket
• Anywhere you can use a COM component you can use a WSC - even within a .NET application

Disadvantages

• You don't get the performance benefits of proper compiled COM components
• They don't support destructors which can make clearing up a pain
• You can't do proper locking in VBScript or JScript so it's difficult to avoid concurrancy issues such as when using them Application scoped in ASP

Having said all that for the majority of applications the advantages certainly outway the disadvantages. Creating your data access and business tiers using WSCs allow you to work outside the confines of ASP environment and create components you can use anywhere that supports COM.

For anyone working in a company that is resisting the adoption of .NET this ability to write functionality to use in ASP but which you can then reuse in ASP.NET provides you with a clear upgrade path.

Links

• Introducing Windows Script Components @ MSDN
• Building Windows Script Components @ 4GuysFromRolla

Microsoft downloads

• Windows Script 5.6 Documentation
• Windows Script Component Wizard