Subscribe to Windows IT Pro

 

Get Newsletters

  • Get the Latest News
  • Product Updates
  • Helpful Tricks
  • Productivity Tips

Subscribe Now!

April 01, 1998 12:00 AM

Supplement: The WSH Bug

Windows IT Pro
InstantDoc ID #3530
Rating: (0)

You’ve checked out the Windows Scripting Host (WSH) URL (http://www.microsoft.com/msdn/sdk/inetsdk/help/wsn/wobj.htm) and decided to give WSH a try. You download and install it and try to run one of the small sample scripts. To your surprise, you get the error you see in Screen A. You refer back to the documentation and are disappointed to read, "Microsoft Internet Explorer version 3.0 must be installed in order to use Windows Scripting Host. WSH relies on the Visual Basic Script and Java Script engines provided with Microsoft Internet Explorer 3.0."

Unfortunately, your company uses America’s other favorite browser. You’d prefer not to load an additional 20MB browser on every workstation to use a 1.5MB scripting engine.

As it turns out, the problem has nothing to do with JScript and VBScript engines. WSH includes both. The problem is a dependency on urlmon.dll and shlwapi.dll—DLLs that WSH does not include. Urlmon.dll is the OLE 32 Extensions for Win32 DLL that provides support for URL monikers. Shlwapi.dll stands for Shell Lightweight Utility Library, which provides additional URL support.

Both wscript.exe and cscript.exe are linked to urlmon.dll, which is linked to shlwapi.dll. When you execute either WSH execution host, it attempts to load these two libraries whether or not your script uses URLs. You can verify this scenario on a machine that doesn’t contain Internet Explorer (IE) or Internet Information Server (IIS) if you type cscript.exe or wscript.exe at a command prompt without a script argument. You can also graphically view the dependency tree using the Microsoft Windows NT Server 4.0 Resource Kit Dependency Walker utility.

Microsoft has confirmed this DLL problem is a bug that the company will address. In the meantime, if you want to use WSH, and IE is not an option, you can copy the two DLLs to the %SystemRoot%\system32 directory and restart your machine. Or you can install IE 3.0 or later and then uninstall it, which fails to remove the two shared DLLs.

Related Content:

ARTICLE TOOLS

Comments
    There are no comments to display. Be the first one!
You must log on before posting a comment.

Are you a new visitor? Register Here

advertisement

advertisement

White Papers

Get your Windows 7 deployment off to the right start by implementing PC lockdown. A locked-down environment is easier and cheaper to support since users are less likely to make unnecessary changes to the core system configuration - read more here!

Essential Guides

Is your iSCSI "lossy"? The reality is that most off-the-shelf Ethernet hardware deployed for iSCSI can lose packets, resulting in slow performance or application downtime. Learn how to assess your current iSCSI infrastructure and engineer an advanced iSCSI SAN infrastructure.

Web Seminars

What's the best way to keep your network safe from malware? In this web seminar, security expert Greg Shields suggests an alternative method to the traditional blacklisting approach that is common with anti-virus and anti-malware solutions.

eLearning Series

We bring the experts direct to you to share their real-world perspective and expertise. During each event, three sessions stream in real time, so you can learn, ask questions, and get solutions.
Upcoming event: Getting the Most with Exchange 2010 with Paul Robichaux

Subscribe to Windows IT Pro!

Windows is a trademark of the Microsoft group of companies. Windows IT Pro is used by Penton Media Inc. under license from owner.