R. McCarty said:
Memory leak generally means an application that when closed does
not relinquish all memory back to the available pool for XP to use.
Over time, this can cause performance problems or XP to malfunction.
Leaks are a "Serious" application defect, that on modern programs
should not occur.
To flesh this out a bit, memory leaks are a far greater problem in scripts
(WSH, VBS, JS and third-party) than in self-contained EXEs or DLLs, that
have control over their own memory access. There, as pointed out in the
prior post, the issue is simply one of decent programming.
The current generation of scripts operate through opening COM object
interfaces that provide access to the file system, shell, registry and
applications. Many applications, such as IE and the MS Office applications,
as well as many third-party apps, are all designed to function as COM
objects for scripting, either through associated DLLs or the EXE file
itself, as well as functioning as applications.
When a typical COM class object is "accessed" by the creation of an
"instance" of the object, a pointer to the IDispatch interface and a new
virtual "object" is created as an interface definition of parameters with
assigned memory. Memory is allocated in which the new object's members may
store data. For the typical COM class object, a new pointer and virtual
object are created for each instance of the underlying object accessed.
If the COM class object is a "singleton" object, however, only a single
instance will be created, which will be shared not only by all object
variable instances in the same script, but by all scripts or other processes
accessing the object. In the case of a singleton object, the initiation
process first checks to see if an instance of the underlying object has
already been instantiated and, if so, returns a pointer to the same initial
virtual object.
When a script terminates, WSH runs a cleanup process that deletes the
pointers and begins the process of eliminating the interface and memory
allocation. An object will be disconnected only after all references to it
have been released, and Windows may retain certain references, depending on
the object type and how it was instantiated. It is possible, for example,
to lock an object, when employing multiple object references. Care must be
taken in writing a script with techniques and object types that allow the
object instance to continue beyond its scope in the script or even beyond
the termination of the script.
A review of posts on the VBS and WSH newsgroups relating to concerns with
continued object connections and "memory leaks" seems to indicate a number
of reasonably distinct situations, including, among others: (1) failure to
properly exit a With statement block by progressing through the End With
statement (a With statement provides a semi-permanent connection to a COM
object and must be formally exited); (2) multiple or duplicate object
references, where object variables in higher levels of scope are not
released; and (3) recursive procedures that create multiple copies of an
object.
The most pernicious scripting "memory leaks" appear to involve EXE or
special DLL objects, that are essentially applications, and which, once
initiated, continue independently, despite being released from the object
connections to the script. With these types of objects, a well-written
script should force the object to shut down through internal means, usually
an object's Quit method, before terminating the script's object reference.
As an example, it is possible for a badly written script accessing the
InternetExplorer.Application as a COM object, to leave open an "invisible"
instance of IE that is no longer needed, but is operating and potentially
progressively chewing up memory. I've used an example of an app-COM object
for clarity, but the same problem could occur if a script has locked open a
COM-only object. And the problem is not limited to badly written scripts,
but also to badly written and compiled thrird-party COM objects that may be
installed voluntarily or by app installations, which can refuse to close
properly or which have the same type of "memory leaks" as a badly written
EXE (i.e., poor memory management and release). On the bright side, any COM
objects that a script leaves open can be found in Task Manager as an active
process and manually closed.
You might want to do a Google Groups search for "memory leaks" on the
scripting.vbs or scripting.wsh newsgroups for some nicely detailed
discussions and examples of the problem in regard to scripts.
Joe Earnest
But isn't your broader point here that the application