VBScript maximum script size?

[poobah252]

Has anyone ever run into a maximum VBScript script size?

I maintain a script that has gradually grown in size over the last five years.

Today I started to get the following cryptic error.

scriptname.wsf(39, 37) Windows Script Host: Cannot retrieve referenced URL : scriptname.vbs

When I looked at the script size, I saw that the current size was 523,581 bytes and the last working size was 524,574 bytes.

On a hunch, I trimmed out a few comments and got it back below the 512-kilobyte mark (524,288 bytes) and it works again.

I could not find anything about such a limit with a google search.

When it runs, the performance seems reasonable.

I am running on Windows XP SP 2, with all current patches, Windows Script Host Version 5.6.

Thanks, Bill Starr
Columbus, Indiana
Wed, 14 Mar 2007, 3:03 pm EDT

 

[EBGreen]

MS provides a WMI diagnostic script that is 964K and we run it frequently with no problems.

[red]"... isn't sanity really just a one trick pony anyway?! I mean, all you get is one trick, rational thinking, but when you are good and crazy, oooh, oooh, oooh, the sky is the limit!" - The Tick[/red]

 

[Brycspain]

I guess attaching the script isnt such a good idea =)

 

[poobah252]

I saw the reply from EBGreen, which makes me think it's not a VBScript limit, per se.

However, at the following link, Joerg Bouillon wrote on 10 July 2003:

WSH seems to be unable to load WSH-files (and probably others) larger than 512 KB. The error message says something like that: "unable to find file ...".

That makes me think it might be a limitation built into Windows Scripting Host.

I am using a ".wsf" file because I have VBScript and Perl functions spread across several different files, but maybe there is some way I can integrate them into the master ".vbs" file without using WSH.

Bill
Thu, 15 Mar 2007, 1:35 pm EDT

 

[Angin31]

Hello
I'm new to scripting, but was wondering if you had tried running the script with cscript instead of WSH?

Here is a link to Microsoft that explains cscript.

http://www.microsoft.com/resources/.../en-us/wsh_runfromcommandprompt.mspx?mfr=true

 

[dilettante]

WSH (Windows Script Host) consists of two script hosts: CScript and WScript.

I doubt that using a full .WSF file instead of a naked .VBS file (which gets wrapped with a minimal WSF structure when loaded alone) makes much difference.


It does seem to be true that 512K is the limit, at least based on anecdotal evidence. The real question is why the heck is the script so large? Surely some of this must be a number of large <resource> elements, string literals, or things of that nature.

The standard answer seems to be to externalize this information as separate text, XML, persisted ADO Recordset, or MDB files.

In truly special cases it might make sense to redesign the script as a set of "overlays" that get loaded and executed by a smaller driver script. This is one thing you might use VBScript's Eval(), Execute, and ExecuteGlobal for.

 

[poobah252]

Thanks for the feedback. I do basically run the WSH script as a command-line cscript job.

Part of the reason it is large is lots of comments. If I remove all comments and indenting, it shrinks to about 232 kilobytes.

The ".wsf" wrapper script itself is very modest, only about 1,600 bytes, just acting as a wrapper to integrate several ".vbs" and ".pl" script files together.

The machine on which this runs has about 2 gigabytes of physical memory and seems to be in no danger of running out of actual resources when running this job, and it performs reasonably well.

The 512 K script size limit appears to be simply an arbitrary one.

Bill
Mon, 26 Mar 2007, 10:03 am EDT

 

[xwb]

You could take some of the code out and read them in as include files using ExecGlobal. That will reduce the size of the script whilst keeping the functionality.

 

[poobah252]

Thanks, xwb.

I had never run across the "ExecuteGlobal" and "Execute" statement before.

That gives me another option for working around the 512K ".wsf" include file limitation.

Bill
Mon, 26 Mar 2007, 2:28 pm EDT