March 2012 - Wine-Devel - list.winehq.org

Re: wined3d: Added PCI device IDs for AMD Radeon 6750M & 6770M

by Gaurav Jain

On 2012-03-31, at 4:49 PM, Henri Verbeet wrote: > On 31 March 2012 21:20, Gaurav Jain <gaurav(a)gauravjain.org> wrote: >> CARD_AMD_RADEON_HD6600M = 0x6741, >> + CARD_AMD_RADEON_HD6750M = 0x6741, > If those are actually supposed to be the same, I don't think there's > much of a point in this patch. > Ahh... I didn't catch that the 6600M & 6750M was identical. Is there even a 6600M? My google search only found a 6630M, 6650M & 6670M. I believe 6600M is the series. I can remove the 6750M from the patch if you'd like. Please note that there is another duplicate entry for 5700 & 5750. The 6770M did have a different PCI ID, would you like the patch modified with only changes for the 6770M?

March 31, 2012

Re: [PATCH] wined3d: When releasing resources, don't perform any other operations on device if it has been released.

by Henri Verbeet

On 31 March 2012 23:30, Christian Costa <titan.costa(a)gmail.com> wrote: > Do you have a better idea ? > My first guess would be to check if vertex buffers are perhaps supposed to take a reference to the D3D interface. > Btw, the problem is easily reproductible. The bugzlla entry contain the > download link. > Yes, we have a lot of those.

March 31, 2012

Re: [PATCH] wined3d: When releasing resources, don't perform any other operations on device if it has been released.

by Christian Costa

Le 31/03/2012 22:46, Henri Verbeet a écrit : > This looks wrong. Is there a legitimate way that this can happen? > > > The FIXME in wined3d_device_decref says : FIXME("Device released with resources still bound, acceptable but unexpected.\n"); If this is "acceptable", resources must not use the device afterwards because it's released. If it's legitimate ? I don't know. The game craches when exiting. This may be due to a bad objects and resources freeing. Do you have a better idea ? Btw, the problem is easily reproductible. The bugzlla entry contain the download link. Christian

March 31, 2012

Re: wined3d: Added PCI device IDs for AMD Radeon 6750M & 6770M

by Henri Verbeet

On 31 March 2012 21:20, Gaurav Jain <gaurav(a)gauravjain.org> wrote: > CARD_AMD_RADEON_HD6600M = 0x6741, > + CARD_AMD_RADEON_HD6750M = 0x6741, If those are actually supposed to be the same, I don't think there's much of a point in this patch.

March 31, 2012

Re: [PATCH] wined3d: When releasing resources, don't perform any other operations on device if it has been released.

by Henri Verbeet

This looks wrong. Is there a legitimate way that this can happen?

March 31, 2012

Re: msi: add support for MSIRUNMODE_REBOOTNOW in MsiGetMode

by Austin English

On Sat, Mar 31, 2012 at 06:00, Hans Leidekker <hans(a)codeweavers.com> wrote: > On Fri, 2012-03-30 at 17:27 -0700, Austin English wrote: >> + case MSIRUNMODE_REBOOTNOW: >> + r = package->need_reboot; >> + break; >> + > > MSIRUNMODE_REBOOTNOW and MSIRUNMODE_REBOOTATEND are not the same thing. > > It seems I misunderstood the analysis then. I'll leave it to you then :). -- -Austin

March 31, 2012

Wine test bot and win16 exe

by Christian Costa

Hi, I wrote a win16 exe test file using open watcom but I cannot submit it to winebot. I fails saying "Unricognized file type". This is a little annoying. Is this a known limitation of wine test bot ? Thanks Christian

March 31, 2012

Re: quartz: update ICOM_THIS_MULTI to follow the new COM standard

by Jacek Caban

On 3/31/12 3:36 PM, John Klehm wrote: > On Fri, Mar 30, 2012 at 11:08 AM, Jacek Caban<jacek(a)codeweavers.com> wrote: >> On 03/30/12 17:55, Aric Stewart wrote: >>> diff --git a/dlls/quartz/quartz_private.h b/dlls/quartz/quartz_private.h >>> index 35cd52b..d2f680c 100644 >>> --- a/dlls/quartz/quartz_private.h >>> +++ b/dlls/quartz/quartz_private.h >>> @@ -38,7 +38,7 @@ >>> #define BYTES_FROM_MEDIATIME(time) SEC_FROM_MEDIATIME(time) >>> #define MSEC_FROM_MEDIATIME(time) ((time) / 10000) >>> >>> -#define ICOM_THIS_MULTI(impl,field,iface) impl* const This=(impl*)((char*)(iface) - offsetof(impl,field)) >>> +#define ICOM_THIS_MULTI(impl,field,iface) impl* const This=CONTAINING_RECORD(iface, impl, field) >> These should disappear once the clean up of affected code is done. >> > > Just for my own curiosity, I assume these pages are the preferred way? > > http://wiki.winehq.org/COMGuideline > http://wiki.winehq.org/ComCleanup Yes, that's the preferred way. Jacek

March 31, 2012

Re: quartz: update ICOM_THIS_MULTI to follow the new COM standard

by John Klehm

