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

Re: [PATCH] winex11: Make GetCursorPos respect clipping and virtual screen size.

by Alexandre Julliard

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

May 18, 2011

Re: [PATCH] dinput: Move the c_df* data format constants to the dxguid static library, mark as hidden

by Alexandre Julliard

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

May 18, 2011

Re: [PATCH] winex11: Make GetCursorPos respect clipping and virtual screen size.

by Alexandre Julliard

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

May 18, 2011

Re: Ubuntu likely to abandon HAL next cycle -- is this workable?

by Detlef Riekenberg

Am Donnerstag, den 12.05.2011, 12:28 +0200 schrieb Scott Ritchie: > 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. I expect for Wine: udisk (current linux) | hal (for older linux and other os) http://bugs.winehq.org/show_bug.cgi?id=21713 -- By by ... Detlef

May 17, 2011

Re: [1/3]usp10/tests: add ScriptShapeOpenType tests mirroring ScriptShape tests

by Marvin

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

May 17, 2011

Re: Support for D3DQUERY_TIMESTAMP* queries...

by Adam Martinson

On 05/09/2011 10:03 AM, Henri Verbeet wrote: >> +static void test_timestamp_queries(IDirect3D9 *pD3d, HWND hwnd) > Please don't use names like pD3d, pDevice, etc. There's also still a > fair amount of inconsistencies in this patch. Most of the places I did that I did so to match the naming conventions in the rest of the file, I think I've got that cleaned up now. As for inconsistencies, I need something more specific... > Patch 7/12 just adds dead code. It also seems to me the way of > splitting the d3d9 and d3d10 disjoint queries is more complicated than > needed. The difference can be handled completely in d3d10, since > "ARB_TIMER_QUERY_FREQ" is just a constant that could easily just be > part of the wined3d interface. Ok, I've reworked things a bit. I removed the stuff for handling the d3d10 stuff, but I think this way it should be easy to handle inside d3d10 when we get there. Let me know what you think.

May 17, 2011

Re: hostname: Add an implementation of the hostname display utility.

by Andrew Nguyen

On 05/17/2011 11:07 AM, Juan Lang wrote: > 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 You're right, I should have considered the fact that hostname.exe is classed as a TCP/IP utility. I didn't snoop at the native executable's imports, however, because I figured it would be spying too closely at the utility's implementation details.

May 17, 2011

Re: hostname: Add an implementation of the hostname display utility.

by Juan Lang

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

May 17, 2011

Re: Regression in ioctl

by GOUJON Alexandre

On 05/17/2011 12:43 PM, Susan Cragin wrote: <snip> > I compile every git. So last compile was the day before this one. > However, I don't remember if I tried to run NatSpeak, so the error > might be as much as two days old? <snip> If something worked before and don't work anymore, it's a regression. Have a look at http://wiki.winehq.org/RegressionTesting. Strangely, I can't reach the page but anyway, GIYF and has always a cached copy. Thus, you'll find the exact culprit and thanks to AJ only accepting small patches, the regression *should* be easy to understand and fix.

May 17, 2011

Re: [1/10] taskmgr: Remove the debug channel dialog functionality.

by Andrew Nguyen

On 05/17/2011 09:01 AM, Alexandre Julliard wrote: > Andrew Nguyen <anguyen(a)codeweavers.com> writes: > >> --- >> programs/taskmgr/Da.rc | 11 -- >> programs/taskmgr/De.rc | 11 -- >> programs/taskmgr/En.rc | 11 -- >> programs/taskmgr/Fr.rc | 11 -- >> programs/taskmgr/He.rc | 12 -- >> programs/taskmgr/It.rc | 11 -- >> programs/taskmgr/Ja.rc | 11 -- >> programs/taskmgr/Ko.rc | 11 -- >> programs/taskmgr/Lt.rc | 11 -- >> programs/taskmgr/Makefile.in | 1 - >> programs/taskmgr/Nl.rc | 11 -- >> programs/taskmgr/No.rc | 11 -- >> programs/taskmgr/Pl.rc | 11 -- >> programs/taskmgr/Pt.rc | 11 -- >> programs/taskmgr/Ro.rc | 11 -- >> programs/taskmgr/Ru.rc | 11 -- >> programs/taskmgr/Si.rc | 11 -- >> programs/taskmgr/Sv.rc | 11 -- >> programs/taskmgr/Tr.rc | 11 -- >> programs/taskmgr/Uk.rc | 11 -- >> programs/taskmgr/Zh.rc | 22 --- >> programs/taskmgr/dbgchnl.c | 343 ------------------------------------------ >> programs/taskmgr/procpage.c | 3 - >> programs/taskmgr/resource.h | 8 - >> programs/taskmgr/taskmgr.c | 3 - >> programs/taskmgr/taskmgr.h | 3 - >> programs/taskmgr/taskmgr.rc | 8 - >> 27 files changed, 0 insertions(+), 601 deletions(-) >> delete mode 100644 programs/taskmgr/dbgchnl.c > > Why do you want to remove it? > I thought from cursory testing that the dialog functionality didn't actually work, but I can see from checking now that I am mistaken. I'll resend a patch that just does the same TCHAR macro changes to dbgchnl.c

May 17, 2011

Re: [1/10] taskmgr: Remove the debug channel dialog functionality.

by Alexandre Julliard

May 17, 2011

Re: Regression in ioctl

by Susan Cragin

May 17, 2011

Re: [PATCH] dinput: Mark internal symbols as hidden visibility

by Marcus Meissner

On Tue, May 17, 2011 at 08:51:23AM +0200, Marcus Meissner wrote: > On Mon, May 16, 2011 at 08:26:08PM -0600, Vitaliy Margolen wrote: > > 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. > > However, they are not exported via the .spec file, so they > will not get visible... > > How should they be exported? Is there a static library in Windows? I looked at this, and it should be: dinput.h should define the GUIDs when #define INITGUID is set. The export should be from dxguid.lib (this will automatically work once the defines are moved to dinput.h) Ciao, Marcus

May 17, 2011

Re: winemenubuilder: extract icons from NE binaries too

by Alexandre Julliard

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

May 17, 2011

Re: shell32: implement the progman DDE interface (try 2)

by Alexandre Julliard

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

May 17, 2011

Re: [PATCH] dinput: Mark internal symbols as hidden visibility

by Marcus Meissner

On Mon, May 16, 2011 at 08:26:08PM -0600, Vitaliy Margolen wrote: > 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. However, they are not exported via the .spec file, so they will not get visible... How should they be exported? Is there a static library in Windows? Ciao, Marcus

May 17, 2011

Re: Trailing white space and other pedantry.

by max

On 05/16/2011 09:39 PM, Ken Thomases wrote: > On May 16, 2011, at 7:42 PM, max wrote: >> On 05/16/2011 01:00 PM, André Hentschel wrote: >> >> I understand that white space only patches will not be applied. Will >> they be applied if they accompany other corrections? > If one would otherwise have modified a line in the course of doing development, then one can and should fix an issue like trailing whitespace on that line. If the line would not have been changed except for the whitespace issue, then it shouldn't be changed. > >> Also, please address the other questions. > Well, he might not have known the answer to or had an opinion about the other questions. > >> Should I submit patches against simple errors in macro definition >> formatting? There are some places where my program catches mismatches >> that SOME other compilers might ignore. >> >> There are also some places in the wine headers where macros are >> redefined differently from the headers provided by the system or >> compilers I have installed. There are also cases where the macros are >> defined differently by different wine headers. Because these problems >> may depend on my system configuration, I believe it might not be >> possible to simply patch these definitions match the configuration I >> have. The problems CAN be fixed simply by adding #undef before each >> redefinition, but I think a review of these changes might be in order. >> They seem to occur in batches, with none in most headers and multiple >> messes in others. > Am I understanding correctly that these are whitespace difference again? Maybe you could provide an example of what you mean. > > To my knowledge the mismatches you have identified have never actually caused problems. Until they do, I expect that fixes for them won't be accepted. Also, when they do, that will probably help guide which of your proposed solutions is preferred. FYI: Scanning (C) source file 'dlls/atl/atl_ax.c'. --Warning: Trailing white space at dlls/atl/atl_ax.c:991. --Warning: Trailing white space at dlls/atl/atl_ax.c:1005. --Warning: Trailing white space at dlls/atl/atl_ax.c:1027. --Warning: Trailing white space at dlls/atl/atl_ax.c:1042. --Warning: Trailing white space at dlls/atl/atl_ax.c:1131. --Warning: Trailing white space at dlls/atl/atl_ax.c:1141. --Warning: Trailing white space at dlls/atl/atl_ax.c:1245. Scanning (C) source file 'dlls/atl/registrar.c'. --Warning: Trailing white space at dlls/atl/registrar.c:206. --Warning: Trailing white space at dlls/atl/registrar.c:213. --Warning: Trailing white space at dlls/atl/registrar.c:243. --Warning: Trailing white space at dlls/atl/registrar.c:380. --Warning: Trailing white space at dlls/atl/registrar.c:525. --Warning: Trailing white space at dlls/atl/registrar.c:597. >> Should I submit each correction as a separate patch, separate patches >> accompanying separate bug reports, combined patches for a given header >> or combined patch and bug report? > Hard to say without an illustration of what you're talking about. In the simple cases, they would produce compiler warnings, not functional issues. In other cases, there are differences that I expect do not show up because the wine project does not use the macro, but could cause application programmers grief. For example: Scanning (C) source file 'dlls/advapi32/service.c'. ==Error: Attempt to change the definition of macro '__attribute__' at line 88 of include/wine/exception.h ignored. Originally defined at /usr/include/sys/cdefs.h:203 Old:' ( xyz ) ' New:' ( x ) ' Scanning (C) source file 'dlls/avicap32/avicap32_main.c'. ==Error: Attempt to change the definition of macro 'IOC_OUT' at line 697 of include/winsock.h ignored. Originally defined at /usr/include/asm-generic/ioctl.h:91 Old:' ( _IOC_READ << _IOC_DIRSHIFT ) ' New:' 1073741824 ' ==Error: Attempt to change the definition of macro 'IOC_IN' at line 698 of include/winsock.h ignored. Originally defined at /usr/include/asm-generic/ioctl.h:90 Old:' ( _IOC_WRITE << _IOC_DIRSHIFT ) ' New:' 2147483648 ' ==Error: Attempt to change the definition of macro 'IOC_INOUT' at line 699 of include/winsock.h ignored. Originally defined at /usr/include/asm-generic/ioctl.h:92 Old:' ( ( _IOC_WRITE | _IOC_READ ) << _IOC_DIRSHIFT ) ' New:' ( IOC_IN | IOC_OUT ) ' ==Error: Attempt to change the definition of macro '_IO' at line 701 of include/winsock.h ignored. Originally defined at /usr/include/asm-generic/ioctl.h:74 Old:' ( type , nr ) _IOC ( _IOC_NONE , ( type ) , ( nr ) , 0 ) ' New:' ( x , y ) ( IOC_VOID | ( ( x ) << 8 ) | ( y ) ) ' ==Error: Attempt to change the definition of macro '_IOR' at line 702 of include/winsock.h ignored. Originally defined at /usr/include/asm-generic/ioctl.h:75 Old:' ( type , nr , size ) _IOC ( _IOC_READ , ( type ) , ( nr ) , ( _IOC_TYPECHECK ( size ) ) ) ' New:' ( x , y , t ) ( IOC_OUT | ( ( ( UINT ) sizeof ( t ) & IOCPARM_MASK ) << 16 ) | ( ( x ) << 8 ) | ( y ) ) ' ==Error: Attempt to change the definition of macro '_IOW' at line 703 of include/winsock.h ignored. Originally defined at /usr/include/asm-generic/ioctl.h:76 Old:' ( type , nr , size ) _IOC ( _IOC_WRITE , ( type ) , ( nr ) , ( _IOC_TYPECHECK ( size ) ) ) ' New:' ( x , y , t ) ( IOC_IN | ( ( ( UINT ) sizeof ( t ) & IOCPARM_MASK ) << 16 ) | ( ( x ) << 8 ) | ( y ) ) ' Max

May 17, 2011

Re: [PATCH] dinput: Mark internal symbols as hidden visibility

by Vitaliy Margolen

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.

May 16, 2011

Re: Trailing white space and other pedantry.

by Ken Thomases

On May 16, 2011, at 7:42 PM, max wrote: > On 05/16/2011 01:00 PM, André Hentschel wrote: >> Am 16.05.2011 18:34, schrieb max(a)mtew.isa-geek.net: >>> 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? >>> >> No, white space only changes will not be accepted. >> Your are right about the preferred style, but most likely the regarding code is a bit old. >> new code should never have trailing white space. >> The best reason is "git blame" to see who wrote the code, i think that makes it clear. > > I understand that white space only patches will not be applied. Will > they be applied if they accompany other corrections? If one would otherwise have modified a line in the course of doing development, then one can and should fix an issue like trailing whitespace on that line. If the line would not have been changed except for the whitespace issue, then it shouldn't be changed. > Also, please address the other questions. Well, he might not have known the answer to or had an opinion about the other questions. > Should I submit patches against simple errors in macro definition > formatting? There are some places where my program catches mismatches > that SOME other compilers might ignore. > > There are also some places in the wine headers where macros are > redefined differently from the headers provided by the system or > compilers I have installed. There are also cases where the macros are > defined differently by different wine headers. Because these problems > may depend on my system configuration, I believe it might not be > possible to simply patch these definitions match the configuration I > have. The problems CAN be fixed simply by adding #undef before each > redefinition, but I think a review of these changes might be in order. > They seem to occur in batches, with none in most headers and multiple > messes in others. Am I understanding correctly that these are whitespace difference again? Maybe you could provide an example of what you mean. To my knowledge the mismatches you have identified have never actually caused problems. Until they do, I expect that fixes for them won't be accepted. Also, when they do, that will probably help guide which of your proposed solutions is preferred. > Should I submit each correction as a separate patch, separate patches > accompanying separate bug reports, combined patches for a given header > or combined patch and bug report? Hard to say without an illustration of what you're talking about. Regards, Ken

May 16, 2011

Re: Trailing white space and other pedantry.

by max

On 05/16/2011 01:00 PM, André Hentschel wrote: > Am 16.05.2011 18:34, schrieb max(a)mtew.isa-geek.net: >> 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? >> > No, white space only changes will not be accepted. > Your are right about the preferred style, but most likely the regarding code is a bit old. > new code should never have trailing white space. > The best reason is "git blame" to see who wrote the code, i think that makes it clear. I understand that white space only patches will not be applied. Will they be applied if they accompany other corrections? Also, please address the other questions. Should I submit patches against simple errors in macro definition formatting? There are some places where my program catches mismatches that SOME other compilers might ignore. There are also some places in the wine headers where macros are redefined differently from the headers provided by the system or compilers I have installed. There are also cases where the macros are defined differently by different wine headers. Because these problems may depend on my system configuration, I believe it might not be possible to simply patch these definitions match the configuration I have. The problems CAN be fixed simply by adding #undef before each redefinition, but I think a review of these changes might be in order. They seem to occur in batches, with none in most headers and multiple messes in others. Should I submit each correction as a separate patch, separate patches accompanying separate bug reports, combined patches for a given header or combined patch and bug report? Max

May 16, 2011

Re: Regression in ioctl

by André Hentschel

Am 16.05.2011 22:49, schrieb Susan Cragin: > 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? > Hi, When did you compiled the last time? yesterday or some month ago? -- Best Regards, André Hentschel

May 16, 2011

Regression in ioctl

by Susan Cragin

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?

May 16, 2011

Re: Trailing white space and other pedantry.

by André Hentschel

