July 2006 - Wine-Devel - list.winehq.org

re: Slow EULA display patch

by Dan Kegel

Krzysztof wrote: >Well, *great* to see that solved in the Wine core, but I still think I >have a bug in RichEdit, because the original (native) riched20 works >fast, despite the bug you just fixed. Is there a good test document for which our riched20 is (with Dan H's patch) still way too slow? If so, let's dig into this. FWIW, Dan H also explored a change to make a riched "run" struct be refcounted; that gave a 4x speedup. Then he switched to using git bisect to find the cause of the regression, and shelved the refcounting patch. - Dan

July 2, 2006

re: Link or rename wcmd.exe to cmd.exe?

by Dan Kegel

chris kcat wrote: >Not sure if this is the best place to bring this up, but I'm not sure >it's "ready". The problem is it runs through the terminal the Wine was exec'd >from. When Wine is run from the desktop manager's menu, or started in the >background (eg. wine foo.exe &), if wcmd is subsequently exec'd, it will >become completely unuseable since it has no input, and potentially no output, >terminal. It then has to be killed through the kill or killall command. Have you ever seen this be a problem in the real world? >To be "ready", wouldn't it need to open up its own terminal window for input >and output in Wine's desktop space (eg. the virtual desktop if it's in use, >or the standard desktop)? No. That would destroy its usefulness in background applications. - Dan

July 2, 2006

Re: [AppDB] Problem with xinha, compile_update_string() and query_parameters()

by Chris Morgan

> > So, the fix is quite simple, stop using compile_insert_string() and > > compile_update_string() and let query_parameters() do the work. This > > way we can be sure that we won't be inserting strings with special > > formatting characters into the format portion of the > > query_parameters() call. > > > > I'll take care of fixing this as soon as I get back home. > > > > Chris > > I was not really comfortable with that solution. compile_update_string was very > nice for aligning the field with the value so it looked very clean. The trouble > with doing it this way is that it is more prone to errors but if you say that is > OK with you then I suppose it will do for me too. > > I agree about the formatting. It was easier to line things up with the other external call to compile_*_string(). It may seem more prone to errors but this is how pear db, adodb, .net and others recommend performing queries. query_parameters() will ensure that the correct number of tokens is present for the number of variables provided so if there is a mismatch the query won't be executed. I think the formatting you chose looks good and is just as good as what we had before. Chris

July 2, 2006

A big online GUID-List

by Detlef Riekenberg

Found a big online GUID-List: http://www.myplugins.info/guids/guidlist.php -- By By ... ... Detlef

July 2, 2006

Re: [AppDB] Problem with xinha, compile_update_string() and query_parameters()

by Tony Lambregts

Chris Morgan wrote: > Is this the case when inserting data from a xinha editor into the > database? Is this being seen only in application related data? > > Sorry for the time you've spent investigating this, it only took a > moment for me to realize what the problem was after knowing the > symptoms. I should have caught this earlier. > > I'm pretty sure this is an easy fix of simply not using > compile_update_string() or compile_insert_string(). If you look at > the use of these functions you'll see something like: > > $sBlah = compile_insert(update)_string(...); > > query_parameters("update/insert ".$sBlah." where '?' ...", a, b, c); > > The problem is that $sBlah contains characters that are special to > query_parameters() like '~', '?', '&'. Because we incorrectly put > $sBlah into the format portion of query_parameters(), we insert these > special characters into the format parameter of query_parameters(). > > So, the fix is quite simple, stop using compile_insert_string() and > compile_update_string() and let query_parameters() do the work. This > way we can be sure that we won't be inserting strings with special > formatting characters into the format portion of the > query_parameters() call. > > I'll take care of fixing this as soon as I get back home. > > Chris I was not really comfortable with that solution. compile_update_string was very nice for aligning the field with the value so it looked very clean. The trouble with doing it this way is that it is more prone to errors but if you say that is OK with you then I suppose it will do for me too. Change Log: Fix crash in updateing xinha fields. Files changed: include/testResults.php

