When building a DLL using 'C', you must not expect ESL to provide any form of memory management. All memory allocations within a DLL function must be freed before returning the ESL application. The only time a memory allocation may be left, is during the initialisation process, however, this memory must be freed before the DLL is unloaded.

If a function returns a string, then you should use the EslCreateString function to return the ESL data type HSTRING, as your ESL application will automatically free the allocated memory, when the string variable used becomes out-of-scope. If you are forced to return a standard NULL terminated 'C' string, which can be converted to an ESL string within the application, then the DLL must provide an additional function call, to release the memory allocated to the string. An example of this processing can be found in the OSUTIL.INC, where the call to the operating system function "GetEnvironmentStringsA" is matched by a call to "FreeEnvironmentStringsA".

You should note that any memory allocated by the ESL supplied string conversion functions, are managed by ESL, therefore you must not attempt to free any such allocation within your 'C' function.

Once you have built your DLL, you must perform extensive testing on each entry point. This testing must include stress testing, where each entry point is called repeatedly. It is recommend you create simple ESL 'applets' to perform the calls, then monitor the memory requirements of ESLRUN.EXE using the Window's "Perfmon" application.

To monitor the memory requirements of a process;

•Delete the existing counters, by hi-lighting each counter line under the graph, then pressing the delete key.

•Ensure the ESL test harness 'applet' is running.

•Right click on the graph and select the 'Add Counters' option on the pop-up menu.

•Select the Performance Object "Process" from the drop down list.

•Select the Counter 'Private Bytes'.

•Select the instance ESLRUN.

•Press the add push button, then close the Add Counter dialog.

If the number of private bytes increases, then you have a memory leak. To be certain of the result, leave the performance monitoring running against the test harness for a reason time, as small leak may not be immediately apparent. You should test each entry point in isolation, if possible, so you can identify the source of any leak. You should also vary the input arguments, to ensure all possible routes through the 'C' functions have been taken, this typically includes passing invalid values to a routine.

Note. The Perfmon application only works on Window's NT or above, so you will not be able to perform the memory leakage tests on Window's 98.