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

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