PF> If you have already made the decision that some 
 PF> code is so isolated that it
 PF> belongs in a DLL,

 CH> The code is not isolated - it's used by several EXEs in the same package.

So your decision to put the code in a DLL was based on reuse;  fine idea. 
The next step is to MAKE it isolated.

If you gave me some idea of your API i'd probably be able to suggest a
logical "close" or "destroy" api.

For example,  I have a "file find"  library that I use a lot, 
which follows a standard open ... close model.

 FFIND *FindOpen(char *FileSpec);
 FindNext(FFIND *);
 FindClose(FFIND *);

That FindClose() doesn't do much more than free() some stuff is no-one
else's business.

There is no shame in writing the following,  if it makes the design more
complete (and it will save you ass when you add some feature that requires
a little more 'destruction' work):

    void CloseSomething(void *p)
    {
       free(p);
    }

When you use C++ classes,  this type of approach is a natural part of the language.


--- Maximus/2 3.00