Am 16.05.2011 18:34, schrieb max(a)mtew.isa-geek.net: > 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? No, whitespace only changes will not be accepted. Your are right about the preferred style, but most likely the regarding code is a bit old. new code should never have trailing whitespace. The best reason is "git blame" to see who wrote the code, i think that makes it clear. -- Best Regards, André Hentschel

May 16, 2011

Trailing white space and other pedantry.

by max＠mtew.isa-geek.net

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

May 16, 2011

Re: [5/5] comctl32/treeview: Don't send TVN_ITEMEXPANDING when item has no children

by Nikolay Sivov

On Mon, May 16, 2011 at 2:11 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: > 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: Mmm, ok. I'll test this thing with native comctl32 too. > > ../../../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 ---- Bright side of it. > 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 > > >

May 16, 2011

Re: d3d: avoid implicit conversion warnings from identical enumeration types D3DPOOL and WINED3DPOOL (Clang)

by Henri Verbeet

2011/5/16 Frédéric Delanoy <frederic.delanoy(a)gmail.com>: > Is there in that case no point in getting rid of those warnings by > adding conversion functions between those related-but-not-identical > enums? > Well, in case of something like IDirect3DCubeTexture9Impl_GetType() there's no point in asking wined3d at all, the implementation should just be "return D3DRTYPE_CUBETEXTURE;". In case of something like IDirect3D9Impl_CheckDeviceFormat() we should have a conversion function.

May 16, 2011

Re: d3d: avoid implicit conversion warnings from identical enumeration types D3DPOOL and WINED3DPOOL (Clang)

by Frédéric Delanoy

2011/5/16 Henri Verbeet <hverbeet(a)gmail.com>: > 2011/5/16 Frédéric Delanoy <frederic.delanoy(a)gmail.com>: >> Indeed. I'm checking a couple of other automatic non-checked enum >> conversions, and those can be problematic; e.g. D3DRESOURCETYPE and >> WINED3DRESOURCETYPE are not identical but are autoconverted without >> any kind of check. >> > The resource type handling in e.g. d3d9 is really ugly, but should be > safe in practice. IDirect3DCubeTexture9Impl_GetType() should only ever > return D3DRTYPE_CUBETEXTURE for example. > Is there in that case no point in getting rid of those warnings by adding conversion functions between those related-but-not-identical enums? Couldn't this help detect invalid enum values quicker instead of passing them around unchecked? Frédéric Delanoy

May 16, 2011

Re: d3d: avoid implicit conversion warnings from identical enumeration types D3DPOOL and WINED3DPOOL (Clang)

by Henri Verbeet

2011/5/16 Frédéric Delanoy <frederic.delanoy(a)gmail.com>: > Indeed. I'm checking a couple of other automatic non-checked enum > conversions, and those can be problematic; e.g. D3DRESOURCETYPE and > WINED3DRESOURCETYPE are not identical but are autoconverted without > any kind of check. > The resource type handling in e.g. d3d9 is really ugly, but should be safe in practice. IDirect3DCubeTexture9Impl_GetType() should only ever return D3DRTYPE_CUBETEXTURE for example.

May 16, 2011

Re: [5/5] comctl32/treeview: Don't send TVN_ITEMEXPANDING when item has no children

by Alexandre Julliard

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

May 16, 2011

Re: d3d: avoid implicit conversion warnings from identical enumeration types D3DPOOL and WINED3DPOOL (Clang)

by Frédéric Delanoy

2011/5/16 Stefan Dösinger <stefandoesinger(a)gmx.at>: > 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. Well there's no loss of precision/type change in this patch. Those are still plain (integer) enums. However, I can understand casting may be risky if one of the enum structures changes, but again it's not like there was some kind of "value validity checking" earlier. > Still the problem will remain with other structures and types. Indeed. I'm checking a couple of other automatic non-checked enum conversions, and those can be problematic; e.g. D3DRESOURCETYPE and WINED3DRESOURCETYPE are not identical but are autoconverted without any kind of check. Say you have enum A { A_FOO, A_BAR, A_BAZ } and enum B { B_FOO, B_BAR } How are you supposed to convert 'enum A' BAZ to 'enum B'? Probably issueing a fixme in the default clause, but then what would be a default return value? enum B B_from_A(elem) { switch( case A_FOO: return B_FOO; case A_BAR: return B_BAR; default: FIXME("Unhandled elem type %#x.\n", elem); return ??? } } Some enums, like D3DFORMAT specify a D3DFMT_UNKNOWN as first (0 valued) first enum value, which is returned in the "default" cause as well. Is this the way it should be done? a standard in wine coding? i.e. should previous example be changed to: enum A { A_UNKNOWN, A_FOO, A_BAR, A_BAZ } enum B { B_UNKNOWN, B_FOO, B_BAR } enum B B_from_A(elem) { switch( case A_FOO: return B_FOO; case A_BAR: return B_BAR; default: FIXME("Unhandled elem type %#x.\n", elem); return B_UNKNOWN; } } If it isn't a standard in wine, would that be a viable solution? Frédéric

May 16, 2011

Re: d3d: avoid implicit conversion warnings from identical enumeration types D3DPOOL and WINED3DPOOL (Clang)

by Stefan Dösinger

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.

May 16, 2011

Re: [Bug 27178] advapi32: CryptEnumProvidersW may don't free resources

by Juan Lang

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

May 15, 2011

winscard: Implement some functions of winscard.dll

by Juan Lang

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

May 15, 2011

Re: [4/5] comctl32/treeview: Properly update image state index when TVS_CHECKBOXES is switched on

by Nikolay Sivov

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

May 15, 2011

Re: usp10/tests: Add a '\n' to an ok() call.

by Marvin

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

May 15, 2011

Re: ddraw/tests: Fix compilation on systems that don't support nameless unions.

by Marvin

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

May 15, 2011

Re: Question about ddraw implemtation

by Ralph Little

Hi, On 11-05-13 10:15 AM, Henri Verbeet wrote: > On 13 May 2011 19:03, Ralph Little<littlesincanada(a)yahoo.co.uk> wrote: >> trace:ddraw:CreateSurface DDSURF==== dwFlags(124) > Is that correct? It doesn't have DDSD_PIXELFORMAT set. > No scrap that last message, my original trace was incorrect. A typo meant I was outputting the size, not the flags :( The flags are actually 4103 which includes DDSD_PIXELFORMAT. Back to the original situation. So, what is happening is that the caller is specifying DDSD_PIXELFORMAT but there is nothing in the DDPIXELFORMAT structure to indicate how to render. However, the surface pointer is NULL so there is nothing to actually draw. I added some code to test the PIXELFORMAT structure and if didn't like what it found, it inserted the default. It gets a lot further but crashes later on. I will try and find out what is happening then. Cheers, Ralph

May 13, 2011

Re: Question about ddraw implemtation

by Ralph Little

Hi, > On 13 May 2011 19:03, Ralph Little<littlesincanada(a)yahoo.co.uk> wrote: >> trace:ddraw:CreateSurface DDSURF==== dwFlags(124) > Is that correct? It doesn't have DDSD_PIXELFORMAT set. > Wait, you're right. I misread what the code was doing. /* No pixelformat given? Use the current screen format */ if(!(desc2.dwFlags & DDSD_PIXELFORMAT)) { WARN("No pixelformat given\n"); desc2.dwFlags |= DDSD_PIXELFORMAT; desc2.u4.ddpfPixelFormat.dwSize=sizeof(DDPIXELFORMAT); It sees that there is no pixelformat specified, then tries to fill one in. Here: else { WARN("pixformat=default\n"); PixelFormat_WineD3DtoDD(&desc2.u4.ddpfPixelFormat, Mode.Format); } it calls the function PixelFormat_WineD3DtoDD() to determine the format details, assuming that there is something in ddpfPixelFormat worth looking at. In this case, it is wrong. With the surface ptr. being NULL, I suspect that all talk of pixelformat is moot in this case. There are no pixels to render. I really do wonder if this is a "trick" to blank the screen. Cheers, Ralph

May 13, 2011

Re: Question about ddraw implemtation

by Henri Verbeet

On 13 May 2011 19:03, Ralph Little <littlesincanada(a)yahoo.co.uk> wrote: > trace:ddraw:CreateSurface DDSURF==== dwFlags(124) Is that correct? It doesn't have DDSD_PIXELFORMAT set.

May 13, 2011

Re: Question about ddraw implemtation

by Ralph Little

Hi, On 11-05-13 03:33 AM, Stefan Dösinger wrote: > On Friday 13 May 2011 01:36:09 Ralph Little wrote: >> 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: > Can you show us the entire DDSURFACEDESC2 structure OK, here it is: ================================ trace:ddraw:CreateSurface DDSURF==== dwSize(124) sizeof DDSURFACEDESC(108) sizeof DDSURFACEDESC2(124) trace:ddraw:CreateSurface DDSURF==== dwFlags(124) trace:ddraw:CreateSurface DDSURF==== dwHeight(600) trace:ddraw:CreateSurface DDSURF==== dwWidth(800) trace:ddraw:CreateSurface DDSURF==== u1.lPitch(0) trace:ddraw:CreateSurface DDSURF==== u1.dwLinearSize(0) trace:ddraw:CreateSurface DDSURF==== dwBackBufferCount/dwDepth(0) trace:ddraw:CreateSurface DDSURF==== u2.dwMipMapCount/dwRefreshRate/dwSrcVBHandle(0) trace:ddraw:CreateSurface DDSURF==== dwAlphaBitDepth(0) trace:ddraw:CreateSurface DDSURF==== dwReserved(0) trace:ddraw:CreateSurface DDSURF==== lpSurface((nil)) trace:ddraw:CreateSurface DDSURF==== u3.dwEmptyFaceColor(0) trace:ddraw:CreateSurface DDSURF==== u3.ddckCKDestOverlay.dwColorSpaceLowValue(0) trace:ddraw:CreateSurface DDSURF==== u3.ddckCKDestOverlay.dwColorSpaceHighValue(0) trace:ddraw:CreateSurface DDSURF==== ddckCKDestBlt.dwColorSpaceLowValue(0) trace:ddraw:CreateSurface DDSURF==== ddckCKDestBlt.dwColorSpaceHighValue(0) trace:ddraw:CreateSurface DDSURF==== ddckCKSrcOverlay.dwColorSpaceLowValue(0) trace:ddraw:CreateSurface DDSURF==== ddckCKSrcOverlay.dwColorSpaceHighValue(0) trace:ddraw:CreateSurface DDSURF==== ddckCKSrcBlt.dwColorSpaceLowValue(0) trace:ddraw:CreateSurface DDSURF==== ddckCKSrcBlt.dwColorSpaceHighValue(0) trace:ddraw:CreateSurface DDSURF==== u4.dwFVF(32) trace:ddraw:CreateSurface DDSURF==== ddsCaps.dwCaps(133120) trace:ddraw:CreateSurface DDSURF==== ddsCaps.dwCaps2(0) trace:ddraw:CreateSurface DDSURF==== ddsCaps.dwCaps3(0) trace:ddraw:CreateSurface DDSURF==== ddsCaps.dwCaps4(0) trace:ddraw:CreateSurface DDSURF==== dwTextureStage(0) =============================================== I notice that the Wine definition of DDSURFACEDESC2 does not include the second union shown here: http://msdn.microsoft.com/en-us/library/ff550340%28VS.85%29.aspx which is a union of dwBackBufferCount/dwDepth. I think it likely that it is a whole-screen surface (800x600) so your assertion that it will use the default pixel format for the display is probably right. Interestingly, the surface pointer is NULL. Any ideas what this surface is trying to accomplish? Is it merely an attempt to blank the screen with no content? Cheers, Ralph

May 13, 2011

Re: [1/2] explorer: initialize COM

by Alexandre Julliard

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

May 13, 2011

Re: [PATCH 3/5] wininet: Clean up closing connection notifications tests

by Marvin

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

May 13, 2011

Re: Question about ddraw implemtation

by Stefan Dösinger

On Friday 13 May 2011 01:36:09 Ralph Little wrote: > 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: Can you show us the entire DDSURFACEDESC2 structure? > b) DDPIXELFORMAT is properly filled in for some default behaviour. That's most likely, although there is no sensible default for this. We don't even know if the app wants a RGB surface, a Paletteindexed surface, a YUV surface etc. Probably Windows creates a surface with the format of the primary surface. I think this is what happens when the app doesn't specify DDSD_PIXELFORMAT in the DDSURFACEDESC2. > If anyone can try this out in (real) DirectDraw and let me know what > happens that would be really cool. See dlls/ddraw/tests/dsurface.c. If you don't have a Windows machine to run tests yourself you can either use winetestbot or ask someone to run it for you on #winehackers. The latter is recommended because winetestbot uses VMs only. There is basic ddraw support in those VMs(VMware), but it may be different from real GPUs.

May 13, 2011

Re: Wine at LinuxTag 2011 - Driving a pun to far :)

by Wolfram Sang

I'll be there as well, giving a kernel talk at 11am.

May 13, 2011

Wine at LinuxTag 2011 - Driving a pun to far :)

by Marcus Meissner

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

May 13, 2011

Curious parallel make issue with make_xftmpl

by Marcus Meissner

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

May 13, 2011

Re: Ubuntu likely to abandon HAL next cycle -- is this workable?

by Marcus Meissner

On Fri, May 13, 2011 at 08:33:49AM +0200, Marcus Meissner wrote: > On Fri, May 13, 2011 at 12:48:23AM +0200, Scott Ritchie wrote: > > On 05/12/2011 07:02 PM, Alexandre Julliard wrote: > > > Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > > > > > >> Udisks has regressed from the portability of HAL to being Linux-only, > > >> what are we going to do for BSDs/Solaris/others? > > > > > > Of course even if we add udisks we'll keep the HAL support around. It's > > > necessary for backwards compatibility, which is something we take > > > seriously, unlike Ubuntu. > > > > > > > The distro position is that HAL has no upstream, is unmaintained, and > > conflicts with udisks/upower to the point where stuff starts breaking > > (eg, the battery monitor gets confused and reports you have 5% and 6 > > hours left) > > The truth is more: > > - HAL upstream is the same as udisk upstream > - HAL was abandoned in favour of udisk. But yes, it is not in the openSUSE default anymore... So it is time to replace . Ciao, Marcus

May 13, 2011

Re: Ubuntu likely to abandon HAL next cycle -- is this workable?

by Marcus Meissner

On Fri, May 13, 2011 at 12:48:23AM +0200, Scott Ritchie wrote: > On 05/12/2011 07:02 PM, Alexandre Julliard wrote: > > Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > > > >> Udisks has regressed from the portability of HAL to being Linux-only, > >> what are we going to do for BSDs/Solaris/others? > > > > Of course even if we add udisks we'll keep the HAL support around. It's > > necessary for backwards compatibility, which is something we take > > seriously, unlike Ubuntu. > > > > The distro position is that HAL has no upstream, is unmaintained, and > conflicts with udisks/upower to the point where stuff starts breaking > (eg, the battery monitor gets confused and reports you have 5% and 6 > hours left) The truth is more: - HAL upstream is the same as udisk upstream - HAL was abandoned in favour of udisk. ciao, Marcus

May 13, 2011

Re: Question about ddraw implemtation

by Ralph Little

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

May 12, 2011

Re: Ubuntu likely to abandon HAL next cycle -- is this workable?

by Scott Ritchie

On 05/12/2011 07:02 PM, Alexandre Julliard wrote: > Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > >> Udisks has regressed from the portability of HAL to being Linux-only, >> what are we going to do for BSDs/Solaris/others? > > Of course even if we add udisks we'll keep the HAL support around. It's > necessary for backwards compatibility, which is something we take > seriously, unlike Ubuntu. > The distro position is that HAL has no upstream, is unmaintained, and conflicts with udisks/upower to the point where stuff starts breaking (eg, the battery monitor gets confused and reports you have 5% and 6 hours left)

