April 2011 - Wine-Devel - list.winehq.org

Fix WineHQ bug #19762
by Joerg-Cyril.Hoehle＠t-systems.com April 29, 2011

April 29, 2011

Kai Wasserbäch wrote: >as bug #19762 is open for some time now, fully bisected, the solution applied for >several versions in my Debian packages ([0]) without reports about breakage, I >hearby propose the reversion of commit 67631163. http://bugs.winehq.org/show_bug.cgi?id=19762#c21 That commit is another example of a commit that introduced a regression while fixing another regression in another app. This does not prove that commit wrong, however, the burden is now on you (us) to prove it in order to change git. It's not an impossible task. Even code that seemed to be backed by tests in Wine was changed when the tests were proven wrong/incomplete. For a start, it may be worth testing that other app and see if it still needs that commit in current Wine. Does anybody know the bug number of that other app's original issue? Finally, are there any tests that support either behavior? Regards, Jörg Höhle

1 0

Re: Fix WineHQ bug #19762
by Henri Verbeet April 29, 2011

April 29, 2011

On 29 April 2011 12:29, Kai Wasserbäch <curan(a)debian.org> wrote: > several versions in my Debian packages ([0]) without reports about breakage, I > hearby propose the reversion of commit 67631163. Wylda tried to reach the I don't think reverting that commit is the right thing to do, it's just going to break something else instead.

1 0

Re: [1/5] wined3d: Add missing temporary variable declaration to ARB shader backend.
by Stefan Dösinger April 29, 2011

April 29, 2011

> + shader_addline(buffer, "TEMP TB;\n"); Which shader instruction uses this? Afair vertex shaders should only use TA, but there's no proper infrastructure that manages that.

2 2

Re: msvcrt: fix utime to correctly handle a NULL-pointer for the utimbuf structure field
by Marvin April 29, 2011

April 29, 2011

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=10627 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: po: Update French translation
by Nicolas Le Cam April 29, 2011

April 29, 2011

Hi Frédéric, Le 29 avril 2011 00:16, Frédéric Delanoy <frederic.delanoy(a)gmail.com> a écrit : > #: winerror.mc:441 > msgid "No more search handles\n" > -msgstr "Il n'y a plus de descripteurs de recherche\n" > +msgstr "Il n'y a plus de descripteur de recherche\n" This one isn't correct. There's not only one handle when available but many so it should take an 's' in the negative form too. Thanks for your work ! -- Nicolas Le Cam

2 1

Re: [2/5] wined3d: Remove rcp special handling of 0 from the ARB shader backend.
by Stefan Dösinger April 28, 2011

April 28, 2011

On Thursday 28 April 2011 00:34:24 Matteo Bruni wrote: > This should fix http://bugs.winehq.org/show_bug.cgi?id=26780 I see this patch was committed, I think I should really read wine-patches more often. I added the RCP 0 handling because StarCraft 2 needed it. Did you test this with SC2? Specifically, the Water was black without proper handling of rcp 0

1 0

Re: comctl32/tests: Remove practically unused parameters from test functions
by Vitaliy Margolen April 28, 2011

April 28, 2011

On 04/27/2011 01:14 AM, Nikolay Sivov wrote: > Remove practically unused parameters from test functions > So how is global variable any better then local variable passed as function parameter? IMHO this is s wrong thing to do - to move everything as global variables just to move it back whenever need arises. Vitaliy.

3 3

Re: include: Generate rmxftmpl.h from rmxftmpl.x using new build tool. (try 3)
by Austin English April 28, 2011

April 28, 2011

On Thu, Apr 28, 2011 at 14:52, Dylan Smith <dylan.ah.smith(a)gmail.com> wrote: > --- > Now using atexit function to cleanup up the output file on errors, and > parsing errors are signaled using a boolean error variable. > > diff --git a/include/rmxftmpl.x b/include/rmxftmpl.x > new file mode 100644 > index 0000000..e7144b0 > --- /dev/null > +++ b/include/rmxftmpl.x > @@ -0,0 +1,268 @@ > +xof 0302txt 0064 > +// Copyright (C) 2011 Dylan Smith > +// > +// This library is free software; you can redistribute it and/or > +// modify it under the terms of the GNU Lesser General Public > +// License as published by the Free Software Foundation; either > +// version 2.1 of the License, or (at your option) any later version. > +// > +// This library is distributed in the hope that it will be useful, > +// but WITHOUT ANY WARRANTY; without even the implied warranty of > +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > +// Lesser General Public License for more details. > +// > +// You should have received a copy of the GNU Lesser General Public > +// License along with this library; if not, write to the Free Software > +// Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA Looks like some C99 comments slipped in. -- -Austin

2 1

