May 2011 - Wine-Devel - list.winehq.org

Re: Strange zero operation in dlls/riched20/tests/editor.c (Coverity)

by Dylan Smith

On Thu, May 5, 2011 at 11:39 AM, Marcus Meissner <meissner(a)suse.de> wrote: > Hi Dylan, folks, > > Coverity sees following constructs in dlls/riched20/tests/editor.c > introduced by your commit aa3b75f6b74fa87641b1f2b5912fbb82feb4c2da > > + SendMessage(hwndRichEdit, WM_CHAR, 22, > + (MapVirtualKey('V', MAPVK_VK_TO_VSC) << 16) & 1); > (several more of similar) > > The 4th argument is always 0 (because of (x<<16)&1). > > You added that Dylan, was perhaps |1 intended for a repeat count of 1? > > Yes, I believe you are right. Thanks for catching that.

May 5, 2011

Re: [3/3] msxml3/domdoc: Add support for VT_ARRAY|VT_UI1 in domdoc_load(). (try 2)

by Adam Martinson

On 05/05/2011 09:37 AM, Nikolay Sivov wrote: > On 5/5/2011 18:14, Adam Martinson wrote: >> I think this is actually the most straightforward/readable way to >> handle it. If multi-dimensional SAFEARRAYs are actually supported, >> we will need separate cases for them. > It's just not the way I thought about it, that's all. Ok, let it be > like that, but could you remove ERR() from it? I feel like it will be > useless line that never works, on the other hand we should add dumping > of array dimension in debugstr_variant() so it will be instantly > visible in trace. It's code that *shouldn't* ever execute AFAIK, that's why I used ERR(). >> And IMHO if an app is trying to do something we don't handle, and >> don't know how it should be handled, it should be a FIXME. > Well ok, I don't really expect it to come often. > I don't either, but it makes debugging a lot easier if it ever does, lol. I think it's just good practice for API functions to complain when they don't know how to handle their args.

May 5, 2011

Re: [2/3] msxml3/domdoc: Add an internal function to load from a UTF8 string.

by Adam Martinson

On 05/05/2011 09:21 AM, Nikolay Sivov wrote: > On 5/5/2011 18:09, Adam Martinson wrote: >> On 05/04/2011 05:56 PM, Nikolay Sivov wrote: >>> You don't need a separate helper for that. doparse() should do fine >>> with "UTF-8" encoding parameter to force encoding. >> This is to avoid calling domdoc_loadXML() from domdoc_load(). When >> we need almost identical behavior from 2 separate interface functions >> having a common internal function they both call makes sense to me... > My point is that we already have doparse(This, str, len, "UTF-8"); > that does exactly what you need. Side effects like setting creating > xmlDocNew(NULL) are handled later in ::load() too. Also ::loadXML() > takes BSTR that's always UTF-16, and we don't do it right now - cause > it's possible to avoid conversion it seems. Adding load_utf8 will mean > we stick to the utf16 -> utf8 conversion in loadXML. > My logic for having this function: domdoc_load() is basically a more flexible version of domdoc_loadXML() that takes a VARIANT instead of a BSTR, and treats its input as a file of some sort. But VT_ARRAY|VT_UI1 case is just a non-null-terminated string, which is more like what domdoc_loadXML() does. To me it makes sense to merge this case with the internal domdoc_loadXML() implementation. I vaguely remember trying to avoid the conversion in domdoc_loadXML() and just passing the BSTR to doparse() with encoding="UTF-16", and running into some quirk in libxml... If memory serves it was that when there's a <?xml encoding="foo"?> declaration in the string that doesn't match the actual encoding, libxml had a fit if the actual encoding wasn't UTF-8. eg, passing a UTF-16 string that contained <?xml encoding="UTF-8"?> caused an error, but passing a UTF-8 string that contained <?xml encoding="UTF-16"?> did not. It's been a while though, it may be worth another look.

May 5, 2011

Strange zero operation in dlls/riched20/tests/editor.c (Coverity)

by Marcus Meissner

Hi Dylan, folks, Coverity sees following constructs in dlls/riched20/tests/editor.c introduced by your commit aa3b75f6b74fa87641b1f2b5912fbb82feb4c2da + SendMessage(hwndRichEdit, WM_CHAR, 22, + (MapVirtualKey('V', MAPVK_VK_TO_VSC) << 16) & 1); (several more of similar) The 4th argument is always 0 (because of (x<<16)&1). You added that Dylan, was perhaps |1 intended for a repeat count of 1? Ciao, Marcus

May 5, 2011

Re: [3/3] msxml3/domdoc: Add support for VT_ARRAY|VT_UI1 in domdoc_load(). (try 2)

by Nikolay Sivov

On 5/5/2011 18:14, Adam Martinson wrote: > On 05/04/2011 06:04 PM, Nikolay Sivov wrote: >> On 5/5/2011 00:38, Adam Martinson wrote: >>> >>> Fixes bugs 14864 + 16453. >>> --- >>> dlls/msxml3/domdoc.c | 27 +++++++++++++ >>> dlls/msxml3/tests/domdoc.c | 94 >>> +++++++++++++++++++++++++++++++++++++++++++- >>> 2 files changed, 120 insertions(+), 1 deletions(-) >>> + case VT_ARRAY|VT_UI1: >>> + { >>> + SAFEARRAY *psa = V_ARRAY(&source); >>> + xmlChar *str; >>> + LONG len; >>> + UINT dim = SafeArrayGetDim(psa); >>> + >>> + switch (dim) >>> + { >>> + case 0: >>> + ERR("SAFEARRAY == NULL\n"); >>> + hr = E_INVALIDARG; >>> + break; >>> + case 1: >>> + /* Only takes UTF8 strings. >>> + * NOT NULL-terminated. */ >>> + SafeArrayAccessData(psa, (void**)&str); >>> + SafeArrayGetUBound(psa, 1,&len); >>> + hr = load_utf8(This, str, ++len, isSuccessful); >>> + SafeArrayUnaccessData(psa); >>> + break; >>> + default: >>> + FIXME("unhandled SAFEARRAY dim: %d\n", dim); >>> + hr = E_NOTIMPL; >>> + } >>> + } >> This could be simplified. SafeArrayGetUBound will fail for case 0 for >> example, and unhandled dimension should be WARN, IMO. > I think this is actually the most straightforward/readable way to > handle it. If multi-dimensional SAFEARRAYs are actually supported, we > will need separate cases for them. It's just not the way I thought about it, that's all. Ok, let it be like that, but could you remove ERR() from it? I feel like it will be useless line that never works, on the other hand we should add dumping of array dimension in debugstr_variant() so it will be instantly visible in trace. > And IMHO if an app is trying to do something we don't handle, and > don't know how it should be handled, it should be a FIXME. Well ok, I don't really expect it to come often.

