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

Re: [PATCH 1/5] hhctrl.ocx: Add HTML to Unicode parsing capability.

by Jacek Caban

On 6/8/12 11:18 PM, Erich E. Hoover wrote: > On Fri, Jun 8, 2012 at 8:17 AM, Jacek Caban<jacek(a)codeweavers.com> wrote: >> ... >> I don't know any helper API for that. Writing decoder for HTML-encoded >> characters sounds like a good solution. > How does something like the attached sound? > A few comments: You definitely don't need a new header file for just one funcition declaration. Even the implementation probably doesn't need a separated file (it's <200 lines of code that is unlikely to grow). +#include "hhctrl.h" +#include <mshtml.h> Probably left from the previous patch? + spc = strchr(amp, ' '); + if(spc && spc < sem) + break; /* cannot have a space between the ampersand and the semicolon */ This should not be needed (see above). + /* Convert the characters prior to the HTML encoded character */ + wlen = MultiByteToWideChar(CP_ACP, 0, h, len, NULL, 0); + MultiByteToWideChar(CP_ACP, 0, h, len, w, wlen); One call should be enough. You may just pass remaining space in the output buffer as its length. + if(amp[0] != '#') + { + for(i=0;i<sizeof(html_encoded_symbols)/sizeof(html_encoded_symbols[0]);i++) + { + const char *encoded_symbol = html_encoded_symbols[i].html_code; + + if(strncmp(encoded_symbol, amp, len) == 0) + { + symbol = html_encoded_symbols[i].ascii_symbol; + break; + } + } + } Binary search sounds like a good choice here (although just FIXME comment would be fine for the patch). + { + int tmp; + + sscanf(amp, "%d", &tmp); + symbol = tmp; + } This will decode "&#123xxx;" as 123 instead of an invalid char. If you get it right, the earlier check for space won't be needed. strtol is probably better tool for this. + wlen = MultiByteToWideChar(CP_ACP, 0, &symbol, 1, NULL, 0); + MultiByteToWideChar(CP_ACP, 0, &symbol, 1, w, wlen); Same here, two calls are not needed. Cheers, Jacek

June 10, 2012

Re: Patch 1/2 - [scrrun] - Add initial support for Dictionary - try 2

by Jacek Caban