Re: include: Generate rmxftmpl.h from rmxftmpl.x using new build tool. (try 3)
by David Adam April 28, 2011

April 28, 2011

1 0

Re: [po]update korean resource
by Nikolay Sivov April 28, 2011

April 28, 2011

On 4/28/2011 13:25, Hwang YunSong(???) wrote: > updated > #: hhctrl.rc:73 > -#, fuzzy > -msgctxt "table of contents" > +msgctxt "????????+??? ?????????" > msgid "&Home" > -msgstr "???" > +msgstr "???(&H)" msgctxt is not a thing to translate as I understand it. It's an additional identifier to distinguish multiple translation variations.

1 0

Re: wined3d/state: Treat unrecognized D3DZBUFFERTYPEs as D3DZB_TRUE. (try 2)
by Henri Verbeet April 28, 2011

April 28, 2011

I'm not so convinced there's value in this, considering there are no known applications depending on this. Stefan thinks it's useful anyway. If you do want to spend the effort to make this go in, note that this affects ddraw and d3d8 as well, not just d3d9. The test should probably just have a loop in depth_buffer_test() itself, or even write a test specific for this purpose. The wined3d part might as well handle the state as a BOOL, considering WINED3DZB_USEW isn't handled all that different from WINED3DZB_TRUE, except for the FIXME.

3 2

Re: [4/5] wined3d: Fix pow handling with special values in ARB backend.
by Matteo Bruni April 28, 2011

April 28, 2011

Actually, this patch seems to break Bioshock with UseGLSL=disabled. Please drop/revert this one for the time being...

1 0

[Fwd: po files]
by Łukasz Wojniłowicz April 28, 2011

April 28, 2011

3 3

mmsystem: Improve 16 bit mapping for MCI_WHERE/PUT/FREEZE/UNFREEZE.
by Joerg-Cyril.Hoehle＠t-systems.com April 28, 2011

April 28, 2011

Hi, Damjan Jovanovic wrote: >In the meanwhile I've found another problem: mciavi32 always deadlocks >when MCI_WAIT is not set:[...] ShowWindow() Looks like bug #21060 and the others http://bugs.winehq.org/show_bug.cgi?id=21060#c2 - bug #12908, bug #15669, bug #18363 involving ShowWindow; - bug #14785, bug #21060 involving EnterCriticalSection. But perhaps there's only a single issue. It would be nice if somebody who knows about windows and their messages would look at these. Regards, Jörg Höhle

1 0

mmsystem: Improve 16 bit mapping for MCI_WHERE/PUT/FREEZE/UNFREEZE.
by Joerg-Cyril.Hoehle＠t-systems.com April 28, 2011

April 28, 2011

Damjan, can you recommend any downloadable 16bit app that stresses the MCI? It's good that you noticed that RECT16 and RECT do not have the same size (whack!). Yet I'm surprised that you left MCI_WINDOW untouched. I believe that the apps that use MCI_WHERE/PUT etc. (i.e. MCIAVI) are likely to use MCI_WINDOW as well to set the window handle. Does no FIXME appear in your console? http://source.winehq.org/source/dlls/mmsystem.dll16/mci16.c#L182 The comment there is obsolete. dwFlags is available and could be used like I did in db0df4c067fd6b701905aaef735c4729fca9d73f Regards, Jörg Höhle

2 1

Re: [PATCH 3/3] msvcrt: Updated spec file
by Alexandre Julliard April 28, 2011

April 28, 2011

Piotr Caban <piotr(a)codeweavers.com> writes: > +@ cdecl -arch=win32 __p___argc() > +@ cdecl -arch=win32 __p___argv() > +@ cdecl -arch=win32 __p___initenv() > +@ cdecl -arch=win32 __p___mb_cur_max() MSVCRT____mb_cur_max_func > +@ cdecl -arch=win32 __p___wargv() > +@ cdecl -arch=win32 __p___winitenv() > +@ cdecl -arch=win32 __p__acmdln() > +@ cdecl -arch=win32 __p__amblksiz() > +@ cdecl -arch=win32 __p__commode() > +@ cdecl -arch=win32 __p__daylight() MSVCRT___p__daylight > +@ cdecl -arch=win32 __p__dstbias() > +@ cdecl -arch=win32 __p__environ() > +@ stub -arch=win32 __p__fileinfo #() > +@ cdecl -arch=win32 __p__fmode() > +@ cdecl -arch=win32 __p__iob() MSVCRT___iob_func > +@ stub -arch=win32 __p__mbcasemap #() > +@ cdecl -arch=win32 __p__mbctype() > +@ cdecl -arch=win32 __p__osver() > +@ cdecl -arch=win32 __p__pctype() MSVCRT___pctype_func > +@ cdecl -arch=win32 __p__pgmptr() > +@ stub -arch=win32 __p__pwctype #() > +@ cdecl -arch=win32 __p__timezone() MSVCRT___p__timezone > +@ cdecl -arch=win32 __p__tzname() > +@ cdecl -arch=win32 __p__wcmdln() > +@ cdecl -arch=win32 __p__wenviron() > +@ cdecl -arch=win32 __p__winmajor() > +@ cdecl -arch=win32 __p__winminor() > +@ cdecl -arch=win32 __p__winver() > +@ cdecl -arch=win32 __p__wpgmptr() I just changed this the other way around recently. These are exported in at least some 64-bit versions. -- Alexandre Julliard julliard(a)winehq.org