May 5, 2011

Re: [2/3] msxml3/domdoc: Add an internal function to load from a UTF8 string.

by Nikolay Sivov

On 5/5/2011 18:09, Adam Martinson wrote: > On 05/04/2011 05:56 PM, Nikolay Sivov wrote: >> You don't need a separate helper for that. doparse() should do fine >> with "UTF-8" encoding parameter to force encoding. > This is to avoid calling domdoc_loadXML() from domdoc_load(). When we > need almost identical behavior from 2 separate interface functions > having a common internal function they both call makes sense to me... My point is that we already have doparse(This, str, len, "UTF-8"); that does exactly what you need. Side effects like setting creating xmlDocNew(NULL) are handled later in ::load() too. Also ::loadXML() takes BSTR that's always UTF-16, and we don't do it right now - cause it's possible to avoid conversion it seems. Adding load_utf8 will mean we stick to the utf16 -> utf8 conversion in loadXML.

May 5, 2011

Re: [3/3] msxml3/domdoc: Add support for VT_ARRAY|VT_UI1 in domdoc_load(). (try 2)

by Adam Martinson

On 05/04/2011 06:04 PM, Nikolay Sivov wrote: > On 5/5/2011 00:38, Adam Martinson wrote: >> >> Fixes bugs 14864 + 16453. >> --- >> dlls/msxml3/domdoc.c | 27 +++++++++++++ >> dlls/msxml3/tests/domdoc.c | 94 >> +++++++++++++++++++++++++++++++++++++++++++- >> 2 files changed, 120 insertions(+), 1 deletions(-) >> + case VT_ARRAY|VT_UI1: >> + { >> + SAFEARRAY *psa = V_ARRAY(&source); >> + xmlChar *str; >> + LONG len; >> + UINT dim = SafeArrayGetDim(psa); >> + >> + switch (dim) >> + { >> + case 0: >> + ERR("SAFEARRAY == NULL\n"); >> + hr = E_INVALIDARG; >> + break; >> + case 1: >> + /* Only takes UTF8 strings. >> + * NOT NULL-terminated. */ >> + SafeArrayAccessData(psa, (void**)&str); >> + SafeArrayGetUBound(psa, 1,&len); >> + hr = load_utf8(This, str, ++len, isSuccessful); >> + SafeArrayUnaccessData(psa); >> + break; >> + default: >> + FIXME("unhandled SAFEARRAY dim: %d\n", dim); >> + hr = E_NOTIMPL; >> + } >> + } > This could be simplified. SafeArrayGetUBound will fail for case 0 for > example, and unhandled dimension should be WARN, IMO. I think this is actually the most straightforward/readable way to handle it. If multi-dimensional SAFEARRAYs are actually supported, we will need separate cases for them. And IMHO if an app is trying to do something we don't handle, and don't know how it should be handled, it should be a FIXME.

May 5, 2011

Re: [2/3] msxml3/domdoc: Add an internal function to load from a UTF8 string.

by Adam Martinson

On 05/04/2011 05:56 PM, Nikolay Sivov wrote: > You don't need a separate helper for that. doparse() should do fine > with "UTF-8" encoding parameter to force encoding. This is to avoid calling domdoc_loadXML() from domdoc_load(). When we need almost identical behavior from 2 separate interface functions having a common internal function they both call makes sense to me... > Also will it preserve existing document or will really create empty > one on error is a question. Yes, that's something we should add tests for in the future.

May 5, 2011

Re: cmd: WCMD_delete: simplify logic, avoid assigning variable to i tself (try 2)

by Alexandre Julliard

Dan Kegel <dank(a)kegel.com> writes: > Simpler version suggested by Henri. > I'm hoping this is enough of an improvement to be worth it. It would be better to build a simple mask and test against that, instead of all that silliness with booleans. -- Alexandre Julliard julliard(a)winehq.org

May 5, 2011

Re: [PATCH 1/2] mountmgr: Populate HKLM\HARDWARE\DEVICEMAP\Scsi here instead of in kernel32. (try 4)

by Alexandre Julliard

Charles Davis <cdavis(a)mymail.mines.edu> writes: > + case 0x05: > + data = "CdRomPeripheral"; > + snprintf(buffer, sizeof(buffer), "Cdrom%d", cdrom_no++); > + break; This needs to be set to the device name that mountmgr has assigned to it. That's the point of doing this in mountmgr: making sure that all the information derives from a single source. -- Alexandre Julliard julliard(a)winehq.org

May 5, 2011

Re: [PATCH try3] wininet: Added support for persistent HTTP connections

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > try3: I've included better content draining in this patch (that I was > hoping to do as follow-up previously, due to already big size of the > patch). That fixes observed test failures. Older wininet implementations > don't have it, so the test fails for them. I'm getting a different failure now: ../../../tools/runtest -q -P wine -M wininet.dll -T ../../.. -p wininet_test.exe.so http.c && touch http.ok http.c:1074: Test failed: Read 0 bytes instead of 13 make: *** [http.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

May 5, 2011

Re: [3/3] msxml3/domdoc: Add support for VT_ARRAY|VT_UI1 in domdoc_load(). (try 2)

by Nikolay Sivov

