November 2006 - Wine-devel - list.winehq.org

wine crashes on every win32 application (null ptr access early); winedbg adventures
by Saulius Menkevičius 22 Nov '06

22 Nov '06

Hi, Recently I got a problem that every app crashes on my system, like: -- begin winedbg output -- bob(a)highland:~$ winedbg ~/bin/win32/mirc/mirc.exe WineDbg starting on pid 0x12 First chance exception: page fault on read access to 0x00000000 in 32-bit code (0x00000000). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:00000000 ESP:0034eb18 EBP:0034ec3c EFLAGS:00210216( - 00 -RIAP1) EAX:00000000 EBX:00000000 ECX:00000000 EDX:000000c8 ESI:7c165cd0 EDI:00000000 Stack dump: 0x0034eb18: 7dcd7ffc 7c165cd0 7c16a430 7c16a430 0x0034eb28: 7c165cd0 7c167564 00000000 0034ec3c 0x0034eb38: 00000000 7deaf7d4 7c165cd0 0000005c 0x0034eb48: 00000000 7dcd778f 7c165cd0 7dcd7700 0x0034eb58: 00000001 7dcba235 7c165cd0 7c165cd0 0x0034eb68: 7c165cd0 7c066498 7c0f23c0 7d8d0000 Backtrace: =>1 0x00000000 (0x0034ec3c) 2 0x00000040 (0x00000002) 3 0x00000000 (0x00000000) 0x00000000: addb %al,0x0(%eax) Wine-dbg> -- end of winedbg -- I tried to remove wine configs, then recompile it from git, still the same. As a separate issue while trying to debug, I find winedbg not acting according to the man page (either that or I'm a dork). Would like to try to digest the stack frames: -- begin winedbg output -- Wine-dbg>l * 7dcd7ffc syntax error Wine-dbg>list * 7dcd7ffc syntax error Wine-dbg>list * 0x7dcd7ffc syntax error Wine-dbg>watch * 7dcd7ffc Watchpoint 1 at 0x00000007 syntax error Wine-dbg> -- end winedbg output -- So the "watch * <addr>" is working (kinda) properly, but list * doesn't. Am I missing something? Thanks

1 0

Re: d3d [1]: Remove AddRef from IWineD3DDevice_GetVertexDeclaration.
by Robert Shearman 22 Nov '06

22 Nov '06

Markus Amsler wrote: > @@ -4704,7 +4704,6 @@ static HRESULT WINAPI IWineD3DDeviceImpl > TRACE("(%p) : ppDecl=%p\n", This, ppDecl); > > *ppDecl = This->stateBlock->vertexDecl; > - if (NULL != *ppDecl) IWineD3DVertexDeclaration_AddRef(*ppDecl); > return WINED3D_OK; > These patches violate COM rules. Is this for performance or other reasons? -- Rob Shearman

3 4

Re: [Try2] winhelp: add preliminary *.cnt file support (parser) - what's wrong?
by Kirill K. Smirnov 22 Nov '06

22 Nov '06

Hi! Please, tell me what's wrong with the patch? http://www.winehq.org/pipermail/wine-patches/2006-November/032984.html -- Kirill K. Smirnov

1 0

Looking for programmator to complete Direct3D 9.0c with GLSL in the Wine
by Mirek 22 Nov '06

22 Nov '06

Hi, I am not so good at programming in C, but I would like to be perfectly working in Direct3D 9.0c in the Wine. I dont know how much work is on so if someone cold told me how far is the complementation of the Direct3D 9.0c support in the Wine? Here is the offer for everyone: The aim is to prepare all apps below working under the Windows on Nvidia GF 6XXX series, with at least 50% of speed in WinXP. There is not needed sound after merging those patches in cvs main head. I offer 1 000 Euro or 1 200 dollars for this work. 3DMark 2003 3DMark 2005 3DMark 2006 CoD 2 NFS MW NFS Carbon ES IV Oblivion Please, contact me or send this to another person you would think could do it. Mirek Slugen Czech Republic

7 6

Question about unloadVertexData
by Stefan Dösinger 22 Nov '06

22 Nov '06

Hi Henri, I think you wrote unloadVertexData and unloadNumberedArrays. If I remember correctly those were needed to deactivate stream sources so they do not make issues in future draws where they shouldn't be active(3dmark2003 vbo performance regression). I noticed that loadVertexData already disables stream sources that aren't available in the current draws, while loadNumberedArrays doesn't. Do we need unloadVertexData at all? Or are non-drawing operations or drawStridedSlow affected by arrays? Background is that I'm atm working on using dirtification to manage stream sources. So far the state management is progressing nicely, what is missing atm are Shaders, re-enabling register combiners and fixing regressions which slipped in(hl2 and bf1942). Then optimizations :-) Stefan

2 1

Re: dlls: add wpcap
by James Hawkins 22 Nov '06

22 Nov '06

