August 2001 - Wine-Devel - list.winehq.org

Re: dumping utility

by Eric Pouech

this can be done of course... I think we could start with a bin hex dumper... if has to be checked whether the x86 disassembler from the debugger could be used here... but a bit of tweaking will be required (like taking care of addresses, how opcodes are read, how output is generated...) OTOH binutils' objdump has greatly evolued and now also includes lots of PE facilities... so I think we'd better focus on pure windows areas (IMO resource dumping is perhaps more needed than the disas feature...) than this one A+ > >>>>> "eric" == eric pouech <eric.pouech(a)wanadoo.fr> writes: > > eric> thanks for your effort. I applied your patch and get the > eric> following: > >> > wine/tools/specmaker> ./pedump -x /dosd/cae/gcprevue/gcprevue.exe > eric> this has to be called with ./pedump -x -d > eric> /dosd/cae/gcprevue/gcprevue.exe as the Usage lines (almost) > eric> mention ;-) > > That looks better with the -d. > > Is pedumper expected to get a disassembler too? > > Bye > -- > Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- > > > --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________________ Faites un vu et puis Voila ! www.voila.fr Pendant tout l'été, gagnez une Ford Ka sur Voila Gratter ! http://cybergrattage.voila.fr/voila

Aug. 24, 2001

Re: dumping utility

by Uwe Bonnes

>>>>> "eric" == eric pouech <eric.pouech(a)wanadoo.fr> writes: eric> thanks for your effort. I applied your patch and get the eric> following: >> > wine/tools/specmaker> ./pedump -x /dosd/cae/gcprevue/gcprevue.exe eric> this has to be called with ./pedump -x -d eric> /dosd/cae/gcprevue/gcprevue.exe as the Usage lines (almost) eric> mention ;-) That looks better with the -d. Is pedumper expected to get a disassembler too? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Aug. 24, 2001

Re: dumping utility

by eric pouech

thanks for your effort. I applied your patch and get the following: > > wine/tools/specmaker> ./pedump -x /dosd/cae/gcprevue/gcprevue.exe this has to be called with ./pedump -x -d /dosd/cae/gcprevue/gcprevue.exe as the Usage lines (almost) mention ;-) A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Aug. 24, 2001

Re: dumping utility

by eric pouech

> This seems to duplicate a lot of code that is in cvdump. Are there > still things that cvdump does that your pedump doesn't support, or > should I remove cvdump completely? yes I forgot to mention that I reintegrated cvdump inside it, so cvdump can be dropped > Also I'm not convinced we need a separate winedemangle binary, we are > already installing a bit too many things in /usr/bin. in fact, I have been wondering on how to set this up I hesitated between having a single name for the exec, and switching between the different modes (specmaker, dump, demangling) with command line options, or generating several execs (in fact a single one and several sym links) I choose the later because I didn't like to have a dump utility named specmaker... however, we can go back to the former, and go for another name ;-) A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Aug. 24, 2001

Re: dumping utility

by Alexandre Julliard

eric pouech <eric.pouech(a)wanadoo.fr> writes: > the executable made out of the sources in specmaker dir can now be > launched under 3 different names: > - specmaker: you keep all the old features of specmaker (except -S > option) > - winedemangle: this replaces the -S option of specmaker > - pedump: PE (and .DBG) file dumping utility... lots of PE dir dumping > still This seems to duplicate a lot of code that is in cvdump. Are there still things that cvdump does that your pedump doesn't support, or should I remove cvdump completely? Also I'm not convinced we need a separate winedemangle binary, we are already installing a bit too many things in /usr/bin. -- Alexandre Julliard julliard(a)winehq.com

Aug. 23, 2001

Re: dumping utility

by Uwe Bonnes

eric pouech writes: > this is a first shot at the PE-dump utility for wine > since, lots of code could/will be shared with specmaker (PE image file > browsing, symbol demangling...), I decided to turn specmaker into a > multi-mode utility > > the executable made out of the sources in specmaker dir can now be > launched under 3 different names: > - specmaker: you keep all the old features of specmaker (except -S > option) > - winedemangle: this replaces the -S option of specmaker > - pedump: PE (and .DBG) file dumping utility... lots of PE dir dumping > still > need to be written (like resources or typelib information) > Hallo Eric, thanks for your effort. I applied your patch and get the following: > wine/tools/specmaker> ./pedump -x /dosd/cae/gcprevue/gcprevue.exe > Unrecognized option > Usage: > -h Display this help message > -d <dll> Use dll for input file and generate implementation code > -C Turns on symbol demangling > -f Dumps file header information > -j sect_name Dumps only the content of section sect_name (import, export, debug) > -x Dumps everything Do I do something wrong? Bye Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Free Software: If you contribute nothing, expect nothing --

