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

Re: winmm/wineoss: Cast-qual warning fix
by Marcus Meissner Nov. 24, 2006

Nov. 24, 2006

On Thu, Nov 23, 2006 at 08:29:00PM +0000, Andrew Talbot wrote: > Changelog: > winmm/wineoss: Cast-qual warning fix. > > diff -urN a/dlls/winmm/wineoss/dscapture.c b/dlls/winmm/wineoss/dscapture.c > --- a/dlls/winmm/wineoss/dscapture.c 2006-11-13 17:34:40.000000000 +0000 > +++ b/dlls/winmm/wineoss/dscapture.c 2006-11-23 20:15:22.000000000 +0000 > @@ -853,7 +853,7 @@ > { > int i; > for (i = 0; i < length; i++) > - ((char *)dst)[i] = ((char *)src)[i]; > + ((char *)dst)[i] = ((const char *)src)[i]; > return dst; > } I really wonder why we do have our own memcpy() here and why there is a strange /* FIXME: using memcpy can cause strange crashes so use this fake one */ comment above it. Ciao, Marcus

2 1

Re: wine crashes on every win32 application (null ptr access early); winedbg adventures
by Saulius Menkevičius Nov. 24, 2006

Nov. 24, 2006

alexis.deruelle wrote: > Try removing nvidia drivers if installed (see bug > http://bugs.winehq.org/show_bug.cgi?id=6735) > > Cheers, > > -- > Alexis > > > Accédez au courrier électronique de La Poste > sur www.laposte.net ou sur 3615 LAPOSTENET (0,34€ TTC /mn) > 1 Giga de stockage gratuit – Antispam et antivirus intégrés > > > > yep, that will be it.. thanks

1 0

[kernel32/console.c] A really very small fix.
by Anatoly Nov. 24, 2006

Nov. 24, 2006

Hi! This fix change CodePage parameter in MultiByteToWideChar() type function from CP_ACP to return of GetConsoleOutputCP(). Now unicode symbols correct outs in wineconsole application (ex: Far). Changelog: Change codepage parameter in ReadConsoleA function. Change codepage parameter in ScrollConsoleScreenBufferA function. Index: dlls/kernel32/console.c =================================================================== RCS file: /home/wine/wine/dlls/kernel32/console.c,v retrieving revision 1.2 diff -u -p -u -r1.2 console.c --- dlls/kernel32/console.c 13 Oct 2006 10:27:18 -0000 1.2 +++ dlls/kernel32/console.c 24 Nov 2006 12:56:13 -0000 @@ -1200,7 +1199,7 @@ BOOL WINAPI ReadConsoleA(HANDLE hConsole BOOL ret; if ((ret = ReadConsoleW(hConsoleInput, ptr, nNumberOfCharsToRead, &ncr, NULL))) - ncr = WideCharToMultiByte(CP_ACP, 0, ptr, ncr, lpBuffer, nNumberOfCharsToRead, NULL, NULL); + ncr = WideCharToMultiByte(GetConsoleOutputCP(), 0, ptr, ncr, lpBuffer, nNumberOfCharsToRead, NULL, NULL); if (lpNumberOfCharsRead) *lpNumberOfCharsRead = ncr; HeapFree(GetProcessHeap(), 0, ptr); @@ -2258,7 +2257,7 @@ BOOL WINAPI ScrollConsoleScreenBufferA(H CHAR_INFO ciw; ciw.Attributes = lpFill->Attributes; - MultiByteToWideChar(CP_ACP, 0, &lpFill->Char.AsciiChar, 1, &ciw.Char.UnicodeChar, 1); + MultiByteToWideChar(GetConsoleOutputCP(), 0, &lpFill->Char.AsciiChar, 1, &ciw.Char.UnicodeChar, 1); return ScrollConsoleScreenBufferW(hConsoleOutput, lpScrollRect, lpClipRect, dwDestOrigin, &ciw);

1 0

oleaut32: preliminary support for VT_DISPATCH as parameters to VarAdd (and other 2-operand operations) (RESEND)
by Alex Villacís Lasso Nov. 24, 2006

Nov. 24, 2006

This is a preliminary patch to add support for VT_DISPATCH as parameters to VarAdd and other arithmetic operations with variants. The tests still "pass" in the sense that null VT_DISPATCH as issued by the tests are still rejected. I post this in the hope that it will be reviewed while I prepare a test case. Changelog: * Add support for receiving of VT_DISPATCH parameters in several operator functions by fetching the result value, then reissuing the same operation on result data. -- The following cryptic message was allegedly found in the inner edge of a Windows XP installation CD: 4F6E65204F5320746F2072756C65207468656D20616C6C2C204F6E65204F5320746F2066696E6420 7468656D2C0D0A4F6E65204F5320746F206272696E67207468656D20616C6C20616E6420696E2074 6865206461726B6E6573732062696E64207468656D2E0A It is rumored that only a true Unix Wizard can decypher this mysterious message, which supposedly encodes the true nature and purpose of the software.

2 1

[winex11.drv/keyboard.c] :Some fix and new function.
by Anatoly Nov. 24, 2006

Nov. 24, 2006

Hi! This patch adds in /dlls/winex11.drv/ new module (ucs2keysym.c). Keyboard.c needs this module (function ucs2ketsym) for convert Unicode values to KeySym (See patch). Now in function X11DRV_VkKeyScanEx have removed FIXME,because function ucs2keysym returns correct keysym for wchar/ Changelog: Add function usc2keysym to convert from WCHAR values to Keysym. And now we have correct keycode for wchar values.

1 0

RFC: OpenAL Winmm driver and OpenAL32.dll thunk -- 2
by Nick Burns Nov. 24, 2006

Nov. 24, 2006

(due to alut changes -- im asking for comments again -- if no problems -- ill try and submit) ------ Very cool audio worked for you as well... I too noticed the stereo effects in ut2004 and was taken aback -- first it was like -- its only on the right -- the the sound zipped over (never heard it like that before) good thing i had my airsick-bag handy. -- Ok those build failures are not totally unexpected -- depending on yer impl of openal -- they may have broken binary compat (i would 'nm' (list exported symbols of) your openal lib) and look for alut*. Very surprising that those functions are missing thou -- they are supposed to be there... freealut will fix the binary compat issues -- so its not the biggest problem -- what i could do is be safer with alut and have the configure test for each alut function that SHOULD be in the openal lib. OR better yet I can just IMPL the lame (OLD DEPRECATED) alut functions on top of openal inside openal32.dll -- this is probably the most portable and best solution... (I would just copy the impl from freealut) Looking at freealut... It is doable -- but it quite a bit of extra code... OR I can drop alut support altogether so the possibilities... 1 - require freealut 2 - impl alut functions on openal (using freealut code 5 functions -> 7 files) 3 - stub alut -- then use freealut to impl these (never used dead deprecated) functions 4 - remove alut I have choosen 3 -- attaching my patch with those changes in (and removed some meaningless comments) These stubs will FIXME -- if hit. The stubbing is controlled with 'USE_BUILTIN_ALUT' in openal.c --- btw if you dont have openal it will still build -- but spew at you if it is used -- that openal is not supported... - Nick >From: Stefan Dösinger <stefandoesinger(a)gmx.at> >To: wine-devel(a)winehq.org >CC: Nick Burns <adger44(a)hotmail.com> >Subject: Re: RFC: OpenAL Winmm driver and OpenAL32.dll thunk was >Re:OpenALand DirectSound >Date: Thu, 23 Nov 2006 21:56:52 +0100 > >Am Mittwoch 22 November 2006 11:44 schrieb Nick Burns: > > Good luck > > And may the Sound be with you... >Ok, after cleaning up the d3d mess in my tree a bit I gave your patch a >try: > >It applied fine, found AL/al.h after creating configure with autoconf, but >compilation failed in dlls/openal: > >openal.o: In function `wine_alutLoadWAVMemory': >/usr/src/wine/dlls/openal32/openal.c:327: undefined reference to >`alutLoadWAVMemory' >openal.o: In function `wine_alutLoadWAVFile': >/usr/src/wine/dlls/openal32/openal.c:327: undefined reference to >`alutLoadWAVFile' >openal.o: In function `wine_alutUnloadWAV': >/usr/src/wine/dlls/openal32/openal.c:326: undefined reference to >`alutUnloadWAV' >openal.o: In function `wine_alutExit': >/usr/src/wine/dlls/openal32/openal.c:326: undefined reference to `alutExit' >openal.o: In function `wine_alutInit': >/usr/src/wine/dlls/openal32/openal.c:326: undefined reference to `alutInit' >collect2: ld returned 1 exit status >winegcc: gcc failed. > >turned out that I needed the freealut package(gentoo). Stangely wine didn't >link against that lib automatically, I had to specify -lalut manually. > >Once the thing was compiled it worked perfectly with Jedi Academy :-) . >Wine >loaded openal32.dll builtin, and I had sound although I had no sound driver >selected in winecfg, which shows that the whole api rollercoaster is >bypassed. I had to configure the game to use openal first. > >The sound appeared strange at first, but after using headphones instead of >my >broken notebook speakers it turned out that those were just stereo effects >I >never heard before :-) . I also used to wonder what that promiently >marked "EAX Sound" option was that used to crash wine: Apparently exactly >that openal option I enabled first in the config files :-) > >/me joins the dark side of the sound > >Great job! >Stefan

1 0

RFC: OpenAL Winmm driver and OpenAL32.dll thunk was Re: OpenAL and DirectSound
by Nick Burns Nov. 23, 2006

Nov. 23, 2006

Attached is my diff/patch for both an openal winmm driver and an openal32.dll thunk I would like to get these into wine -- please comment and stuff... ----Rant follows---- I seem to be making a habit of responding to myself... (this antihistamine is kicking in) Sometimes in life you feel retarded -- at least this time I have an excuse (I am sick) Anyhow -- I took all sorts of care to make sure that my OpenAL thunk was CDECL -- I even made sure that my spec file was perfect... But, I for some reason (unknown to even the person who wrote this code -- me) I used WINAPI (stdcall) in all the actual impl of the OpenAL thunk This explains why 'WINEDEBUG=relay' worked just fine -- but it failed in odd ways without the relay. I fixed that in my thunk -- and all seems well Tested with UT2004Demo (uses openal) hello_world.exe (al example code) playfile.exe (al example code) On Mac Book Pro running Mac OSX 10.4.8 and tot wine ut2004 notes -- in System (this can be done in the gui -- uncheck (yes uncheck -- the gui seems backwards) 'use system driver' under audio) mv DefOpenAL32.dll DefOpenAL32.dll_ UT2004.ini -- change [ALAudio.ALAudioSubsystem] UseDefaultDriver=False then run WINEDEBUG=trace+openal wine UT2004.exe Also I did play ut2004 -- menus and 2 bot matches sounded fine (though the mouse seems sluggish...) (not tested in linux) - Nick >From: "Nick Burns" <adger44(a)hotmail.com> >To: wine-devel(a)winehq.org >Subject: Re: OpenAL and DirectSound -- openal32.dll first pass >Date: Mon, 20 Nov 2006 20:43:05 -0800 > >Sorry for the double post -- was unaware that 'wine.dev(a)web.de' was the >same thing... > >I was sick last night and could not sleep .: I wrote up an openal32.dll >thunk. > >I will be testing with ut2004/and the demos (hello_world and playfile) very >soon... > >I get sound with tracing but not without -- when it works ill submit a >patch... > >- Nick > >>From: "Nick Burns" <adger44(a)hotmail.com> >>To: wine.dev(a)web.de, stefandoesinger(a)gmx.at >>CC: wine-devel(a)winehq.org >>Subject: Re: OpenAL and DirectSound >>Date: Mon, 20 Nov 2006 00:29:42 -0800 >> >>I would really like to get my openal driver into wine... >>But we should also have an openal32.dll >> >>For example -- on my Mac Book Pro running Mac OSX 10.4.8 and tot wine >>If a windows application uses openal it will go from openal(windows) -> >>dsound HEL(wine) -> openal(osx) >>This means the audio data has soo much fun traveling from api to api -- >>kinda like a code rollercoaster... >> >>Anyhow -- I will resubmit my openal patch -- maybe if I get some time I >>will try to make a thunk (or I could help ... or work more)... >> >>Also I would like help with my openal patch (get hw accel working for >>dsound and dsound3d) >> >>- Nick >> >>>From: Detlef Riekenberg <wine.dev(a)web.de> >>>To: Stefan Dösinger <stefandoesinger(a)gmx.at> >>>CC: wine-devel(a)winehq.org >>>Subject: Re: OpenAL and DirectSound >>>Date: Fri, 17 Nov 2006 20:06:01 +0100 >>> >>>On Fr, 2006-11-17 at 17:31 +0100, Stefan Dösinger wrote: >>> >>> > Just stumbled uppon some interesting thing about openal and >>>DirectSound 3D on >>> > vista: http://www.openal.org/openal_vista.html >>> > >>> > It sounds like openal will be the old way to get hw accelerated 3d >>>sound on >>> > vista, and creative is writing a dsound -> openal wrapper. Maybe it >>>gets a >>> > proper license so we can include it in wine :-) >>> > >>> > Maybe we should write an openal thunk for wine? Many games use openal, >>>and it >>> > seems that on wine openal uses directsound. That might work more >>>better and >>> > faster if we had a openal.dll which directly called linux openal :-) >>> > >>> > Just dropping the suggestions :-) >>> >>>There was something a while ago... >>> >>> >>>Google-Result for "wineopenal": >>>http://www.winehq.com/pipermail/wine-devel/2006-June/048273.html >>> >>> >>>-- >>> >>>By by ... Detlef >>> >> >> >> >> > > > >

3 10

Wine internship available
by Dan Kegel Nov. 23, 2006

Nov. 23, 2006

James Hawkins is wrapping up his internship with me next month, and boy will I miss him! (See http://cia.navi.cx/stats/author/James%20Hawkins%20%3Ctruiken(a)gmail.com%3E for one reason why!) If you know any students who are good programmers who would like to get paid to work on Wine for a term, please send them to http://www.kegel.com/academy/ Thanks! - Dan

1 0

Suggestions on your FAQ
by M.D. van Es Nov. 23, 2006

Nov. 23, 2006

Hello, Searching your website http://www.winehq.org for information on release 1.0of Wine, I read your FAQ and found some items that appear to be out of date. Hopefully, you'll find the following remarks helpful. 1. - following the link: http://www.winehq.com/site/docs/wine-faq/index#ARE-HERE-ANY-ALTERNATIVES-TO… - that is paragraph 2.3 - here is nothed that both VMWare and Win4Lin cost money. To my knowledge, some months ago, VMWare has released some free software, first the Viewer and later on the VMWare Server, although it remains closed source and in my opinion cannot be compared to Wine in that it does emulate. 2. - following the link: http://www.winehq.com/site/docs/wine-faq/index#WHEN-WILL-WINE-BE-FINISHED - that is paragraph 2.12 - The current release being referred to in the last line is Wine 0.9 to be released around September 30th 2005. I'm sure this is not valid. In fact, I read you were working on release 1.0 for the end of 2006. http://tweakers.net/nieuws/44607/Plannen-voor-Wine-1.0-gepresenteerd.html(D…. Succes with your work, I'm enjoying it every day. Regards, Martin van Es

1 0

Problem with optary.h
by Francois Gouget Nov. 23, 2006

Nov. 23, 2006

I have done a test compilation of the Wine conformance tests on Windows and found that dlls/mshtml/tests/misc.c fails to compile because it depends on the optary.h header. The problem is that this header is not part of the Platform SDK or of the DirectX SDK. Apparently it is only part of the IE6 SDK, which seems to be deprecated now. At least that's the impression I got from: http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/samples/in… This raises the following questions: * Should optary.h really be in Wine's global include directory? * How should one go about compiling misc.c with the Windows headers? Should we add the IE SDK as a requirement for compiling the Wine conformance tests? * Is optary.h still present in the IE 7 SDK (or equivalent)? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux: the choice of a GNU generation

1 0

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

Nov. 22, 2006

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 Nov. 22, 2006

Nov. 22, 2006

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 Nov. 22, 2006

Nov. 22, 2006

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 Nov. 22, 2006

Nov. 22, 2006

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 Nov. 22, 2006

Nov. 22, 2006

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 Nov. 22, 2006

Nov. 22, 2006

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 Nov. 22, 2006

Nov. 22, 2006

> 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 Nov. 22, 2006

Nov. 22, 2006

"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 Nov. 22, 2006

Nov. 22, 2006

"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 Nov. 22, 2006

Nov. 22, 2006

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

Wine 0.9.25 full of regressions!
by Mirek Nov. 21, 2006

Nov. 21, 2006

Hi, i just instaled wine 0.9.25 (i had 0.9.24) and it is full of regressions, why is this possible, why is not there someone who can test wine before it came out to new release? 1. 3DMark 2003 - cant open setigns menu 2. 3DMark 2003 - with GLSL, almost all working test are broken (bad graphic) 3. 3DMark 2003 - with ARB is about 25% slower 4. HL2 Episode One - Some characters are black 5. NFS: MW - with ARB it is slower 6. W3 - cannot run, because of Opengl init 7. W3 FT - same as W3 8. nVidiaSDK - opengl demos in nVidia are not working anymore 9. nVidiaSDK - some Direct3D demos are broken more than in release 0.9.24 9. Prey - not working This is pretty big list, almost half of my apps are not working, or working worst than before, it is sad. Mirek Slugen

10 19

Re: winequartz.drv: Add mouse events handling and stub window creation support. (take2)
by Detlef Riekenberg Nov. 21, 2006

Nov. 21, 2006

On Mo, 2006-11-20 at 16:48 +0100, Pierre d'Herbemont wrote: > +/* --------------------------------------------------------------------- > + * send_mouse_input > + */ > +static void send_mouse_input( HWND hwnd, DWORD flags, DWORD x, DWORD y, > + DWORD data, DWORD time, DWORD extra_info, UINT injected_flags ) > +{ > + POINT pt; > + > + pt.x = x; > + pt.y = y; Hi. Some more questions. POINT pt is never used for more than accessing pt.x and pt.y in this function, which is really useless, as both values are fn-parameters. Is there code waiting, that use pt? A comment would be nice for this case. Did you already try to replace "DWORD x, DWORD y" with "POINT pt" for the driver-internal Functions? > +BOOL QDRV_CreateWindow( HWND hwnd, CREATESTRUCTA *cs, BOOL unicode ) > + if (cs->cx > 65535) > + { > + ERR( "invalid window width %d\n", cs->cx ); > + cs->cx = 50; > + } Setting the minimal or maximal size to 50 looks strange for me. Is this an leftover from debugging? > \ No newline at end of file This is easy to fix. -- By by ... Detlef

6 6

Re: rpcrt4: Allow applications to specify authentication levels other than connect in RpcBindingSetAuthInfoA/W.
by Kai Blin Nov. 21, 2006

Nov. 21, 2006

On Tuesday 21 November 2006 14:09, Robert Shearman wrote: > + /* FIXME: the mapping should probably be retrieved using SSPI somehow */ > + if (AuthnLevel == RPC_C_AUTHN_LEVEL_DEFAULT) > + AuthnLevel = RPC_C_AUTHN_LEVEL_NONE; I figure this could be done using QueryContextAttributes, I guess. So far this is a bit stubbed out, but it should basically do the right thing (tm) for integrity and confidentiality. Cheers, Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.

1 0

Re: user32: Add a rudimentary WM_SETFONT message test for the static control, make it pass under Wine
by Alexandre Julliard Nov. 21, 2006

Nov. 21, 2006

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > @@ -496,7 +504,10 @@ static LRESULT StaticWndProc_common( HWN > { > SetWindowLongPtrW( hwnd, HFONT_GWL_OFFSET, wParam ); > if (LOWORD(lParam)) > - STATIC_TryPaintFcn( hwnd, full_style ); > + { > + InvalidateRect( hwnd, NULL, TRUE ); > + UpdateWindow( hwnd ); > + } A single RedrawWindow call would be more efficient. > @@ -673,9 +684,7 @@ static void STATIC_PaintTextfn( HWND hwn > if (!IsWindowEnabled(hwnd)) SetTextColor(hdc, GetSysColor(COLOR_GRAYTEXT)); > } > > - if (!(len = SendMessageW( hwnd, WM_GETTEXTLENGTH, 0, 0 ))) return; > - if (!(text = HeapAlloc( GetProcessHeap(), 0, (len + 1) * sizeof(WCHAR) ))) return; > - SendMessageW( hwnd, WM_GETTEXT, len + 1, (LPARAM)text ); > + if (!(len = InternalGetWindowText( hwnd, text, sizeof(text)/sizeof(WCHAR) ))) return; You are introducing a hard-coded limit to the length of the text, that's not a good idea. -- Alexandre Julliard julliard(a)winehq.org

1 0

FW: Re: Hebrew translation of wine
by Scott Ritchie Nov. 21, 2006

Nov. 21, 2006

Of course, translations are always welcome. The trick is, I really have no idea how Rosetta works or which parts belong in Ubuntu Rosetta and which parts belong in upstream Wine. Therefore I'm forwarding your message to wine-devel, hopefully someone there can enlighten me. Thanks, Scott Ritchie On Mon, 2006-11-20 at 18:53 +0200, Amichai Teumim wrote: > Hi Scott > > I would like to translate Wine to Hebrew for Ubuntu using Rosetta. > > Would you approve of this? > > Thanks > > Amichai

4 4