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

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

May 23, 2011

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 May 23, 2011

May 23, 2011

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 May 22, 2011

May 22, 2011

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 May 22, 2011

May 22, 2011

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 May 22, 2011

May 22, 2011

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 May 22, 2011

May 22, 2011

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 May 20, 2011

May 20, 2011

, 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 May 20, 2011

May 20, 2011

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 May 19, 2011

May 19, 2011

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 May 19, 2011

May 19, 2011

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 May 19, 2011

May 19, 2011

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 May 19, 2011

May 19, 2011

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 May 19, 2011

May 19, 2011

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 May 19, 2011

May 19, 2011

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 May 19, 2011

May 19, 2011

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 May 19, 2011

May 19, 2011

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 May 19, 2011

May 19, 2011

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 May 19, 2011

May 19, 2011

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 May 19, 2011

May 19, 2011

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 May 18, 2011

May 18, 2011

Please discard this patch. An updated version follows.

1 0

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

May 18, 2011

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 May 17, 2011

May 17, 2011

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 May 17, 2011

May 17, 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=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 May 17, 2011

May 17, 2011

Feedback please.

3 5

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

May 17, 2011

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 May 17, 2011

May 17, 2011

2 1

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

May 17, 2011

2 1

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

May 17, 2011

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 May 17, 2011

May 17, 2011

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 May 17, 2011

May 17, 2011

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 May 17, 2011

May 17, 2011

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 May 16, 2011

May 16, 2011

This popped up today, and prevented me from opening my program. susan(a)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(a)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 May 16, 2011

May 16, 2011

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 May 16, 2011

May 16, 2011

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 May 15, 2011

May 15, 2011

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 May 15, 2011

May 15, 2011

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 May 15, 2011

May 15, 2011

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 May 15, 2011

May 15, 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=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 May 15, 2011

May 15, 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=10944 Your paranoid android. === W7PROX64 (64 bit ddrawmodes) === Timeout

1 0

Re: Question about ddraw implemtation
by Ralph Little May 13, 2011

May 13, 2011

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 May 13, 2011

May 13, 2011

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 May 13, 2011

May 13, 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=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 May 13, 2011

May 13, 2011

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 May 13, 2011

May 13, 2011

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 May 12, 2011

May 12, 2011

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 May 12, 2011

May 12, 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=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 May 12, 2011

May 12, 2011

-----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 May 11, 2011

May 11, 2011

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 May 11, 2011

May 11, 2011

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 May 11, 2011

May 11, 2011

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 May 11, 2011

May 11, 2011

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 May 11, 2011

May 11, 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=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 May 11, 2011

May 11, 2011

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 May 11, 2011

May 11, 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=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 May 11, 2011

May 11, 2011

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 May 11, 2011

May 11, 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=10851 Your paranoid android. === W7PROX64 (64 bit ddrawmodes) === Timeout

1 0

__ms_va_list and NULL
by André Hentschel May 10, 2011

May 10, 2011

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 May 10, 2011

May 10, 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=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 May 10, 2011

May 10, 2011

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 May 10, 2011

May 10, 2011

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 May 10, 2011

May 10, 2011

"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 May 10, 2011

May 10, 2011

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 May 10, 2011

May 10, 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=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 May 10, 2011

May 10, 2011

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 May 10, 2011

May 10, 2011

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 May 9, 2011

May 9, 2011

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 May 9, 2011

May 9, 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=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 May 9, 2011

May 9, 2011

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 May 9, 2011

May 9, 2011

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 May 9, 2011

May 9, 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=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 May 9, 2011

May 9, 2011

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 May 9, 2011

May 9, 2011

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 May 9, 2011

May 9, 2011

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 May 9, 2011

May 9, 2011

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 May 9, 2011

May 9, 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=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 May 9, 2011

May 9, 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=10796 Your paranoid android. === WINEBUILD (build) === Can't determine base name

1 0

Re: ddraw: Add tests for SetCooperativeLevel
by Marvin May 9, 2011

May 9, 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=10792 Your paranoid android. === W7PROX64 (64 bit ddrawmodes) === Timeout

1 0

Re: [4/5] d3dx9: Implement D3DXMESHOPT_ATTRSORT vertex reordering.
by Matteo Bruni May 8, 2011

May 8, 2011

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 May 8, 2011

May 8, 2011

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 May 8, 2011

May 8, 2011

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 May 8, 2011

May 8, 2011

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 May 8, 2011

May 8, 2011

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 May 8, 2011

May 8, 2011

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 May 8, 2011

