Re: Allocate and De-allocate in Multi-DLL Program

I'm designing an application that will consist of several separate but
related programs, mostly command-line but at least one windowed program
as well. Each program will use some, but probably not all, of a set of
common routines for input validity checking, management of a simple data
store, etc. These common routines each need the ability to cause the
program to display a meaningful error message and, in the case of
command-line programs, terminate with a unique return code in the event
that they detect an uncorrectable error.

It seems to me that a message resource and FormatMessage() would be
ideal for handling the messages. An object containing a Message ID could
be thrown from within a common routine and caught at the outer most
level where it could be displayed with FormatMessage() and cout or
MessageBox(), as appropriate.

The problem is that it seems that I can have only one message resource
in an EXE file. I don't want to put all of the messages used by each of
the main programs and all of the common routines into a single message
resource in each program.

A solution to that is to group the common routines into a small set of
DLLs and have a message resource in each. That raises the question: Can
I throw an object from a DLL and have it caught in the EXE?

It seems likely that throwing and catching involves allocating and
de-allocating an object and I've read here about the problem resulting
from de-allocating an object in a module that may be using a different
heap than the object that allocated it.

Some thought and experimentation has persuaded me that, if an object has
a virtual destructor and both constructor and destructor are inline,
delete will call the destructor in the same module that constucted the
object, regardless of where the delete is. Can anyone find ground to
disagree with that?

Alternatively, I could link the programs and all of the DLLs with the
DLL run-time libraries. This would result, if I understand correctly, in
a single heap being used across the entire program.

My concern stems
from the fact that I'm still using VC 6.0. Can I still count on DLL
libraries that are compatible with VC 6.0 being installed on every
Windows machine?