On Fri, Mar 30, 2012 at 11:08 AM, Jacek Caban <jacek(a)codeweavers.com> wrote: > On 03/30/12 17:55, Aric Stewart wrote: >> diff --git a/dlls/quartz/quartz_private.h b/dlls/quartz/quartz_private.h >> index 35cd52b..d2f680c 100644 >> --- a/dlls/quartz/quartz_private.h >> +++ b/dlls/quartz/quartz_private.h >> @@ -38,7 +38,7 @@ >> #define BYTES_FROM_MEDIATIME(time) SEC_FROM_MEDIATIME(time) >> #define MSEC_FROM_MEDIATIME(time) ((time) / 10000) >> >> -#define ICOM_THIS_MULTI(impl,field,iface) impl* const This=(impl*)((char*)(iface) - offsetof(impl,field)) >> +#define ICOM_THIS_MULTI(impl,field,iface) impl* const This=CONTAINING_RECORD(iface, impl, field) > > These should disappear once the clean up of affected code is done. > Just for my own curiosity, I assume these pages are the preferred way? http://wiki.winehq.org/COMGuideline http://wiki.winehq.org/ComCleanup

March 31, 2012

Re: msi: add support for MSIRUNMODE_REBOOTNOW in MsiGetMode

by Hans Leidekker

On Fri, 2012-03-30 at 17:27 -0700, Austin English wrote: > + case MSIRUNMODE_REBOOTNOW: > + r = package->need_reboot; > + break; > + MSIRUNMODE_REBOOTNOW and MSIRUNMODE_REBOOTATEND are not the same thing.

March 31, 2012

Re: [2/2] gdi32: Simplify font cache. (try 2)

by Kusanagi Kouichi

On 2012-03-30 15:36:06 +0200, Alexandre Julliard wrote: > Kusanagi Kouichi <slash(a)ac.auone-net.jp> writes: > > > @@ -1516,23 +1464,8 @@ static void add_face_to_cache(Face *face) > > RegSetValueExW(hkey_face, face_full_name_value, 0, REG_SZ, (BYTE*)face->FullName, > > (strlenW(face->FullName) + 1) * sizeof(WCHAR)); > > > > - reg_save_dword(hkey_face, face_index_value, face->face_index); > > - reg_save_dword(hkey_face, face_italic_value, (face->ntmFlags & NTM_ITALIC) != 0); > > - reg_save_dword(hkey_face, face_bold_value, (face->ntmFlags & NTM_BOLD) != 0); > > - reg_save_dword(hkey_face, face_version_value, face->font_version); > > - reg_save_dword(hkey_face, face_external_value, face->external); > > - > > - RegSetValueExW(hkey_face, face_font_sig_value, 0, REG_BINARY, (BYTE*)&face->fs, sizeof(face->fs)); > > + RegSetValueExW(hkey_face, face_value, 0, REG_BINARY, (BYTE*)face, sizeof *face); > > I don't think that's a good idea. There are many things in the structure > that don't make sense to have in the registry. Font cache lacks some information. Of course we can fix that, but that might occur again. If we save and load full information, we never lose any information. > Also this won't work on 64-bit. Wine64 looks to work. Do you mean WoW64? > > -- > Alexandre Julliard > julliard(a)winehq.org

March 31, 2012

Re: Wine release 1.5.1

by mike＠yurick.ca

I am no longer using this e-mail. Please contact me for my new e-mail address. Thank you, Mike

March 30, 2012

Re: 'Pending' patches state

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > > WM_SHOWWINDOW at the start and at the end of every message sequence > > means that ShowWindow() should be used to hide and show the window > > during SetParent call processing. > > That's the sort of explanation you should have included in your > patch, instead of expecting me to dig through the source or the list > archive to find it. Plus of course some explanation as to why the test > can't be marked as succeeding despite the change. Alexandre, do I need to provide more clarifications? -- Dmitry.

March 30, 2012

Re: jscript: Fixed jsheap_grow implementation