On 6/8/12 7:44 PM, Vijay Kiran Kamuju wrote: > On Fri, Jun 8, 2012 at 11:00 AM, Jacek Caban<jacek(a)codeweavers.com> wrote: >> Hi Vijay, >> >> On 06/08/12 03:15, Vijay Kiran Kamuju wrote: >>> + *ppvObject = NULL; >>> + if ( IsEqualGUID( riid,&IID_IDictionary ) || >>> + IsEqualGUID( riid,&IID_IPersist ) || >>> + IsEqualGUID( riid,&IID_IDispatch ) || >>> + IsEqualGUID( riid,&IID_IUnknown ) ) >>> + { >>> + *ppvObject = This; >>> + } > Attaching the new dictionary.c with a bit more functionality, please review This looks mostly right. There is one thing I'd change: static ULONG WINAPI dictionary_AddRef(IDictionary *iface) { IDictionaryImpl *This = impl_from_IDictionary( iface ); return InterlockedIncrement(&This->ref ); } [...] dictionary_AddRef(iface); You may just use IDistionary_AddRef here (or IUnknown_AddRef) instead of directly calling the function. This way you don't need to move dictionary_AddRef out of vtbl order (and I generally consider it a better practice, but that's just a personal opinion). Thanks, Jacek

June 10, 2012

Re: joy.cpl icon

by Alexandre Julliard

Joel Holdsworth <joel(a)airwebreathe.org.uk> writes: > Moving over to rsvg-convert is trivial of course, except one > question. Is it present on enough platforms? I'm using Ubunut > 12.04. Is maintainer mode meant to work on Debian Squeeze? Switching to rsvg-convert is fine, maintainer mode is only guaranteed to work on my box ;-) -- Alexandre Julliard julliard(a)winehq.org

June 10, 2012

joy.cpl icon

by Joel Holdsworth

Hi All, I've just submitted an icon for joy.cpl to wine-patches. Unfortunatly I've uncovered a problem with the buildimage script. When I first wrote the script, I used the "rsvg" command to convert svg to png. rsvg has been depreciated in favour of rsvg-convert, which has slightly different semantics: rsvg-convert in.svg > out.png instead of rsvg in.svg out.png Moving over to rsvg-convert is trivial of course, except one question. Is it present on enough platforms? I'm using Ubunut 12.04. Is maintainer mode meant to work on Debian Squeeze? We could support both, but I'd rather not do that. Joel

June 9, 2012

Re: [PATCH 1/5] hhctrl.ocx: Add HTML to Unicode parsing capability.

by Erich E. Hoover

On Fri, Jun 8, 2012 at 8:17 AM, Jacek Caban <jacek(a)codeweavers.com> wrote: > ... > I don't know any helper API for that. Writing decoder for HTML-encoded > characters sounds like a good solution. How does something like the attached sound? Erich

June 8, 2012

Re: iphlpapi: Don't rely on the HAVE_XXX macros having a numeric values.

by Dan Kegel

Alexandre wrote: > It's common practice to avoid it, to make things like -Wundef more useful. Good point. Reading http://ozlabs.org/~rusty/index.cgi/tech/2008-01-04.html makes me sad. -Wundef would be a lot more useful if autoconf defined symbols to zero instead of undefining them; then we could get rid of all the defined() calls, and the compiler could tell us when we'd misspelled a HAVE_XXX. Oh, well. - Dan

June 8, 2012

Re: iphlpapi: Don't rely on the HAVE_XXX macros having a numeric values.

by Alexandre Julliard

Dan Kegel <dank(a)kegel.com> writes: > On Fri, Jun 8, 2012 at 11:51 AM, Francois Gouget <fgouget(a)free.fr> wrote: >> On Fri, 8 Jun 2012, Dan Kegel wrote: >>> Isn't this a no-op? I thought that an undefined symbol was >>> treated as false by the preprocessor. >> >> Actually you may be right. But then this is the only place in Wine where >> we rely on this and I see not reason to make this assumption. Even more >> so since we don't for the other macros in the same test which makes this >> locally inconsistent. > > It feels funny to avoid using a basic feature of C... > maybe we should remove the extra defined() calls. It's common practice to avoid it, to make things like -Wundef more useful. -- Alexandre Julliard julliard(a)winehq.org

June 8, 2012

Re: iphlpapi: Don't rely on the HAVE_XXX macros having a numeric values.

by Dan Kegel

On Fri, Jun 8, 2012 at 11:51 AM, Francois Gouget <fgouget(a)free.fr> wrote: > On Fri, 8 Jun 2012, Dan Kegel wrote: >> Isn't this a no-op? I thought that an undefined symbol was >> treated as false by the preprocessor. > > Actually you may be right. But then this is the only place in Wine where > we rely on this and I see not reason to make this assumption. Even more > so since we don't for the other macros in the same test which makes this > locally inconsistent. It feels funny to avoid using a basic feature of C... maybe we should remove the extra defined() calls.

June 8, 2012

re: iphlpapi: Don't rely on the HAVE_XXX macros having a numeric values.

by Francois Gouget

On Fri, 8 Jun 2012, Dan Kegel wrote: > -#elif defined(HAVE_SYS_SYSCTL_H) && defined(IPCTL_STATS) && > (HAVE_STRUCT_IPSTAT_IPS_TOTAL || HAVE_STRUCT_IP_STATS_IPS_TOTAL) > +#elif defined(HAVE_SYS_SYSCTL_H) && defined(IPCTL_STATS) && > (defined(HAVE_STRUCT_IPSTAT_IPS_TOTAL) || > defined(HAVE_STRUCT_IP_STATS_IPS_TOTAL)) > > Isn't this a no-op? I thought that an undefined symbol was > treated as false by the preprocessor. Actually you may be right. But then this is the only place in Wine where we rely on this and I see not reason to make this assumption. Even more so since we don't for the other macros in the same test which makes this locally inconsistent. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Hiroshima '45 - Czernobyl '86 - Windows '95

June 8, 2012

Re: [PATCH 3/3] wininet: Added InternetGetSecurityInfoByURL tests

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > --- > dlls/wininet/tests/Makefile.in | 2 +- > dlls/wininet/tests/http.c | 38 > ++++++++++++++++++++++++++++++++++++++ > 2 files changed, 39 insertions(+), 1 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M wininet.dll -T ../../.. -p wininet_test.exe.so http.c && touch http.ok http.c:3020: Test failed: InternetGetSecurityInfoByURLA returned: 1(12028), exected 12028 http.c:3153: Test failed: InternetGetSecurityInfoByURLA returned: 1(997), exected 12028 make[1]: *** [http.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

June 8, 2012