replacement MM versus internal fallback heap MM

[dhoke]

Can someone accurately confirm/deny the (in-)compatibility of the internal
fallback heap management with the replacement heap management?

Thanks.

Background

B/CG reportedly shipped a FastMM based (external) replacement memory manager
with BDS2006 (maybe earlier.)

B/CG Builder static runtimes contain internal fallback routines that will
always be used (due to what I consider poor internal build configuration
choices - QC50159) that do not appear to be completely compatible with the
FastMM replacement.

This can result in cross-heap-manager allocating/freeing if you happen to be
using third-party libraries built against the static runtimes, and you are
using the dynamic runtimes. (SQLAPI++ appears to be a library that is built
against the static runtimes), or the other way around.

This can also occur within a developing system if some supporting DLLs are
built with different library options than each other or their client
applications, where dynamic memory management items might cross those
modules' boundaries (as might particularly happen where inline functions are
used in class/objects that might be passed across those boundaries.)