Database Search

TechHome

• IntControl 32 and Memory Address Location
• Max Memory Allocation for Win3.1 versus Win95 and NT
• Memory Allocation StringSpace and Arrays
• Run in Separate Memory Space under NT
• Task Manager Performance 100 percent
• WinBatch Debugger Slow to Start
• WinBatch System Requirements
• WinResources and Physical Memory

Can't find the information you are looking for here? Then leave a message over on our WinBatch Tech Support Forum.

Memory Allocation, StringSpace, and Arrays

Keywords:  Arrays Memory Allocation Multidimensional Arrays  string space stringspace=  maxvars=

Question:

        'if (isdefined(var)) then drop(var)' 

What sort of debugging do you suggest?

Answer:

If the Call'ed WBT files are COMPLETELY independent (as in no variables in common) AND you are NEVER NEVER going to compile the script, you can try the CallExt function. If you are going to compile them, use RunWait of the other scripts instead.

Or you can try the Drop function on unneeded large string variables.

In a pinch, you can allocate a large binary buffer and store strings into the binary buffer, which can store different strings at different offsets and use it as sort of an array.

More details on memory allocation debugging below:

3097 Memory Allocation Failure - Out of memory for variables

Note that if you are using the Searcher extender, and if you are recursing through numerous directories and saving those as variable names (e.g., dir%num%, where num=980+ dirs), you can use up the last available variable and crash. In this scenario, you might be able to eliminate a lot of code with the new "Shell Operations" extender. It's in the download area.

All variables are one big happy family. Be aware that EACH faked array element (array%xx%) counts as one variable.

A variable allocated in a WBC file can be dropped at the end of the wbc file or anywhere. It's a good idea to use the Drop command to drop variables whenever possible, to conserve memory usage. However that is usually not the problem. The problem usually is that one or two variables are eating up ALL the space. These must be watched carefully.

The following bit of code will also create the Memory Allocation Failure error:

        num=0

        :loop
        num=num+1
        a%num%=num

        goto loop  

3096 Memory Allocation Failure - Out of memory for strings

• Winbatch 98F has unlimited string space (only limited by your memory), so upgrade to the latest version.

• In older versions, WinBatch has a limited amount of space to store string variables. WinBatch uses a 64K (recently raised (in WB97 through WB98F) from 32K) memory buffer to hold the string variables. The error occurs when WinBatch is unable to allocate a sufficiently large chunk of data needed to store a string. Getting rid (dropping) of large strings helps. However "memory fragmentation" does occur and may cause the error.

  As you use strings, the string storage area becomes "fragmented" (holes or wasted spaces start appearing). This can impact the ability to store large strings.

• In addition, certain operations like ItemSort need three copies of the string to work with. So if you have maybe a 10K string (500 items of 20 characters each) and do an ItemSort you've just used 30K of string space. If a little fragmentation occurred previously, it will die with the error you got.

  There are various workarounds available:

  1. Do horrible sorting operations first, before string space becomes fragmented.

  2. (High-Tech one here) If you need to hold LARGE variables or entire files, consider using the BinaryBuffers. The Binary commands are able to utilize the string space more efficiently. BinaryBuffers hold large amounts of data. Allocate a LARGE binary buffer at the beginning of your program. When you need to de-fragment memory, BinaryPokeStr all needed variables into reserved spots in BinaryBuffer, drop all variables except binarybuffer handle, then reload variables with BinaryPeekStr.

  3. Why do you need a sorted list? If list is a result of FileItemize and you don't need it sorted, and if you are running 32 bit WinBatch, try the Searcher extender.

     So give up trying to FileItemize a massive directory and get the "SEARCHER" extender from our download area and modify your code to use the SEARCHER extender instead.

     The problem is that the directory list returned by FileItemize is stored in a WinBatch varaible and it exceeds WinBatch's capabilities in that case.

     Searcher is a different way of doing the same function, but only holding one file name at a time in memory.

  4. With work, a BinarySort can be used to sort instead of ItemSort.

  5. Update to the 97 series (free from 95/96 series) - More string space is available by default.
     • If you are using versions prior to WinBatch 97, you can double the amount of string space available, from 32K to 64K. This rarely helps the problem, as a program that chews through the available memory often has no trouble chewing thru twice that.

     • The editing of the string space (discussed later in this article) in the registry usually works. There are many considerations though: Most programs that bomb at 32K also bomb at 64K. Usually some program bug or technique is eating up gobs of memory and merely doubling the available memory does not affect it. For this reason, the StringSpace patch is not highly publicized. It rarely really works.

     • The stringspace item in the registry works with 32 bit Winbatch only. 16 bit uses an INI file. If you don't get the keys exactly correct, it does not work. Interpreted and compiled winbatch scripts use different keys.

     • With the default 32k of stringspace, the largest reasonable variable is maybe 6K. With 64K stringspace, the largest reasonable variable is maybe 12K.

