- wine-devel - winehq.org

Re: Added unbound sampler test for pixel shaders. (try 2)
by Henri Verbeet 05 Jun '11

05 Jun '11

Testing 3D and Cube textures (provided they're supported) may be useful too.

1 0

re: gdi speed: 10x slower than real win
by Dan Kegel 05 Jun '11

05 Jun '11

Yup. It's being worked on, slowly; see http://wiki.winehq.org/Performance, especially http://wiki.winehq.org/DIBEngine

1 0

Re: [1/8] d3d8: Use D3DPOOL <-> WINED3DPOOL enum conversion functions instead of implicit conversions (clang)
by Alexandre Julliard 05 Jun '11

05 Jun '11

Frédéric Delanoy <frederic.delanoy(a)gmail.com> writes: > +static inline D3DPOOL d3dpool_from_wined3dpool(WINED3DPOOL type) > +{ > + switch (type) > + { > + case WINED3DPOOL_DEFAULT: return D3DPOOL_DEFAULT; > + case WINED3DPOOL_MANAGED: return D3DPOOL_MANAGED; > + case WINED3DPOOL_SYSTEMMEM: return D3DPOOL_SYSTEMMEM; > + case WINED3DPOOL_SCRATCH: return D3DPOOL_SCRATCH; > + case WINED3DPOOL_FORCE_DWORD: return D3DPOOL_FORCE_DWORD; > + } > + return (D3DPOOL) type; > +} > + > +static inline WINED3DPOOL wined3dpool_from_d3dpool(D3DPOOL type) > +{ > + switch (type) > + { > + case D3DPOOL_DEFAULT: return WINED3DPOOL_DEFAULT; > + case D3DPOOL_MANAGED: return WINED3DPOOL_MANAGED; > + case D3DPOOL_SYSTEMMEM: return WINED3DPOOL_SYSTEMMEM; > + case D3DPOOL_SCRATCH: return WINED3DPOOL_SCRATCH; > + case D3DPOOL_FORCE_DWORD: return WINED3DPOOL_FORCE_DWORD; > + } > + return (WINED3DPOOL) type; > +} I still don't see the point of that kind of switch statement. To be honest I don't see either why we even need different enum types in the first place. -- Alexandre Julliard julliard(a)winehq.org

4 7

gdi speed: 10x slower than real win
by Jarek Czekalski 04 Jun '11

04 Jun '11

Hi Devels The app I use runs unacceptably slow under wine. I suspected gdi routines and wrote a simple win32 api app to make some tests and comparisons. On my box it shows wine gdi is 10 times slower than the real windows. Let's get into details. REASON I love EditPad Pro (appdb editpad pro <http://appdb.winehq.org/objectManager.php?sClass=application&iId=8392>), a text editor with the capabilities for a programmer that I can't find in any other tool. After upgrade from version 6 to 7 I have problems with the usability, due to slow performance. The app is written in Delphi and now they included new interface features. The menus seem to be animated, they roll down instead of popping up immediately. Menus roll down slowly on wine, but that's a little problem, just a noticable thing. I have problems with very typing characters and these problems are almost gone when I switch off all the toolbars. Looks like the icons on them make them slow down the whole app. The author of the app claims that on his vmwared ubuntu everything is ok. I hope to get the judgement from you. TESTING APP I attach zip with source code and the executable of a short win32 api. It's an animated rectangle, optionally with a bitmap inside. It moves pixel by pixel from left to right. The next move is generated by PostMessage(WM_USER) at the end of OnPaint. I hope that's a way of assessing the gdi speed. Time needed to make the full pass of 500 pixels is printed on the screen. RESULTS test_gdi.exe without parameters draws bitmapped rect, while with the option "t" - the rect is bare. I tested 3 evironments and took 2 measurings on each of them. First number is the bitmapped time. Units are seconds. wine 0.39 0.22 - every movement phase is drawn vmwared w2k 0.123 0.085 - only several painted rects in random places w2k 0.0387 0.0285 - several painted every 2nd line, skewed rects The factor of 10 comes from comparing bitmapped time between wine and real W2K. Wine graphics is perfect, and the faster environments take some shorter ways. POSSIBLE EXPLANATION Just my imagination. I guess Windows buffer their graphics outcome in memory. Fast changes in this memory are not passed to the graphic device. This would explain the artifacts seen in the experiment and also the lack of flickering of the apps under the real win. For example mentioned EditPadPro redraws its edit area with every character typed (at least in the syntax highlighting mode), while under real win this behaviour is undetectable. BIBLIOGRAPHY The speed issue was reviewed in such posts I could locate: GDI Question <http://www.winehq.org/pipermail/wine-devel/2003-February/014052.html> (2003) Windows 2D GDI benchmark tools? <http://www.winehq.org/pipermail/wine-devel/2009-July/077144.html> (2009) Speed problem with Wine... <http://www.winehq.org/pipermail/wine-users/2001-July/007320.html> (2001) Has anything changed? LAST WORD I hope you'll benefit from the tester I wrote. I'm looking forward to see your comments. Do you notice the same speed multiplier as me: 10x? Maybe I have to fix my Debian to reach better results. Jarek

1 0

Re: wined3d: Enable blit stretching for 64 bpp
by Roderick Colenbrander 04 Jun '11

04 Jun '11

Hi André, I'm not sure if we should add this change since for a part it hides the real problem. Sure this patch likely works, but >32bpp blits should never enter the software rendering code in the first place. The code used to be a huge mess and Henri cleaned it up quite a bit already (thanks, because I became too busy). It may be easier now to fix this properly. Roderick 2011/6/4 André Hentschel <nerv(a)dawncrow.de>: > For http://bugs.winehq.org/show_bug.cgi?id=27377 > --- > dlls/wined3d/surface.c | 3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c > index 91b16a6..7f9d9df 100644 > --- a/dlls/wined3d/surface.c > +++ b/dlls/wined3d/surface.c > @@ -6780,6 +6780,9 @@ do { \ > case 4: > STRETCH_ROW(DWORD); > break; > + case 8: > + STRETCH_ROW(DWORD64); > + break; > case 3: > { > const BYTE *s; > -- > > Best Regards, André Hentschel > > >

1 0

Re: cmd: ensure create_full_path returns FALSE for all errors
by Marcus Meissner 04 Jun '11

04 Jun '11

On Sat, Jun 04, 2011 at 04:37:05PM +0200, Frédéric Delanoy wrote: > This resolves the issue from bug #27383 > --- > programs/cmd/builtins.c | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/programs/cmd/builtins.c b/programs/cmd/builtins.c > index 0352e59..18e16fe 100644 > --- a/programs/cmd/builtins.c > +++ b/programs/cmd/builtins.c > @@ -496,6 +496,7 @@ static BOOL create_full_path(WCHAR* path) > WCHAR *slash; > DWORD last_error = GetLastError(); > if (last_error == ERROR_ALREADY_EXISTS) > + ret = FALSE; > break; You at least miss { } here. Ciao, Marcus

2 1

Re: [1/2] d3d8: Increment the reference count of the IDirect3D8 parent when creating a device.
by Stefan Dösinger 04 Jun '11

04 Jun '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The two patches look ok Am 03.06.2011 um 14:23 schrieb Andrew Nguyen: > --- > dlls/d3d8/d3d8_private.h | 5 +++-- > dlls/d3d8/device.c | 29 ++++++++--------------------- > dlls/d3d8/directx.c | 2 +- > dlls/d3d8/tests/device.c | 12 ++++++++++++ > 4 files changed, 24 insertions(+), 24 deletions(-) > > > <0001-d3d8-Increment-the-reference-count-of-the-IDirect3D8-p.txt> -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJN6jEJAAoJEN0/YqbEcdMwpNoP/33vRTq283VUfbwKhtVwYGQP hkp1Hh53id7moMGQ4YoH6BhsdWH2KeAvx5asuHEiciJZ/6JiS5Jc/1tNIuD5U+HS RcaFsOrKInuvbPojZECNoe1J/JH5i/A7fCLrAY+FknXOWz+t1UsD6sQbaZqVRM4H j7SvP335TRYYN/8KOyuI2vc2ZDQ+aLo+MXoQpu/7OfRbnnbCsR2ddDLCw/B6ktDN W0fUHjxRU5OigKebUG/KIcXmxYIbbVvNABR4UpRG30Py68CXlYsSM04HRZK4rLea H9pTGSLN1b2eybDKeDbwuIcCVsZHEDFp/mCYxQhPnGoPMHvwfUcHgP8q/rJrTN8+ JYWWYq4g9CuawMxjKivycq30PmAjl2vFl2Dttt9eDuub49ND6sqdDEmcJm8evvhn edOaV8C1o8TVQ4i4AOuUGyMjP3LdXrE02Ec60qjGq5J94NLolAAj5qjDX1JhwghW NKeSsNKGAdstD1FUBOZ6kOPWJ9OOFWyA0GQjiJ7/6616lbjvxJqso/D7IariJImz k/8Rb5UYgYOfB5sHXcyU0pohjouXBqntC5la0Bd1EMy44lZ61K6b03e7rpsyFTKI Wq3Noq1LE4u0gr0E00jE91UVyo30a3Msr6Ss8p1DJf/wmxbrUWNODvYXVlLUd06+ 18tpvn6fFHzrE9vBq3Ll =tSUa -----END PGP SIGNATURE-----

1 0

Re: wineoss.drv: Add mmdevapi driver.
by Gerald Pfeifer 04 Jun '11

04 Jun '11

I believe commit be332326ba8fc3def406c5f29adf04fbe9a83976 Author: Andrew Eikum <aeikum(a)codeweavers.com> Date: Wed Apr 27 09:12:36 2011 -0500 is causing the following build failures on my nightly FreeBSD testers: mmdevdrv.c:463:20: error: 'AFMT_S24_PACKED' undeclared (first use in this function) mmdevdrv.c:476:16: error: 'AFMT_FLOAT' undeclared (first use in this function) mmdevdrv.c:854:24: error: 'AFMT_FLOAT' undeclared (first use in this function) mmdevdrv.c:863:24: error: 'AFMT_S24_PACKED' undeclared (first use in this function) mmdevdrv.c:1084:24: error: 'SNDCTL_DSP_HALT' undeclared (first use in this function) Looks like some autoconfigury is not working or incomplete? Gerald

3 6

Re: wineoss.drv: Support platforms that do not feature AFMT_FLOAT.
by Andrew Eikum 04 Jun '11

04 Jun '11

On 05/07/2011 07:46 PM, Gerald Pfeifer wrote: > As we have seen from a related thread on wine-devel, FreeBSD's > implementation of OSS is slightly, though not a lot, different from > what current Linux distributions feature. > > This patch addresses one such case, AFMT_FLOAT which does not exist > on FreeBSD (yet?), and I'm sure other non-Linux systems. I guess we can add this workaround. I don't know how far down this road we should be willing to go, though. I would consider the FreeBSD implementation broken: it deviates from the spec as stated by the authors. So this seems to be their bug, not ours. How far should we bend over backwards to accommodate their bug? Anyways this is a tiny hassle, so I'm fine with it. Perhaps you should consider filing a FreeBSD bug? Thanks Gerald. Andrew > I created this diff with more context so that it becomes immediate that > this patch is harmless in that AFMT_FLOAT is handled as an error case > for system not providing it. > > Gerald > > --- > dlls/wineoss.drv/mmdevdrv.c | 4 ++++ > 1 files changed, 4 insertions(+), 0 deletions(-) > > diff --git a/dlls/wineoss.drv/mmdevdrv.c b/dlls/wineoss.drv/mmdevdrv.c > index 789cb1e..254a119 100644 > --- a/dlls/wineoss.drv/mmdevdrv.c > +++ b/dlls/wineoss.drv/mmdevdrv.c > @@ -504,25 +504,27 @@ static int get_oss_format(const WAVEFORMATEX *fmt) > case 32: > return AFMT_S32_LE; > } > return -1; > } > > if(fmt->wFormatTag == WAVE_FORMAT_IEEE_FLOAT || > (fmt->wFormatTag == WAVE_FORMAT_EXTENSIBLE&& > IsEqualGUID(&fmtex->SubFormat,&KSDATAFORMAT_SUBTYPE_IEEE_FLOAT))){ > if(fmt->wBitsPerSample != 32) > return -1; > > +#ifdef AFMT_FLOAT > return AFMT_FLOAT; > +#endif > } > > return -1; > } > > static WAVEFORMATEX *clone_format(const WAVEFORMATEX *fmt) > { > WAVEFORMATEX *ret; > size_t size; > > if(fmt->wFormatTag == WAVE_FORMAT_EXTENSIBLE) > size = sizeof(WAVEFORMATEXTENSIBLE); > @@ -935,27 +937,29 @@ static HRESULT WINAPI AudioClient_GetMixFormat(IAudioClient *iface, > > if(This->dataflow == eRender) > formats = This->ai.oformats; > else if(This->dataflow == eCapture) > formats = This->ai.iformats; > else > return E_UNEXPECTED; > > fmt->Format.wFormatTag = WAVE_FORMAT_EXTENSIBLE; > if(formats& AFMT_S16_LE){ > fmt->Format.wBitsPerSample = 16; > fmt->SubFormat = KSDATAFORMAT_SUBTYPE_PCM; > +#ifdef AFMT_FLOAT > }else if(formats& AFMT_FLOAT){ > fmt->Format.wBitsPerSample = 32; > fmt->SubFormat = KSDATAFORMAT_SUBTYPE_IEEE_FLOAT; > +#endif > }else if(formats& AFMT_U8){ > fmt->Format.wBitsPerSample = 8; > fmt->SubFormat = KSDATAFORMAT_SUBTYPE_PCM; > }else if(formats& AFMT_S32_LE){ > fmt->Format.wBitsPerSample = 32; > fmt->SubFormat = KSDATAFORMAT_SUBTYPE_PCM; > }else if(formats& AFMT_S24_LE){ > fmt->Format.wBitsPerSample = 24; > fmt->SubFormat = KSDATAFORMAT_SUBTYPE_PCM; > }else{ > ERR("Didn't recognize any available OSS formats: %x\n", formats); > return E_FAIL; > >

2 1

Re: loader: Add Polish translation
by Frédéric Delanoy 04 Jun '11

04 Jun '11

2011/6/3 Łukasz Wojniłowicz <lukasz.wojnilowicz(a)gmail.com>: > --- > loader/wine.pl.man.in | 327 +++++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 327 insertions(+), 0 deletions(-) > create mode 100644 loader/wine.pl.man.in > > diff --git a/loader/wine.pl.man.in b/loader/wine.pl.man.in > new file mode 100644 > index 0000000..e4a14a8 > --- /dev/null > +++ b/loader/wine.pl.man.in > @@ -0,0 +1,327 @@ > +.\" -*- nroff -*- > +.TH WINE 1 "June 2011" "@PACKAGE_STRING@" "Windows On Unix" That line is not translated Also, you might want to alter the Makefile.in for install/uninstalls Frédéric

1 0

Re: [2/2] explorer: add a navbar to explorer
by Juan Lang 03 Jun '11

03 Jun '11

Hi Jay, +static const WCHAR ForwardButtonName[] = {'F','o','w','a','r','d','\0'}; Misspelled. --Juan

1 0

Re: [1/2] explorer: implement the explorer using IExplorerBrowser
by Juan Lang 03 Jun '11

03 Jun '11

Hi Jay, +static void MakeExplorerWindow(IShellFolder* startFolder, HINSTANCE hInstance) I know the general rule of thumb when modifying an existing file is to keep its style, but we also tend to stay away from this style of function naming. It looks too much like the functions could be Win32 API names. Preferred style is the "one true style" of function naming, e.g. make_explorer_window instead. As it happens, explorer.c is the odd man out in programs/explorer, and since it only has 4 functions at the moment, it's probably better to change them than to add more functions with this style. Thanks, --Juan

1 0

Re: [PATCH 1/4] winealsa.drv: Partially implement IAudioSessionManager2
by Joris Huizer 03 Jun '11

03 Jun '11

I'm sorry if I'm wrong, but it seems to me in this and following patches, the AudioSessionManager_Release() function is incomplete - I think the dealing with ref == 0 is missing. HTH, Joris

2 1

WineConf 2011 - Minneapolis, MN - October 1,2
by Jeremy White 03 Jun '11

03 Jun '11

Hi Folks, We have made arrangements for this year's WineConf to happen in Minneapolis, MN on Saturday October 1 and Sunday October 2. Minneapolis is the little known other city of the Twin Cities across the river from our home town, St. Paul. I've put some preliminary information up on the Wiki: http://wiki.winehq.org/WineConf2011 We thought that this year it would be fun to stay in downtown Minneapolis, as there is quite a bit to do there. Further, at that time of year, the weather has a good chance of being beautiful, so it will hopefully be a great time for all. I checked, and only very rarely has it been below freezing on October 1 <evil grin>. (Seriously, it's usually very nice. Really. Trust me). If you are interested in WineConf, and have contributed to Wine, but are not sure if you can afford the travel costs, please write to me. The Wine Party fund is used mostly to defray travel costs these days and we may be able to help. Note that most further communication will happen on the wineconf(a)winehq.org mailing list; if you're interested, you should subscribe. If you're coming, please hit the RSVP page: http://www.winehq.org/wineconf/rsvp/ Hope to see you in Minneapolis! Cheers, Jeremy

1 0

Re : Re : ddraw: Add tests for Setcooperativelevel
by paulo lesgaz 03 Jun '11

03 Jun '11

Any reason it was not commited yet? A+ David ________________________________ De : paulo lesgaz <jeremielapuree(a)yahoo.fr> À : Stefan Dösinger <stefandoesinger(a)gmx.at>; wine-devel(a)winehq.org Envoyé le : Mer 1 juin 2011, 20h 37min 36s Objet : Re : ddraw: Add tests for Setcooperativelevel ________________________________ De : Stefan Dösinger <stefandoesinger(a)gmx.at> À : wine-devel(a)winehq.org Cc : paulo lesgaz <jeremielapuree(a)yahoo.fr> Envoyé le : Mer 1 juin 2011, 15h 11min 25s Objet : Re: ddraw: Add tests for Setcooperativelevel On Wednesday 01 June 2011 08:01:57 paulo lesgaz wrote: >> Hi, >> >> any problem with the patch >> >> http://source.winehq.org/patches/data/74702 >I guess Alexandre was waiting for a reply from me or Henri. > >The tests themselves look ok, but I wonder what your ultimate goal is - is >there a game that has issues with DDSCL_CREATEDEVICEWINDOW? Yes, see bug 25660 My tests prove that DDSCL_CREATEDEVICEWINDOW+DDSCL_EXCLUSIVE+DDSCL_FULLSCREEN is allowed with a NULL window. That is what expected by Half life I demo. Currently, Wine returns DDERR_INVALIDPARAMS. Obviously, there are already tests that prove that DDSCL_EXCLUSIVE+DDSCL_FULLSCREEN fails with a null window. > Also the tests we >have are somewhat unsatisfying, we don't have a single test where >DDSCL_CREATEDEVICEWINDOW is supposed to succeed. Maybe it would be the subject of an another patch? A+ David

1 0

Re:o
by Nick Burns 03 Jun '11

03 Jun '11

http://www.sisco.ch/indexz35X.php

1 0

Re: [1/3] kernel32/heap: Emulate Win9x if appropriate in GlobalMemoryStatusEx(). (resend)
by Dmitry Timoshkov 03 Jun '11

03 Jun '11

Adam Martinson <amartinson(a)codeweavers.com> wrote: > + osver.dwOSVersionInfoSize = sizeof(osver); > + GetVersionExW(&osver); > + ... > + if (osver.dwMajorVersion >= 5) Once again, that's wrong way of detecting win9x, or please try to explain better how the patch does what the subject describes, and for which app it's needed. -- Dmitry.

3 5

Re: [PATCH 3/3] msvcrt: Improved tolower_l and toupper_l implementation
by Marvin 03 Jun '11

03 Jun '11

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 http://testbot.winehq.org/JobDetails.pl?Key=11457 Your paranoid android. === WNT4WSSP6 (32 bit string) === string.c:1987: Test failed: ret = fffffff4 string.c:1992: Test failed: ret = ffffffd0 === W2KPROSP4 (32 bit string) === string.c:1987: Test failed: ret = fffffff4 string.c:1992: Test failed: ret = ffffffd0 === WXPPROSP3 (32 bit string) === string.c:1987: Test failed: ret = fffffff4 string.c:1992: Test failed: ret = ffffffd0 === W2K3R2SESP2 (32 bit string) === string.c:1987: Test failed: ret = fffffff4 string.c:1992: Test failed: ret = ffffffd0

1 0

Re: [4/4] ws2_32: Avoid a crash with an optional pointer in WSAAsyncGetServByName.
by Marvin 03 Jun '11

03 Jun '11

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 http://testbot.winehq.org/JobDetails.pl?Key=11362 Your paranoid android. === WXPPROSP3 (32 bit sock) === sock.c:501: Test failed: oob_server (218): unexpectedly at the OOB mark: 0 sock.c:511: Test failed: oob_server (218): unexpectedly at the OOB mark: 0

3 3

mmdevapi buffering
by Joerg-Cyril.Hoehle＠t-systems.com 03 Jun '11

03 Jun '11

Hi, I have one big concern about MSDN's "Rendering a stream" (shared mode) example w.r.t wrap-around of buffer pointers and how Wine implements it. The example is at http://msdn.microsoft.com/en-us/library/dd316756(v=vs.85).aspx Suppose the write pointer is near the end of the buffer and the app is a little late, so the HW read pointer is not far away. |---------------------------------------------------^read------^write-----| What is GetCurrentPadding going to return? - the tiny write-read portion, says MSDN AFAICT - 0, because there's a new fresh buffer waiting to be filled? MSDN's example then computes avail = GetBufferSize() - GetCurrentPadding(); What is GetBuffer(avail) going to return?!? - If it's a pointer to the above buffer, it can only succeed if avail is tiny, otherwise there's a buffer overflow. However avail, as defined above and in MSDN's example, will be large. Wine tricks around that by returning a dynamic local tmp buffer larger than GetBufferSize (I wonder why a fixed one instead, twice GetBufferSize would not suffice?) Does native behave like that? - E_BUFFER_TOO_LARGE ? The MSDN example would exit. - Could it be a pointer to the beginning of the buffer? - Or it's a pointer to another buffer! That's not compatible with Wine's current local_buffer implementation... Isn't Wine's mmdevapi going to produces glitches? The problematic situation is when avail is small, as the following sleep for half a buffer size in MSDN's example will inevitably produce an xrun. So what actually is the buffer size and how does GetCurrentPadding behave? I don't expect MSDN's example to be fundamentally flawed. IMHO, they designed their API such that it is the typical use case. I believe that multiple buffers (of size GetBufferSize) are involved (much like ALSA's periods) and that GetBuffer switches among them -- exactly like they say about the exclusive mode ping pong. I suppose native's mixer (in shared mode) would mix these possibly incompletely filled buffers and everything is fine there. No need to deal with wrap-around! Why should Wine do something entirely different? Regards, Jörg Höhle

2 2

Re: [1/5] wined3d: Add support for GL_ARB_timer_query.
by Stefan Dösinger 03 Jun '11

03 Jun '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'd recommend to wait for Henri to return from vacation before applying these Am 02.06.2011 um 19:25 schrieb Adam Martinson: > --- > dlls/wined3d/directx.c | 1 + > dlls/wined3d/wined3d_gl.h | 19 +++++++++++++++++++ > 2 files changed, 20 insertions(+), 0 deletions(-) > > > <0002-wined3d-Add-support-for-GL_ARB_timer_query.patch> -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJN6KyMAAoJEN0/YqbEcdMw+doP/jwoZxrZSkkgguKyN0MKlpNl BaYc2Yc3uGdNrOLCk78X/Zu1otVVlNZJHR5xIID3ZaK0egjhHRXF7Ljhj36paduN u25lslD4iN1IRHocDm0C0IqmmX5Q8YMrGSf1Xxn19KFaWV7tTHqs5KE4Dz707lct 0R/doxjYyZ4uBiE9FIglnPm2DZsyZoi5RPlYZA2XSD5uC57hD8hdqQPmLGXw+O42 WpjvNsN+hDwghJOEBCyG93rsttU7Zb9CBAQJS/CqYegG0L6cbRAZHebj/kHgWT7M 4TBNlo0rElgcD3/2CXNK1jjDSvAKS1soicnv7ZtlKbbmEHPE4EaQ82giIkqJB2Vv NddGTh9JvINLVq8FBJwRs9CwAMhVjUeGvrI13tnSUSu4QdcMZ9fxlg2SIeslWNrB x34siT+Eo8hOY6ZP6nTbdScSoxkHvOm4T8xeGKgC0l+sdAdAP18sHV1SgwoSLth/ fk68H6j6unL2S5yaQmIwaC+EKLRQkG+/wlsoFltR0iOplsxYKtm7KvYet6UAQNol Pq7Z1d7KLlg7GnsKgcFVVtXXNgEcKaEchuxUzRKkQy46MbQsghJhDW4mr+8vGwNS bFWf2qxHP0D8b/VnK43tsIAoXb5iA92yAlrC0e3ssy2yMdjS3SiFvwOBQsMtqBrD V0X2LrLXsqM1n00U6mPN =1nqX -----END PGP SIGNATURE-----

1 0

winealsa.drv:mmdevapi input validation
by Joerg-Cyril.Hoehle＠t-systems.com 03 Jun '11

03 Jun '11

Hi, because of bug #27087, I had a look at the emerging mmdevapi code. Actually, it's the first time I read its documentation on MSDN. Here are a few comments of mine while reading the code. The handling of duration (-> buffer size) in winealsa.drv/mmdevdrv.c:AudioClient_Initialize does not perform enough validation. MSDN explicitly acknowledges that it could be 0. I believe it should be related to ALSA's buffer, or a minimum of something like 2*period_size. Or perhaps even 3*period size. IIRC MSDN also documents a maximum of 2s for renderer and 0.5 for capture. AudioRenderClient_ReleaseBuffer does not check that written_frames is what GetBuffer returned. Use with AUDCLNT_BUFFERFLAGS_SILENT and you'll have memcpy overwrite arbitrary amounts of memory. MSDN says: AUDCLNT_E_INVALID_SIZE I believe Wine should currently include if (AUDCLNT_STREAMFLAGS_EVENTCALLBACK && SHAREMODE_EXCLUSIVE) { FIXME("unsupported") & return E_ } because none of the buffer allocation and parameter checking specific to that mode that MSDN mentions in Initialize is implemented. When it (the ping pong buffer logic) will be implemented, some better logic to trigger SetEvent() will probably be needed, because I'm unsure whether CreateTimerQueueTimer() provides the required stability over time and possibly ignores a laptop's suspend/resume cycle or xruns. In exclusive mode, reception of an event is a guarantee that GetBuffer(GetBufferSize frames) will succeed. I suggest the values returned by AudioClient_GetDevicePeriod be adjusted to match what test.winehq shows. 10ms/3ms makes some sense, 10ms is mentioned a lot in MSDN and blogs. 3ms is small yet has a chance to work without glitch with MSDN's exclusive mode example. I can't remember seeing input validation of broken avgbytes and blockalign in the WAVEFORMAT parameter. I showed some tests some month ago that prove that unlike Wine, winmm is not disturbed by bad values. How does mmdevapi react to them? Regards, Jörg Höhle

2 2

Re: [13/18]usp10/tests: add Gurmukhi shaping test
by Marvin 02 Jun '11

02 Jun '11

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 http://testbot.winehq.org/JobDetails.pl?Key=11438 Your paranoid android. === WXPPROSP3 (32 bit usp10) === TestLauncher.c:89: Test failed: Can't open test executable C:\winetest\usp10_test.exe, error 32

1 0

Re: [2/19](resend)usp10: improve Sinhala shaping using Indic rules
by Alexandre Julliard 02 Jun '11

02 Jun '11

Aric Stewart <aric(a)codeweavers.com> writes: > @@ -0,0 +1,236 @@ > + > +#include "config.h" > +#include <stdarg.h> > +#include <stdio.h> > +#include <stdlib.h> Please add a license header on new files. > +#define IS_VALID_INDEX (next < cChar) Don't reference local variables directly, pass them to the macro. > +#define OPTIONAL_CHAR(a) if (IS_VALID_INDEX && lex(input[next])==a) {next++;} > +#define OPTIONAL_CHAR_JOINER() if (IS_VALID_INDEX && IS_JOINER(next)) {next++;} > +#define ZERO_OR_MORE(a) while(IS_VALID_INDEX && lex(input[next])==a){next++;} > +#define ZERO_OR_MORE_MANTRA() while (IS_VALID_INDEX && IS_MANTRA(next)){next++;} Same here, and these should be wrapped in do/while(0). -- Alexandre Julliard julliard(a)winehq.org

1 0

ddraw: Add tests for Setcooperativelevel
by paulo lesgaz 02 Jun '11

02 Jun '11

Hi, any problem with the patch http://source.winehq.org/patches/data/74702 A+ David

2 3

Re: [1/26](resend)usp10: Add Indic syllable parsing and reordering system
by Alexandre Julliard 02 Jun '11

02 Jun '11

Aric Stewart <aric(a)codeweavers.com> writes: > +void Indic_ReorderCharacters( LPWSTR input, int cChar, lexical_function lex, reorder_function reorder_f) > +{ > + int index = 0; > + int next = 0; > + int center; > + > + if (!lex || ! reorder_f) > + { > + ERR("Failure to have required functions\n"); > + return; > + } > + > + debug_output_string(input, cChar, lex); > + while (next != -1) > + { > + ZERO_OR_MORE(lex_Generic); > + index = next; > + next = Indic_process_next_syllable(input, cChar, 0, &center, index, lex); > + if (next != -1) > + { > + reorder_f(input, index, center, next-1, lex); > + index = next; > + } > + else if (index < cChar) > + { > + int i; > + TRACE("Processing failed at %i\n",index); > + for (i = index; i < cChar; i++) > + if (lex(input[i])==lex_Generic) > + { > + TRACE("Restart processing at %i\n",i); > + next = i; > + index = i; > + break; > + } > + } > + } > + TRACE("Processed %i of %i characters\n",index,cChar); > +} Please don't add dead code. This function should be called from somewhere (same for the subsequent patches). -- Alexandre Julliard julliard(a)winehq.org

1 0

A request about the release notes
by Scott Ritchie 02 Jun '11

02 Jun '11

When 1.3.19 came out it changed the build requirements for OSS support -- OSS 3 was no longer supported and OSS 4 dev libraries were required at build time. This was the changelog: New sound driver architecture for MMDevAPI. Better support for relative mouse events in DInput. Debugger support for the ARM platform. Various improvements in D3DX9. More MSVC runtime functions. Various bug fixes. At least two distros broke their OSS support as a result, since the standard "update wine version but use same packaging" didn't return a complete Wine anymore. In my case I only noticed when a bug report came in and I manually looked at the package build log. This sort of thing would be much less likely to happen if such a build dependency change were noted in the release notes, such as a "OSS 3 no longer supported" bullet point. Thanks, Scott Ritchie

1 0

Re: wined3d: Set container of swapchain surfaces to WINED3D_CONTAINER_NONE in swapchain_init() error path.
by Stefan Dösinger 01 Jun '11

01 Jun '11

On Wednesday 01 June 2011 01:38:24 Piotr Pawłow wrote: > Since commit fadfdf21c055caf833a137ffc269c2073dc87fd6 surface refcounts are > forwarded to the container. We need to break this forwarding in > swapchain_init() error path, otherwise the swapchain refcount goes down to > zero and swapchain_cleanup() gets called on an invalid, partly initialized > swapchain. This patch looks OK

1 0

Re: Added unbound sampler test for pixel shaders.
by Alexandre Julliard 01 Jun '11

01 Jun '11

Sean Sube <ssube(a)codeweavers.com> writes: > --- > dlls/d3d9/tests/visual.c | 80 > ++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 80 insertions(+), 0 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M d3d9.dll -T ../../.. -p d3d9_test.exe.so visual.c && touch visual.ok visual.c:8909: Tests skipped: D3DFMT_G16R16 textures not supported as render targets. visual.c:7503: Tests skipped: Card has unconditional pow2 support, skipping conditional NP2 tests visual.c:12112: Test failed: Color is 0xffffffff. make[1]: *** [visual.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

RFC: d3d9: Increment the reference count of the IDirect3D9 instance when creating a device.
by Andrew Nguyen 01 Jun '11

01 Jun '11

The Pathologic demo in bug 21552 expects that the reference count of a IDirect3D9 instance is incremented after a successful call to CreateDevice with the instance. Does my proposed fix for d3d8 and d3d9 manage the reference count of the device parent appropriately? In particular, I'm concerned about the slightly cumbersome acquisition of the pointer to the parent instance within the Release call for the Direct3D device interface. Is the overall location of the AddRef/Release calls correct, and should I be doing something differently when the device tries to decrement the parent reference count?

2 1

Re: infosoft/tests: COM cleanup in infosoft.c.
by Marvin 01 Jun '11

01 Jun '11

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 http://testbot.winehq.org/JobDetails.pl?Key=11350 Your paranoid android. === WVISTAADM (32 bit infosoft) === infosoft.c:183: Test failed: failed infosoft.c:197: Test failed: failed === W2K8SE (32 bit infosoft) === infosoft.c:183: Test failed: failed infosoft.c:197: Test failed: failed === W7PRO (32 bit infosoft) === infosoft.c:183: Test failed: failed infosoft.c:197: Test failed: failed === W7PROX64 (32 bit infosoft) === infosoft.c:183: Test failed: failed infosoft.c:197: Test failed: failed === W7PROX64 (64 bit infosoft) === infosoft.c:183: Test failed: failed infosoft.c:197: Test failed: failed

2 1

Re: [4/5] ddraw: Extend the lifetime of the IDirect3D7::EnumDevices strings beyond function scope.
by Stefan Dösinger 01 Jun '11

01 Jun '11

Does the enum_device_entry structure have to be in ddraw_private.h? I think you can just declare it in ddraw.c because it is used only there. At some point we'll want to get rid of the ddraw device type strings and call wined3d_get_adapter_identifier - but that needs more work and some more tests. Am 31.05.2011 um 12:50 schrieb Andrew Nguyen: > --- > dlls/ddraw/ddraw.c | 43 +++++++++++++------ > dlls/ddraw/ddraw_private.h | 8 ++++ > dlls/ddraw/tests/d3d.c | 98 ++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 136 insertions(+), 13 deletions(-) > > > <0004-ddraw-Extend-the-lifetime-of-the-EnumDevices-strings-b.txt>

2 2

Re: comctl32/tests: Using unsigned constants to remove sign comparison warning.
by Nikolay Sivov 31 May '11

31 May '11

On Fri, May 27, 2011 at 5:16 PM, Marko Nikolic <grkoma(a)gmail.com> wrote: > --- > dlls/comctl32/tests/treeview.c | 6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/dlls/comctl32/tests/treeview.c b/dlls/comctl32/tests/treeview.c > index 5fd26a0..b1eb85e 100644 > --- a/dlls/comctl32/tests/treeview.c > +++ b/dlls/comctl32/tests/treeview.c > @@ -634,7 +634,7 @@ static void test_get_set_bkcolor(void) > > /* If the value is -1, the control is using the system color for the background color. */ > crColor = (COLORREF)SendMessage( hTree, TVM_GETBKCOLOR, 0, 0 ); > - ok(crColor == -1, "Default background color reported as 0x%.8x\n", crColor); > + ok(crColor == 0xffffffff, "Default background color reported as 0x%.8x\n", crColor); > ~0 looks better here imo. >

3 2

Re: Added unbound sampler test for pixel shaders.
by Stefan Dösinger 31 May '11

31 May '11

On Tuesday 31 May 2011 17:48:14 Sean Sube wrote: > + static const DWORD ps_code[] = > + { > + 0xFFFF0200, 0x0200001F, 0x90000000, 0xA00F0800, > + 0x0200001F, 0x80000000, 0xB00F0000, 0x03000042, > + 0x800F0000, 0xB0E40000, 0xA0E40000, 0x02000001, > + 0x800F0800, 0x80E40000, 0x0000FFFF, > + }; Please write the assembler code into comments, this makes the test easier to read. > + hr = IDirect3DDevice9_GetPixelShader(device, &old_ps); > + ok(SUCCEEDED(hr), "IDirect3DDevice9_GetPixelShader failed, hr %#x.\n", hr); The individual tests should unset the pixel shader, if old_ps is not NULL here that's a bug. > + color = getPixelColorFromSurface(rt, 32, 32); > + ok(color == 0xFF000000, "Color is %#x.\n", color); My understanding is that the test currently fails, so you should mark it as todo: todo_wine ok(...); > + hr = IDirect3DDevice9_CreatePixelShader(device, ps_code, &ps); > + ok(SUCCEEDED(hr), "IDirect3DDevice9_CreatePixelShader failed, hr %#x. \n", hr); Your test must check is PS 2.0 shaders are supported. We already have a pixel shader >= 2.0 supported block in the START_TEST(visual) function, please call your test function inside it. (e.g. after dp2add_ps_test)

1 0

Re: [2/3] kernel32/heap: Fix some hacks in GlobalMemoryStatus().
by Dmitry Timoshkov 31 May '11

31 May '11

Adam Martinson <amartinson(a)codeweavers.com> wrote: > +/* Check the current process and all ancestors. Some apps run sub-processes that > + * have the IMAGE_FILE_LARGE_ADDRESS_AWARE flag set, but the parent process doesn't. > + * (eg, Dragon NaturallySpeaking 7 setup runs Install Shield 6). > + * If any don't have IMAGE_FILE_LARGE_ADDRESS_AWARE, return FALSE. */ How do the processes running in separate address spaces have anything to do with that? -- Dmitry.

2 1

Re: [1/3] kernel32/heap: Emulate Win9x if appropriate in GlobalMemoryStatusEx().
by Dmitry Timoshkov 31 May '11

31 May '11

Adam Martinson <amartinson(a)codeweavers.com> wrote: > + if (osver.dwMajorVersion >= 5) That's a wrong check for win9x. -- Dmitry.

2 1

Re: advapi: test and fix GetUserName() in case where buffer is too small
by Hans Leidekker 31 May '11

31 May '11

On Mon, 2011-05-30 at 21:13 -0700, Dan Kegel wrote: > @@ -91,7 +91,7 @@ GetUserNameW( LPWSTR lpszName, LPDWORD lpSize ) > > if (len > *lpSize) > { > - SetLastError(ERROR_MORE_DATA); > + SetLastError(ERROR_INSUFFICIENT_BUFFER); GetUserNameA also needs to be fixed. It sets ERROR_MORE_DATA when WideCharToMultiByte fails, which can simply be removed because that function will set ERROR_INSUFFICIENT_BUFFER itself if the buffer is too small. And there are at least two cases, in dlls/crypt32/protectdata.c and dlls/msi/package.c, where we depend on the wrong error.

3 4

Re: [PATCH 1/6] mshtml: Added support for accessing document elements by index
by Marvin 31 May '11

31 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=11331 Your paranoid android. === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found

1 0

Re: kernel32: Call Fls callback (try 2)
by Alexandre Julliard 31 May '11

31 May '11

André Hentschel <nerv(a)dawncrow.de> writes: > + if (ret && callback) callback(NtCurrentTeb()->FlsSlots[index]); > + /* FIXME: add equivalent of ThreadZeroTlsCell here */ > + if (NtCurrentTeb()->FlsSlots) NtCurrentTeb()->FlsSlots[index] = 0; It's not that easy... -- Alexandre Julliard julliard(a)winehq.org

1 0

bug in GetUserNameW error return values
by Kevin Hendricks 31 May '11

31 May '11

Hi, There is a small bug in the wine implementation of GetUserNameW (and the same fix is needed in GetUserNameA). From: dlls/advapi32/advapi.c starting at line 92 if (len > *lpSize) { SetLastError(ERROR_MORE_DATA); *lpSize = len; return FALSE; } It seems the actual GetUserNameW returns 122 not 234 which maps to ERROR_INSUFFICIENT_BUFFER and not ERROR_MORE_DATA This bug prevents the username from being properly read in all version of of Kindle for PC when run under wine. The code in question luckily ignores the improper error return value and simply replaces the username with the string "AlternateUserName" so Kindle For PC will actually work under wine but this actually changes how the DRM is created on the ebook as the Kindle DRM is tied to both the user name and the volume serial number, making it hard to post-process any ebook under wine. Please fix this in your next release. Thanks, Kevin

2 1

Re: [1/2] README: Update Linux requirements
by Michael Stefaniuc 30 May '11

30 May '11

Hello André, On 05/30/2011 08:09 PM, André Hentschel wrote: > now that it's official > --- > README | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/README b/README > index baa6ab3..51a080b 100644 > --- a/README > +++ b/README > @@ -41,7 +41,7 @@ support kernel threads may be supported in the future. > Linux info: > While Linux 2.2.x should still work and Linux 2.0.x may still work > (older 2.0.x versions had thread-related crashes), > - it's best to have a current kernel such as 2.4.x or 2.6.x. > + it's best to have a current kernel such as 2.4.x, 2.6.x or 3.0. Are you sure that a 2.4 Kernel is still good enough for modern Wine? And for the new Linux numbering: it is 3.x not 3.0 as the main change is to have only two digits for the Linux version as released by Linus; the third is reserved for the stable trees. bye michael

3 2

Tahoma Font License
by Mark Page 30 May '11

30 May '11

I am a bit confused by the Wine "tahoma" license: "Wine Tahoma Regular" ... GNU Lesser General Public License 2.1 It would be useful to add the font to the ClanLib SDK resources (ClanLib has a zlib style license) It is not clear how a font can be licensed using LGPL, since LGPL is based around software libraries. Ideally I feel it should have a creative commons license I believe Creative commons did not exist when that font was created (I initially posted this message to forum.winehq.org, and it was suggested that I should post here instead) Mark.

3 3

Re: [3/8] d3d8: Use D3DRESOURCETYPE -> WINED3DRESOURCETYPE enum conversion function instead of implicit conversion (clang)
by Stefan Dösinger 30 May '11

30 May '11

On Sunday 29 May 2011 09:46:06 Frédéric Delanoy wrote: > +static inline D3DRESOURCETYPE > d3dresourcetype_from_wined3dresourcetype(WINED3DRESOURCETYPE type) +{ > ... > + case WINED3DRTYPE_BUFFER: return D3DRTYPE_VERTEXBUFFER; > ... > +static inline WINED3DRESOURCETYPE > wined3dresourcetype_from_d3dresourcetype(D3DRESOURCETYPE type) +{ > + case D3DRTYPE_VERTEXBUFFER: return WINED3DRTYPE_BUFFER; > + case D3DRTYPE_INDEXBUFFER: return (WINED3DRESOURCETYPE) type; Those two cases are worth printing a FIXME. Just move the implementation to device.c (like d3dformat_from_wined3dformat) so you have a declared debug channel. In the long run the resource type conversion should go away in almost all places, and those places that still need it(like CheckDeviceFormat) have to do the conversion on their own. (Sorry that I didn't send that with the feedback for patch 7, it took me a while to get around to reading it)

2 2

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9
by Michael Mc Donnell 30 May '11

30 May '11

On Sat, May 28, 2011 at 10:08 PM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > On Saturday 28 May 2011 19:55:55 you wrote: > >> It was implemented by setting the vertex declaration to null when the >> declaration is invalid. That seems to match what happens on Windows, >> because if a program has set an invalid declaration and then calls >> GetDeclaration or DrawSubset it will fail with an access violation. >> Should Wine also fail with an access violation or should it be >> slightly more graceful and return E_FAIL instead (which my new patch >> does)? > Yes, I think returning E_FAIL is a good idea, but write a WARN if > CreateVertexDeclaration fails or when you catch a NULL vdecl. A WARN will not > be shown by default(unlike a FIXME), it is used when the app does something > fishy but you think you handled it correctly. > >> + if (FAILED(hr)) >> + new_vertex_declaration = NULL; >> + >> + /* Free old vertex declaration */ >> + if (This->vertex_declaration) >> + IDirect3DVertexDeclaration9_Release(This->vertex_declaration); > In this situation you can just release the old decl before calling > CreateVertexDeclaration and pass &This->vertex_declaration to CreateVdecl. > That simplified the code a bit. Don't forget to set This->vertex_declaration to > NULL in case of an error though Ok I've simplified the code. I've also inserted three WARNs. I've skipped a WARN when freeing the mesh because that works fine on Windows with an invalid declaration. >> + /* Set the position type to color instead of float3 (invalid > declaration) */ >> + hr = mesh->lpVtbl->UpdateSemantics(mesh, declaration_wrong_type_color); >> + todo_wine ok(hr == D3D_OK, "Test UpdateSematics wrong type color, " >> + "got %#x expected D3D_OK\n", hr); > Is this really invalid? I don't know it on top of my head, but in general > types and usage are independent, especially with shaders. I don't see a check > in d3d9 or wined3d for this case. You're right it isn't invalid. It doesn't crash, it just doesn't draw anything. I've change that comment and re-ordered the tests. > Beyond that I think the patches look OK. I'd recommend to send them to wine- > devel one more time and then next week to wine-patches. Henri is on Vacation > this week, and he's usually more picky than I am. I also hope some of the > people who regularly contribute to d3dx9 will have a look and comment. Ok, I've attached the newest version. I'll let the patches sit here for a week, and start working on the other functions in the mean time.

2 1

Re: crypt32: Add BCryptEnumAlgorithms stub.
by David Hedberg 30 May '11

30 May '11

On Mon, May 30, 2011 at 12:45, David Hedberg <dhedberg(a)codeweavers.com> wrote: > --- Sorry, the commit message should of course say bcrypt, not crypt32.

1 0

Re: [8/8] d3d8: Use D3DPRIMITIVETYPE -> WINED3DPRIMITIVETYPE enum conversion function instead of implicit conversion (clang)
by Stefan Dösinger 30 May '11

30 May '11

Am 29.05.2011 um 19:35 schrieb Frédéric Delanoy: > Please skip this patch; it needs adaptation to avoid rebasing/merge > conflicts due to changes to be done in patch " [7/8] d3d8: Use > D3DRENDERSTATETYPE -> WINED3DRENDERSTATETYPE enum conversion function > instead of implicit conversion (clang)." > > I'll resend both patches in a subsequent series. To avoid confusion it is better to resend them as [7/8] and [8/8] as long as the original patches aren't applied. Now I'd recommend you to wait until today's commit wave before resending anything else to see which patches are applied and resend the others.

2 2

NTDLL doesn't compile under Clang
by C.W. Betts 29 May '11

29 May '11

When compiling the NTDLL component of Wine, I get the following error: ../../../wine-git/./dlls/ntdll/large_int.c:267:13: error: unknown use of instruction mnemonic without a size suffix __asm__("div %4,%%eax" ^ <inline asm>:1:2: note: instantiated into assembly here div 12(%esp),%eax ^ I'm using Clang 2.0 from Xcode 4.0

4 3

Re: [PATCH] gdiplus: Convert and pass in 3 points, not 1 (Coverity)
by Vincent Povirk 29 May '11

29 May '11

Good catch. This sort of thing would have been very hard to track down in a real app. On Sun, May 29, 2011 at 4:53 PM, Marcus Meissner <marcus(a)jet.franken.de> wrote: > Hi, > > CID 1147 > We get 3 points, not 1 ... and also need to pass on 3 points. > > Ciao, Marcus > --- > dlls/gdiplus/matrix.c | 12 +++++++----- > 1 files changed, 7 insertions(+), 5 deletions(-) > > diff --git a/dlls/gdiplus/matrix.c b/dlls/gdiplus/matrix.c > index 1035cc2..acfe989 100644 > --- a/dlls/gdiplus/matrix.c > +++ b/dlls/gdiplus/matrix.c > @@ -105,7 +105,8 @@ GpStatus WINGDIPAPI GdipCreateMatrix3I(GDIPCONST GpRect *rect, GDIPCONST GpPoint > GpMatrix **matrix) > { > GpRectF rectF; > - GpPointF ptF; > + GpPointF ptF[3]; > + int i; > > TRACE("(%p, %p, %p)\n", rect, pt, matrix); > > @@ -114,10 +115,11 @@ GpStatus WINGDIPAPI GdipCreateMatrix3I(GDIPCONST GpRect *rect, GDIPCONST GpPoint > rectF.Width = (REAL)rect->Width; > rectF.Height = (REAL)rect->Height; > > - ptF.X = (REAL)pt->X; > - ptF.Y = (REAL)pt->Y; > - > - return GdipCreateMatrix3(&rectF, &ptF, matrix); > + for (i = 0; i < 3; i++) { > + ptF[i].X = (REAL)pt[i].X; > + ptF[i].Y = (REAL)pt[i].Y; > + } > + return GdipCreateMatrix3(&rectF, ptF, matrix); > } > > GpStatus WINGDIPAPI GdipCloneMatrix(GpMatrix *matrix, GpMatrix **clone) > -- > 1.7.3.4 > > > >

1 0

Re: ddraw: Add tests for SetCooperativeLevel
by Marvin 29 May '11

29 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=11295 Your paranoid android. === W7PROX64 (64 bit ddrawmodes) === Timeout

1 0

Re: [7/8] d3d8: Use D3DRENDERSTATETYPE -> WINED3DRENDERSTATETYPE enum conversion function instead of implicit conversion (clang)
by Stefan Dösinger 29 May '11

29 May '11

On Sunday 29 May 2011 09:46:10 Frédéric Delanoy wrote: > default: > - hr = wined3d_device_set_render_state(This->wined3d_device, > State, Value); > + hr = > wined3d_device_set_render_state(This->wined3d_device, + > wined3drenderstatetype_from_d3drenderstatetype(State), Value); } > wined3d_mutex_unlock(); d3d8's SetRenderState and GetRenderState already have a switch-case statement because ZBIAS doesn't exist in wined3d, so strictly speaking a direct cast is not possible. You cannot move the switch-case from SetRenderState to the state conversion function because the meaning of the Value parameter is different between D3DRS_ZBIAS and WINED3DRS_DEPTHBIAS. So I'd suggest to put the cast into the default cases of d3ddevice8::SetRenderState and d3device8::GetRenderState In d3d9 you can cast between the d3d9 and wined3d render state types.

1 0

Re: Support for D3DQUERY_TIMESTAMP* queries...
by Adam Martinson 27 May '11

27 May '11

On 05/27/2011 01:23 PM, Adam Martinson wrote: > On 05/25/2011 11:31 AM, Stefan Dösinger wrote: >> On Wednesday 25 May 2011 18:23:39 Adam Martinson wrote: >>> Do you think that needs to be done before I submit those or is that >>> something that can come later? >> I'd prefer to have this checked before submitting. It shouldn't take >> long. >> Just write a test app that grabs the timestamp in a loop and prints >> it to >> stdout and see what kind of values it writes. If it does wrap around >> in a >> reasonable amount of time(e.g. a few hours) write a test that waits >> for the >> wraparound to approach, starts a disjoint query, waits until after the >> wraparound, ends the disjoint query and prints its result. > Ran a test for 10 mins or so, on my card it behaves like the > GL_ARB_timer_query version, except the frequency is 10ns instead of > 1ns... so it doesn't look like it would wrap around in my lifetime. I > can include that test with an environment variable to set the number > of iterations if you like. Are these ok to submit now?

1 0

Re: winealsa: Have TRACE_ON() use the same channel as TRACE (alsa).
by Alexandre Julliard 27 May '11

27 May '11

<Joerg-Cyril.Hoehle(a)t-systems.com> writes: > alsa.c:ALSA_TraceParameters writes to channel "alsa", therefore you may consider > that it makes sense that TRACE_ON dispatches on that same channel and apply this patch. > Otherwise you need to listen to 2 channels to get output, e.g. +alsa,+wave or +dsalsa. > > Back when everything was in audio.c, "wave" was the only channel used. That would probably be a better choice. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/2] mshtml: Added IHTMLScreen::get_availHeight implementation
by Alexandre Julliard 27 May '11

27 May '11

Jacek Caban <jacek(a)codeweavers.com> writes: > @@ -186,8 +186,15 @@ static HRESULT WINAPI HTMLScreen_get_updateInterval(IHTMLScreen *iface, LONG *p) > static HRESULT WINAPI HTMLScreen_get_availHeight(IHTMLScreen *iface, LONG *p) > { > HTMLScreen *This = impl_from_IHTMLScreen(iface); > - FIXME("(%p)->(%p)\n", This, p); > - return E_NOTIMPL; > + RECT work_area; > + > + TRACE("(%p)->(%p)\n", This, p); > + > + if(!SystemParametersInfoW(SPI_GETWORKAREA, 0, &work_area, 0)) > + return E_FAIL; > + > + *p = work_area.bottom; You probably want work_area.bottom - work_area.top. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 5/5] msvcp90: Added _Mutex class implementation
by Nikolay Sivov 27 May '11

27 May '11

On Fri, May 27, 2011 at 4:24 PM, Piotr Caban <piotr(a)codeweavers.com> wrote: > --- > dlls/msvcp100/msvcp100.spec | 32 ++++++++++++++++---------------- > dlls/msvcp71/msvcp71.spec | 16 ++++++++-------- > dlls/msvcp80/msvcp80.spec | 32 ++++++++++++++++---------------- > dlls/msvcp90/Makefile.in | 1 + > dlls/msvcp90/msvcp90.spec | 32 ++++++++++++++++---------------- > 5 files changed, 57 insertions(+), 56 deletions(-) > There's no misc.c in a patch.

1 0

Re: [3/3]usp10: add Devanagari script
by Marvin 26 May '11

26 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=11215 Your paranoid android. === WNT4WSSP6 (32 bit usp10) === Timeout

1 0

Re: [PATCH 5/7] comdlg32: Implement support for custom control subitems.
by Marvin 26 May '11

26 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=11214 Your paranoid android. === WVISTAADM (32 bit itemdlg) === itemdlg.c:1284: Test failed: Failed to find item. itemdlg.c:1287: Test failed: Got L"" itemdlg.c:1289: Test failed: Failed to find item. itemdlg.c:1292: Test failed: Got L"" itemdlg.c:1294: Test failed: Failed to find item. itemdlg.c:1297: Test failed: Got L"" itemdlg.c:1300: Test failed: Got L"" === W2K8SE (32 bit itemdlg) === itemdlg.c:1284: Test failed: Failed to find item. itemdlg.c:1287: Test failed: Got L"" itemdlg.c:1289: Test failed: Failed to find item. itemdlg.c:1292: Test failed: Got L"" itemdlg.c:1294: Test failed: Failed to find item. itemdlg.c:1297: Test failed: Got L"" itemdlg.c:1300: Test failed: Got L""

1 0

Re: [PATCH 4/7] comdlg32: Implement some functions for modifying custom controls.
by Marvin 26 May '11

26 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=11212 Your paranoid android. === WVISTAADM (32 bit itemdlg) === itemdlg.c:1284: Test failed: Failed to find item. itemdlg.c:1287: Test failed: Got L"" itemdlg.c:1289: Test failed: Failed to find item. itemdlg.c:1292: Test failed: Got L"" === W2K8SE (32 bit itemdlg) === itemdlg.c:1284: Test failed: Failed to find item. itemdlg.c:1287: Test failed: Got L"" itemdlg.c:1289: Test failed: Failed to find item. itemdlg.c:1292: Test failed: Got L""

1 0

Re: [PATCH 1/7] comdlg32: Add a container for custom controls.
by Marvin 26 May '11

26 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=11209 Your paranoid android. === W7PROX64 (32 bit itemdlg) === itemdlg: unhandled exception c0000005 at 75B94C19

1 0

Re: winscard: Implement some functions of winscard.dll
by Alexandre Julliard 26 May '11

26 May '11

Sergey Stepanov <serg_admin(a)rambler.ru> writes: > @@ -33,6 +35,24 @@ const SCARD_IO_REQUEST g_rgSCardT0Pci = { SCARD_PROTOCOL_T0, 8 }; > const SCARD_IO_REQUEST g_rgSCardT1Pci = { SCARD_PROTOCOL_T1, 8 }; > const SCARD_IO_REQUEST g_rgSCardRawPci = { SCARD_PROTOCOL_RAW, 8 }; > > +#define MAKE_FUNCPTR(f) static typeof(f) * p##f = NULL > +MAKE_FUNCPTR(SCardEstablishContext); > +MAKE_FUNCPTR(SCardReleaseContext); > +#undef MAKE_FUNCPTR This can't work. You need to use the Unix headers (with appropriate configure checks), declare pointers to the Unix functions, and convert any types that need it before calling them. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: USB Device Support
by Juan Lang 26 May '11

26 May '11

Hi Scott, > I've been working through my Dell Inspiron 1545 with Linux/Ubuntu > 10.04 LTS experiences with ongoing reviews. I'd like to provide some help > to others considering making the transition from Windows to Linux. I'm > trying to get my Garmin GPS to talk to its Mapsource (running under WINE) > application through a USB port. This allows tracks to be read from and > written to the GPS itself. So far no luck. Can someone there please > provide some advice? If this functionality isn't available yet then so be > it. The Mapsource application runs fine it's just the USB communication > that isn't working. Many thanks. Such questions are better addressed to the Wine forum. Thanks, --Juan

1 0

kernel32/heap: Fix GlobalMemoryStatus()/GlobalMemoryStatusEx()
by Adam Martinson 26 May '11

26 May '11

There are a bunch of old apps which are known to be buggy with this, the ones I tested were: Dragon NaturallySpeaking 7 Adobe Illustrator 8 Need for Speed 2 SE (demo) Adobe Photoshop 4 Photoshop 4 has a hack in GlobalMemoryStatus() that's causing problems for some of the others. The 2nd patch removes that hack, and breaks it the same way it's broken on Windows. Normally I wouldn't advocate breaking apps, but in this case I think it's appropriate. The 3rd patch gives a workaround for Photoshop 4 that seams like the appropriate solution to me, as it mirrors the workaround for Windows. Any feedback would be appreciated.

1 0

Re: kernel32/toolhelp: PROCESSENTRY32::szExeFile is the full path in Win9x.
by Saulius Krasuckas 26 May '11

26 May '11

* On Wed, 25 May 2011, Adam Martinson wrote: > > Dragon NaturallySpeaking 7 expects this in Win98 mode. > --- > dlls/kernel32/tests/toolhelp.c | 19 +++++++++++++++- > dlls/kernel32/toolhelp.c | 48 +++++++++++++++++++++++++++++---------- > 2 files changed, 53 insertions(+), 14 deletions(-) I am not sure you do it right (now that new testing strategy is taken): * On Tue, 30 Nov 2010, Alexandre Julliard wrote: > > The value of running tests on Win9x these days is certainly > questionable. We don't try to emulate the Win9x behavior anyway, except > in a very few cases (which most likely don't have tests...) so it only > serves to document historical behavior that nobody cares about any > longer. WRT doesn't test win9x any longer, so what's the point of putting such check in the test? > --- a/dlls/kernel32/tests/toolhelp.c > +++ b/dlls/kernel32/tests/toolhelp.c ... > @@ -106,6 +108,10 @@ static void test_process(DWORD curr_pid, DWORD sub_pcs_pid) > unsigned found = 0; > int num = 0; > int childpos = -1; > + OSVERSIONINFO osver; > + > + osver.dwOSVersionInfoSize = sizeof(osver); > + pGetVersionEx(&osver); > > hSnapshot = pCreateToolhelp32Snapshot( TH32CS_SNAPPROCESS, 0 ); > ok(hSnapshot != NULL, "Cannot create snapshot\n"); > @@ -116,10 +122,15 @@ static void test_process(DWORD curr_pid, DWORD sub_pcs_pid) > { > do > { > + TCHAR* bslash = strchr(pe.szExeFile, '\\'); > if (pe.th32ProcessID == curr_pid) found++; > if (pe.th32ProcessID == sub_pcs_pid) { childpos = num; found++; } > trace("PID=%x %s\n", pe.th32ProcessID, pe.szExeFile); > num++; > + if (osver.dwMajorVersion < 5) > + ok(bslash != NULL, "szExeFile is not a full path: %s\n", pe.szExeFile); > + else > + ok(bslash == NULL, "szExeFile is a full path: %s\n", pe.szExeFile); > } while (pProcess32Next( hSnapshot, &pe )); > } > ok(found == 2, "couldn't find self and/or sub-process in process list\n"); Now such check is pointless, IMHO. Here goes question to Alexandre: what about (testing in) such cases? S.

2 1

Re: ole32/ole2: Don't call IDropTarget::QueryInterface() in RegisterDragDrop(). [whitespace fixed]
by Huw Davies 26 May '11

26 May '11

> +static IDropTarget* WrapDropTarget(IDropTarget* inner) > +{ > + DropTargetWrapper* This = HeapAlloc(GetProcessHeap(), 0, sizeof(*This)); > + > + if (This) > + { > + This->iface = (IDropTarget){ &DropTargetWrapper_VTbl }; This->iface.lpVtbl = &DropTargetWrapper_VTbl; > - hr = CoMarshalInterface(stream, &IID_IDropTarget, unk, MSHCTX_LOCAL, NULL, MSHLFLAGS_TABLESTRONG); > - IUnknown_Release(unk); > + hr = CoMarshalInterface(stream, &IID_IDropTarget, (IUnknown*)wrapper, MSHCTX_LOCAL, NULL, MSHLFLAGS_TABLESTRONG); > > if(SUCCEEDED(hr)) > { > hr = create_map_from_stream(stream, &map); > if(SUCCEEDED(hr)) > { > - IDropTarget_AddRef(pDropTarget); > SetPropW(hwnd, prop_oledroptarget, pDropTarget); You probably want to set the window prop to the wrapper here. Either way you still need the AddRef (on the wrapper if you set that), it gets released in RevokeDragDrop. Huw.

2 6

extern char **environ and msvc
by Stefan Dösinger 25 May '11

25 May '11

Hi, This is one of the last remaining hacks needed to compile the d3d parts of Wine with Visual Studio. Our definition of **environ is conflicting with one already in the Windows SDK headers: 1>..\..\wine\libs\wine\loader.c(54): warning C4273: '_environ': Inkonsistente DLL-Bindung. 1> C:\Program Files\Microsoft Visual Studio 10.0\VC\include\stdlib.h(299): Siehe vorherige Definition von '_environ' I'm sorry for the German, I don't know how to change this. Google finds only other clueless people. Either way it says something like "Inconsistent DLL binding" The line in stdlib.h declares _environ as _CRTIMP extern char ** _environ; /* pointer to environment table */ The compiler just writes a warning, but afterwards linking fails: 1>loader.obj : error LNK2001: Nicht aufgelöstes externes Symbol "__environ". The linker complains about an "unresolved external symbol __environ". Removing our declaration of environ fixes the warning, link error and libwine seems to work OK. I don't know what the proper fix is, please advise. Maybe this code shouldn't be compiled at all? I don't think I need the loader code on Windows. Stefan

2 2

Re: [2/2] user32: Add message test for hotkeys.
by Marvin 25 May '11

25 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=11184 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

1 0

Re: [1/2] user32: Add test for RegisterHotKey/UnregisterHotKey.
by Marvin 25 May '11

25 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=11183 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

1 0

re: Hans Leidekker : msi: Support rollback of failed uninstalls.
by Dan Kegel 25 May '11

25 May '11

wow, msi has really come a long way!

2 1

Re: USB Device Support
by Scott 25 May '11

25 May '11

Hi, I've been working through my Dell Inspiron 1545 with Linux/Ubuntu 10.04 LTS experiences with ongoing reviews. I'd like to provide some help to others considering making the transition from Windows to Linux. I'm trying to get my Garmin GPS to talk to its Mapsource (running under WINE) application through a USB port. This allows tracks to be read from and written to the GPS itself. So far no luck. Can someone there please provide some advice? If this functionality isn't available yet then so be it. The Mapsource application runs fine it's just the USB communication that isn't working. Many thanks. Best - Scott

1 0

Re: [PATCH 1/2] ddraw: COM cleanup for IDirectDrawSurface3 iface
by Stefan Dösinger 25 May '11

25 May '11

On Wednesday 25 May 2011 00:39:46 Ričardas Barkauskas wrote: > My first try for COM cleanup. Please donėt be too harsh :) > If this is too large for one patch, please suggest how to split it. > > This is not automatic clean up so I don't really expect it to be good on > first try. I can't find anything wrong with it on first sight, but I don't really know how to manually review a patch that large with many repetitions. I guess I could print them on a *lot* of paper and read them at the pool or something like that. I don't see an easy way to split them up either :-/ . I guess we'll have to trust Puk's script verification. Just one thing: in unsafe_impl_from_IDirectDrawSurface*: > + if (iface->lpVtbl != &ddraw_surface7_vtbl) return NULL; I don't think apps can pass in their own ddraw object implementations. I've never seen an app that does that or any document that suggests this is possible and achives something. So I'd recommend to add a FIXME() or ERR() to that case. An ERR because the most likely cause for such a behavior is that our own ddrawex.dll screws up. This is the only other place where we have a IDirectDrawSurface* implementation. Or we could just remove the check and see if we ever crash because trying to read surface implementation fields returns odd values.

2 1

re: [2/5] d3dx9: Generate effect instances from materials for mesh loading.
by Dan Kegel 25 May '11

25 May '11

+ static const char diffuse_paramname[] = "Diffuse"; + static const char power_paramname[] = "Power"; + static const char specular_paramname[] = "Specular"; + static const char emissive_paramname[] = "Emissive"; + static const char ambient_paramname[] = "Ambient"; + static const DWORD basic_paramname_sizes = sizeof(diffuse_paramname) + + sizeof(power_paramname) + + sizeof(specular_paramname) + + sizeof(emissive_paramname) + + sizeof(ambient_paramname); ... It might be more readable to define material_effects[] up next to where those paramnames are defined, since it kind of clutters the loop, and it's nicer to keep the whole table definition together. (Also, at least conceptually, basic_paramname_sizes could be computed by a loop over the table. Then you wouldn't need those five _paramname variables, you could just use string constants. But if the strlen's would be expensive, I guess that's ok.) A comment or two about the layout of the output buffer might be nice. Can materials and material_ptr be const pointers? - Dan

2 2

Re: [PATCH] version: mark internal function with hidden visibility
by Alexandre Julliard 25 May '11

25 May '11

Marcus Meissner <meissner(a)suse.de> writes: > @@ -348,7 +348,7 @@ static BOOL find_pe_resource( HFILE lzfd, DWORD *resLen, DWORD *resOff ) > /*********************************************************************** > * find_version_resource [internal] > */ > -DWORD find_version_resource( HFILE lzfd, DWORD *reslen, DWORD *offset ) > +DECLSPEC_HIDDEN DWORD find_version_resource( HFILE lzfd, DWORD *reslen, DWORD *offset ) > { This should be in a header. It's not very useful to make it hidden if callers are not aware of the fact. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/5] wined3d: Don't check the FBO status if FIXMEs are off
by Henri Verbeet 25 May '11

25 May '11

On 24 May 2011 22:37, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > I put the fixme checks outside context_check_fbo_status because the ENTER_GL() / LEAVE_GL() > locking is more expensive than the FBO validation itself. Moving the locking into the function I'm not sure that's really worth it. If the GL lock is really such a concern, you should probably change the calls in context.c to already be under the GL lock anyway. You can easily change context_apply_draw_buffers() for example to require locking by the caller.

2 1

Re: usp10/tests: Make enumFontProc() static.
by Marvin 25 May '11

25 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=11170 Your paranoid android. === WNT4WSSP6 (32 bit usp10) === Timeout

1 0

Re: [PATCH 1/2] ddraw: COM cleanup for IDirectDrawSurface3 iface
by Michael Stefaniuc 25 May '11

25 May '11

Hello Ričardas! Ričardas Barkauskas wrote: > My first try for COM cleanup. Please donėt be too harsh :) > If this is too large for one patch, please suggest how to split it. > > This is not automatic clean up so I don't really expect it to be good on > first try. Heh! I have attached the raw diff generated by my coccinelle script. Looking at the interdiff between the two patches it looks like you caught everything. And the BADBADBAD() (*) from the generated patch are replaced with unsafe_impl_from_IDirectDrawSurface3(), very good. If you want to do more COM cleanup I can give you the raw generated patches to save you some time. bye michael P.S.: (*) My script validates that impl_from_IFace() is called only from methods of that IFace. All other impl_from_IFace() calls are replaced with BADBADBAD().

1 1

Re: cmd: Don't read past end of thisVar in WCMD_expand_envvar (valgrind)
by Marvin 25 May '11

25 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=11166 Your paranoid android. === WNT4WSSP6 (32 bit) === batch.c:223: Test failed: unexpected char 0x54 position 0 in line 86 (got 'This Line Is Never Reached. If this runs, it is a bug.', wanted '65536') batch.c:223: Test failed: unexpected char 0x31 position 0 in line 87 (got '1', wanted 'errorlevel just right, good') batch.c:223: Test failed: unexpected char 0x65 position 0 in line 88 (got 'errorlevel too low, bad', wanted 'abc0def') batch.c:223: Test failed: unexpected char 0x54 position 0 in line 89 (got 'This Line Is Never Reached. If this runs, it is a bug.', wanted 'errorlevel zero, good') batch.c:223: Test failed: unexpected char 0x61 position 0 in line 90 (got 'abc1def', wanted '7 should be 7') batch.c:223: Test failed: unexpected char 0x65 position 0 in line 91 (got 'errorlevel nonzero, bad', wanted '7 should still be 7') batch.c:223: Test failed: unexpected char 0x37 position 0 in line 92 (got '7 should be 7', wanted '3 should be 3 now') batch.c:223: Test failed: unexpected char 0x54 position 0 in line 93 (got 'This Line Is Never Reached. If this runs, it is a bug.', wanted '-----------Testing GOTO-----------') batch.c:223: Test failed: unexpected char 0x37 position 0 in line 94 (got '7 should still be 7', wanted 'goto with no leading space worked') batch.c:223: Test failed: unexpected char 0x30 position 0 in line 95 (got '0 should be 3 now', wanted 'goto with a leading space worked') batch.c:223: Test failed: unexpected char 0x2d position 0 in line 96 (got '-----------Testing GOTO-----------', wanted 'goto with a leading tab worked') batch.c:223: Test failed: unexpected char 0x67 position 0 in line 97 (got 'goto with no leading space worked', wanted 'goto with a following space worked') batch.c:223: Test failed: unexpected char 0x67 position 0 in line 98 (got 'goto with a leading space worked', wanted '-----------Done, jumping to EOF-----------') batch.c:235: Test failed: too long output, got additional goto with a leading tab worked === W2KPROSP4 (32 bit) === batch.c:223: Test failed: unexpected char 0x30 position 0 in line 92 (got '0 should be 3 now', wanted '3 should be 3 now') === WXPPROSP3 (32 bit) === batch.c:223: Test failed: unexpected char 0x30 position 0 in line 92 (got '0 should be 3 now', wanted '3 should be 3 now') === W2K3R2SESP2 (32 bit) === batch.c:223: Test failed: unexpected char 0x30 position 0 in line 92 (got '0 should be 3 now', wanted '3 should be 3 now') === WVISTAADM (32 bit) === batch.c:223: Test failed: unexpected char 0x30 position 0 in line 92 (got '0 should be 3 now', wanted '3 should be 3 now') === W2K8SE (32 bit) === batch.c:223: Test failed: unexpected char 0x30 position 0 in line 92 (got '0 should be 3 now', wanted '3 should be 3 now') === W7PRO (32 bit) === batch.c:223: Test failed: unexpected char 0x30 position 0 in line 92 (got '0 should be 3 now', wanted '3 should be 3 now') === W7PROX64 (32 bit) === batch.c:223: Test failed: unexpected char 0x30 position 0 in line 92 (got '0 should be 3 now', wanted '3 should be 3 now') === W7PROX64 (64 bit) === batch.c:223: Test failed: unexpected char 0x30 position 0 in line 92 (got '0 should be 3 now', wanted '3 should be 3 now')

2 1

windows are incompletely drawn: bisected to commit 7864ade5a8306c0078e16ae6d7e40bdece29395b
by Wolfgang Walter 25 May '11

25 May '11

An application we use shows incompletely painted windows with 1.3.19. I bisected it to commit 7864ade5a8306c0078e16ae6d7e40bdece29395b is the first bad commit commit 7864ade5a8306c0078e16ae6d7e40bdece29395b Author: Dmitry Timoshkov <dmitry(a)codeweavers.com> Date: Tue Sep 14 14:24:11 2010 +0900 winex11.drv: Avoid copying invalid window bits. I reverted it in 1.3.19 and that fixed indeed the problem. The wrongly painted windows are maximized windows within a MDI window: if there are serveral such windows opened and one switches between them parts of the newly active window is not painted and the content of the old one is still displayed. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts

2 1

Re: [2/5] d3dx9: Generate effect instances from materials for mesh loading.
by Matteo Bruni 25 May '11

25 May '11

2011/5/24 Dylan Smith <dylan.ah.smith(a)gmail.com>: > --- > dlls/d3dx9_36/mesh.c | 117 +++++++++++++++++++++++++++++++++++++++++++++++-- > 1 files changed, 112 insertions(+), 5 deletions(-) > > diff --git a/dlls/d3dx9_36/mesh.c b/dlls/d3dx9_36/mesh.c > index fa32797..20b3262 100644 > --- a/dlls/d3dx9_36/mesh.c > +++ b/dlls/d3dx9_36/mesh.c ... > + strcpy(defaults->pParamName, diffuse_paramname); > + defaults->pValue = defaults->pParamName + sizeof(diffuse_paramname); > + defaults->Type = D3DXEDT_FLOATS; > + defaults->NumBytes = sizeof(D3DCOLORVALUE); > + memcpy(defaults->pValue, &material_ptr->MatD3D.Diffuse, sizeof(D3DCOLORVALUE)); > + (defaults + 1)->pParamName = (LPSTR)((D3DCOLORVALUE*)defaults->pValue + 1); > + defaults++; > + > + strcpy(defaults->pParamName, power_paramname); > + defaults->pValue = defaults->pParamName + sizeof(power_paramname); > + defaults->Type = D3DXEDT_FLOATS; > + defaults->NumBytes = sizeof(FLOAT); > + *(FLOAT*)defaults->pValue = material_ptr->MatD3D.Power; > + (defaults + 1)->pParamName = (LPSTR)((FLOAT*)defaults->pValue + 1); > + defaults++; ... A nitpick maybe, but I think you could avoid to repeat the same code for each parameter by means of a loop driven by a table. It may be worth a try if it doesn't become more cumbersome than the current approach.

1 0

Re: [2/2]usp10/test: add Tibetan shaping test
by Marvin 24 May '11

24 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=11159 Your paranoid android. === WNT4WSSP6 (32 bit usp10) === Timeout

1 0

Re: usp10/test: make sure to only trace on _test_shape_ok number of glyphs if font is not valid
by Marvin 24 May '11

24 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=11158 Your paranoid android. === WNT4WSSP6 (32 bit usp10) === Timeout

1 0

Re: [PATCH 4/5] wined3d: Mask out writes to unused render targets.
by Stefan Dösinger 24 May '11

24 May '11

On Tuesday 24 May 2011 21:18:53 Henri Verbeet wrote: > @@ -1999,19 +1999,22 @@ static void context_apply_draw_buffers(struct > wined3d_context *context, UINT rt_ if > (wined3d_settings.offscreen_rendering_mode == ORM_FBO) { > const struct wined3d_gl_info *gl_info = context->gl_info; > - unsigned int i; > + unsigned int i = 0; > > - for (i = 0; i < rt_count; ++i) > + while (rt_mask) > { > if (rts[i] && rts[i]->resource.format->id != > WINED3DFMT_NULL) context->draw_buffers[i] = GL_COLOR_ATTACHMENT0 + i; > else > context->draw_buffers[i] = GL_NONE; > + > + rt_mask >>= 1; > + ++i; > } Shouldn't you also check if the lowest bit of rt_mask? Otherwise you'll miss situations where oC0 is written, oC1 isn't and oC2 is written. context->draw_buffer_dirty also has to be dirtified somewhere when the pixel shader is changed, their rt masks are different and a target is bound to one of the changed indices.

1 0

Re: [PATCH] wined3d: Mark wined3d_pixel_format with hidden visibility
by Henri Verbeet 24 May '11

24 May '11

On 13 May 2011 18:27, Marcus Meissner <meissner(a)suse.de> wrote: > @@ -1273,7 +1273,7 @@ struct wined3d_pixel_format > BOOL doubleBuffer; > int auxBuffers; > int numSamples; > -} wined3d_pixel_format; > +} wined3d_pixel_format DECLSPEC_HIDDEN; > No, that's wrong. It's not supposed to be a variable at all, it's a leftover from the typedef.

1 0

Re: [8/8]usp10/test: add Lao shaping test
by Marvin 24 May '11

24 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=11140 Your paranoid android. === WNT4WSSP6 (32 bit usp10) === Timeout

1 0

Re: [7/8]usp10/test: add Phags-pa shaping test
by Marvin 24 May '11

24 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=11139 Your paranoid android. === WNT4WSSP6 (32 bit usp10) === Timeout

1 0

Re: [6/8]usp10/test: add Thaana shaping test
by Marvin 24 May '11

24 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=11138 Your paranoid android. === WNT4WSSP6 (32 bit usp10) === Timeout

1 0

Re: [5/8]usp10/tests: add Syriac shaping test
by Marvin 24 May '11

24 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=11137 Your paranoid android. === WNT4WSSP6 (32 bit usp10) === Timeout

1 0

Re: [4/8]usp10: add Thai shaping test
by Marvin 24 May '11

24 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=11136 Your paranoid android. === WNT4WSSP6 (32 bit usp10) === Timeout

1 0

Re: [3/8]usp10: add Arabic Shaping Test
by Marvin 24 May '11

24 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=11135 Your paranoid android. === WNT4WSSP6 (32 bit usp10) === Timeout

1 0

Re: [2/8]usp10: add Hebrew shaping test
by Marvin 24 May '11

24 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=11134 Your paranoid android. === WNT4WSSP6 (32 bit usp10) === Timeout

1 0

Re: [1/8]usp10/tests: update test_ScriptShapeOpenType framework to shape in a given font
by Marvin 24 May '11

24 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=11133 Your paranoid android. === WNT4WSSP6 (32 bit usp10) === usp10.c:1733: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 73 usp10.c:1699: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1711: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 87 usp10.c:1712: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 71 usp10.c:1720: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 87 usp10.c:1721: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 88 usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 87 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 87 usp10.c:1749: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 86 === W2KPROSP4 (32 bit usp10) === usp10.c:1733: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 67 usp10.c:1699: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1711: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 81 usp10.c:1712: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 65 usp10.c:1720: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 81 usp10.c:1721: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 82 usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 81 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 81 usp10.c:1749: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 80 === WXPPROSP3 (32 bit usp10) === usp10.c:1733: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 67 usp10.c:1699: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1711: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 81 usp10.c:1712: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 65 usp10.c:1720: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 81 usp10.c:1721: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 82 usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 81 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 81 usp10.c:1749: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 80 === W2K3R2SESP2 (32 bit usp10) === usp10.c:1733: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 67 usp10.c:1699: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1711: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 81 usp10.c:1712: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 65 usp10.c:1720: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 81 usp10.c:1721: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 82 usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 81 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 81 usp10.c:1749: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 80 === WVISTAADM (32 bit usp10) === usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 4 not 6 for X = 49 usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 5 not 7 for X = 75 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 3 not 5 for X = 75 usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 6 not 4 for X = 75 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 4 not 6 for X = 75 usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 7 not 5 for X = 49 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 5 not 3 for X = 49 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 6 not 4 for X = 88 === W2K8SE (32 bit usp10) === usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 4 not 6 for X = 49 usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 5 not 7 for X = 75 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 3 not 5 for X = 75 usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 6 not 4 for X = 75 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 4 not 6 for X = 75 usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 7 not 5 for X = 49 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 5 not 3 for X = 49 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 6 not 4 for X = 88 === W7PRO (32 bit usp10) === usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 4 not 6 for X = 49 usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 5 not 7 for X = 75 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 3 not 5 for X = 75 usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 6 not 4 for X = 75 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 4 not 6 for X = 75 usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 7 not 5 for X = 49 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 5 not 3 for X = 49 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 6 not 4 for X = 88 === W7PROX64 (32 bit usp10) === usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 4 not 6 for X = 49 usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 5 not 7 for X = 75 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 3 not 5 for X = 75 usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 6 not 4 for X = 75 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 4 not 6 for X = 75 usp10.c:1731: Test failed: ScriptStringXtoCP should return Ch = 7 not 5 for X = 49 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 5 not 3 for X = 49 usp10.c:1747: Test failed: ScriptStringXtoCP should return Ch = 6 not 4 for X = 88

1 0

Re: [11/15]usp10/tests: update test_ScriptShapeOpenType framework to shape in a given font
by Alexandre Julliard 24 May '11

24 May '11

Aric Stewart <aric(a)codeweavers.com> writes: > @@ -297,9 +297,13 @@ static void test_ScriptItemize( void ) > test_items_ok(test10,4,&Control,&State,1,t101,FALSE,0); > } > > -static inline void _test_shape_ok(HDC hdc, LPCWSTR string, DWORD cchString, > - SCRIPT_CONTROL *Control, SCRIPT_STATE *State, > - DWORD item, DWORD nGlyphs, > +#define shape_cond_ok(a,b,c...) if (a>0) {winetest_ok(b,c);} else if(!b) {winetest_trace(c);} > + > +#define shape_cond_skip(a,b...) if (a>0) {winetest_win_skip(b);} else {winetest_trace(b);} You can't do that. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH] winealsa.drv: Implement device enumeration
by Alexandre Julliard 24 May '11

24 May '11

Andrew Eikum <aeikum(a)codeweavers.com> writes: > --- > dlls/winealsa.drv/mmdevdrv.c | 113 > +++++++++++++++++++++++++++++++++++------- > 1 files changed, 94 insertions(+), 19 deletions(-) It doesn't work here (and I didn't even plug in my USB headset ;-) ../../../tools/runtest -q -P wine -M mmdevapi.dll -T ../../.. -p mmdevapi_test.exe.so capture.c && touch capture.ok ALSA lib ../../src/confmisc.c:768:(parse_card) cannot find card '0' ALSA lib ../../src/conf.c:4170:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory ALSA lib ../../src/confmisc.c:392:(snd_func_concat) error evaluating strings ALSA lib ../../src/conf.c:4170:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory ALSA lib ../../src/confmisc.c:1251:(snd_func_refer) error evaluating name ALSA lib ../../src/conf.c:4170:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory ALSA lib ../../src/conf.c:4649:(snd_config_expand) Evaluate error: No such file or directory ALSA lib ../../../src/pcm/pcm.c:2190:(snd_pcm_open_noupdate) Unknown PCM front [many more of the same...] ALSA lib ../../src/confmisc.c:768:(parse_card) cannot find card '0' ALSA lib ../../src/conf.c:4170:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory ALSA lib ../../src/confmisc.c:392:(snd_func_concat) error evaluating strings ALSA lib ../../src/conf.c:4170:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory ALSA lib ../../src/confmisc.c:1251:(snd_func_refer) error evaluating name ALSA lib ../../src/conf.c:4170:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory ALSA lib ../../src/conf.c:4649:(snd_config_expand) Evaluate error: No such file or directory ALSA lib ../../../src/pcm/pcm.c:2190:(snd_pcm_open_noupdate) Unknown PCM iec958 capture.c:158: Test failed: Activation failed with 80004005 ALSA lib ../../src/confmisc.c:768:(parse_card) cannot find card '0' ALSA lib ../../src/conf.c:4170:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory ALSA lib ../../src/confmisc.c:392:(snd_func_concat) error evaluating strings ALSA lib ../../src/conf.c:4170:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory ALSA lib ../../src/confmisc.c:1251:(snd_func_refer) error evaluating name ALSA lib ../../src/conf.c:4170:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory ALSA lib ../../src/conf.c:4649:(snd_config_expand) Evaluate error: No such file or directory ALSA lib ../../../src/pcm/pcm.c:2190:(snd_pcm_open_noupdate) Unknown PCM iec958 capture.c:323: Test failed: Activation failed with 80004005 ALSA lib ../../src/confmisc.c:768:(parse_card) cannot find card '0' ALSA lib ../../src/conf.c:4170:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory ALSA lib ../../src/confmisc.c:392:(snd_func_concat) error evaluating strings ALSA lib ../../src/conf.c:4170:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory ALSA lib ../../src/confmisc.c:1251:(snd_func_refer) error evaluating name ALSA lib ../../src/conf.c:4170:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory ALSA lib ../../src/conf.c:4649:(snd_config_expand) Evaluate error: No such file or directory ALSA lib ../../../src/pcm/pcm.c:2190:(snd_pcm_open_noupdate) Unknown PCM iec958 capture.c:420: Test failed: Activation failed with 80004005 ALSA lib ../../src/confmisc.c:768:(parse_card) cannot find card '0' ALSA lib ../../src/conf.c:4170:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory ALSA lib ../../src/confmisc.c:392:(snd_func_concat) error evaluating strings ALSA lib ../../src/conf.c:4170:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory ALSA lib ../../src/confmisc.c:1251:(snd_func_refer) error evaluating name ALSA lib ../../src/conf.c:4170:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory ALSA lib ../../src/conf.c:4649:(snd_config_expand) Evaluate error: No such file or directory ALSA lib ../../../src/pcm/pcm.c:2190:(snd_pcm_open_noupdate) Unknown PCM iec958 capture.c:520: Test failed: Activation failed with 80004005 ALSA lib ../../src/confmisc.c:768:(parse_card) cannot find card '0' ALSA lib ../../src/conf.c:4170:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory ALSA lib ../../src/confmisc.c:392:(snd_func_concat) error evaluating strings ALSA lib ../../src/conf.c:4170:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory ALSA lib ../../src/confmisc.c:1251:(snd_func_refer) error evaluating name ALSA lib ../../src/conf.c:4170:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory ALSA lib ../../src/conf.c:4649:(snd_config_expand) Evaluate error: No such file or directory ALSA lib ../../../src/pcm/pcm.c:2190:(snd_pcm_open_noupdate) Unknown PCM iec958 capture.c:607: Test failed: Activation failed with 80004005 wine: Unhandled page fault on read access to 0x00000000 at address 0x68687a9a (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x68687a9a). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:68687a9a ESP:0032fc30 EBP:0032fd38 EFLAGS:00010206( R- -- I - -P- ) EAX:00000000 EBX:6869915c ECX:0032fd04 EDX:686995c8 ESI:68693ada EDI:80004005 Stack dump: 0x0032fc30: 00000000 68693ae4 80004005 00000000 0x0032fc40: 0032fd18 00123e08 00000017 00c9ed90 0x0032fc50: 0032fd00 7bc9ed90 0032fc78 7bc68211 0x0032fc60: 00000002 00000040 0032fca8 7bc688f5 0x0032fc70: 7bcb9c30 00000002 00000001 7bc3578f 0x0032fc80: 00000017 00000017 00000000 7ffdf044 Backtrace: =>0 0x68687a9a func_capture+0x38a() [/home/julliard/wine/wine/dlls/mmdevapi/tests/capture.c:609] in mmdevapi_test (0x0032fd38) 1 0x686929be run_test+0x14d(name="capture.c") [/home/julliard/wine/wine/dlls/mmdevapi/tests/../../../include/wine/test.h:556] in mmdevapi_test (0x0032fd88) 2 0x68693487 main+0x156(argc=0x1, argv=(nil)) [/home/julliard/wine/wine/dlls/mmdevapi/tests/../../../include/wine/test.h:624] in mmdevapi_test (0x0032fe48) 3 0x6869365c __wine_spec_exe_entry+0x7b(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in mmdevapi_test (0x0032fe90) 4 0x7b85aaac call_process_entry+0xb() in kernel32 (0x0032fea8) 5 0x7b85b6df start_process+0x5e(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/kernel32/process.c:1087] in kernel32 (0x0032fee8) 6 0x7bc73808 call_thread_func+0xb() in ntdll (0x0032fef8) 7 0x7bc76f6e call_thread_entry_point+0x6d(entry=0x7b85b680, arg=0x7ffdf000) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2499] in ntdll (0x0032ffc8) 8 0x7bc4c15e start_process+0x1d(kernel_start=0x7b85b680) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2612] in ntdll (0x0032ffe8) 9 0x6802998d wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) 0x68687a9a func_capture+0x38a [/home/julliard/wine/wine/dlls/mmdevapi/tests/capture.c:609] in mmdevapi_test: movl 0x0(%eax),%edx 609 hr = IAudioClient_GetMixFormat(ac, &fmt); -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [8/15]usp10/tests: Hebrew shaping test
by Alexandre Julliard 24 May '11

24 May '11

Aric Stewart <aric(a)codeweavers.com> writes: > --- > dlls/usp10/tests/usp10.c | 9 +++++++++ > 1 files changed, 9 insertions(+), 0 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M usp10.dll -T ../../.. -p usp10_test.exe.so usp10.c && touch usp10.ok usp10.c:438: Test failed: 0: Glyph not present when it should be usp10.c:438: Test failed: 1: Glyph not present when it should be usp10.c:438: Test failed: 2: Glyph not present when it should be usp10.c:438: Test failed: 3: Glyph not present when it should be make[1]: *** [usp10.ok] Error 4 -- Alexandre Julliard julliard(a)winehq.org

1 0

performance regression or not?
by Joerg-Cyril.Hoehle＠t-systems.com 24 May '11

24 May '11

Hi, please consider the following WINEDEBUG=+fps numbers. 1.1.24 24-19 fps, depending on orientation 1.3.16 14-7 fps 1.3.18-291-g9da9240 14-6 fps 1.3.18-342-gab199f5 13-5 fps 1.3.19-46-g3025f7f 8 fps 1.3.20 7-4 fps The low fps results in jerky character movement. This looks like a serious performance degradation over time, isn't it? Actually, the situation is much subtler and so confusing that I don't know what to think about it. - Disabling audio in winecfg yields 25 fps. Audio seems to play a major role, although both CPU% of the dual core machine are mostly near 33%. - Once and only once, while running 1.3.19-27-gf912e55, I observed 25 fps (with sound!) instead of 13. So new Wine *can* still play fast, it just almost never does it. Why? - After much bisecting, I've learnt that while newer versions of Wine typically produce low fps initially, I can go to the app's options -> graphics -> effects settings during game, change some of them, revert them to their original values, then observe 25 fps -- with sound! What's this weird relationship between sound and 3D? - git bisect lead to a change about mmdevapi.dll that the app does not even use. My hypothesis so far is that Wine or the app seems extremely sensitive to the random location of some stuff in memory. - I don't believe the machine is overloaded. I can start 2 side by side, e.g. demo and retail, in different versions of Wine. - I'm now wondering whether thread affinity may play a role. Alas, I don't know how to disable one core with Mac OS X 10.5.8 The app uses mono internally (windows' version). It's named 2weistein http://www.2weistein.de/ There exists a demo of the first 2 levels, but the level 'Lyrias Zauberbann' where fps varies much is not part of the demo. How to make sense of these observations? Thanks for your help, Jörg Höhle Testing using an "early 2009" NVidia Mac Mini with OS X 10.5.8 and XQuartz 2.6.1

3 2

Wine's implementation of d3dtypes.h does not work with ISO C++
by Daniel Scharrer 24 May '11

24 May '11

Hi all, I am working on porting the d3d 7 game Arx Fatalis [1] to linux/OpenGL and we are currently compiling as a winelib application to do so. Because the game is written in c++ and defines D3D_OVERLOADS, I get the following errors in d3dtypes.h (reported as wine bug [2]): /usr/include/wine/windows/d3dtypes.h: In member function ‘D3DVALUE& _D3DMATRIX::operator()(int, int)’: /usr/include/wine/windows/d3dtypes.h:339:30: error: ISO C++ forbids casting to an array type ‘D3DVALUE [4][4]’ /usr/include/wine/windows/d3dtypes.h: In member function ‘const D3DVALUE& _D3DMATRIX::operator()(int, int) const’: /usr/include/wine/windows/d3dtypes.h:341:36: error: ISO C++ forbids casting to an array type ‘const D3DVALUE [4][4]’ Notice that is is a fatal error and not just a warning unless -fpermissive is passed to wineg++. While we can work around this when using gcc (using pragmas to enable -fpermissive just for wine's d3d headers), there is no portable way (across compilers) to use Direct3D's overloaded operators from wine's implementation. The bug report [2] hasn't gotten any real responses and I'd really like to get this fixed, but don't know what the best solution would be that follows wine coding conventions. Wine's current implementation of D3DMATRIX is typedef struct _D3DMATRIX { D3DVALUE _11, _12, _13, _14; D3DVALUE _21, _22, _23, _24; D3DVALUE _31, _32, _33, _34; D3DVALUE _41, _42, _43, _44; #if defined(__cplusplus) && defined(D3D_OVERLOADS) _D3DMATRIX() { } /* This is different from MS, but avoids anonymous structs. */ D3DVALUE &operator () (int r, int c) { return ((D3DVALUE [4][4])&_11)[r][c]; } const D3DVALUE &operator() (int r, int c) const { return ((const D3DVALUE [4][4])&_11)[r][c]; } #endif } D3DMATRIX, *LPD3DMATRIX; MSDN doesn't seem to have a documentation for anything older than d3d 9 anymore, so I have no idea what the original definition looks like. The comment indicates that anonymous structs aren't allowed -- is this correct? An alternative solution would be to calculate the 2D array offsets manually, something like this: D3DVALUE &operator () (int r, int c) { return ((D3DVALUE*)&_11)[r*4 + c]; } Would that implementation be acceptable? Also, if D3D_OVERLOADS has been defined, wine's d3dtypes.h (and also d3d.h) expect <math.h> to have already been included: In file included from /usr/include/wine/windows/d3dtypes.h:346:0, from /usr/include/wine/windows/d3d.h:26, from test.cpp:4: /usr/include/wine/windows/d3dvec.inl: In function ‘D3DVALUE Magnitude(const _D3DVECTOR&)’: /usr/include/wine/windows/d3dvec.inl:118:33: error: ‘sqrt’ was not declared in this scope As I don't have a copy of the d3d 7 SDK I can't check if this is normal or another bug in the wine headers. [1] https://github.com/lubosz/ArxFatalis [2] http://bugs.winehq.org/show_bug.cgi?id=25942 -- Daniel Scharrer

2 1

Question about the fSources argument to SHChangeNotifyRegister
by Jay Yang 24 May '11

24 May '11

Hi, Could someone who understands the fSources argument to SHChangeNotifyRegister explain it to me? MSDN says it can take some combination of SHCNRF_InterruptLevel, SHCNRF_ShellLevel, SHCNRF_RecursiveInterrupt, and SHCNRF_NewDelivery. I've looked at the source and it seems that the only one wine handles differently is SHCNRF_NewDelivery, so what do the others mean? MSDN says something about it but quite frankly I don't know what the difference between interrupt level and shell level notifications are. Also the the only place in the tree where wine uses this function, in dlls/shell32/shlview.c, it gets passed SHCNF_IDLIST, which isn't even one of the values. SHCNF_IDLIST happens to be defined as 0, but I think that's irrelevant. Thanks -- Jay Yang

1 0

Re: [1/5] d3d: Make the INTZ test more reliable
by Henri Verbeet 23 May '11

23 May '11

On 23 May 2011 22:50, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > This eliminates the precision issues caused by the projected texture by > setting the .w coordinate to a constant value. I decided to keep the > projected sampling itself around to demonstrate that d3d doesn't do anything > special with the 3rd and 4th value like it does with other shadow formats The 3rd and 4th coordinate are going to be the same for the locations you're sampling now.

2 1

Re: [PATCH 3/5] d3d9/tests: Fix the depth clamping test.
by Marvin 23 May '11

23 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=11124 Your paranoid android. === WXPPROSP3 (32 bit visual) === visual.c:205: Test failed: IDirect3D_CreateDevice returned: 8876086c === W2K3R2SESP2 (32 bit visual) === visual.c:205: Test failed: IDirect3D_CreateDevice returned: 8876086c === WVISTAADM (32 bit visual) === visual.c:205: Test failed: IDirect3D_CreateDevice returned: 8876086c === W2K8SE (32 bit visual) === visual.c:205: Test failed: IDirect3D_CreateDevice returned: 8876086c === W7PRO (32 bit visual) === visual.c:205: Test failed: IDirect3D_CreateDevice returned: 8876086c === W7PROX64 (32 bit visual) === visual.c:205: Test failed: IDirect3D_CreateDevice returned: 8876086c === W7PROX64 (64 bit visual) === visual.c:205: Test failed: IDirect3D_CreateDevice returned: 8876086c

1 0

Re: dbghelp: Implement SymEnumSourceFilesW.
by Alexandre Julliard 23 May '11

23 May '11

Andrew Nguyen <anguyen(a)codeweavers.com> writes: > This fixes bug 27222. > > --- > dlls/dbghelp/dbghelp.spec | 2 +- > dlls/dbghelp/source.c | 102 +++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 103 insertions(+), 1 deletions(-) The A version should call the W one, not the other way around. -- Alexandre Julliard julliard(a)winehq.org

2 2

no line numbers in backtraces on Mac OS X?
by Joerg-Cyril.Hoehle＠t-systems.com 23 May '11

23 May '11

Hi, Is it normal that there are no source line numbers in backtraces on Mac OS? Despite many patches to winedbg etc., the backtraces I get are no better that those from 1.1.24 times. 18 0x41f5b2a1 _OpenDriverA+0x51() in winmm (0x0032ce78) 19 0x4041467f _initAudioDlg+0x75f() in winecfg (0x0032dc28) I'm using configure + make to build. On Linux, the line numbers help a lot in locating bogus code. Thank for your help, Jörg Höhle.

4 4

Re: [PATCH 1/2] mountmgr: Populate HKLM\HARDWARE\DEVICEMAP\Scsi here instead of in kernel32. (try 7 resend)
by Alexandre Julliard 23 May '11

23 May '11

Charles Davis <cdavis(a)mymail.mines.edu> writes: > Rebased against Marcus Meissner's DECLSPEC_HIDDEN patches. (I hate you, Marcus...) > Try 7: Fix getting the device name for IDE devices. > Try 6: Fix some problems noticed by Vitaliy Margolen. > Try 5: Get the value of "DeviceName" from mountmgr instead of making one up. > Try 4: Fix unused variable warning. > Try 3: Add support for IDE drives. > Try 2: Don't depend on the SCSI generic driver on Linux. The unix device name is not being set properly here. I would consider not setting the key a feature (we don't really need it), but it means the DMA flag isn't set either. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: user32: Partially implement FlashWindowEx with tests (try 2)
by Alexandre Julliard 23 May '11

23 May '11

André Hentschel <nerv(a)dawncrow.de> writes: > + for (i=0; i<pfwi->uCount + 1; i++) > + { > + FlashWindow(pfwi->hwnd, TRUE); > + Sleep(msecs); > + FlashWindow(pfwi->hwnd, FALSE); > + Sleep(msecs); > + } I don't think you want to hang the app that way. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [15/15]usp10/test: add Lao shaping test
by Marvin 23 May '11

23 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=11107 Your paranoid android. === WNT4WSSP6 (32 bit usp10) === Timeout

1 0

Re: [14/15]usp10/test: add Phags-pa shaping test
by Marvin 23 May '11

23 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=11106 Your paranoid android. === WNT4WSSP6 (32 bit usp10) === Timeout

1 0

Re: [13/15]usp10/test: add Thaana shaping test
by Marvin 23 May '11

23 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=11105 Your paranoid android. === WNT4WSSP6 (32 bit usp10) === Timeout

1 0

Re: [12/15]usp10/tests: add Syriac shaping test
by Marvin 23 May '11

23 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=11104 Your paranoid android. === WNT4WSSP6 (32 bit usp10) === Timeout

1 0

Re: [8/15]usp10/tests: Hebrew shaping test
by Marvin 23 May '11

23 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=11100 Your paranoid android. === WNT4WSSP6 (32 bit usp10) === usp10.c:1594: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 73 usp10.c:1560: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1572: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 87 usp10.c:1573: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 71 usp10.c:1581: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 87 usp10.c:1582: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 88 usp10.c:1592: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 87 usp10.c:1608: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 87 usp10.c:1610: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 86 === W2KPROSP4 (32 bit usp10) === usp10.c:1594: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 67 usp10.c:1560: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1572: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 81 usp10.c:1573: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 65 usp10.c:1581: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 81 usp10.c:1582: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 82 usp10.c:1592: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 81 usp10.c:1608: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 81 usp10.c:1610: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 80 === WXPPROSP3 (32 bit usp10) === usp10.c:1594: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 67 usp10.c:1560: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1572: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 81 usp10.c:1573: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 65 usp10.c:1581: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 81 usp10.c:1582: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 82 usp10.c:1592: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 81 usp10.c:1608: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 81 usp10.c:1610: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 80 === W2K3R2SESP2 (32 bit usp10) === usp10.c:1594: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 67 usp10.c:1560: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1572: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 81 usp10.c:1573: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 65 usp10.c:1581: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 81 usp10.c:1582: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 82 usp10.c:1592: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 81 usp10.c:1608: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 81 usp10.c:1610: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 80

1 0

mmsystem16.h incorrect? SEGPTR vs. LPSTR
by Joerg-Cyril.Hoehle＠t-systems.com 23 May '11

23 May '11

Alexandre, Damjan, Eric, I understand your answers mean that a patch is needed to MCI_*_PARMS16 in mmsystem16.h to turn all occurrences of LPSTR into SEGPTR. E.g. MCI_LOAD_PARMS16, MCI_DGV_INFO_PARMS16, MCI_DGV_OPEN_PARMS16 ... I suppose "DWORD dwCallback;" is ok to copy 1:1 (what the code currently does) because it contains a window handle, not pointer. It would be wrong if the 16bit SDK contained HWND16 wCallback; UINT16 wReserved0; because then Wine might see half garbage and be lucky when wReserved is 0. Regards, Jörg Höhle

1 0

[1/2] mmsystem.dll16: fix MCI_STATUS mapping for digitalvideo
by Joerg-Cyril.Hoehle＠t-systems.com 23 May '11

23 May '11

Damjan, @@ -407,6 +441,20 @@ static MMSYSTEM_MapType MCI_UnMapMsg16To32W(WORD wMsg, DWORD dwFlags, DWORD_PTR + mdsp16->dwCallback = mdsp32w->dwCallback; + mdsp16->dwItem = mdsp32w->dwItem; + mdsp16->dwTrack = mdsp32w->dwTrack; This is superfluous. dwReturn is the only documented output. This was different with your former MCI_WHERE patch, where a RECT is output. I'd try hard not to turn one message call (Status) into 2 (GetDevCaps + Status). I've seen logs of apps that continuously poll MCI_STATUS_POSITION. Instead, I'd continue the path lead by winmm/mci.c:MCI_MapMsgAtoW: Allocate the largest structure and fill it depending on dwFlags, e.g.: case MCI_OPEN: { /* MCI_ANIM_OPEN_PARMS is the largest known MCI_OPEN_PARMS * structure, larger than MCI_WAVE_OPEN_PARMS */ BTW, I've a note that MCI_INFO needs similar treatment, but never wrote the patch... Select the right set of flags to fill the slots, otherwise fallback to defaults like: /* We don't know how many DWORD follow, as * the structure depends on the device. */ if (HIWORD(dwParam1)) memcpy(&mci_openW->dwStyle, &mci_openA->dwStyle, sizeof(MCI_ANIM_OPEN_PARMSW) - sizeof(MCI_OPEN_PARMSW)); Of course, one may argue that this is a heuristic and can fail. Well, GetDevCaps is a heuristic as well that only supports devtype_digital_video. An advantage IMHO of the existing approach is that it does not invent within the same source code base yet another mechanism to map 16 to 32 or A to W. I'd rather follow the existing model until the time it proves unbearable, or immediately switch the *whole* code base to another model, not the single MCI_STATUS function. For instance, you can argue that it makes sense for winmm to cache the device type (winmm:MCI_Open has it in several cases). It would arguably also make sense to cache the MCI auto_open'ed property, but I digress. Your MCI_get_device_type is bogus. MCI_GETDEVCAPS_DEVICE_TYPE belongs into dwItem, not dwFlags. Regards, Jörg Höhle

3 6

Request for comments: d3dX : wined3d implicit enum conversion warnings and resolution
by Frédéric Delanoy 23 May '11

23 May '11

Hi guys, while trying to compile wine with clang, I get a whole bunch of "implicit conversion from enumeration type FOO to different enumeration type WINED3DFOO" (and conversely) warnings when an enum value of type A is assigned to a var of enum type B. In order to tackle those, instead of using (probably ugly) casts everywhere, I put them in a "static inline" function in d3dX_private.h (conv functions put in the header so inlining is possible everywhere, so a potential performance impact is limited) Originally, I intended to issue a FIXME("Unhandled/unrecognized value...") in the default: clause of a switch statement to catch values not in in the original enum's domain, but I couldn't find a way to make FIXMEs work in a .h file 'cos of a macro expansion hell I'm not quite sure however what the best solution is wrt performance, so I'd like your comments on this Some explanations: *D3DPOOL and WINED3DPOOL have a full 1-1 mapping, so the conv functions simply do a cast. *D3DRESOURCETYPE and WINED3DRESOURCETYPE have *not* a 1-1 mapping, and I present here 3 possible solution types: D3DRESOURCETYPE => D3DRTYPE_SURFACE = 1, D3DRTYPE_VOLUME = 2, D3DRTYPE_TEXTURE = 3, D3DRTYPE_VOLUMETEXTURE = 4, D3DRTYPE_CUBETEXTURE = 5, D3DRTYPE_VERTEXBUFFER = 6, D3DRTYPE_INDEXBUFFER = 7, D3DRTYPE_FORCE_DWORD = 0x7fffffff WINED3DRESOURCETYPE => WINED3DRTYPE_SURFACE = 1, WINED3DRTYPE_VOLUME = 2, WINED3DRTYPE_TEXTURE = 3, WINED3DRTYPE_VOLUMETEXTURE = 4, WINED3DRTYPE_CUBETEXTURE = 5, WINED3DRTYPE_BUFFER = 6, WINED3DRTYPE_FORCE_DWORD = 0x7fffffff Type 1 --------- Identical semantics to direct assigment All cases specified, even "obvious" ones (D3D_FOO <-> WINED3D_FOO), using same enum value; non mapped values use the default: clause (e.g. D3DRTYPE_INDEXBUFFER=7; no 7 enum val in WINED3DRESOURCETYPE) Default clause: only used for values not in original enum Type 2 --------- Same as v1 except obvious values aren't specified in a case: Non directly obvious values (same enum val) can still be "highlighted" (e.g. WINED3DRTYPE_BUFFER=6 ==> D3DRTYPE_VERTEXBUFFER=6) Default clause: used for values not in original enum AND obvious values Maybe more optimal than "type 1", but isn't that a micro/premature optimisation? Type 3 --------- Potentially more risky/invasive: conversion does not simply return value "as-is" Semantics *changes* from direct assigment; some additional code changes are necessary; could help centralise, though e.g. D3DRTYPE_VERTEXBUFFER=6 => WINED3DRTYPE_BUFFER=6 D3DRTYPE_INDEXBUFFER=7 => WINED3DRTYPE_BUFFER=6 Adapted code (directx.c): - switch(RType) { - case D3DRTYPE_VERTEXBUFFER: - case D3DRTYPE_INDEXBUFFER: - WineD3DRType = WINED3DRTYPE_BUFFER; - break; - - default: - WineD3DRType = RType; - break; - } + WineD3DRType = wined3dresourcetype_from_d3dresourcetype(RType); What do you think would be best? Frédéric

1 0

Re: ddraw: Don't interpret end padding as dwCaps2 for x64.
by Alexandre Julliard 23 May '11

23 May '11

Dylan Smith <dylan.ah.smith(a)gmail.com> writes: > @@ -3123,6 +3123,8 @@ static HRESULT CreateSurface(IDirectDrawImpl *ddraw, DDSURFACEDESC2 *DDSD, > memset(&desc2, 0, sizeof(desc2)); > desc2.dwSize = sizeof(desc2); /* For the struct copy */ > DD_STRUCT_COPY_BYSIZE(&desc2, DDSD); > + if (DDSD->dwSize == sizeof(DDSURFACEDESC)) > + CLEAR_STRUCT_END_PADDING((DDSURFACEDESC*)&desc2, ddsCaps); I'd suggest to rethink the whole thing. We don't really need to set the same structure fields 4 times. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: urlmon: Fix incorrect pointer arithmetic (too conversative) in map_url_to_zone.
by Nikolay Sivov 23 May '11

23 May '11

On Sun, May 22, 2011 at 10:53 PM, Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > The difference between two pointers (of the same type) is the number > of elements, not the number of bytes. That's why it was divided by element size to get 'number of elements'. What's a problem? > Thus the code below was way > incorrect, luckily only too conversative. > > Gerald > > --- > dlls/urlmon/sec_mgr.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/urlmon/sec_mgr.c b/dlls/urlmon/sec_mgr.c > index 7b4bb35..75850ee 100644 > --- a/dlls/urlmon/sec_mgr.c > +++ b/dlls/urlmon/sec_mgr.c > @@ -529,7 +529,7 @@ static HRESULT map_url_to_zone(LPCWSTR url, DWORD *zone, LPWSTR *ret_url) > hres = CoInternetParseUrl(secur_url, PARSE_PATH_FROM_URL, 0, path, > sizeof(path)/sizeof(WCHAR), &size, 0); > > - if(SUCCEEDED(hres) && (ptr = strchrW(path, '\\')) && ptr-path < sizeof(root)/sizeof(WCHAR)) { > + if(SUCCEEDED(hres) && (ptr = strchrW(path, '\\')) && ptr-path < sizeof(root)) { > UINT type; > > memcpy(root, path, (ptr-path)*sizeof(WCHAR)); > -- > 1.7.4.1 > > >

1 0

Re: comctl32: Shed an unused parameter of TOOLTIPS_HitTestT and rename to TOOLTIPS_HitTest. (RESEND)
by Nikolay Sivov 23 May '11

23 May '11

On Sun, May 22, 2011 at 6:07 PM, Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > Any problems with this patch I submitted back in February? > I believe I mentioned it, or I should have. Message handler is incomplete, cause it should return text as well, that's why it has A/W versions. This needs tests and proper implementation, not just reducing parameters list for no reason. (and if tests show no use of text for these messages it's a reason of course) > Gerald > > --- > dlls/comctl32/tooltips.c | 7 +++---- > 1 files changed, 3 insertions(+), 4 deletions(-) > > diff --git a/dlls/comctl32/tooltips.c b/dlls/comctl32/tooltips.c > index a2e58e0..445845c 100644 > --- a/dlls/comctl32/tooltips.c > +++ b/dlls/comctl32/tooltips.c > @@ -1396,8 +1396,7 @@ TOOLTIPS_GetToolInfoT (const TOOLTIPS_INFO *infoPtr, TTTOOLINFOW *ti, BOOL isW) > > > static LRESULT > -TOOLTIPS_HitTestT (const TOOLTIPS_INFO *infoPtr, LPTTHITTESTINFOW lptthit, > - BOOL isW) > +TOOLTIPS_HitTest (const TOOLTIPS_INFO *infoPtr, LPTTHITTESTINFOW lptthit) > { > TTTOOL_INFO *toolPtr; > INT nTool; > @@ -2209,8 +2208,8 @@ TOOLTIPS_WindowProc (HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam) > > case TTM_HITTESTA: > case TTM_HITTESTW: > - return TOOLTIPS_HitTestT (infoPtr, (LPTTHITTESTINFOW)lParam, > - uMsg == TTM_HITTESTW); > + return TOOLTIPS_HitTest (infoPtr, (LPTTHITTESTINFOW)lParam); > + > case TTM_NEWTOOLRECTA: > case TTM_NEWTOOLRECTW: > return TOOLTIPS_NewToolRectT (infoPtr, (LPTTTOOLINFOW)lParam); > -- > 1.7.4.1 > > >

1 0

Re: TestBot job 11094 results: Re: comctl32/tests: Add casts to avoid comparison of different int types. [take 2]
by Gerald Pfeifer 23 May '11

23 May '11

On Mon, 23 May 2011, Marvin wrote: > VM Status Number of test failures > WINEBUILD completed > WNT4WSSP6 completed 0 > W2KPROSP4 completed 0 > WXPPROSP3 completed 0 > W2K3R2SESP2 failed > WVISTAADM completed 0 > W2K8SE completed 0 > W7PRO completed 0 > W7PROX64 completed 0 > W7PROX64 completed 0 For the record, I plead not guilty as far as the following goes. === W2K3R2SESP2 (32 bit tab) === Can't copy exe to VM: Failed to resolve host :-) Gerald

1 0

Big ugly build changes might be needed for Debian/Ubuntu
by Scott Ritchie 22 May '11

22 May '11

So, multiarch is going along well in Debian/Ubuntu, and by next distro release Wine should be building as a proper multiarch package. Previous hacks like ia32-libs will be dead for good. A side effect of this change, however, is the current build daemons ONLY have packages for one architecture. This means that, at build time, you won't be able to pull in the 32-bit packages on a 64-bit build daemon. >From what I understand, this change is originating in Debian (and thus propagating to Ubuntu). I believe the motivations are mostly ease of management of the build daemons -- only by doing this, for instance, can an entire architecture be properly isolated and self-contained. This means for bi-arch Wine, we will need to either: - Make Wine support building in pure 64-bit mode and then calling the 32-bit subsystem from a separate binary - Make a very persuasive case that Wine isn't the only package that needs to have multiple architectures at build time Hopefully I'm overestimating the amount of work involved, as this sort of architecture modularity might be a "nice to have" in Wine anyway. If none of this is doable by next release, we'll just have a 32-bit only Wine, which isn't really any worse than the situation now. -Scott Ritchie

5 12

Re: user32: Partially implement FlashWindowEx with tests
by Dmitry Timoshkov 22 May '11

22 May '11

André Hentschel <nerv(a)dawncrow.de> wrote: > + if (!pfwi->hwnd || pfwi->cbSize < sizeof(FLASHWINFO)) > + { > + SetLastError(ERROR_INVALID_PARAMETER); > + return FALSE; > + } I don't see in your tests the case for 'cbSize > sizeof(FLASHWINFO)'. Also using !IsWindow() instead of !hwnd would fix one more test case. -- Dmitry.

3 2

Re: ddraw: Don't interpret end padding as dwCaps2 for x64.
by Stefan Dösinger 22 May '11

22 May '11

On Sunday 22 May 2011 06:57:30 Dylan Smith wrote: > 4 bytes of padding are at the end of DDSURFACEDESC when compiling for > x64, because it contains a pointer field followed by an odd number > of DWORD fields. Does DDSURFACEDESC have the same padding when using the microsoft headers and msvc?

2 1

Re: comctl32/tests: Add casts to avoid comparison of different int types. [take 2]
by Alexandre Julliard 22 May '11

22 May '11

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > This is the first hunk of a patch a few days ago; testbot.winehq.org > thinks it's fine: https://testbot.winehq.org/JobDetails.pl?Key=9291 You don't need casts. If the variable has the wrong type you can change that. -- Alexandre Julliard julliard(a)winehq.org

2 1

hello
by chris.teague＠gmail.com 20 May '11

20 May '11

, i paid off all my debt http://tulsamarketplace.com/redirect.php?to=aHR0cDovL3d3dy5jbmJjNy5jb20vP3B…

1 0

Re: gdi32: Fetch CURVECAPS, LINECAPS and POLYGONALCAPS for an EMF from parent device.
by Alexandre Julliard 20 May '11

20 May '11

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > This follows the way how it's done for other device capabilities. It's not clear that this makes sense, a metafile is capable of doing all these things even if the device cannot. Have you verified this on a device that doesn't have all the caps? -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [3/3] d3d9: Try to get the INTZ test working on nvidia cards
by Henri Verbeet 19 May '11

19 May '11

I think I'd rather just change the way the test works.

1 0

Re: [PATCH 7/7] msvcrt: Make functions working on FILE thread safe
by Alexandre Julliard 19 May '11

19 May '11

Piotr Caban <piotr(a)codeweavers.com> writes: > --- > dlls/msvcrt/file.c | 448 > ++++++++++++++++++++++++++++++++++++---------------- > 1 files changed, 314 insertions(+), 134 deletions(-) This one should probably be split. It also breaks badly on 64-bit: ../../../../wine/tools/runtest -q -P wine -M mshtml.dll -T ../../.. -p mshtml_test.exe.so ../../../../wine/dlls/mshtml/tests/activex.c && touch activex.ok err:seh:setup_exception stack overflow 2336 bytes in thread 0021 eip 00002b829f113a5d esp 0000000000140ce0 stack 0x140000-0x141000-0x240000 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: hostname: Add an implementation of the hostname display utility. (try 2)
by Alexandre Julliard 19 May '11

19 May '11

Andrew Nguyen <anguyen(a)codeweavers.com> writes: > diff --git a/programs/hostname/Makefile.in b/programs/hostname/Makefile.in > new file mode 100644 > index 0000000..300d727 > --- /dev/null > +++ b/programs/hostname/Makefile.in > @@ -0,0 +1,12 @@ > +EXTRADEFS = -DWINE_NO_UNICODE_MACROS > +MODULE = hostname.exe > +APPMODE = -mconsole -municode > +IMPORTS = ws2_32 You probably don't want to use winsock, at least not for Unix builds. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [2/2] d3dx9: Implement D3DXLoadMeshHierarchy for basic mesh hierarchy.
by Joris Huizer 19 May '11

19 May '11

Hello, I found a possibly memory leak in the patch. In this function: > +static HRESULT parse_mesh(IDirectXFileData *filedata, struct mesh_data *mesh_data, DWORD provide_flags) These may leak the allocated blocks: > + > + mesh_data->vertices = HeapAlloc(GetProcessHeap(), 0, > + mesh_data->num_vertices * sizeof(*mesh_data->vertices)); > + mesh_data->num_tri_per_face = HeapAlloc(GetProcessHeap(), 0, > + mesh_data->num_poly_faces * sizeof(*mesh_data->num_tri_per_face)); > + mesh_data->indices = HeapAlloc(GetProcessHeap(), 0, > + (mesh_data->num_tri_faces + mesh_data->num_poly_faces * 2) * sizeof(*mesh_data->indices)); > + if (!mesh_data->vertices || !mesh_data->num_tri_per_face || !mesh_data->indices) > + return E_OUTOFMEMORY; > + HTH, Joris

2 2

Re: oleaut32/tests: remove macros from test_VarCyCmpR8
by Nikolay Sivov 19 May '11

19 May '11

On Thu, May 19, 2011 at 11:30 AM, Austin English <austinenglish(a)gmail.com> wrote: > -- > -Austin > > > > This test should use a table+loop I think.

1 0

Re: [bugzilla] Fix Bug 16822 - Mass Effect: Mouse input does not work (almost completely)
by Vitaliy Margolen 19 May '11

19 May '11

On 05/18/2011 12:03 PM, siro wrote: > This patch don't clear the dinput queue in IDirectInputDevice2WImpl_Acquire Clearly this is wrong. Of course you can prove otherwise with some tests. You can also test with native dinput to see if it has the same issue or not. Vitaliy.

1 0

Re: gdi32: Add support in DeviceCaps CURVECAPS, LINECAPS, POLYGONALCAPS for EnhMetafiles
by Dmitry Timoshkov 19 May '11

19 May '11

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > gdi32: Add support in DeviceCaps CURVECAPS, LINECAPS, POLYGONALCAPS > for EnhMetafiles I'd guess they should be cached and returned for the parent device instead. -- Dmitry.

1 0

Re: [PATCH] winex11: Make GetCursorPos respect clipping and virtual screen size.
by Alexandre Julliard 19 May '11

19 May '11

Lauri Kenttä <lauri.kentta(a)gmail.com> writes: > On Wed, 18 May 2011 10:57:24 +0200, Alexandre Julliard wrote: >> >> That won't really do what you want. Why do you need this? > > Then what does it do wrong? It seems to do exactly what I want and > mostly what Windows does. The clip rectangle is only valid while the pointer is grabbed, in which case the cursor pos will be clipped already. So for the case where the pointer is not grabbed (for instance if you don't have XInput) it would have to go through the wineserver. > The clipping is necessary for games using Infinite Engine > (e.g. Baldur's Gate) for border scrolling when using virtual > desktop. Otherwise it's next to impossible to scroll because the game > only checks for one pixel at the border (e.g. x == 0) but Wine > currently returns also values that never occur on Windows (e.g. x == > -1). Have you tried the new desktop clipping mode? -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: [PATCH] dinput: Move the c_df* data format constants to the dxguid static library, mark as hidden
by Alexandre Julliard 19 May '11

19 May '11

Marcus Meissner <meissner(a)suse.de> writes: > --- > dlls/dinput/Makefile.in | 1 - > dlls/dinput/data_formats.c | 566 -------------------------------------------- > dlls/dxguid/dxguid.c | 545 ++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 545 insertions(+), 567 deletions(-) > delete mode 100644 dlls/dinput/data_formats.c What makes you think they should be in dxguid? -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: tests/msvcrt: add test for _splitpath function
by Eric Pouech 19 May '11

19 May '11

adding c:test.txt (and friends) as input should be also interesting UNC paths should also be tested A+ + } Paths[] = { {"C:/directory/test.txt", "C:", "/directory/", > "test", ".txt"}, > + {"C:\\directory\\test.txt", "C:", "\\directory\\", > "test", ".txt"}, > + {"C:\\directory\\test", "C:", "\\directory\\", "test", > ""}, > + {"C:\\directory\\.txt", "C:", "\\directory\\", "", > ".txt"}, > + {"C:\\directory\\", "C:", "\\directory\\", "", ""}, > + {"C:\\test.txt", "C:", "\\", "test", ".txt"}, > + {"C:\\test", "C:", "\\", "test", ""}, > + {"C:\\.txt", "C:", "\\", "", ".txt"}, > + {"C:\\", "C:", "\\", "", ""}, > + {"\\directory\\test.txt", "", "\\directory\\", "test", > ".txt"}, > + {"\\directory\\test", "", "\\directory\\", "test", ""}, > + {"\\directory\\.txt", "", "\\directory\\", "", ".txt"}, > + {"\\directory\\", "", "\\directory\\", "", ""}, > + {"\\test.txt", "", "\\", "test", ".txt"}, > + {"\\test", "", "\\", "test", ""}, > + {"\\.txt", "", "\\", "", ".txt"}, > + {"\\", "", "\\", "", ""}, > + {"test.txt", "", "", "test", ".txt"}, > + {"test", "", "", "test", ""}, > + {".txt", "", "", "", ".txt"}, > + {"", "", "", "", ""}}; > -- > Eric Pouech >

1 0

Re: d3d: avoid implicit conversion warnings from identical enumeration types D3DPOOL and WINED3DPOOL (Clang) - please discard patch
by Frédéric Delanoy 19 May '11

19 May '11

Patch can be discarded. Spreading casts all over is probably a bad thing.

1 0

Re: d3d8: Silence implicit enum conversion warnings for D3DFormat (clang) - please discard
by Frédéric Delanoy 18 May '11

18 May '11

Please discard this patch. An updated version follows.

1 0

Re: [PATCH] winex11: Make GetCursorPos respect clipping and virtual screen size.
by Alexandre Julliard 18 May '11

18 May '11

Lauri Kenttä <lauri.kentta(a)gmail.com> writes: > @@ -1245,8 +1245,17 @@ BOOL CDECL X11DRV_GetCursorPos(LPPOINT pos) > if (ret) > { > POINT old = *pos; > + RECT clip = clipping_cursor ? clip_rect : virtual_screen_rect; > pos->x = winX + virtual_screen_rect.left; > pos->y = winY + virtual_screen_rect.top; > + if (pos->x < clip.left) > + pos->x = clip.left; > + if (pos->x >= clip.right) > + pos->x = clip.right - 1; > + if (pos->y < clip.top) > + pos->y = clip.top; > + if (pos->y >= clip.bottom) > + pos->y = clip.bottom - 1; That won't really do what you want. Why do you need this? -- Alexandre Julliard julliard(a)winehq.org

1 0

Ubuntu likely to abandon HAL next cycle -- is this workable?
by Scott Ritchie 17 May '11

17 May '11

Consensus here seems to be to try and remove HAL from the archive. Wine still uses it, so this means we'll either need to lobby for keeping HAL or to migrate to udisks. Does udisks meet our needs? Will it work for a future USB driver? Is someone working on the migration? Thanks, Scott Ritchie

5 6

Re: [1/3]usp10/tests: add ScriptShapeOpenType tests mirroring ScriptShape tests
by Marvin 17 May '11

17 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=10989 Your paranoid android. === WNT4WSSP6 (32 bit usp10) === usp10.c:1585: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 73 usp10.c:1551: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1563: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 87 usp10.c:1564: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 71 usp10.c:1572: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 87 usp10.c:1573: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 88 usp10.c:1583: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 87 usp10.c:1599: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 87 usp10.c:1601: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 86 === W2KPROSP4 (32 bit usp10) === usp10.c:1585: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 67 usp10.c:1551: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1563: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 81 usp10.c:1564: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 65 usp10.c:1572: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 81 usp10.c:1573: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 82 usp10.c:1583: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 81 usp10.c:1599: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 81 usp10.c:1601: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 80 === WXPPROSP3 (32 bit usp10) === usp10.c:1585: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 67 usp10.c:1551: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1563: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 81 usp10.c:1564: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 65 usp10.c:1572: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 81 usp10.c:1573: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 82 usp10.c:1583: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 81 usp10.c:1599: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 81 usp10.c:1601: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 80 === W2K3R2SESP2 (32 bit usp10) === usp10.c:1585: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 67 usp10.c:1551: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1563: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 81 usp10.c:1564: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 65 usp10.c:1572: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 81 usp10.c:1573: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 82 usp10.c:1583: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 81 usp10.c:1599: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 81 usp10.c:1601: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 80

1 0

Support for D3DQUERY_TIMESTAMP* queries...
by Adam Martinson 17 May '11

17 May '11

Feedback please.

3 5

Re: hostname: Add an implementation of the hostname display utility.
by Juan Lang 17 May '11

17 May '11

Hi Andrew, + GetComputerNameW(name, &size); + hostname_printfW(fmtW, name); I'm pretty sure that's not what you want. GetComputerName returns the "NetBIOS name" of the computer, which is set in the registry. hostname prints the IP hostname of the computer. At least, my look at a Windows version's imports showed no import of GetComputerName, while there is an import of ws2_32.dll's gethostname (by ordinal). --Juan

2 1

Re: Regression in ioctl
by Susan Cragin 17 May '11

17 May '11

2 1

Re: [1/10] taskmgr: Remove the debug channel dialog functionality.
by Alexandre Julliard 17 May '11

17 May '11

2 1

Re: [PATCH] dinput: Mark internal symbols as hidden visibility
by Vitaliy Margolen 17 May '11

17 May '11

On 05/13/2011 08:51 AM, Marcus Meissner wrote: > -const DIDATAFORMAT c_dfDIJoystick = { > +DECLSPEC_HIDDEN const DIDATAFORMAT c_dfDIJoystick = { > -const DIDATAFORMAT c_dfDIJoystick2 = { > +DECLSPEC_HIDDEN const DIDATAFORMAT c_dfDIJoystick2 = { > -const DIDATAFORMAT c_dfDIMouse = { > +DECLSPEC_HIDDEN const DIDATAFORMAT c_dfDIMouse = { > -const DIDATAFORMAT c_dfDIMouse2 = { > +DECLSPEC_HIDDEN const DIDATAFORMAT c_dfDIMouse2 = { > -const DIDATAFORMAT c_dfDIKeyboard = { > +DECLSPEC_HIDDEN const DIDATAFORMAT c_dfDIKeyboard = { These are public exports see include/dinput.h:1988. Vitaliy.

3 2

Re: winemenubuilder: extract icons from NE binaries too
by Alexandre Julliard 17 May '11

17 May '11

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > --- a/programs/winemenubuilder/Makefile.in > +++ b/programs/winemenubuilder/Makefile.in > @@ -1,7 +1,7 @@ > EXTRADEFS = -DWINE_NO_UNICODE_MACROS > MODULE = winemenubuilder.exe > APPMODE = -mwindows -municode > -IMPORTS = uuid windowscodecs shell32 shlwapi ole32 user32 advapi32 > +IMPORTS = uuid windowscodecs shell32 shlwapi ole32 user32 advapi32 kernel You really don't want to use 16-bit functions here. This should be done with normal 32-bit calls. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: shell32: implement the progman DDE interface (try 2)
by Alexandre Julliard 17 May '11

17 May '11

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > Changelog: > * shell32: implement the progman DDE interface > > This attempt calls CoInitialize() only when needed, and icon handling > has been tested, fixed and simplified. I know this is not performance-critical, but the code is quite inefficient, especially with memory allocations. That also makes it hard to read because it adds a lot of unneeded complexity. -- Alexandre Julliard julliard(a)winehq.org

1 0

Trailing white space and other pedantry.
by max＠mtew.isa-geek.net 17 May '11

17 May '11

From: Max TenEyck Woodbury<max(a)mtew.isa-geek.net> I have been working on the documentation extraction problem and code analysis problem. I have made some progress with the program I am writing to do this. It reads the same files as c2man.pl does, but does a more detailed parse of the code. In fact, it even reads and processes all the include files. It is far from complete at this time, but it does produce interesting warnings. One of the warnings reports lines with trailing while space. It has turned up quite a few places where this occurs. If I understand the preferred style, there should not be trailing white space. The question I have is what should I do with them. I can either fix the files or turn that particular warning off. So far, I have been fixing the files on a local copy of the repository. Should I turn the fixes into patches and submit them, or just keep them to myself? Another problem the program warns about is incompatible macro redefinitions. In a few places the differences are just white space, and I have made local fixes. In other places, the differences are more substantial and there are two basic options available. The more difficult solution is to change the definitions in wine to make them compatible with the rest of the system. This could cause problems for people with different system configurations. The other solution is to simply #undef the macros before redefining them. Should I turn the simple fixes into patches and submit them? Should I submit the other problems as bug reports? Max

4 4

Regression in ioctl
by Susan Cragin 16 May '11

16 May '11

This popped up today, and prevented me from opening my program. susan@ubuntu:~/.wine/drive_c/Program Files/Nuance/NaturallySpeaking10/Program$ wine natspeak fixme:mountmgr:harddisk_ioctl returning zero-filled buffer for IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS fixme:mountmgr:harddisk_ioctl unsupported ioctl 74080 fixme:mountmgr:harddisk_ioctl returning zero-filled buffer for IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS fixme:mountmgr:harddisk_ioctl unsupported ioctl 74080 fixme:mountmgr:harddisk_ioctl returning zero-filled buffer for IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS fixme:mountmgr:harddisk_ioctl unsupported ioctl 74080 fixme:reg:RegSetKeySecurity :(0x54,4,0xb05a50): stub fixme:mountmgr:harddisk_ioctl returning zero-filled buffer for IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS fixme:mountmgr:harddisk_ioctl unsupported ioctl 74080 susan@ubuntu:~/.wine/drive_c/Program Files/Nuance/NaturallySpeaking10/Program$ I had just compiled today's git. wine-1.3.20-44-gddad22d Is there a regression test in my future?

2 1

Re: [5/5] comctl32/treeview: Don't send TVN_ITEMEXPANDING when item has no children
by Alexandre Julliard 16 May '11

16 May '11

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > Fix for http://bugs.winehq.org/show_bug.cgi?id=23591 > > From 3bb38e13558c6e06efbb33b7e24cc36c4ae5973f Mon Sep 17 00:00:00 2001 > From: Nikolay Sivov <nsivov(a)codeweavers.com> > Date: Sat, 14 May 2011 20:03:40 +0400 > Subject: [PATCH 5/5] Don't send TVN_ITEMEXPANDING when item has no children It doesn't work here: ../../../tools/runtest -q -P wine -M explorerframe.dll -T ../../.. -p explorerframe_test.exe.so nstc.c && touch nstc.ok nstc.c:1668: Test failed: Got 0x80070057 nstc.c:1933: Test failed: Got event 6, count 0 nstc.c:1934: Test failed: Got event 7, count 0 nstc.c:1935: Test failed: No event. nstc.c:1949: Test failed: Got event 4, count 0 nstc.c:1999: Test failed: Got event 6, count 0 nstc.c:2000: Test failed: No event. nstc.c:2001: Test failed: Got event 7, count 0 nstc.c:2010: Test failed: Item not expanded. nstc.c:2030: Test failed: itemstate is 0x00000000 nstc.c:2080: Test succeeded inside todo block: Got event 6, count 0 nstc.c:2081: Test succeeded inside todo block: Got event 7, count 0 nstc.c:2082: Test succeeded inside todo block: Got event 12, count 0 nstc.c:2090: Test succeeded inside todo block: itemstate is 0x00000000 nstc.c:2163: Test failed: itemstate is 0x00000000 nstc.c:2216: Test failed: itemstate is 0x00000004 nstc.c:2228: Test failed: itemstate is 0x00000004 nstc.c:2283: Test failed: Got event 6, count 0 nstc.c:2284: Test failed: No event. nstc.c:2285: Test failed: Got event 7, count 0 nstc.c:2290: Test failed: Got (0x80004005) nstc.c:2291: Test failed: psi is (nil) make: *** [nstc.ok] Error 22 -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: d3d: avoid implicit conversion warnings from identical enumeration types D3DPOOL and WINED3DPOOL (Clang)
by Stefan Dösinger 16 May '11

16 May '11

On Friday 13 May 2011 15:03:35 Frédéric Delanoy wrote: > Adding d3dpool_from_wined3dpool and wined3dpool_from_d3dpool conversion > functions instead of direct casts seems overkill for such straightforward > conversions. I'm not quite sure about that patch. I sent a bunch of patches to add float<- >integer casts myself to silence some msvc warnings. WINED3DPOOL in the way it currently is will go away sooner or later when we transition to a d3d10-style resource model. Still the problem will remain with other structures and types.

3 4

Re: [Bug 27178] advapi32: CryptEnumProvidersW may don't free resources
by Juan Lang 15 May '11

15 May '11

You need to include your full name when sending a patch, patches from anonymous authors are not accepted. --Juan

1 0

winscard: Implement some functions of winscard.dll
by Juan Lang 15 May '11

15 May '11

Hi Sergey, #include "config.h" +#include <dlfcn.h> #include <stdarg.h> This change will cause compile failures on systems without this header. You need to add a configure check for the header, and include it conditionally. Thanks, --Juan

1 0

Re: [4/5] comctl32/treeview: Properly update image state index when TVS_CHECKBOXES is switched on
by Nikolay Sivov 15 May '11

15 May '11

On 5/15/2011 23:47, Nikolay Sivov wrote: > Naming is just ugly, especially since data structure got some binary > compatibility with native one (so it's not so wine* only now). > I'm sorry, duplicating subjects was unintentional. Please use 'Get rid of wine* prefixed names' as patch comment (as git commit in attached patch).

1 0

Re: usp10/tests: Add a '\n' to an ok() call.
by Marvin 15 May '11

15 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=10945 Your paranoid android. === WNT4WSSP6 (32 bit usp10) === usp10.c:1442: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 73 usp10.c:1408: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1420: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 87 usp10.c:1421: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 71 usp10.c:1429: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 87 usp10.c:1430: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 88 usp10.c:1440: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 87 usp10.c:1456: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 87 usp10.c:1458: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 86 === W2KPROSP4 (32 bit usp10) === usp10.c:1442: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 67 usp10.c:1408: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1420: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 81 usp10.c:1421: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 65 usp10.c:1429: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 81 usp10.c:1430: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 82 usp10.c:1440: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 81 usp10.c:1456: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 81 usp10.c:1458: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 80 === WXPPROSP3 (32 bit usp10) === usp10.c:1442: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 67 usp10.c:1408: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1420: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 81 usp10.c:1421: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 65 usp10.c:1429: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 81 usp10.c:1430: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 82 usp10.c:1440: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 81 usp10.c:1456: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 81 usp10.c:1458: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 80 === W2K3R2SESP2 (32 bit usp10) === usp10.c:1442: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 67 usp10.c:1408: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1420: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 81 usp10.c:1421: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 65 usp10.c:1429: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 81 usp10.c:1430: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 82 usp10.c:1440: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 81 usp10.c:1456: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 81 usp10.c:1458: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 80 === WVISTAADM (32 bit usp10) === usp10.c:1442: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 67 usp10.c:1408: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1420: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 81 usp10.c:1421: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 65 usp10.c:1429: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 81 usp10.c:1430: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 82 usp10.c:1440: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 81 usp10.c:1456: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 81 usp10.c:1458: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 80 === W2K8SE (32 bit usp10) === usp10.c:1442: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 67 usp10.c:1408: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1420: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 81 usp10.c:1421: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 65 usp10.c:1429: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 81 usp10.c:1430: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 82 usp10.c:1440: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 81 usp10.c:1456: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 81 usp10.c:1458: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 80 === W7PRO (32 bit usp10) === usp10.c:1442: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 67 usp10.c:1408: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1420: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 81 usp10.c:1421: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 65 usp10.c:1429: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 81 usp10.c:1430: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 82 usp10.c:1440: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 81 usp10.c:1456: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 81 usp10.c:1458: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 80 === W7PROX64 (32 bit usp10) === usp10.c:1442: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 67 usp10.c:1408: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1420: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 81 usp10.c:1421: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 65 usp10.c:1429: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 81 usp10.c:1430: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 82 usp10.c:1440: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 81 usp10.c:1456: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 81 usp10.c:1458: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 80

1 0

Re: ddraw/tests: Fix compilation on systems that don't support nameless unions.
by Marvin 15 May '11

15 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=10944 Your paranoid android. === W7PROX64 (64 bit ddrawmodes) === Timeout

1 0

Re: Question about ddraw implemtation
by Ralph Little 13 May '11

13 May '11

Hi, Further to my last post, I can confirm that the pixelformat structure is completely empty. A quick dump of the DDPIXELFORMAT structure shows that: ================================= trace:ddraw:PixelFormat_DD2WineD3D =========dwSize = 32, sizeof(32) trace:ddraw:PixelFormat_DD2WineD3D =========dwFlags = 0 trace:ddraw:PixelFormat_DD2WineD3D =========dwFourCC = 0 trace:ddraw:PixelFormat_DD2WineD3D =========dwRGBBitCount = 0 trace:ddraw:PixelFormat_DD2WineD3D =========dwRBitMask = 0 trace:ddraw:PixelFormat_DD2WineD3D =========dwGBitMask = 0 trace:ddraw:PixelFormat_DD2WineD3D =========dwBBitMask = 0 trace:ddraw:PixelFormat_DD2WineD3D =========dwRGBAlphaBitMask = 0 ================================= I don't know if this is a bug in the Sims that either: a) DDPIXELFORMAT is improperly filled in relying on some buggy behaviour in DirectDraw b) DDPIXELFORMAT is properly filled in for some default behaviour. c) DDSURFACEDESC2 is improperly defined with dwFlags & DDSD_PIXELFORMAT If anyone can try this out in (real) DirectDraw and let me know what happens that would be really cool. Cheers, Ralph

3 5

Re: [1/2] explorer: initialize COM
by Alexandre Julliard 13 May '11

13 May '11

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > Changelog: > * explorer: initialize COM > > Needed for the upcoming DDE patch to be able to create LNK files. You should do that only when necessary, there are very few things that need that DDE support. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 3/5] wininet: Clean up closing connection notifications tests
by Marvin 13 May '11

13 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=10918 Your paranoid android. === WVISTAADM (32 bit http) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation

1 0

Wine at LinuxTag 2011 - Driving a pun to far :)
by Marcus Meissner 13 May '11

13 May '11

Hi, I will be on LinuxTag 2011 tomorrow (Saturday) and together with Christian Boltz hold a lecture on Wine at 5pm. http://www.linuxtag.org/2011/de/program/freies-vortragsprogramm/popup/vortr… The talk will be on both beverage and the emulator, as Christian (also a openSUSE community member) is a real life Wine grower. The emulator part from me will be more on the light and fun side. :) (This also accounts that it is in the last slot in the conference program.) We did hold this talk at the openSUSE conference in Nuernberg already, including Wine tasting. Not sure if Christian has planned tasting this time ;) If someone wants to meet up on LT, just drop me a e-mail or just drop by the openSUSE booth tomorrow and query the folks where I am :) Ciao, Marcus

2 1

Curious parallel make issue with make_xftmpl
by Marcus Meissner 13 May '11

13 May '11

Hi, on large parallel in-tree builds I get this error occasionaly: ... ../tools/widl/widl -I. -I. -I../include -I../include -h -o wine/winedxgi.h wine/winedxgi.idl ../tools/widl/widl -m64 -I. -I. -I../include -I../include -t -o stdole2.tlb stdole2.idl gcc -DLDAP_DEPRECATED=1 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 ../tools/make_xftmpl.c -o ../tools/make_xftmpl ../tools/widl/widl -I. -I. -I../include -I../include -h -o docobjectservice.h docobjectservice.idl ../tools/widl/widl -I. -I. -I../include -I../include -h -o exdisp.h exdisp.idl gcc -c -I. -I. -I../include -I../include -I/usr/include/freetype2 -D__WINESRC__ -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -DLDAP_DEPRECATED=1 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o make_ctests.o make_ctests.c ../tools/make_xftmpl.c:21:20: fatal error: config.h: No such file or directory compilation terminated. make[1]: *** [../tools/make_xftmpl] Error 1 make[1]: *** Waiting for unfinished jobs.... gcc -c -I. -I. -I../include -I../include -I/usr/include/freetype2 -D__WINESRC__ -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -DLDAP_DEPRECATED=1 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o sfnt2fnt.o sfnt2fnt.c LC_ALL=C sed -e 's,@PACKAGE_STRING\@,Wine 1.3.19,g' ./wine.inf.in >wine.inf || (rm -f wine.inf && false) sed -e 's,@bindir\@,/usr/bin,g' ./wineapploader.in >wineapploader || (rm -f wineapploader && false) LC_ALL=C sed -e 's,@bindir\@,/usr/bin,g' -e 's,@dlldir\@,/usr/lib64/wine,g' -e 's,@PACKAGE_STRING\@,Wine 1.3.19,g' winemaker.man.in >winemaker.man || (rm -f winemaker.man && false) LC_ALL=C sed -e 's,@bindir\@,/usr/bin,g' -e 's,@dlldir\@,/usr/lib64/wine,g' -e 's,@PACKAGE_STRING\@,Wine 1.3.19,g' winemaker.de.man.in >winemaker.de.man || (rm -f winemaker.de.man && false) LC_ALL=C sed -e 's,@bindir\@,/usr/bin,g' -e 's,@dlldir\@,/usr/lib64/wine,g' -e 's,@PACKAGE_STRING\@,Wine 1.3.19,g' winemaker.fr.man.in >winemaker.fr.man || (rm -f winemaker.fr.man && false) gcc -DLDAP_DEPRECATED=1 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o make_ctests make_ctests.o gcc -DLDAP_DEPRECATED=1 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o fnt2fon fnt2fon.o ../libs/port/libwine_port.a gcc -DLDAP_DEPRECATED=1 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o fnt2bdf fnt2bdf.o ../libs/port/libwine_port.a gcc -DLDAP_DEPRECATED=1 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o make_xftmpl make_xftmpl.o ../libs/port/libwine_port.a make[1]: Leaving directory `/usr/src/packages/BUILD/wine-1.3.19.20110512/include' make: *** [include] Error 2 I *think* the include/ directory has a make_xftmpl build rule which is not passing the correct -I include paths, especially as make_xftmpl itself is also building in parallel in tools/. Ciao, Marcus

1 0

Question about ddraw implemtation
by Ralph Little 12 May '11

12 May '11

Hi, I have been looking into bug #9672 regarding a crash on startup of The Sims. Tracing through what is happening, the problem seems to be manifesting in the DirectDraw implementation. The Sims calls CreateSurface() with DDSD->dwFlags & DDSD_PIXELFORMAT set to state that a pixformat is specified in u4.ddpfPixelFormat, but no optional flags are set in the pixelformat u4.ddpfPixelFormat.dwFlags [DDPIXELFORMAT]. The function PixelFormat_DD2WineD3D uses this to determine the proper WINE3D pixformat implementation. It does not cope with what I presume is the default situation of no flags having been set, the value being 0. I'm thinking that if you provide 0 for u4.ddpfPixelFormat.dwFlags, you get some basic default, but I don't know what that would be. Certainly, The Sims seems to be providing zero for this parameter. Any ideas what is the proper behaviour in this circumstance? I presume the crash is the game's inability to handle the failure of the surface create gracefully. Here is the relevant trace fragment (with my bit of debug "pixelformat given, flags = 0" added): Cheers, Ralph ======================================= trace:ddraw:ddraw4_CreateSurface iface 0x139f0c, surface_desc 0x34f944, surface 0x34f9c0, outer_unknown (nil). trace:ddraw:CreateSurface ddraw 0x139f08, surface_desc 0x34f944, surface 0x34f9c0, outer_unknown (nil). trace:ddraw:CreateSurface (0x139f08) Requesting surface desc : trace:ddraw:DDRAW_dump_members - DDSD_CAPS : DDSCAPS_SYSTEMMEMORY DDSCAPS_ZBUFFER trace:ddraw:DDRAW_dump_members - DDSD_HEIGHT : 600 trace:ddraw:DDRAW_dump_members - DDSD_WIDTH : 800 trace:ddraw:DDRAW_dump_members - DDSD_PIXELFORMAT : ( ) warn:ddraw:CreateSurface pixelformat given, flags = 0 trace:ddraw:ddraw_create_surface ddraw 0x139f08, surface_desc 0x34f7ec, surface 0x34f8b4, level 0. trace:ddraw:ddraw_create_surface (0x139f08) Requesting surface desc : trace:ddraw:DDRAW_dump_members - DDSD_CAPS : DDSCAPS_SYSTEMMEMORY DDSCAPS_ZBUFFER trace:ddraw:DDRAW_dump_members - DDSD_HEIGHT : 600 trace:ddraw:DDRAW_dump_members - DDSD_WIDTH : 800 trace:ddraw:DDRAW_dump_members - DDSD_PIXELFORMAT : ( ) trace:ddraw:PixelFormat_DD2WineD3D Convert a DirectDraw Pixelformat to a WineD3D Pixelformat trace:ddraw:DDRAW_dump_pixelformat ( ) err:ddraw:PixelFormat_DD2WineD3D Unknown Pixelformat! (0) warn:ddraw:ddraw_surface_init Unsupported / unknown pixelformat. warn:ddraw:ddraw_create_surface Failed to initialize surface, hr 0x88760091. warn:ddraw:CreateSurface ddraw_create_surface failed, hr 0x88760091. err:seh:raise_exception Unhandled exception code c0000005 flags 0 addr 0xfffffffff

1 0

Re: ddraw: Fix filtering of enumerated display modes (try 4)
by Marvin 12 May '11

12 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=10886 Your paranoid android. === W7PROX64 (64 bit ddrawmodes) === Timeout

1 0

Re: ddraw: Fix filtering of enumerated display modes (try 3)
by Stefan Dösinger 12 May '11

12 May '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This patch looks OK to me Am 11.05.2011 um 10:03 schrieb Ričardas Barkauskas: > try 3: Non standard bit mask test added. More surface description and > pixel format flags tested and DDSD_REFRESHRATE filtering and appearance > in callback surface description fixed. It affects filtering even when > DDEDM_REFRESHRATES is not set. > > try 2: Removed pixel format printing. Fixed email address > > Ričardas Barkauskas > REalm > <0001-ddraw-Fix-filtering-of-enumerated-display-modes.txt> -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJNy5voAAoJEN0/YqbEcdMwDK8P/iRh2fXmfGB+DV6zgHd1QY+6 JBTDZdLpSRIhdeM6KI+CYxbdClOkg5IEw7HUVldc8N8WnGoO28oeaf+XlaDVTwIR 66PPzC6NI/Q/301Gx34aO17VNQpnUs8Q6ITQU5kmEzlCP1cL0Tt0VCQQt95RETbv zxs2IW26QCwoHEv7g9cO8MNoU3UYOFVdln6EONOvpNRZDuAxU+NChF5OPMUJsCmJ xbkNTkCdrwf6kyHbm1MQewIVcgmZu/8b+enhL6mDpHtwiVOgD8Blw9u7rvdjlZse h7qb9X4zbsgNUUpvC4B6M1cK1LAi5M5LEI5dyAPzkWFUNV2CDwyhagnaAxv4VHkg KcYH9rzUN4EAe9ctnMH633Q7NMo870KboZOOyThQdRaXRXosRGsaFQ6tHqkqbNlp u47OdATqZrTKlDWsAC9CNBV8+NsLat6wK6sDhLVKgRTJuL2gTcePmHS+hzQ5aIxA 8A+2avxZRGlzaBW7tC7hKt/jYV7NHemWzEZNn6mduNL/PysmT+43881AthlSLDhD aegYN6e1XECPnDfTNDP/XaGaObiUZgLb8MbmRzOTJDMSKt06Hgf+PSjIW9LW4w1j bYz1QABAV1Wmso1iYEYTh1vMEeXq9TRm0m1+w+CV/PEVsRNwz2XLsNzfCjLYcgMq zZDO1Seyq/e3PiCmf9hU =KEpe -----END PGP SIGNATURE-----

1 0

dsound: return success in IDirectSoundBufferImpl_AcquireResources
by Joerg-Cyril.Hoehle＠t-systems.com 11 May '11

11 May '11

Austin English wrote: - FIXME("(%p,%08u,%u,%p): stub\n",This,dwFlags,dwEffectsCount,pdwResultCodes); + FIXME("(%p,%08u,%u,%p): stub, faking success!\n",This,dwFlags,dwEffectsCount,pdwResultCodes); This is superfluous :-) "stub" is generally synonym with faking success. One lesson about apps - I tend to forget it myself - is that often enough they don't check every result and choose an alternative control path when some call fails, so better return success even thought it's a lie. Several bugs were fixed by returning the success value that apps would get on native, instead of returning the value that would be consistent with the specification and implementation state in Wine, e.g. NOTSUPPORTED, ERR_NOTIMPLEMENTED etc. I don't like that, but it helps. Often enough, the stub must fill part of the output parameters to prevent a crash later on. This remembers me to look at bug #17893 (needs amstream stub) again. Regards, Jörg Höhle

2 1

winealsa.drv/midi.c: Adds the midi MTC Quarter Frame messages support.
by Joerg-Cyril.Hoehle＠t-systems.com 11 May '11

11 May '11

Hi, well, I know little about MIDI and have no MIDI HW, yet what I read about the F1 code is that it is indeed a quarter time "tick" and takes 2 bytes, so the 2nd part of Stéphane Bacri's patch from last month looks good to me. The first half + toSend = ((ev->data.control.value & 0x7f) << 8) | MIDI_CMD_COMMON_MTC_QUARTER; looks ok too (by analogy with the surrounding code). One would argue that the existing shifts in midi.c would benefit from named constants too, http://source.winehq.org/source/dlls/winealsa.drv/midi.c#L365 MIDI_CMD_COMMON_SONG_SELECT 0xf3 MIDI_CMD_COMMON_SONG_POS 0xf2 http://www.alsa-project.org/alsa-doc/alsa-lib/group___m_i_d_i___commands.ht… Regards, Jörg Höhle

1 0

configure looking for prelink
by Claudio Fontana 11 May '11

11 May '11

Hello all, I noticed that wine's configure script looks for prelink using AC_PATH_PROG(PRELINK, prelink, false, [/sbin /usr/sbin $PATH]) I'd suggest changing it to AC_PATH_PROG(PRELINK, prelink, false, [/sbin /usr/sbin /usr/local/sbin $PATH]) to cover the case where the prelink package is built from source and installed in the default prefix (/usr/local). Thanks, Claudio Fontana

1 0

Re: msvcrt: Don't pass NULL as __ms_va_list in printf implementation
by Marcus Meissner 11 May '11

11 May '11

On Wed, May 11, 2011 at 12:20:51PM +0200, Piotr Caban wrote: > --- > dlls/msvcrt/printf.h | 2 +- > dlls/msvcrt/wcs.c | 4 ++-- > 2 files changed, 3 insertions(+), 3 deletions(-) > > > diff --git a/dlls/msvcrt/printf.h b/dlls/msvcrt/printf.h > index 64d159e..53f35bc 100644 > --- a/dlls/msvcrt/printf.h > +++ b/dlls/msvcrt/printf.h > @@ -607,7 +607,7 @@ static int FUNC_NAME(create_positional_ctx)(void *args_ctx, const APICHAR *forma > int i, j; > > i = FUNC_NAME(pf_printf)(FUNC_NAME(puts_clbk_str), &puts_ctx, format, NULL, TRUE, FALSE, > - arg_clbk_type, args_ctx, NULL); > + arg_clbk_type, args_ctx, valist); You should not process a va_list twice. You could va_copy() it to a second va_list if you need to do it twice. Ciao, Marcus

2 1

Re: [PATCH] riched20: Fixed some lParams with keycodes (Coverity)
by Marvin 11 May '11

11 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=10861 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: msvcrt: Don't pass NULL as __ms_va_list in printf implementation
by Marcus Meissner 11 May '11

11 May '11

On Wed, May 11, 2011 at 12:20:51PM +0200, Piotr Caban wrote: > --- > dlls/msvcrt/printf.h | 2 +- > dlls/msvcrt/wcs.c | 4 ++-- > 2 files changed, 3 insertions(+), 3 deletions(-) > > > diff --git a/dlls/msvcrt/printf.h b/dlls/msvcrt/printf.h > index 64d159e..53f35bc 100644 > --- a/dlls/msvcrt/printf.h > +++ b/dlls/msvcrt/printf.h > @@ -607,7 +607,7 @@ static int FUNC_NAME(create_positional_ctx)(void *args_ctx, const APICHAR *forma > int i, j; > > i = FUNC_NAME(pf_printf)(FUNC_NAME(puts_clbk_str), &puts_ctx, format, NULL, TRUE, FALSE, > - arg_clbk_type, args_ctx, NULL); > + arg_clbk_type, args_ctx, valist); You cannot use a valist twice. va_copy() before to a second one if you need the information twice. Ciao, Marcus

1 0

Re: urlmon: Code clean up and make tests a bit stricker
by Marvin 11 May '11

11 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=10855 Your paranoid android. === WVISTAADM (32 bit protocol) === protocol.c:2855: Test failed: Abort failed: 800c0200 === W7PROX64 (32 bit protocol) === protocol.c:965: Test failed: unexpected call ReportResult protocol.c:970: Test failed: hrResult = 00000000, expected: 80004004 protocol.c:2683: Test failed: Read failed: 00000001 === W7PROX64 (64 bit protocol) === protocol.c:965: Test failed: unexpected call ReportResult protocol.c:970: Test failed: hrResult = 00000000, expected: 80004004 protocol.c:2683: Test failed: Read failed: 00000001

1 0

Re: [PATCH 1/3] gdi32/tests: Test for font selection by full name.
by Grazvydas Ignotas 11 May '11

11 May '11

On Wed, May 11, 2011 at 12:08 AM, Grazvydas Ignotas <notasas(a)gmail.com> wrote: > To ensure correct font is selected, look in font name table directly. > --- > dlls/gdi32/tests/font.c | 143 +++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 143 insertions(+), 0 deletions(-) I unintentionally sent these patches twice, sorry about that. Please disregard the second copy. Gražvydas

1 0

Re: ddraw: Fix filtering of enumerated display modes (try 3)
by Marvin 11 May '11

11 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=10851 Your paranoid android. === W7PROX64 (64 bit ddrawmodes) === Timeout

1 0

__ms_va_list and NULL
by André Hentschel 10 May '11

10 May '11

Hi Piotr and folks, Most ARM crosscompilers (can't test with a native ARM one right now) don't like using NULL for a va_list and i'm not the only one seeing this issue. Piotr, i think that's your code, so maybe you can tell if it needs to be tuned or if that is a bug in the compiler (as the normal x86(_64) gcc works here). I hacked around that issue and attached the patch for documentation purpose, at least it compiles fine, don't know if it runs. without that patch: arm-linux-gnueabi-gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_MT -D_REENTRANT -fPIC -Wall -pipe -fno-strength-reduce -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -g -O2 -o wcs.o wcs.c In file included from wcs.c:38: printf.h: In function ‘create_positional_ctx_a’: printf.h:610: error: incompatible type for argument 9 of ‘pf_printf_a’ printf.h:338: note: expected ‘va_list’ but argument is of type ‘void *’ In file included from wcs.c:40: printf.h: In function ‘create_positional_ctx_w’: printf.h:610: error: incompatible type for argument 9 of ‘pf_printf_w’ printf.h:338: note: expected ‘va_list’ but argument is of type ‘void *’ wcs.c: In function ‘MSVCRT_vsprintf_p_l’: wcs.c:886: error: incompatible type for argument 9 of ‘pf_printf_a’ printf.h:338: note: expected ‘va_list’ but argument is of type ‘void *’ wcs.c: In function ‘MSVCRT_vswprintf_p_l’: wcs.c:940: error: incompatible type for argument 9 of ‘pf_printf_w’ printf.h:338: note: expected ‘va_list’ but argument is of type ‘void *’ make: *** [wcs.o] Fehler 1 -- diff --git a/dlls/msvcrt/printf.h b/dlls/msvcrt/printf.h index 64d159e..4267133 100644 --- a/dlls/msvcrt/printf.h +++ b/dlls/msvcrt/printf.h @@ -605,9 +605,10 @@ static int FUNC_NAME(create_positional_ctx)(void *args_ctx, const APICHAR *forma struct FUNC_NAME(_str_ctx) puts_ctx = {INT_MAX, NULL}; printf_arg *args = args_ctx; int i, j; + __ms_va_list empty = {0}; i = FUNC_NAME(pf_printf)(FUNC_NAME(puts_clbk_str), &puts_ctx, format, NULL, TRUE, FALSE, - arg_clbk_type, args_ctx, NULL); + arg_clbk_type, args_ctx, empty); if(i < 0) return i; diff --git a/dlls/msvcrt/wcs.c b/dlls/msvcrt/wcs.c index 2f2c140..f60cf75 100644 --- a/dlls/msvcrt/wcs.c +++ b/dlls/msvcrt/wcs.c @@ -870,6 +870,7 @@ int CDECL MSVCRT_vsprintf_p_l(char *buffer, MSVCRT_size_t length, const char *fo printf_arg args_ctx[MSVCRT__ARGMAX+1]; struct _str_ctx_a puts_ctx = {length, buffer}; int ret; + __ms_va_list empty = {0}; memset(args_ctx, 0, sizeof(args_ctx)); @@ -883,7 +884,7 @@ int CDECL MSVCRT_vsprintf_p_l(char *buffer, MSVCRT_size_t length, const char *fo arg_clbk_valist, NULL, args); else ret = pf_printf_a(puts_clbk_str_a, &puts_ctx, format, locale, TRUE, TRUE, - arg_clbk_positional, args_ctx, NULL); + arg_clbk_positional, args_ctx, empty); puts_clbk_str_a(&puts_ctx, 1, &nullbyte); return ret; @@ -924,6 +925,7 @@ int CDECL MSVCRT_vswprintf_p_l(MSVCRT_wchar_t *buffer, MSVCRT_size_t length, printf_arg args_ctx[MSVCRT__ARGMAX+1]; struct _str_ctx_w puts_ctx = {length, buffer}; int ret; + __ms_va_list empty = {0}; memset(args_ctx, 0, sizeof(args_ctx)); @@ -937,7 +939,7 @@ int CDECL MSVCRT_vswprintf_p_l(MSVCRT_wchar_t *buffer, MSVCRT_size_t length, arg_clbk_valist, NULL, args); else ret = pf_printf_w(puts_clbk_str_w, &puts_ctx, format, locale, TRUE, TRUE, - arg_clbk_positional, args_ctx, NULL); + arg_clbk_positional, args_ctx, empty); puts_clbk_str_w(&puts_ctx, 1, &nullbyte); return ret; -- Best Regards, André Hentschel

3 2

Re: [2/2] usp10/tests: test ScriptItemizeOpenType
by Marvin 10 May '11

10 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=10831 Your paranoid android. === WNT4WSSP6 (32 bit usp10) === usp10.c:1445: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 73 usp10.c:1411: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1423: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 87 usp10.c:1424: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 71 usp10.c:1432: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 87 usp10.c:1433: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 88 usp10.c:1443: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 87 usp10.c:1459: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 87 usp10.c:1461: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 86 === W2KPROSP4 (32 bit usp10) === usp10.c:1445: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 67 usp10.c:1411: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1423: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 81 usp10.c:1424: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 65 usp10.c:1432: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 81 usp10.c:1433: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 82 usp10.c:1443: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 81 usp10.c:1459: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 81 usp10.c:1461: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 80 === WXPPROSP3 (32 bit usp10) === usp10.c:1445: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 67 usp10.c:1411: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1423: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 81 usp10.c:1424: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 65 usp10.c:1432: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 81 usp10.c:1433: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 82 usp10.c:1443: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 81 usp10.c:1459: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 81 usp10.c:1461: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 80 === W2K3R2SESP2 (32 bit usp10) === usp10.c:1445: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 67 usp10.c:1411: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1423: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 81 usp10.c:1424: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 65 usp10.c:1432: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 81 usp10.c:1433: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 82 usp10.c:1443: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 81 usp10.c:1459: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 81 usp10.c:1461: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 80 === WVISTAADM (32 bit usp10) === usp10.c:1445: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 67 usp10.c:1411: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1423: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 81 usp10.c:1424: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 65 usp10.c:1432: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 81 usp10.c:1433: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 82 usp10.c:1443: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 81 usp10.c:1459: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 81 usp10.c:1461: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 80 === W2K8SE (32 bit usp10) === usp10.c:1445: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 67 usp10.c:1411: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1423: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 81 usp10.c:1424: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 65 usp10.c:1432: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 81 usp10.c:1433: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 82 usp10.c:1443: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 81 usp10.c:1459: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 81 usp10.c:1461: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 80 === W7PRO (32 bit usp10) === usp10.c:1445: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 67 usp10.c:1411: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1423: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 81 usp10.c:1424: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 65 usp10.c:1432: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 81 usp10.c:1433: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 82 usp10.c:1443: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 81 usp10.c:1459: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 81 usp10.c:1461: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 80 === W7PROX64 (32 bit usp10) === usp10.c:1445: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 67 usp10.c:1411: Test failed: Leading values should be after trialing for rtl chracters(6) usp10.c:1423: Test failed: ScriptStringXtoCP should return Ch = 6 not 5 for X = 81 usp10.c:1424: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 65 usp10.c:1432: Test failed: ScriptStringXtoCP should return Ch = 6 not 7 for X = 81 usp10.c:1433: Test failed: ScriptStringXtoCP should return iTrailing = 1 not 0 for X = 82 usp10.c:1443: Test failed: ScriptStringXtoCP should return Ch = 7 not 6 for X = 81 usp10.c:1459: Test failed: ScriptStringXtoCP should return Ch = 5 not 6 for X = 81 usp10.c:1461: Test failed: ScriptStringXtoCP should return iTrailing = 0 not 1 for X = 80

1 0

Re: [PATCH 1/2] mountmgr: Populate HKLM\HARDWARE\DEVICEMAP\Scsi here instead of in kernel32. (try 6)
by Alexandre Julliard 10 May '11

10 May '11

Charles Davis <cdavis(a)mymail.mines.edu> writes: > Try 6: Fix some problems noticed by Vitaliy Margolen. > Try 5: Get the value of "DeviceName" from mountmgr instead of making one up. > Try 4: Fix unused variable warning. > Try 3: Add support for IDE drives. > Try 2: Don't depend on the SCSI generic driver on Linux. > > --- > dlls/kernel32/Makefile.in | 1 - > dlls/kernel32/oldconfig.c | 404 ------------------------------------------ > dlls/kernel32/process.c | 3 - > dlls/mountmgr.sys/device.c | 192 ++++++++++++++++++++- > dlls/mountmgr.sys/diskarb.c | 2 +- > dlls/mountmgr.sys/hal.c | 207 +++++++++++++++++++++- > dlls/mountmgr.sys/mountmgr.c | 6 +- > dlls/mountmgr.sys/mountmgr.h | 37 ++++- > 8 files changed, 439 insertions(+), 413 deletions(-) > delete mode 100644 dlls/kernel32/oldconfig.c Now it's not setting DeviceName at all here. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [3/5] d3dx9: Implement D3DXMESHOPT_ATTRSORT|D3DXMESHOPT_IGNOREVERTS. (try 2)
by Alexandre Julliard 10 May '11

10 May '11

Dylan Smith <dylan.ah.smith(a)gmail.com> writes: > static HRESULT WINAPI ID3DXMeshImpl_OptimizeInplace(ID3DXMesh *iface, DWORD flags, CONST DWORD *adjacency_in, DWORD *adjacency_out, > DWORD *face_remap_out, LPD3DXBUFFER *vertex_remap_out) > { That function clearly needs to be split into several helpers. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: gdi32: Handle pre-Unicode symbol TTFs with symbols at U+00XX.
by Alexandre Julliard 10 May '11

10 May '11

"Konstantin L. Metlov" <metlov(a)fti.dn.ua> writes: > Commit 834378183ad2dffa84fab63b080c31241ac33cba handles the case when glyph is in the U+F0XX range differently > from the original patch. The commit (as I've just tested) does not fix the problem with special symbols in > KOMPAS 3D CAD, which original patch fixed. With this patch I propose to revert the changes of commit > 834378183ad2dffa84fab63b080c31241ac33cba and apply the original patch instead. The original patch was ugly. There's no reason to test for all the conditions twice. If my version doesn't fix your issue please address that without reintroducing the previous ugliness. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ddraw: Fix filtering of enumerated display modes by bits per pixel
by Stefan Dösinger 10 May '11

10 May '11

On Monday 09 May 2011 20:55:21 Ričardas Barkauskas wrote: > + modes16bpp_cnt = 0; > + U2(ddsd.ddpfPixelFormat).dwRBitMask = 0x0000; > + U3(ddsd.ddpfPixelFormat).dwGBitMask = 0x0000; > + U4(ddsd.ddpfPixelFormat).dwBBitMask = 0x0000; Please add an additional test that passes in non-null flags that don't match standard R5G6B5. > + if ((DDSD->dwFlags & DDSD_PIXELFORMAT) && (DDSD- >u4.ddpfPixelFormat.dwFlags & DDPF_RGB) ) > + if(pixelformat.u1.dwRGBBitCount != DDSD- >u4.ddpfPixelFormat.u1.dwRGBBitCount) continue; For the fun of it you could see what happens when you pass a non-RGB format(e.g. a DDPF_YUV or DDPF_BUMPDUDV one) to EnumPixelFormat, but that's not really a requirement for me. Afaics the DDPF_RGB check is needed anyway to enumerate 8 bit palettized formats properly. A YUV primary format may even make sense. A BUMPDUDV one not really.

2 2

Re: [PATCH try6] wininet: Added support for persistent HTTP connections
by Marvin 10 May '11

10 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=10825 Your paranoid android. === W7PROX64 (64 bit protocol) === protocol.c:972: Test failed: unexpected call ReportResult protocol.c:977: Test failed: hrResult = 00000000, expected: 80004004 protocol.c:2690: Test failed: Read failed: 00000001

1 0

Re: comctl32/listview: Make edit box handle available from LVN_ENDLABELEDIT notification
by Vitaliy Margolen 10 May '11

10 May '11

On 05/09/2011 01:09 AM, Nikolay Sivov wrote: > Fix for http://bugs.winehq.org/show_bug.cgi?id=25908 > There are 3 separate changes in this patch: > - BOOL bSame; > + BOOL same; Variable name rename. The actual fix with new test. > + ok(g_editbox_disp_info.item.pszText != NULL, "got %p\n", g_editbox_disp_info.item.pszText); Btw it's nice to print what did you expected back. > + ok(!IsWindow(hwndedit), "Expected Edit window to be freed\n"); I'm not so sure you can rely on system not allocating any more windows with the same handle. This is a race condition. > - /* WM_COMMAND with EN_KILLFOCUS isn't forwared to parent */ > + /* WM_COMMAND with EN_KILLFOCUS isn't forwarded to parent */ A typo fix. Vitaliy.

3 3

Re: kernel32: Implement CreateSymbolicLinkA/W by reusing a modified IoCreateSymbolicLink
by Vitaliy Margolen 10 May '11

10 May '11

On 05/09/2011 04:02 PM, André Hentschel wrote: > Also for http://bugs.winehq.org/show_bug.cgi?id=27108 I'm afraid that according to msdn kernel32's CreateSymbolicLink has absolutely nothing to do with ntdll's NtCreateSymbolicLinkObject. Other then similar name. The kernel32's creates file system symlinks (for files) and reparse points (for directories). Ntdll's NtCreateSymbolicLinkObject creates object manager's symlinks only. At leas in Wine they don't apply to file systems. Vitaliy.

1 0

Re: kernel32: Implement CreateSymbolicLinkA/W by reusing a modified IoCreateSymbolicLink
by Juan Lang 09 May '11

09 May '11

Hi André, + NtCreateSymbolicLinkObject( &handle, STANDARD_RIGHTS_REQUIRED | 0x1 /* SYMBOLIC_LINK_ALL_ACCESS */, + &attr, &targetstr ); + RtlFreeUnicodeString(&linkstr); + RtlFreeUnicodeString(&targetstr); + /* FIXME: store handle somewhere */ + return handle != INVALID_HANDLE_VALUE; Your fixme already indicates you need to do something different: you're introducing a handle leak. Since the caller has no access to it, what's its use? Simply close it. Also, rather than test the handle value, NtCreateSymbolicLinkObject already has a more direct way to return success: its return value. I'd suggest you use that instead. Finally, any reason you don't call CreateSymbolicLinkW from CreateSymbolicLinkA? This is the usual way we implement things, and avoids having to fix two places if one turns out to be incorrect. Thanks, --Juan

1 0

Re: ddraw: Fix filtering of enumerated display modes by bits per pixel
by Marvin 09 May '11

09 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=10820 Your paranoid android. === W7PROX64 (64 bit ddrawmodes) === Timeout

1 0

Re: [PATCH 1/2] mountmgr: Populate HKLM\HARDWARE\DEVICEMAP\Scsi here instead of in kernel32. (try 5)
by Vitaliy Margolen 09 May '11

09 May '11

On 05/09/2011 07:42 AM, Charles Davis wrote: > Try 5: Get the value of "DeviceName" from mountmgr instead of making one up. > Try 4: Fix unused variable warning. > Try 3: Add support for IDE drives. > Try 2: Don't depend on the SCSI generic driver on Linux. > - RtlCreateUnicodeStringFromAsciiz( &nameW, "FirstBusTimeScanInMs" ); > + static const WCHAR bus_scan_timeW[] = {'F','i','r','s','t','B','u','s','S','c','a','n','T','i','m','e','I','n','M','s',0}; These do not match. > > + if (devtype) > + { > + if (!(type = p_libhal_device_get_property_string( ctx, udi, "storage.drive_type",&error ))) > + *devtype = ~0; > + else if (!strcmp( type, "disk" ) || !strcmp( type, "floppy" )) > + *devtype = 0x00; > + else if (!strcmp( type, "tape" )) > + *devtype = 0x01; > + else if (!strcmp( type, "cdrom" )) > + *devtype = 0x05; > + else if (!strcmp( type, "raid" )) > + *devtype = 0x0C; > + else > + *devtype = ~0; > + } Please don't use magic numbers here. Also these numbers are wrong. From winbase.h: #define DRIVE_UNKNOWN 0 #define DRIVE_NO_ROOT_DIR 1 #define DRIVE_REMOVABLE 2 #define DRIVE_FIXED 3 #define DRIVE_REMOTE 4 /* Win32 additions */ #define DRIVE_CDROM 5 #define DRIVE_RAMDISK 6 Missing "DeviceName"="Cdrom0" for cdroms. Also names of devices do not match. This can potentially break some software: -"Identifier"="ATA Hitachi HDS72202JKAO" +"Identifier"="ATA Hitachi HDS72202" -"Identifier"="ATA WDC WD7500AAKS-030.0" +"Identifier"="ATA WDC WD7500AAKS-0" -"Identifier"="SAMSUNG DVDWBD SH-B083L SB01" +"Identifier"="SAMSUNG DVDWBD SH-B083L" Vitaliy.

2 1

Re: [PATCH try5] wininet: Added support for persistent HTTP connections
by Alexandre Julliard 09 May '11

09 May '11

Jacek Caban <jacek(a)codeweavers.com> writes: > + FreeLibrary(WININET_hModule); > + return ERROR_SUCCESS; It can still crash here. > +static void delayed_collect_connections(void) > +{ > + static const WCHAR wininet_dllW[] = {'w','i','n','i','n','e','t','.','d','l','l',0}; > + > + if(collector_running) > + return; > + > + if(!LoadLibraryW(wininet_dllW)) > + return; You probably don't want that inside the lock. Also GetModuleHandleEx is probably better. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH try5] wininet: Added support for persistent HTTP connections
by Marvin 09 May '11

09 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=10813 Your paranoid android. === W2K3R2SESP2 (32 bit protocol) === protocol.c:972: Test failed: unexpected call ReportResult protocol.c:977: Test failed: hrResult = 00000000, expected: 80004004 protocol.c:2690: Test failed: Read failed: 00000001

2 1

Re: audio: remove extraneous parentheses around equality comparisons
by Paul Chitescu 09 May '11

09 May '11

If you're at it can you move the variable at the right side of the comparison? if (((mr->msg_tosave + 1) % mr->ring_buffer_size) == mr->msg_toget)

1 0

Re: [PATCH] msi: Fixed check_flag_combo macro (Coverity)
by Alexandre Julliard 09 May '11

09 May '11

Marcus Meissner <meissner(a)suse.de> writes: > The macro was always FALSE, as > x & y == ~y > is always FALSE. x& y == y was clearly intended. > CID 1448 It doesn't work here: ../../../tools/runtest -q -P wine -M msi.dll -T ../../.. -p msi_test.exe.so action.c && touch action.ok action.c:5578: Test failed: Expected ERROR_SUCCESS, got 1627 action.c:5587: Test failed: Expected ERROR_FILE_NOT_FOUND, got 0 action.c:5599: Test failed: Expected ERROR_FILE_NOT_FOUND, got 0 action.c:5656: Test failed: key not created action.c:5660: Test failed: key not created action.c:5664: Test failed: key not created make: *** [action.ok] Error 6 -- Alexandre Julliard julliard(a)winehq.org

3 2

Re: [2/2] urlmon: Honor E_ABORT for URLDownloadToFile status callbacks
by Alexandre Julliard 09 May '11

09 May '11

Thomas Mullaly <thomas.mullaly(a)gmail.com> writes: > --- > dlls/urlmon/download.c | 27 +++++++++++++++-- > dlls/urlmon/tests/url.c | 74 ++++++++++++++++++++++++++++++++++++++++++++-- > 2 files changed, 94 insertions(+), 7 deletions(-) > From de69f682d1b11c3b23969ad02756162232ea9403 Mon Sep 17 00:00:00 2001 > From: Thomas Mullaly <tmullaly(a)codeweavers.com> > Date: Sun, 1 May 2011 00:30:17 -0400 > Subject: urlmon: Honor E_ABORT for URLDownloadToFile status callbacks It doesn't work here: ../../../tools/runtest -q -P wine -M qmgr.dll -T ../../.. -p qmgr_test.exe.so job.c && touch job.ok job.c:378: Test failed: Bad state: 4 job.c:378: Test failed: Bad state: 4 job.c:378: Test failed: Bad state: 4 job.c:378: Test failed: Bad state: 4 job.c:378: Test failed: Bad state: 4 job.c:378: Test failed: Bad state: 4 job.c:378: Test failed: Bad state: 4 job.c:378: Test failed: Bad state: 4 etc. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 9/9] mmdevapi/tests: Add tests for volume control interfaces
by Alexandre Julliard 09 May '11

09 May '11

Andrew Eikum <aeikum(a)codeweavers.com> writes: > --- > dlls/mmdevapi/tests/capture.c | 389 > ++++++++++++++++++++++++++++++++++++++ > dlls/mmdevapi/tests/render.c | 414 > +++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 803 insertions(+), 0 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M mmdevapi.dll -T ../../.. -p mmdevapi_test.exe.so capture.c && touch capture.ok capture.c:648: Test failed: Activation failed with 80004005 wine: Unhandled page fault on read access to 0x00000000 at address 0x68677fb5 (thread 0033), starting debugger... Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x68677fb5). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:68677fb5 ESP:0032fc30 EBP:0032fd38 EFLAGS:00010206( R- -- I - -P- ) EAX:00000000 EBX:6868915c ECX:0032fbe0 EDX:0032fce4 ESI:6868399a EDI:0032fcf8 Stack dump: 0x0032fc30: 00000000 686839a4 80004005 00000000 0x0032fc40: 0032fd14 00000000 00000000 00124b60 0x0032fc50: 0032fce4 7bc9ed90 0032fc78 7bc68211 0x0032fc60: 3d4ccccd 00000040 0032fca8 80004005 0x0032fc70: 9999999a 3fd99999 00000001 0032fce4 0x0032fc80: 3d4ccccd 00000017 00000000 7ffdf044 Backtrace: =>0 0x68677fb5 func_capture+0x8a5() [/home/julliard/wine/wine/dlls/mmdevapi/tests/capture.c:650] in mmdevapi_test (0x0032fd38) 1 0x6868287e run_test+0x14d(name="capture.c") [/home/julliard/wine/wine/dlls/mmdevapi/tests/../../../include/wine/test.h:556] in mmdevapi_test (0x0032fd88) 2 0x68683347 main+0x156(argc=0, argv=0x68677fb5) [/home/julliard/wine/wine/dlls/mmdevapi/tests/../../../include/wine/test.h:624] in mmdevapi_test (0x0032fe48) 3 0x6868351c __wine_spec_exe_entry+0x7b(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in mmdevapi_test (0x0032fe90) 4 0x7b8596cc call_process_entry+0xb() in kernel32 (0x0032fea8) 5 0x7b85a2ff start_process+0x5e(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/kernel32/process.c:1086] in kernel32 (0x0032fee8) 6 0x7bc73808 call_thread_func+0xb() in ntdll (0x0032fef8) 7 0x7bc76f6e call_thread_entry_point+0x6d(entry=0x7b85a2a0, arg=0x7ffdf000) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2499] in ntdll (0x0032ffc8) 8 0x7bc4c15e start_process+0x1d(kernel_start=0x7b85a2a0) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2612] in ntdll (0x0032ffe8) 9 0x6802998d wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) 0x68677fb5 func_capture+0x8a5 [/home/julliard/wine/wine/dlls/mmdevapi/tests/capture.c:650] in mmdevapi_test: movl 0x0(%eax),%ecx 650 hr = IAudioClient_Initialize(ac2, AUDCLNT_SHAREMODE_SHARED, -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Assorted spelling and case fixes.
by Marvin 09 May '11

09 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=10800 Your paranoid android. === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found

1 0

Re: winspool.drv: Add stubs for IsValidDevmodeW and IsValidDevmodeA.
by Marvin 09 May '11

09 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=10796 Your paranoid android. === WINEBUILD (build) === Can't determine base name

1 0

Re: ddraw: Add tests for SetCooperativeLevel
by Marvin 09 May '11

09 May '11

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 http://testbot.winehq.org/JobDetails.pl?Key=10792 Your paranoid android. === W7PROX64 (64 bit ddrawmodes) === Timeout

1 0

Re: [4/5] d3dx9: Implement D3DXMESHOPT_ATTRSORT vertex reordering.
by Matteo Bruni 08 May '11

08 May '11

2011/5/6 Dylan Smith <dylan.ah.smith(a)gmail.com>: > +struct vertex_attrib_duplication { > + DWORD attrib; > + DWORD vertex_index; > + struct vertex_attrib_duplication *ptr; > +}; ... > + struct vertex_attrib_duplication **heads = NULL; /* head of list for each vertex */ You probably want to use Wine lists (from include/wine/list.h) instead of your own implementation. > + heads = HeapAlloc(GetProcessHeap(), 0, This->numvertices * sizeof(*heads) + max_entries * sizeof(*duplications)); > + duplications = (struct vertex_attrib_duplication *)(heads + This->numvertices); I'm not sure why you are usually sticking together many arrays in a single allocation. Economizing on the number of HeapAllocs is not a great reason IMHO.

2 2

Re: [2/5] d3dx9: Implement D3DXMESHOPT_COMPACT for ID3DXMesh::OptimizeInplace.
by Matteo Bruni 08 May '11

08 May '11

2011/5/6 Dylan Smith <dylan.ah.smith(a)gmail.com>: ... > + new_vertex_buffer_size = This->numvertices; ... > + new_vertex_buffer_size *= vertex_size; > + hr = IDirect3DDevice9_CreateVertexBuffer(This->device, new_vertex_buffer_size, > + vertex_desc.Usage, This->fvf, vertex_desc.Pool, &vertex_buffer, NULL); ... + for (i = 0; i < new_num_vertices; i++) + CopyMemory(new_vertices + i * vertex_size, orig_vertices + vertex_remap_ptr[i] * vertex_size, vertex_size); Is this correct, i.e. should the new vertex buffer be big as much as the old one? I expected it to be just big enough to keep all the remaining vertices (new_num_vertices). Maybe this is so to match some native behavior?

2 1

Re: [1/5] d3dx9: Implement ID3DXMesh::CloneMesh without vertex buffer conversion.
by Matteo Bruni 08 May '11

08 May '11

2011/5/6 Dylan Smith <dylan.ah.smith(a)gmail.com>: > --- Just a couple of nitpicks: > + This->vertex_buffer->lpVtbl->AddRef(This->vertex_buffer); You should probably use the macros where they are around (D3D9 objects have them, as opposed to the mesh objects which don't for some strange reason). > + CopyMemory(data_out, data_in, This->numvertices * vertex_size); It's usually preferred to use memcpy(). I see that there are already a couple of uses of CopyMemory, in your previous patches, I didn't notice them...

1 0

Re: tools: Upgrade the config.guess/config.sub scripts
by Austin English 08 May '11

08 May '11

2011/5/7 André Hentschel <nerv(a)dawncrow.de>: > from git://git.sv.gnu.org/config.git without the whitespace changes > --- > tools/config.guess | 17 ++++++++++------- > tools/config.sub | 49 +++++++++++++++++++++++++++++++++++-------------- > 2 files changed, 45 insertions(+), 21 deletions(-) > > diff --git a/tools/config.guess b/tools/config.guess > index 4c8f032..1f28e79 100755 > --- a/tools/config.guess > +++ b/tools/config.guess > @@ -92,7 +92,7 @@ if test $# != 0; then > exit 1 > fi > > -trap 'exit 1' HUP INT TERM > +trap 'exit 1' 1 2 15 > > # CC_FOR_BUILD -- compiler used by this script. Note that the use of a > # compiler to aid in system detection is discouraged as it requires > @@ -106,7 +106,7 @@ trap 'exit 1' HUP INT TERM > > set_cc_for_build=' > trap "exitcode=\$?; (rm -f \$tmpfiles 2>/dev/null; rmdir \$tmp 2>/dev/null) && exit \$exitcode" 0 ; > -trap "rm -f \$tmpfiles 2>/dev/null; rmdir \$tmp 2>/dev/null; exit 1" HUP INT PIPE TERM ; > +trap "rm -f \$tmpfiles 2>/dev/null; rmdir \$tmp 2>/dev/null; exit 1" 1 2 13 15 ; > : ${TMPDIR=/tmp} ; > { tmp=`(umask 077 && mktemp -d "$TMPDIR/cgXXXXXX") 2>/dev/null` && test -n "$tmp" && test -d "$tmp" ; } || > { test -n "$RANDOM" && tmp=$TMPDIR/cg$$-$RANDOM && (umask 077 && mkdir $tmp) ; } || Looks like http://bugs.winehq.org/show_bug.cgi?id=16622 has re-emerged: http://git.savannah.gnu.org/gitweb/?p=config.git;a=commitdiff;h=2ec80f0dba7… -- -Austin

1 0

Re: riched20:tests Add conformance test for EM_FINDWORDBREAK function.
by André Hentschel 08 May '11

08 May '11

Am 08.05.2011 05:14, schrieb James McKenzie: > > + if (winetest_debug > 1) { > test_WM_CHAR(); > test_EM_FINDTEXT(); > test_EM_GETLINE(); > @@ -7090,6 +7368,8 @@ START_TEST( editor ) > test_WM_GETDLGCODE(); > test_zoom(); > test_dialogmode(); > + } > + test_EM_FINDWORDBREAK(); > Hi, i guess you didn't meant to include that in your patch. -- Best Regards, André Hentschel

2 1

Re: ntdll: Make RtlReAllocateHeap() preserve V-bit information when run under Valgrind
by Marcus Meissner 08 May '11

08 May '11

On Sat, May 07, 2011 at 06:33:08PM +0200, Bart Van Assche wrote: > Hello, > > A patch I submitted about five weeks ago had the status "Pending" on the patch status page during about four weeks. I can't see this patch anymore on the patch status page today. Anyone who can tell me what happened or which steps I should take next ? > > The patch itself can be found here: http://www.winehq.org/pipermail/wine-patches/2011-April/100570.html If you got no reply or indication on a patch within a week, you can consider it lost ;) To do then: - Ask yourself if the patch is good (tm) - Ask by e-mail or in IRC (#winehackers) on what could be improved with it. >From a brief look ... I think your patch seems to be doing more than one thing at once. Please seperate multiple changes into multiple small patches. Ciao, Marcus

1 0

RFC: doc for message contexts additions in PO files
by Frédéric Delanoy 08 May '11

08 May '11

Hi guys, I've put together the following doc for the introduction of message contexts. It's still a bit raw but I'd improve it for the wiki version. Could you please have a look and help proofread it? I'd like to ensure I didn't miss an important step. Thanks in advance. Frédéric Delanoy PS: BTW what is the reference version? en_US.po or en.po? ********* Adding one/more message contexts (ADD LINK TO EXTERNAL DOC) (QUICK MC EXPLANATION) Prerequisite: enable maintainer mode using ./configure --enable-maintainer-mode (you might have to add some development packages; check with your distribution for infos). 1. Locate strings to be "altered" Say you have in your localized po file: #: file1.rc:123 file2.rc:456 msgid "ambiguous word" msgstr "translation" and you want to disambiguate, you'd do the following 2. Find appropriate translations - check the respective rc entries (in file1.rc line 123) FOO "ambiguous word" (in file2.rc line 456) BAR "ambiguous word" and find their meaning/context (e.g. using some code browsing tools, like cscope to find references; running the program is recommanded, ...) 3. Add the messages contexts - The following syntax is used: "translation" -> "#msgctxt#your context#translation" - You end up with sthg like FOO "#msgctxt#context #ambiguous word#" Similarly BAR "#msgctxt#context 2#ambiguous word#" 3. Run 'make depend && make' 4. Edit your po file to add the new translations 5. Ideally, remove the "#, fuzzy" automatically inserted in the En_US.po reference file (and En.rc ). 6. Run 'make' again and test your changes.

2 1

Re: gdi32: Remove a set but unused variable
by Gerald Pfeifer 07 May '11

07 May '11

I admit I am surprised that Commit: 46988651d91fbea7f611287e5d8320239e72108d URL: http://source.winehq.org/git/wine.git/?a=commit;h=46988651d91fbea7f611287e5… Author: Nicolas Le Cam <niko.lecam at gmail.com> Date: Fri Apr 29 23:57:09 2011 +0200 gdi32: Remove a set but unused variable. has been applied, for I had proposed this very patch a year ago when Alexandre had rejected it with It seems pretty clear that it should be used, not removed. [ http://www.winehq.org/pipermail/wine-devel/2010-May/083517.html ] I tried to take that into account by updating the patch accordingly http://www.winehq.org/pipermail/wine-patches/2010-May/088317.html which, unexplicably to me, broke the tests so it was not applied: http://www.winehq.org/pipermail/wine-devel/2010-May/083850.html Now my original patch was re-submitted by Nicolas and applied. Was Alexandre's analysis incorrect in the original case, did he just fail to catch the mistake this time around, or is it something else? Gerald

1 0

Re: Jerome Leclanche : wine.desktop: Remove the nonexistent application/ x-win-lnk MIME type.
by Francois Gouget 07 May '11

07 May '11

On Thu, 5 May 2011, Alexandre Julliard wrote: > Module: wine > Branch: master > Commit: db03d247158ee44c06935b5e23fbf37485d8c8bf > URL: http://source.winehq.org/git/wine.git/?a=commit;h=db03d247158ee44c06935b5e2… > > Author: Jerome Leclanche <adys.wh(a)gmail.com> > Date: Wed May 4 19:01:33 2011 +0100 > > wine.desktop: Remove the nonexistent application/x-win-lnk MIME type. I'm not sure this patch is correct: on my Debian Testing machine application/x-win-lnk is defined in /usr/share/mime/packages/kde.xml which comes from the kdelibs5-data. I also found a reference to this package in the kdebase-runtime Fedora 11 runtime. So this MIME type may not be standard (heck it has the 'x-' prefix anyway) but KDE seems to know / be using it. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Research is the transformation of money to knowledge. Innovation is the transformation of knowledge to money. -- Dr. Hans Meixner

4 4

Huge frustration
by Roland Kaeser 07 May '11

07 May '11

Hello Please take the following not personal but the huge pent-up frustration constrains me to say a few words. I've just tested one of my "longest waiting" apps to get working on linux: CorelDraw X3/X4. And I had to see that it fails already with the same errors. I tooke a short look into the bug database to see all the related bugs: http://bugs.winehq.org/show_bug.cgi?id=11687 open (not even confirmed) since more than 3 years http://bugs.winehq.org/show_bug.cgi?id=14123 open since 2008-06-25 http://bugs.winehq.org/show_bug.cgi?id=3599 open (new) since 2005-10-15 http://bugs.winehq.org/show_bug.cgi?id=3611 open (new) since 2005-10-17 I know we had this discussion already a lot of times but after six acc. three years its time for me to say something again. I know also thats a lot more fun developing directx routines instead of fixing old bugs but sometimes You should also think about the "other" generality which uses the computer not just to play games. It would be understandeable to me if its written in the bug that the fix of this bug will consume a lot of resources and its impossible to fix this, but just to ignore it is not "the proper way to behave". I'm sure that there are many more of the above bugs which nobody has has ever took seriously a lock at it. Has anybody ever imagined how many apps depending on such bugs which prevents them to get running on Linux? Maybe all of the above bugs are only related to CorelDraw but its also possible that dozens or hundrets of other apps also fail with the same problems but nobody has ever wrote a bug report or saw it in the bug database and thought that it will be fixed cause its already reported? Just take a look at: http://www.inside-it.ch/frontend/insideit?_d=_article&site=ic&news.id=22515 English version: http://arstechnica.com/civis/viewtopic.php?f=14&t=1122655 The most of their problems where related to special windows apps running only in goverment institutions and where not able to run on Linux (wine). How many of these problems whould not even ever have been occured if such small bugs like the above whoud be fixed which makes all of those apps runnable on linux. Sorry to say that but Your politics just to develop things which makes fun or are interesting is also part of the above problem. Regards Roland

5 4

Re: [1/2] mmsystem.dll16: fix MCI_STATUS mapping for digitalvideo
by Damjan Jovanovic 06 May '11

06 May '11

On Thu, May 5, 2011 at 9:23 PM, Eric Pouech <eric.pouech(a)orange.fr> wrote: > Le 05/05/2011 15:30, Damjan Jovanovic a écrit : > > Changelog: > * mmsystem.dll16: fix MCI_STATUS mapping for digitalvideo > > Damjan Jovanovic > > > Hi Damjan, > > I wonder if storing the device type (or at least information to select the > two types of mapping) in the allocated structure for mapping instead of > calling for the device type at each unmap operation wouldn't be a preferable > solution > A+ > > -- > Eric Pouech Hi Eric It might be even more preferable to store the device type in a local variable. The allocated structure is way too complex already. Damjan Jovanovic

1 0

Re: [PATCH try4] wininet: Added support for persistent HTTP connections
by Alexandre Julliard 06 May '11

06 May '11

Jacek Caban <jacek(a)codeweavers.com> writes: > + /* FIXME: do the check also for SSL connections */ > + if(!netconn->useSSL) { > + res = NETCON_recv(netconn, &b, 1, MSG_PEEK|MSG_DONTWAIT, &len); > + if((res == ERROR_SUCCESS && len == 1) || res == WSAEWOULDBLOCK) > + break; This doesn't build with winsock (MSG_DONTWAIT is not defined). I'm also not sure what is the purpose of that check. If it's to check if remote has closed the connection, you need to do that by handling the error on the first send. -- Alexandre Julliard julliard(a)winehq.org

2 1

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