May 8, 2011

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 May 7, 2011

May 7, 2011

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 May 7, 2011

May 7, 2011

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 May 7, 2011

May 7, 2011

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 May 6, 2011

May 6, 2011

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 May 6, 2011

May 6, 2011

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

Re: [PATCH try4] wininet: Added support for persistent HTTP connections
by Alexandre Julliard May 6, 2011

May 6, 2011

Jacek Caban <jacek(a)codeweavers.com> writes: > try4: Check idle connection before using it in an attempt to catch > closed connection sooner, avoiding some request resends. It hopefully > fixes observed problem with tests. It does, but there's a new problem: it sometimes crashes in the collect_connections thread during the winhttp tests, because wininet has been unloaded while the thread is still running. Probably the thread needs to grab a library reference, though a collection mechanism that doesn't require a separate thread would be even better. I can still put the patch in for now, since the failure is not very frequent. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH try4] wininet: Added support for persistent HTTP connections
by Marvin May 6, 2011

May 6, 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=10757 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: po: Update French translation
by Nicolas Le Cam May 6, 2011

May 6, 2011

> #: regedit.rc:88 > -#, fuzzy > msgid "Modify Binary Data..." > -msgstr "Modifier les données &binaires" > +msgstr "Modifier les données &binaires..." I'm not sure you can add a keyboard accelerator if there isn't one in the original message. -- Nicolas Le Cam

2 3

winscard/tests: Add test base functions of winscard.dll
by Joerg-Cyril.Hoehle＠t-systems.com May 6, 2011

May 6, 2011