May 12, 2011

Question about ddraw implemtation

by Ralph Little

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

May 12, 2011

Re: Ubuntu likely to abandon HAL next cycle -- is this workable?

by Alexandre Julliard

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > Udisks has regressed from the portability of HAL to being Linux-only, > what are we going to do for BSDs/Solaris/others? Of course even if we add udisks we'll keep the HAL support around. It's necessary for backwards compatibility, which is something we take seriously, unlike Ubuntu. -- Alexandre Julliard julliard(a)winehq.org

May 12, 2011

Re: ddraw: Fix filtering of enumerated display modes (try 4)

by Marvin

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

May 12, 2011

Re: Ubuntu likely to abandon HAL next cycle -- is this workable?

by Damjan Jovanovic

On Thu, May 12, 2011 at 12:28 PM, Scott Ritchie <scott(a)open-vote.org> wrote: > 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 Udisks has regressed from the portability of HAL to being Linux-only, what are we going to do for BSDs/Solaris/others? Damjan Jovanovic

May 12, 2011

Ubuntu likely to abandon HAL next cycle -- is this workable?

by Scott Ritchie

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

May 12, 2011

Re: ddraw: Fix filtering of enumerated display modes (try 3)

by Stefan Dösinger

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

May 12, 2011

Re: [1/2] mmsystem.dll16: fix MCI_STATUS mapping for digitalvideo

by Damjan Jovanovic

On Mon, May 9, 2011 at 6:35 PM, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > Any of these steps means much more code than the simple^Histic > approach which has worked surprisingly well for the last 10 years: "if > flag 00020000 is set in OPEN, it must be MCI_*_OPEN_PARENT, as none of > the other 4 standard drivers (wave, MIDI, avi qtz, CDA) uses that bit." > Likewise MCI_DGV_STATUS_DISKSPACE Thank you for the detailed explanation. The problem then becomes that if a driver expects MCI_DGV_STATUS_PARMS, and we pass MCI_STATUS_PARMS because the request didn't looks like it's destined for a digitalvideo device, it might go and read/write a field that's outside the bounds of the allocated structure. But since it seems that the extra fields should generally only be used if special flags were also passed, and those flags would allow us to detect the device type and pass the right structure, I suppose the current heuristics are good enough. And now I can see why Microsoft abandoned further MCI development :-). > Regards, > Jörg Höhle > Regards Damjan Jovanovic

May 11, 2011

Re: dsound: return success in IDirectSoundBufferImpl_AcquireResources

by Chris Robinson

On Wednesday, May 11, 2011 6:40:42 AM Joerg-Cyril.Hoehle(a)t-systems.com wrote: > 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. That's not fixing bugs, that's hiding them. :) The bug is that the function is not implemented/supported, not that the function is being truthful with its return value, and simply changing the return value doesn't fix that. Hence the bug is not fixed. It actually kind of bothers me to see patches to "fix bugs" that only change the return value of a stub from error to success... returning success when the function doesn't work is itself a bug, and not any better than a hack, IMO. It can lead apps down a path that assume the function did what it was supposed to, when it really didn't, and trigger problems in unrelated code making it harder to track down the actual problem. Especially as Wine tends to implement stuff on an as-needed basis, this leaves many stubs empty. If returning a failure code causes a problem, that's a sign that the stub should be properly filled out enough to satisfy it.

May 11, 2011

winealsa.drv/midi.c: Adds the midi MTC Quarter Frame messages support.

by Joerg-Cyril.Hoehle＠t-systems.com

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

May 11, 2011

dsound: return success in IDirectSoundBufferImpl_AcquireResources

by Joerg-Cyril.Hoehle＠t-systems.com

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

May 11, 2011

configure looking for prelink

by Claudio Fontana

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

May 11, 2011

Re: msvcrt: Don't pass NULL as __ms_va_list in printf implementation

by Eric Pouech

> > You could va_copy() it to a second va_list if you need to do it twice. > va_copy is C99. Are we ready to say that is now dependant to C89 ?. A+ -- Eric Pouech

May 11, 2011

Re: [PATCH] riched20: Fixed some lParams with keycodes (Coverity)

by Marvin

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

May 11, 2011

Re: msvcrt: Don't pass NULL as __ms_va_list in printf implementation

by Marcus Meissner

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

May 11, 2011

Re: msvcrt: Don't pass NULL as __ms_va_list in printf implementation

by Marcus Meissner

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

May 11, 2011

Re: urlmon: Code clean up and make tests a bit stricker

by Marvin

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

May 11, 2011

Re: [PATCH 1/3] gdi32/tests: Test for font selection by full name.

by Grazvydas Ignotas

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

May 11, 2011

Re: ddraw: Fix filtering of enumerated display modes (try 3)

by Marvin

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

May 11, 2011

Re: __ms_va_list and NULL

by Alexandre Julliard

Piotr Caban <piotr(a)codeweavers.com> writes: > On 05/10/11 20:02, André Hentschel wrote: >> 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. > I don't know if it's a compiler fault or the code is faulty. The code is faulty. You either need to pass a proper va_list, or make the function take a pointer instead. -- Alexandre Julliard julliard(a)winehq.org

May 10, 2011

Re: __ms_va_list and NULL

by Piotr Caban

On 05/10/11 20:02, André Hentschel wrote: > 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. I don't know if it's a compiler fault or the code is faulty. Adding empty __ms_va_lists looks suspicious. In this case there's always proper valist and you can pass (no need to create new). It will be ignored in the same way NULL is.

May 10, 2011

Re: [2/2] usp10/tests: test ScriptItemizeOpenType

by Marvin

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

May 10, 2011

__ms_va_list and NULL

by André Hentschel

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

May 10, 2011

Re: [PATCH 1/2] mountmgr: Populate HKLM\HARDWARE\DEVICEMAP\Scsi here instead of in kernel32. (try 6)

by Alexandre Julliard

Charles Davis <cdavis(a)mymail.mines.edu> writes: >> Now it's not setting DeviceName at all here. > As far as I can tell, this is a limitation of the way mountmgr works. It > only assigns a device name when a disk is in the drive. I take it you > want me to fix that? Ultimately we'll want to create the devices even without a disk in the drive, but that can be a separate patch. For now setting the name only when it's mounted would be good enough. -- Alexandre Julliard julliard(a)winehq.org

May 10, 2011

Re: [3/5] d3dx9: Implement D3DXMESHOPT_ATTRSORT|D3DXMESHOPT_IGNOREVERTS. (try 2)

by Alexandre Julliard

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

May 10, 2011

Re: [PATCH 1/2] mountmgr: Populate HKLM\HARDWARE\DEVICEMAP\Scsi here instead of in kernel32. (try 6)

by Charles Davis

On 5/10/11 11:11 AM, Alexandre Julliard wrote: > 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. As far as I can tell, this is a limitation of the way mountmgr works. It only assigns a device name when a disk is in the drive. I take it you want me to fix that? Chip

May 10, 2011

Re: [PATCH 1/2] mountmgr: Populate HKLM\HARDWARE\DEVICEMAP\Scsi here instead of in kernel32. (try 6)

by Alexandre Julliard

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

May 10, 2011

Re: gdi32: Handle pre-Unicode symbol TTFs with symbols at U+00XX.

by Alexandre Julliard

"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

May 10, 2011

Re: ddraw: Fix filtering of enumerated display modes by bits per pixel

by Stefan Dösinger

>> Please add an additional test that passes in non-null flags that >don't match >> standard R5G6B5. > >I'm not exactly sure what you mean with this. The other test has mask >of >R5G5B5. The one that's missing is R5G6B5, but I don't think it's >needed. E.g. a red mask of 0xf0f0, green 0x0f00 and blue 0x000f. The purpose is to find out if windows listens to non-zero masks. If it does you'll get 0 formats reported. If it doesn't you'll get the usual count. -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

May 10, 2011

Re: [PATCH try6] wininet: Added support for persistent HTTP connections

by Marvin

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

May 10, 2011

Re: comctl32/listview: Make edit box handle available from LVN_ENDLABELEDIT notification

by Alexandre Julliard

Vitaliy Margolen <wine-devel(a)kievinfo.com> writes: > I'm guessing AJ doesn't care much about such details. So NVM. > > Anyone want's to remove any requirements to wine tests? As long as > they compile and pass on AJ's pc, is seems to be the only requirement. The tests are supposed to succeed. Writing fancy failure messages is a waste of time, since they are not supposed to be seen anyway. Printing the failing value is useful, but printing "foo was expected instead" is generally useless. And about window handles, IsWindow() is just fine, handles don't get reused the way you think. Learn how things work before flaming others. -- Alexandre Julliard julliard(a)winehq.org

May 10, 2011

Re: ddraw: Fix filtering of enumerated display modes by bits per pixel

by Ričardas Barkauskas

On 05/09/2011 10:11 PM, Stefan Dösinger wrote: > 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. I'm not exactly sure what you mean with this. The other test has mask of R5G5B5. The one that's missing is R5G6B5, but I don't think it's needed. >> + 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. My bad. Didn't think of testing this before. Now it is to strict. Ricardas Barkauskas REalm

May 10, 2011

Re: kernel32: Implement CreateSymbolicLinkA/W by reusing a modified IoCreateSymbolicLink

by Vitaliy Margolen

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.

May 9, 2011

Re: comctl32/listview: Make edit box handle available from LVN_ENDLABELEDIT notification

by Vitaliy Margolen

I'm guessing AJ doesn't care much about such details. So NVM. Anyone want's to remove any requirements to wine tests? As long as they compile and pass on AJ's pc, is seems to be the only requirement. Vitaliy. On 05/09/2011 08:42 AM, Nikolay Sivov wrote: > On 5/9/2011 17:39, Vitaliy Margolen wrote: >> 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. > I don't think it's a big deal. >> >> 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. > I don't expect NULL, that's all. I don't care about particular pointer > value. If you mean I should print that I expect NULL, I don't think so, it's > redundant. In case it fails you need to look at failed line anyway. >> >>> + 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. > This duplicates previous test behaviour that's doing just fine for quite a > long time. Test is single threaded, and you should run test program in clean > environment, with no programs around best. So it's working fine in practice. >> >>> - /* WM_COMMAND with EN_KILLFOCUS isn't forwared to parent */ >>> + /* WM_COMMAND with EN_KILLFOCUS isn't forwarded to parent */ >> A typo fix. > And? Separate patch to fix a typo in test file comment? (same test function > I'm patching now even) >> >> Vitaliy. >> >> >> > > >

May 9, 2011

Re: kernel32: Implement CreateSymbolicLinkA/W by reusing a modified IoCreateSymbolicLink

by Juan Lang

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

May 9, 2011

Re: ddraw: Fix filtering of enumerated display modes by bits per pixel

by Marvin

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

May 9, 2011

Re: ddraw: Fix filtering of enumerated display modes by bits per pixel

by Stefan Dösinger

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.

May 9, 2011

[1/2] mmsystem.dll16: fix MCI_STATUS mapping for digitalvideo

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Damjan Jovanovic wrote: >What determines what subtype of MCI_STATUS_PARMS is passed to >mciSendCommand() for an MCI_STATUS message? I consider the string interface the defining property of MCI devices. This sets it apart from e.g. COM interfaces. Further I believe the string and command interfaces to be interchangeable. This has several consequences. A. The string interfaces only provides one return value. There's no need to provide other output variables since the string interface cannot return them. This answers >are you convinced no MCI driver ever modifies fields it shouldn't, and >no application depends on that exceptional behaviour? with yes. If you suspect a deviating behaviour, then by all means, write a test. For instance, I was surprised when my tests revealed that in some version of MS some of the MCI drivers modify dwRetSize (in INFO_PARMS). I read into VirtualAlloc() the other day to find out how to write-protect memory so as to detect whether some a priori read-only slot is written to. Of course, this does not prevent e.g. a root kit to hide as an MCI driver and write whatever into the PARMS structure. B. The MCI_*_PARMS and the MCI resource files must be congruent. The MCI parser does not know any PARMS structure. It uses the resource description to reconstruct the layout of the PARMS structure. C. Each device recognizes one structure per command. The structure is defined by the device's resource file (defaulting to winmm_res.rc). This answers >must [the driver] assume it got MCI_DGV_STATUS_PARMS only when it >deals with a DGV-specific status request like MCI_DGV_STATUS_DISKSPACE >and fall back to the generic MCI_STATUS_PARMS for all other cases? with no. Driver X can and must assume that it received a MCI_X_STATUS_PARMS. That's what it receives from the MCI parser. All MCI_*_STATUS_PARMS need not have their slots in the same place, but it would be unwise to deviate from the order of the core commands. Then you couldn't send an MCI_STATUS_MODE using the generic MCI_STATUS_PARMS to an unknown MCI device! Only "status x mode" would work. Wine's A/W and 16/32 MCI mappers depend on this common ordering. Note that the device type only selects the command set when defaulting to winmm_res.rc. A driver providing its own resource (like mciavi) can return any device type it sees fit -- I still wonder why mciavi returns type "digitalvideo" instead of "animation". In the end, the resource defines the layout and extra parameters that the driver purports to recognize. What I mean is that dispatching on devtype is no guarantee for correctness, rather than a good guess. These were the rules, now the exceptions. :-) - I believe MS goofed with mciavi/mciqtz32 because MCI_DGV_SETVIDEO_PARMS and mciavi_res.rc publish 4 slots - over, quality, algorithm, number - in non-matching order. Hence you cannot use the generic MCI parser to construct the layout in digitalv.h I never wrote a test to see whether there are some MS hacks to map one to the other, or whether the .h is incorrect. - Using the MCI string interface always involves an alias, whereas you can use the command interface without it. - The MCI_BREAK system command has an hwndBreak slot and associated MCI_BREAK_HWND flag that the string interface does not know about. - dwRetSize update mentioned above. After I discovered that, I had Wine implement the "straight" behaviour because the modification is not documented, not all drivers implement it across all versions, not all commands do it, native implements it bogusly for dwRetSize=0 and its value is unclear with W/A: so let's not write to it. I put a comment in the code to signal this irregularity. Does an application depend on the update? Who knows? Possible rewrites and future directions: - Several times I thought about passing a bUnicode flag within winmm's MCI parser to delay the mapping from A to W. Never written. - I thought about reusing the PARMS structure in-place, replacing string A with W pointers. This would eliminate the current hassle of not knowing the size of structure. All that one needs to know is the location of the string pointers. Never written. That's obviously not feasible with the 16/32 mapping due to differing offsets. Another, less fancy approach would be to parse the resource strings even for MCI commands so as to know the layout. It would slow down every command. But it would be correct. - One problem remains with OPEN. Basically, it looks like the MCI needs to preparse the "open ..." string to determine which device to open. Only when the device is known does winmm know which resource to use for parsing! E.g. mciwave accepts an extra buffer parameter. I don't believe native would do two passes. It may well be that native's parser is an implementation of the IBM patent I mentioned some month ago. Perhaps that helps solve the issue. - The OPEN issue affects the 16/32 mapper too. After all, MCI_ANIM_OPEN_PARMS contains a HWND beyond the common parameters... How to find out whether the OPEN will go to a device that uses extra slots? ... And how to fill these slots? The only solution path that I currently see is that mmsystem16 would duplicate some of winmm's job: send the 3 messages to load and open the driver to obtain the resource, then only call MCI_OPEN. Any of these steps means much more code than the simple^Histic approach which has worked surprisingly well for the last 10 years: "if flag 00020000 is set in OPEN, it must be MCI_*_OPEN_PARENT, as none of the other 4 standard drivers (wave, MIDI, avi qtz, CDA) uses that bit." Likewise MCI_DGV_STATUS_DISKSPACE Regards, Jörg Höhle