by Marvin

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=17589 Your paranoid android. === WNT4WSSP6 (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 === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

March 30, 2012

Re: quartz: update ICOM_THIS_MULTI to follow the new COM standard

by Aric Stewart

ok thanks, Glad I got this feedback before I started submitting my com cleanup patches that used it. -aric On 3/30/12 11:26 AM, Jacek Caban wrote: > On 03/30/12 18:09, Aric Stewart wrote: >> Meaning that I should not shift TO using that macro instead shift AWAY >> from using it? >> >> I have been doing some cleanup and been shifting to using it more. > > ICOM_THIS_MULTI macro should go away. Your patch made ICOM_THIS_MULTI > look a bit better by using CONTAINING_RECORD, but there is not much > point in doing it, since ICOM_THIS_MULTI should be completely removed. > > > Cheers, > Jacek

March 30, 2012

Re: quartz: update ICOM_THIS_MULTI to follow the new COM standard

by Jacek Caban

On 03/30/12 18:09, Aric Stewart wrote: > Meaning that I should not shift TO using that macro instead shift AWAY > from using it? > > I have been doing some cleanup and been shifting to using it more. ICOM_THIS_MULTI macro should go away. Your patch made ICOM_THIS_MULTI look a bit better by using CONTAINING_RECORD, but there is not much point in doing it, since ICOM_THIS_MULTI should be completely removed. Cheers, Jacek

March 30, 2012

Re: quartz: update ICOM_THIS_MULTI to follow the new COM standard

by Aric Stewart

Meaning that I should not shift TO using that macro instead shift AWAY from using it? I have been doing some cleanup and been shifting to using it more. -aric On 3/30/12 11:08 AM, Jacek Caban wrote: > On 03/30/12 17:55, Aric Stewart wrote: >> diff --git a/dlls/quartz/quartz_private.h b/dlls/quartz/quartz_private.h >> index 35cd52b..d2f680c 100644 >> --- a/dlls/quartz/quartz_private.h >> +++ b/dlls/quartz/quartz_private.h >> @@ -38,7 +38,7 @@ >> #define BYTES_FROM_MEDIATIME(time) SEC_FROM_MEDIATIME(time) >> #define MSEC_FROM_MEDIATIME(time) ((time) / 10000) >> >> -#define ICOM_THIS_MULTI(impl,field,iface) impl* const This=(impl*)((char*)(iface) - offsetof(impl,field)) >> +#define ICOM_THIS_MULTI(impl,field,iface) impl* const This=CONTAINING_RECORD(iface, impl, field) > > These should disappear once the clean up of affected code is done. > > Cheers, > Jacek

March 30, 2012

Re: quartz: update ICOM_THIS_MULTI to follow the new COM standard

by Jacek Caban

On 03/30/12 17:55, Aric Stewart wrote: > diff --git a/dlls/quartz/quartz_private.h b/dlls/quartz/quartz_private.h > index 35cd52b..d2f680c 100644 > --- a/dlls/quartz/quartz_private.h > +++ b/dlls/quartz/quartz_private.h > @@ -38,7 +38,7 @@ > #define BYTES_FROM_MEDIATIME(time) SEC_FROM_MEDIATIME(time) > #define MSEC_FROM_MEDIATIME(time) ((time) / 10000) > > -#define ICOM_THIS_MULTI(impl,field,iface) impl* const This=(impl*)((char*)(iface) - offsetof(impl,field)) > +#define ICOM_THIS_MULTI(impl,field,iface) impl* const This=CONTAINING_RECORD(iface, impl, field) These should disappear once the clean up of affected code is done. Cheers, Jacek

March 30, 2012

Re: [2/2] gdi32: Simplify font cache. (try 2)

by Alexandre Julliard

Kusanagi Kouichi <slash(a)ac.auone-net.jp> writes: > @@ -1516,23 +1464,8 @@ static void add_face_to_cache(Face *face) > RegSetValueExW(hkey_face, face_full_name_value, 0, REG_SZ, (BYTE*)face->FullName, > (strlenW(face->FullName) + 1) * sizeof(WCHAR)); > > - reg_save_dword(hkey_face, face_index_value, face->face_index); > - reg_save_dword(hkey_face, face_italic_value, (face->ntmFlags & NTM_ITALIC) != 0); > - reg_save_dword(hkey_face, face_bold_value, (face->ntmFlags & NTM_BOLD) != 0); > - reg_save_dword(hkey_face, face_version_value, face->font_version); > - reg_save_dword(hkey_face, face_external_value, face->external); > - > - RegSetValueExW(hkey_face, face_font_sig_value, 0, REG_BINARY, (BYTE*)&face->fs, sizeof(face->fs)); > + RegSetValueExW(hkey_face, face_value, 0, REG_BINARY, (BYTE*)face, sizeof *face); I don't think that's a good idea. There are many things in the structure that don't make sense to have in the registry. Also this won't work on 64-bit. -- Alexandre Julliard julliard(a)winehq.org

March 30, 2012

Re: [PATCH 3/3] dmsynth: Put port caps that match native ones.

by Andrew Eikum

On Fri, Mar 30, 2012 at 12:33:51PM +0200, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Andrew Eikum asked Christian Costa: > >Just to be clear, which "native" do you mean? Does this match Windows > >7's dmusic behavior, or something else? I've been trying to target > >Windows 7's behavior in the new audio design. > > A w7 target makes a lot of sense for mmdevapi/WASAPI. > > However, isn't DMusic a thing of the past? In that case, I argue that DSound and DMusic > should target the "best in class" native OS of the time where apps were written > using these APIs, because the app writers "optimized" their apps to the behaviour > they could observe. Wouldn't "best in class" mean XP for DSound/DMusic? > > For similar reasons, the MCI should mimic w9x(/wxp) behaviour, because that's what > was available when apps using the MCI were developed. > > I prefer to hear "thank you guys, app X works like a charm in Wine like it worked on > my rusty w98 and later xp box, whereas it refuses to run on w7" rather than > "you guys do a great job of making my app X worked as badly in Wine as in w7 :-( > whereas it used to work fine on my w98/xp machine". > I think about the goal of "targeting Windows 7" as more about revealing how Microsoft chose to implement these APIs on top of MMDevAPI, than about replicating Windows 7's behavior exactly. Targeting Windows 7 is the default choice when implementing these APIs in Wine, and when we find applications that expect older behavior, we can deviate from Windows 7's behavior to fix them specifically. Andrew

March 30, 2012

Re: jscript: Add VT_I2 support (try 2)

by Jacek Caban

Hi Alistair, On 03/30/12 12:29, Alistair Leslie-Hughes wrote: > Hi, > > > Changelog: > jscript: Add VT_I2 support > hres = IDispatchEx_InvokeEx(dispex, id, ctx->lcid, flags, dp, retv, &ei->ei, &ctx->jscaller->IServiceProvider_iface); + if(SUCCEEDED(hres) && retv) + { + if(V_VT(retv) == VT_I2) + VariantChangeType(retv, retv, 0, VT_I4); + } Since the conversion here is trivial, why not do it directly? --- a/dlls/jscript/jsutils.c +++ b/dlls/jscript/jsutils.c @@ -191,6 +191,10 @@ HRESULT to_primitive(script_ctx_t *ctx, VARIANT *v, jsexcept_t *ei, VARIANT *ret case VT_R8: *ret = *v; break; + case VT_I2: + V_VT(ret) = VT_I4; + V_I4(ret) = V_I2(v); + break; I thought the findings we've discussed off-list was that internal values should never be of VT_I2 types, so this should never happen. If it's not the case, I'd like to see a test case. +function TestVT_I2() +{ + varI2 = GetShort(); + num3 = 3 + + ok(getVT(varI2) === "VT_I4", "getVT(varI2) = " + getVT(varI2)); Please include getVT(GetShort()) test I've showed you. This eliminates a lot of flow of value. + if(!strcmp_wa(bstrName, "GetShort")) { + *pid = DISPID_GLOBAL_SHORT; + return S_OK; + } Please follow JavaScript names convention (this should be getShort). Cheers, Jacek

March 30, 2012

Re: [2/2] scrrun: Add scrrun tests (try 3)

by Marvin

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

March 30, 2012

Re: gdi32: Add support for loading scalable font resources.

by Dmitry Timoshkov

Huw Davies <huw(a)codeweavers.com> wrote: > > > + if (size.u.LowPart < sizeof( *dos )) goto fail; > > > > Testing LowPart only could not work for large sizes. > > Of course, but we don't care if very large files fail, they won't be > genuine resource files anyway. Then returning 64-bit sizes doesn't make sence, and large sizes should be detected and rejected. -- Dmitry.

March 30, 2012

Re: gdi32: Add support for loading scalable font resources.

by Huw Davies

On Fri, Mar 30, 2012 at 07:31:54PM +0900, Dmitry Timoshkov wrote: > Huw Davies <huw(a)codeweavers.com> wrote: > > > + if (size.u.LowPart < sizeof( *dos )) goto fail; > > Testing LowPart only could not work for large sizes. Of course, but we don't care if very large files fail, they won't be genuine resource files anyway. Huw.

March 30, 2012

[PATCH 3/3] dmsynth: Put port caps that match native ones.

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

Hi, Andrew Eikum asked Christian Costa: >Just to be clear, which "native" do you mean? Does this match Windows >7's dmusic behavior, or something else? I've been trying to target >Windows 7's behavior in the new audio design. A w7 target makes a lot of sense for mmdevapi/WASAPI. However, isn't DMusic a thing of the past? In that case, I argue that DSound and DMusic should target the "best in class" native OS of the time where apps were written using these APIs, because the app writers "optimized" their apps to the behaviour they could observe. Wouldn't "best in class" mean XP for DSound/DMusic? For similar reasons, the MCI should mimic w9x(/wxp) behaviour, because that's what was available when apps using the MCI were developed. I prefer to hear "thank you guys, app X works like a charm in Wine like it worked on my rusty w98 and later xp box, whereas it refuses to run on w7" rather than "you guys do a great job of making my app X worked as badly in Wine as in w7 :-( whereas it used to work fine on my w98/xp machine". Actually, there are quite a few AppDB comments like the first one. One reason might be that the dlls those app use were added to Wine at a time where the target OS was w9x or xp, whereas if they were written now, targeting w7, the old app would not work in Wine either. A related topic is: we have no idea what the "set compatibility for wXY" checkbox in w7 does. Recently, I discovered that "Age of Empires II - Conquerors" only plays videos on a w7 machine when you set w7 to xp compatibility. Why? The rest of the app seems to work (except for the purple grass issue, which requires a particular DirectDraw compatibility registry entry in w7). Did AoE target w7 when it was written? Obviously not. Regards, Jörg Höhle

March 30, 2012

Re: gdi32: Add support for loading scalable font resources.

by Dmitry Timoshkov

Huw Davies <huw(a)codeweavers.com> wrote: > + if (size.u.LowPart < sizeof( *dos )) goto fail; Testing LowPart only could not work for large sizes. -- Dmitry.

March 30, 2012

Re: [PATCH 2/3] dmsynth: Check the rigth CLSID to create the DirectMusicSynthSink object.

by Marvin

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=17568 Your paranoid android. === WNT4WSSP6 (32 bit dmsynth) === dmsynth.c:39: Test failed: CoCreateInstance returned: 80040154 dmsynth.c:42: Test failed: CoCreateInstance returned: 80040154 === W2KPROSP4 (32 bit dmsynth) === dmsynth.c:39: Test failed: CoCreateInstance returned: 80004002 dmsynth.c:42: Test failed: CoCreateInstance returned: 80004002 === W2K3R2SESP2 (32 bit dmsynth) === dmsynth.c:39: Test failed: CoCreateInstance returned: 80040154 dmsynth.c:42: Test failed: CoCreateInstance returned: 80040154 === W2K8SE (32 bit dmsynth) === dmsynth.c:39: Test failed: CoCreateInstance returned: 80040154 dmsynth.c:42: Test failed: CoCreateInstance returned: 80040154

March 29, 2012

Re: [PATCH 1/3] dmsynth: Add basic tests.

by Marvin

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=17567 Your paranoid android. === WNT4WSSP6 (32 bit dmsynth) === dmsynth.c:39: Test failed: CoCreateInstance returned: 80040154 dmsynth.c:42: Test failed: CoCreateInstance returned: 80040154 === W2KPROSP4 (32 bit dmsynth) === dmsynth.c:39: Test failed: CoCreateInstance returned: 80004002 dmsynth.c:42: Test failed: CoCreateInstance returned: 80004002 === W2K3R2SESP2 (32 bit dmsynth) === dmsynth.c:39: Test failed: CoCreateInstance returned: 80040154 dmsynth.c:42: Test failed: CoCreateInstance returned: 80040154 === W2K8SE (32 bit dmsynth) === dmsynth.c:39: Test failed: CoCreateInstance returned: 80040154 dmsynth.c:42: Test failed: CoCreateInstance returned: 80040154

March 29, 2012

Re: [PATCH 3/3] d3drm: Implement CreateMesh method and stubbed IDirect3DRMMesh interface.

by Christian Costa

Le 30/03/2012 00:28, Michael Stefaniuc a écrit : > Hello Christian, > > On 03/29/2012 11:57 PM, Christian Costa wrote: >> +HRESULT Direct3DRMMesh_create(REFIID riid, IUnknown** ppObj) >> +{ >> + IDirect3DRMMeshImpl* object; >> + >> + TRACE("(%p)\n", ppObj); >> + >> + object = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(IDirect3DRMMeshImpl)); >> + if (!object) >> + { >> + ERR("Out of memory\n"); >> + return E_OUTOFMEMORY; >> + } >> + >> + object->IDirect3DRMMesh_iface.lpVtbl =&Direct3DRMMesh_Vtbl; >> + object->ref = 1; >> + >> + if (IsEqualGUID(riid,&IID_IDirect3DRMMesh)) >> + *ppObj = (IUnknown*)&object->IDirect3DRMMesh_iface; >> + else >> + *ppObj = (IUnknown*)&object->IDirect3DRMMesh_iface; > both if and else code path are the same. > >> + >> + return S_OK; >> +} >> + > bye > michael > Thanks Michael. Something was wrong. I resent a cleaner patch. Bye Christian

March 29, 2012

Re: [PATCH 3/3] d3drm: Implement CreateMesh method and stubbed IDirect3DRMMesh interface.

by Michael Stefaniuc

Hello Christian, On 03/29/2012 11:57 PM, Christian Costa wrote: > +HRESULT Direct3DRMMesh_create(REFIID riid, IUnknown** ppObj) > +{ > + IDirect3DRMMeshImpl* object; > + > + TRACE("(%p)\n", ppObj); > + > + object = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(IDirect3DRMMeshImpl)); > + if (!object) > + { > + ERR("Out of memory\n"); > + return E_OUTOFMEMORY; > + } > + > + object->IDirect3DRMMesh_iface.lpVtbl = &Direct3DRMMesh_Vtbl; > + object->ref = 1; > + > + if (IsEqualGUID(riid, &IID_IDirect3DRMMesh)) > + *ppObj = (IUnknown*)&object->IDirect3DRMMesh_iface; > + else > + *ppObj = (IUnknown*)&object->IDirect3DRMMesh_iface; both if and else code path are the same. > + > + return S_OK; > +} > + bye michael

