July 2004 - Wine-Devel - list.winehq.org

debugging a dll

by Dan Timis

Hi, Someone sent me a debug version of a Windows dll and a map file. I'm not a Windows programmer, and I'm not sure how to use the map fiile. For instance, I get a runtime error dialog. With backtrace in winedbg I get this: ... 29 0x400bf58d (NTDLL.DLL.RtlRaiseException+0x5 in NTDLL.DLL) (ebp=4083f9dc) 30 0x100771e9 (LIBDEBUG.DLL.EntryPoint+0x1609 in LIBDEBUG.DLL) (ebp=4083fa1c) 31 0x10097138 (LIBDEBUG.DLL.NIUIAEntry+0x1ad8 in LIBDEBUG.DLL) (ebp=4083fa8c) 32 0x100012b2 (LIBDEBUG.DLL..text+0x2b2 in LIBDEBUG.DLL) (ebp=4083fbf8) ... I assume that everything above NTDLL.DLL.RtlRaiseException is just code to put up the dialog box, and that the problem is at 0x100771e9 (LIBDEBUG.DLL.EntryPoint+0x1609... If I look for 0x100771e9 in the map file, the closest thing I find is this: 0001:00076ed0 _realloc 10077ed0 f LIBCMTD:dbgheap.obj 0001:00076f00 __realloc_dbg 10077f00 f LIBCMTD:dbgheap.obj 0001:000774b0 __expand 100784b0 f LIBCMTD:dbgheap.obj 0001:000774e0 __expand_dbg 100784e0 f LIBCMTD:dbgheap.obj Am I correct to assume that realloc_dbg throws an exception? If I look for 0x100012b2 (LIBDEBUG.DLL..text+0x2b2), the closest I find is: 0001:000011d0 ?_Grow@?$basic_string(a)DU?$char_traits(a)D@std@@V?$allocator(a)D@2@@std@@AAE_ NI_N(a)Z... That would make sense, we are trying to grow a string, calling realloc, etc. The entry in the middle: 31 0x10097138 (LIBDEBUG.DLL.NIUIAEntry+0x1ad8 in LIBDEBUG.DLL) (ebp=4083fa8c) points to: 0001:00097140 ?onEvent(a)Application@UIA(a)NI@@MAE_NIPAVEventData(a)23@@Z ... I don't understand how this relates to the other two. Are there any tools that could help understand better what's going on? Are there any tools to demangle the C++ names? I tried c++filt and not surprisingly it did not understand these symbols. Thanks, Dan Timis Muse Research, Inc.

July 31, 2004

Re: Wine isn't GUI user friendly

by Scott W Gifford

Mike Hearn <mike(a)navi.cx> writes: [...] > I don't know how to tell if a console is available or not though. isatty(STDOUT_FILENO) is probably pretty close to the right way to do this. -----ScottG.

July 30, 2004

Re: [D3D] Added native and emulated S3TC support (take 2)

by Lionel Ulmer

> I've only mentionned the libtxc_dxtn.so library for software > decompression when the video card does not support S3TC. > Maybe Lionel can say if we can add more precise information i.e > reference to the DRI project. Well, the page where you can download it is the third Google link when searching for 'libtxc_dxtn'. So I think the information there is enough :-) Lionel PS: thanks for the edits, will be able to test the final version now that it's commited :-) -- Lionel Ulmer - http://www.bbrox.org/

July 30, 2004

Re: list view completely mangled in WINE

by Uwe Bonnes

>>>>> "Tobias" == Tobias Burnus <burnus(a)gmx.de> writes: Tobias> Hello, in Crystal Impact's Diamond the list view is completely Tobias> mangled and only barely recognizable as list view. Tobias> Result in WINE: Tobias> http://www.physik.fu-berlin.de/~tburnus/wine/diamond_list_wine.png Tobias> Result in Windows: Tobias> http://www.physik.fu-berlin.de/~tburnus/wine/diamond_list.png Consider running with native comctl32 as a workaround. Wine comctl32 still has a long way to go... ... Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

