- Wine-Devel - list.winehq.org

Debugging 2....
by Auge Mike June 19, 2003

June 19, 2003

Hi All, Yesterday, I was trying to debug WINE. But Ive been surprised when I saw (while using stepi): 0x08048700 in _init . . 0x08048706 in _dl_runtime_resolve . . 0x4000b014 in fixup . . 0x4000b022 in _dl_build_local_scope . 0x40006ec0 in _dl_lookup_symbol_internal 0x40006cd0 in _dl_unload_cache_internal *Why I got such thing? *Another question is when wine_initial_task is being called? Yours, _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

2 1

Missing Bugzilla Descriptions
by Dustin Navea June 18, 2003

June 18, 2003

Hey guys i was browsing thru BugZilla and I noticed that most if not all of the bugs between 853-1349 are missing their descriptions.. Possibly from the software update? Either way, I'm still around every now and then, although I'm not subscribed to any lists, so if anyone replies, please CC me __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com

5 5

Wintab: beginning to investigate Aric's patch from April.
by Robert North June 18, 2003

June 18, 2003

Ok, I've just managed to start looking into Aric's Wintab32 patch from April 23rd. I've been extremely busy (more so than I expected) since then, on a small Java contract. So I've missed my goal of looking into Aric's code in 3 weeks. (Apologies Aric) But anyway, I'm starting to look into it. The first thing I'm seeing is a crash in the WTInfo() wintab call with Painter 5. Will look into this further, and attempt to fix. Aric: Ever had this? I'll investigate further before posting up any significant details, as I suspect the fix is trivial. Infact, has anyone else looked into this patch? I haven't looked any further into Aric's other problems with Painter, as this WTInfo() error prevents Painter from even starting! More importantly, I'd like to know why it didn't make it into the CVS? Did the patch slip behind the filing cabinet (as they do ;-)? Or was there a more substantive reason to reject the patch? I think Mike Hearn mentioned something about it's size (v. large)? Aric, Alexandre: do you want me to want me to re-subimt the patch, once I've got WTInfo() working? I've also noticed that it doesn't update Wine's autoconf file to look for the XInput X extension, as is done to support other dlls that use X extensions. I assume this should be added. Just to touch base with Aric: Has anyone done any more work in Code Weavers on this? That's all for now. -Rob.

2 2

#include "windows.h" versus #include <windows.h>
by Gerald Pfeifer June 18, 2003

June 18, 2003