On 5/5/2011 00:38, Adam Martinson wrote: > > Fixes bugs 14864 + 16453. > --- > dlls/msxml3/domdoc.c | 27 +++++++++++++ > dlls/msxml3/tests/domdoc.c | 94 > +++++++++++++++++++++++++++++++++++++++++++- > 2 files changed, 120 insertions(+), 1 deletions(-) > + case VT_ARRAY|VT_UI1: > + { > + SAFEARRAY *psa = V_ARRAY(&source); > + xmlChar *str; > + LONG len; > + UINT dim = SafeArrayGetDim(psa); > + > + switch (dim) > + { > + case 0: > + ERR("SAFEARRAY == NULL\n"); > + hr = E_INVALIDARG; > + break; > + case 1: > + /* Only takes UTF8 strings. > + * NOT NULL-terminated. */ > + SafeArrayAccessData(psa, (void**)&str); > + SafeArrayGetUBound(psa, 1,&len); > + hr = load_utf8(This, str, ++len, isSuccessful); > + SafeArrayUnaccessData(psa); > + break; > + default: > + FIXME("unhandled SAFEARRAY dim: %d\n", dim); > + hr = E_NOTIMPL; > + } > + } This could be simplified. SafeArrayGetUBound will fail for case 0 for example, and unhandled dimension should be WARN, IMO.

May 4, 2011

Re: [2/3] msxml3/domdoc: Add an internal function to load from a UTF8 string.

by Nikolay Sivov

On 5/5/2011 00:38, Adam Martinson wrote: > --- > dlls/msxml3/domdoc.c | 85 > +++++++++++++++++++++++++++++-------------------- > 1 files changed, 50 insertions(+), 35 deletions(-) You don't need a separate helper for that. doparse() should do fine with "UTF-8" encoding parameter to force encoding. Also will it preserve existing document or will really create empty one on error is a question.

May 4, 2011

Re: [2/2] msxml3/domdoc: Add support for VT_ARRAY|VT_UI1 in domdoc_load().

by Nikolay Sivov

On 5/4/2011 19:30, Adam Martinson wrote: > On 05/03/2011 05:30 PM, Nikolay Sivov wrote: >> I'm worried about VT_UI1 being interpreted as ASCII stream or just a >> byte stream that could be in any encoding. If it's a case you can't >> assume it's encoded as utf8, when you do utf8 -> utf16 (for BSTR). >> >> For this particular case you might want direct doparse() call for >> VT_UI1 array, I suggest a simple test -- create byte (VT_UI1) array >> over a WCHAR buffer with UTF16 xml data and try to ::load() from it. >> If encoding is detected then you need direct doparse() call, to do >> completely clear case don't include encoding= attribute in this xml >> data. > I glad you mentioned this, I thought about that too. I did some > testing and it seems that only UTF8 (or maybe just ASCII) is > supported. The SAFEARRAY does seem to be treated more like a file > than a string, eg if there is a '\0' at the end of the array it causes > a parse error (I don't think we need to duplicate that behavior though). Yeah, I don't see a reason to implement this particular case for now. > I'm not sure if multi-dimensional arrays are supported, it will take > some further testing, but if so that can be a separate patch; for now > I'll just add a FIXME if the array is not a vector. I don't expect it's supported, it sounds a bit insane for me to load from multidimensional arrays. I think after this case (VT_UI1 array) implemented we need a WARN for any other variant type. And some tests for sure.

May 4, 2011

Re: Support for D3DQUERY_TIMESTAMP* queries...

by Adam Martinson

OK, I think I addressed those issues, let me know how these look.

May 4, 2011

Re: [PATCH 2/2 try2] wininet: Added support for persistent HTTP connections

by Jacek Caban

On 5/4/11 8:05 PM, Alexandre Julliard wrote: > Jacek Caban<jacek(a)codeweavers.com> writes: > >> That's an already existing race in tests. It fails on Windows as well: >> http://test.winehq.org/data/a343c1fbd0f37a5cadd98698ae5d580727ddf0c7/2003_f… >> I've seen it here and my patch seems to make is more likely to fail. I >> plan fixing it, but, as it's not new, so I think it shouldn't block >> committing my patch. > Maybe it's not new, but it's much worse. That failure used to happen > maybe at most once a week here, but now it's failing 9 times out of 10. > I really don't want to have to always run make test in a loop until it > works. Oh, didn't expect it to be that bad, it fails about 1 out of 5 times here. I will fix the test first then. Jacek

May 4, 2011

Re: [PATCH 2/2 try2] wininet: Added support for persistent HTTP connections

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > That's an already existing race in tests. It fails on Windows as well: > http://test.winehq.org/data/a343c1fbd0f37a5cadd98698ae5d580727ddf0c7/2003_f… > I've seen it here and my patch seems to make is more likely to fail. I > plan fixing it, but, as it's not new, so I think it shouldn't block > committing my patch. Maybe it's not new, but it's much worse. That failure used to happen maybe at most once a week here, but now it's failing 9 times out of 10. I really don't want to have to always run make test in a loop until it works. -- Alexandre Julliard julliard(a)winehq.org

May 4, 2011

Re: [PATCH 2/2 try2] wininet: Added support for persistent HTTP connections

by Jacek Caban

On 05/04/11 16:07, Alexandre Julliard wrote: > Jacek Caban <jacek(a)codeweavers.com> writes: > >> try2: Using GetTickCount64() for timestamps >> >> --- >> dlls/urlmon/tests/protocol.c | 2 +- >> dlls/urlmon/tests/url.c | 20 +- >> dlls/wininet/http.c | 567 >> ++++++++++++++++++++++++------------------ >> dlls/wininet/internet.c | 2 +- >> dlls/wininet/internet.h | 42 +++- >> dlls/wininet/netconnection.c | 138 ++++------- >> dlls/wininet/tests/http.c | 32 +-- >> 7 files changed, 427 insertions(+), 376 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:2621: Test failed: expected 1 retrievals, got 0 > http.c:2628: Test failed: count was wrong > http.c:2629: Test failed: http data wrong > http.c:2649: Test succeeded inside todo block: expected 1 retrievals > make: *** [http.ok] Error 4 That's an already existing race in tests. It fails on Windows as well: http://test.winehq.org/data/a343c1fbd0f37a5cadd98698ae5d580727ddf0c7/2003_f… I've seen it here and my patch seems to make is more likely to fail. I plan fixing it, but, as it's not new, so I think it shouldn't block committing my patch. Jacek

