July 2008 - Wine-devel - list.winehq.org

Re: quartz: Add support for the file writer filter
by Alexandre Julliard 22 Jul '08

22 Jul '08

"Maarten Lankhorst" <m.b.lankhorst(a)gmail.com> writes: > This should be in qcap, however it doesn't have the directshow > primitives (wine directshow base classes) that quartz has. If you > reject it for that reason, please let me know.. If it's in qcap on Windows it should clearly be in qcap on Wine. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: oleaut32: fix the SafeArrayGetVartype tests on Vista and use that behaviour. [try 3] [resend]
by Alexandre Julliard 22 Jul '08

22 Jul '08

"Reece Dunn" <msclrhd(a)googlemail.com> writes: > This includes Rob Shearman's suggestion of marking the old behaviour > as broken() as it is clearly a bug, and also updated the > SafeArrayGetVartype implementation to return the correct value in this > case. > > The tests pass on Vista and on Wine. > > Was there anything wrong with this patch? You should simplify the test, there's no need for two separate branches. -- Alexandre Julliard julliard(a)winehq.org

1 0

ntdll/server and unix_fd handling
by Kai Blin 22 Jul '08

22 Jul '08

Hi folks, I'm currently trying to get some integrated Wine/Samba tests working and in order to do so, I'm trying to add Samba socket wrapper support to Wine (i.e. allow Wine to hook into Samba's fake AF_FILE-based networking for testing). The socket wrapper code keeps track of the unix_fds of the sockets it's wrapping, because it can also _not_ wrap other fds. Now, I've been trying to connect this in dlls/ws2_32/socket.c:WSASocketW() by getting the unix_fd of the SOCKET the create_socket wineserver call returns, by calling get_sock_fd(). Now I noticed that every time I call this for the same SOCKET, the unix_fd increases by 1, effectively killing the tracking socket_wrapper does. After some more digging, upstream of the get_sock_fd call, the server_get_unix_fd() call always gets the same fd, either from wineserver or from the cache. wine_server_handle_to_fd() then seems to call dup() on the unix_fd. This seems to be needed because for some reason unix fds are used only temporary, so get_sock_fd is always followed by release_sock_fd(), which calls a close(). Why is this handled this way? Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

2 1

Re: general question..
by James Hawkins 22 Jul '08

22 Jul '08

On Mon, Jul 21, 2008 at 8:41 PM, Chris Ahrendt <celticht32(a)aol.com> wrote: > As I have been going through trying to debug the everquest2 issues on my > machine I have run into a few places where I think the code should be > changed a little ( this alot of times is where there is a GOTO in the > code). My question is in the case where I do find these goto's and I > rewrite the code should I submit the changes here for approval? > I have been doing some code reviews and found a few places where > there are goto's that don't need to be there. I guess I am old school > and really dislike code with goto's (they make debugging and maintenance > a nightmare (I used to maintain 20 year old cobol code along time ago =) ) > You're not going to find many in this project that agree with your stance on the use of goto's. That being said, I'm curious to see where you think the use of goto's should be replaced by something else. Feel free to send a RFC to wine-devel. P.S. Please don't send discussion emails to wine-patches. wine-devel is for discussion and wine-patches is for patches only. -- James Hawkins

1 0

Re: one liner patch to stop crash, everquest2.exe
by celticht32＠aol.com 22 Jul '08

22 Jul '08

yes I am looking at the shaders... and am noticing something as well in the traces... some reason when it goes to ask how much memory to use... on my machine it thinks it only has 16mb of texture memory.. when the laptop has 256mb of video ram...? if you look in device.c the pixel shader fails atleast on my firegl5200.? The other curiosity is that when EverQuest2.exe runs it seems to be going through the adapter initialization two times.. once when it loads then it starts loading up sound? and then it looks atleast in my traces? it initializes the adapter again getting an adapter which is the second adapter (I think) used for dual head.... Chris

1 0

Re: rasapi32: the tests need raserror.h to build using MS headers.
by Stefan Leichter 21 Jul '08

21 Jul '08

Am Monday 21 July 2008 21:44 schrieb Reece Dunn: > The error constants (e.g. ERROR_BUFFER_TOO_SMALL) are defined in > raserror.h, which is needed for the tests to build using the Microsoft > headers (checked against the Vista SDK headers). > > - Reece my wine tree does not have the raserror.h header. Therefore the compilation under wine breaks for me. Did you forget to include the header file in the patch? Stefan

2 1

Re: [Gdiplus try2 02/16] Implement GdipCreateRegion
by Huw Davies 21 Jul '08

21 Jul '08

Adam Petaccia wrote: >@@ -226,6 +277,11 @@ GpStatus WINGDIPAPI GdipSetEmpty(GpRegion*region) > > if(!(calls++)) > FIXME("not implemented\n"); >+ TRACE("%p\n", region); >+ >+ GdipDeleteRegion(region); >+ GdipCreateRegion(&region); >+ region->node->type = RegionDataEmptyRect; > > return NotImplemented; > } This is still wrong. You probably don't even want to implement GdipSetEmpty in this patch anyway. In general you may be better off submitting a smaller patch series rather than 16 patches in one go. Huw.

2 1

Re: [PATCH] shell32: Clear a pointer on failure in XDG_UserDirLookup.
by Lei Zhang 21 Jul '08

21 Jul '08

On Wed, Jul 16, 2008 at 12:54 PM, Lei Zhang <thestig(a)google.com> wrote: > Hi, > > We should clear the out pointer on failure, so the caller won't access bad data. > Anything wrong with this patch? Should I check the return value from XDG_UserDirLookup() instead?

1 1

Re: CUDA wrapper
by Seth Shelnutt 21 Jul '08

21 Jul '08

Well at least it compiled, but it isn't working. We are still getting the message that the function isn't implemented. Initializing Nvidia gpu library cudaMalloc CUDAStream::Allocate failed feature is not yet implemented Now both cudamalloc and all four cuda stream's, cudaStreamCreate, Destroy, Query and Synchronize were implemented. I thought maybe it was because in the spec file I had the cudaStream's as pointers (ptr) so I switched them to long but ti didn't make a difference. Originally the argument was "stream" but I can't get any argument but ptr and long to pass the winegcc for spec files. http://shelnutt.twomurs.com/patches/cuda/cuda.dll.spec Does wine need to somehow be made aware of the presence of the cudart.dll.sofile? We tried putting it in both the system32 and the lib folder but it seems also that maybe WINE needs to be made aware of it?

3 10

Failing make crosstest
by Adam Petaccia 21 Jul '08

21 Jul '08

For me make crosstest fails on comctl32, is anyone else seeing this? Or have I missed a secret step? make[2]: Entering directory `/usr/local/src/cvs/wine/dlls/comctl32/tests' i586-mingw32msvc-windres -i rsrc.res -o rsrc.res.cross.o i586-mingw32msvc-windres: rsrc.res: Not a valid WIN32 resource file make[2]: *** [rsrc.res.cross.o] Error 1 make[2]: Leaving directory `/usr/local/src/cvs/wine/dlls/comctl32/tests' make[1]: *** [comctl32/tests/__crosstest__] Error 2 make[1]: Leaving directory `/usr/local/src/cvs/wine/dlls' make: *** [dlls/__crosstest__] Error 2

1 0