Sergey, >+ * Unit test suite for AVI Functions >+ * Copyright 2008 Detlef Riekenberg +#include "wingdi.h" >+#include "vfw.h" Please try and hide better the copy&paste origin of the code :-) >rezult result + ok(winscard_rezult != SCARD_F_INTERNAL_ERROR I recommend tests to be stricter, e.g. ok(result == SCARD_S_SUCCESS || result == SCARD_E_XYZ || broken(result == SCARD_E_...) Here's work done last year by Yauheni Baltouski and Aliaksei Hud. They are not working on winscard any more. I'd be pleased to eventually see winscard tests in Wine. Maybe you could merge this work? I *hope* I attached the latest version of the patch. If yes, it was verified last year to pass on: - native machines with and without card readers; - testbot, incl. w9x machines; - 64 bit? can't remember; - stock Linux (Ubuntu Lucid); - Linux with Mounir Idrassi's winscard dll (in which case the todo_wine succeed) and a card reader. It contains a good mixture of win_skip(), broken() and todo_wine to that effect. I had not submitted these tests in the past because IIRC there's still a resource leak (FreeLibrary following LoadLibrary; SCardFreeMemory following SCardListReaders AUTOALLOCATE) and some style issues (casts inside ok("%ld") formats) as well as IMHO too many redundant trace("testing X\n"), see $WINETEST_REPORT_SUCCESS. In their patch, LoadLibrary was necessary instead of a statically linked .exe because not all native systems provide winscard.dll Nowadays, successful tests on w9x are not considered important anymore, so this might be superfluous (but I don't know whether one can expect winscard on all machines since NT). +#ifndef SCARD_AUTOALLOCATE +#define SCARD_AUTOALLOCATE (DWORD)(-1) +#ifndef SCARD_SCOPE_USER +#define SCARD_SCOPE_USER 0x0000 was necessary because Wine's winscard.h does not yet provide enough definitions. -- Completing winscard.h would be a useful patch on its own. This test was considered the first of a series: small enough yet still doing something useful (ListReaders), but not yet depending on the presence of a chip card. Final comments on your initial patch: + mszReaders = malloc(cchReaders); HeapAlloc() is recommended in Wine, i.e. programming against the MS API. +START_TEST(winscard_api) Just name it winscard. Keep the name short because you use it on the command line. You don't initialize SCARD_READERSTATE as MSDN requires it for SCardGetStatusChange: "Important Each member of each structure in this array must be initialized to zero" and you don't check whether SCardListReaders returned at least one string in mszReaders for you to feed into SCardGetStatusChange. Regards, Jörg Höhle >From 3a936d8e0c100aee0da324d4d32e92368eefde88 Mon Sep 17 00:00:00 2001 From: Yauheni Baltouski <ybaltouski(a)gmail.com> Date: Tue, 29 Jun 2010 11:25:24 +0300 Subject: winscard/test: add initial test cases --- configure.ac | 1 + dlls/winscard/tests/Makefile.in | 11 +++ dlls/winscard/tests/scard.c | 180 +++++++++++++++++++++++++++++++++++++++ 3 files changed, 192 insertions(+), 0 deletions(-) create mode 100644 dlls/winscard/tests/Makefile.in create mode 100644 dlls/winscard/tests/scard.c diff --git a/configure.ac b/configure.ac index 61f376e..0309abc 100644 --- a/configure.ac +++ b/configure.ac @@ -2661,6 +2661,7 @@ WINE_CONFIG_TEST(dlls/winmm/tests) WINE_CONFIG_DLL(winnls.dll16,enable_win16) WINE_CONFIG_DLL(winnls32,,[winnls32]) WINE_CONFIG_DLL(winscard,,[winscard]) +WINE_CONFIG_TEST(dlls/winscard/tests) WINE_CONFIG_DLL(winsock.dll16,enable_win16) WINE_CONFIG_DLL(winspool.drv,,[winspool]) WINE_CONFIG_TEST(dlls/winspool.drv/tests) diff --git a/dlls/winscard/tests/Makefile.in b/dlls/winscard/tests/Makefile.in new file mode 100644 index 0000000..879481b --- /dev/null +++ b/dlls/winscard/tests/Makefile.in @@ -0,0 +1,11 @@ +TOPSRCDIR = @top_srcdir@ +TOPOBJDIR = ../../.. +SRCDIR = @srcdir@ +VPATH = @srcdir@ +TESTDLL = winscard.dll +IMPORTS = kernel32 ntdll + +C_SRCS = \ + scard.c + +(a)MAKE_TEST_RULES@ diff --git a/dlls/winscard/tests/scard.c b/dlls/winscard/tests/scard.c new file mode 100644 index 0000000..fd751c8 --- /dev/null +++ b/dlls/winscard/tests/scard.c @@ -0,0 +1,180 @@ +/* + * Unit tests for winscard.dll functions + * + * Copyright 2010 Yauheni S Baltouski + * + * + * 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 + */ + +#include <stdarg.h> +#include <stdio.h> + +#include "windef.h" +#include "winbase.h" +#include "winerror.h" +#include "winver.h" + +#include <winscard.h> +#include "wine/test.h" + +#ifndef SCARD_AUTOALLOCATE +#define SCARD_AUTOALLOCATE (DWORD)(-1) +#endif + +#ifndef SCARD_SCOPE_USER +#define SCARD_SCOPE_USER 0x0000 +#endif + +static const CHAR winscardDll[] = "winscard.dll"; + +static LONG (WINAPI *pSCardEstablishContext)(DWORD ,LPCVOID, LPCVOID, LPSCARDCONTEXT); +static LONG (WINAPI *pSCardReleaseContext)(SCARDCONTEXT); +static LONG (WINAPI *pSCardListReadersA)(SCARDCONTEXT,LPCSTR,LPSTR,LPDWORD); +static LONG (WINAPI *pSCardListReadersW)(SCARDCONTEXT,LPCSTR,LPSTR,LPDWORD); + +static SCARDCONTEXT hSC; +static LPTSTR szReaders; +static DWORD cchReaders = SCARD_AUTOALLOCATE; + +static void test_SCardEstablishContext(void) { + LONG lReturn; + + trace("testing SCardEstablishContext\n"); + + lReturn = pSCardEstablishContext(SCARD_SCOPE_USER, + NULL, + NULL, + &hSC); + todo_wine + { + ok((SCARD_S_SUCCESS==lReturn || broken(SCARD_E_NO_SERVICE==lReturn /*service disabled */)), + "can't execute SCardEstablishContext, SCardEstablishContext ptr = %p, return = %ld\n", + pSCardEstablishContext, + (long)lReturn); + } +} + +static void test_SCardReleaseContext(void) { + LONG lReturn; + + trace("testing SCardReleaseContext\n"); + if (hSC) { + + lReturn = pSCardReleaseContext(hSC); } + + todo_wine + { + ok(SCARD_S_SUCCESS==lReturn && hSC, + "can't execute SCardReleaseContext, SCardReleaseContext ptr = %p, SCARDCONTEXT=%lx, return=%ld\n", + pSCardReleaseContext, + (long int)hSC, + (long)lReturn); + } +} + +static void test_SCardListReadersA(void) { + LONG lReturn; + + trace("testing SCardListReadersA\n"); + if (hSC) { + + lReturn = pSCardListReadersA(hSC, + NULL, + (LPTSTR)&szReaders, + &cchReaders); } + + todo_wine + { + ok((lReturn == SCARD_S_SUCCESS || lReturn == SCARD_E_NO_READERS_AVAILABLE) && hSC, + "can't execute SCardListReadersA, SCardListReadersA ptr = %p, SCARDCONTEXT=%lx, return=%ld\n", + pSCardListReadersA, + (long int)hSC, + (long)lReturn); + } +} + +static void test_SCardListReadersW(void) { + LONG lReturn; + + trace("testing SCardListReadersW\n"); + if (hSC) { + + lReturn = pSCardListReadersW(hSC, + NULL, + (LPTSTR)&szReaders, + &cchReaders);} + + todo_wine + { + ok((lReturn == SCARD_S_SUCCESS || lReturn == SCARD_E_NO_READERS_AVAILABLE) && hSC, + "can't execute SCardListReadersW, SCardListReadersW ptr = %p, SCARDCONTEXT=%lx, return=%ld\n", + pSCardListReadersW, + (long int)hSC, + (long)lReturn); + } +} + +static BOOL init_winscard(void){ +#define GET_PROC(func) \ + (p ## func = (void *)GetProcAddress(module, #func)) + HMODULE module=NULL; + trace("testing winscard initialization\n"); + module = LoadLibraryA(winscardDll); + if (!module) + { + win_skip("No winscard.dll found - aborting"); + return FALSE; + } + else { + + trace("loading winscard SCardEstablishContext\n"); + GET_PROC(SCardEstablishContext); + todo_wine ok(pSCardEstablishContext!=NULL, "can't initialize winscard SCardEstablishContext, error=%lx\n", (long int)GetLastError()); + if (pSCardEstablishContext==NULL) return FALSE; + + trace("loading winscard SCardReleaseContext\n"); + GET_PROC(SCardReleaseContext); + todo_wine ok(pSCardReleaseContext!=NULL, "can't initialize winscard SCardReleaseContext, error=%lx\n", (long int)GetLastError()); + if (pSCardReleaseContext==NULL) return FALSE; + + trace("loading winscard SCardListReadersA\n"); + GET_PROC(SCardListReadersA); + todo_wine ok(pSCardListReadersA!=NULL, "can't initialize winscard SCardListReadersA, error=%lx\n", (long int)GetLastError()); + if (pSCardListReadersA==NULL) return FALSE; + + trace("loading winscard SCardListReadersW\n"); + GET_PROC(SCardListReadersW); + todo_wine ok(pSCardListReadersW!=NULL, "can't initialize winscard SCardListReadersW, error=%lx\n", (long int)GetLastError()); + if (pSCardListReadersW==NULL) return FALSE; + + return TRUE; + } +#undef GET_PROC +} + + +START_TEST(scard) +{ + if (init_winscard()) { + test_SCardEstablishContext(); + if (hSC) + { + test_SCardListReadersW(); + test_SCardListReadersA(); + test_SCardReleaseContext();/*must be at end of tests*/ + } + } +} -- 1.7.0.4

