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