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

Re: [08/11] windowscodecs: Add tests for more types of IFD fields.

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=18986 Your paranoid android. === W7PRO (32 bit metadata) === metadata.c:494: Test failed: 20: expected count 3, got 4 metadata.c:495: Test failed: 20: expected abc, got abcd === W7PROX64 (32 bit metadata) === metadata.c:494: Test failed: 20: expected count 3, got 4 metadata.c:495: Test failed: 20: expected abc, got abcd === TEST64_W7SP1 (32 bit metadata) === metadata.c:494: Test failed: 20: expected count 3, got 4 metadata.c:495: Test failed: 20: expected abc, got abcd === W7PROX64 (64 bit metadata) === metadata.c:494: Test failed: 20: expected count 3, got 4 metadata.c:495: Test failed: 20: expected abc, got abcd === TEST64_W7SP1 (64 bit metadata) === metadata.c:494: Test failed: 20: expected count 3, got 4 metadata.c:495: Test failed: 20: expected abc, got abcd

June 13, 2012

Misspelt Portuguese in msvcrt

by Francois Gouget

Is there a reason why Portuguese is misspelt in these two places? diff --git a/dlls/msvcrt/locale.c b/dlls/msvcrt/locale.c index 97b82ec..b26a9c8 100644 --- a/dlls/msvcrt/locale.c +++ b/dlls/msvcrt/locale.c @@ -85,7 +85,7 @@ static const char * const _country_synonyms[] = "german-swiss", "des", "italian-swiss", "its", "german-austrian", "dea", - "portugese", "ptb", + "portuguese", "ptb", "portuguese-brazil", "ptb", "spanish-mexican", "esm", "norwegian-bokmal", "nor", diff --git a/dlls/msvcrt/tests/locale.c b/dlls/msvcrt/tests/locale.c index 8d6a34f..638a3d2 100644 --- a/dlls/msvcrt/tests/locale.c +++ b/dlls/msvcrt/tests/locale.c @@ -472,7 +472,7 @@ static void test_setlocale(void) if(ret) ok(!strcmp(ret, "Polish_Poland.1250"), "ret = %s\n", ret); - ret = setlocale(LC_ALL, "portugese"); + ret = setlocale(LC_ALL, "portuguese"); ok(ret != NULL || broken (ret == NULL), "ret == NULL\n"); if(ret) ok(!strcmp(ret, "Portuguese_Brazil.1252"), "ret = %s\n", ret); -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ E-Voting: Those who cast the votes decide nothing. Those who count the votes decide everything.

June 13, 2012

Re: po: Update Russian translation (try 3) (resend)

by Francois Gouget

msgid "KeyID=" -msgstr "Код ключа=" +msgstr "Код ключа: " [...] msgid "Other Name=" -msgstr "Другое имя=" +msgstr "Альтернативное имя: " and many more like this. Why did you not fix this? Replacing the equal sign with a colon looks wrong to me but then I don't speak Russian. Still I have not seen anything to suggest that the typographic rules would be different in this regard. But Nikolay Sivov, who speaks Russian, seems to concur. Note that this was reported to you back in May: http://www.winehq.org/pipermail/wine-devel/2012-May/095672.html -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Good judgment comes from experience, and experience comes from bad judgment -- Barry LePatner

June 13, 2012

Re : d3dx9_36: D3DXQuaternionLn computes as if the norm of the input is 1

by Nozomi Kodama

