I seem to remember Windows being rather singular in the memory allocation system it uses by default.

Here's some related reading: banishing "free to wrong pool", and making Win32 faster? (Not a solution)

I wonder what sort of trouble one could get into by doing that. (I think I would prefer to use the external library's freeing routine, assuming such exists.)

I don't see that you would have any trouble doing that...provided you ensure that you only call the CRT_free() for those things allocated directly by the CRT_malloc(). If the external library concerned exports its own free() then obviously use that, as they might be doing something extra in there. But if they don't, you are in effect just providing access to the CRT_free().

Reading Nick Clerk's post, I don;t think either of his proposals would help you here in as much as what he is suggesting is to ensure that the VMem class use perl mallloc et al., rather than the CRT's. Whilst that would (probably) help prevent many of the "free to wrong pool" messages generated by memory allocated & freed by perl, it wouldn't address your situation where an external library allocates the memory (via the CRT) and leaves the caller (you) to free it.

IMO, the correct answer is for perl to not redefine the CRT calls, but rather define (and require all internal allocations use) its own distinct Perl_malloc()/Perl_free() etc. (which it of course already does), but not then redefine the CRT calls to use those. But that ship has already sailed. (Preprocessors are evil I say: EVIL! :)

An alternative (which I hate, but that could be retro-fitted at this stage without too much effort), would be to define and expose CRT_malloc(), CRT_free() etc. in the header files. If this was done early enough in the chain, then they would be unaffected by later redefinitions and woudl allow you to call CRT_free() for your particular problem.

In effect, that is what my hack does. It just gives you access to the CRT free() call--which is the only solution to the original problem.