1 0

avicap32: fix build with recent kernel headers
by Rafał Mużyło May 6, 2011

May 6, 2011

Attached patch seems to fix build problem with recent kernel headers, where v4l1 was removed. I'm sending it here first (instead straight to wine-patches), as I have no real way of testing it - I only know it builds. As such, I haven't bothered yet with keeping consistant folding style. In case of any questions, CC me. PS.: qcap *might* need a similar, though far more complex fix.

2 1

Re: winscard/tests: Implement test for two functions of winscard.dll
by Marvin May 6, 2011

May 6, 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=10750 Your paranoid android. === WXPPROSP3 (32 bit winscard_api) === winscard_api.c:37: Test failed: Can't connect to pcscd daemon 8010001d winscard_api.c:39: Test failed: Error call SCardIsValidContext 6 === W2K3R2SESP2 (32 bit winscard_api) === winscard_api.c:37: Test failed: Can't connect to pcscd daemon 8010001d winscard_api.c:39: Test failed: Error call SCardIsValidContext 6 === WVISTAADM (32 bit winscard_api) === winscard_api.c:37: Test failed: Can't connect to pcscd daemon 8010001d winscard_api.c:39: Test failed: Error call SCardIsValidContext 6 === W2K8SE (32 bit winscard_api) === winscard_api.c:37: Test failed: Can't connect to pcscd daemon 8010001d winscard_api.c:39: Test failed: Error call SCardIsValidContext 6 === W7PRO (32 bit winscard_api) === winscard_api.c:37: Test failed: Can't connect to pcscd daemon 8010001d winscard_api.c:39: Test failed: Error call SCardIsValidContext 6