March 29, 2012

Re: Would like to get some feedback on GSOC idea

by Juan Lang

Hi Marek, On Tue, Mar 27, 2012 at 9:13 AM, M C <kcmark(a)gmail.com> wrote: > Hi everyone, > > My name is Marek Chmiel, I am a student a NEIU. I am studying computer > science and network security related topics. This semester I had spent > a fair amount of time writing crypt related functions with java, and > became very interested in Cryptography. After looking over the > suggested ideas on SOC official wine wiki I was pleasantly surprised > to see that there was already a crypt related idea suggested. I have a > great understanding of c++ and java, and though I know c I have not > worked with it as much as the other languages. > > Implementing a DSS provider sounds like an awesome task to tackle, if > someone has never written code for Linux, can they take on such a > task? Are there any significant issues implementing a DSS that you > guys know about? Any crypt GSOC ideas would you suggest for someone > who has wrote limited amount of code for Linux? If you know C, you ought to be able to code in Linux. I don't see that being a significant hurdle. I don't know of any significant issues implementing a DSS provider. The usual gotchas with coding for Wine apply here: tests, tests, tests. Solid test cases are a prerequisite to adding new code to Wine, and if a SoC project produces nothing but a solid test suite, it's still a win. I expect this is a pretty straightforward project for someone motivated, so I'm happy to see someone interested in picking it up. > What I would also like to do, besides implementing a DSS provider, is > to fix most if not all of the crypt related bugs that remain in Wine. > This might seem like more than most people can chew, but viewing the > Bug Tracking database it appears that there aren't that many crypt > related bugs and might even be caused by a lack of a DSS provider > (Hopefully this wouldn't create a entire new series of bugs). There aren't that many bugs, it's true. I don't think many of them relate specifically to DSS, and some may be quite challenging to fix. But the more you can fix, the better :) As you dig more into the project, I'm sure you'll have more specific questions. By all means ask once you get there. (Also, I'll try to be a mentor, should your project be accepted. I may be on vacation part of the summer, hopefully not enough to impact your work too much.) --Juan