May 9, 2011

Re: [PATCH 1/2] mountmgr: Populate HKLM\HARDWARE\DEVICEMAP\Scsi here instead of in kernel32. (try 5)

by Charles Davis

On 5/9/11 8:36 AM, Vitaliy Margolen wrote: > 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. You're right, will fix. > >> >> + 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. OK. > 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 The numbers I used are actually the SCSI peripheral device type numbers. I use them in create_scsi_entry() to figure out which one of the "*Peripheral" strings to put in the registry. But yeah, I probably shouldn't use magic numbers like that. > > Missing "DeviceName"="Cdrom0" for cdroms. You only get a DeviceName if there's a disk in the drive (a limitation of the way mountmgr works). > > 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" OK, I can fix these. > -"Identifier"="SAMSUNG DVDWBD SH-B083L SB01" > +"Identifier"="SAMSUNG DVDWBD SH-B083L" Can't fix that. HAL provides no way to query the SCSI revision of a SCSI device. Short of actually sending an INQUIRY SCSI command to the device, I don't know how to fix that. Thanks. Chip

May 9, 2011

Re: [PATCH try5] wininet: Added support for persistent HTTP connections

by Alexandre Julliard

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

May 9, 2011

Re: Support for D3DQUERY_TIMESTAMP* queries...

by Henri Verbeet

On 4 May 2011 20:38, Adam Martinson <amartinson(a)codeweavers.com> wrote: > OK, I think I addressed those issues, let me know how these look. > > +#define GL_TIME_ELAPSED_ARB 0x88BF > +#define GL_TIMESTAMP_ARB 0x8E28 Most of wined3d uses lowercase hex literals. > + type = wined3d_query_get_type(This->wineD3DQuery); > + if (type == D3DQUERYTYPE_TIMESTAMPDISJOINT) That's not a wined3d type. Also, this patch doesn't make sense on its own. > +static void test_timestamp_queries(IDirect3D9 *pD3d, HWND hwnd) Please don't use names like pD3d, pDevice, etc. There's also still a fair amount of inconsistencies in this patch. Patch 7/12 just adds dead code. It also seems to me the way of splitting the d3d9 and d3d10 disjoint queries is more complicated than needed. The difference can be handled completely in d3d10, since "ARB_TIMER_QUERY_FREQ" is just a constant that could easily just be part of the wined3d interface.

May 9, 2011

Re: comctl32/listview: Make edit box handle available from LVN_ENDLABELEDIT notification

by Nikolay Sivov

On 5/9/2011 17:39, Vitaliy Margolen wrote: > 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. I don't think it's a big deal. > > 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. I don't expect NULL, that's all. I don't care about particular pointer value. If you mean I should print that I expect NULL, I don't think so, it's redundant. In case it fails you need to look at failed line anyway. > >> + 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. This duplicates previous test behaviour that's doing just fine for quite a long time. Test is single threaded, and you should run test program in clean environment, with no programs around best. So it's working fine in practice. > >> - /* WM_COMMAND with EN_KILLFOCUS isn't forwared to parent */ >> + /* WM_COMMAND with EN_KILLFOCUS isn't forwarded to parent */ > A typo fix. And? Separate patch to fix a typo in test file comment? (same test function I'm patching now even) > > Vitaliy. > > >

May 9, 2011

Re: [PATCH 1/2] mountmgr: Populate HKLM\HARDWARE\DEVICEMAP\Scsi here instead of in kernel32. (try 5)

by Vitaliy Margolen

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.

May 9, 2011

Re: [PATCH try5] wininet: Added support for persistent HTTP connections

by Jacek Caban

On 05/09/11 13:13, Marvin wrote: > 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 It's unrelated to the patch. Jacek

May 9, 2011

Re: comctl32/listview: Make edit box handle available from LVN_ENDLABELEDIT notification

by Vitaliy Margolen

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.

May 9, 2011

Re: [PATCH try5] wininet: Added support for persistent HTTP connections

by Marvin

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

May 9, 2011

Re: wineoss.drv: Add mmdevapi driver.

by Andrew Eikum

On 05/07/2011 07:04 PM, Gerald Pfeifer wrote: > On Fri, 6 May 2011, Andrew Eikum wrote: >> If Wine is trying to build wineoss.drv, then you must have oss_sysinfo. >> If you have oss_sysinfo, then you have OSSv4. If you have OSSv4, then >> you should have all of the above symbols, but apparently you don't. So I >> suspect it's something amiss with your OSSv4 implementation, and that's >> where I would begin investigating. >> >> Does that help you diagnose the problem? > > Yes, thanks a lot! Based on yours and Farncois' input, I did some > research and found the following, among others > > http://manuals.opensound.com/developer/AFMT_S24_PACKED.html > > and consulting Google Code Search I find that also other applications > do something like the following here (mplayer, for example). > > Suggested patch below. Makes sense to me. Thanks. Do this patch and the float format patch together fix your build issues, Gerald? Andrew > > Gerald > > > ChangeLog: > Use AFMT_S24_LE instead of AFMT_S24_PACKED. > > diff --git a/dlls/wineoss.drv/mmdevdrv.c b/dlls/wineoss.drv/mmdevdrv.c > index ff21cd6..789cb1e 100644 > --- a/dlls/wineoss.drv/mmdevdrv.c > +++ b/dlls/wineoss.drv/mmdevdrv.c > @@ -500,7 +500,7 @@ static int get_oss_format(const WAVEFORMATEX *fmt) > case 16: > return AFMT_S16_LE; > case 24: > - return AFMT_S24_PACKED; > + return AFMT_S24_LE; > case 32: > return AFMT_S32_LE; > } > @@ -953,7 +953,7 @@ static HRESULT WINAPI AudioClient_GetMixFormat(IAudioClient *iface, > }else if(formats& AFMT_S32_LE){ > fmt->Format.wBitsPerSample = 32; > fmt->SubFormat = KSDATAFORMAT_SUBTYPE_PCM; > - }else if(formats& AFMT_S24_PACKED){ > + }else if(formats& AFMT_S24_LE){ > fmt->Format.wBitsPerSample = 24; > fmt->SubFormat = KSDATAFORMAT_SUBTYPE_PCM; > }else{

May 9, 2011

Re: wineoss.drv: Support platforms that do not feature AFMT_FLOAT.

by Andrew Eikum

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

May 9, 2011

Re: audio: remove extraneous parentheses around equality comparisons

by Paul Chitescu

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)

May 9, 2011

Re: [PATCH] msi: Fixed check_flag_combo macro (Coverity)

by Hans Leidekker

On Mon, 2011-05-09 at 13:05 +0200, Marcus Meissner wrote: > > 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 > > I have the suspicion that my patch just uncovers another bug, either > in this specific check, or other code. :/ > > ... > trace:msi:ITERATE_RemoveEnvironmentString name L"=+-MSITESTVAR2" value L"1" > err:msi:env_parse_flags Invalid flags: 00000007 > ... > > Hans? You seem to have added it the remove environment checks in aaf5ff.. any idea? ITERATE_RemoveEnvironmentString already validates parsed flags, so I would move the check_flag_combo invocations from env_parse_flags to ITERATE_WriteEnvironmentString.

May 9, 2011

Re: [PATCH] msi: Fixed check_flag_combo macro (Coverity)

by Marcus Meissner

On Mon, May 09, 2011 at 12:07:39PM +0200, Alexandre Julliard wrote: > 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 I have the suspicion that my patch just uncovers another bug, either in this specific check, or other code. :/ ... trace:msi:ITERATE_RemoveEnvironmentString name L"=+-MSITESTVAR2" value L"1" err:msi:env_parse_flags Invalid flags: 00000007 ... Hans? You seem to have added it the remove environment checks in aaf5ff.. any idea? Ciao, Marcus

May 9, 2011

Re: [PATCH] msi: Fixed check_flag_combo macro (Coverity)

by Alexandre Julliard

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

May 9, 2011

Re: [2/2] urlmon: Honor E_ABORT for URLDownloadToFile status callbacks

by Alexandre Julliard

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

May 9, 2011

Re: [PATCH 9/9] mmdevapi/tests: Add tests for volume control interfaces

by Alexandre Julliard

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

May 9, 2011

Re: Assorted spelling and case fixes.

by Marvin

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

May 9, 2011

Re: winspool.drv: Add stubs for IsValidDevmodeW and IsValidDevmodeA.

by Marvin

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

May 9, 2011

Re: ddraw: Add tests for SetCooperativeLevel

by Marvin

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

May 8, 2011

Re: [4/5] d3dx9: Implement D3DXMESHOPT_ATTRSORT vertex reordering.

by Matteo Bruni

2011/5/8 Dylan Smith <dylan.ah.smith(a)gmail.com>: > On Sun, May 8, 2011 at 3:18 PM, Matteo Bruni <matteo.mystral(a)gmail.com> > wrote: >> >> 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. >> > I only wanted a singly linked list. The back links would be unused, but > would waste memory and update operations. The linked list also gets > invalidated by sorting, so the ptr field is actually also used to store the > original position in the array for performing a stable sort. I don't think > using include/wine/list.h would make the code clearer, since it would be > like trying to abstract the implementation details, when those details are > relevant to the implementation (see the answer to the next question for an > example). It is an ongoing effort (almost complete I think) to replace custom list implementations with the generic one through the Wine codebase. I don't think this case is so special to require a custom list. I don't have a strong opinion here, but, e.g., I don't find adding one or two fields to the structure a big drawback. >> >> > + 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. > > Reducing memory allocations and keeping locality of memory references seemed > like a good idea, but in this case it actually affects the behaviour of the > sort. The pointer values are used in vertex_attrib_compare as a secondary > value, which largely affects the result since many vertices share the same > attribute value. Pointers into the heads array are used to keep the first > use of each vertex in the original order of the vertices, and duplications > of those vertices must be sorted using a stable sort, so their original > position in the array are compared where the attribute value is the same. I was referring to allocating "heads" and "duplications" from the same call, which, as far as I can see, is not required. Regarding the sorting requirements, those can also be addressed by adding another index field to the structure.

May 8, 2011

Re: [4/5] d3dx9: Implement D3DXMESHOPT_ATTRSORT vertex reordering.

by Dylan Smith

On Sun, May 8, 2011 at 3:18 PM, Matteo Bruni <matteo.mystral(a)gmail.com>wrote: > 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. > > I only wanted a singly linked list. The back links would be unused, but would waste memory and update operations. The linked list also gets invalidated by sorting, so the ptr field is actually also used to store the original position in the array for performing a stable sort. I don't think using include/wine/list.h would make the code clearer, since it would be like trying to abstract the implementation details, when those details are relevant to the implementation (see the answer to the next question for an example). > + 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. > Reducing memory allocations and keeping locality of memory references seemed like a good idea, but in this case it actually affects the behaviour of the sort. The pointer values are used in vertex_attrib_compare as a secondary value, which largely affects the result since many vertices share the same attribute value. Pointers into the heads array are used to keep the first use of each vertex in the original order of the vertices, and duplications of those vertices must be sorted using a stable sort, so their original position in the array are compared where the attribute value is the same.

May 8, 2011

Re: [2/5] d3dx9: Implement D3DXMESHOPT_COMPACT for ID3DXMesh::OptimizeInplace.

by Dylan Smith

On Sun, May 8, 2011 at 3:17 PM, Matteo Bruni <matteo.mystral(a)gmail.com>wrote: > 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? > Ya, I was just trying to match the native behaviour.

May 8, 2011

Re: [4/5] d3dx9: Implement D3DXMESHOPT_ATTRSORT vertex reordering.

by Matteo Bruni

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.

May 8, 2011

Re: [2/5] d3dx9: Implement D3DXMESHOPT_COMPACT for ID3DXMesh::OptimizeInplace.

by Matteo Bruni

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?

May 8, 2011

Re: [1/5] d3dx9: Implement ID3DXMesh::CloneMesh without vertex buffer conversion.

by Matteo Bruni

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

May 8, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Michael Mc Donnell

My plans have changed a bit to avoid duplication of work. The updated plan is: Before May 23: * Read up on DirectX in general Week 1-3 (May 23rd-June 10th): * Implement test for UpdateSemantics function * Implement UpdateSemantics function Week 4-6 (June 13th-July 1st): * Implement test for ConvertPointRepsToAdjacency function * Implement test for ConvertAdjacencyToPointReps function * Implement ConvertPointRepsToAdjacency function * Implement ConvertAdjacencyToPointReps function Week 7-9 (July 4th-22th): * Implement test for D3DXWeldVertices * Implement D3DXWeldVertices Week 10-12 (July 25th-August 12th): * Improve clone function if possible * Improve implemented functions as needed. Week 13 (Auguest 15th-19th): * Make sure that all code has been integrated in the official tree. * Last code clean-up for code that has not already been accepted.

May 8, 2011

Re: tools: Upgrade the config.guess/config.sub scripts

by Austin English

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

May 8, 2011

Re: riched20:tests Add conformance test for EM_FINDWORDBREAK function.

by James McKenzie

On 5/8/11 3:18 AM, André Hentschel wrote: > 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. > Resending. Thanks for catching that from my tests. James McKenzie

May 8, 2011

Re: [1/2] mmsystem.dll16: fix MCI_STATUS mapping for digitalvideo

by Damjan Jovanovic