July 2, 2006

Re: [AppDB] Problem with xinha, compile_update_string() and query_parameters()

by Chris Morgan

Is this the case when inserting data from a xinha editor into the database? Is this being seen only in application related data? Sorry for the time you've spent investigating this, it only took a moment for me to realize what the problem was after knowing the symptoms. I should have caught this earlier. I'm pretty sure this is an easy fix of simply not using compile_update_string() or compile_insert_string(). If you look at the use of these functions you'll see something like: $sBlah = compile_insert(update)_string(...); query_parameters("update/insert ".$sBlah." where '?' ...", a, b, c); The problem is that $sBlah contains characters that are special to query_parameters() like '~', '?', '&'. Because we incorrectly put $sBlah into the format portion of query_parameters(), we insert these special characters into the format parameter of query_parameters(). So, the fix is quite simple, stop using compile_insert_string() and compile_update_string() and let query_parameters() do the work. This way we can be sure that we won't be inserting strings with special formatting characters into the format portion of the query_parameters() call. I'll take care of fixing this as soon as I get back home. Chris On 7/2/06, Tony Lambregts <tony.lambregts(a)gmail.com> wrote: > We have a problem with xinha, compile_update_string() and query_parameters(). > Xinha changes double quotes, ampersands, the less than symbol, the greater than > symbol and probably others into their HTML Ampersand Character Codes[1]. This > conflicts with what mysql_real_escape_string() does and causes > query_parameters() to refuse to update the database when there is an one of > these characters in a Xinha field. > > I have investigated this for quite a while now and am unsatisfied with any quick > solution that have looked at. > > [1] > http://rabbit.eng.miami.edu/info/htmlchars.html > > -- > > Tony Lambregts >

July 2, 2006

[AppDB] Problem with xinha, compile_update_string() and query_parameters()

by Tony Lambregts

We have a problem with xinha, compile_update_string() and query_parameters(). Xinha changes double quotes, ampersands, the less than symbol, the greater than symbol and probably others into their HTML Ampersand Character Codes[1]. This conflicts with what mysql_real_escape_string() does and causes query_parameters() to refuse to update the database when there is an one of these characters in a Xinha field. I have investigated this for quite a while now and am unsatisfied with any quick solution that have looked at. [1] http://rabbit.eng.miami.edu/info/htmlchars.html -- Tony Lambregts

July 2, 2006

wine's fullscreen code has no effect on metacity

by Vincent Povirk

Some patches were committed to wine recently to make it use _NET_WM_STATE_FULLSCREEN for fullscreen apps. These patches appear to work in kwin but not metacity (I was using firefox as a test). In metacity, it appears wine recognizes that it needs to make a window fullscreen and send the appropriate message, but nothing happens (panels are still on top of firefox in fullscreen mode). I've mentioned this on wine's bug (http://bugs.winehq.org/show_bug.cgi?id=3312) but I suspect it's probably caused by some quirk in metacity that wine triggers by doing some rather odd things itself. That's why I've CC'd the metacity-devel list (to which I and probably anyone on any wine mailing lists are not subscribed). So, uh, metacity people, under what circumstances would metacity be likely to put a window that had sent the proper _NET_WM_STATE_ADD message for _NET_WM_STATE_FULLSCREEN behind panels? -- Vincent Povirk

July 2, 2006

Re: [Tools/Wine.inf] Set Internet Explorer version

by Olaf Leidinger

> He was asking if we should *require* people to install IE, and I said > no, we shouldn't. If someone wants to install IE, go ahead, but apps > that depend on the presence of IE should work with builtin IE. Oh, sorry - I mis-read that part. You're right - wine should not rely on windows base components at all. Ciao, Olaf

July 2, 2006

re: Any chances to get some feedback on latests mswsock patch?

by Dan Kegel

In addition to Juan's comments: it would be nice if, when you post new patches that obsolete old ones, if you stated that clearly. Otherwise we have to think a bit to decide if they apply on top of your old ones.

July 2, 2006