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

Re: winetrick & mono dot net 3.5 emmulation.

by Vincent Povirk

Wine should probably include whatever registry key is needed by default.

Aug. 25, 2010

WineConf 2010

by Francois Gouget

WineConf 2010 is now all set: Where: Hotel Ibis Bastille in Paris When: November, Saturday 20th ~9am to Sunday 21st ~5pm You should book your hotel room directly from the hotel; the sooner the better. Also if you have not booked your plane tickets yet, this is your reminder. All the details should be available on the WineConf 2010 wiki page: http://wiki.winehq.org/WineConf2010 Again, note that most further communication will happen on the wineconf(a)winehq.org mailing list. So subscribe there to be sure not to miss the latest news. This is also the place to go if you have questions, etc. I hope to see you all in Paris! -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt IP over Avian Carriers with Quality of Service

Aug. 25, 2010

Re: winetrick & mono dot net 3.5 emmulation.

by Dan Kegel

On Wed, Aug 25, 2010 at 7:02 PM, Hin-Tak Leung <hintak_leung(a)yahoo.co.uk> 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 ? Sure, a fakedotnet35 verb seems like a fine thing for the short term, if it makes an app happy. Or maybe it should be added to the mono26 verb. Ideally Wine would load mono and set those variables automatically, but it might be a while before somebody has the time to make it all work smoothly like that.

Aug. 25, 2010

winetrick & mono dot net 3.5 emmulation.

by Hin-Tak Leung

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 ?

Aug. 25, 2010

re: [PATCH 2/7] d3dx9_36/tests: Added HLSL test suite

by Dan Kegel

Henri wrote: > You still have basic formatting errors like trailing spaces, mixing > tabs and spaces, inconsistent "*" placement, etc. > ... unnecessary cast... > wine-patches reviews are supposed to catch non-trivial interactions with > other parts of the code, not trivial whitespace errors. Looking at http://wiki.winehq.org/SubmittingPatches, I didn't see a nice, concise checklist of things to check for, so I added one at the top, and linked to Henri's post. Improvements welcome. - Dan

Aug. 25, 2010

Re: Inviting Mono and pulseaudio to wineconf?

by Vincent Povirk

> Maybe we should preemptively invite an OpenAL guy :-) I assume you mean Chris Robinson. And yes, we should totally invite him.

Aug. 25, 2010

Re: [PATCH 2/7] d3dx9_36/tests: Added HLSL test suite

by Henri Verbeet

On 25 August 2010 09:58, Travis Athougies <iammisc(a)gmail.com> wrote: > +static IDirect3DPixelShader9* compile_pixel_shader(IDirect3DDevice9* device, const char *shader, const char *profile,· > +»······»·······»·······»·······»·······»······· ID3DXConstantTable **constants) You still have basic formatting errors like trailing spaces, mixing tabs and spaces, inconsistent "*" placement, etc. > + hres = IDirect3DDevice9_CreateVertexShader(device_ptr, (DWORD*) ID3DXBuffer_GetBufferPointer(compiled), &vshader_passthru); Here's another unnecessary cast. For the record, I'm not going to point out every single flaw in every single patch. If I find an issue in a patch, you should take that as a hint that perhaps you didn't review your patches careful enough before sending them, and go over them again yourself. Anyway, we've decided to implement the shader assembler and compiler in the d3dcompiler dll. I think it makes sense to move any compiler/assembler tests there as well. Note that I'm going to request that d3dcompiler follows the same general style as used in dxgi/d3d10core/d3d10, this is different from the style used in most of d3dx9. Something else. In my opinion an internship should imply some level of guidance/training, not simply "cheap labor". In particular, while ideally you would have caught the issues mentioned in this and previous reviews yourself, whoever has been mentoring you certainly should have, these are basic C / Wine development issues. The process is supposed to look somewhat like this: 1. Carefully write the patch. 2. Carefully review the patch. 3. If you find any issues, carefully fix them and go back to 2. 4. Run the test suite. 5. If it finds any issues, carefully fix them and go back to 2. 6. Send the patch to your mentor for review. 7. If he finds any issues, carefully fix them and go back to 2. 8. If it's still the same day as on 1, consider waiting a day, so you can give the patch a fresh look in the next step. 9. Repeat steps 2 through 5 before sending the patch to wine-patches. 10. Send the patch to wine-patches. 11. If it finds any issues, carefully fix them and go back to 2. Replace "patch" with "patchset" if you're doing more complicated things. Ideally step 6 would produce something like a "Signed-off-by" or "Reviewed-by" tag. If you're at step 11 for the third or fourth time, and there are still problems with the patch, there are structural failures at 1, 2 and 6. Failures at 1 and 2 are somewhat expected for an internship, depending on what kind of standards a specific organization sets, but that's exactly what step 6 is supposed to catch. I.e., when I find an issue in a patch that means at the very least that you didn't catch it when writing the patch, didn't catch it when reviewing the patch the first time, your mentor didn't catch it, and you didn't catch it during review before sending the patch. The things wine-patches reviews are supposed to catch are non-trivial interactions with other parts of the code, not trivial whitespace errors.