On Fri, May 6, 2011 at 6:23 PM, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > Damjan, > > @@ -407,6 +441,20 @@ static MMSYSTEM_MapType MCI_UnMapMsg16To32W(WORD wMsg, DWORD dwFlags, DWORD_PTR > + mdsp16->dwCallback = mdsp32w->dwCallback; > + mdsp16->dwItem = mdsp32w->dwItem; > + mdsp16->dwTrack = mdsp32w->dwTrack; > This is superfluous. dwReturn is the only documented output. > This was different with your former MCI_WHERE patch, where a RECT is output. I'm aware it will be superfluous in the majority of cases, but are you convinced no MCI driver ever modifies fields it shouldn't, and no application depends on that exceptional behaviour? > I'd try hard not to turn one message call (Status) into 2 (GetDevCaps + Status). > I've seen logs of apps that continuously poll MCI_STATUS_POSITION. > Instead, I'd continue the path lead by winmm/mci.c:MCI_MapMsgAtoW: > Allocate the largest structure and fill it depending on dwFlags, e.g.: > case MCI_OPEN: > { /* MCI_ANIM_OPEN_PARMS is the largest known MCI_OPEN_PARMS > * structure, larger than MCI_WAVE_OPEN_PARMS */ > BTW, I've a note that MCI_INFO needs similar treatment, but never wrote the patch... > > Select the right set of flags to fill the slots, otherwise fallback to defaults like: > /* We don't know how many DWORD follow, as > * the structure depends on the device. */ > if (HIWORD(dwParam1)) > memcpy(&mci_openW->dwStyle, &mci_openA->dwStyle, sizeof(MCI_ANIM_OPEN_PARMSW) - sizeof(MCI_OPEN_PARMSW)); > > Of course, one may argue that this is a heuristic and can fail. Well, > GetDevCaps is a heuristic as well that only supports devtype_digital_video. What determines what subtype of MCI_STATUS_PARMS is passed to mciSendCommand() for an MCI_STATUS message? According to the API, "For VCR devices" uses one type, "For digital-video devices" uses another type, etc. But must the digital video MCI driver assume every MCI_STATUS lpStatus parameter points to MCI_DGV_STATUS_PARMS, or must it assume it got MCI_DGV_STATUS_PARMS only when it deals with a DGV-specific status request like MCI_DGV_STATUS_DISKSPACE and fall back to the generic MCI_STATUS_PARMS for all other cases? > An advantage IMHO of the existing approach is that > it does not invent within the same source code base > yet another mechanism to map 16 to 32 or A to W. I'd rather follow the > existing model until the time it proves unbearable, or immediately switch > the *whole* code base to another model, not the single MCI_STATUS function. > > For instance, you can argue that it makes sense for winmm > to cache the device type (winmm:MCI_Open has it in several cases). > It would arguably also make sense > to cache the MCI auto_open'ed property, but I digress. > > > Your MCI_get_device_type is bogus. MCI_GETDEVCAPS_DEVICE_TYPE > belongs into dwItem, not dwFlags. Let's finish this discussion, then I'll see whether to fix that bug or eliminate the entire function. > Regards, > Jörg Höhle > Regards Damjan Jovanovic

May 8, 2011

Re: ntdll: Make RtlReAllocateHeap() preserve V-bit information when run under Valgrind

by Marcus Meissner

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

May 8, 2011

Re: RFC: doc for message contexts additions in PO files

by André Hentschel

Am 24.04.2011 11:03, schrieb Frédéric Delanoy: > 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. I'd say just put it on the wiki and we'll see what happens. It's better than getting forgotten on the mailinglist. -- Best Regards, André Hentschel

May 8, 2011

Re: riched20:tests Add conformance test for EM_FINDWORDBREAK function.

by André Hentschel

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

May 8, 2011

Re: wineoss.drv: Add mmdevapi driver.

by Gerald Pfeifer

On Fri, 6 May 2011, Andrew Eikum wrote: > If Wine is trying to build wineoss.drv, then you must have oss_sysinfo. > If you have oss_sysinfo, then you have OSSv4. If you have OSSv4, then > you should have all of the above symbols, but apparently you don't. So I > suspect it's something amiss with your OSSv4 implementation, and that's > where I would begin investigating. > > Does that help you diagnose the problem? Yes, thanks a lot! Based on yours and Farncois' input, I did some research and found the following, among others http://manuals.opensound.com/developer/AFMT_S24_PACKED.html and consulting Google Code Search I find that also other applications do something like the following here (mplayer, for example). Suggested patch below. Gerald ChangeLog: Use AFMT_S24_LE instead of AFMT_S24_PACKED. diff --git a/dlls/wineoss.drv/mmdevdrv.c b/dlls/wineoss.drv/mmdevdrv.c index ff21cd6..789cb1e 100644 --- a/dlls/wineoss.drv/mmdevdrv.c +++ b/dlls/wineoss.drv/mmdevdrv.c @@ -500,7 +500,7 @@ static int get_oss_format(const WAVEFORMATEX *fmt) case 16: return AFMT_S16_LE; case 24: - return AFMT_S24_PACKED; + return AFMT_S24_LE; case 32: return AFMT_S32_LE; } @@ -953,7 +953,7 @@ static HRESULT WINAPI AudioClient_GetMixFormat(IAudioClient *iface, }else if(formats & AFMT_S32_LE){ fmt->Format.wBitsPerSample = 32; fmt->SubFormat = KSDATAFORMAT_SUBTYPE_PCM; - }else if(formats & AFMT_S24_PACKED){ + }else if(formats & AFMT_S24_LE){ fmt->Format.wBitsPerSample = 24; fmt->SubFormat = KSDATAFORMAT_SUBTYPE_PCM; }else{

May 7, 2011

Re: gdi32: Remove a set but unused variable

by Gerald Pfeifer

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

May 7, 2011

Re: Jerome Leclanche : wine.desktop: Remove the nonexistent application/ x-win-lnk MIME type.

by Scott Ritchie

A .desktop entry pointing to a nonexistant mime type is harmless, so I'd revert the change. Indeed only a year ago Wine's .desktop entry pointed to MANY non-existant mime types. -Scott Ritchie On 05/07/2011 05:27 AM, Jerome Leclanche wrote: > Odd, I'm on KDE but my shortcuts are all application/x-ms-shortcut (Natty). > > I had a quick search through the kde sources and it seems KDE might be > forcing x-win-lnk for some windows-specific behaviour. At least it's > there in a bunch of tests, but no app seems to actually use it. > > I'll file a bug with KDE and see what else references it. Should the > commit be reverted or is it a case of fix-it-upstream? > > > J. Leclanche > > > > 2011/5/7 Ozan Türkyılmaz <ozan.turkyilmaz(a)gmail.com>: >> On Sat, 7 May 2011, Francois Gouget wrote: >>> >>> 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. >>> >> >> I found it on /usr/share/mime/packages/kde.xml on Slackware 13.37 as well. >> It's included in kdelibs package. >> >> -- >> Ozan, BSc, BEng >> >> >> > >

May 7, 2011

Re: Huge frustration

by André Hentschel

Am 07.05.2011 12:52, schrieb Roland Kaeser: > 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 After i read through the bugs, i think the activity wasn't that low. But e.g. no reply by you or the bug reporter on comments like http://bugs.winehq.org/show_bug.cgi?id=14123#c8 or http://bugs.winehq.org/show_bug.cgi?id=3611#c22 is also a reason. Further you can't motivate volunteers by attacking them. -- Best Regards, André Hentschel

May 7, 2011

Re: Huge frustration

by James McKenzie

On 5/7/11 3:52 AM, Roland Kaeser wrote: > 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. > Many bug fixes depend on fixing a six year old + bug (421). However, if you feel so strongly, then maybe YOU can take a stab at trying to fix a bug. It is NOT easy (6724 is one bug that I'm working on and it has been around for four+ years.) Also, not all developers are working on fixing and improving DirectX. Some are working on code improvements and long overdue code cleanups. James McKenzie

May 7, 2011

Re: Jerome Leclanche : wine.desktop: Remove the nonexistent application/ x-win-lnk MIME type.

by Jerome Leclanche

Fixed in kdelibs 5552b1f68348ff5a5cc4a20b661a1ba3ad7bafe2: https://projects.kde.org/projects/kde/kdelibs/repository/revisions/5552b1f6… After a little more search, turns out it was just registered as a helper for a kde 3.x plugin which hasn't been provided for quite a few major releases. It also seems to be where it originated from in the first place. J. Leclanche 2011/5/7 Jerome Leclanche <adys.wh(a)gmail.com>: > Odd, I'm on KDE but my shortcuts are all application/x-ms-shortcut (Natty). > > I had a quick search through the kde sources and it seems KDE might be > forcing x-win-lnk for some windows-specific behaviour. At least it's > there in a bunch of tests, but no app seems to actually use it. > > I'll file a bug with KDE and see what else references it. Should the > commit be reverted or is it a case of fix-it-upstream? > > > J. Leclanche > > > > 2011/5/7 Ozan Türkyılmaz <ozan.turkyilmaz(a)gmail.com>: >> On Sat, 7 May 2011, Francois Gouget wrote: >>> >>> 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. >>> >> >> I found it on /usr/share/mime/packages/kde.xml on Slackware 13.37 as well. >> It's included in kdelibs package. >> >> -- >> Ozan, BSc, BEng >> >> >> >

May 7, 2011

Re: Huge frustration

by Lats

> > 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". Most wine developers are just people sorting out problems that either affect them or have some intrinsic reason to work on the problem. Many of them get started because they want to resolve a bug to allow a Windows program to run. If the bugs you are experiencing are not getting traction then you can always have a look yourself.

May 7, 2011

Re: Jerome Leclanche : wine.desktop: Remove the nonexistent application/ x-win-lnk MIME type.

by Jerome Leclanche

Odd, I'm on KDE but my shortcuts are all application/x-ms-shortcut (Natty). I had a quick search through the kde sources and it seems KDE might be forcing x-win-lnk for some windows-specific behaviour. At least it's there in a bunch of tests, but no app seems to actually use it. I'll file a bug with KDE and see what else references it. Should the commit be reverted or is it a case of fix-it-upstream? J. Leclanche 2011/5/7 Ozan Türkyılmaz <ozan.turkyilmaz(a)gmail.com>: > On Sat, 7 May 2011, Francois Gouget wrote: >> >> 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. >> > > I found it on /usr/share/mime/packages/kde.xml on Slackware 13.37 as well. > It's included in kdelibs package. > > -- > Ozan, BSc, BEng > > >

May 7, 2011

Re: Huge frustration

by Henri Verbeet

On 7 May 2011 12:52, Roland Kaeser <roli8200(a)yahoo.de> wrote: > I know also thats a lot more fun developing directx routines instead of > fixing old bugs but No, it isn't. Sorry. But you know, git is awesome. You can spend days doing all kinds of interesting things, like figuring out which people contribute to which areas of Wine, etc. I'll leave that as an exercise for the reader, but you'll probably find there aren't actually all the many people "developing directx routines" all day. Fortunately Wine, like any good Free Software project, has much more people that are good at complaining associated with it than, well, any of these nasty developers, so that makes it all ok.

May 7, 2011

Huge frustration

by Roland Kaeser

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

May 7, 2011

Re: Jerome Leclanche : wine.desktop: Remove the nonexistent application/ x-win-lnk MIME type.

by Ozan Türkyılmaz

On Sat, 7 May 2011, Francois Gouget wrote: > 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. > I found it on /usr/share/mime/packages/kde.xml on Slackware 13.37 as well. It's included in kdelibs package. -- Ozan, BSc, BEng

May 7, 2011

Re: Jerome Leclanche : wine.desktop: Remove the nonexistent application/ x-win-lnk MIME type.

by Francois Gouget

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

May 7, 2011

Re: wineoss.drv: Add mmdevapi driver.

by Francois Gouget

On Fri, 6 May 2011, Andrew Eikum wrote: [...] > You might find some relevant information searching config.log for > "oss_sysinfo". The configure changes that Julliard added use the oss_sysinfo > structure to check that you have OSSv4 installed. > > If Wine is trying to build wineoss.drv, then you must have oss_sysinfo. If you > have oss_sysinfo, then you have OSSv4. If you have OSSv4, then you should have > all of the above symbols, but apparently you don't. So I suspect it's > something amiss with your OSSv4 implementation, and that's where I would begin > investigating. > > Does that help you diagnose the problem? My understanding (from a bit of Googling some time ago, hopefully someone more expert can chime in) is that FreeBSD does not implement OSSv4: their OSS evolved from OSSv3 independently and now has essentially the same feature set but is not 100% API compatible. That's probably the cause of this build error. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The greatest programming project of all took six days; on the seventh day the programmer rested. We've been trying to debug the *&^%$#@ thing ever since. Moral: design before you implement.

May 7, 2011

[1/2] mmsystem.dll16: fix MCI_STATUS mapping for digitalvideo

by Joerg-Cyril.Hoehle＠t-systems.com

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

May 6, 2011

Re: [1/2] mmsystem.dll16: fix MCI_STATUS mapping for digitalvideo

by Damjan Jovanovic

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

May 6, 2011

Re: [PATCH try4] wininet: Added support for persistent HTTP connections

by Jacek Caban

On 05/06/11 13:17, Alexandre Julliard wrote: > 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. Yes, the check is supposed to test for closed connections. It's inspired in how it's done in Gecko [1]. Handling error on the first send also should be fixed (it needs more investigation, send successes for me, it's later recv that fails and it's already too late to handle it well), but we should attempt to detect closed connection earlier because sending has side effects like callback notifications. Thanks, Jacek [1] http://wine.git.sourceforge.net/git/gitweb.cgi?p=wine/wine-gecko;a=blob;f=n…

May 6, 2011

Re: wineoss.drv: Add mmdevapi driver.

by Andrew Eikum

On 05/05/2011 10:22 PM, Gerald Pfeifer wrote: > On Fri, 29 Apr 2011, Gerald Pfeifer wrote: >> commit be332326ba8fc3def406c5f29adf04fbe9a83976 >> Author: Andrew Eikum<aeikum(a)codeweavers.com> >> Date: Wed Apr 27 09:12:36 2011 -0500 >> >> is causing the following build failures on my nightly FreeBSD testers: >> >> mmdevdrv.c:463:20: error: 'AFMT_S24_PACKED' undeclared (first use in this function) >> mmdevdrv.c:476:16: error: 'AFMT_FLOAT' undeclared (first use in this function) >> mmdevdrv.c:854:24: error: 'AFMT_FLOAT' undeclared (first use in this function) >> mmdevdrv.c:863:24: error: 'AFMT_S24_PACKED' undeclared (first use in this function) >> mmdevdrv.c:1084:24: error: 'SNDCTL_DSP_HALT' undeclared (first use in this function) >> >> Looks like some autoconfigury is not working or incomplete? > > This has now been broken for a week; when are you planning on fixing > this, Andrew? Bugs are much easier to keep track of than mailing list threads. > If not, any pointers on how to best approach this? > > I checked, and AFMT_FLOAT is not defined in /usr/include on either > my FreeBSD 8.2 tester nor my openSUSE 11.4 machine, whereas other > AFMT_ strings are. Similarly for AFMT_S24_PACKED and SNDCTL_DSP_HALT. Commit f60a0f5e565ab9ec5f13b6b489e03b6b22ebf8f7 was supposed to fix these issues. See bug 26975 for more background. You might find some relevant information searching config.log for "oss_sysinfo". The configure changes that Julliard added use the oss_sysinfo structure to check that you have OSSv4 installed. If Wine is trying to build wineoss.drv, then you must have oss_sysinfo. If you have oss_sysinfo, then you have OSSv4. If you have OSSv4, then you should have all of the above symbols, but apparently you don't. So I suspect it's something amiss with your OSSv4 implementation, and that's where I would begin investigating. Does that help you diagnose the problem? Andrew

May 6, 2011

Re: [PATCH try4] wininet: Added support for persistent HTTP connections

by Alexandre Julliard

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

May 6, 2011

Re: [PATCH try4] wininet: Added support for persistent HTTP connections

by Alexandre Julliard

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

May 6, 2011

Re: [PATCH try4] wininet: Added support for persistent HTTP connections

by Jacek Caban

On 05/06/11 10:47, Marvin wrote: > 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 This is not related to my patch. All I've changed in protocol.c was removing todo_wine, so it can't affect Windows runs. Jacek

May 6, 2011

Re: po: Update French translation

by Frédéric Delanoy

2011/5/6 Nicolas Le Cam <niko.lecam(a)gmail.com>: > Le 6 mai 2011 08:41, Frédéric Delanoy <frederic.delanoy(a)gmail.com> a écrit : >> 2011/5/6 Nicolas Le Cam <niko.lecam(a)gmail.com>: >>>> #: 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. >> >> Well actually, it's more like an error/omission in the original En version. >> >> POPUP "" >> BEGIN >> MENUITEM "&Modify...", ID_EDIT_MODIFY >> MENUITEM "Modify Binary Data...", ID_EDIT_MODIFY_BIN >> MENUITEM SEPARATOR >> MENUITEM "&Delete\tDel", ID_EDIT_DELETE >> MENUITEM "&Rename", ID_EDIT_RENAME >> END >> >> As you can see, there's an accelerator on 3 out of 4 entries. For >> consistency sake, the remaining one should have one as well. >> I'll send a patch for this. >> >>> -- >>> Nicolas Le Cam >> >> Frédéric Delanoy >> > IMHO it isn't. It duplicates Windows behaviour : Modify / Delete and > Rename have accelerators, Modify Binary Data doesn't. Well if I want to be pedantic, the translations aren't also word-for-word equal with windows. Does that mean they should be discarded altogether? I agree that 100% code, bug-for-bug compatibility is wine ultimate objective, but for the GUI menu entries, I'm not so sure. Maybe Windows regedit should add an accelerator there as well? That would make sense IMHO. Frédéric

May 6, 2011

winscard/tests: Add test base functions of winscard.dll

by Joerg-Cyril.Hoehle＠t-systems.com

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

May 6, 2011

Re: [PATCH try4] wininet: Added support for persistent HTTP connections

by Marvin

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

May 6, 2011

Re: avicap32: fix build with recent kernel headers

by Michael Stefaniuc

Hello Rafał, Rafał Mużyło wrote: > Attached patch seems to fix build problem with recent kernel headers, > where v4l1 was removed. I'm sending it here first (instead straight while the v4l1 API was removed from the kernel it wasn't removed from the userspace. libv4l1 will translate v4l1 to v4l2. > to wine-patches), as I have no real way of testing it - I only know it builds. A more correct fix would be to stop using directly the kernel headers and move to using the libv4l2 library. > 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. bye michael

May 6, 2011

Re: po: Update French translation

by Nicolas Le Cam

Le 6 mai 2011 08:41, Frédéric Delanoy <frederic.delanoy(a)gmail.com> a écrit : > 2011/5/6 Nicolas Le Cam <niko.lecam(a)gmail.com>: >>> #: 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. > > Well actually, it's more like an error/omission in the original En version. > > POPUP "" > BEGIN > MENUITEM "&Modify...", ID_EDIT_MODIFY > MENUITEM "Modify Binary Data...", ID_EDIT_MODIFY_BIN > MENUITEM SEPARATOR > MENUITEM "&Delete\tDel", ID_EDIT_DELETE > MENUITEM "&Rename", ID_EDIT_RENAME > END > > As you can see, there's an accelerator on 3 out of 4 entries. For > consistency sake, the remaining one should have one as well. > I'll send a patch for this. > >> -- >> Nicolas Le Cam > > Frédéric Delanoy > IMHO it isn't. It duplicates Windows behaviour : Modify / Delete and Rename have accelerators, Modify Binary Data doesn't. -- Nicolas Le Cam

May 6, 2011

Re: winscard/tests: Implement test for two functions of winscard.dll

by Marvin

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

May 6, 2011

Re: winscard/tests: Implement test for two functions of winscard.dll

by Marvin

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

May 6, 2011

Re: po: Update French translation

by Frédéric Delanoy

2011/5/6 Nicolas Le Cam <niko.lecam(a)gmail.com>: >> #: 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. Well actually, it's more like an error/omission in the original En version. POPUP "" BEGIN MENUITEM "&Modify...", ID_EDIT_MODIFY MENUITEM "Modify Binary Data...", ID_EDIT_MODIFY_BIN MENUITEM SEPARATOR MENUITEM "&Delete\tDel", ID_EDIT_DELETE MENUITEM "&Rename", ID_EDIT_RENAME END As you can see, there's an accelerator on 3 out of 4 entries. For consistency sake, the remaining one should have one as well. I'll send a patch for this. > -- > Nicolas Le Cam Frédéric Delanoy

May 6, 2011

Re: wineoss.drv: Add mmdevapi driver.

by Gerald Pfeifer

On Fri, 29 Apr 2011, Gerald Pfeifer wrote: > commit be332326ba8fc3def406c5f29adf04fbe9a83976 > Author: Andrew Eikum <aeikum(a)codeweavers.com> > Date: Wed Apr 27 09:12:36 2011 -0500 > > is causing the following build failures on my nightly FreeBSD testers: > > mmdevdrv.c:463:20: error: 'AFMT_S24_PACKED' undeclared (first use in this function) > mmdevdrv.c:476:16: error: 'AFMT_FLOAT' undeclared (first use in this function) > mmdevdrv.c:854:24: error: 'AFMT_FLOAT' undeclared (first use in this function) > mmdevdrv.c:863:24: error: 'AFMT_S24_PACKED' undeclared (first use in this function) > mmdevdrv.c:1084:24: error: 'SNDCTL_DSP_HALT' undeclared (first use in this function) > > Looks like some autoconfigury is not working or incomplete? This has now been broken for a week; when are you planning on fixing this, Andrew? If not, any pointers on how to best approach this? I checked, and AFMT_FLOAT is not defined in /usr/include on either my FreeBSD 8.2 tester nor my openSUSE 11.4 machine, whereas other AFMT_ strings are. Similarly for AFMT_S24_PACKED and SNDCTL_DSP_HALT. Gerald

May 5, 2011

avicap32: fix build with recent kernel headers

by Rafał Mużyło

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.

May 5, 2011

Re: po: Update French translation

by Nicolas Le Cam

> #: 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

May 5, 2011

Re: Strange zero operation in dlls/riched20/tests/editor.c (Coverity)

by Dylan Smith

On Thu, May 5, 2011 at 11:39 AM, Marcus Meissner <meissner(a)suse.de> wrote: > 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? > > Yes, I believe you are right. Thanks for catching that.

May 5, 2011

Re: [3/3] msxml3/domdoc: Add support for VT_ARRAY|VT_UI1 in domdoc_load(). (try 2)

by Adam Martinson

On 05/05/2011 09:37 AM, Nikolay Sivov wrote: > On 5/5/2011 18:14, Adam Martinson wrote: >> I think this is actually the most straightforward/readable way to >> handle it. If multi-dimensional SAFEARRAYs are actually supported, >> we will need separate cases for them. > It's just not the way I thought about it, that's all. Ok, let it be > like that, but could you remove ERR() from it? I feel like it will be > useless line that never works, on the other hand we should add dumping > of array dimension in debugstr_variant() so it will be instantly > visible in trace. It's code that *shouldn't* ever execute AFAIK, that's why I used ERR(). >> And IMHO if an app is trying to do something we don't handle, and >> don't know how it should be handled, it should be a FIXME. > Well ok, I don't really expect it to come often. > I don't either, but it makes debugging a lot easier if it ever does, lol. I think it's just good practice for API functions to complain when they don't know how to handle their args.

May 5, 2011

Re: [2/3] msxml3/domdoc: Add an internal function to load from a UTF8 string.

by Adam Martinson

On 05/05/2011 09:21 AM, Nikolay Sivov wrote: > On 5/5/2011 18:09, Adam Martinson wrote: >> On 05/04/2011 05:56 PM, Nikolay Sivov wrote: >>> You don't need a separate helper for that. doparse() should do fine >>> with "UTF-8" encoding parameter to force encoding. >> This is to avoid calling domdoc_loadXML() from domdoc_load(). When >> we need almost identical behavior from 2 separate interface functions >> having a common internal function they both call makes sense to me... > My point is that we already have doparse(This, str, len, "UTF-8"); > that does exactly what you need. Side effects like setting creating > xmlDocNew(NULL) are handled later in ::load() too. Also ::loadXML() > takes BSTR that's always UTF-16, and we don't do it right now - cause > it's possible to avoid conversion it seems. Adding load_utf8 will mean > we stick to the utf16 -> utf8 conversion in loadXML. > My logic for having this function: domdoc_load() is basically a more flexible version of domdoc_loadXML() that takes a VARIANT instead of a BSTR, and treats its input as a file of some sort. But VT_ARRAY|VT_UI1 case is just a non-null-terminated string, which is more like what domdoc_loadXML() does. To me it makes sense to merge this case with the internal domdoc_loadXML() implementation. I vaguely remember trying to avoid the conversion in domdoc_loadXML() and just passing the BSTR to doparse() with encoding="UTF-16", and running into some quirk in libxml... If memory serves it was that when there's a <?xml encoding="foo"?> declaration in the string that doesn't match the actual encoding, libxml had a fit if the actual encoding wasn't UTF-8. eg, passing a UTF-16 string that contained <?xml encoding="UTF-8"?> caused an error, but passing a UTF-8 string that contained <?xml encoding="UTF-16"?> did not. It's been a while though, it may be worth another look.

May 5, 2011

Strange zero operation in dlls/riched20/tests/editor.c (Coverity)

by Marcus Meissner

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

May 5, 2011

Re: [3/3] msxml3/domdoc: Add support for VT_ARRAY|VT_UI1 in domdoc_load(). (try 2)

by Nikolay Sivov

On 5/5/2011 18:14, Adam Martinson wrote: > On 05/04/2011 06:04 PM, Nikolay Sivov wrote: >> 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. > I think this is actually the most straightforward/readable way to > handle it. If multi-dimensional SAFEARRAYs are actually supported, we > will need separate cases for them. It's just not the way I thought about it, that's all. Ok, let it be like that, but could you remove ERR() from it? I feel like it will be useless line that never works, on the other hand we should add dumping of array dimension in debugstr_variant() so it will be instantly visible in trace. > And IMHO if an app is trying to do something we don't handle, and > don't know how it should be handled, it should be a FIXME. Well ok, I don't really expect it to come often.

May 5, 2011

Re: [2/3] msxml3/domdoc: Add an internal function to load from a UTF8 string.

by Nikolay Sivov

On 5/5/2011 18:09, Adam Martinson wrote: > On 05/04/2011 05:56 PM, Nikolay Sivov wrote: >> You don't need a separate helper for that. doparse() should do fine >> with "UTF-8" encoding parameter to force encoding. > This is to avoid calling domdoc_loadXML() from domdoc_load(). When we > need almost identical behavior from 2 separate interface functions > having a common internal function they both call makes sense to me... My point is that we already have doparse(This, str, len, "UTF-8"); that does exactly what you need. Side effects like setting creating xmlDocNew(NULL) are handled later in ::load() too. Also ::loadXML() takes BSTR that's always UTF-16, and we don't do it right now - cause it's possible to avoid conversion it seems. Adding load_utf8 will mean we stick to the utf16 -> utf8 conversion in loadXML.

May 5, 2011

Re: [3/3] msxml3/domdoc: Add support for VT_ARRAY|VT_UI1 in domdoc_load(). (try 2)

by Adam Martinson

On 05/04/2011 06:04 PM, Nikolay Sivov wrote: > 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. I think this is actually the most straightforward/readable way to handle it. If multi-dimensional SAFEARRAYs are actually supported, we will need separate cases for them. And IMHO if an app is trying to do something we don't handle, and don't know how it should be handled, it should be a FIXME.

May 5, 2011

Re: [2/3] msxml3/domdoc: Add an internal function to load from a UTF8 string.

by Adam Martinson

On 05/04/2011 05:56 PM, Nikolay Sivov wrote: > You don't need a separate helper for that. doparse() should do fine > with "UTF-8" encoding parameter to force encoding. This is to avoid calling domdoc_loadXML() from domdoc_load(). When we need almost identical behavior from 2 separate interface functions having a common internal function they both call makes sense to me... > Also will it preserve existing document or will really create empty > one on error is a question. Yes, that's something we should add tests for in the future.

May 5, 2011

Re: cmd: WCMD_delete: simplify logic, avoid assigning variable to i tself (try 2)

by Alexandre Julliard

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

May 5, 2011

Re: [PATCH 1/2] mountmgr: Populate HKLM\HARDWARE\DEVICEMAP\Scsi here instead of in kernel32. (try 4)

by Alexandre Julliard

Charles Davis <cdavis(a)mymail.mines.edu> writes: > + case 0x05: > + data = "CdRomPeripheral"; > + snprintf(buffer, sizeof(buffer), "Cdrom%d", cdrom_no++); > + break; This needs to be set to the device name that mountmgr has assigned to it. That's the point of doing this in mountmgr: making sure that all the information derives from a single source. -- Alexandre Julliard julliard(a)winehq.org

May 5, 2011

Re: [PATCH try3] wininet: Added support for persistent HTTP connections

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > try3: I've included better content draining in this patch (that I was > hoping to do as follow-up previously, due to already big size of the > patch). That fixes observed test failures. Older wininet implementations > don't have it, so the test fails for them. I'm getting a different failure now: ../../../tools/runtest -q -P wine -M wininet.dll -T ../../.. -p wininet_test.exe.so http.c && touch http.ok http.c:1074: Test failed: Read 0 bytes instead of 13 make: *** [http.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

May 5, 2011

Re: [3/3] msxml3/domdoc: Add support for VT_ARRAY|VT_UI1 in domdoc_load(). (try 2)

by Nikolay Sivov

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.

May 4, 2011

Re: [2/3] msxml3/domdoc: Add an internal function to load from a UTF8 string.

by Nikolay Sivov

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.

May 4, 2011

Re: [2/2] msxml3/domdoc: Add support for VT_ARRAY|VT_UI1 in domdoc_load().

by Nikolay Sivov

On 5/4/2011 19:30, Adam Martinson wrote: > On 05/03/2011 05:30 PM, Nikolay Sivov wrote: >> I'm worried about VT_UI1 being interpreted as ASCII stream or just a >> byte stream that could be in any encoding. If it's a case you can't >> assume it's encoded as utf8, when you do utf8 -> utf16 (for BSTR). >> >> For this particular case you might want direct doparse() call for >> VT_UI1 array, I suggest a simple test -- create byte (VT_UI1) array >> over a WCHAR buffer with UTF16 xml data and try to ::load() from it. >> If encoding is detected then you need direct doparse() call, to do >> completely clear case don't include encoding= attribute in this xml >> data. > I glad you mentioned this, I thought about that too. I did some > testing and it seems that only UTF8 (or maybe just ASCII) is > supported. The SAFEARRAY does seem to be treated more like a file > than a string, eg if there is a '\0' at the end of the array it causes > a parse error (I don't think we need to duplicate that behavior though). Yeah, I don't see a reason to implement this particular case for now. > I'm not sure if multi-dimensional arrays are supported, it will take > some further testing, but if so that can be a separate patch; for now > I'll just add a FIXME if the array is not a vector. I don't expect it's supported, it sounds a bit insane for me to load from multidimensional arrays. I think after this case (VT_UI1 array) implemented we need a WARN for any other variant type. And some tests for sure.