July 30, 2004

regression

by Ivan Leo Puoti

The following patch http://www.winehq.com/hypermail/wine-cvs/2004/03/0434.html causes an infinite loop when installing the word97/2k viewer. A relay log from the loop is attached. Can someone please fix this? Ivan.

July 30, 2004

Re: for whoever maintinas winrash

by Chris Morgan

So this isn't winrash's window, this is the winetest window? Chris On Friday 30 July 2004 3:02 pm, Kevin Koltzau wrote: > On Friday 30 July 2004 12:25 pm, Chris Morgan wrote: > > I'm not really sure what the user means. I don't have anything other > > than an xp machine to test on and services are supported there. Anyone > > know what the issue is? Maybe adding some code to the non-service path > > that was added to support win9X machines would let us hide the window? > > Win9X does not support multiple window stations as NT does, so the terminal > window is visible on screen (where on NT the terminal window is on a > non-visible window station) The only solution to this is to make winetest a > GUI app that does not create any visible windows.

July 30, 2004

Re: for whoever maintinas winrash

by Kevin Koltzau

On Friday 30 July 2004 12:25 pm, Chris Morgan wrote: > I'm not really sure what the user means. I don't have anything other than an > xp machine to test on and services are supported there. Anyone know what the > issue is? Maybe adding some code to the non-service path that was added to > support win9X machines would let us hide the window? Win9X does not support multiple window stations as NT does, so the terminal window is visible on screen (where on NT the terminal window is on a non-visible window station) The only solution to this is to make winetest a GUI app that does not create any visible windows.

July 30, 2004

Questions about vfork/memory issues on Solaris x86

by Joe Gainey

Joe Gainey wrote: > I've got some cross platform issues i cannot resolve. There are some > obvious issues like the assumption that round() is in the math library > and not linking in the math library itself. i've worked passed those. > Currently, I'm working with a patched version of the latest cvs source > on Solaris 9x86. After applying Robert Lunnon's patch kit to the > latest cvs course and substituting rint for the round function in > wine/dlls/dsound/mixer.c and add the math library to EXTRALIBS, I got > a clean compile. however running the wine binary results in the > following: > > try_mmap_fixed: vfork: Resource temporarily unavailable > > I'm not intimately familiar with how wine manages it's memory so I > hesitate to guess what is going on. I've attached the output of the > truss if anyone has any ideas on what it going on or how to fix it > please let me know. > > Joe Gainey

July 30, 2004

Re: Question about mmap issues on FreeBSD/NetBSD

by Joe Gainey

I've got some cross platform issues i cannot resolve. There are some obvious issues like the assumption that round() is in the math library and not linking in the math library itself. i've worked passed those. Currently, I'm working with a patched version of the latest cvs source on Solaris 9x86. After applying Robert Lunnon's patch kit to the latest cvs course and substituting rint for the round function in wine/dlls/dsound/mixer.c and add the math library to EXTRALIBS, I got a clean compile. however running the wine binary results in the following: try_mmap_fixed: vfork: Resource temporarily unavailable I'm not intimately familiar with how wine manages it's memory so I hesitate to guess what is going on. I've attached the output of the truss if anyone has any ideas on what it going on or how to fix it please let me know. Joe Gainey

July 30, 2004

Re: RESEND: Try to avoid loading 16-bit DLLs into memory for accessing version info

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Try to avoid loading 16-bit DLLs into memory for accessing > version info, this might lead to undesired side effects like > loading a bunch of other 16-bit DLLs. The problem I see is that this will bypass the loadorder config, and retrieve the version of the native dll in all cases. I think it would be better to try to take loadorder into account, though I admit it's not trivial to do. -- Alexandre Julliard julliard(a)winehq.org

July 30, 2004