Aug. 25, 2010

Re: Inviting Mono and pulseaudio to wineconf?

by Dan Kegel

On Wed, Aug 25, 2010 at 6:36 AM, Jeff Cook <jeff(a)deserettechnology.com> wrote: >> Having a good pulseaudio driver (in the new wine audio design) might >> not be a bad thing. > > My understanding is that the new mmdevapi code leverages OpenAL, which > theoretically should take care of the pulseaudio issues assuming both > sides implement the protocol appropriately. Sure, and Pulseaudio leverages the ALSA API, which theoretically should take care of compatibility problems, assuming both sides implement the API properly. But you raise a good point. Hey, Maarten, how's the OpenAL stuff coming? Will there be something to demo before Wineconf? Maybe we should preemptively invite an OpenAL guy :-) - Dan

Aug. 25, 2010

Re: mscoree: improve GetCORSytemDirectory

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

Aug. 25, 2010

Re: d3dx9: Implement D3DXDeclaratorFromFVF. (try 2)

by Henri Verbeet

On 25 August 2010 14:31, Misha Koshelev <misha680(a)gmail.com> wrote: > for some reason were from Paulo Lesgaz. > For what it's worth, "Paulo Lesgaz" is an (obvious) pseudonym, as is "Jérémie Lapurée". See e.g. http://fr.wikipedia.org/wiki/Joe_Bar_Team for reference.

Aug. 25, 2010

Re: d3dx9: Implement D3DXDeclaratorFromFVF. (try 2)

by Misha Koshelev

On Wed, 2010-08-25 at 12:28 +0200, Henri Verbeet wrote: > On 25 August 2010 04:04, misha680 <misha680(a)gmail.com> wrote: > > What do you think about this one on top of those? I will wait to send to > > wine-patches until your patches have been committed. > > http://wine.1045685.n5.nabble.com/file/n2652101/0004-d3dx9-Implement-D3DXDe… > > Still not quite right, I'm afraid, although it's a bit closer. > However, as mentioned in > http://www.winehq.org/pipermail/wine-devel/2010-August/086112.html, > since this is about the tenth version of D3DXDeclaratorFromFVF() I'm > seeing (not counting the ones in d3d9 and wined3d...), I went ahead > and just implemented it myself. The patch attached to that mail is the > initial untested version. The patch attached to this mail is what I > think it should look like after doing some tests. I'll probably send > it in tomorrow. Thank you so much. My apologies - for some reason I got confused and thought that the patches in http://wine.1045685.n5.nabble.com/Re-d3dx9-Implement-D3DXDeclaratorFromFVF-… for some reason were from Paulo Lesgaz. Thank you for your help with this! Misha

Aug. 25, 2010

"Spanish - Modern Sort_Spain.1252" locale on wine

by GOUJON Alexandre

Hi everyone, I'm trying to fix msvcrt:locale on wine and it appears "Spanish - Modern Sort_Spain.1252" locale is missing. According to msdn (http://msdn.microsoft.com/en-us/library/39cwe7zf%28v=VS.71%29.aspx) "esn" and "spanish-modern" are equivalent which is false [quoted from msvcrt/tests/locale.c] ret = setlocale(LC_ALL, "esn"); ok(ret != NULL || broken (ret == NULL), "ret == NULL\n"); if(ret) ok(!strcmp(ret, "Spanish_Spain.1252") || broken(!strcmp(ret, "Spanish - Modern Sort_Spain.1252")), "ret = %s\n", ret); and ret = setlocale(LC_ALL, "spanish-modern"); ok(ret != NULL || broken (ret == NULL), "ret == NULL\n"); if(ret) ok(!strcmp(ret, "Spanish - Modern Sort_Spain.1252") || broken(!strcmp(ret, "Spanish_Spain.1252")), "ret = %s\n", ret); If I modify dlls/kernerl32/nls/esn.nls LOCALE_SENGLANGUAGE "Spanish" to LOCALE_SENGLANGUAGE "Spanish - Modern Sort" then it'll fix the second test and break the first one. So I'm wondering what to do. Create another nls file based on esn with a different LOCALE_SENGLANGUAGE ? (and change _country_synonyms[] in locale.c) Hard code this (i.e. if .. == "spanish-modern" .. ) ? Other advice ? Thanks in advance

Aug. 25, 2010

Re: ddraw [try 3]: SetCooperativeLevel with Full screen + exclusive + normal is authorized

by Henri Verbeet