May 4, 2011

Re: Support for D3DQUERY_TIMESTAMP* queries...

by Adam Martinson

OK, I think I addressed those issues, let me know how these look.

May 4, 2011

Re: [PATCH 2/2 try2] wininet: Added support for persistent HTTP connections

by Jacek Caban

On 5/4/11 8:05 PM, Alexandre Julliard wrote: > Jacek Caban<jacek(a)codeweavers.com> writes: > >> That's an already existing race in tests. It fails on Windows as well: >> http://test.winehq.org/data/a343c1fbd0f37a5cadd98698ae5d580727ddf0c7/2003_f… >> I've seen it here and my patch seems to make is more likely to fail. I >> plan fixing it, but, as it's not new, so I think it shouldn't block >> committing my patch. > Maybe it's not new, but it's much worse. That failure used to happen > maybe at most once a week here, but now it's failing 9 times out of 10. > I really don't want to have to always run make test in a loop until it > works. Oh, didn't expect it to be that bad, it fails about 1 out of 5 times here. I will fix the test first then. Jacek

May 4, 2011

Re: [PATCH 2/2 try2] wininet: Added support for persistent HTTP connections

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > That's an already existing race in tests. It fails on Windows as well: > http://test.winehq.org/data/a343c1fbd0f37a5cadd98698ae5d580727ddf0c7/2003_f… > I've seen it here and my patch seems to make is more likely to fail. I > plan fixing it, but, as it's not new, so I think it shouldn't block > committing my patch. Maybe it's not new, but it's much worse. That failure used to happen maybe at most once a week here, but now it's failing 9 times out of 10. I really don't want to have to always run make test in a loop until it works. -- Alexandre Julliard julliard(a)winehq.org

May 4, 2011

Re: [PATCH 2/2 try2] wininet: Added support for persistent HTTP connections