May 4, 2011

Re: winscard/tests: Add test base functions of winscard.dll

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

May 4, 2011

Re: [PATCH 2/2 try2] wininet: Added support for persistent HTTP connections

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > try2: Using GetTickCount64() for timestamps > > --- > dlls/urlmon/tests/protocol.c | 2 +- > dlls/urlmon/tests/url.c | 20 +- > dlls/wininet/http.c | 567 > ++++++++++++++++++++++++------------------ > dlls/wininet/internet.c | 2 +- > dlls/wininet/internet.h | 42 +++- > dlls/wininet/netconnection.c | 138 ++++------- > dlls/wininet/tests/http.c | 32 +-- > 7 files changed, 427 insertions(+), 376 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:2621: Test failed: expected 1 retrievals, got 0 http.c:2628: Test failed: count was wrong http.c:2629: Test failed: http data wrong http.c:2649: Test succeeded inside todo block: expected 1 retrievals make: *** [http.ok] Error 4 -- Alexandre Julliard julliard(a)winehq.org

May 4, 2011

Re: [2/2] msxml3/domdoc: Add support for VT_ARRAY|VT_UI1 in domdoc_load().

by Adam Martinson

On 05/03/2011 05:30 PM, Nikolay Sivov wrote: > I'm worried about VT_UI1 being interpreted as ASCII stream or just a > byte stream that could be in any encoding. If it's a case you can't > assume it's encoded as utf8, when you do utf8 -> utf16 (for BSTR). > > For this particular case you might want direct doparse() call for > VT_UI1 array, I suggest a simple test -- create byte (VT_UI1) array > over a WCHAR buffer with UTF16 xml data and try to ::load() from it. > If encoding is detected then you need direct doparse() call, to do > completely clear case don't include encoding= attribute in this xml data. I glad you mentioned this, I thought about that too. I did some testing and it seems that only UTF8 (or maybe just ASCII) is supported. The SAFEARRAY does seem to be treated more like a file than a string, eg if there is a '\0' at the end of the array it causes a parse error (I don't think we need to duplicate that behavior though). I'm not sure if multi-dimensional arrays are supported, it will take some further testing, but if so that can be a separate patch; for now I'll just add a FIXME if the array is not a vector. >> I remember another place where it would have been useful to be able >> to call domdoc_loadXML() with a UTF8 string to avoid converting to >> BSTR and back, I think in the schema stuff. It would be nice to have >> an internal function to do that, then domdoc_loadXML() can just wrap >> it, but I think that can be a separate patch. > Anyway if you need a interface call to implement some other method use > already defined macro instead of internal static implementation > function. Internal method implementations better not depend on each > other. Ye, you're right, I will add that as part of this set.

May 4, 2011

Re: FAQ translation possible?

by Juan Lang

> I tried to find the wiki/web server responsible, but without success. > Who's responsible for the server? J. Newman? In this case, it's Dimi O'Paun. --Juan

May 4, 2011

Re: FAQ translation possible?

by Frédéric Delanoy

On Wed, May 4, 2011 at 07:24, Ove Kåven <ovek(a)arcticnet.no> wrote: > Den 04. mai 2011 00:49, skrev Frédéric Delanoy: >> But in any case, the language to use should preferably be autoselected >> from WineHQ's lang cookie IMHO. > > The way I understand moinmoin, you need to create a new wiki page with > the translated content. This is typically done by also translating the > page name itself, i.e. if you have an English "MyProject", then you have > a "MeinProjekt" page in German. Anyway, the version of moinmoin used here is dated and doesn't support on-page-change notification, which makes translation (but especially further maintainance) tricky. I tried to find the wiki/web server responsible, but without success. Who's responsible for the server? J. Newman? > Once the translation exist, you can update moinmoin's dictionary page > (the GermanDict page in this case), so that it knows that MeinProjekt is > a German translation of MyProject. With that done, if a German user > accesses MyProject, there will be a toolbar entry to take them to the > German version. > > MoinMoin can do even better for the front page, because if the user > accesses the wiki without requesting a specific page, then moinmoin can > itself choose which front page to return. It's chosen based on the > preferred language of the user's browser, and it will search its > dictionary to find what the name of that language's front page is. So > German people would automatically get StartSeite instead of FrontPage. > > Then, of course, that front page would contain links to the pages of the > language it is written in. So German users would automatically be served > the German frontpage, and all German pages (like StartSeite) would link > to MeinProjekt where the English pages (like FrontPage) would link to > MyProject. > > This scheme, of course, works best if the people putting content into > the wiki are careful not to use acronyms like FAQ as page names. Thanks for the info. Frédéric

May 4, 2011

signal(SIGCHLD,SIG_DFL) before exec()

by Ilya Basin

Hi list. I suffer from this bug: http://bugs.winehq.org/show_bug.cgi?id=27014 In wine sources there're not so many places where exec(3) family is used. In some places SIGCHLD and SIGPIPE are restored to default before calling exec(), in others they aren't. What's the difference? Can anyone explain me the why SIGCHLD not restored to default before calling execvp() here: http://source.winehq.org/source/libs/port/spawn.c?v=wine-1.3.19#L42 int spawnvp(int mode, const char *cmdname, const char *const argv[]) { ... if (mode == _P_OVERLAY) { execvp(cmdname, (char **)argv); /* if we get here it failed */ #ifdef ENOTSUP if (errno != ENOTSUP) /* exec fails on MacOS if the process has multiple threads */ #endif return -1; } Because it's not forked and if execvp() fails, we end up with the default handler?

May 4, 2011

Re: FAQ translation possible?

by Ove Kåven