On 25 August 2010 08:48, David Adam <david.adam.cnrs(a)gmail.com> wrote: > + if(cooplevel == (DDSCL_NORMAL | DDSCL_EXCLUSIVE) ) So what happens if you set e.g. "DDSCL_NORMAL | DDSCL_EXCLUSIVE | DDSCL_FPUPRESERVE"? You also still have trailing spaces. The way this would conceptually make sense to me is if you always need either NORMAL or EXCLUSIVE, with NORMAL | EXCLUSIVE -> EXCLUSIVE and EXCLUSIVE requiring FULLSCREEN. (Well, except for SETFOCUSWINDOW, which seems to live in a world of its own.) I.e., something along these lines: if (coop & SETFOCUSWINDOW) { ... return; } if (coop & EXCLUSIVE) { if (!(coop & FULLSCREEN)) fail(); ... } else if (coop & NORMAL) { ... } else fail();

Aug. 25, 2010

wined3d and visual studio: The remaining uglyness

by Stefan Dösinger

Hi, I've spent some time to get wined3d to compile with visual studio on Windows. I sent some code fixes needed for that, but a few hacks are remaining. I'm sending them here for discussion. First, why did I look at Visual Studio: *) mingw on windows a bit messy. Cross Compiling all the time even more so *) msvc is the native toolkit, it opens up many other tools. I was interested in VsPerfKit specifically. Basically I set up a Visual Studio process to compile libport, libwine, wined3d, d3d8 and d3d9 out of tree, referencing the code files via relative paths(../../wine/dlls/wined3d/*.c). This was done manually, there's no integration with Wine's native build system. That's hack #1. Unfortunately I can't attach the project right now, it's on a different computer at home. I think we have a script to generate msvc projects for the tests. Maybe the right way is to extend this to the DLLs and programs. I wrote a hand-written config.h file defining a few HAVE_XXX_H constants. That is hack #2 and relates to Alexandre's concern about the libport isnan and isinf implementations. More specific code issues: *) MIDL uses cdecl as the default calling convention for exported functions. Patch 6 in the archive fixes wined3d.idl to work correctly with midl, but this change causes a segfault in widl. *) Msvc complains that -unsigned_int is still unsigned, and the integer overflow just happens to do what you want. The easiest way is to write 0 - unsigned_int, but I'm not sure about it. *) NaN and Inf generation *) msvc doesn't like the predeclaration of **environ. It causes a unknown symbol error at link time.

Aug. 25, 2010

Re: d3dx9: Implement D3DXDeclaratorFromFVF. (try 2)

by Henri Verbeet

On 25 August 2010 04:04, misha680 <misha680(a)gmail.com> wrote: > What do you think about this one on top of those? I will wait to send to > wine-patches until your patches have been committed. > http://wine.1045685.n5.nabble.com/file/n2652101/0004-d3dx9-Implement-D3DXDe… Still not quite right, I'm afraid, although it's a bit closer. However, as mentioned in http://www.winehq.org/pipermail/wine-devel/2010-August/086112.html, since this is about the tenth version of D3DXDeclaratorFromFVF() I'm seeing (not counting the ones in d3d9 and wined3d...), I went ahead and just implemented it myself. The patch attached to that mail is the initial untested version. The patch attached to this mail is what I think it should look like after doing some tests. I'll probably send it in tomorrow.

Aug. 25, 2010

Re: ddraw: SetCooperativeLevel with Full screen + exclusive + normal is authorized

by Stefan Dösinger

Hi, Your CreateSurface tests are missing in this patch(assuming that paulo lesgaz is your alter ego) There's a comment above the SetCooperativeLevel implementation that needs adjustments. > if(cooplevel & DDSCL_NORMAL) > { > - /* Can't coexist with fullscreen or exclusive */ > - if(cooplevel & (DDSCL_FULLSCREEN | DDSCL_EXCLUSIVE) ) > + /* Can't coexist with exclusive only*/ > + if(cooplevel = DDSCL_NORMAL | DDSCL_EXCLUSIVE ) This check doesn't do what you intend it to do. An application may pass NORMAL | EXCLUSIVE | FPUSETUP for instance Also, your test shows that NORMAL | EXCLUSIVE | FULLSCREEN means fullscreen mode. The CreateSurface test passes because the FULLSCREEN and EXCLUSIVE flags are added, but the window is still set up for windowed rendering. In this flag combination you want to enter the fullscreen setup codepath.

Aug. 25, 2010

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

by Stefan Dösinger

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

Aug. 25, 2010

Re: Inviting Mono and pulseaudio to wineconf?

by Stefan Dösinger

Am 25.08.2010 um 04:34 schrieb James McKenzie: > Dan Kegel wrote: >> Would it be appropriate and useful to invite someone from >> Mono and Pulseaudio to attend Wineconf this year? >> We do have to work well with those projects, maybe that would help >> solve a couple current or future problems. >> > Dan: > > +1 on Mono, -1 on PulseAudio I guess it never hurts to have people around, but we should have a set of issues to discuss with them.

Aug. 25, 2010

Re: Inviting Mono and pulseaudio to wineconf?

by Scott Ritchie

On 08/24/2010 12:32 PM, Dan Kegel wrote: > Would it be appropriate and useful to invite someone from > Mono and Pulseaudio to attend Wineconf this year? > We do have to work well with those projects, maybe that would help > solve a couple current or future problems. > > If I remember right I floated this idea (with Mono) earlier, and there was some conflict that meant it wouldn't work. I believe I was thinking of scheduling concurrent conferences however - we could always just bring Mono people to wineconf as a separate thing. Thanks, Scott Ritchie

Aug. 25, 2010

Re: ddraw [try 3]: SetCooperativeLevel with Full screen + exclusive + normal is authorized

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=4741 Your paranoid android. === W98SE (32 bit ddrawmodes) === No test summary line found === W7PROX64 (64 bit ddrawmodes) === Timeout

Aug. 25, 2010

Help with 6120d7cc145, causing bugs

by Jeff Cook

Just wondering if I could get a bit more review on commit 6120d7cc145 which was committed in early August. Here's a link: http://source.winehq.org/git/wine.git/?a=commit;h=6120d7cc14522983fbc38026a… There have been a few bug reports filed against it recently, see 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. To me this is weird because the program is currently written so that it flows into filllines_no_master only if there no is master control. A patch adding else if (micelem) instead of just else was recently committed and fixed at least one person's problem. Some people on the bug report are unable to provide full debug information so it makes this harder. If you have the time, please review the patch and let me know what errors you notice that may be causing the aforementioned bug. I am new to Wine dev so please forgive anything really stupid. :) Thanks From Jeff. -- Jeff Cook (801) 231-3157 jeff(a)deserettechnology.com

