- Wine-Devel - list.winehq.org

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: ole db conformance tests
by Dan Kegel Jan. 1, 2006

Jan. 1, 2006

About three years ago, I wrote in http://www.winehq.org/hypermail/wine-devel/2003/01/0208.html : > Say, how close are these kinds of things to being able to run under wine? > http://msdn.microsoft.com/library/en-us/oledb/htm/testtoolsov.asp The MDAC SDK, downloadable from http://msdn.microsoft.com/data/mdac/downloads/ , contains conformance tests for ole db data sources. Seems like we ought to try running them. I just verified that LTM, the test runner app, from MDAC 2.6 SDK, runs under Wine. I haven't tried running any tests, as it looks a bit involved (you have to have visual C++ installed, and you have to build the tests, it seems). Anyway, it seems like MDAC is something we really want to start supporting better, so maybe it's time to start looking into those conformance tests. Even if they only test data sources, heck, that's pretty good right there. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

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. 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.

1 0

Re: MSI: Change some FIXME messages to comments.
by Robert Shearman Dec. 31, 2005

Dec. 31, 2005

Mike McCormack wrote: > ChangeLog: > Change some FIXME messages to comments. How hard would it be to do the work to really fix these FIXMEs? By changing these to comments I think they are going to be forgotten. -- Rob Shearman

2 1

Re: Preliminary CD-Rom support on MacOS X #5
by Markus Amsler Dec. 30, 2005

Dec. 30, 2005

Hi, I took a look at your patches, here's what i've found: ntdll_cdrom.diff: > # > > @ cdecl MODULE_DllThreadAttach(ptr) > @ cdecl MODULE_GetLoadOrderW(ptr wstr wstr) >+@ cdecl CDROM_InitCDDevices() >+@ cdecl CDROM_FoundDevices() >+@ cdecl CDROM_BSDPathForMedia(ptr) >+@ cdecl CDROM_GetMountPointForBSDDevice(ptr) >+@ cdecl CDROM_BSDPathForHandle(long) >\ No newline at end of file - You shouldn't add more seperation hacks. Besides that, if _APPLE_ is not defined, the linker doesn't find these symbols. - Gcc spits out warnings about the missing newlines at the end of files. Markus

2 1