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