Aug. 23, 2001

Re: _CheckNotSysLevel()

by Daniel Walker

Uwe Bonnes wrote: > > >>>>> "Daniel" == Daniel Walker <diwalker(a)earthlink.net> writes: > > Daniel> Alexandre Julliard wrote: > >> Daniel Walker <diwalker(a)earthlink.net> writes: > >> > >> > It seems Wise installers break inside _CheckNotSysLevel() . I think > >> > every Wise installer I've tried breaks .. The cuteftp package was > >> one of > them .. > >> > >> How about posting a backtrace? > > > Daniel> Alright. Daniel Walker > > > Daniel> Backtrace: =>0 0x400d3f01 > Daniel> (_CheckNotSysLevel+0x51(lock=0x40779f84) [syslevel.c:153] in > Daniel> libntdll.so) (ebp=405b4a98) 1 0x40761087 (GDI_CheckNotLock+0x1b > Daniel> [gdiobj.c:438] in libgdi32.so) (ebp=405b4aa8) 2 0x407575f5 > Daniel> (CreateCompatibleDC+0x19(hdc=0xb4) [dc.c:705] in libgdi32.so) > Hallo Daniel, > > are you sure the hang happens with a recent CVS updated version? > E.g. for me line number differ to you backtrace. It's actually not a hang.. There is a break point set in _CheckNotSysLevel() and that stops execution and open the debugger.. Daniel Walker

Aug. 23, 2001

Re: _CheckNotSysLevel()

by Daniel Walker

Uwe Bonnes wrote: > > >>>>> "Daniel" == Daniel Walker <diwalker(a)earthlink.net> writes: > > Daniel> Alexandre Julliard wrote: > >> Daniel Walker <diwalker(a)earthlink.net> writes: > >> > >> > It seems Wise installers break inside _CheckNotSysLevel() . I think > >> > every Wise installer I've tried breaks .. The cuteftp package was > >> one of > them .. > >> > >> How about posting a backtrace? > > > Daniel> Alright. Daniel Walker > > > Daniel> Backtrace: =>0 0x400d3f01 > Daniel> (_CheckNotSysLevel+0x51(lock=0x40779f84) [syslevel.c:153] in > Daniel> libntdll.so) (ebp=405b4a98) 1 0x40761087 (GDI_CheckNotLock+0x1b > Daniel> [gdiobj.c:438] in libgdi32.so) (ebp=405b4aa8) 2 0x407575f5 > Daniel> (CreateCompatibleDC+0x19(hdc=0xb4) [dc.c:705] in libgdi32.so) > Hallo Daniel, > > are you sure the hang happens with a recent CVS updated version? > E.g. for me line number differ to you backtrace. yeah I'm sure . I updated my tree last night .. Daniel Walker

Aug. 23, 2001

Re: _CheckNotSysLevel()

by Uwe Bonnes

>>>>> "Daniel" == Daniel Walker <diwalker(a)earthlink.net> writes: Daniel> Alexandre Julliard wrote: >> Daniel Walker <diwalker(a)earthlink.net> writes: >> >> > It seems Wise installers break inside _CheckNotSysLevel() . I think >> > every Wise installer I've tried breaks .. The cuteftp package was >> one of > them .. >> >> How about posting a backtrace? Daniel> Alright. Daniel Walker Daniel> Backtrace: =>0 0x400d3f01 Daniel> (_CheckNotSysLevel+0x51(lock=0x40779f84) [syslevel.c:153] in Daniel> libntdll.so) (ebp=405b4a98) 1 0x40761087 (GDI_CheckNotLock+0x1b Daniel> [gdiobj.c:438] in libgdi32.so) (ebp=405b4aa8) 2 0x407575f5 Daniel> (CreateCompatibleDC+0x19(hdc=0xb4) [dc.c:705] in libgdi32.so) Hallo Daniel, are you sure the hang happens with a recent CVS updated version? E.g. for me line number differ to you backtrace. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Aug. 23, 2001

Re: _CheckNotSysLevel()

by Daniel Walker