1 0

[PATCH] Add undocumented function to unify MultiByteToWideChar conversation
by Alexey Fisher April 28, 2011

April 28, 2011

MultiByteToWideChar are called directly only from one function. All other colls in comctl32 go thrue this function. It was recovered with from dissassambled code. Signed-off-by: Alexey Fisher <bug-track(a)fisher-privat.net> --- dlls/comctl32/comctl32undoc.c | 41 +++++++++++++++++++++++++++++++++++++++++ 1 files changed, 41 insertions(+), 0 deletions(-) diff --git a/dlls/comctl32/comctl32undoc.c b/dlls/comctl32/comctl32undoc.c index ff94051..6eb6c0f 100644 --- a/dlls/comctl32/comctl32undoc.c +++ b/dlls/comctl32/comctl32undoc.c @@ -560,6 +560,47 @@ INT WINAPI AddMRUStringW(HANDLE hList, LPCWSTR lpszString) } /************************************************************************** + * comctl_MultiByteToWideChar (internal) + * Convert Multibyte string to WideChar string. + * + * PARAMS + * CodePage [I] COdepage of lpMultiByteStr + * lpMultiByteStr [I] multibyte string + * + * RETURNS + * Pointer to lpWideCharStr [O] or NULL if failed. Do not forget to + * Free the lpWideCharStr after use! + */ +LPWSTR comctl_MultiByteToWideChar(UINT CodePage, LPCSTR lpMultiByteStr) +{ + LPWSTR lpWideCharStr; + int len; + + if (lpMultiByteStr == NULL || lpMultiByteStr == -1) + return NULL; + + if (IsBadReadPtr(lpMultiByteStr, 1)) + return NULL; + + len = MultiByteToWideChar(CodePage, NULL, lpMultiByteStr, -1, NULL, NULL); + if (!len) + len = 1; + + lpWideCharStr = LocalAlloc(len * sizeof(WCHAR), 0); + if (!lpWideCharStr) + return NULL; + + if (!MultiByteToWideChar(CodePage, 1, lpMultiByteStr, -1, + lpWideCharStr, len)) { + LocalFree(lpWideCharStr); + lpWideCharStr = NULL; + return NULL; + } + + return lpWideCharStr; +} + +/************************************************************************** * AddMRUStringA [COMCTL32.153] * * See AddMRUStringW. -- 1.7.4.1

3 6

Re: infosoft/tests: COM cleanup in infosoft.c.
by Marvin April 27, 2011

April 27, 2011

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=10605 Your paranoid android. === WVISTAADM (32 bit infosoft) === infosoft.c:185: Test failed: failed infosoft.c:199: Test failed: failed === W2K8SE (32 bit infosoft) === infosoft.c:185: Test failed: failed infosoft.c:199: Test failed: failed === W7PRO (32 bit infosoft) === infosoft.c:185: Test failed: failed infosoft.c:199: Test failed: failed === W7PROX64 (32 bit infosoft) === infosoft.c:185: Test failed: failed infosoft.c:199: Test failed: failed === W7PROX64 (64 bit infosoft) === infosoft.c:185: Test failed: failed infosoft.c:199: Test failed: failed

2 1

Question on Conformance Test
by James McKenzie April 27, 2011

April 27, 2011

All: I am writing a conformance test for the richedit function EM_FINDWORDBREAK. I realize that WindowsNT 4.0 is our base configuration and most of the values process the same. However, a couple of values process differently for Windows NT 4.0/Windows2000, WindowsXP/Windows2003 and Windows Vista onward. What would be the BEST method of annotating this: Per the development guide: ok ( GetLastError() == WINXP_ERROR || GetLastError() == WINNT40_ERROR, ...); or: ok ( GetLastError() == WINXP_ERROR || Broken (GetLastError() == WINNT40_ERROR)); In other words, should I avoid the use of Broken() in this case, as the returned value is correct? Thank you. James McKenzie

3 2

Re: wined3d: Track when the FBO is dirty. (try 4)
by Adam Martinson April 27, 2011

April 27, 2011

On Tuesday 26 April 18:16:27 Henri Verbeet wrote: > This is mostly the same as the previous version. Yes, it's just rebased. I'm happy to change it however you see fit, but I need to know what you'd like changed and how.

1 0

winealsa.drv: Add mmdevapi driver.
by Joerg-Cyril.Hoehle＠t-systems.com April 27, 2011

April 27, 2011

Andrew, + fmt->Format.nSamplesPerSec = 41100; + fmt->nSamplesPerSec != 41100 && 44100. IIRC, there was an error exactly like this somewhere in the old drivers. But why does your IsFormatSupported only accept 48kHz, 44.1, 22.050, etc.? Do the native drivers behave like this? Is this a reasonable subset such that Wine behaves the same on most HW (disregarding CONTINUOUS_RATE)? dump_fmt + TRACE("cbSize: %u\n", fmt->cbSize); Old Wine code contains several comments about never ever reading cbSize in the WAVE_FORMAT_PCM case because it's a potential read past the structure and may cause a segmentation fault. Is it not a valid concern anymore? WAVEFORMATEX contains the cbSize slot. However if the winmm:wave* functions pass through their argument to mmdevapi, it may well end up to be the smaller PCMWAVEFORMAT only. IsFormatSupported MSDN says that CoTaskMemFree will be used to free the output variable ppClosestMatch. Wine uses clone_format=>HeapAlloc to allocate it. Does CoTaskMemFree match HeapAlloc? I'd have expected CoTaskMemAlloc, but I've never used these OLE functions. + switch(fmt->wBitsPerSample){ + case 64: + if(!snd_pcm_format_mask_test(formats, SND_PCM_FORMAT_FLOAT64_LE)){ vs. + if(fmt->wBitsPerSample != 32){ + WARN("Unsupported float size: %u\n", fmt->wBitsPerSample); IsFormatSupported may accept 64 bit fp samples, but Initialize will refuse it. Did you add that code to hear about sound cards that process 64 bits so we know they exist? Regards, Jörg Höhle

3 4

Re: wined3d: Track when the FBO is dirty. (try 4)
by Adam Martinson April 27, 2011

April 27, 2011

On Wednesday 27 Apr 2011 01:19:51 Stefan Dösinger wrote: > > > On Tuesday 26 April 2011 19:35:06 Adam Martinson wrote: > > - FIXME("Unrecognized D3DZBUFFERTYPE value %#x.\n", > > + WARN("treating unrecognized D3DZBUFFERTYPE value %#x as > WINED3DZB_TRUE.\n", > > stateblock->state.render_states[WINED3DRS_ZENABLE]); > > + /* falltrough */ > > + case WINED3DZB_TRUE: > Please provide a test for this. Will do, but this is for http://source.winehq.org/patches/data/73534 not http://source.winehq.org/patches/data/73533.