March 29, 2012

Implementing a DSS provider

by M C

Hello everyone, I am doing some research in regards GSOC, and would like to find out if anyone besides Juan Lang is experienced enough to make suggestions in regards to bug 10506 and/or the implementation of a DSS provider.

March 29, 2012

Re: [PATCH 2/5] dmusic: Enumerate ports for midi out and midi in devices in EnumPort.

by Christian Costa

Le 29/03/2012 20:25, Alexandre Julliard a écrit : > Christian Costa<titan.costa(a)gmail.com> writes: > >> With this patch I get exactly the same output for ports caps (except guid) as native. >> I kept the comment regarding dmusic32 usage altough the native version >> of dmusic I used does standard winmm calls to get port informations. >> --- >> dlls/dmusic/Makefile.in | 2 - >> dlls/dmusic/dmusic.c | 120 ++++++++++++++++++++++++++++++++--------------- >> 2 files changed, 82 insertions(+), 40 deletions(-) > It doesn't work here: > > ../../../tools/runtest -q -P wine -M dmime.dll -T ../../.. -p dmime_test.exe.so performance.c&& touch performance.ok > performance.c:111: Test failed: Got unexpected portcaps struct size: 00000004 > make[1]: *** [performance.ok] Error 1 > This happens in tests newly added by Andrew (dmusic: Support creating default ports with GUID_NULL). In his test, the dwSize member of the structure DMUS_PORTCAPS is not initialized before getting port caps This worked because before my patch only the Microsoft Synthetizer is enumerated and caps returned by the Synth GepCaps sets the dwSize member. I can sets the dwSize in my code but normally it's up to the caller to set the dwSize member. The callee should copy the number of bytes specified by dwSize or just return an error.

