Re: Link or rename wcmd.exe to cmd.exe?
On Sunday 02 July 2006 16:31, you wrote: > Have you ever seen this be a problem in the real world? Yes. Start Progman, or some ther "shell" application, without an xterm (eg. through your WM or by running wine progman.exe &), then attempt to execute wcmd.exe (a standard operation I'd think, if you want to have a Windows shell running and subsequently want to get a Windows command line). You lose the ability to control wcmd, and can't kill it without manually running kill or killall on the process. > >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. Wouldn't not doing it destroy its usefulness? If wcmd is supposed to act like Windows' cmd, then it should act like Windows' cmd, eg. opening its own console window in Wine's desktop space and running there. If it doesn't, it would lead to compatibility issues for programs that try to use a cmd.exe window itself since the behavior is different.
Re: Slow EULA display patch
On Sun, Jul 02, 2006 at 04:35:11PM -0700, Dan Kegel wrote: > 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. That wasn't the real reason I scratched the refcount idea. To make it work correctly, I had to add copy-on-write and once I did this the performance dropped again. However, the problem I was trying to solve was that ME_SplitRunSimple calls ME_VSplitString, which makes a copy of a large suffix of its string argument. The process then occurs again iteratively on the suffix, so a lot of copys are being made. Instead of this, if we only copied the part of the suffix we need, and then use the same base string in every iteration, we could eliminate another n-squared algorithm. The 4x speedup might have been, in part, a side effect of something that got broken by the incorrectly reference counted strings. Sorry I didn't mention this before.
re: Slow EULA display patch
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
re: Link or rename wcmd.exe to cmd.exe?
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
Re: [AppDB] Problem with xinha, compile_update_string() and 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. 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
A big online GUID-List
Found a big online GUID-List: http://www.myplugins.info/guids/guidlist.php -- By By ... ... Detlef
Re: [AppDB] Problem with xinha, compile_update_string() and query_parameters()
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
Index: include/testResults.php
===
RCS file: /home/wine/appdb/include/testResults.php,v
retrieving revision 1.26
diff -u -u -r1.26 testResults.php
--- include/testResults.php 30 Jun 2006 16:38:05 - 1.26
+++ include/testResults.php 2 Jul 2006 21:04:37 -
@@ -106,20 +106,30 @@
return;
}
-$sUpdate = compile_update_string(array( 'versionId' => $this->iVersionId,
-'whatWorks' => $this->sWhatWorks,
-'whatDoesnt'=> $this->sWhatDoesnt,
-'whatNotTested' => $this->sWhatNotTested,
-'testedDate'=> $this->sTestedDate,
-'distributionId'=> $this->iDistributionId,
-'testedRelease' => $this->sTestedRelease,
-'installs' => $this->sInstalls,
-'runs' => $this->sRuns,
-'testedRating' => $this->sTestedRating,
-'comments' => $this->sComments));
-
-if(query_parameters("UPDATE testResults SET ".$sUpdate." WHERE testingId = '?'",
-$this->iTestingId))
+if(query_parameters("UPDATE testResults SET versionId = '?', ".
+ "whatWorks = '?', ".
+ "whatDoesnt = '?', ".
+ "whatNotTested = '?', ".
+ "testedDate = '?', ".
+ "distributionId = '?', ".
+ "testedRelease = '?', ".
+ "installs = '?', ".
+ "runs = '?', ".
+ "testedRating = '?', ".
+ "comments = '?' ".
+"WHERE testingId = '?'",
+ $this->iVersionId,
+ $this->sWhatWorks,
+ $this->sWhatDoesnt,
+ $this->sWhatNotTested,
+ $this->sTestedDate,
+ $this->iDistributionId,
+ $this->sTestedRelease,
+ $this->sInstalls,
+ $this->sRuns,
+ $this->sTestedRating,
+ $this->sComments,
+ $this->iTestingId))
{
if(!$bSilent)
$this->SendNotificati
Re: [AppDB] Problem with xinha, compile_update_string() and query_parameters()
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 <[EMAIL PROTECTED]> 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
[AppDB] Problem with xinha, compile_update_string() and query_parameters()
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
wine's fullscreen code has no effect on metacity
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
Re: [Tools/Wine.inf] Set Internet Explorer version
> 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 pgpK11C4SWE1a.pgp Description: PGP signature