>>2012/6/12 Nozomi Kodama <nozomi.kodama(a)yahoo.com>: >> >> + if ( (pq->w >= 1.0f) || (pq->w == -1.0f) ) > >I think the second comparison should be '<=', if you want to avoid getting NaNs. I checked in Vista. D3DX accepts -1.0f as input and returns what the patch does. However, any value < -1.0f is a unacceptable value for D3DX ( D3DX returns (-1#IND00,-1#IND00,-1#IND00,-1#IND00) ). Best regards Nozomi

June 13, 2012

Re: d3dx9_36: D3DXQuaternionLn computes as if the norm of the input is 1

by Matteo Bruni

2012/6/12 Nozomi Kodama <nozomi.kodama(a)yahoo.com>: > > + if ( (pq->w >= 1.0f) || (pq->w == -1.0f) ) I think the second comparison should be '<=', if you want to avoid getting NaNs.

June 12, 2012

Re: [PATCH 4/5] wined3d: Set undefined vertex attributes to 0.0.

by Stefan Dösinger

Am Dienstag, 12. Juni 2012, 17:03:49 schrieb Henri Verbeet: > + if (state->vertex_shader->reg_maps.input_registers & (1 << i)) > + GL_EXTCALL(glVertexAttrib4fARB(i, 0.0f, 0.0f, 0.0f, 0.0f)); Does an application need this? Afair Windows drivers have implementation- specific behavior here that pretty much matches their GL counterparts.

June 12, 2012

Re: Command line parameters

by Ben Peddell

On 12/06/2012 8:59 PM, John Emmas wrote: > Thanks Hin-Tak and Dan but I think we're at crossed purposes now. > Remember that my original question had nothing to do with paths. I > simply used paths as a convenient example. My question is about > command-line parameters and (more specifically) about UTF-8 string > conversion. Here's an example.... Consider a Windows user whose > name is Göran. The UTF-8 byte sequence for this is:- > > 47 C3 B6 72 61 6E -- (6 bytes) > > whereas Windows would expect something like this (depending on the > user's locale):- > > 47 F6 72 61 6E -- (5 bytes) > > Let's suppose that a Linux app launches a Windows child process > (via Wine). The (Linux) host app needs to pass the string "Göran" > as one of the command-line parameters. Linux uses UTF-8 and will > therefore pass the first sequence of bytes to Wine (6 bytes). But > Windows doesn't understand UTF-8. A Windows app would expect the > second byte sequence (5 bytes - or 10 bytes for a Unicode app). By "Linux uses UTF-8" you're saying that you have a UTF-8 locale active. > > Does Wine carry out the necessary conversion or does it simply > pass the original byte string unmodified? That's what I'm trying > to find out. Thanks. Wine first converts the command-line to Unicode according to the active host locale. Then any character set conversion from Unicode to ANSI or vice versa within the application is done according to the active Windows locale. If the Wine process needs to execute a native process, Wine converts the command line from Unicode using the active host locale. The default character set under Linux is ISO-8859-1, while the default character set under Windows is Windows-1252, which has all of the printable characters in the same places as in ISO-8859-1, with some extra printable characters in the C1 (0x80..0x9F) area. If no host locale is specified (i.e. the locale is POSIX), and the default Windows locale is used, then the only available characters an ANSI Windows program will be unable to be passed are the extra characters in the C1 area. All unrepresentable characters are replaced with question marks [?]. -- Ben Peddell IT Support Bowen, Collinsville and Proserpine Catholic schools http://klightspeed.killerwolves.net/

June 12, 2012

Re: Command line parameters

by Ben Peddell

On 12/06/2012 8:59 PM, John Emmas wrote: > Thanks Hin-Tak and Dan but I think we're at crossed purposes now. > Remember that my original question had nothing to do with paths. I > simply used paths as a convenient example. My question is about > command-line parameters and (more specifically) about UTF-8 string > conversion. Here's an example.... Consider a Windows user whose > name is Göran. The UTF-8 byte sequence for this is:- > > 47 C3 B6 72 61 6E -- (6 bytes) > > whereas Windows would expect something like this (depending on the > user's locale):- > > 47 F6 72 61 6E -- (5 bytes) > > Let's suppose that a Linux app launches a Windows child process > (via Wine). The (Linux) host app needs to pass the string "Göran" > as one of the command-line parameters. Linux uses UTF-8 and will > therefore pass the first sequence of bytes to Wine (6 bytes). But > Windows doesn't understand UTF-8. A Windows app would expect the > second byte sequence (5 bytes - or 10 bytes for a Unicode app). By "Linux uses UTF-8" you're saying that you have a UTF-8 locale active. > > Does Wine carry out the necessary conversion or does it simply > pass the original byte string unmodified? That's what I'm trying > to find out. Thanks. Wine first converts the command-line to Unicode according to the active host locale. Then any character set conversion from Unicode to ANSI or vice versa within the application is done according to the active Windows locale. If the Wine process needs to execute a native process, Wine converts the command line from Unicode using the active host locale. The default character set under Linux is ISO-8859-1, while the default character set under Windows is Windows-1252, which has all of the printable characters in the same places as in ISO-8859-1, with some extra printable characters in the C1 (0x80..0x9F) area. If no host locale is specified (i.e. the locale is POSIX), and the default Windows locale is used, then the only available characters an ANSI Windows program will be unable to be passed are the extra characters in the C1 area. All unrepresentable characters are replaced with question marks [?]. -- Ben Peddell IT Support Bowen, Collinsville and Proserpine Catholic schools http://klightspeed.killerwolves.net/

June 12, 2012

Re: Command line parameters

by Hin-Tak Leung

--- On Tue, 12/6/12, John Emmas <johne53(a)tiscali.co.uk> wrote: <snipped> > Thanks Hin-Tak and Dan but I think we're at crossed purposes > now. Remember that my original question had nothing to > do with paths. I simply used paths as a convenient > example. My question is about command-line parameters > and (more specifically) about UTF-8 string conversion. > Here's an example.... Consider a Windows user whose > name is Göran. The UTF-8 byte sequence for this is:- > > 47 C3 B6 72 61 6E -- (6 > bytes) > > whereas Windows would expect something like this (depending > on the user's locale):- > > 47 F6 72 61 6E -- (5 > bytes) > > Let's suppose that a Linux app launches a Windows child > process (via Wine). The (Linux) host app needs to pass > the string "Göran" as one of the command-line > parameters. Linux uses UTF-8 and will > therefore pass the first sequence of bytes to Wine (6 > bytes). But Windows doesn't understand UTF-8. A > Windows app would expect the second byte sequence (5 bytes - > or 10 bytes for a Unicode app). > > Does Wine carry out the necessary conversion or does it > simply pass the original byte string unmodified? > That's what I'm trying to find out. Thanks. I have already answered that question - it depends on your application, how it uses win32 API. win32 api's is divided into the older *A routines which expects ascii, and the newer *W routines, which expects WCHAR (UTF16LE).

June 12, 2012

Re: [2/2] msxml3: Support xmlns[:*] attribute nodes intelligently.

by Ulrik Dickow

Den 12-06-2012 13:21, Nikolay Sivov skrev: > On 6/12/2012 11:55, Ulrik Dickow wrote: >> Patch 2 of 2 from http://bugs.winehq.org/show_bug.cgi?id=26226 . >> >> >> > >> + /* Emit appropriate fixme or warning in case of unsupported or invalid namespace. >> + * The W3C spec would like us to exit earlier for attempts to redefine the namespace for >> + * the reserved "xmlns" attribute or prefix (http://www.w3.org/TR/xml-names/#ns-decl) >> + * like http://gdome2.cs.unibo.it/gtk-doc/gdome2-gdomeelement.html#GDOME-EL-SETATTR…, >> + * but since native msxml3 accepts anything here, it's safest to just continue with warning. >> + */ > The question is more like what libxml2 thinks about that. If it follows > w3c here which is likely the question will be - won't it break somewhere > internally in libxml2 code if we hack it that way? I don't think so. We have already seen that libxml2 doesn't consider the attribute "xmlns" to have any special meaning in relation to namespaces, when setting an attribute. It hasn't given any problems in my tests. But maybe you are right that it is safer to return E_INVALIDARG, as I did in an earlier version, to guard against future increased intelligence in libxml2. Both of the applications in bug 26226 use the correct W3C namespace, so they don't care. I'll change it back. >> + if(namespaceURI && namespaceURI[0] && node_type != NODE_ELEMENT) >> + { >> + if(node_type == NODE_ATTRIBUTE) >> + switch((!strcmpW(name, xmlnsW) || >> + !strncmpW(name, xmlnscW, sizeof(xmlnscW)/sizeof(WCHAR))) + >> + !strcmpW(namespaceURI, w3xmlns)) > Could you please simplify that, it's a bit hard to read. I guess you mean I simplified it too much. But yes, it can be hard to read/understand. I'll offer an expanded version using logical variables and maybe several if-then-else instead of this overly simple switch. BTW, as a funny side-note, at first I had added a "default:" clause with a FIXME (or similar) stating that this should be impossible. 'gcc -O2' was intelligent enough to know that for logical variables a and b in C, a + b can only be 0 (both are false), 1 (exactly one is true) or 2 (both are true), so it completely optimized away the FIXME-string/statement from the binary. >> + * Note: We would be more in line with the native msxml if we only detected a >> + * redundancy/conflict for prefixes existing on the element itself (in element->ns >> + * or in the linked list element->nsDef). But as long as our *_get_xml() doesn't >> + * eliminate redundant namespace definitions in children, this behaviour may be >> + * an advantage in some cases. As disadvantage is that we incorrectly regard the >> + * redefinition in element 'b' in '<a xmlns="x"><b xmlns="y"/></a>' as a conflict. >> + * Libxml2 currently doesn't have a function or option to only search for namespaces >> + * on the current node; but it would be easy to make a reduced version of xmlSearchNs >> + * (currently defined in http://git.gnome.org/browse/libxml2/tree/tree.c#n5871) >> + * However, most apps probably set the ns to y on node b creation, so no conflict here. >> + * > I don't think it's better to potentially break one thing while fixing > the other. In current wine, attributes named "xmlns" don't work at all in setAttributeNode (an error code is returned instead of S_OK, and no attribute is added, no matter whether a namespace is already present or not at this level). So fixing this issue doesn't break anything that worked before. I consider it a step-wise improvement. Something better, nothing worse. I wanted to keep that patch as small and simple as possible. setAttribute also has this "dumb" use of xmlSearchNs. > And I guess I like a thought on making xmlSearchNs version > that will do what we want from it. Ok, actually it'll only be about 10 lines of extra code, roughly, so I'll add that -- and shrink the comment, less worries, more code :). > Just to clarify - is that right that libxml2 problem here is a lack of some checks > that lead to duplication and conflicts later? (that are visible in doc > dumps too) Well, yes, in a way: it doesn't check whether we try to set attributes named "xmlns" or use prefix "xmlns" or use the namespaceURI "http://www.w3.org/2000/xmlns/". But maybe it shouldn't. It's a matter of policy -- giving higher layers the freedom to enforce restrictions themselves. It turns out that the native msxml3 doesn't enforce restrictions. As the doc dumps show, it too can give 1) duplication when setAttribute is used (but not when setAttributeNode is used) 2) conflicts between the namespaces in visible XML (get_xml) versus what get_namespaceURI tells us, both for setAttribute and setAttributeNode The most problematic lack in libxml2 is not about treating (input) attributes specially, but rather the whole concept of treating the ns fields as "directives to print an xmlns attribute". It doesn't map well with the native msxml concept of treating namespaces as just information that this element _belongs_ to this namespace. Whether or not an xmlns attribute should be printed (returned from get_xml), depends on what part of the tree the user wants to look at. If the user asks for XML for a parent, a child in the same namespace doesn't have the xmlns attribute repeated at its level (due to ns fields). It would be nice to have XML-generation functions in libxml2 that suppressed child xmlns output similarly. Fortunately most applications probably don't care about this extra XML (BridgeCentral doesn't). >> +/* Convenient helper function for creating an attribute node in a given namespace. >> + * Note: CHECK_HR() should not be here, but in caller, to give optimal line number info. >> + */ > You mean EXPECT_HR here I guess. Yup, sorry. >> +static HRESULT create_attribute_ns( >> + IXMLDOMDocument *doc, >> + const char *attr_name, >> + const char *nsURI, >> + IXMLDOMAttribute **attr_ptr) >> +{ >> + HRESULT hr; >> + VARIANT var; >> + IXMLDOMNode *node; >> + >> + V_VT(&var) = VT_I1; >> + V_I1(&var) = NODE_ATTRIBUTE; >> + >> + hr = IXMLDOMDocument_createNode(doc, var, _bstr_(attr_name), _bstr_(nsURI), &node); >> + if (hr == S_OK) >> + { >> + IXMLDOMNode_QueryInterface(node, &IID_IXMLDOMAttribute, (void**) attr_ptr); >> + IXMLDOMNode_Release(node); >> + } >> + return hr; >> +} > Please null out pointer in case of failure, or better always before > createNode(). Ok.

June 12, 2012