How to debug:

It's tricky to debug. Usually you KNOW what your fat variables are. You could write a subroutine that looks like...

:sizechk
Message("varname",strlen(varname))
Message("varname2",strlen(varname2))
etc etc etc
return

GOSUB SIZECHK

Another possible problem is fragmentation. The string space could get so broken up that you can't allocate any more space.

Question (tread continued):

How does one utilize the registry edits to increase stringspace? Do we have to do this on the machine we are going to compile .wbcs on, or do it to each machine we are going to run the .wbc on?

Answer:

It checks the entries, and it does not like them, changes them and then re-runs the script.

The code is a tad messy as it is designed to work with both 16 and 32 bit interpreted and compiled versions...

And without further ado...

if WinMetrics(-2) == 0 ;16 bit version
val=IniReadpvt("WB16I","StringSpace",32000,"www-prod.ini")
else ;32 bit version
errormode(@OFF)
val=RegQueryValue(@REGMACHINE,"SOFTWARE\Wilson
WindowWare\Settings\WWW-PROD\WB32I[StringSpace]")
ErrorMode(@CANCEL)
endif

if val!=65500
if WinMetrics(-2)==0 ; 16
   IniWritePvt("WB16I","StringSpace",65500,"www-prod.ini")
   IniWritePvt("WBC16I","StringSpace",65500,"www-prod.ini")
else ; 32
   RegSetValue(@REGMACHINE,"SOFTWARE\Wilson WindowWare\Settings\WWW-PROD\WB32I[StringSpace]",65500)
   RegSetValue(@REGMACHINE,"SOFTWARE\Wilson WindowWare\Settings\WWW-PROD\WBC32I[StringSpace]",65500)
endif

moi=strlower(IntControl(1004,0,0,0,0))

if FileExtension(moi)=="exe"
   Run(moi,"")
else
   Run(WinExeName(""),moi)
endif
exit
endif

Question:

I've done everything I can think of including bumping stringspace up to 64K, dropping variables, poking the original list of modems into a binary buffer, refreshing the Itembox "var" from the binary buffer right after the call to dialog(), etc. The only thing I haven't done so far is to break the list up into smaller lists and force the user to select from sublists. If anyone has any other ideas, I would be v-e-r-y greatful.

Answer:

You already figured out one way to fix it - break up the list into smaller chunks.

Or once thru the script, you can have the script completely re-launch itself for the next one - or if the user goes back to the dialog box.

StringSpace and FileItemize

Or...

Use a DOS command to grab a list of files and then redirect the output to a file and then use the file commands to go through the file line by line.

RunWait("command.com", "/c dir /b > newfilename")

How to Increase StringSpace And Max Variables

Undocumented workaround for WinBatch 2011B or newer:

Maximum number variables can be set using the following registry setting. The limit will apply to both compiled and interpreted scripts. You would need to change the RegSetValue view flag to 64 for the setting to apply 64-bit scripts. The setting does not affect the variable limit in the WinBatch Studio debugger. The maximum recognized limit is 65000.

WBVer = "WB44I" ; This may change with newly formatted versions of WinBatch 
bitness = 32
If WinMetrics(-2)>2 then bitness = 64
strRegMaxVars = "SOFTWARE\Wilson WindowWare\Settings\WWW-PROD\":WBVer:"\[MaxVars]"
nMaxVars = 4000
if nMaxVars<65000 then RegSetValue( @REGMACHINE, strRegMaxVars, nMaxVars, bitness )

To change the string space:

A change can be made to the registry, under the WinBatch/WWW-PROD section, as in the following:

WBVer = "WB44I" ; This may change with newly formatted versions of WinBatch 
; Set the max string space for the version of WinBatch that is running ( 32-bit or 64 bit ) 
; controls which registry view the function uses when accessing the Windows registry.
bitness = 32
If WinMetrics(-2)>2 then bitness = 64
strRegMaxStrSpace = "SOFTWARE\Wilson WindowWare\Settings\WWW-PROD\":WbVer:"\[stringspace]"
nMaxStrSpace = 65535
if nMaxStrSpace<65000 then RegSetValue( @REGMACHINE, strRegMaxStrSpace, nMaxStrSpace, bitness )

In Older WinBatch versions (i.e. 5.1a) :

To change the string space in Win3.1/3.11:

There is an option to set number of variables and amount of string space allocated, in the WWW-PROD.INI in C:\WINDOWS:

  [WBxxx]
  MaxVars = 400
  StringSpace = 32000

Article ID:   W13435

Filename:   Memory Allocation StringSpace and Arrays.txt

File Created: 2012:05:22:14:52:56

Last Updated: 2012:05:22:14:52:56