March 29, 2012

Re: [PATCH 2/5] dmusic: Enumerate ports for midi out and midi in devices in EnumPort.

by Alexandre Julliard

Christian Costa <titan.costa(a)gmail.com> writes: > With this patch I get exactly the same output for ports caps (except guid) as native. > I kept the comment regarding dmusic32 usage altough the native version > of dmusic I used does standard winmm calls to get port informations. > --- > dlls/dmusic/Makefile.in | 2 - > dlls/dmusic/dmusic.c | 120 ++++++++++++++++++++++++++++++++--------------- > 2 files changed, 82 insertions(+), 40 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M dmime.dll -T ../../.. -p dmime_test.exe.so performance.c && touch performance.ok performance.c:111: Test failed: Got unexpected portcaps struct size: 00000004 make[1]: *** [performance.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

March 29, 2012

Re: MsiGetFileHash

by Hans Leidekker

On Thu, 2012-03-29 at 18:29 +0200, Robert van Herk wrote: > + mapping = CreateFileMappingW( handle, NULL, PAGE_READONLY, 0, 0, NULL ); > + if (mapping) > + { > + p = MapViewOfFile( mapping, FILE_MAP_READ, 0, 0, length ); > + if (p) > + { > + MD5_CTX ctx; > + > + MD5Init( &ctx ); > + MD5Update( &ctx, p, length ); > + MD5Final( &ctx ); > + UnmapViewOfFile( p ); > + > + memcpy( pHash->dwData, ctx.digest, sizeof pHash->dwData ); > + r = ERROR_SUCCESS; > + } > + CloseHandle( mapping ); > + } > + } else { > + /* Empty file -> set hash to 0 */ > + memset( pHash->dwData, 0, sizeof pHash->dwData ); > + r = ERROR_SUCCESS; > } > + > CloseHandle( handle ); Please use 4 space indentation and put brackets on a new line like in the rest of that function. Same for the test. Please also provide a more descriptive subject line and prefix it with "msi: "

March 29, 2012

Re: SoC 2012 Ideas

by Stefan Dösinger

Am Mittwoch, 28. März 2012, 22:10:27 schrieb Charles Davis: > 2) HLSL compiler. My general response to "HLSL Compiler" would be "too complex for gsoc, too much work, nope", but since I know that you worked on compilers in the past it might work for you. I cannot promise anything of course, but my guess is that it is worth writing an application. I think three things would be important: 1) A plan how to integrate the compiler step by step. I think a general consensus is to start with a parser that can parse the entire (d3d9?) language, but I don't know what the idea is beyond that. 2) A flexible plan that allows for adjustments depending on how the project progresses, once a complete parser is done. The good thing about the parser is that I've once written a hacky compiler as a school project, and the parser is pretty much complete for d3d9 shaders. Even if the other code is pretty ugly, the parser should be reusable. 3) A design that is flexible enough for future needs(or well, d3d10/11). I am still afraid of getting stuck in a dead end street with anything written from scratch, but since all other options failed I guess that's the only way left. Maybe Henri and Matteo can weight in with their opinions as well. Cheers, Stefan

March 29, 2012

Re: [PATCH 3/3] (try2) gdi32: Add support for loading scalable font resources.

by Alexandre Julliard

Huw Davies <huw(a)codeweavers.com> writes: > --- > dlls/gdi32/font.c | 75 +++++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 75 insertions(+), 0 deletions(-) This one doesn't build: gcc -m32 -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings -fno-omit-frame-pointer -Wpointer-arith -Wlogical-op -Werror -I/usr/include/freetype2 -g -O2 -o font.o font.c font.c: In function ‘AddFontResourceExW’: font.c:3498:59: error: ‘count’ may be used uninitialized in this function [-Werror=uninitialized] font.c:3475:36: note: ‘count’ was declared here cc1: all warnings being treated as errors make[1]: *** [font.o] Error 1 Admittedly count would always be initialized with the files we create, but we probably shouldn't rely on that. -- Alexandre Julliard julliard(a)winehq.org

March 29, 2012

Re: [PATCH 2/5] dmusic: Enumerate ports for midi out and midi in devices in EnumPort.

by Andrew Eikum

On Thu, Mar 29, 2012 at 04:18:20PM +0200, Christian Costa wrote: > It's the original code. I decided to keep it in this patch and add error > checking in the patch that comes just after. > I can merge them but I prefer to do things incrementally as much as > possible. Ah, sure enough. I missed that patch. Though in [3/5], you're missing assigning hr for _GetPortCaps(). I also think it would be nice to WARN with the result code in the failure case (or TRACE if a failure is expected in some cases). You know, the usual "if(FAILED(hr)){WARN(..., hr); return hr;}" error checking thing.

