December 2005 - Wine-Devel - list.winehq.org

D3DX9 SDK releases, DLL support (CIV4)
by Andrei Barbu Jan. 2, 2006

Jan. 2, 2006

Hi, I've been playing with getting CIV4 to run on wine. http://appdb.winehq.org/appview.php?versionId=3632&iTestingId=125 I'm left with just one issue. D3DX9_26.DLL is missing. This is a D3D9 SDK release (they put one out every month or so from what I've seen, with a new DLL that has the number incremented). It's mostly like the original with some minor changes. How would I support this in wine? I don't know the wine build system enough to extend it to do this. Is there a nice way to generate these DLLs and to include the d3dx9 dll so I just have to add in/fix missing calls? This may not be an issue now, but as more and more games get released more will depend on these dlls. Thanks, Andrei

5 5

Question about X11DRV_ChoosePixelFormat glXChooseFBConfig returns NULL (glError: 0)
by L. Lenders Jan. 2, 2006

Jan. 2, 2006

Just for the info: after some digging i found a quick hack to get rid of the error: comment line 208 in dlls/x11drv/opengl.c: //TEST_AND_ADD1(ppfd->dwFlags & PFD_STEREO, GLX_STEREO); Somehow setting the PFD_STEREO flag makes doom3 crash and triggers the error mentioned in the subject. After commenting line 208 doom3 starts up just fine. Digging further..... :) (any help appreciated) Louis ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

5 6

SPARC assembly won't compile, problems with NT headers
by Troy Rollo Jan. 1, 2006

Jan. 1, 2006

winegcc from the current WineHQ produces assembly output for SPARC systems that cannot be processed by the assembler. 1. "operation combines symbols in different segments" error. This problem arises because the imports code attempts to generate a relocation involving symbols in different segments (one in the text segment and one in the data segment). SPARC assemblers (including gas on a SPARC) cannot deal with relocations involving symbols in different segments. This only affects position independent code and can be avoided by changing the assembly code output in imports.c to something simpler. 2. "can't resolve `_end' {*UND* section} - `.L__wine_spec_rva_base' {.data section}" This problem is more sinister. It arises from the same limitation as the first problem, but is not susceptible to being worked around. The offending code is the code that attempts to generate the NT header of the executable - specifically the SizeOfImage element. I can't see any way at this point to provide for this calculation to be done until after the linker output is generated. I suspect the solution to this problem is to just output a zero in this location and have winegcc modify the executable image to insert the correct values after the linker has created it. Does anybody have any objections to this solution or another approach to suggest? -- Troy Rollo - wine(a)troy.rollo.name

7 13

Re: winecfg: Added "Use PRIMARY selection" option
by Stefan Dösinger Jan. 1, 2006

Jan. 1, 2006

> ChangeLog: > > Added support for "Use PRIMARY selection" clipboard option. One question: Why not make this the default? This would be the unix way to use the clipboard. Or use the primary selection on a middle mouse button click, and the other clipboard value on paste / CTRL-V? This is the behavior I'm used to from native apps. Is this possible?

2 2

Re: On creating 16bit windows convert null instances to current process
by Dmitry Timoshkov Jan. 1, 2006

Jan. 1, 2006

"Joseph Garvin" <k04jg02(a)kzoo.edu> wrote: > + /* Correct if instance is null now, because later we won't > + be able to tell the difference between a 16-bit NULL and > + a 32-bit NULL */ > + > + if (!instance) > + { > + HTASK16 hTask = GetCurrentTask(); > + TDB *tdb = GlobalLock16(x); > + instance = tdb->hInstance; > + GlobalUnlock(tdb); > + } Did you ever test it? GlobalLock16 on x coordinate won't return you anything useful, not mentioning a TDB pointer. Probably you meant GlobalLock(hTask)? And GlobalUnlock(tdb) is not right at all, you want GlobalUnlock16(hTask). -- Dmitry.

3 4

Re: WININET: lpvStatusInfo in INTERNET_STATUS_NAME_RESOLVED, INTERNET_STATUS_CONNECTING_TO_SERVER, and INTERNET_STATUS_CONNECTED_TO_SERVER should be strings, not sockaddr_in.
by Robert Shearman Dec. 31, 2005

Dec. 31, 2005

Jacek Caban wrote: >+ /* FIXME: inet_ntoa is not thread safe. */ >+ szaddr = WININET_strdup_AtoW(inet_ntoa(lpwhs->socketAddress.sin_addr)); > INTERNET_SendCallback(&lpwhr->hdr, lpwhr->hdr.dwContext, > INTERNET_STATUS_NAME_RESOLVED, >- &(lpwhs->socketAddress), >- sizeof(struct sockaddr_in)); >+ szaddr, strlenW(szaddr)); >+ HeapFree(GetProcessHeap(), 0, szaddr); > > Like the comment says, it is not thread-safe. I don't think it is wise to delibrately introduce race conditions like this and it tends to cause problems with applications that rely heavily on multiple threads (such as iTunes). It would be better to use the thread-safe inet_ntop (which also has the bonus of supporting IPv6) or the ws2_32 version of inet_ntoa. -- Rob Shearman

1 0

Finding patches in wine-cvs mailing list for regression tests using CVS dates
by Daniel Calviño Sánchez Dec. 31, 2005

Dec. 31, 2005