Den 04. mai 2011 00:49, skrev Frédéric Delanoy: > But in any case, the language to use should preferably be autoselected > from WineHQ's lang cookie IMHO. The way I understand moinmoin, you need to create a new wiki page with the translated content. This is typically done by also translating the page name itself, i.e. if you have an English "MyProject", then you have a "MeinProjekt" page in German. Once the translation exist, you can update moinmoin's dictionary page (the GermanDict page in this case), so that it knows that MeinProjekt is a German translation of MyProject. With that done, if a German user accesses MyProject, there will be a toolbar entry to take them to the German version. MoinMoin can do even better for the front page, because if the user accesses the wiki without requesting a specific page, then moinmoin can itself choose which front page to return. It's chosen based on the preferred language of the user's browser, and it will search its dictionary to find what the name of that language's front page is. So German people would automatically get StartSeite instead of FrontPage. Then, of course, that front page would contain links to the pages of the language it is written in. So German users would automatically be served the German frontpage, and all German pages (like StartSeite) would link to MeinProjekt where the English pages (like FrontPage) would link to MyProject. This scheme, of course, works best if the people putting content into the wiki are careful not to use acronyms like FAQ as page names.

May 4, 2011

Re: FAQ translation possible?

by Frédéric Delanoy

2011/5/3 Juan Lang <juan.lang(a)gmail.com>: >> Wouldn't it make sense to move the FAQ to the wine website repository >> so as to ease translation? FAQ is probably one of the most important >> things to translate IMO. > > We've recently moved it the other way. > >> Or is it more important to remain it to the wiki for quick update/review? > > Yes, that's why it's in the wiki. > --Juan Hmm... makes sense but this makes translation nigh impossible. I could certainly create a custom Fr FAQ but it's more like an ugly hack (and translation updates could prove difficult than they should be... or maybe with on-change email notification?). >From a quick review of moinmoin features (http://moinmo.in/MoinMoinFeatures) it seems i18n is possible but I'm far from an expert in it, although it appears it's possible only for the wiki interface, and not for the wiki's actual contents. But in any case, the language to use should preferably be autoselected from WineHQ's lang cookie IMHO. Maybe someone with moinmoin experience could provide some insight (specifying in language in a page seems possible according to http://moinmo.in/HelpOnLanguages)? Frédéric

May 3, 2011

Re: [2/2] msxml3/domdoc: Add support for VT_ARRAY|VT_UI1 in domdoc_load().

by Nikolay Sivov

On 5/3/2011 18:43, Adam Martinson wrote: > On 05/03/2011 01:45 AM, Nikolay Sivov wrote: >> On 5/3/2011 08:07, Adam Martinson wrote: >>> >>> Fixes bug 14864. >>> --- >>> dlls/msxml3/domdoc.c | 255 >>> ++++++++++++++++++++++++++------------------------ >>> 1 files changed, 134 insertions(+), 121 deletions(-) >>> >>> + case VT_ARRAY|VT_UI1: >>> + { >>> + SAFEARRAY* psa; >>> + BSTR bstr; >>> + psa = V_ARRAY(&source); >>> + bstr = bstr_from_xmlChar(psa->pvData); >>> + hr = domdoc_loadXML(iface, bstr, isSuccessful); >>> + SysFreeString(bstr); >>> + return hr; >>> + } >>> + break; >> Is it really supposed to be utf8 array? Or this will work cause >> one-byte chars match utf8? >> >> Also I don't like this method dependency, I think the proper way is >> to call IXMLDOMDocument3_loadXML(iface...) here. >> Or another way to avoid call through vtable - introduce something >> called domdoc_load_xml(This...) and use it in both places, >> but I think it's not worth it. > > It was the Google Chrome installer, I'm not sure if it's supposed to > be UTF8 or not, all of the characters it used were ASCII. I'm > assuming it's supposed to be UTF8 due to it being VT_UI8 instead of > VT_I8, but I can't say for sure. I'm worried about VT_UI1 being interpreted as ASCII stream or just a byte stream that could be in any encoding. If it's a case you can't assume it's encoded as utf8, when you do utf8 -> utf16 (for BSTR). For this particular case you might want direct doparse() call for VT_UI1 array, I suggest a simple test -- create byte (VT_UI1) array over a WCHAR buffer with UTF16 xml data and try to ::load() from it. If encoding is detected then you need direct doparse() call, to do completely clear case don't include encoding= attribute in this xml data. > I remember another place where it would have been useful to be able > to call domdoc_loadXML() with a UTF8 string to avoid converting to > BSTR and back, I think in the schema stuff. It would be nice to have > an internal function to do that, then domdoc_loadXML() can just wrap > it, but I think that can be a separate patch. Anyway if you need a interface call to implement some other method use already defined macro instead of internal static implementation function. Internal method implementations better not depend on each other.

May 3, 2011

Re: [PATCH 2/2] wininet: Added support for persistent HTTP connections

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > +static DWORD64 collector_timeout; > + > +static DWORD64 current_time(void) > +{ > + ULARGE_INTEGER timeout; > + SYSTEMTIME st; > + FILETIME ft; > + > + GetSystemTime(&st); > + SystemTimeToFileTime(&st, &ft); > + > + timeout.u.LowPart = ft.dwLowDateTime; > + timeout.u.HighPart = ft.dwHighDateTime; > + > + return timeout.QuadPart; > +} That's a lot of complexity for a timestamp, GetTickCount() would work just as well, as long as you do the comparisons correctly. -- Alexandre Julliard julliard(a)winehq.org

May 3, 2011

Re: [PATCH 3/5] d3d8/tests: Fix some failure messages in test_depth_stencil_size().

by Henri Verbeet

On 3 May 2011 22:59, Marvin <testbot(a)testbot.winehq.org> wrote: > === WXPPROSP3 (32 bit device) === > TestLauncher.c:89: Test failed: Can't open test executable C:\winetest\d3d8_test.exe, error 32 > I don't think this patch introduced this failure.

May 3, 2011

Re: [PATCH 4/5] d3d8/tests: Add a Reset test.

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=10710 Your paranoid android. === WXPPROSP3 (32 bit device) === TestLauncher.c:89: Test failed: Can't open test executable C:\winetest\d3d8_test.exe, error 32

May 3, 2011

