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.
