Michael Stefaniuc wrote:
Hello!
winedump has a VC++ symbol demangling function but that is bitrotting as it is a copy of the msvcrt.__unDname . As i wanted to use the newer msvcrt.__unDname funtion i have written a quick and dirty program that is basicaly only a wrapper around UnDecorateSymbolName(). Most importand feature is that it runs on the command line. I'm not expecting it to go into Wine but others might find it usefull. After applying the patch configure needs to be regenerated.
actually, there's a tool in the MS SDK called undname that does exactly this... it has also a couple of other options (like demangling all symbols listed in a text file)...
but what should be done is to port back the code from msvcrt into winedump
A+
Eric Pouech wrote:
Michael Stefaniuc wrote:
Hello!
winedump has a VC++ symbol demangling function but that is bitrotting as it is a copy of the msvcrt.__unDname . As i wanted to use the newer msvcrt.__unDname funtion i have written a quick and dirty program that is basicaly only a wrapper around UnDecorateSymbolName(). Most importand feature is that it runs on the command line. I'm not expecting it to go into Wine but others might find it usefull. After applying the patch configure needs to be regenerated.
actually, there's a tool in the MS SDK called undname that does exactly this... it has also a couple of other options (like demangling all symbols listed in a text file)...
but what should be done is to port back the code from msvcrt into winedump
A+
I'm wondering, why can't winedump import msvcrt and call what it needs, instead of duplicating code?
(Just me thinking aloud)
I'm wondering, why can't winedump import msvcrt and call what it needs, instead of duplicating code?
(Just me thinking aloud)
- because we don't want winedump to be winelib app - because winedump does a bit more than just demangling (like adding pmt names) which requires an extra level of intelligence that doesn't exist in msvcrt.__undname
A+
Eric Pouech wrote:
Michael Stefaniuc wrote:
winedump has a VC++ symbol demangling function but that is bitrotting as it is a copy of the msvcrt.__unDname . As i wanted to use the newer msvcrt.__unDname funtion i have written a quick and dirty program that is basicaly only a wrapper around UnDecorateSymbolName(). Most importand feature is that it runs on the command line. I'm not expecting it to go into Wine but others might find it usefull. After applying the patch configure needs to be regenerated.
actually, there's a tool in the MS SDK called undname that does exactly this... it has also a couple of other options (like demangling all symbols listed in a text file)...
Good to know as i never ever had or looked at the SDK. If there is interest in this i can make my program into a undname replacement.
but what should be done is to port back the code from msvcrt into winedump
... where the code will bitrot again. Why not make winedump a Wine app and use the dbghelp and other related dlls? That way we remove redundant code, don't have to backport fixes (this is unsexy and people will forget to do it) and we will have an other application besides winedbg that uses and tests our dlls.
bye michael
Am Dienstag, den 07.02.2006, 22:48 +0100 schrieb Michael Stefaniuc:
Why not make winedump a Wine app
Please do not do that. winedump now works on windows without an wine-specific dll.
Hi,
On Wed, Feb 08, 2006 at 01:31:23PM +0100, Detlef Riekenberg wrote:
Am Dienstag, den 07.02.2006, 22:48 +0100 schrieb Michael Stefaniuc:
Why not make winedump a Wine app
Please do not do that. winedump now works on windows without an wine-specific dll.
I second that. winedump has the potential to become a very powerful yet small universally usable tool. Adding a hard wine dependency would hurt a lot.
Andreas
Andreas Mohr wrote:
On Wed, Feb 08, 2006 at 01:31:23PM +0100, Detlef Riekenberg wrote:
Am Dienstag, den 07.02.2006, 22:48 +0100 schrieb Michael Stefaniuc:
Why not make winedump a Wine app
Please do not do that. winedump now works on windows without an wine-specific dll.
Huh? Who said something about using a wine-specific dll? Though i do not know if the imagehlp and dbghelp dlls come by default with Windows. But i figure you should be able to get them with the SDK. What makes more sense is to say that winedump runs on any POSIX or maybe even standard C systems without requiring the Wine overhead.
I second that. winedump has the potential to become a very powerful yet small universally usable tool. Adding a hard wine dependency would hurt a lot.
"Has the potential" like in HR speak in job references meaning "has the potential but failed to use it" ... . Just do a cvs log on tools/winedump/msmangle.c and dlls/msvcrt/undname.c . I see the technical reasons why winedump needs it's own name demangling (the mangled name is easier to parse and generate code out of it). But for getting a human readable demangled name the __unDName() function is WAY better. If that's not the target audience for "winedump sym" then there is space for a Wine app that can be called undname.
bye michael
Andreas Mohr wrote:
Detlef Riekenberg wrote:
schrieb Michael Stefaniuc:
Why not make winedump a Wine app
Please do not do that. winedump now works on windows without an wine-specific dll.
I second that. winedump has the potential to become a very powerful yet small universally usable tool. Adding a hard wine dependency would hurt a lot.
Would it help any to dump the code in a 3rd file which both msvcrt and winedump can reference?
Molle Bestefich wrote:
Andreas Mohr wrote:
Detlef Riekenberg wrote:
schrieb Michael Stefaniuc:
Why not make winedump a Wine app
Please do not do that. winedump now works on windows without an wine-specific dll.
I second that. winedump has the potential to become a very powerful yet small universally usable tool. Adding a hard wine dependency would hurt a lot.
Would it help any to dump the code in a 3rd file which both msvcrt and winedump can reference?
This was tried before for other things and Alexandre always opposed it. And the code would need some cleanup as the usage differs between winedump and __unDName: the first generates C code to be used in Wine and the other a human readable output that can be used in C++.
bye michael
-
Andreas Mohr -
Detlef Riekenberg -
Eric Pouech -
Joris Huizer -
Michael Stefaniuc -
Molle Bestefich