Re: [PATCH 3/5] d3d8/tests: Fix some failure messages in test_depth_stencil_size().

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=10709 Your paranoid android. === WXPPROSP3 (32 bit device) === TestLauncher.c:89: Test failed: Can't open test executable C:\winetest\d3d8_test.exe, error 32

May 3, 2011

Re: [2/2] msxml3/domdoc: Add support for VT_ARRAY|VT_UI1 in domdoc_load().

by Adam Martinson

On 05/03/2011 09:43 AM, Adam Martinson wrote: > On 05/03/2011 01:45 AM, Nikolay Sivov wrote: >> On 5/3/2011 08:07, Adam Martinson wrote: >>> >>> Fixes bug 14864. >>> --- >>> dlls/msxml3/domdoc.c | 255 >>> ++++++++++++++++++++++++++------------------------ >>> 1 files changed, 134 insertions(+), 121 deletions(-) >>> >>> + case VT_ARRAY|VT_UI1: >>> + { >>> + SAFEARRAY* psa; >>> + BSTR bstr; >>> + psa = V_ARRAY(&source); >>> + bstr = bstr_from_xmlChar(psa->pvData); >>> + hr = domdoc_loadXML(iface, bstr, isSuccessful); >>> + SysFreeString(bstr); >>> + return hr; >>> + } >>> + break; >> Is it really supposed to be utf8 array? Or this will work cause >> one-byte chars match utf8? >> >> Also I don't like this method dependency, I think the proper way is >> to call IXMLDOMDocument3_loadXML(iface...) here. >> Or another way to avoid call through vtable - introduce something >> called domdoc_load_xml(This...) and use it in both places, >> but I think it's not worth it. > > It was the Google Chrome installer, I'm not sure if it's supposed to > be UTF8 or not, all of the characters it used were ASCII. I'm > assuming it's supposed to be UTF8 due to it being VT_UI8 instead of > VT_I8, but I can't say for sure. I remember another place where it > would have been useful to be able to call domdoc_loadXML() with a UTF8 > string to avoid converting to BSTR and back, I think in the schema > stuff. It would be nice to have an internal function to do that, then > domdoc_loadXML() can just wrap it, but I think that can be a separate > patch. > Err, VT_I1/VT_UI1, not VT_I8/VT_UI8.

May 3, 2011

Re: Support for D3DQUERY_TIMESTAMP* queries...

by Henri Verbeet

On 3 May 2011 16:51, Adam Martinson <amartinson(a)codeweavers.com> wrote: > Feedback please. This is in addition to what Stefan already said: > +/* GL_ARB_timer_query */ > +#ifndef GL_ARB_timer_query > +#define GL_ARB_timer_query 1 > +#define GL_TIME_ELAPSED_ARB 0x88BF > +#define GL_TIMESTAMP_ARB 0x8E28 > +#endif > + > +typedef void (WINE_GLAPI *PFNGLQUERYCOUNTERPROC) (GLuint id, GLenum target); > +typedef void (WINE_GLAPI *PFNGLGETQUERYOBJECTI64VPROC) (GLuint id, GLenum pname, GLint64 *params); > +typedef void (WINE_GLAPI *PFNGLGETQUERYOBJECTUI64VPROC) (GLuint id, GLenum pname, GLuint64 *params); Where did you get these? The style reminds me of glext.h. > @@ -95,26 +95,31 @@ static HRESULT WINAPI IDirect3DQuery9Impl_GetDevice(IDirect3DQuery9 *iface, > static D3DQUERYTYPE WINAPI IDirect3DQuery9Impl_GetType(IDirect3DQuery9 *iface) > { > IDirect3DQuery9Impl *This = impl_from_IDirect3DQuery9(iface); > - HRESULT hr; > + D3DQUERYTYPE ret; > > TRACE("iface %p.\n", iface); > > wined3d_mutex_lock(); > - hr = wined3d_query_get_type(This->wineD3DQuery); > + ret = wined3d_query_get_type(This->wineD3DQuery); > wined3d_mutex_unlock(); > > - return hr; > + return ret; > } This makes sense, but should clearly be a separate patch. If you're changing the name anyway, "type" would probably be a more reasonable name than "ret". > +struct _wined3d_timestamp_query > +{ > + struct list entry; > + struct wined3d_context *context; > + int n_ids; > + GLuint ids[1]; > +}; ... > + query->extendedData = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(struct _wined3d_timestamp_query)); ... > +struct wined3d_timestamp_query > +{ > + struct list entry; > + struct wined3d_context *context; > + int n_ids; > + GLuint ids[]; > +}; That's ugly and fragile. Please try to write coherent patches. Patch 4/7 in particular looks like it was just copy-pasted together. Patch 5/7 could have easily been at least 4 separate patches.

May 3, 2011