by Jacek Caban

On 05/04/11 16:07, Alexandre Julliard wrote: > Jacek Caban <jacek(a)codeweavers.com> writes: > >> try2: Using GetTickCount64() for timestamps >> >> --- >> dlls/urlmon/tests/protocol.c | 2 +- >> dlls/urlmon/tests/url.c | 20 +- >> dlls/wininet/http.c | 567 >> ++++++++++++++++++++++++------------------ >> dlls/wininet/internet.c | 2 +- >> dlls/wininet/internet.h | 42 +++- >> dlls/wininet/netconnection.c | 138 ++++------- >> dlls/wininet/tests/http.c | 32 +-- >> 7 files changed, 427 insertions(+), 376 deletions(-) > It doesn't work here: > > ../../../tools/runtest -q -P wine -M wininet.dll -T ../../.. -p wininet_test.exe.so http.c && touch http.ok > http.c:2621: Test failed: expected 1 retrievals, got 0 > http.c:2628: Test failed: count was wrong > http.c:2629: Test failed: http data wrong > http.c:2649: Test succeeded inside todo block: expected 1 retrievals > make: *** [http.ok] Error 4 That's an already existing race in tests. It fails on Windows as well: http://test.winehq.org/data/a343c1fbd0f37a5cadd98698ae5d580727ddf0c7/2003_f… I've seen it here and my patch seems to make is more likely to fail. I plan fixing it, but, as it's not new, so I think it shouldn't block committing my patch. Jacek

May 4, 2011

Re: winscard/tests: Add test base functions of winscard.dll

by Marvin

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=10722 Your paranoid android. === WINEBUILD (build) === Make failed

May 4, 2011

Re: [PATCH 2/2 try2] wininet: Added support for persistent HTTP connections

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > try2: Using GetTickCount64() for timestamps > > --- > dlls/urlmon/tests/protocol.c | 2 +- > dlls/urlmon/tests/url.c | 20 +- > dlls/wininet/http.c | 567 > ++++++++++++++++++++++++------------------ > dlls/wininet/internet.c | 2 +- > dlls/wininet/internet.h | 42 +++- > dlls/wininet/netconnection.c | 138 ++++------- > dlls/wininet/tests/http.c | 32 +-- > 7 files changed, 427 insertions(+), 376 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M wininet.dll -T ../../.. -p wininet_test.exe.so http.c && touch http.ok http.c:2621: Test failed: expected 1 retrievals, got 0 http.c:2628: Test failed: count was wrong http.c:2629: Test failed: http data wrong http.c:2649: Test succeeded inside todo block: expected 1 retrievals make: *** [http.ok] Error 4 -- Alexandre Julliard julliard(a)winehq.org

May 4, 2011

Re: [2/2] msxml3/domdoc: Add support for VT_ARRAY|VT_UI1 in domdoc_load().

by Adam Martinson

On 05/03/2011 05:30 PM, Nikolay Sivov wrote: > I'm worried about VT_UI1 being interpreted as ASCII stream or just a > byte stream that could be in any encoding. If it's a case you can't > assume it's encoded as utf8, when you do utf8 -> utf16 (for BSTR). > > For this particular case you might want direct doparse() call for > VT_UI1 array, I suggest a simple test -- create byte (VT_UI1) array > over a WCHAR buffer with UTF16 xml data and try to ::load() from it. > If encoding is detected then you need direct doparse() call, to do > completely clear case don't include encoding= attribute in this xml data. I glad you mentioned this, I thought about that too. I did some testing and it seems that only UTF8 (or maybe just ASCII) is supported. The SAFEARRAY does seem to be treated more like a file than a string, eg if there is a '\0' at the end of the array it causes a parse error (I don't think we need to duplicate that behavior though). I'm not sure if multi-dimensional arrays are supported, it will take some further testing, but if so that can be a separate patch; for now I'll just add a FIXME if the array is not a vector. >> I remember another place where it would have been useful to be able >> to call domdoc_loadXML() with a UTF8 string to avoid converting to >> BSTR and back, I think in the schema stuff. It would be nice to have >> an internal function to do that, then domdoc_loadXML() can just wrap >> it, but I think that can be a separate patch. > Anyway if you need a interface call to implement some other method use > already defined macro instead of internal static implementation > function. Internal method implementations better not depend on each > other. Ye, you're right, I will add that as part of this set.

May 4, 2011

Re: FAQ translation possible?

by Juan Lang

> I tried to find the wiki/web server responsible, but without success. > Who's responsible for the server? J. Newman? In this case, it's Dimi O'Paun. --Juan

May 4, 2011

Re: FAQ translation possible?

by Frédéric Delanoy

On Wed, May 4, 2011 at 07:24, Ove Kåven <ovek(a)arcticnet.no> wrote: > Den 04. mai 2011 00:49, skrev Frédéric Delanoy: >> But in any case, the language to use should preferably be autoselected >> from WineHQ's lang cookie IMHO. > > The way I understand moinmoin, you need to create a new wiki page with > the translated content. This is typically done by also translating the > page name itself, i.e. if you have an English "MyProject", then you have > a "MeinProjekt" page in German. Anyway, the version of moinmoin used here is dated and doesn't support on-page-change notification, which makes translation (but especially further maintainance) tricky. I tried to find the wiki/web server responsible, but without success. Who's responsible for the server? J. Newman? > Once the translation exist, you can update moinmoin's dictionary page > (the GermanDict page in this case), so that it knows that MeinProjekt is > a German translation of MyProject. With that done, if a German user > accesses MyProject, there will be a toolbar entry to take them to the > German version. > > MoinMoin can do even better for the front page, because if the user > accesses the wiki without requesting a specific page, then moinmoin can > itself choose which front page to return. It's chosen based on the > preferred language of the user's browser, and it will search its > dictionary to find what the name of that language's front page is. So > German people would automatically get StartSeite instead of FrontPage. > > Then, of course, that front page would contain links to the pages of the > language it is written in. So German users would automatically be served > the German frontpage, and all German pages (like StartSeite) would link > to MeinProjekt where the English pages (like FrontPage) would link to > MyProject. > > This scheme, of course, works best if the people putting content into > the wiki are careful not to use acronyms like FAQ as page names. Thanks for the info. Frédéric

May 4, 2011

signal(SIGCHLD,SIG_DFL) before exec()

by Ilya Basin

Hi list. I suffer from this bug: http://bugs.winehq.org/show_bug.cgi?id=27014 In wine sources there're not so many places where exec(3) family is used. In some places SIGCHLD and SIGPIPE are restored to default before calling exec(), in others they aren't. What's the difference? Can anyone explain me the why SIGCHLD not restored to default before calling execvp() here: http://source.winehq.org/source/libs/port/spawn.c?v=wine-1.3.19#L42 int spawnvp(int mode, const char *cmdname, const char *const argv[]) { ... if (mode == _P_OVERLAY) { execvp(cmdname, (char **)argv); /* if we get here it failed */ #ifdef ENOTSUP if (errno != ENOTSUP) /* exec fails on MacOS if the process has multiple threads */ #endif return -1; } Because it's not forked and if execvp() fails, we end up with the default handler?

May 4, 2011

Re: FAQ translation possible?

by Ove Kåven

Den 04. mai 2011 00:49, skrev Frédéric Delanoy: > But in any case, the language to use should preferably be autoselected > from WineHQ's lang cookie IMHO. The way I understand moinmoin, you need to create a new wiki page with the translated content. This is typically done by also translating the page name itself, i.e. if you have an English "MyProject", then you have a "MeinProjekt" page in German. Once the translation exist, you can update moinmoin's dictionary page (the GermanDict page in this case), so that it knows that MeinProjekt is a German translation of MyProject. With that done, if a German user accesses MyProject, there will be a toolbar entry to take them to the German version. MoinMoin can do even better for the front page, because if the user accesses the wiki without requesting a specific page, then moinmoin can itself choose which front page to return. It's chosen based on the preferred language of the user's browser, and it will search its dictionary to find what the name of that language's front page is. So German people would automatically get StartSeite instead of FrontPage. Then, of course, that front page would contain links to the pages of the language it is written in. So German users would automatically be served the German frontpage, and all German pages (like StartSeite) would link to MeinProjekt where the English pages (like FrontPage) would link to MyProject. This scheme, of course, works best if the people putting content into the wiki are careful not to use acronyms like FAQ as page names.

May 4, 2011

Re: FAQ translation possible?

by Frédéric Delanoy

2011/5/3 Juan Lang <juan.lang(a)gmail.com>: >> Wouldn't it make sense to move the FAQ to the wine website repository >> so as to ease translation? FAQ is probably one of the most important >> things to translate IMO. > > We've recently moved it the other way. > >> Or is it more important to remain it to the wiki for quick update/review? > > Yes, that's why it's in the wiki. > --Juan Hmm... makes sense but this makes translation nigh impossible. I could certainly create a custom Fr FAQ but it's more like an ugly hack (and translation updates could prove difficult than they should be... or maybe with on-change email notification?). >From a quick review of moinmoin features (http://moinmo.in/MoinMoinFeatures) it seems i18n is possible but I'm far from an expert in it, although it appears it's possible only for the wiki interface, and not for the wiki's actual contents. But in any case, the language to use should preferably be autoselected from WineHQ's lang cookie IMHO. Maybe someone with moinmoin experience could provide some insight (specifying in language in a page seems possible according to http://moinmo.in/HelpOnLanguages)? Frédéric

May 3, 2011

Re: [2/2] msxml3/domdoc: Add support for VT_ARRAY|VT_UI1 in domdoc_load().

by Nikolay Sivov

On 5/3/2011 18:43, Adam Martinson wrote: > On 05/03/2011 01:45 AM, Nikolay Sivov wrote: >> On 5/3/2011 08:07, Adam Martinson wrote: >>> >>> Fixes bug 14864. >>> --- >>> dlls/msxml3/domdoc.c | 255 >>> ++++++++++++++++++++++++++------------------------ >>> 1 files changed, 134 insertions(+), 121 deletions(-) >>> >>> + case VT_ARRAY|VT_UI1: >>> + { >>> + SAFEARRAY* psa; >>> + BSTR bstr; >>> + psa = V_ARRAY(&source); >>> + bstr = bstr_from_xmlChar(psa->pvData); >>> + hr = domdoc_loadXML(iface, bstr, isSuccessful); >>> + SysFreeString(bstr); >>> + return hr; >>> + } >>> + break; >> Is it really supposed to be utf8 array? Or this will work cause >> one-byte chars match utf8? >> >> Also I don't like this method dependency, I think the proper way is >> to call IXMLDOMDocument3_loadXML(iface...) here. >> Or another way to avoid call through vtable - introduce something >> called domdoc_load_xml(This...) and use it in both places, >> but I think it's not worth it. > > It was the Google Chrome installer, I'm not sure if it's supposed to > be UTF8 or not, all of the characters it used were ASCII. I'm > assuming it's supposed to be UTF8 due to it being VT_UI8 instead of > VT_I8, but I can't say for sure. I'm worried about VT_UI1 being interpreted as ASCII stream or just a byte stream that could be in any encoding. If it's a case you can't assume it's encoded as utf8, when you do utf8 -> utf16 (for BSTR). For this particular case you might want direct doparse() call for VT_UI1 array, I suggest a simple test -- create byte (VT_UI1) array over a WCHAR buffer with UTF16 xml data and try to ::load() from it. If encoding is detected then you need direct doparse() call, to do completely clear case don't include encoding= attribute in this xml data. > I remember another place where it would have been useful to be able > to call domdoc_loadXML() with a UTF8 string to avoid converting to > BSTR and back, I think in the schema stuff. It would be nice to have > an internal function to do that, then domdoc_loadXML() can just wrap > it, but I think that can be a separate patch. Anyway if you need a interface call to implement some other method use already defined macro instead of internal static implementation function. Internal method implementations better not depend on each other.

May 3, 2011

Re: [PATCH 2/2] wininet: Added support for persistent HTTP connections

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > +static DWORD64 collector_timeout; > + > +static DWORD64 current_time(void) > +{ > + ULARGE_INTEGER timeout; > + SYSTEMTIME st; > + FILETIME ft; > + > + GetSystemTime(&st); > + SystemTimeToFileTime(&st, &ft); > + > + timeout.u.LowPart = ft.dwLowDateTime; > + timeout.u.HighPart = ft.dwHighDateTime; > + > + return timeout.QuadPart; > +} That's a lot of complexity for a timestamp, GetTickCount() would work just as well, as long as you do the comparisons correctly. -- Alexandre Julliard julliard(a)winehq.org

May 3, 2011

Re: [PATCH 3/5] d3d8/tests: Fix some failure messages in test_depth_stencil_size().

by Henri Verbeet

On 3 May 2011 22:59, Marvin <testbot(a)testbot.winehq.org> wrote: > === WXPPROSP3 (32 bit device) === > TestLauncher.c:89: Test failed: Can't open test executable C:\winetest\d3d8_test.exe, error 32 > I don't think this patch introduced this failure.

May 3, 2011

Re: [PATCH 4/5] d3d8/tests: Add a Reset test.

by Marvin

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=10710 Your paranoid android. === WXPPROSP3 (32 bit device) === TestLauncher.c:89: Test failed: Can't open test executable C:\winetest\d3d8_test.exe, error 32

May 3, 2011

Re: [PATCH 3/5] d3d8/tests: Fix some failure messages in test_depth_stencil_size().

by Marvin

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=10709 Your paranoid android. === WXPPROSP3 (32 bit device) === TestLauncher.c:89: Test failed: Can't open test executable C:\winetest\d3d8_test.exe, error 32

May 3, 2011

Re: [2/2] msxml3/domdoc: Add support for VT_ARRAY|VT_UI1 in domdoc_load().

by Adam Martinson

On 05/03/2011 09:43 AM, Adam Martinson wrote: > On 05/03/2011 01:45 AM, Nikolay Sivov wrote: >> On 5/3/2011 08:07, Adam Martinson wrote: >>> >>> Fixes bug 14864. >>> --- >>> dlls/msxml3/domdoc.c | 255 >>> ++++++++++++++++++++++++++------------------------ >>> 1 files changed, 134 insertions(+), 121 deletions(-) >>> >>> + case VT_ARRAY|VT_UI1: >>> + { >>> + SAFEARRAY* psa; >>> + BSTR bstr; >>> + psa = V_ARRAY(&source); >>> + bstr = bstr_from_xmlChar(psa->pvData); >>> + hr = domdoc_loadXML(iface, bstr, isSuccessful); >>> + SysFreeString(bstr); >>> + return hr; >>> + } >>> + break; >> Is it really supposed to be utf8 array? Or this will work cause >> one-byte chars match utf8? >> >> Also I don't like this method dependency, I think the proper way is >> to call IXMLDOMDocument3_loadXML(iface...) here. >> Or another way to avoid call through vtable - introduce something >> called domdoc_load_xml(This...) and use it in both places, >> but I think it's not worth it. > > It was the Google Chrome installer, I'm not sure if it's supposed to > be UTF8 or not, all of the characters it used were ASCII. I'm > assuming it's supposed to be UTF8 due to it being VT_UI8 instead of > VT_I8, but I can't say for sure. I remember another place where it > would have been useful to be able to call domdoc_loadXML() with a UTF8 > string to avoid converting to BSTR and back, I think in the schema > stuff. It would be nice to have an internal function to do that, then > domdoc_loadXML() can just wrap it, but I think that can be a separate > patch. > Err, VT_I1/VT_UI1, not VT_I8/VT_UI8.

May 3, 2011

Re: Support for D3DQUERY_TIMESTAMP* queries...

by Henri Verbeet

