Thanks, but this is not what I meant.
Currently, when a buffer overruns, the free pointers right after get corrupted, and when the next piece of block is allocated, the machine will crash. This will tell me approximetly where the buffer overrun, but is, generally speaking, too late. Enabling the debug messages detects the error at the same place (i.e. - too late).
What I am talking about is a compile time (or run time, no reason why not) option that will add "hot zone" areas before and after each heap allocated buffer. These zones should be: A. Large enough so that the overrun doesn't reach the heap managment structures themselves. This means that the program can keep on running despite having the buffer overflow. B. Identifiable, so that we know if a buffer has overwritten it.
Whenever you free a buffer, you check the hot zones. If they have changed, the buffer you are freeing now has been overwritten. This gives an excellent debugging tool, as it points right at the offending code.
Such a thing is not really implemented yet.
There is a freeware tool called 'valgrind' which might be instrumentable, but I do not think it can cope with wines very own memory management yet.
You could add assert(HeapValidate(heap,0,NULL))); around critical pieces of code, to call the heap checking more often. (replace heap by GetProcessHeap(), or whatever heap you use.)
Additionaly you could careful reread and reaudit your code (even in diff form) ;)
Ciao, Marcus