March 29, 2012

Re: [PATCH 5/5] dmusic: Implement partially SetDirectSound.

by Christian Costa

2012/3/29 Andrew Eikum <aeikum(a)codeweavers.com> > It would be nice to see some tests for this. For example, how does > this IDirectSound reference relate to the one created by > IDirectMusicPerformance::InitAudio()? > > There are few tests mark as todo in my first dmusic patch about interaction beween SetDirectSound and CreatePort. These tests were supposed to be fixed by this patch but it needed some stuff in CreatePort as well as GUID_NULL support. I removed this part because you send a patch for it. I will wait you patch gets in and resend the full version. More generally, wrt to SetDirectSound, I would like to focus first on dmusic only without dmime Init and InitAudio involved. I've another patch next involving dmime which fixes Init wrt to SetDirectSound. I also doing so InitAudio test but I don't know why I can event make the dmime tests running with all dlls as native.

March 29, 2012

Re: [PATCH 3/3] dmsynth: Put port caps that match native ones.

by Christian Costa

2012/3/29 Andrew Eikum <aeikum(a)codeweavers.com> > Just to be clear, which "native" do you mean? Does this match Windows > 7's dmusic behavior, or something else? I've been trying to target > Windows 7's behavior in the new audio design. > > They're recents but I don't remember. I will check this evening. I didn't know about Windows 7 target but I'm ok with that so I will aligned if needed. > Also... > > On Thu, Mar 29, 2012 at 08:53:52AM +0200, Christian Costa wrote: > > - obj->pCaps.dwEffectFlags = DMUS_EFFECT_REVERB | DMUS_EFFECT_CHORUS > | DMUS_EFFECT_DELAY; > > + obj->pCaps.dwEffectFlags = DMUS_EFFECT_REVERB; /* > DMUS_EFFECT_CHORUS | DMUS_EFFECT_DELAY */ > > I'd just remove the unused flags. No need for crufty comments. > > > Ok I will remove them.

March 29, 2012

Re: [PATCH 2/5] dmusic: Enumerate ports for midi out and midi in devices in EnumPort.

by Christian Costa

2012/3/29 Andrew Eikum <aeikum(a)codeweavers.com> > On Thu, Mar 29, 2012 at 08:52:45AM +0200, Christian Costa wrote: > > + midiOutGetDevCapsW(index - 1, &caps, sizeof(caps)); > > ... > > + CoCreateInstance(&CLSID_DirectMusicSynth, NULL, > CLSCTX_INPROC_SERVER, &IID_IDirectMusicSynth8, (void**)&synth); > > + IDirectMusicSynth8_GetPortCaps(synth, port_caps); > > Maybe I'm pickier than most people, but I like error checking on these > sorts of calls. They make it easier to find what is happening when > something goes terribly and unexpectedly wrong. > It's the original code. I decided to keep it in this patch and add error checking in the patch that comes just after. I can merge them but I prefer to do things incrementally as much as possible.

March 29, 2012

Re: [PATCH 3/3] dmsynth: Put port caps that match native ones.

by Andrew Eikum

Just to be clear, which "native" do you mean? Does this match Windows 7's dmusic behavior, or something else? I've been trying to target Windows 7's behavior in the new audio design. Also... On Thu, Mar 29, 2012 at 08:53:52AM +0200, Christian Costa wrote: > - obj->pCaps.dwEffectFlags = DMUS_EFFECT_REVERB | DMUS_EFFECT_CHORUS | DMUS_EFFECT_DELAY; > + obj->pCaps.dwEffectFlags = DMUS_EFFECT_REVERB; /* DMUS_EFFECT_CHORUS | DMUS_EFFECT_DELAY */ I'd just remove the unused flags. No need for crufty comments.

March 29, 2012

Re: [PATCH 2/5] dmusic: Enumerate ports for midi out and midi in devices in EnumPort.

by Andrew Eikum

On Thu, Mar 29, 2012 at 08:52:45AM +0200, Christian Costa wrote: > + midiOutGetDevCapsW(index - 1, &caps, sizeof(caps)); > ... > + CoCreateInstance(&CLSID_DirectMusicSynth, NULL, CLSCTX_INPROC_SERVER, &IID_IDirectMusicSynth8, (void**)&synth); > + IDirectMusicSynth8_GetPortCaps(synth, port_caps); Maybe I'm pickier than most people, but I like error checking on these sorts of calls. They make it easier to find what is happening when something goes terribly and unexpectedly wrong.

March 29, 2012

Re: [PATCH 5/5] dmusic: Implement partially SetDirectSound.

by Andrew Eikum

