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

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