2 1

Re: wined3d: Track when the FBO is dirty. (try 4)
by Henri Verbeet April 27, 2011

April 27, 2011

This is mostly the same as the previous version.

2 1

Question on Conformance Test
by Joerg-Cyril.Hoehle＠t-systems.com April 27, 2011

April 27, 2011

Hi, James McKenzie wrote: >I realize that WindowsNT 4.0 is our base configuration IMHO that doesn't matter. Winecfg's default changed from w95 to w2k to xp while I was looking. >What would be the BEST method of annotating this: >ok ( GetLastError() == WINXP_ERROR || GetLastError() == WINNT40_ERROR, ...); >or: >ok ( GetLastError() == WINXP_ERROR || Broken (GetLastError() == WINNT40_ERROR)); You judge: - If you feel both results are quite logical, use ||. - I've used broken() to document which values Wine shall *not* return. That's IMHO an underestimated use of broken(). - OTOH, I've used || specifically when I thought Wine might/should perhaps change behavior in the future, such that no future patch would be needed to turn GetLastError() == WINXP_ERROR || broken(GetLastError() == WINNT40_ERROR) into broken(GetLastError() == WINXP_ERROR || GetLastError() == WINNT40_ERROR - ... which never prevented me from writing todo_wine ok(broken(NT.../*what Wine returns today*/) || XP /*what I want it to return*/, ... (rather than that, put broken last). Regards, Jörg Höhle

1 0

Re: wined3d: Track when the FBO is dirty. (try 4)
by Stefan Dösinger April 26, 2011

April 26, 2011

On Tuesday 26 April 2011 19:35:06 Adam Martinson wrote: > - FIXME("Unrecognized D3DZBUFFERTYPE value %#x.\n", > + WARN("treating unrecognized D3DZBUFFERTYPE value %#x as WINED3DZB_TRUE.\n", > stateblock->state.render_states[WINED3DRS_ZENABLE]); > + /* falltrough */ > + case WINED3DZB_TRUE: Please provide a test for this.

1 1