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