Alexandre Julliard wrote: > > Daniel Walker <diwalker(a)earthlink.net> writes: > > > It seems Wise installers break inside _CheckNotSysLevel() . I think > > every Wise installer I've tried breaks .. The cuteftp package was one of > > them .. > > How about posting a backtrace? Alright. Daniel Walker Backtrace: =>0 0x400d3f01 (_CheckNotSysLevel+0x51(lock=0x40779f84) [syslevel.c:153] in libntdll.so) (ebp=405b4a98) 1 0x40761087 (GDI_CheckNotLock+0x1b [gdiobj.c:438] in libgdi32.so) (ebp=405b4aa8) 2 0x407575f5 (CreateCompatibleDC+0x19(hdc=0xb4) [dc.c:705] in libgdi32.so) (ebp=405b4ac4) 3 0x40759919 (StretchDIBits+0x95(hdc=0xb4, xDst=0x0, yDst=0x0, widthDst=0x12e, heightDst=0x4d, xSrc=0x0, ySrc=0x0, widthSrc=0x12e, heightSrc=0x4d, bits=0x403df2c8, info=0x403df264, wUsage=0x0, dwRop=0x8800c6) [dib.c:220] in libgdi32.so) (ebp=405b4ae8) 4 0x40759876 (StretchDIBits16+0x52(hdc=0xb4, xDst=0x0, yDst=0x0, widthDst=0x12e, heightDst=0x4d, xSrc=0x0, ySrc=0x0, widthSrc=0x12e, heightSrc=0x4d, bits=0x403df2c8, info=0x403df264, wUsage=0x0, dwRop=0x8800c6) [dib.c:145] in libgdi32.so) (ebp=405b4b28) 5 0x4076439a (PlayMetaFileRecord16+0xe9e(hdc=0xb4, ht=0x403d9180, mr=0x403df248, nHandles=0x0) [metafile.c:1226] in libgdi32.so) (ebp=405b4b8c) 6 0x40762f9d (MF_PlayMetaFile+0x129(hdc=0xb4, mh=0x403df218) [metafile.c:527] in libgdi32.so) (ebp=405b4bc8) 7 0x407630b0 (PlayMetaFile+0x24(hdc=0xb4, hmf=0x918) [metafile.c:574] in libgdi32.so) (ebp=405b4be8) 8 0x10007fdc (GLC5757.TMP.CustomDlg+0x54d in E:\GLC5757.TMP) (ebp=405b54c0) 9 0x406e7307 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=405b54e4) 10 0x406e7389 (WINPROC_CallWndProc+0x75(proc=0x10007a8f, hwnd=0x40c, msg=0xf, wParam=0x0, lParam=0x0) [winproc.c:171] in libuser32.so) (ebp=405b5510) 11 0x406eca3d (WINPROC_CallProc32WTo32A+0x85(func=0x10007a8f, hwnd=0x40c, msg=0xf, wParam=0x0, lParam=0x0) [winproc.c:2441] in libuser32.so) (ebp=405b5538) 12 0x406ecf77 (CallWindowProcW+0x93(func=0x40d90984, hwnd=0x40c, msg=0xf, wParam=0x0, lParam=0x0) [winproc.c:2692] in libuser32.so) (ebp=405b5560) 13 0x406bf476 (DefDlgProcW+0x72(hwnd=0x40c, msg=0xf, wParam=0x0, lParam=0x0) [defdlg.c:438] in libuser32.so) (ebp=405b5590) 14 0x406e7307 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=405b55b4) 15 0x406e7389 (WINPROC_CallWndProc+0x75(proc=0x406bf404, hwnd=0x40c, msg=0xf, wParam=0x0, lParam=0x0) [winproc.c:171] in libuser32.so) (ebp=405b55e0) 16 0x406ec98d (WINPROC_CallProc32ATo32W+0x7d(func=0x406bf404, hwnd=0x40c, msg=0xf, wParam=0x0, lParam=0x0) [winproc.c:2419] in libuser32.so) (ebp=405b5608) 17 0x406ecea7 (CallWindowProcA+0xb3(func=0x40d90240, hwnd=0x40c, msg=0xf, wParam=0x0, lParam=0x0) [winproc.c:2656] in libuser32.so) (ebp=405b5630) 18 0x406cf56a (DispatchMessageA+0xd6(msg=0x405b56f4) [message.c:944] in libuser32.so) (ebp=405b5674) 19 0x406c3b58 (IsDialogMessageA+0x98(hwndDlg=0x40c, msg=0x405b56f4) [dialog.c:1566] in libuser32.so) (ebp=405b5698) 20 0x100079f0 (GLC5757.TMP.DDECallback+0x3f52 in E:\GLC5757.TMP) (ebp=405b5720) 21 0x10007793 (GLC5757.TMP.DDECallback+0x3cf5 in E:\GLC5757.TMP) (ebp=405b5838) 22 0x100045d7 (GLC5757.TMP.DDECallback+0xb39 in E:\GLC5757.TMP) (ebp=405b6554) 23 0x10001f5c (GLC5757.TMP.WiseMain+0xf4d in E:\GLC5757.TMP) (ebp=406e128c) 24 0x565708ec (_end+0x150fe3c8) (ebp=83e58955) *** Invalid address 0x83e58955 (_end+0x429e6431)

Aug. 23, 2001