Aug. 25, 2010

Re: Inviting Mono and pulseaudio to wineconf?

by Jeff Cook

On Wed, Aug 25, 2010 at 12:10 AM, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > I'm not against inviting Pulseaudio guys. Sure, Pulseaudio was added > to distributions way too early and there still are a lot of issues but > sound servers like pulseaudio are really the way to go for the future. > People want to be able to plug in lets say a usb headset (so another > soundcard) when playing a game and expect audio to move over to it or > want to see audio move over to their HDTV when they plug it in and > that's stuff which requires some form of arbiter at the user side. > > Having a good pulseaudio driver (in the new wine audio design) might > not be a bad thing. My understanding is that the new mmdevapi code leverages OpenAL, which theoretically should take care of the pulseaudio issues assuming both sides implement the protocol appropriately. > > Roderick

Aug. 25, 2010

Re: Inviting Mono and pulseaudio to wineconf?

by Roderick Colenbrander

I'm not against inviting Pulseaudio guys. Sure, Pulseaudio was added to distributions way too early and there still are a lot of issues but sound servers like pulseaudio are really the way to go for the future. People want to be able to plug in lets say a usb headset (so another soundcard) when playing a game and expect audio to move over to it or want to see audio move over to their HDTV when they plug it in and that's stuff which requires some form of arbiter at the user side. Having a good pulseaudio driver (in the new wine audio design) might not be a bad thing. Roderick On Tue, Aug 24, 2010 at 7:34 PM, James McKenzie <jjmckenzie51(a)earthlink.net> wrote: > Dan Kegel wrote: >> >> Would it be appropriate and useful to invite someone from >> Mono and Pulseaudio to attend Wineconf this year? >> We do have to work well with those projects, maybe that would help >> solve a couple current or future problems. >> > > Dan: > > +1 on Mono, -1 on PulseAudio > > James McKenzie > > > >

Aug. 25, 2010

Re: Inviting Mono and pulseaudio to wineconf?

by James McKenzie

Dan Kegel wrote: > Would it be appropriate and useful to invite someone from > Mono and Pulseaudio to attend Wineconf this year? > We do have to work well with those projects, maybe that would help > solve a couple current or future problems. > Dan: +1 on Mono, -1 on PulseAudio James McKenzie

Aug. 25, 2010

Re: d3dx9: Implement D3DXDeclaratorFromFVF. (try 2)

by misha680

Henri Verbeet wrote: > > On 24 August 2010 05:05, Misha Koshelev <misha680(a)gmail.com> wrote: >> + elements[idx].Stream = 0xFF; >> + elements[idx].Offset = D3DXGetDeclVertexSize(elements, 0); >> + elements[idx].Stream = 0; > That's ugly. > >> + memcpy(Declaration, elements, size * sizeof(D3DVERTEXELEMENT9)); > That's unnecessary. > > > > Thanks, I noticed your patches here: http://source.winehq.org/patches/data/65330 http://source.winehq.org/patches/data/65331 http://source.winehq.org/patches/data/65331 What do you think about this one on top of those? I will wait to send to wine-patches until your patches have been committed. http://wine.1045685.n5.nabble.com/file/n2652101/0004-d3dx9-Implement-D3DXDe… 0004-d3dx9-Implement-D3DXDeclaratorFromFVF.txt Thank you Misha -- View this message in context: http://wine.1045685.n5.nabble.com/Re-d3dx9-Implement-D3DXDeclaratorFromFVF-… Sent from the Wine - Devel mailing list archive at Nabble.com.