Hello. First of all, I'm not sure if this message should be posted here, so sorry if it isn't the correct place. I found a regression and made some test to find the patch that caused the problem. I followed the "How to do regression testing using CVS" section in Wine documentation http://winehq.org/site/docs/winedev-guide/x1344, but I think it's outdated. The wine-cvs archive mailing list linked in the documentation is http://www.winehq.org/hypermail/wine-cvs This archive ends in August 2005. I think the archive linked should be http://www.winehq.org/pipermail/wine-cvs/ But the main problem comes now. I used CVS to make the regression test. But when looking in the mailing list messages, the date in them isn't the CVS commit date. Instead, it is the Git commit date (or at least I think so). The Git to CVS gateway seems to get some time to commit the changes to the CVS. So I don't know how can I get the exact patch that caused the problem. I'll try to explain it with my problem. When I update the CVS to "2005-12-21 21:29:02 +0100", the game runs perfectly. However, if I update the CVS to "2005-12-21 21:29:03 +0100", it crashes. However, looking in the mailing list, there are no commits at "2005-12-21 21:29:03 +0100" (the previous was made at "2005-12-21 21:19:47 +0100"). Is there something I'm missing? How could I proceed? Thanks. P.D: I didn't give more information about the crash because the message was mainly focused to the dates in the mailing list question. Of course, I'll fill a bug report when I find the patch that caused the problem.

3 5

Re: Preliminary CD-Rom support on MacOS X #2
by Robert Shearman Dec. 31, 2005

Dec. 31, 2005

emmanuel maillard wrote: > Changelog : > kernel/proces.c : Initialize darwin removable devices I appreciate you splitting up your patches for easier review, but patches are meant to be independent atomic changes that improve the code. However, if Alexandre applied this patch alone then Wine wouldn't compile any more and this isn't acceptable. -- Rob Shearman

3 3

Re: OLEAUT32: Use the FAILED macro to check for failure of interface methods.
by Robert Shearman Dec. 31, 2005

Dec. 31, 2005

Mike McCormack wrote: > } > hr=IStream_Read(pStm,header,8,&xread); >- if (hr || xread!=8) { >+ if (FAILED(hr) || xread!=8) { > FIXME("Failure while reading picture header (hr is %lx, nread is %ld).\n",hr,xread); > return hr; > } >@@ -1128,10 +1128,10 @@ static HRESULT WINAPI OLEPictureImpl_Loa > while (xread < origsize) { > hr = IStream_Read(pStm,xbuf+xread,origsize-xread,&nread); > xread+=nread; >- if (hr || !nread) >+ if (FAILED(hr) || !nread) > break; > } >- if (!nread || hr) /* done, or error */ >+ if (!nread || FAILED(hr)) /* done, or error */ > break; > if (xread == origsize) { > origsize += sizeinc; >@@ -1139,7 +1139,7 @@ static HRESULT WINAPI OLEPictureImpl_Loa > xbuf = HeapReAlloc (GetProcessHeap(), HEAP_ZERO_MEMORY, xbuf, origsize); > } > } >- if (hr) >+ if (FAILED(hr)) > TRACE("hr in no-stat loader case is %08lx\n", hr); > TRACE("loaded %ld bytes.\n", xread); > This->datalen = xread; >@@ -1155,7 +1155,7 @@ static HRESULT WINAPI OLEPictureImpl_Loa > ULONG nread; > hr = IStream_Read(pStm,xbuf+xread,This->datalen-xread,&nread); > xread+=nread; >- if (hr || !nread) >+ if (FAILED(hr) || !nread) > break; > } > if (xread != This->datalen) > > > These changes are wrong. IStream_Read can return S_FALSE, which means that the call was successful, but didn't do what was intended. From MSDN: S_FALSE The data cannot be read from the stream object. Depending on the implementation, either S_FALSE or an error code could be returned when reading past the end of the stream. -- Rob Shearman

3 3

Finding patches in wine-cvs mailing list for regression tests using CVS dates
by Daniel Calviño Sánchez Dec. 30, 2005

Dec. 30, 2005

Hello. First of all, I'm not sure if this message should be posted here, so sorry if it isn't the correct place. I found a regression and made some test to find the patch that caused the problem. I followed the "How to do regression testing using CVS" section in Wine documentation http://winehq.org/site/docs/winedev-guide/x1344, but I think it's outdated. The wine-cvs archive mailing list linked in the documentation is http://www.winehq.org/hypermail/wine-cvs This archive ends in August 2005. I think the archive linked should be http://www.winehq.org/pipermail/wine-cvs/ But the main problem comes now. I used CVS to make the regression test. But when looking in the mailing list messages, the date in them isn't the CVS commit date. Instead, it is the Git commit date (or at least I think so). The Git to CVS gateway seems to get some time to commit the changes to the CVS. So I don't know how can I get the exact patch that caused the problem. I'll try to explain it with my problem. When I update the CVS to "2005-12-21 21:29:02 +0100", the game runs perfectly. However, if I update the CVS to "2005-12-21 21:29:03 +0100", it crashes. However, looking in the mailing list, there are no commits at "2005-12-21 21:29:03 +0100" (the previous was made at "2005-12-21 21:19:47 +0100"). Is there something I'm missing? How could I proceed? Thanks. P.D: I didn't give more information about the crash because the message was mainly focused to the dates in the mailing list question. Of course, I'll fill a bug report when I find the patch that caused the problem.

1 0