August 2010 - Wine-Devel - list.winehq.org

Re: msvcrt:locale Properly fix setlocale()

by Alexandre Julliard

Alexandre Goujon <ale.goujon(a)gmail.com> writes: > @@ -431,7 +431,7 @@ static void test_setlocale(void) > ret = setlocale(LC_ALL, "non"); > ok(ret != NULL || broken (ret == NULL), "ret == NULL\n"); > if(ret) > - todo_wine ok((!strcmp( ret, "Norwegian-Nynorsk_Norway.1252")) > + ok((!strcmp( ret, "Norwegian-Nynorsk_Norway.1252")) > || broken(!strcmp(ret, "Norwegian (Bokmål)_Norway.1252")) > || broken(!strcmp(ret, "Norwegian_Norway.1252")) > || broken(!strcmp(ret, "Norwegian (Nynorsk)_Norway.1252")), "ret = %s\n", ret); > @@ -453,7 +453,7 @@ static void test_setlocale(void) > ret = setlocale(LC_ALL, "norwegian-nynorsk"); > ok(ret != NULL || broken (ret == NULL), "ret == NULL\n"); > if(ret) > - todo_wine ok(!strcmp(ret, "Norwegian-Nynorsk_Norway.1252") > + ok(!strcmp(ret, "Norwegian-Nynorsk_Norway.1252") > || broken(!strcmp(ret, "Norwegian_Norway.1252")) > || broken(!strcmp(ret, "Norwegian (Nynorsk)_Norway.1252")) > || broken(!strcmp(ret, "Norwegian (Bokmal)_Norway.1252")) I don't think it makes sense to declare minor spelling differences as broken, or to change the kernel resources for this. -- Alexandre Julliard julliard(a)winehq.org

Aug. 27, 2010

Re: Help with 6120d7cc145, causing bugs

by sudemon

On 27.08.2010 18:47, Henri Verbeet wrote: > 6120d7cc14522983fbc38026ab4fcb6e4a68cdf0 actually does, does the > attached patch make any difference for you? Thanks, patch solved the problem.

Aug. 27, 2010

Re: Help with 6120d7cc145, causing bugs

by wylda＠volny.cz

> Actually, looking a bit at what > 6120d7cc14522983fbc38026ab4fcb6e4a68cdf0 actually > does, does the attached patch make any difference for you? Yes! :-D For crashing tested on: Warcarft 3, 3DMark 2001 SE, Harbinger For HEAP corruption tested on: Demoscene debris All apps are working perfectly! Could i kindly ask you for sending to patches today? It looks like i will have spare time for testing, so it will help me to not to mess with revering. Thank you for quick analysis and patch. W.

Aug. 27, 2010

Re: Fwd: [PATCH 1/3] winmm: Fix mciSendString command parsing on 64-bit.

by Alexandre Julliard

Octavian Voicu <octavian.voicu(a)gmail.com> writes: > The reason for which I opted for a BYTE* is so that I can use sizeof() > to increment the pointer correctly. DWORD_PTR has a different size of > 32- and 64-bit systems, so using DWORD* would make it more complicated > to increment with sizeof(DWORD_PTR). Another reason is that offset is > now in bytes, so supplying a pointer of different size wouldn't make > much sense. There's no reason to change this. Just work with DWORDs throughout, it will avoid a lot of ugly casts. -- Alexandre Julliard julliard(a)winehq.org

Aug. 27, 2010

Re: Try 4: SetCooperative Levels with Normal+Fullscreen+Exclusive is authorized

by Henri Verbeet

On 27 August 2010 11:05, paulo lesgaz <jeremielapuree(a)yahoo.fr> wrote: > I modified my patch to follow Henri's and Stefan's requests and hints. Do > you have more observations to do with this one? > Not exactly a new one, but you still have whitespace errors.

Aug. 27, 2010

Re: Help with 6120d7cc145, causing bugs

by Henri Verbeet

On 27 August 2010 14:33, Henri Verbeet <hverbeet(a)gmail.com> wrote: > clearly outside that range. At first sight I'd say there's an error in > the calculation for "mixdev[mixnum].chans" somewhere, that's what > ultimately determines the size of the block that's allocated above, > and should correspond to the number of lines filled in filllines(), 16 > in the log you attached. > Actually, looking a bit at what 6120d7cc14522983fbc38026ab4fcb6e4a68cdf0 actually does, does the attached patch make any difference for you?

Aug. 27, 2010

Re: Help with 6120d7cc145, causing bugs

by Henri Verbeet

On 27 August 2010 14:04, <wylda(a)volny.cz> wrote: > > Also from log previously attached, following string is written to > address out of this word, isn't? Look like some return address than > HEAP, right? > > 0009:Call KERNEL32.MultiByteToWideChar(0000fdf2,00000000,0021cac8 > "HDA NVidia",ffffffff,7dfc9ee4,00000020) ret=7dfb2ae4 > 0009:Ret KERNEL32.MultiByteToWideChar() retval=0000000b > ret=7dfb2ae4 > Well, it would be this one: > 0009:Call KERNEL32.MultiByteToWideChar(0000fdf2,00000000,7d6d8b18 "Digital",ffffffff,004e3044,00000020) ret=7dfb268b > 0009:Ret KERNEL32.MultiByteToWideChar() retval=00000008 ret=7dfb268b > 0009:Call ntdll.RtlAllocateHeap(00110000,00000008,000004ec) ret=7dfb31c2 > 0009:Ret ntdll.RtlAllocateHeap() retval=004e2b58 ret=7dfb31c2 This allocates 0x4ec bytes at 0x4e2b58, so that's 0x4e2b58 -> 0x4e3044. MultiByteToWideChar() writing 0x20 wide chars at 0x4e3044 is clearly outside that range. At first sight I'd say there's an error in the calculation for "mixdev[mixnum].chans" somewhere, that's what ultimately determines the size of the block that's allocated above, and should correspond to the number of lines filled in filllines(), 16 in the log you attached.

Aug. 27, 2010

Re: Help with 6120d7cc145, causing bugs

by wylda＠volny.cz

Also from log previously attached, following string is written to address out of this word, isn't? Look like some return address than HEAP, right? 0009:Call KERNEL32.MultiByteToWideChar(0000fdf2,00000000,0021cac8 "HDA NVidia",ffffffff,7dfc9ee4,00000020) ret=7dfb2ae4 0009:Ret KERNEL32.MultiByteToWideChar() retval=0000000b ret=7dfb2ae4

Aug. 27, 2010

Re: Help with 6120d7cc145, causing bugs

by wylda＠volny.cz

> > There have been a few bug reports... > http://bugs.winehq.org/show_bug.cgi?id=23902 and > http://bugs.winehq.org/show_bug.cgi?id=24131 . > > It seems that in some relatively rare sound > setups, an inappropriate sound element gets fed in to > filllines_no_master which leads to a crash on audio initialize. Hi, i put eyes & fingers into a code, which is bad. People like me, should never do such things, but it just shows my desperateness around this problem. Am i correct when saying: HEAP is allocated begining at 0x004e2b58 and 1260bytes long: 0009:Call ntdll.RtlAllocateHeap(00110000,00000008,000004ec) ret=7dfb31c2 0009:Ret ntdll.RtlAllocateHeap() retval=004e2b58 ret=7dfb31c2 so HEAP ends up at 0x004E3043 followed by 12 "safety bytes" (starting at 0x004e3044), because i run the app with WINEDEBUG=warn+heap. This allocation is shortly followed and used by: 0009:Call KERNEL32.MultiByteToWideChar(0000fdf2,00000000,7d5807e8 "Headphone",ffffffff,004e2b58,00000020) ret=7dfb2382 0009:Ret KERNEL32.MultiByteToWideChar() retval=0000000a ret=7dfb2382 ... 0009:Call KERNEL32.MultiByteToWideChar(0000fdf2,00000000,7d6d8b18 "Digital",ffffffff,004e3044,00000020) ret=7dfb268b 0009:Ret KERNEL32.MultiByteToWideChar() retval=00000008 ret=7dfb268b So this "D" is written to a place (0x004e3044), where it shouldn't be ("safety bytes"). At the end of application run, the wine complains: 0009:Call ntdll.RtlFreeHeap(00110000,00000000,004e2b58) ret=7dfb3778 err:heap:HEAP_ValidateInUseArena Heap 0x110000: block 0x4e2b58 tail overwritten at 0x4e3044 (byte 0/12 == 0x44) And this 0x44 stands for "D" from ascii? Mentioned address 0x4e2b58 appears only in the begining (allocation) and at the end (free). Is this helpful somehow? What should i do something next? Thanks in advance for any help. Longer log attached. W.

Aug. 27, 2010

Fwd: [PATCH 1/3] winmm: Fix mciSendString command parsing on 64-bit.

by Octavian Voicu

Same here. ---------- Forwarded message ---------- From: Octavian Voicu <octavian.voicu(a)gmail.com> Date: Thu, Aug 26, 2010 at 3:12 PM Subject: Re: [PATCH 1/3] winmm: Fix mciSendString command parsing on 64-bit. To: Joerg-Cyril.Hoehle(a)t-systems.com On Thu, Aug 26, 2010 at 2:15 PM, Octavian Voicu <octavian.voicu(a)gmail.com> wrote: > I just looked in mmddk.h and they have this: > > #ifdef _WIN64 > #define MCI_INTEGER64 13 > #endif // _WIN64 > > Which is really funny, because I wrote that patch without knowing > anything about that. Gonna take a look at resources inside a 64-bit > winmm.dll and report back, but it is pretty obvious what I'll find -- > they wouldn't define MCI_INTEGER64 for nothing. I can confirm it, the 64-bit dll uses MCI_INTEGER64 (0x0000000D), while the 32-bit one uses MCI_INTEGER. Maybe we should also have #ifdefs in mmddk.h and winmm_res.rc. So, do you want to fix your patches and send them, or do you want me to continue working on this patch set? You should also send the mciParser test (btw, I tested my patch set with your extra tests and they all pass). Octavian

Aug. 27, 2010

Fwd: [PATCH 1/3] winmm: Fix mciSendString command parsing on 64-bit.

by Octavian Voicu

For some reason I forgot to hit reply to all. ---------- Forwarded message ---------- From: Octavian Voicu <octavian.voicu(a)gmail.com> Date: Thu, Aug 26, 2010 at 2:15 PM Subject: Re: [PATCH 1/3] winmm: Fix mciSendString command parsing on 64-bit. To: Joerg-Cyril.Hoehle(a)t-systems.com On Thu, Aug 26, 2010 at 1:11 PM, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > are you aware of bug http://bugs.winehq.org/show_bug.cgi?id=22146 > and the partial patch and additional test cases there? First of all, I wasn't aware of it, so thanks for pointing it out. I just saw the crash on my system and tried to fix it; to my shame, I didn't search wine bug database. Sorry for the duplicate work. >>winmm: Add MCI_INTEGER_PTR return type for DWORD_PTR return values. >>+#define MCI_INTEGER_PTR 13 > What kind of testing did you perform on native systems to derive the existence of this value? > If such value does not exist, then I fear your patch set looses the ability to > drop in native dlls for compatibility testing and validation. > If it exists, then it's good news you found it. The only testing I ran is winmm:mci tests. With my patch set, 27 tests fail on 64 bit (compared to 23 on 32bit). I'm guessing the 4 extra failures are in other parts of the code. Not sure about TODOs, as I had no tests marked as TODO when I ran the tests from command line (the 23 tests that also fail on 32-bit are definitely marked as TODOs on test.winehq.org) I didn't think it was necessary to test on native systems. The command parsing looks like internal winmm stuff, which makes no difference to the exported interfaces, as long as the command string is parsed into the corresponding MCI_ structures correctly. MCI_GetDWord, MCI_GetString, MCI_ParseOptArgs, MCI_HandleReturnValues, the functions which I modified, are explicitly listed as internal functions. I just looked in mmddk.h and they have this: #ifdef _WIN64 #define MCI_INTEGER64 13 #endif // _WIN64 Which is really funny, because I wrote that patch without knowing anything about that. Gonna take a look at resources inside a 64-bit winmm.dll and report back, but it is pretty obvious what I'll find -- they wouldn't define MCI_INTEGER64 for nothing. >>-static DWORD MCI_ParseOptArgs(DWORD_PTR* data, int _offset, LPCWSTR lpCmd, >>+static DWORD MCI_ParseOptArgs(BYTE* data, int _offset, LPCWSTR lpCmd, >>- if (!MCI_GetDWord(&(data[offset+0]), &args) || >>- !MCI_GetDWord(&(data[offset+1]), &args) || >>- !MCI_GetDWord(&(data[offset+2]), &args) || >>- !MCI_GetDWord(&(data[offset+3]), &args)) { >>+ if (!MCI_GetDWord(data+offset+0*sizeof(DWORD), &args) || >>+ !MCI_GetDWord(data+offset+1*sizeof(DWORD), &args) || >>+ !MCI_GetDWord(data+offset+2*sizeof(DWORD), &args) || >>+ !MCI_GetDWord(data+offset+3*sizeof(DWORD), &args)) { > > The MCI_XYZ_PARMS structures are neither DWORD_PTR, not BYTE*, > they are DWORD with some DWORD_PTR in between. > Wouldn't using DWORD* data help avoid such pointer arithmetic > and eliminate several hunks of the patch ? The reason for which I opted for a BYTE* is so that I can use sizeof() to increment the pointer correctly. DWORD_PTR has a different size of 32- and 64-bit systems, so using DWORD* would make it more complicated to increment with sizeof(DWORD_PTR). Another reason is that offset is now in bytes, so supplying a pointer of different size wouldn't make much sense. Argument type in MCI_GetDWord and MCI_GetString was changed for consistency, it wouldn't matter very much there. For the same reason I changed all the &data[offset] into data+offset. In any case, using the MCI_XYZ_PARMS union looks much better :) Maybe also stick MCI_GENERIC_PARMS in there.

Aug. 27, 2010

Re: Any idea how to solve that ?

by GOUJON Alexandre

On 08/27/2010 09:53 AM, GOUJON Alexandre wrote: > Hi, > > No one have replied for my ["Spanish - Modern Sort_Spain.1252" locale > on wine] mail. > So I'm asking again if someone has an idea. > If solved, msvcrt:locale test on wine will pass without any error. > > The situation is the following : > setlocale(LC_ALL, "esn"); > > ok(!strcmp(ret, "Spanish_Spain.1252") > > setlocale(LC_ALL, "spanish-modern"); > > ok(!strcmp(ret, "Spanish - Modern Sort_Spain.1252") > > with > static const char * const _country_synonyms[] = > { ... "spanish-modern", "esn" } > -> this has to be changed since above tests prove they're not the same > > I submitted a job for the WineTestBot for finding what esX '=' Spanish > - Modern Sort_Spain.1252 > And the result is : none. > > So, should I create another esX ? > What template for this new one ? > Another idea ? > > Each todo_wine we remove may resolve (or prevent) bugs. Well, in fact MSDN was right : spanish-modern '=' esn except some W98 and NT4. According to the test https://testbot.winehq.org/JobDetails.pl?Key=4821 the ok() is in fact a broken() and the broken() ... So the (wine msvcrt:locale) code is already right. Cool !

Aug. 27, 2010

Try 4: SetCooperative Levels with Normal+Fullscreen+Exclusive is authorized

by paulo lesgaz

Hello, I modified my patch to follow Henri's and Stefan's requests and hints. Do you have more observations to do with this one? As previously, all the tests go on passing. A+ David

Aug. 27, 2010

Re: [1/5] msi/tests: Use a different product code in the package tests to avoid cascading test failures.

by testbot＠testbot.winehq.org

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=4818 Your paranoid android. === W7PROX64 (64 bit package) === package.c:8385: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8396: Test failed: Expected "C:\winetest\", got "" package.c:8407: Test failed: Expected "C:\winetest\", got "" package.c:8457: Test failed: Expected "C:\winetest\FileName3.dll", got "" package.c:8468: Test failed: Expected "C:\winetest\FileName5.dll", got "" package.c:8477: Test failed: Expected "C:\", got "" package.c:8483: Test failed: Expected "C:\winetest\", got "" package.c:8504: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8513: Test failed: Expected "C:\winetest\FileName1", got ""

Aug. 27, 2010

Re: kernel32: add error text for WSAECONNREFUSED

by Dmitry Timoshkov

Dan Kegel <dank(a)kegel.com> wrote: > This gets Pando-based installers further, see > http://bugs.winehq.org/show_bug.cgi?id=24019 > > There's obviously more to do here, but this little bit is useful. Please simultaneously add it to all other language files. -- Dmitry.

Aug. 27, 2010

Re: windowscodecs: support ICO files with embedded PNGs

by Damjan Jovanovic

If this patch isn't accepted then the winemenubuilder ones shouldn't be either. PNG is typically used to compress the largest icon in the ICO file, and the largest icon is the one winemenubuilder will extracts to be used during the +/- 1 minute delay in Gnome before a menu item starts having the best-sized icon, so with the winemenubuilder patches and without this one some icons will regress to showing nothing initially. IWICStream::InitializeFromIStreamRegion can always come later. The read loop is thus temporary, and a 256x256 PNG (the largest size ICO supports) cannot take up more than 256*256*4 bytes = 256 kB, so the memory usage with this patch is not a concern. On Fri, Aug 27, 2010 at 7:42 AM, Vincent Povirk <madewokherd(a)gmail.com>wrote: > You mean you're not going to implement > IWICStream::InitializeFromIStreamRegion? That's no fun. > > Also, that read loop is a bit silly. You might as well just lock the > HGLOBAL and read into it directly. > > On Fri, Aug 27, 2010 at 12:30 AM, Damjan Jovanovic <damjan.jov(a)gmail.com> > wrote: > > Changelog: > > * windowscodecs: support ICO files with embedded PNGs > > Closes #23708. > > Damjan Jovanovic > > > > > > > > > > >

Aug. 27, 2010

Any idea how to solve that ?

by GOUJON Alexandre

Hi, No one have replied for my ["Spanish - Modern Sort_Spain.1252" locale on wine] mail. So I'm asking again if someone has an idea. If solved, msvcrt:locale test on wine will pass without any error. The situation is the following : setlocale(LC_ALL, "esn"); > ok(!strcmp(ret, "Spanish_Spain.1252") setlocale(LC_ALL, "spanish-modern"); > ok(!strcmp(ret, "Spanish - Modern Sort_Spain.1252") with static const char * const _country_synonyms[] = { ... "spanish-modern", "esn" } -> this has to be changed since above tests prove they're not the same I submitted a job for the WineTestBot for finding what esX '=' Spanish - Modern Sort_Spain.1252 And the result is : none. So, should I create another esX ? What template for this new one ? Another idea ? Each todo_wine we remove may resolve (or prevent) bugs.

Aug. 27, 2010

Re: windowscodecs: support ICO files with embedded PNGs

by Vincent Povirk

You mean you're not going to implement IWICStream::InitializeFromIStreamRegion? That's no fun. Also, that read loop is a bit silly. You might as well just lock the HGLOBAL and read into it directly. On Fri, Aug 27, 2010 at 12:30 AM, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > Changelog: > * windowscodecs: support ICO files with embedded PNGs > Closes #23708. > Damjan Jovanovic > > > >

Aug. 27, 2010

Re: mpr: Fix translations

by James McKenzie

Amine Khaldi wrote: [nothing] Can you please put some sort of tracking information when resubmitting a patch like [try2]. This will keep those of us who are manually tracking and applying your fixes in sync. Thank you. James McKenzie

Aug. 27, 2010

Re: RFC: Resolving a full screen bug

by Erich Hoover

On Thu, Aug 26, 2010 at 2:02 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > ... > It's not correct, the iconic flag is supposed to reflect the state that > we have asked from X. What is the exact sequence that leads to the > window remaining iconified? I figured this still wasn't quite right. It's not that it remains iconified, it's that it goes to "partial-screen" (see attached screenshot) instead of full-screen. The relevant calls appear to be (noting that my display is currently set to 1440x900): > trace:win:WIN_CreateWindowEx L"Borderlands" L"LaunchUnrealUWindowsClient" ex=00040000 style=00cb0000 360,225 720x450 parent=(nil) menu=(nil) inst=0x400000 params=(nil) > trace:win:dump_window_styles style: WS_CAPTION WS_SYSMENU WS_MINIMIZEBOX WS_MAXIMIZEBOX > trace:win:dump_window_styles exstyle: WS_EX_APPWINDOW > ... > trace:win:SetWindowPos hwnd 0x30096, after (nil), 21,846 (32x32), flags 00008160 > trace:win:dump_winpos_flags flags: SWP_FRAMECHANGED SWP_SHOWWINDOW SWP_NOCOPYBITS SWP_STATECHANGED > ... > trace:win:SetWindowPos hwnd 0x30096, after (nil), 0,0 (1440x900), flags 00000014 > trace:win:dump_winpos_flags flags: SWP_NOZORDER SWP_NOACTIVATE > ... > trace:win:SetWindowPos hwnd 0x30096, after (nil), 0,0 (0x0), flags 00000043 > trace:win:dump_winpos_flags flags: SWP_NOSIZE SWP_NOMOVE SWP_SHOWWINDOW > ... So, you can see why I was suspicious of the "iconic" status not being updated and that resulting in the window not transitioning to the full-screen size. Erich Hoover ehoover(a)mines.edu

Aug. 27, 2010

Re: user32: Make GetMessage and PeekMessage patchable

by Stefan Dösinger

Am 26.08.2010 um 07:08 schrieb Henri Verbeet: > On 26 August 2010 15:51, Stefan Dösinger <stefan(a)codeweavers.com> wrote: >> From: =?UTF-8?q?Stefan=20D=C3=B6singer?= <stefan(a)macbook.local> > Please configure git properly? Oops, sorry. I am surprised I never sent a patch from this machine since I set it up more than a year ago...

Aug. 26, 2010

Re: Inviting Mono and pulseaudio to wineconf?

by Hin-Tak Leung

--- On Thu, 26/8/10, Vincent Povirk <madewokherd(a)gmail.com> wrote: > > Also, half of the > > cross-compiling dependencies are available (and more > up to date) on fedora > > under the ming32-* packages. > > I don't use fedora, but you're welcome to add that > information for the > benefit of fedora users. (Or even a reference for yourself; > that's > pretty much what I use the wiki for.) > > Maybe I'll fix the svn references sometime, if I remember. I have added the github info - wasn't too sure about editing/removing old stuff, so I just added an extra paragraph at the end of the svn checkout part. I'll make another section later about building on fedora and fedora-specific info.

Aug. 26, 2010

Re: [PATCH] inetcpl: Add initial applet

by Detlef Riekenberg

Am Dienstag, den 24.08.2010, 17:56 -0700 schrieb Juan Lang: > Hi Detlef, > were you planning to resubmit this patch? [1] Yes, after the next release but as a more complete Patchset. > Using our own inetcpl.cpl would allow us to avoid > that, by exposing cryptui.CryptUICertMgr without using any native > DLLs. Good Idea. -- By by ... Detlef

Aug. 26, 2010

Re: Inviting Mono and pulseaudio to wineconf?

by Vincent Povirk

> Also, half of the > cross-compiling dependencies are available (and more up to date) on fedora > under the ming32-* packages. I don't use fedora, but you're welcome to add that information for the benefit of fedora users. (Or even a reference for yourself; that's pretty much what I use the wiki for.) Maybe I'll fix the svn references sometime, if I remember.

Aug. 26, 2010

Re: Inviting Mono and pulseaudio to wineconf?

by Hin-Tak Leung

Vincent Povirk wrote: <snipped> >> http://wiki.winehq.org/Mono is looking good. (Think there's a Summer >> of Code 2011 project or two in there?) > > Judging by bugzilla, there don't seem to be any large projects that > would help compatibility enough to be worthwhile. All the mscoree bugs > only affect one app. Sorry for going off-track in this thread again... I just noticed a couple of outdated-ness on http://wiki.winehq.org/Mono - the Ximian people have switched to git on github for hosting the development about a month ago. It is on git://github.com/mono/mono.git or thereabouts. Also, half of the cross-compiling dependencies are available (and more up to date) on fedora under the ming32-* packages.

Aug. 26, 2010

Re: shell32: Add a navigation pane to the ExplorerBrowser control.

by Juan Lang

> ^ is bitwise-XOR, so it is more like if(This->navpane.show != show_navpane), > which looks to be what he intended. Ah, yes 'tis. Perhaps it's a deficiency of my brain, but when reading bit-twiddling code, I remember the bitwise operators, but when reading logical code, I tend to stick to the boolean operators more. David, AJ will probably override me and say it's not necessary, but to my eyes != looks clearer. Thanks, --Juan

Aug. 26, 2010

Re: shell32: Add a navigation pane to the ExplorerBrowser control.

by David Hedberg

On Thu, Aug 26, 2010 at 19:32, Octavian Voicu <octavian.voicu(a)gmail.com> wrote: > On Thu, Aug 26, 2010 at 8:11 PM, Juan Lang <juan.lang(a)gmail.com> wrote: >> Hi David, I know this was committed already, but something caught my >> eye that I didn't understand: >> >> + if(This->navpane.show ^ show_navpane) >> >> Is this a cute way to write if(This->navpane.show && show_navpane) ? >> If so, why ^ rather than &&? > > ^ is bitwise-XOR, so it is more like if(This->navpane.show != show_navpane), > which looks to be what he intended. > > Octavian > It's indeed supposed to be !=, which also seems like the easier and better way of expressing it. :-) I guess the only reason I used ^ is that that was what came to my mind when I wrote the code in question. It shouldn't matter in practice, but I can include a patch for it in my next batch of patches.

Aug. 26, 2010

Re: shell32: Add a navigation pane to the ExplorerBrowser control.

by Octavian Voicu

On Thu, Aug 26, 2010 at 8:11 PM, Juan Lang <juan.lang(a)gmail.com> wrote: > Hi David, I know this was committed already, but something caught my > eye that I didn't understand: > > + if(This->navpane.show ^ show_navpane) > > Is this a cute way to write if(This->navpane.show && show_navpane) ? > If so, why ^ rather than &&? ^ is bitwise-XOR, so it is more like if(This->navpane.show != show_navpane), which looks to be what he intended. Octavian

Aug. 26, 2010

Re: shell32: Add a navigation pane to the ExplorerBrowser control.

by Juan Lang

Hi David, I know this was committed already, but something caught my eye that I didn't understand: + if(This->navpane.show ^ show_navpane) Is this a cute way to write if(This->navpane.show && show_navpane) ? If so, why ^ rather than &&? Thanks, --Juan

Aug. 26, 2010

Re: [PATCH 1/1] gameux/tests: verifying registry values created by GameExplorer (try 4)

by testbot＠testbot.winehq.org

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=4793 Your paranoid android. === W7PRO (32 bit gameexplorer) === gameexplorer.c:453: Test failed: failed while checking registry value (error 0x1) gameexplorer.c:471: Test failed: failed while checking registry value (error 0x1) === W7PROX64 (32 bit gameexplorer) === gameexplorer.c:453: Test failed: failed while checking registry value (error 0x1) gameexplorer.c:471: Test failed: failed while checking registry value (error 0x1) === W7PROX64 (64 bit gameexplorer) === gameexplorer.c:453: Test failed: failed while checking registry value (error 0x1) gameexplorer.c:471: Test failed: failed while checking registry value (error 0x1)

Aug. 26, 2010

Re: ddraw/tests: New visual back buffer flipping tests. (try 3)

by Oldřich Jedlička

On Wednesday 25 August 2010 12:03:50 Stefan Dösinger wrote: > > + hr = IDirectDrawSurface_AddAttachedSurface(Primary, Backbuffer); > > + todo_wine ok(hr == DD_OK || broken(hr == DDERR_CANNOTATTACHSURFACE), > > + "Attaching a back buffer to a front buffer returned %08x\n", hr); > > The patch looks OK. Out of curiosity, which windows system returns > DDERR_CANNOTATTACHSURFACE? Allowing this result with broken() is OK since > you have an application that depends on this behavior. I've searched my previous patches and I think that I've copied it during my first tries from dsurface.c: AttachmentTest. I don't know if it is needed in my tests too, probably not for the testbot. It looked like a good idea to have the check too if it had been in AttachmentTest already. I can remove it with further patch (also from the dsurface.c: BackBufferAttachmentFlipTest). Should I remove it? I will wait for the patch to be applied first and I will send small correction to remove the broken() check, right? I can remove the broken() check from my "New attachment tests for 3D back buffers." patch too. Should I remove it or keep it? Oldřich.

Aug. 26, 2010

Re: Inviting Mono and pulseaudio to wineconf?

by James Mckenzie

Vincent Povirk <madewokherd(a)gmail.com> wrote: >Sent: Aug 26, 2010 9:03 AM >To: Dan Kegel <dank(a)kegel.com> >Cc: wine-devel(a)winehq.org, Stefan Dösinger <stefandoesinger(a)gmx.at> >Subject: Re: Inviting Mono and pulseaudio to wineconf? > >> Mono: >> Vincent, what do you think? Probably they're not holding us up, >> but maybe they'd like to see a presentation from you about >> status of Mono integration? > >Oh geez. Um. Well, they are indeed not holding us up. In all my >communication with them, they've been very helpful. > Since Microsoft appears to have taken a hostile turn towards anything released with Windows 7, WMP 10, .NET .3.5 + working with Wine, it would be very interesting to see what the Mono team's stance is on integration with Wine and the path onward. At one time it was very hostile, now it seems to have changed to at least neutral and maybe even what we call 'hallway' friendly. >I don't know that the current status of Mono integration is much to talk about. > >> http://wiki.winehq.org/Mono is looking good. (Think there's a Summer >> of Code 2011 project or two in there?) > >Judging by bugzilla, there don't seem to be any large projects that >would help compatibility enough to be worthwhile. All the mscoree bugs >only affect one app. > Hmmm. Maybe we need to widen the 'gene pool' to see if other applications are affected. James McKenzie

Aug. 26, 2010

Re: Inviting Mono and pulseaudio to wineconf?

by Vincent Povirk

> Mono: > Vincent, what do you think? Probably they're not holding us up, > but maybe they'd like to see a presentation from you about > status of Mono integration? Oh geez. Um. Well, they are indeed not holding us up. In all my communication with them, they've been very helpful. I don't know that the current status of Mono integration is much to talk about. > http://wiki.winehq.org/Mono is looking good. (Think there's a Summer > of Code 2011 project or two in there?) Judging by bugzilla, there don't seem to be any large projects that would help compatibility enough to be worthwhile. All the mscoree bugs only affect one app.

Aug. 26, 2010

Re: : Use SUBLANG_NEUTRAL for language-independent resources

by Greg Geldorp

> From: Francois Gouget <fgouget(a)free.fr> > > According to past Winetest results these platforms could (should?) have > it though. A full log is strange but I don't how it could be cause by my > patch: > > gameux: start - - > Usage: C:\winetest\gameux_test64.exe test_name > > Valid test names: > gameexplorer > gamestatistics > gameux: done (1) > > No test summary line found Your patch only changed the .rc file. TestBot doesn't know what tests to run in that case (it determines the tests to run from the .c files that were changed). Same kind of thing happens when the .js files for the jscript.dll tests are changed. I'll see if I can teach it to just run all tests in these cases. Ge.

Aug. 26, 2010

Re: [5/5] d3d10: Implement D3D10CompileShader, forward to d3dcompiler.

by Henri Verbeet

On 26 August 2010 17:26, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > +#define COBJMACROS > #include "config.h" > #include "wine/port.h" > - > +#include "objbase.h" > +#include "d3dcompiler.h" > #include "d3d10_private.h" You should probably just include d3dcompiler.h from d3d10_private.h.

Aug. 26, 2010

Re: [2/5] d3dcompiler: Stub D3DCompile implementation.

by Henri Verbeet

On 26 August 2010 17:26, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > Please stick to the coding style used in the rest of the d3d10 dlls (see e.g. blob.c for reference). This applies to patches 4 and 5 as well.

Aug. 26, 2010

Re: user32: Make GetMessage and PeekMessage patchable

by Henri Verbeet

On 26 August 2010 15:51, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > From: =?UTF-8?q?Stefan=20D=C3=B6singer?= <stefan(a)macbook.local> Please configure git properly?

Aug. 26, 2010

Re: Inviting Mono and pulseaudio to wineconf?

by Dan Kegel

On Wed, Aug 25, 2010 at 9:51 AM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: >>> Would it be appropriate and useful to invite someone from >>> Mono and Pulseaudio to attend Wineconf this year? > > I guess it never hurts to have people around, but we should have a set of issues to discuss with them. Pulseaudio: What's the status with http://bugs.winehq.org/show_bug.cgi?id=10495 ? Alexandre said in http://bugs.winehq.org/show_bug.cgi?id=10495#c251 that it's being worked on... Mono: Vincent, what do you think? Probably they're not holding us up, but maybe they'd like to see a presentation from you about status of Mono integration? http://wiki.winehq.org/Mono is looking good. (Think there's a Summer of Code 2011 project or two in there?) - Dan

Aug. 26, 2010

Re: gameux: Use SUBLANG_NEUTRAL for language-independent resources.

by Francois Gouget

On Thu, 26 Aug 2010, testbot(a)testbot.winehq.org wrote: [...] > http://testbot.winehq.org/JobDetails.pl?Key=4787 > > Your paranoid android. > > === W98SE (32 bit) === > === W2KPROSP4 (32 bit) === > === WXPPROSP3 (32 bit) === > === W2K3R2SESP2 (32 bit) === > === W2K8SE (32 bit) === > No test summary line found I think it's just because these platforms don't have the gameux library. Isn't testbot supposed to detect that though? > === WVISTAADM (32 bit) === > === W7PRO (32 bit) === > === W7PROX64 (32 bit) === > === W7PROX64 (64 bit) === > No test summary line found According to past Winetest results these platforms could (should?) have it though. A full log is strange but I don't how it could be cause by my patch: gameux: start - - Usage: C:\winetest\gameux_test64.exe test_name Valid test names: gameexplorer gamestatistics gameux: done (1) No test summary line found -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Computers are like airconditioners They stop working properly if you open WINDOWS

Aug. 26, 2010

Re: Use SUBLANG_NEUTRAL for the Gaelic resources?

by Francois Gouget

On Tue, 24 Aug 2010, Huw Davies wrote: [...] > > If not it would be better to use SUBLANG_NEUTRAL instead of > > SUBLANG_GAELIC. For instance: > > I think they're different enough to warrant falling back to English > rather than Irish (which is essentially what you're asking). Works for me. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.

Aug. 26, 2010

Re: gameux: Use SUBLANG_NEUTRAL for language-independent resources.

by testbot＠testbot.winehq.org

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=4787 Your paranoid android. === W98SE (32 bit) === No test summary line found === 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

Aug. 26, 2010

Re: [PATCH 4/5] shell32: Add INameSpaceTreeControlEvents stub to the ExplorerBrowser control.

by David Hedberg

On Thu, Aug 26, 2010 at 13:03, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > On 8/26/2010 14:53, David Hedberg wrote: >> >> + *ppvObject = NULL; >> + if(IsEqualIID(riid,&IID_INameSpaceTreeControlEvents)) >> + { >> + *ppvObject = iface; >> + } >> + > > Why don't you allow IUnknown here? > An oversight on my part I guess, although I'm not sure anyone will ever request IUnknown here in this case. I'll add it.

Aug. 26, 2010

Re: [PATCH 1/5] shell32: Check for ICommDlgBrowser from Site and use it in the IExplorerBrowser control.

by David Hedberg

On Thu, Aug 26, 2010 at 13:15, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > On 8/26/2010 14:53, David Hedberg wrote: >> >> --- >> dlls/shell32/ebrowser.c | 98 +++++++++++++++++++---- >> dlls/shell32/tests/ebrowser.c | 174 >> ++++++++++++++++++++++++++++++++++++++++- >> 2 files changed, 251 insertions(+), 21 deletions(-) >> >> diff --git a/dlls/shell32/ebrowser.c b/dlls/shell32/ebrowser.c >> index b243aa0..1137880 100644 >> --- a/dlls/shell32/ebrowser.c >> +++ b/dlls/shell32/ebrowser.c >> @@ -73,6 +73,8 @@ typedef struct _ExplorerBrowserImpl { >> LPITEMIDLIST current_pidl; >> >> IUnknown *punk_site; >> + ICommDlgBrowser3 *pcdb3_site; >> + UINT cdb_site_supported; >> } ExplorerBrowserImpl; > > I think a better way for this would be to store a pointer for each interface > version, instead of having additional switch. When you have separate > pointers a call looks more obvious like: > > if (pcdb_site) ICommDlgBrowser_*(pcdb_site). > > Makes sense, I'll send a new version. Thanks.

Aug. 26, 2010

Re: [PATCH 1/5] shell32: Check for ICommDlgBrowser from Site and use it in the IExplorerBrowser control.

by Nikolay Sivov

On 8/26/2010 14:53, David Hedberg wrote: > --- > dlls/shell32/ebrowser.c | 98 +++++++++++++++++++---- > dlls/shell32/tests/ebrowser.c | 174 ++++++++++++++++++++++++++++++++++++++++- > 2 files changed, 251 insertions(+), 21 deletions(-) > > diff --git a/dlls/shell32/ebrowser.c b/dlls/shell32/ebrowser.c > index b243aa0..1137880 100644 > --- a/dlls/shell32/ebrowser.c > +++ b/dlls/shell32/ebrowser.c > @@ -73,6 +73,8 @@ typedef struct _ExplorerBrowserImpl { > LPITEMIDLIST current_pidl; > > IUnknown *punk_site; > + ICommDlgBrowser3 *pcdb3_site; > + UINT cdb_site_supported; > } ExplorerBrowserImpl; I think a better way for this would be to store a pointer for each interface version, instead of having additional switch. When you have separate pointers a call looks more obvious like: if (pcdb_site) ICommDlgBrowser_*(pcdb_site).

Aug. 26, 2010

Re: [PATCH 4/5] shell32: Add INameSpaceTreeControlEvents stub to the ExplorerBrowser control.

by Nikolay Sivov

On 8/26/2010 14:53, David Hedberg wrote: > + *ppvObject = NULL; > + if(IsEqualIID(riid,&IID_INameSpaceTreeControlEvents)) > + { > + *ppvObject = iface; > + } > + Why don't you allow IUnknown here?

Aug. 26, 2010

Re: mpr: Fix Czech translation.

by Alexandre Julliard

Amine Khaldi <amine.khaldi(a)reactos.org> writes: > Regards, > Amine. There's no need to send a separate patch for each language, it's the same change for all. Also make sure your mailer doesn't mangle the high bit chars. -- Alexandre Julliard julliard(a)winehq.org

Aug. 26, 2010

[PATCH 1/3] winmm: Fix mciSendString command parsing on 64-bit.

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

Octavian, are you aware of bug http://bugs.winehq.org/show_bug.cgi?id=22146 and the partial patch and additional test cases there? >winmm: Add MCI_INTEGER_PTR return type for DWORD_PTR return values. >+#define MCI_INTEGER_PTR 13 What kind of testing did you perform on native systems to derive the existence of this value? If such value does not exist, then I fear your patch set looses the ability to drop in native dlls for compatibility testing and validation. If it exists, then it's good news you found it. >-static DWORD MCI_ParseOptArgs(DWORD_PTR* data, int _offset, LPCWSTR lpCmd, >+static DWORD MCI_ParseOptArgs(BYTE* data, int _offset, LPCWSTR lpCmd, >- if (!MCI_GetDWord(&(data[offset+0]), &args) || >- !MCI_GetDWord(&(data[offset+1]), &args) || >- !MCI_GetDWord(&(data[offset+2]), &args) || >- !MCI_GetDWord(&(data[offset+3]), &args)) { >+ if (!MCI_GetDWord(data+offset+0*sizeof(DWORD), &args) || >+ !MCI_GetDWord(data+offset+1*sizeof(DWORD), &args) || >+ !MCI_GetDWord(data+offset+2*sizeof(DWORD), &args) || >+ !MCI_GetDWord(data+offset+3*sizeof(DWORD), &args)) { The MCI_XYZ_PARMS structures are neither DWORD_PTR, not BYTE*, they are DWORD with some DWORD_PTR in between. Wouldn't using DWORD* data help avoid such pointer arithmetic and eliminate several hunks of the patch ? Regards, Jörg Höhle

Aug. 26, 2010

Re: RFC: Resolving a full screen bug

by Alexandre Julliard

Erich Hoover <ehoover(a)mines.edu> writes: > I've been periodically revisiting a patch I've been using to fix a bug > with running Borderlands under Wine at the same resolution as the > desktop ( original message: > http://www.winehq.org/pipermail/wine-devel/2010-May/083339.html ). > Attached is an iteration that appears to resolve the issue without > impacting the other applications I normally run. It appears that the > problem arises since Borderlands goes straight from being iconified to > being exactly the desktop resolution, as a result Wine never turns off > the "iconic" flag - so the application window is not sized or > positioned properly. I would appreciate it if I could get some > feedback on this patch, it doesn't seem to break anything but it would > be nice to have an expert opinion. It's not correct, the iconic flag is supposed to reflect the state that we have asked from X. What is the exact sequence that leads to the window remaining iconified? -- Alexandre Julliard julliard(a)winehq.org

Aug. 26, 2010

RFC: Resolving a full screen bug

by Erich Hoover

I've been periodically revisiting a patch I've been using to fix a bug with running Borderlands under Wine at the same resolution as the desktop ( original message: http://www.winehq.org/pipermail/wine-devel/2010-May/083339.html ). Attached is an iteration that appears to resolve the issue without impacting the other applications I normally run. It appears that the problem arises since Borderlands goes straight from being iconified to being exactly the desktop resolution, as a result Wine never turns off the "iconic" flag - so the application window is not sized or positioned properly. I would appreciate it if I could get some feedback on this patch, it doesn't seem to break anything but it would be nice to have an expert opinion. Erich Hoover ehoover(a)mines.edu

Aug. 26, 2010

Re: winetrick & mono dot net 3.5 emmulation.

by Hin-Tak Leung

apologies - for laziness, I picked one message with Dan Kegel and did a reply and emptied subject/body. I guess that messes up e-mail software that actually uses the invisible headers for threads. -------- Original Message -------- Subject: Re: winetrick & mono dot net 3.5 emmulation. Date: Wed, 25 Aug 2010 21:01:09 -0700 From: James McKenzie <jjmckenzie51(a)earthlink.net> To: Hin-Tak Leung <hintak_leung(a)yahoo.co.uk> Hin-Tak Leung wrote: > The installer of one application I have requires Net 3.5 and refuses > to install > if it is not detected. Yet it runs adequately well with mono 2.6.x > (when installed to Vista then copied over). So I am wondering if there > should be a winetrick "lie about having .net 3.5" registry setting, > and go about seeing what needs to be done - e.g. how is that installer > detecting dot net 3.5 ? > > > > Can you open a separate thread for this? I'm going ahead and deleting all of the messages from the hijacked thread on my system and you have a very good point to make. James McKenzie

Aug. 26, 2010