Aug. 25, 2010

Re: Ongoing Debian package maintenance.

by Lei Zhang

On Tue, Aug 24, 2010 at 3:06 PM, Ben Klein <shacklein(a)gmail.com> wrote: > On 24 August 2010 04:34, Lei Zhang <thestig(a)google.com> wrote: >> >> On Fri, Aug 20, 2010 at 4:00 PM, Ben Klein <shacklein(a)gmail.com> wrote: >> > Hello everyone, >> > >> > My health has not improved at all since my last call for help with the >> > Debian package management. I really need someone to take over from me, or at >> > least some help to devise a new set of (semi-)automated build scripts. Any >> > volunteers? >> >> Hi Ben, >> >> Does the task basically involve building new .deb packages for every >> release? I can probably take over this if nobody else volunteered. > > Yes, that is essentially the job. For every release of Wine, produce a > package for Debian's stable branch and testing/unstable. Ok, I'll take the job. If you have any documentation / pointers on what the package maintainer needs to do, send them my way, or better yet, put it on the Wine wiki.

Aug. 25, 2010

Re: [PATCH] inetcpl: Add initial applet

by Juan Lang

Hi Detlef, were you planning to resubmit this patch? [1] A user asked how to import a certificate recently [2], and I directed him to install ie6 to do so, but that has a lot of side effects which may not be wanted. Using our own inetcpl.cpl would allow us to avoid that, by exposing cryptui.CryptUICertMgr without using any native DLLs. Thanks, --Juan [1] http://www.winehq.org/pipermail/wine-patches/2010-May/088373.html [2] http://forum.winehq.org/viewtopic.php?t=9399

Aug. 25, 2010

Re: [3/3] d3dcompiler: Move D3DAssemble tests from d3dx9_36.

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

Aug. 24, 2010

Re: [3/3] d3dcompiler: Move D3DAssemble tests from d3dx9_36.

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

Aug. 24, 2010

Re: [4/4] oleaut32/tests: Some tests for IPicture::get_Handle()

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=4738 Your paranoid android. === W7PROX64 (64 bit olepicture) === olepicture.c:796: Test failed: got 0 olepicture.c:808: Test failed: got 0

Aug. 24, 2010

Re: Ongoing Debian package maintenance.

by Ben Klein

On 24 August 2010 04:34, Lei Zhang <thestig(a)google.com> wrote: > > On Fri, Aug 20, 2010 at 4:00 PM, Ben Klein <shacklein(a)gmail.com> wrote: > > Hello everyone, > > > > My health has not improved at all since my last call for help with the > > Debian package management. I really need someone to take over from me, or at > > least some help to devise a new set of (semi-)automated build scripts. Any > > volunteers? > > Hi Ben, > > Does the task basically involve building new .deb packages for every > release? I can probably take over this if nobody else volunteered. Yes, that is essentially the job. For every release of Wine, produce a package for Debian's stable branch and testing/unstable. > Get better! Thanks, Lei. I'm going through some tests at the moment and think I know what the outcome of the next one will be, which is good because it will tell me what's been wrong for YEARS with me (though it's got a LOT worse these past few months).

Aug. 24, 2010

Re: [3/4] oleaut32/olepicture: Fix ::get_hPal() behaviour for certain picture types

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=4737 Your paranoid android. === W7PROX64 (64 bit olepicture) === olepicture.c:765: Test failed: got 0 olepicture.c:777: Test failed: got 0

Aug. 24, 2010

Inviting Mono and pulseaudio to wineconf?

by Dan Kegel

Would it be appropriate and useful to invite someone from Mono and Pulseaudio to attend Wineconf this year? We do have to work well with those projects, maybe that would help solve a couple current or future problems.

Aug. 24, 2010

Re : Re : Re : ddraw [try 2]: SetCooperativeLevel with Full screen + exclusive + normal is authorized

by paulo lesgaz

Added new tests for d3d7. No change. All the tests passed on real Vista David ________________________________ De : Stefan Dösinger <stefandoesinger(a)gmx.at> À : paulo lesgaz <jeremielapuree(a)yahoo.fr> Cc : wine-devel(a)winehq.org Envoyé le : Mar 24 août 2010, 20h 00min 05s Objet : Re: Re : Re : ddraw [try 2]: SetCooperativeLevel with Full screen + exclusive + normal is authorized Am 24.08.2010 um 17:48 schrieb paulo lesgaz: Is this patch correct to test d3d7 and d3d2 SetCooperativeLevel? >For now, all the tests pass on a real vista box. >Actually, I missed something: The exising test tests IDirectDraw, not >IDirectDraw7. So it is testing the oldest ddraw interface. Can you test >IDirectDraw7 instead of IDirectDraw2? If microsoft added extra sanity checks >they did so most likely in the newer interfaces.