On 11/21/06, mengzhuo li <muziwind(a)yahoo.com.cn> wrote: > Changlog: add wpcap.dll.so in wine, there are some wpcap functions added, > not all. > note: before configure, you should use autoreconf to generate a new > configure file. > Why are you adding this dll? Does it fix some app? I just looked around and wpcap.dll is a third-party library used for packet capturing. This does not need to be implemented in Wine if that's the case, but I've added comments below for future reference. diff -uNr wine.orig/configure.ac wine/configure.ac --- wine.orig/configure.ac 2006-11-21 16:28:25.000000000 +0800 +++ wine/configure.ac 2006-11-21 16:30:51.000000000 +0800 @@ -1669,6 +1669,7 @@ dlls/ntdsapi/Makefile dlls/objsel/Makefile dlls/odbc32/Makefile +dlls/wpcap/Makefile dlls/odbccp32/Makefile dlls/ole32/Makefile dlls/ole32/tests/Makefile diff -uNr wine.orig/dlls/Makefile.in wine/dlls/Makefile.in --- wine.orig/dlls/Makefile.in 2006-11-21 16:27:59.000000000 +0800 +++ wine/dlls/Makefile.in 2006-11-21 16:30:51.000000000 +0800 @@ -125,6 +125,7 @@ ntdsapi \ objsel \ odbc32 \ + wpcap \ odbccp32 \ ole32 \ oleacc \ @@ -559,6 +560,7 @@ ntdll/libntdll.$(IMPLIBEXT) \ ntdsapi/libntdsapi.$(IMPLIBEXT) \ odbc32/libodbc32.$(IMPLIBEXT) \ + wpcap/libwpcap.$(IMPLIBEXT) \ odbccp32/libodbccp32.$(IMPLIBEXT) \ ole32/libole32.$(IMPLIBEXT) \ oleacc/liboleacc.$(IMPLIBEXT) \ @@ -820,6 +822,9 @@ odbc32/libodbc32.$(IMPLIBEXT): odbc32/odbc32.spec $(WINEBUILD) @cd odbc32 && $(MAKE) libodbc32.$(IMPLIBEXT) +wpcap/libwpcap.$(IMPLIBEXT): wpcap/wpcap.spec $(WINEBUILD) + @cd wpcap && $(MAKE) libwpcap.$(IMPLIBEXT) + odbccp32/libodbccp32.$(IMPLIBEXT): odbccp32/odbccp32.spec $(WINEBUILD) @cd odbccp32 && $(MAKE) libodbccp32.$(IMPLIBEXT) diff -uNr wine.orig/dlls/wpcap/Makefile.in wine/dlls/wpcap/Makefile.in --- wine.orig/dlls/wpcap/Makefile.in 1970-01-01 08:00:00.000000000 +0800 +++ wine/dlls/wpcap/Makefile.in 2006-11-21 16:30:51.000000000 +0800 @@ -0,0 +1,16 @@ +TOPSRCDIR = @top_srcdir@ +TOPOBJDIR = ../.. +SRCDIR = @srcdir@ +VPATH = @srcdir@ +MODULE = wpcap.dll +IMPORTLIB = libwpcap.$(IMPLIBEXT) +IMPORTS = kernel32 ntdll +EXTRAINCL = @X_CFLAGS@ +EXTRALIBS = @X_LIBS@ @X_PRE_LIBS@ @XLIB@ @X_EXTRA_LIBS@ @OPENGL_LIBS@ -lpcap + I'm not a Makefile pro by any means, but why do you need all thse EXTRALIBS? Also, you're going to have to add a configure check for -lpcap. +C_SRCS = \ + wpcap.c + +(a)MAKE_DLL_RULES@ + +### Dependencies: diff -uNr wine.orig/dlls/wpcap/wpcap.c wine/dlls/wpcap/wpcap.c --- wine.orig/dlls/wpcap/wpcap.c 1970-01-01 08:00:00.000000000 +0800 +++ wine/dlls/wpcap/wpcap.c 2006-11-21 16:30:51.000000000 +0800 @@ -0,0 +1,73 @@ +#ifdef WIN32 +#undef WIN32 +#endif +#include <pcap.h> You need to add the GPL license to the top of every source file. Check out any other source file in the code base for examples. +void wine_pcap_close(pcap_t * a) +{ + pcap_close(a); +} + Assuming the name of the API is pcap_close, you'll have to define it like this: void WINAPI pcap_close(pcap_t *a) WINAPI is needed, but the wine_ prefix is not. +pcap_t * wine_pcap_open_live(const char * a, int b, int c , int d , char * e ) +{ + return pcap_open_live(a,b,c,d,e); +} + +int wine_pcap_findalldevs(pcap_if_t ** a, char * b) +{ + return pcap_findalldevs(a,b); +} + +void wine_pcap_freealldevs(pcap_if_t * a) +{ + pcap_freealldevs(a); +} + +int wine_pcap_compile(pcap_t * a, struct bpf_program * b, char * c, int d, bpf_u_int32 e ) +{ + return pcap_compile(a,b,c,d,e); +} + +int wine_pcap_setfilter(pcap_t * a, struct bpf_program * b) +{ + return pcap_setfilter(a,b); +} + +int wine_pcap_datalink(pcap_t * a) +{ + return pcap_datalink(a); +} + +const u_char* wine_pcap_next(pcap_t * a, struct pcap_pkthdr * b) +{ + return pcap_next(a,b); +} + +int wine_pcap_setbuff(pcap_t * p, int dim) +{ + //return pcap_setbuff(p ,dim); + return 0; +#if 0 + #ifdef HAVE_REMOTE + if (p->rmt_clientside) + { + /* Currently, this is a bug: the capture buffer cannot be set with remote capture */ + return 0; + } +#endif /* HAVE_REMOTE */ + + if (p->adapter==NULL) + { + snprintf(p->errbuf, PCAP_ERRBUF_SIZE, "The kernel buffer size cannot be set while reading from a file"); + return -1; + } + + if(PacketSetBuff(p->adapter,dim)==FALSE) + { + snprintf(p->errbuf, PCAP_ERRBUF_SIZE, "driver error: not enough memory to allocate the kernel buffer"); + return -1; + } + return 0; +#endif +} + + diff -uNr wine.orig/dlls/wpcap/wpcap.spec wine/dlls/wpcap/wpcap.spec --- wine.orig/dlls/wpcap/wpcap.spec 1970-01-01 08:00:00.000000000 +0800 +++ wine/dlls/wpcap/wpcap.spec 2006-11-21 16:30:51.000000000 +0800 @@ -0,0 +1,9 @@ +@ stdcall pcap_close(ptr) wine_pcap_close +@ stdcall pcap_open_live(str long long long str) wine_pcap_open_live +@ stdcall pcap_findalldevs(ptr str) wine_pcap_findalldevs +@ stdcall pcap_freealldevs(ptr) wine_pcap_freealldevs +@ stdcall pcap_compile(ptr ptr str long long) wine_pcap_compile +@ stdcall pcap_setfilter(ptr ptr) wine_pcap_setfilter +@ stdcall pcap_datalink(ptr) wine_pcap_datalink +@ stdcall pcap_next(ptr ptr) wine_pcap_next +@ stdcall pcap_setbuff(ptr long) wine_pcap_setbuff As I said before, you don't need to forward these, just name the APIs like they are in the spec file and it should work. -- James Hawkins