The following most certainly cannot be right: % grep windows.h .../wine/programs/notepad/*.c .../wine/programs/notepad/License_En.c:#include "windows.h" .../wine/programs/notepad/dialog.c:#include <windows.h> .../wine/programs/notepad/license.c:#include "windows.h" .../wine/programs/notepad/main.c:#include <windows.h> Should this generally be "windows.h" or <windows.h>? (I suppose the former.) Anybody going to unify this? Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.pfeifer.com/gerald/

3 4

Sound3D problems
by Rok Mandeljc June 18, 2003

June 18, 2003

Hmm... it seems that none of 3d sound apps that used to work work anymore; all crashing when trying to get ds3dl->dsb->dsound->nrofbuffers in clause: for (i = 0; i < ds3dl->dsb->dsound->nrofbuffers; i++) There were come great changes in dsound lately (especially in buffers i think). Is this the source of problems? Or is it lack of CriticalSection stuff (I don't really understand them, so I didn't bother with them when I was writing it)? -- Rok Mandeljc <rok.mandeljc(a)gimb.org> "All that is gold does not glitter, Not all those who wander are lost; The old that is strong does not wither, Deep roots are not reached by the frost. >From the ashes a fire shall be woken, A light from the shadows shall spring; Renewed shall be blade that was broken, The crownless again shall be king." -- J.R.R. Tolkien

2 1

[DSOUND?] SMP problem workaround, more info
by OverrideX June 18, 2003

June 18, 2003

Hi again, Ok so I've found a workaround (not a great one..) for the deadlock I experience running System Shock 2 in wine using a SMP box. I've also tried another game in wine, Jedi Knight 2 which does not deadlock, I'm guessing it has to do with how ss2 is calling sounds, since it seems directly related to dsound underruns, and dsound_main.c says in the todo it's missing critical section locking in some parts of it's code, and it's critical section timeouts with the same address, and different tid's that are in the log when the deadlock occurs. (see older thread for more info....) I decided I needed to try a new kernel, 2.5.70 to see if it was something with my kernel - and I also had an idea of how to work around it. The kernel upgrade still deadlocked, but 2.5.70 has the ability to set hard cpu affinity, so by restricting all the wine processes to only using cpu1, the deadlock disappears - obviously this should be fixed in the code rather than working around it like this, but I can't trace it since it doesn't happen when the game plays slow. It seems like it only happens when the game is playing at a good pace and two or more sounds are about to play at the same time. I hope someone knows what needs to be fixed for this without too much more info, as I'm only a novice coder. But until then I'll do some heavy reading on how wine works and see if I can figure it out myself... cheers -Dan -- OverrideX <overridex(a)punkass.com> GPG Key Fingerprint = 4AD5 CE9C D7C8 0069 BDD3 7F72 3AB2 642A 5A5D EB89 It is difficult to legislate morality in the absence of moral legislators.

2 2

Re: Graphics Problem
by Robert Shearman June 17, 2003

June 17, 2003

Rob Hughes said: > make[2]: Entering directory `/usr/src/wine/dlls/opengl32' > gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include > -D_REENTRANT -fPIC -D__WINESRC__ -Wall -mpreferred-stack-boundary=2 > -gstabs+ -Wpointer-arith -g -O2 -o opengl_ext.o opengl_ext.c > opengl_ext.c:12: redefinition of `GLintptrARB' > /usr/X11R6/include/GL/gl.h:67: `GLintptrARB' previously declared here > opengl_ext.c:13: redefinition of `GLsizeiptrARB' > /usr/X11R6/include/GL/gl.h:68: `GLsizeiptrARB' previously declared here > make[2]: *** [opengl_ext.o] Error 1 > make[2]: Leaving directory `/usr/src/wine/dlls/opengl32' > make[1]: *** [opengl32] Error 2 > make[1]: Leaving directory `/usr/src/wine/dlls' > make: *** [dlls] Error 2 > > This is with cvs as of this morning and NVIDIA 43.63 drivers. > It appears as though a CVS commit 4 days ago added those types. Perhaps Lionel could have a look at these errors? Rob

1 0

Re: PATCH: dlls/cabinet/fdi.c
by Gregory M. Turner June 17, 2003

June 17, 2003

On Tuesday 17 June 2003 03:42 am, Gerald Pfeifer wrote: > This patch removes an unused variable introduced by the recent changes > to this file and thus avoids the following warning: > - cab_UBYTE buf[64], buf2[256] /* for modification [snip] > + cab_UBYTE buf[64] /* for modification by call back fn */ ; Was going to use that as the user-modifiable buffer for the cabinet name in the "Next Cabinet" notification callback, which I never implemented, as it's part of the split cabinets puzzle. I promise this warning will go away with my next patch. Sorry about that, I've been known to give others an earful for leaving warnings lying around, so I will not complain if the patch is applied, although this would create a trivial merge situation for me, as the variable will probably have to be revived again in my next patch. Also, the patch is incorrect, buf2 only, not buf, is for modification by the callback, so if we kill the variable, we should also kill the comment. My apologies for the superfluous warning! -- "Socialism in general has a record of failure so blatant that only an intellectual could ignore or evade it." -- Thomas Sowell gmt

2 1

Re: ntdll/kernel32: #27
by Alexandre Julliard June 17, 2003

June 17, 2003

Eric Pouech <pouech-eric(a)wanadoo.fr> writes: > - this patch partially implements this scheme. It's partial because > console handles are still handled by wineserver. Their value is > however obfuscated so that we can track their real usage. IMO you shouldn't need to have any obfuscation code in the server at all. If you need that, something is wrong with the design. > - next step would mean implementing the console handle management > outside of wineserver (likely in wineconsole) I'm not convinced we really need that; IMO it's OK to keep them in the server, as long as we can identify them as console handles from the client. -- Alexandre Julliard julliard(a)winehq.com

2 6

Re: Dmusic interfaces
by Rok Mandeljc June 17, 2003

June 17, 2003

Hi everyone. Sorry for not contributing anything to dmusic in a while, but I'm currently busy with final exams... As I can see, more work was done on it :) > Is anyone of you working on Dmusic interfaces ? > Now doing test with Dxdiag doesnt work, > it says "No such interface" when trying to create a IDirectPerformance > object. This problem can be fixed with adding a if (IsEqualGUID(lpcGUID, &IID_IDirectMusicPerformance) || IsEqualGUID(lpcGUID, &IID_IDirectMusicPerformance8)) in DMUSIC_CreateDirectMusicPerformance8 (at the time being, there's check for IID_IDirectMusicPerformance8 only). But even with this added, dxdiag creates interface, calls some functions and then crashes (though I have no idea why). I was looking at code and i wonder if it's ok to allocate memory for interfaces like this: segment = (IDirectMusicSegmentImpl*)HeapAlloc(GetProcessHeap(),0,sizeof(IDirectMusicImpl)); I mean, it's IDirectMusicSegmentImpl, why using size of IDirectMusicImpl then? (or this doesn't matter?) Another thing... does anyone of you know how to write effective chunk loading function (it will be needed sooner or later since most dmusic objects are stored in files)? -- Rok Mandeljc <rok.mandeljc(a)gimb.org> "All that is gold does not glitter, Not all those who wander are lost; The old that is strong does not wither, Deep roots are not reached by the frost. >From the ashes a fire shall be woken, A light from the shadows shall spring; Renewed shall be blade that was broken, The crownless again shall be king." -- J.R.R. Tolkien

2 1