Aug. 24, 2010

Re: Re : Re : ddraw [try 2]: SetCooperativeLevel with Full screen + exclusive + normal is authorized

by Stefan Dösinger

Am 24.08.2010 um 17:48 schrieb paulo lesgaz: > Is this patch correct to test d3d7 and d3d2 SetCooperativeLevel? > For now, all the tests pass on a real vista box. Actually, I missed something: The exising test tests IDirectDraw, not IDirectDraw7. So it is testing the oldest ddraw interface. Can you test IDirectDraw7 instead of IDirectDraw2? If microsoft added extra sanity checks they did so most likely in the newer interfaces.

Aug. 24, 2010

Re: wine.inf: added .NET InstallRoot key

by Vincent Povirk

Yes, build-mingw32.sh works, but the resulting build is incomplete. For example, it lacks libgluezilla and a mozilla library to glue to, so the browsing component does not work. This is in the official Windows builds of Mono. I don't know what else is missing. On Tue, Aug 24, 2010 at 12:45 PM, Hin-Tak Leung <hintak_leung(a)yahoo.co.uk> wrote: > --- On Tue, 24/8/10, Vincent Povirk <madewokherd(a)gmail.com> wrote: > >> > And eventually mono will be >> installed automatically like gecko is? >> >> If I ever get the damn thing to build fully on a Linux box, >> yes. > > Is there a problem with that? Mono comes with a script called "build-mingw32.sh" for cross-compiling on linux. I use that for every mono release since about 2.2 as I need a little customization, changing the heap setting, before they get the new garbage collector code scheduled for 2.8(?) ready. I only rebuild the runtime - not the class libraries, so I stop the build in the middle. > > There are some dependency differences (depending on different versions of dependent dll's) against MSVC builds, file naming differences (the mono dll is called libmono.dll in one but just mono.dll in the other - I filed a bug for it and it is still open), and dependencies on gcc_s*.dll from exception unwinding, but it is basically inter-operable - as I swap one part of the stock msvc build with a custom mingw cross-compiled part for every release for much of the last two years now. > > > > >

Aug. 24, 2010

Re: wine.inf: added .NET InstallRoot key

by Hin-Tak Leung