Re: Support for D3DQUERY_TIMESTAMP* queries...

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 03.05.2011 um 16:51 schrieb Adam Martinson: > +#ifndef WINE_NO_TRACE_MSGS > + for (; i < query->n_ids; ++i) > + TRACE("Allocated timestamp query %u in context %p.\n", query->ids[i], context); > +#endif use if(TRACE_ON(d3d)) instead. It'll be statically FALSE if there are no trace messages, and you also avoid the loop at runtime when traces aren't on. > +struct _wined3d_timestamp_query > +{ > + struct list entry; > + struct wined3d_context *context; > + int n_ids; > + GLuint ids[1]; > +}; I'm not sure if this is necessary, I think we can just give struct wined3d_timestamp_query a ids[3] field. > +typedef struct D3D10_QUERY_DATA_TIMESTAMP_DISJOINT { > + UINT64 Frequency; > + BOOL Disjoint; > +} D3D10_QUERY_DATA_TIMESTAMP_DISJOINT; Wrong code style, it looks like you copypasted .idl code into a .c file. Please define this in wined3d.idl using WINED3D_QUERY_... names. The wined3d.idl file will soon be gone and replaced with a plain .h header. If you don't need those types for implementing the d3d9 queries ignore the d3d10 stuff for now. > + static BOOL warned = FALSE; > + if (!warned) > + { > + WARN("GL_ARB_timer_query not supported, returning WINED3DERR_NOTAVAILABLE\n"); > + warned = TRUE; > + } I don't think we have to limit WARNs to one output only. WARNs aren't shown by default. This kind of limiting is used for FIXMEs only to make sure repeated FIXMEs don't spam the terminal and hide other output. I have to go now, I'll be back later. If I have time and am not tired I'll read this a bit more and check the tests. But probably Henri has sent some comments by then too. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJNwDRoAAoJEN0/YqbEcdMwC+oQAJGAxuDNh2bGbBNGuFs5uxXo Jkf7+Kgb4aXuhYReGzCX5l1nYK82UBMGWC4j53tKWnziw4VueHuyuKwpmHO+EpRk cjgz5pi4WBT3EGTuvCbnQ9ayOKRI76OKa45mD0uFCMvsM/cHKh0QcUJD4SpkmHLM 97sZuNpBuWy6vqNTfSgTirpQCI/gBUlQZVHKBesVhsJJ7yVZG5TgZjARKasYzoVg Q6hHKK6qWby2NnawYpKQp51ie0OV3W65JZPHQ3fn+3ogrCcsL27u2SQE8MqHhKt4 PYxzGRfl+LCjdIIJ7UekXKawFlh6DqCF+j+9KEonJwSVzduj96Y+j0La5QML9eFW Kjk53LLgzrb8kQcSmMS6YLNot158am4twu9uE8Lf6KjO5ADXIdRqdISFCipqecu/ cJc0IyYEaKgcrFaRcCRuPtZreXaK8QjH0n7KzvEW9I+74UN0cegTIN37yIeAwev+ oPYTwGr6fUHtOUQ/8t/jYMvgm0Up8kLnK9OU9LWJPcTOVh+BtyeKI2vmg/QPvCCk lbPLuZD59JHdxyBDrKqYqyxIRcX6aLGctnRH5t+QVh5RHLmr8rcbZDm3JIEsDyHN dUE41KiDa/oad76pSW5OL2NU+QHLbVgnJ6IQjGQSdH7gF4zkLHX8VYTaWdFqYRMy U2KFQKkMYUCWBaGxaS4B =jvdN -----END PGP SIGNATURE-----

May 3, 2011

msvcrt: Add tests to show that utime() can take a NULL-pointer for the utimbuf structure field

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

Louis, >Anything i could do to improve to get it in? Perhaps http://source.winehq.org/patches/ shows that you should get rid of the one apply failure. Basically, your patch does the right thing, as MSDN says "If times is a NULL pointer, the modification time is set to the current local time." -- like POSIX. >-#if(0) /* FIXME: this test crashes wine, remove this line when wine is fixed */ People here prefer if(0) so that the compiler can still validate the form of the code. I've been even been using if (winetest_debug>1) so I can direct testbot to run the additional test. Finally, why not merge the two? After all, it's one change, and several tests. Why do you call it test_utime() since you don't verify the effects of utime()? Regards, Jörg Höhle

May 3, 2011

Re: [PATCH 2/4] wintrust: Added CryptSIPPutSignedDataMsg implementation (for PE files)

by Piotr Caban

On 05/03/11 13:07, Piotr Caban wrote: > --- > dlls/wintrust/crypt.c | 66 ++++++++++++++++++++++++++++++++++++++++++------ > 1 files changed, 57 insertions(+), 9 deletions(-) Patches 2 and 3 in this series are not correct. Please ignore them.

May 3, 2011

Re: FAQ translation possible?

by Juan Lang

> Wouldn't it make sense to move the FAQ to the wine website repository > so as to ease translation? FAQ is probably one of the most important > things to translate IMO. We've recently moved it the other way. > Or is it more important to remain it to the wiki for quick update/review? Yes, that's why it's in the wiki. Thanks, --Juan

May 3, 2011

FAQ translation possible?

by Frédéric Delanoy

Hi, I'm currently revising/translating WineHQ's website French translation. Translating the help, I remarked the FAQ is maintained in the wiki section. Wouldn't it make sense to move the FAQ to the wine website repository so as to ease translation? FAQ is probably one of the most important things to translate IMO. Is the wiki page somehow translatable (preferably using WineHQ's language cookie setting)? Or is it more important to remain it to the wiki for quick update/review? Frédéric Delanoy

May 3, 2011

Support for D3DQUERY_TIMESTAMP* queries...

by Adam Martinson

Feedback please.

May 3, 2011

Re: [2/2] msxml3/domdoc: Add support for VT_ARRAY|VT_UI1 in domdoc_load().

by Adam Martinson

On 05/03/2011 01:45 AM, Nikolay Sivov wrote: > On 5/3/2011 08:07, Adam Martinson wrote: >> >> Fixes bug 14864. >> --- >> dlls/msxml3/domdoc.c | 255 >> ++++++++++++++++++++++++++------------------------ >> 1 files changed, 134 insertions(+), 121 deletions(-) >> >> + case VT_ARRAY|VT_UI1: >> + { >> + SAFEARRAY* psa; >> + BSTR bstr; >> + psa = V_ARRAY(&source); >> + bstr = bstr_from_xmlChar(psa->pvData); >> + hr = domdoc_loadXML(iface, bstr, isSuccessful); >> + SysFreeString(bstr); >> + return hr; >> + } >> + break; > Is it really supposed to be utf8 array? Or this will work cause > one-byte chars match utf8? > > Also I don't like this method dependency, I think the proper way is to > call IXMLDOMDocument3_loadXML(iface...) here. > Or another way to avoid call through vtable - introduce something > called domdoc_load_xml(This...) and use it in both places, > but I think it's not worth it. It was the Google Chrome installer, I'm not sure if it's supposed to be UTF8 or not, all of the characters it used were ASCII. I'm assuming it's supposed to be UTF8 due to it being VT_UI8 instead of VT_I8, but I can't say for sure. I remember another place where it would have been useful to be able to call domdoc_loadXML() with a UTF8 string to avoid converting to BSTR and back, I think in the schema stuff. It would be nice to have an internal function to do that, then domdoc_loadXML() can just wrap it, but I think that can be a separate patch.