It would be nice to see some tests for this. For example, how does this IDirectSound reference relate to the one created by IDirectMusicPerformance::InitAudio()? On Thu, Mar 29, 2012 at 08:53:10AM +0200, Christian Costa wrote: > > --- > dlls/dmusic/dmusic.c | 27 +++++++++++++++++++++------ > dlls/dmusic/dmusic_private.h | 2 ++ > 2 files changed, 23 insertions(+), 6 deletions(-) > > diff --git a/dlls/dmusic/dmusic.c b/dlls/dmusic/dmusic.c > index 8f2edea..60d6b8a 100644 > --- a/dlls/dmusic/dmusic.c > +++ b/dlls/dmusic/dmusic.c > @@ -52,19 +52,22 @@ static ULONG WINAPI IDirectMusic8Impl_AddRef (LPDIRECTMUSIC8 iface) { > return refCount; > } > > -static ULONG WINAPI IDirectMusic8Impl_Release (LPDIRECTMUSIC8 iface) { > +static ULONG WINAPI IDirectMusic8Impl_Release(LPDIRECTMUSIC8 iface) > +{ > IDirectMusic8Impl *This = (IDirectMusic8Impl *)iface; > ULONG refCount = InterlockedDecrement(&This->ref); > > TRACE("(%p)->(ref before=%u)\n", This, refCount + 1); > > if (!refCount) { > + if (This->dsound) > + IDirectSound_Release(This->dsound); > HeapFree(GetProcessHeap(), 0, This->ppPorts); > HeapFree(GetProcessHeap(), 0, This); > } > > DMUSIC_UnlockModule(); > - > + > return refCount; > } > > @@ -257,10 +260,22 @@ static HRESULT WINAPI IDirectMusic8Impl_GetDefaultPort (LPDIRECTMUSIC8 iface, LP > return S_OK; > } > > -static HRESULT WINAPI IDirectMusic8Impl_SetDirectSound (LPDIRECTMUSIC8 iface, LPDIRECTSOUND pDirectSound, HWND hWnd) { > - IDirectMusic8Impl *This = (IDirectMusic8Impl *)iface; > - FIXME("(%p, %p, %p): stub\n", This, pDirectSound, hWnd); > - return S_OK; > +static HRESULT WINAPI IDirectMusic8Impl_SetDirectSound(LPDIRECTMUSIC8 iface, LPDIRECTSOUND dsound, HWND wnd) > +{ > + IDirectMusic8Impl *This = (IDirectMusic8Impl *)iface; > + > + FIXME("(%p, %p, %p): partial implementation\n", This, dsound, wnd); > + > + if (dsound) > + { > + This->dsound = dsound; > + IDirectSound_AddRef(dsound); > + } > + > + /* If no direct sound object is given, native does not create one yet */ > + This->dsound_inited = TRUE; > + > + return S_OK; > } > > static HRESULT WINAPI IDirectMusic8Impl_SetExternalMasterClock (LPDIRECTMUSIC8 iface, IReferenceClock* pClock) { > diff --git a/dlls/dmusic/dmusic_private.h b/dlls/dmusic/dmusic_private.h > index c05adf0..b0655d6 100644 > --- a/dlls/dmusic/dmusic_private.h > +++ b/dlls/dmusic/dmusic_private.h > @@ -96,6 +96,8 @@ struct IDirectMusic8Impl { > IReferenceClockImpl* pMasterClock; > IDirectMusicPort** ppPorts; > int nrofports; > + BOOL dsound_inited; > + IDirectSound* dsound; > }; > > /***************************************************************************** > > >

March 29, 2012

Re: po: Update German translation

by Julian Rüger

Hi André, Am Mittwoch, den 28.03.2012, 20:37 +0200 schrieb André Hentschel: > Thx missed that, next time it's all up to you. Giving the translation stuff completely in your hands now. :) OK, umm, thanks I guess ;) I might still bug you for approval though. Best, Julian PS: That mail was supposed to be private, since I used German, but it was late and I screwed up :)

March 29, 2012

Re: [PATCH 1/2] vbscript: Added Mid function implementation

by Marvin

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=17548 Your paranoid android. === WNT4WSSP6 (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 === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

March 29, 2012

Re: [PATCH 1/2] vbscript: Added Mid function implementation

by Marvin

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=17548 Your paranoid android. === WNT4WSSP6 (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 === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

March 29, 2012

Re: SoC 2012 Ideas

by Alex Bradbury

On 29 March 2012 10:01, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > BTW, I once defined a set of iptable rules to prevent networking for Wine (or was it for a whole user?) > based on the consideration that the apps I use have nothing to do with networking. > Here too, nothing need be changed in Wine. You can also add a 'nonet' group, configure an iptables rule to drop all packets from that gid and then use sg to execute wine using that nonet group. Of course this assumes the apps you run don't or can't switch from nonet to another group. Alex

March 29, 2012

SoC 2012 Ideas

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

Charles Davis wrote: >1) Make Wine use App Sandbox on Mac OS X. >At the very least, I would like to be able to limit Wine's file-system activity to the prefix. I'm not familiar with Mac OS X' particular security features, but I wonder why limiting FS activity needs changes in wine? With AppArmor or the like on Linux, you'd define a set of rules living outside of the app. Limiting to the prefix won't work, because /dev/tty and /tmp/X11.socket etc. need be used. All my apps are installed in a directory outside any .wine prefix. There's a symlink from within C:\Programs. How would you take that into account? BTW, I once defined a set of iptable rules to prevent networking for Wine (or was it for a whole user?) based on the consideration that the apps I use have nothing to do with networking. Here too, nothing need be changed in Wine. Regards, Jörg Höhle

March 29, 2012

Re: RFC: KUSER_SHARED_DATA update patch to fix bug 29168

by Johan Gill

On Thu, Mar 22, 2012 at 5:19 AM, Joey Yandle <dragon(a)dancingdragon.be>wrote: > > > > It's been explained several times already that any approach to share data > > between wineserver and clients is going to be rejected. > > > > Can you point me to such an explanation? I joined wine-devel just > before posting my RFC. If this has been discussed previously, I'd > prefer to get the context before wasting my and others' time. > > I know they declined an in-process wineserver due to difficulties blaming the right component on a crash: is it the app or wine that's faulty? I found no other relevant discussion on wine-devel since January 2010, when searching for first 'share' and then 'server'. Too bad if a fork is needed, couldn't the sharing be configurable?

March 29, 2012