At 20:34 02/04/03 +0200, Eric Pouech wrote:
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 !!
I've never got very far with winelib - as soon as any code involving OLE gets involved, things won't compile. In fact, getting stuff without OLE to compile is frequently painful and slow :-(
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)
since I haven't been using winelib (although we did try unsuccessfully) I'll leave that up to you...
Seeya, Adam -- Real Programmers don't comment their code. If it was hard to write, it should be hard to read, and even harder to modify. These are all my own opinions.