May 3, 2011

Re: [PATCH 3/4] d3dx9: Implement ID3DXBaseEffect::GetPixelShader().

by Henri Verbeet

2011/5/3 Rico Schüller <kgbricola(a)web.de>: > +#define SAFE_ADDREF(x) if(x) IUnknown_AddRef(x) > +#define SAFE_RELEASE(x) if(x) IUnknown_Release(x) That's not so safe, actually. Consider e.g. what happens when "x" has side effects, or when you write something like "if (cond) SAFE_ADDREF(x); else return;". If you really want this an inline function should do just as well, but for the handful of uses I see in this series it just obfuscates the code.

May 3, 2011

msvcrt: Add tests to show that utime() can take a NULL-pointer for the utimbuf structure field

by Louis Lenders

See http://www.winehq.org/pipermail/wine-patches/2011-April/101371.html Anything i could do to improve to get it in?

May 3, 2011

Re: ddraw (try 2): Add a few tests for Setcooperativelevel

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=10695 Your paranoid android. === WNT4WSSP6 (32 bit ddrawmodes) === ddrawmodes.c:800: Test failed: SetCooperativelevel(DDSCL_SETFOCUSWINDOW) returned: 80070057 ddrawmodes.c:803: Test failed: SetCooperativelevel(DDSCL_CREATEDEVICEWINDOW | DDSCL_EXCLUSIVE | DDSCL_FULLSCREEN) returned: 80070057 ddrawmodes.c:828: Test failed: SetCooperativelevel(DDSCL_SETFOCUSWINDOW) returned: 80070057 === W7PROX64 (64 bit ddrawmodes) === Timeout

May 3, 2011

Re: [2/2] msxml3/domdoc: Add support for VT_ARRAY|VT_UI1 in domdoc_load().

by Nikolay Sivov

On 5/3/2011 08:07, Adam Martinson wrote: > > Fixes bug 14864. > --- > dlls/msxml3/domdoc.c | 255 > ++++++++++++++++++++++++++------------------------ > 1 files changed, 134 insertions(+), 121 deletions(-) > > + case VT_ARRAY|VT_UI1: > + { > + SAFEARRAY* psa; > + BSTR bstr; > + psa = V_ARRAY(&source); > + bstr = bstr_from_xmlChar(psa->pvData); > + hr = domdoc_loadXML(iface, bstr, isSuccessful); > + SysFreeString(bstr); > + return hr; > + } > + break; Is it really supposed to be utf8 array? Or this will work cause one-byte chars match utf8? Also I don't like this method dependency, I think the proper way is to call IXMLDOMDocument3_loadXML(iface...) here. Or another way to avoid call through vtable - introduce something called domdoc_load_xml(This...) and use it in both places, but I think it's not worth it.

May 3, 2011

Re: [PATCH 1/2] d3d9/tests: Added a test for resetting an invisible, inactive window to fullscreen mode.

by Henri Verbeet

On 2 May 2011 13:24, Marvin <testbot(a)testbot.winehq.org> wrote: > === WXPPROSP3 (32 bit device) === > device: unhandled exception c0000005 at 0040320F > For what it's worth, not sure if you figured this out by yourself yet or not, but you need to handle create_device() failing to create a device on machines like the testbot that don't have D3D hardware.

May 2, 2011

Re: [PATCH 2/2] wined3d: Turn off message filtering temporarily in the Reset() method to allow certain messages (e.g. WM_ACTIVATEAPP) through.

by Henri Verbeet

On 2 May 2011 23:28, John Edmonds <pocketcookies2(a)gmail.com> wrote: > Are you suggesting that we turn off message filtering altogether or just for > the Reset function? > Just Reset().

May 2, 2011

Re: [PATCH 2/2] wined3d: Turn off message filtering temporarily in the Reset() method to allow certain messages (e.g. WM_ACTIVATEAPP) through.

by John Edmonds

Are you suggesting that we turn off message filtering altogether or just for the Reset function? I would like to add that I did disable all message filtering (by commenting out the code in Wine's wndproc) and the games I was testing worked fine. However, I did not investigate the effects of that change very thoroughly. On May 2, 2011 7:52 AM, "Henri Verbeet" <hverbeet(a)gmail.com> wrote: > On 2 May 2011 13:18, John Edmonds <pocketcookies2(a)gmail.com> wrote: >> Toki Tori and RUSH both depend on receing WM_ACTIVATEAPP before they will start. These messages are currently getting filtered out. >> This resolves bug #25640. > > It doesn't look right to me to filter messages during > IWineD3DDevice_ReleaseFocusWindow() but not > IWineD3DDevice_AcquireFocusWindow(). Maybe it just shouldn't filter at > all. > >

May 2, 2011

Working on UpdateSemantics or D3DXWeldVertices in D3DX9?

by Michael Mc Donnell

Hi Guys! I'm doing Google Summer of Code 2011 and found out that some of the functions I was to implement have been implemented while my application was being processed. This means I have to find some other functions in D3DX9 to implement. I see that UpdateSemantics and D3DXWeldVertices are unimplemented in D3DX9, and was wondering if anyone is working on these? Cheers, Michael

May 2, 2011

Re: comctl32: avoid using ZeroMemory()

by Austin English

On Mon, May 2, 2011 at 10:58, Marcus Meissner <meissner(a)suse.de> wrote: > On Mon, May 02, 2011 at 10:52:50AM -0500, Austin English wrote: >> Avoids a Clang bug: >> http://bugs.winehq.org/show_bug.cgi?id=26754 > > clang cannot even survive a simple memset() to 0? http://llvm.org/bugs/show_bug.cgi?id=9830 -- -Austin

May 2, 2011

Re: comctl32: avoid using ZeroMemory()

by Marcus Meissner

On Mon, May 02, 2011 at 10:52:50AM -0500, Austin English wrote: > Avoids a Clang bug: > http://bugs.winehq.org/show_bug.cgi?id=26754 clang cannot even survive a simple memset() to 0? Ciao, Marcus

May 2, 2011