On 3 May 2011 16:51, Adam Martinson <amartinson(a)codeweavers.com> wrote: > Feedback please. This is in addition to what Stefan already said: > +/* GL_ARB_timer_query */ > +#ifndef GL_ARB_timer_query > +#define GL_ARB_timer_query 1 > +#define GL_TIME_ELAPSED_ARB 0x88BF > +#define GL_TIMESTAMP_ARB 0x8E28 > +#endif > + > +typedef void (WINE_GLAPI *PFNGLQUERYCOUNTERPROC) (GLuint id, GLenum target); > +typedef void (WINE_GLAPI *PFNGLGETQUERYOBJECTI64VPROC) (GLuint id, GLenum pname, GLint64 *params); > +typedef void (WINE_GLAPI *PFNGLGETQUERYOBJECTUI64VPROC) (GLuint id, GLenum pname, GLuint64 *params); Where did you get these? The style reminds me of glext.h. > @@ -95,26 +95,31 @@ static HRESULT WINAPI IDirect3DQuery9Impl_GetDevice(IDirect3DQuery9 *iface, > static D3DQUERYTYPE WINAPI IDirect3DQuery9Impl_GetType(IDirect3DQuery9 *iface) > { > IDirect3DQuery9Impl *This = impl_from_IDirect3DQuery9(iface); > - HRESULT hr; > + D3DQUERYTYPE ret; > > TRACE("iface %p.\n", iface); > > wined3d_mutex_lock(); > - hr = wined3d_query_get_type(This->wineD3DQuery); > + ret = wined3d_query_get_type(This->wineD3DQuery); > wined3d_mutex_unlock(); > > - return hr; > + return ret; > } This makes sense, but should clearly be a separate patch. If you're changing the name anyway, "type" would probably be a more reasonable name than "ret". > +struct _wined3d_timestamp_query > +{ > + struct list entry; > + struct wined3d_context *context; > + int n_ids; > + GLuint ids[1]; > +}; ... > + query->extendedData = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(struct _wined3d_timestamp_query)); ... > +struct wined3d_timestamp_query > +{ > + struct list entry; > + struct wined3d_context *context; > + int n_ids; > + GLuint ids[]; > +}; That's ugly and fragile. Please try to write coherent patches. Patch 4/7 in particular looks like it was just copy-pasted together. Patch 5/7 could have easily been at least 4 separate patches.

May 3, 2011

Re: Support for D3DQUERY_TIMESTAMP* queries...

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 03.05.2011 um 16:51 schrieb Adam Martinson: > +#ifndef WINE_NO_TRACE_MSGS > + for (; i < query->n_ids; ++i) > + TRACE("Allocated timestamp query %u in context %p.\n", query->ids[i], context); > +#endif use if(TRACE_ON(d3d)) instead. It'll be statically FALSE if there are no trace messages, and you also avoid the loop at runtime when traces aren't on. > +struct _wined3d_timestamp_query > +{ > + struct list entry; > + struct wined3d_context *context; > + int n_ids; > + GLuint ids[1]; > +}; I'm not sure if this is necessary, I think we can just give struct wined3d_timestamp_query a ids[3] field. > +typedef struct D3D10_QUERY_DATA_TIMESTAMP_DISJOINT { > + UINT64 Frequency; > + BOOL Disjoint; > +} D3D10_QUERY_DATA_TIMESTAMP_DISJOINT; Wrong code style, it looks like you copypasted .idl code into a .c file. Please define this in wined3d.idl using WINED3D_QUERY_... names. The wined3d.idl file will soon be gone and replaced with a plain .h header. If you don't need those types for implementing the d3d9 queries ignore the d3d10 stuff for now. > + static BOOL warned = FALSE; > + if (!warned) > + { > + WARN("GL_ARB_timer_query not supported, returning WINED3DERR_NOTAVAILABLE\n"); > + warned = TRUE; > + } I don't think we have to limit WARNs to one output only. WARNs aren't shown by default. This kind of limiting is used for FIXMEs only to make sure repeated FIXMEs don't spam the terminal and hide other output. I have to go now, I'll be back later. If I have time and am not tired I'll read this a bit more and check the tests. But probably Henri has sent some comments by then too. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJNwDRoAAoJEN0/YqbEcdMwC+oQAJGAxuDNh2bGbBNGuFs5uxXo Jkf7+Kgb4aXuhYReGzCX5l1nYK82UBMGWC4j53tKWnziw4VueHuyuKwpmHO+EpRk cjgz5pi4WBT3EGTuvCbnQ9ayOKRI76OKa45mD0uFCMvsM/cHKh0QcUJD4SpkmHLM 97sZuNpBuWy6vqNTfSgTirpQCI/gBUlQZVHKBesVhsJJ7yVZG5TgZjARKasYzoVg Q6hHKK6qWby2NnawYpKQp51ie0OV3W65JZPHQ3fn+3ogrCcsL27u2SQE8MqHhKt4 PYxzGRfl+LCjdIIJ7UekXKawFlh6DqCF+j+9KEonJwSVzduj96Y+j0La5QML9eFW Kjk53LLgzrb8kQcSmMS6YLNot158am4twu9uE8Lf6KjO5ADXIdRqdISFCipqecu/ cJc0IyYEaKgcrFaRcCRuPtZreXaK8QjH0n7KzvEW9I+74UN0cegTIN37yIeAwev+ oPYTwGr6fUHtOUQ/8t/jYMvgm0Up8kLnK9OU9LWJPcTOVh+BtyeKI2vmg/QPvCCk lbPLuZD59JHdxyBDrKqYqyxIRcX6aLGctnRH5t+QVh5RHLmr8rcbZDm3JIEsDyHN dUE41KiDa/oad76pSW5OL2NU+QHLbVgnJ6IQjGQSdH7gF4zkLHX8VYTaWdFqYRMy U2KFQKkMYUCWBaGxaS4B =jvdN -----END PGP SIGNATURE-----

May 3, 2011

msvcrt: Add tests to show that utime() can take a NULL-pointer for the utimbuf structure field

by Joerg-Cyril.Hoehle＠t-systems.com

Louis, >Anything i could do to improve to get it in? Perhaps http://source.winehq.org/patches/ shows that you should get rid of the one apply failure. Basically, your patch does the right thing, as MSDN says "If times is a NULL pointer, the modification time is set to the current local time." -- like POSIX. >-#if(0) /* FIXME: this test crashes wine, remove this line when wine is fixed */ People here prefer if(0) so that the compiler can still validate the form of the code. I've been even been using if (winetest_debug>1) so I can direct testbot to run the additional test. Finally, why not merge the two? After all, it's one change, and several tests. Why do you call it test_utime() since you don't verify the effects of utime()? Regards, Jörg Höhle

May 3, 2011

Re: [PATCH 2/4] wintrust: Added CryptSIPPutSignedDataMsg implementation (for PE files)

by Piotr Caban

On 05/03/11 13:07, Piotr Caban wrote: > --- > dlls/wintrust/crypt.c | 66 ++++++++++++++++++++++++++++++++++++++++++------ > 1 files changed, 57 insertions(+), 9 deletions(-) Patches 2 and 3 in this series are not correct. Please ignore them.

May 3, 2011

Re: FAQ translation possible?

by Juan Lang

> Wouldn't it make sense to move the FAQ to the wine website repository > so as to ease translation? FAQ is probably one of the most important > things to translate IMO. We've recently moved it the other way. > Or is it more important to remain it to the wiki for quick update/review? Yes, that's why it's in the wiki. Thanks, --Juan

May 3, 2011

FAQ translation possible?

by Frédéric Delanoy

Hi, I'm currently revising/translating WineHQ's website French translation. Translating the help, I remarked the FAQ is maintained in the wiki section. Wouldn't it make sense to move the FAQ to the wine website repository so as to ease translation? FAQ is probably one of the most important things to translate IMO. Is the wiki page somehow translatable (preferably using WineHQ's language cookie setting)? Or is it more important to remain it to the wiki for quick update/review? Frédéric Delanoy

May 3, 2011

Support for D3DQUERY_TIMESTAMP* queries...

by Adam Martinson

Feedback please.

May 3, 2011

Re: [2/2] msxml3/domdoc: Add support for VT_ARRAY|VT_UI1 in domdoc_load().

by Adam Martinson

On 05/03/2011 01:45 AM, Nikolay Sivov wrote: > On 5/3/2011 08:07, Adam Martinson wrote: >> >> Fixes bug 14864. >> --- >> dlls/msxml3/domdoc.c | 255 >> ++++++++++++++++++++++++++------------------------ >> 1 files changed, 134 insertions(+), 121 deletions(-) >> >> + case VT_ARRAY|VT_UI1: >> + { >> + SAFEARRAY* psa; >> + BSTR bstr; >> + psa = V_ARRAY(&source); >> + bstr = bstr_from_xmlChar(psa->pvData); >> + hr = domdoc_loadXML(iface, bstr, isSuccessful); >> + SysFreeString(bstr); >> + return hr; >> + } >> + break; > Is it really supposed to be utf8 array? Or this will work cause > one-byte chars match utf8? > > Also I don't like this method dependency, I think the proper way is to > call IXMLDOMDocument3_loadXML(iface...) here. > Or another way to avoid call through vtable - introduce something > called domdoc_load_xml(This...) and use it in both places, > but I think it's not worth it. It was the Google Chrome installer, I'm not sure if it's supposed to be UTF8 or not, all of the characters it used were ASCII. I'm assuming it's supposed to be UTF8 due to it being VT_UI8 instead of VT_I8, but I can't say for sure. I remember another place where it would have been useful to be able to call domdoc_loadXML() with a UTF8 string to avoid converting to BSTR and back, I think in the schema stuff. It would be nice to have an internal function to do that, then domdoc_loadXML() can just wrap it, but I think that can be a separate patch.

May 3, 2011

Re: [PATCH 3/4] d3dx9: Implement ID3DXBaseEffect::GetPixelShader().

by Henri Verbeet

2011/5/3 Rico Schüller <kgbricola(a)web.de>: > +#define SAFE_ADDREF(x) if(x) IUnknown_AddRef(x) > +#define SAFE_RELEASE(x) if(x) IUnknown_Release(x) That's not so safe, actually. Consider e.g. what happens when "x" has side effects, or when you write something like "if (cond) SAFE_ADDREF(x); else return;". If you really want this an inline function should do just as well, but for the handful of uses I see in this series it just obfuscates the code.

May 3, 2011

msvcrt: Add tests to show that utime() can take a NULL-pointer for the utimbuf structure field

by Louis Lenders

See http://www.winehq.org/pipermail/wine-patches/2011-April/101371.html Anything i could do to improve to get it in?

May 3, 2011

Re: ddraw (try 2): Add a few tests for Setcooperativelevel

by Marvin

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=10695 Your paranoid android. === WNT4WSSP6 (32 bit ddrawmodes) === ddrawmodes.c:800: Test failed: SetCooperativelevel(DDSCL_SETFOCUSWINDOW) returned: 80070057 ddrawmodes.c:803: Test failed: SetCooperativelevel(DDSCL_CREATEDEVICEWINDOW | DDSCL_EXCLUSIVE | DDSCL_FULLSCREEN) returned: 80070057 ddrawmodes.c:828: Test failed: SetCooperativelevel(DDSCL_SETFOCUSWINDOW) returned: 80070057 === W7PROX64 (64 bit ddrawmodes) === Timeout

May 3, 2011

Re: [2/2] msxml3/domdoc: Add support for VT_ARRAY|VT_UI1 in domdoc_load().

by Nikolay Sivov

On 5/3/2011 08:07, Adam Martinson wrote: > > Fixes bug 14864. > --- > dlls/msxml3/domdoc.c | 255 > ++++++++++++++++++++++++++------------------------ > 1 files changed, 134 insertions(+), 121 deletions(-) > > + case VT_ARRAY|VT_UI1: > + { > + SAFEARRAY* psa; > + BSTR bstr; > + psa = V_ARRAY(&source); > + bstr = bstr_from_xmlChar(psa->pvData); > + hr = domdoc_loadXML(iface, bstr, isSuccessful); > + SysFreeString(bstr); > + return hr; > + } > + break; Is it really supposed to be utf8 array? Or this will work cause one-byte chars match utf8? Also I don't like this method dependency, I think the proper way is to call IXMLDOMDocument3_loadXML(iface...) here. Or another way to avoid call through vtable - introduce something called domdoc_load_xml(This...) and use it in both places, but I think it's not worth it.

May 3, 2011

Re: [PATCH 1/2] d3d9/tests: Added a test for resetting an invisible, inactive window to fullscreen mode.

by Henri Verbeet

On 2 May 2011 13:24, Marvin <testbot(a)testbot.winehq.org> wrote: > === WXPPROSP3 (32 bit device) === > device: unhandled exception c0000005 at 0040320F > For what it's worth, not sure if you figured this out by yourself yet or not, but you need to handle create_device() failing to create a device on machines like the testbot that don't have D3D hardware.

May 2, 2011

Re: [PATCH 2/2] wined3d: Turn off message filtering temporarily in the Reset() method to allow certain messages (e.g. WM_ACTIVATEAPP) through.

by Henri Verbeet

On 2 May 2011 23:28, John Edmonds <pocketcookies2(a)gmail.com> wrote: > Are you suggesting that we turn off message filtering altogether or just for > the Reset function? > Just Reset().

May 2, 2011

Re: [PATCH 2/2] wined3d: Turn off message filtering temporarily in the Reset() method to allow certain messages (e.g. WM_ACTIVATEAPP) through.

by John Edmonds

Are you suggesting that we turn off message filtering altogether or just for the Reset function? I would like to add that I did disable all message filtering (by commenting out the code in Wine's wndproc) and the games I was testing worked fine. However, I did not investigate the effects of that change very thoroughly. On May 2, 2011 7:52 AM, "Henri Verbeet" <hverbeet(a)gmail.com> wrote: > On 2 May 2011 13:18, John Edmonds <pocketcookies2(a)gmail.com> wrote: >> Toki Tori and RUSH both depend on receing WM_ACTIVATEAPP before they will start. These messages are currently getting filtered out. >> This resolves bug #25640. > > It doesn't look right to me to filter messages during > IWineD3DDevice_ReleaseFocusWindow() but not > IWineD3DDevice_AcquireFocusWindow(). Maybe it just shouldn't filter at > all. > >

May 2, 2011

Working on UpdateSemantics or D3DXWeldVertices in D3DX9?

by Michael Mc Donnell

Hi Guys! I'm doing Google Summer of Code 2011 and found out that some of the functions I was to implement have been implemented while my application was being processed. This means I have to find some other functions in D3DX9 to implement. I see that UpdateSemantics and D3DXWeldVertices are unimplemented in D3DX9, and was wondering if anyone is working on these? Cheers, Michael

May 2, 2011

Re: comctl32: avoid using ZeroMemory()

by Austin English

On Mon, May 2, 2011 at 10:58, Marcus Meissner <meissner(a)suse.de> wrote: > On Mon, May 02, 2011 at 10:52:50AM -0500, Austin English wrote: >> Avoids a Clang bug: >> http://bugs.winehq.org/show_bug.cgi?id=26754 > > clang cannot even survive a simple memset() to 0? http://llvm.org/bugs/show_bug.cgi?id=9830 -- -Austin

May 2, 2011

Re: comctl32: avoid using ZeroMemory()

by Marcus Meissner

On Mon, May 02, 2011 at 10:52:50AM -0500, Austin English wrote: > Avoids a Clang bug: > http://bugs.winehq.org/show_bug.cgi?id=26754 clang cannot even survive a simple memset() to 0? Ciao, Marcus

May 2, 2011