1 0

Re: winscard/tests: Implement test for two functions of winscard.dll
by Marvin May 6, 2011

May 6, 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=10749 Your paranoid android. === WXPPROSP3 (32 bit winscard_api) === winscard_api.c:37: Test failed: Can't connect to pcscd daemon 8010001d winscard_api.c:39: Test failed: Error call SCardIsValidContext 6 === W2K3R2SESP2 (32 bit winscard_api) === winscard_api.c:37: Test failed: Can't connect to pcscd daemon 8010001d winscard_api.c:39: Test failed: Error call SCardIsValidContext 6 === WVISTAADM (32 bit winscard_api) === winscard_api.c:37: Test failed: Can't connect to pcscd daemon 8010001d winscard_api.c:39: Test failed: Error call SCardIsValidContext 6 === W2K8SE (32 bit winscard_api) === winscard_api.c:37: Test failed: Can't connect to pcscd daemon 8010001d winscard_api.c:39: Test failed: Error call SCardIsValidContext 6 === W7PRO (32 bit winscard_api) === winscard_api.c:37: Test failed: Can't connect to pcscd daemon 8010001d winscard_api.c:39: Test failed: Error call SCardIsValidContext 6

1 0

Strange zero operation in dlls/riched20/tests/editor.c (Coverity)
by Marcus Meissner May 5, 2011

May 5, 2011

Hi Dylan, folks, Coverity sees following constructs in dlls/riched20/tests/editor.c introduced by your commit aa3b75f6b74fa87641b1f2b5912fbb82feb4c2da + SendMessage(hwndRichEdit, WM_CHAR, 22, + (MapVirtualKey('V', MAPVK_VK_TO_VSC) << 16) & 1); (several more of similar) The 4th argument is always 0 (because of (x<<16)&1). You added that Dylan, was perhaps |1 intended for a repeat count of 1? Ciao, Marcus

2 1

Re: [3/3] msxml3/domdoc: Add support for VT_ARRAY|VT_UI1 in domdoc_load(). (try 2)
by Nikolay Sivov May 5, 2011

May 5, 2011

On 5/5/2011 00:38, Adam Martinson wrote: > > Fixes bugs 14864 + 16453. > --- > dlls/msxml3/domdoc.c | 27 +++++++++++++ > dlls/msxml3/tests/domdoc.c | 94 > +++++++++++++++++++++++++++++++++++++++++++- > 2 files changed, 120 insertions(+), 1 deletions(-) > + case VT_ARRAY|VT_UI1: > + { > + SAFEARRAY *psa = V_ARRAY(&source); > + xmlChar *str; > + LONG len; > + UINT dim = SafeArrayGetDim(psa); > + > + switch (dim) > + { > + case 0: > + ERR("SAFEARRAY == NULL\n"); > + hr = E_INVALIDARG; > + break; > + case 1: > + /* Only takes UTF8 strings. > + * NOT NULL-terminated. */ > + SafeArrayAccessData(psa, (void**)&str); > + SafeArrayGetUBound(psa, 1,&len); > + hr = load_utf8(This, str, ++len, isSuccessful); > + SafeArrayUnaccessData(psa); > + break; > + default: > + FIXME("unhandled SAFEARRAY dim: %d\n", dim); > + hr = E_NOTIMPL; > + } > + } This could be simplified. SafeArrayGetUBound will fail for case 0 for example, and unhandled dimension should be WARN, IMO.

2 3

Re: [2/3] msxml3/domdoc: Add an internal function to load from a UTF8 string.
by Nikolay Sivov May 5, 2011

May 5, 2011

On 5/5/2011 00:38, Adam Martinson wrote: > --- > dlls/msxml3/domdoc.c | 85 > +++++++++++++++++++++++++++++-------------------- > 1 files changed, 50 insertions(+), 35 deletions(-) You don't need a separate helper for that. doparse() should do fine with "UTF-8" encoding parameter to force encoding. Also will it preserve existing document or will really create empty one on error is a question.

2 3

Re: cmd: WCMD_delete: simplify logic, avoid assigning variable to i tself (try 2)
by Alexandre Julliard May 5, 2011

May 5, 2011

Dan Kegel <dank(a)kegel.com> writes: > Simpler version suggested by Henri. > I'm hoping this is enough of an improvement to be worth it. It would be better to build a simple mask and test against that, instead of all that silliness with booleans. -- Alexandre Julliard julliard(a)winehq.org

1 0