the reason msvcrtd is there is that you need to use it for valgrind to do any checking of the heap - an instrumented malloc (see the changes to ntdll/heap.c) is required to tell valgrind that freshly allocated blocks are uninitialized, and the freed blocks are now invalid.
IMO you need msvcrd for running under wine a windows program compiled with both DEBUG turned on, and linking to MSVCRT you don't need msvcrtd at all to run, say, a winelib program with valgrind enabled (I assume this comes from the fact you did most of the testing with a wine running a windows app which has been compiled with the DEBUG flag on) anyway, that's pure semantic. I doesn't change the real benefit behind: being able to run wine under valgrind !!
on a more minor side of things, I would keep the VALGRIND prefix in heap.c
not sure what you mean here, but the heap.c stuff appears to have been committed (slightly rewritten by the look of it...). To be of ANY use you need the MSVCRTD stuff as well though!
basically, partly what Alexandre did to your patch => keeping the code (and macros) which are valgrind related being prefixed with VALGRIND
last point, using the .vg extension to the wine script may not be optimal. it won't work (as it is written) for winelib programs (which got started also thru the wine script) one solution would be (to follow your idea) to link (for a winelib app called foo) foo.vg to script wine (and change your rule something like *.vg|*/*.vg). another option would be to embed this support as an option to the wine script (like --valgrind)
maybe, this was just a hack to make it easier to use "in tree". not sure people would want a "--valgrind" switch in a (presumably) production winelib piece of software - it would show the world all your bugs ;-)
sure!!! that's why putting it in a file external to winewrapper might be a good solution too (lile the .winewrapper)
A+