--- On Tue, 24/8/10, Vincent Povirk <madewokherd(a)gmail.com> wrote: > > And eventually mono will be > installed automatically like gecko is? > > If I ever get the damn thing to build fully on a Linux box, > yes. Is there a problem with that? Mono comes with a script called "build-mingw32.sh" for cross-compiling on linux. I use that for every mono release since about 2.2 as I need a little customization, changing the heap setting, before they get the new garbage collector code scheduled for 2.8(?) ready. I only rebuild the runtime - not the class libraries, so I stop the build in the middle. There are some dependency differences (depending on different versions of dependent dll's) against MSVC builds, file naming differences (the mono dll is called libmono.dll in one but just mono.dll in the other - I filed a bug for it and it is still open), and dependencies on gcc_s*.dll from exception unwinding, but it is basically inter-operable - as I swap one part of the stock msvc build with a custom mingw cross-compiled part for every release for much of the last two years now.

Aug. 24, 2010

Re: wine.inf: added .NET InstallRoot key

by Vincent Povirk

> And eventually mono will be installed automatically like gecko is? If I ever get the damn thing to build fully on a Linux box, yes.

Aug. 24, 2010

Re : Re : ddraw [try 2]: SetCooperativeLevel with Full screen + exclusive + normal is authorized

by paulo lesgaz

Is this patch correct to test d3d7 and d3d2 SetCooperativeLevel? For now, all the tests pass on a real vista box. David ________________________________ De : Stefan Dösinger <stefandoesinger(a)gmx.at> À : paulo lesgaz <jeremielapuree(a)yahoo.fr> Cc : wine-devel(a)winehq.org Envoyé le : Mar 24 août 2010, 16h 44min 38s Objet : Re: Re : ddraw [try 2]: SetCooperativeLevel with Full screen + exclusive + normal is authorized I think those tests should do, but have a few spelling issues and you're not releasing the surface. So if I understand things correctly: *) NORMAL | FULLSCREEN | EXCLUSIVE -> fullscreen mode *) NORMAL | EXCLUSIVE -> error *) NORMAL | FULLSCREEN -> windowed mode For testing older ddraw interface vesions you can QueryInterface the ddraw object for IID_IDirectDraw, IID_IDirectDraw2(and ddraw3 and ddraw4). Then you run the same tests on those. I am pretty sure the check that NORMAL mode is mutually exclusive with FULLSCREEN/EXCLUSIVE already existed in old ddraw, and is motivated by a statement in msdn that those modes are mutually exclusive - which makes sense, you can't be in fullscreen mode and not be in fullscreen mode at the same time. It seems that one flag is ignored rather than an error returned. On a general note, I am away from home the next weeks. I expect to be able to read mail, but it will me sporadic(ok, I haven't been reliable in the past few weeks either) Am 24.08.2010 um 15:26 schrieb paulo lesgaz: Such tests are what you were thinking about? >They all passed on my real vista box. > >David > > > > > > ________________________________ De : Stefan Dösinger <stefandoesinger(a)gmx.at> >À : wine-devel(a)winehq.org >Envoyé le : Mar 24 août 2010, 11h 30min 59s >Objet : Re: ddraw [try 2]: SetCooperativeLevel with Full screen + exclusive + >normal is authorized > >Hi, >Can you add a test that tests in which mode ddraw is after such a call? >Specfically, try to create a double buffered primary surface. If this succeeds, >ddraw is in fullscreen mode. If ddraw is in normal mode you'll get >DDERR_NOEXCLUSIVEMODE (or similar) back. > >Am 24.08.2010 um 10:00 schrieb David Adam: > >> Fixed a typo >> >> A+ >> >> David >> <0001-SetCooperativeLevel-with-Full-screen-exclusive-norma.patch> > > > > ><0001-SetCooperativeLevel-with-Full-screen-exclusive-norma.patch>

Aug. 24, 2010

wine.inf: added .NET InstallRoot key

by Louis Lenders

Dan Kegel <dank <at> kegel.com> writes: > > What is our intent with adding all these registry keys? > It seems as if they are helpful for installing mono, > but might get in the way of installing MS .net. > > If that's the intent, do y'all want me to make the > dotnet20 winetricks verb remove any registry > keys that confuse the dotnet20 installer? > > I tested dotnet 2.0 and these 2 keys don't harm the installer The only key that causes trouble AFAICT is the already present key [HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP\v2.0.50727] "Version"="2.2.30729" It makes the .NET SP1 installer crash much earlier than it does without this key

Aug. 24, 2010

Re: Re : ddraw [try 2]: SetCooperativeLevel with Full screen + exclusive + normal is authorized

by Stefan Dösinger

I think those tests should do, but have a few spelling issues and you're not releasing the surface. So if I understand things correctly: *) NORMAL | FULLSCREEN | EXCLUSIVE -> fullscreen mode *) NORMAL | EXCLUSIVE -> error *) NORMAL | FULLSCREEN -> windowed mode For testing older ddraw interface vesions you can QueryInterface the ddraw object for IID_IDirectDraw, IID_IDirectDraw2(and ddraw3 and ddraw4). Then you run the same tests on those. I am pretty sure the check that NORMAL mode is mutually exclusive with FULLSCREEN/EXCLUSIVE already existed in old ddraw, and is motivated by a statement in msdn that those modes are mutually exclusive - which makes sense, you can't be in fullscreen mode and not be in fullscreen mode at the same time. It seems that one flag is ignored rather than an error returned. On a general note, I am away from home the next weeks. I expect to be able to read mail, but it will me sporadic(ok, I haven't been reliable in the past few weeks either) Am 24.08.2010 um 15:26 schrieb paulo lesgaz: > Such tests are what you were thinking about? > They all passed on my real vista box. > > David > > > De : Stefan Dösinger <stefandoesinger(a)gmx.at> > À : wine-devel(a)winehq.org > Envoyé le : Mar 24 août 2010, 11h 30min 59s > Objet : Re: ddraw [try 2]: SetCooperativeLevel with Full screen + exclusive + normal is authorized > > Hi, > Can you add a test that tests in which mode ddraw is after such a call? Specfically, try to create a double buffered primary surface. If this succeeds, ddraw is in fullscreen mode. If ddraw is in normal mode you'll get DDERR_NOEXCLUSIVEMODE (or similar) back. > > Am 24.08.2010 um 10:00 schrieb David Adam: > > > Fixed a typo > > > > A+ > > > > David > > <0001-SetCooperativeLevel-with-Full-screen-exclusive-norma.patch> > > > > > <0001-SetCooperativeLevel-with-Full-screen-exclusive-norma.patch>

Aug. 24, 2010

Re: wine.inf: added .NET InstallRoot key

by Dan Kegel

On Tue, Aug 24, 2010 at 1:52 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: >> What is our intent with adding all these registry keys? >> It seems as if they are helpful for installing mono, >> but might get in the way of installing MS .net. > > If they prevent installing MS .NET there should be a way to undo them > like we do for IE, by unregistering mscoree or something along those > lines. OK, so people who need the native .net should use something like winetricks to do the unregistering and installation, right? And eventually mono will be installed automatically like gecko is? - Dan

Aug. 24, 2010

Re: wine.inf: added .NET InstallRoot key

by Alexandre Julliard

Dan Kegel <dank(a)kegel.com> writes: > What is our intent with adding all these registry keys? > It seems as if they are helpful for installing mono, > but might get in the way of installing MS .net. If they prevent installing MS .NET there should be a way to undo them like we do for IE, by unregistering mscoree or something along those lines. -- Alexandre Julliard julliard(a)winehq.org

Aug. 24, 2010

Re : ddraw [try 2]: SetCooperativeLevel with Full screen + exclusive + normal is authorized

by paulo lesgaz

Such tests are what you were thinking about? They all passed on my real vista box. David ________________________________ De : Stefan Dösinger <stefandoesinger(a)gmx.at> À : wine-devel(a)winehq.org Envoyé le : Mar 24 août 2010, 11h 30min 59s Objet : Re: ddraw [try 2]: SetCooperativeLevel with Full screen + exclusive + normal is authorized Hi, Can you add a test that tests in which mode ddraw is after such a call? Specfically, try to create a double buffered primary surface. If this succeeds, ddraw is in fullscreen mode. If ddraw is in normal mode you'll get DDERR_NOEXCLUSIVEMODE (or similar) back. Am 24.08.2010 um 10:00 schrieb David Adam: > Fixed a typo > > A+ > > David > <0001-SetCooperativeLevel-with-Full-screen-exclusive-norma.patch>

Aug. 24, 2010

Re: msvcrt:locale Remove todo_wine and add broken when necessary

by GOUJON Alexandre

On 08/24/2010 02:51 PM, Octavian Voicu wrote: > broken() only works for tests that fail on some Windows versions; it > has no effect on Wine, see [1]. > My mistake. > Proper way to fix this bug is to make setlocale replicate Windows behavior. > I'll investigate further to fix it this way. Thanks

Aug. 24, 2010

Re: msvcrt:locale Remove todo_wine and add broken when necessary

by Octavian Voicu

On Tue, Aug 24, 2010 at 12:44 PM, Alexandre Goujon <ale.goujon(a)gmail.com> wrote: > - todo_wine ok(!strcmp(ret, "Chinese (Simplified)_People's Republic of China.936") > + ok(!strcmp(ret, "Chinese (Simplified)_People's Republic of China.936") > + || broken(!strcmp(ret, "Chinese_People's Republic of China.936")) broken() only works for tests that fail on some Windows versions; it has no effect on Wine, see [1]. Proper way to fix this bug is to make setlocale replicate Windows behavior. Octavian [1] http://source.winehq.org/git/wine.git/?a=blob;f=include/wine/test.h;h=1a980…

Aug. 24, 2010

re: wine.inf: added .NET InstallRoot key

by Dan Kegel

What is our intent with adding all these registry keys? It seems as if they are helpful for installing mono, but might get in the way of installing MS .net. If that's the intent, do y'all want me to make the dotnet20 winetricks verb remove any registry keys that confuse the dotnet20 installer?

Aug. 24, 2010

Re: Wine Gecko 1.1.0 RC1

by Jacek Caban

On 8/24/10 12:12 PM, Luca Bennati wrote: > Applied the patch to master, recompiled ok. I put the rc1 cab in > /usr/share/wine/gecko/, as always. > In the creation of a new prefix, it gave me an err which wasn't there before: > err:mshtml:init_xpcom AutoRegister(NULL) failed: 80070057 > but 'wine iexplore' works better than before (sites that crashed wine > before don't crash it anymore). > I investigated it a bit recreating a new prefix with 'WINEDEBUG=+mshtml > winecfg' and here's the log: Thanks for testing. This error is a known false error. Modules loading method has changed in Gecko and AutoRegister call is no longer needed, so I'm going to remove this call. It's harmless in the new Gecko, so I'm going to do it in another patch to limit size of this one. Thanks, Jacek

Aug. 24, 2010

Re: mscoree: improve GetCORVersion

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

Aug. 24, 2010

Re : ddraw [try 2]: SetCooperativeLevel with Full screen + exclusive + normal is authorized

by paulo lesgaz

The added tests show that the change is correct for d3d7 at least. How can I check that they are also correct for olders ddraw? David ________________________________ De : Henri Verbeet <hverbeet(a)gmail.com> À : wine-devel(a)winehq.org Envoyé le : Mar 24 août 2010, 11h 41min 36s Objet : Re: ddraw [try 2]: SetCooperativeLevel with Full screen + exclusive + normal is authorized This looks suspicious to me, you have to assume the code wasn't just added for the hell of it, even though with ddraw you're never quite sure. Do other ddraw versions behave the same? Please don't add trailing spaces, neither in the code nor in TRACEs.

Aug. 24, 2010