wine-devel October 2015

wine-devel@winehq.org

67 participants
305 discussions

Re: [1/4] combase: Add TRACEs to string functions.
by Alistair Leslie-Hughes 25 Oct '15

25 Oct '15

Hi Sebastian, On 25/10/15 14:43, Sebastian Lackner wrote: > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > --- > @@ -95,6 +100,9 @@ HRESULT WINAPI WindowsCreateStringReference(LPCWSTR ptr, UINT32 len, > HSTRING_HEADER *header, HSTRING *out) > { > struct hstring_private *priv = impl_from_HSTRING_HEADER(header); > + > + TRACE("(%p, %u, %p, %p)\n", ptr, len, header, out); Would it make sense to output ptr as a string? Best Regards Alistair Leslie-Hughes

2 1

Re: winmm: Clear adwInfo when the struct MMIOINFO is initialized by MMIO_Open
by Andrew Eikum 25 Oct '15

25 Oct '15

This looks OK to me. What do you think about zeroing the whole structure instead of just some of the fields, just to prevent this problem happening again in the future? In either case, Signed-off-by: Andrew Eikum <aeikum(a)codeweavers.com> On Fri, Oct 23, 2015 at 06:24:02PM +0800, Bruno Jesus wrote: > Signed-off-by: Bruno Jesus <00cpxxx(a)gmail.com> > > The program from bug 35872 registers an IO handler that test adwInfo > and crashes because when MMIO_Open is called these values have > garbage. > > Fixes https://bugs.winehq.org/show_bug.cgi?id=35872 > diff --git a/dlls/winmm/mmio.c b/dlls/winmm/mmio.c > index ad73564..03cadd5 100644 > --- a/dlls/winmm/mmio.c > +++ b/dlls/winmm/mmio.c > @@ -596,6 +596,7 @@ static HMMIO MMIO_Open(LPSTR szFileName, MMIOINFO* refmminfo, DWORD dwOpenFlags, > mmioinfo.pIOProc = NULL; > mmioinfo.pchBuffer = NULL; > mmioinfo.cchBuffer = 0; > + memset(mmioinfo.adwInfo, 0, sizeof(mmioinfo.adwInfo)); > is_unicode = FALSE; > } > > diff --git a/dlls/winmm/tests/mmio.c b/dlls/winmm/tests/mmio.c > index fd5433c..48367ee 100644 > --- a/dlls/winmm/tests/mmio.c > +++ b/dlls/winmm/tests/mmio.c > @@ -599,12 +599,15 @@ static void test_mmioSetBuffer(char *fname) > static LRESULT CALLBACK mmio_test_IOProc(LPSTR lpMMIOInfo, UINT uMessage, LPARAM lParam1, LPARAM lParam2) > { > LPMMIOINFO lpInfo = (LPMMIOINFO) lpMMIOInfo; > + int i; > > switch (uMessage) > { > case MMIOM_OPEN: > if (lpInfo->fccIOProc == FOURCC_DOS) > lpInfo->fccIOProc = mmioFOURCC('F', 'A', 'I', 'L'); > + for (i = 0; i < sizeof(lpInfo->adwInfo) / sizeof(*lpInfo->adwInfo); i++) > + ok(lpInfo->adwInfo[i] == 0, "[%d] Expected 0, got %u\n", i, lpInfo->adwInfo[i]); > return MMSYSERR_NOERROR; > case MMIOM_CLOSE: > return MMSYSERR_NOERROR; > @@ -642,6 +645,18 @@ static void test_mmioOpen_fourcc(void) > mmio.lDiskOffset); > mmioClose(hmmio, 0); > > + /* Same test with NULL info */ > + memset(&mmio, 0, sizeof(mmio)); > + hmmio = mmioOpenA(fname, NULL, MMIO_READ); > + mmioGetInfo(hmmio, &mmio, 0); > + ok(hmmio && mmio.fccIOProc == FOURCC_XYZ, "mmioOpenA error %u, got %4.4s\n", > + mmio.wErrorRet, (LPCSTR)&mmio.fccIOProc); > + ok(mmio.adwInfo[1] == 0, "mmioOpenA sent MMIOM_SEEK, got %d\n", > + mmio.adwInfo[1]); > + ok(mmio.lDiskOffset == 0, "mmioOpenA updated lDiskOffset, got %d\n", > + mmio.lDiskOffset); > + mmioClose(hmmio, 0); > + > mmioInstallIOProcA(FOURCC_XYZ, NULL, MMIO_REMOVEPROC); > > memset(&mmio, 0, sizeof(mmio)); >

2 1

Videos or Slides from WineConf
by Joel Holdsworth 25 Oct '15

25 Oct '15

Hi, are there any plans to publish videos or slides from wineconf? Joel

11 15

Re: [PATCH v2] user32: Added a GetDisplayConfigBufferSizes stub
by Marvin 24 Oct '15

24 Oct '15

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=17611 Your paranoid android. === w1064 (32 bit monitor) === monitor.c:248: Test failed: Unexpected ChangeDisplaySettingsEx() return code for resolution[0]: -2 monitor.c:248: Test failed: Unexpected ChangeDisplaySettingsEx() return code for resolution[1]: -2 monitor.c:248: Test failed: Unexpected ChangeDisplaySettingsEx() return code for resolution[2]: -2 monitor.c:248: Test failed: Unexpected ChangeDisplaySettingsEx() return code for resolution[3]: -2

2 1

Re: d3d11: Make impl_from_ID3D11ShaderResourceView() static.
by Józef Kucia 24 Oct '15

24 Oct '15

Hi Francois, On Sat, Oct 24, 2015 at 4:05 PM, Francois Gouget <fgouget(a)free.fr> wrote: > --- > dlls/d3d11/view.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/d3d11/view.c b/dlls/d3d11/view.c > index 91f9265..a62c2de 100644 > --- a/dlls/d3d11/view.c > +++ b/dlls/d3d11/view.c > @@ -1189,7 +1189,7 @@ struct d3d_rendertarget_view *unsafe_impl_from_ID3D10RenderTargetView(ID3D10Rend > > /* ID3D11ShaderResourceView methods */ > > -struct d3d_shader_resource_view *impl_from_ID3D11ShaderResourceView(ID3D11ShaderResourceView *iface) > +static struct d3d_shader_resource_view *impl_from_ID3D11ShaderResourceView(ID3D11ShaderResourceView *iface) It should actually be "static inline". Thanks!

1 0

Wine-git no longer compiles
by Bruno Jesus 23 Oct '15

23 Oct '15

Hi all, I just pulled today's git and wine no longer compiles: bruno@Note:~/programs/wine32$ make make: *** No rule to make target '../wine/Make.vars.in', needed by 'Makefile'. I can see some Makefile changes from Alexandre so probably related, am I the only affected? I'm compiling out of tree and I didn't try make clean yet because rebuilding the whole wine takes a lot of time (over 2 hours). Best wishes, Bruno

3 4

Wine Staging patch submission
by Michael Müller 23 Oct '15

23 Oct '15

Dear Wine developers, a lot of changes regarding the integration of Wine Staging have already been realized, but there are also some tasks left. In this email I would like to talk about the ways on how to submit patches that should be integrated into the staging tree. So far most patch submissions were done through our Wine Staging bug tracker, but now we would like to move the patch submission to WineHQ. We had the choice between using a mailing list or using the upstream bug tracker. For the usual development progress a mailing list is perfectly fine, however patches submitted to Wine Staging are usually either complex, or need more work. Often multiple revisions are required, and we think that its much easier to keep track of the progress of a patchset, when all information is collected in one place. Also, it is much easier to use the existing bug tracker than writing tools for a separate staging patch overview page. ;-) * How does it work? We want to add a new component "patches" into the Staging product in the WineHQ bug tracker. If you want so submit a patch, you can then create a new bug report and add your patch as attachment. In case of a patch series, you can either put them into a tar archive, or add several attachments. You can sign-off your patch if you want to indicate that it would be ready for integration into the development branch, and just needs some more testing. Other developers are of course invited to give feedback on those patches, too. If the patch gets accepted, the status changes to FIXED. If the patch fixes a bug and there is no open bug report for this problem yet, we might also change the status to STAGED and move it to the appropriate upstream category. * Which patches should be sent to Staging? Normal patches should be sent to wine-patches. If Alexandre or a reviewer decides that the patch is dangerous or not good enough, they would tell you to try to get it into Staging first. Someone of the Wine Staging team will then be assigned as reviewer, and provide additional feedback / instructions how to proceed. If the patch just needs some additional testing, we will directly add it to Wine Staging. Otherwise we will ask you to create a bug report, where the patch can be improved iteratively. If you already know that your patch is very experimental, you can skip the first step and directly create a bug report as described above. * What happens after my patch got into Staging? This depends a bit on the reason why your patch was added, but usually one or more of the following things will happen: * you continue working on the patch and send us an updated version * someone else improves the patch (list all authors, for example by signing off the modified patch) * we remove / replace your patch if it turns out to be wrong or if we find a better solution * we (or you) send the patch to wine-patches if we think it is ready Although there are quite a few people testing git versions of Wine Staging, it sometimes makes sense to wait till the patch was included for one release to ensure that it does not introduce any regressions. I hope this answers all your questions regarding the patch submission to Wine Staging :-) Regards, Michael

6 6

Re: [PATCH] user32: Added GetDisplayConfigBufferSizes() stub
by Dmitry Timoshkov 23 Oct '15

23 Oct '15

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > +LONG WINAPI GetDisplayConfigBufferSizes(UINT32 flags, UINT32 *num_path_info, UINT32 *num_mode_info) > +{ > + FIXME("(0x%x %p %p): stub\n", flags, num_path_info, num_mode_info); > + if (num_path_info) *num_path_info = 0; > + if (num_mode_info) *num_mode_info = 0; > + return ERROR_NOT_SUPPORTED; > +} According to MSDN 2nd and 3rd parameters of this API can't be NULL. Also you should probably add a prototype to winuser.h. -- Dmitry.

2 2

Re: [2/2] ntdll: Do not check if object was signaled after user APC in server_select. (resend)
by Marvin 23 Oct '15

23 Oct '15

1 0

Re: [PATCH 2/2] ws2_32: Add support for TF_REUSE_SOCKET to TransmitFile.
by Marvin 23 Oct '15

23 Oct '15

1 0

← Newer
1
...
7
8
9
10
11
12
13
...
31
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel October 2015