2 2

Re: wined3d: Don't refcount in getter functions.
by Stefan Dösinger 22 Nov '06

22 Nov '06

> If this is complete garbage please let me know, so i can stop working on I think these patches make sense :-) Preferably we should get completely rid of COM in wined3d. Well ok, the interface can stay, but the refcounting is pain...

1 0

Re: [5/6] wined3d: Make CreateFakeGLContext thread safe.
by Dmitry Timoshkov 22 Nov '06

22 Nov '06

"Jan Zerebecki" <jan.wine(a)zerebecki.de> wrote: > static void WineD3D_ReleaseFakeGLContext(void) { > GLXContext glCtx; > > + EnterCriticalSection(&wined3d_fake_gl_context_cs); > + > if(!wined3d_fake_gl_context_available) { > TRACE_(d3d_caps)("context not available\n"); > + LeaveCriticalSection(&wined3d_fake_gl_context_cs); > return; > } You could avoid a call to LeaveCriticalSection by moving EnterCriticalSection after the wined3d_fake_gl_context_available check. -- Dmitry.

2 1

Re: user32: add a test for window width and height fixup when width or height exceed a short storage or are negative.
by Dmitry Timoshkov 21 Nov '06

21 Nov '06

"Pierre d'Herbemont" <pdherbemont(a)free.fr> wrote: > This is a test for the CreateWindow call to see what is done with width > or height that exceed the size of a short storage, or are negative. > Hence we could decide if the fixup should be moved in user32 from > winex11.drv. > > This test is passing under Wine, but I didn't test with real Windows, so > I guess I better monitor: > http://test.winehq.org/data Under XP SP2 with your test case I get: win.c:3725: Test failed: expected rect.right 65535 != 65539 win.c:3726: Test failed: expected rect.bottom 65535 != 65539 I'm attaching a more comprehensive test which passes for me under XP SP2. -- Dmitry.

1 0

Re: user32: add a test for window width and height fixup when width or height exceed a short storage or are negative.
by James Hawkins 21 Nov '06

21 Nov '06

On 11/21/06, Pierre d'Herbemont <pdherbemont(a)free.fr> wrote: > This is a test for the CreateWindow call to see what is done with width > or height that exceed the size of a short storage, or are negative. > Hence we could decide if the fixup should be moved in user32 from > winex11.drv. > > This test is passing under Wine, but I didn't test with real Windows, so > I guess I better monitor: > http://test.winehq.org/data > > Is that the best way to go? > No, you need to either test it in Windows yourself, or have someone else run the tests on Windows for you to verify what you've written is correct. It won't be accepted otherwise. -- James Hawkins

1 0