snip<
It works very well, too. Sometimes it loses keyboard and/or mouse
focus, but Alt+Tabbing away and back fixes that.
So, what's up? Does the debug flag cause some sort of registry
clean-up, perhaps?
(CXG Linux 9.1.0, Ubuntu 10.4 x64, nVidia GeForce 9500 GT, official
drivers)
Hi again.
The Alt-Tabbing away from main wine window and back into it to regain keyboard/mouse
input is a known bug - I think some of the recent Steam updates may have something to
do with that...at any rate, there is a ticket hoisted on that issue, just FYI...
Regarding what debug flags can sometimes do....tricky, huh? 8) When I was debugging
something with Team Fortress 2, the very same thing caught me by surprise..ie; the
moment you ran the thing with debug flags enabled, it stopped misbehaving...and wouldn't
misbehave again when you subsequently ran it -without- debug flags ; ostensibly it
appears as though running debug has fixed the issue...this is possible, however it's
not doing so deliberately nor instigating any registry clean-up...it's incidental.
'For whatever reason' your win32 app wants to do something specific at a particular
point in time -- this could be anything, access ram, access diskdrive, open display
or initialize sound...whatever..but the important thing is the app is expecting that
to happen 'now' or in a timely fashion. Sometimes, this can't happen because of some
timing issue with/within wine's operations or that of the host system itself (like
some linux kernel quirk), which may 'block' what the win32 app is trying to do, and it
headbutts oblivion and crashes. When you turn on debugging flags, the timing of the
execution environment alters dramatically...ie; for example, imagine how much the
extra disk I/O generated to write the logfile impacts upon whether or not the win32
app wants to write to the disk at the same time....
Sometimes, you get lucky....the combination of debug flags along with your system's
performance parameters so coincides with the win32 process' execution requirements,
that it can do whatever it wants to do 'now' -- sometimes, the operation the win32
app is trying to complete is mission critical...TF2 was a good example. In that case
I believe it was trying to read-in audio files, process them, and write a master cache
file for all the required audio data ; until it could complete this operation cleanly
and actually finish writing the cache file, the game would not run - it would try and
do it again 8) Doing the debug run actually let that process complete ; it only needs
to be done once and the app is happy, hence removing the debug flags and discovering
the game now worked without them, is indicative that something like this has occurred.
...you can get all funky with it too...ie; piping your debug output to local drive
is quite different to piping your debug output to an NFS mount (reduce your disk I/O
but get NIC I/O), pipe to /dev/null or even pipe to ramdisk...all these things effect
the host machine's timing/handling of task cues. The more debug channels you specify,
the more you gobble up timeslice available to other things...don't do this, but the
debug channel +all is a very good way to eat a banquet in a single bite - that chokes
most systems to a standstill. It's also important to recognize here, that applying
debug flags to the wine process, because it -does- effect execution timing, can 'hide'
or somehow cause debug run results to be inconclusive, because either too many debug
flags were used at once and/or the debug flags required to catch the ferret need to
be run in conjunction with other specific debug channels...permutations exude...and
in the end it's typically one of the codeweavers/wine devs who knows exactly what they
want to look at in the way of debug channels...
...actually, there are some apps over in the WineHQ AppDB wherein the -only- way to
run the app itself, is with debug running at the same time - a rather creative use
of debug channels to get an app running all the time 8)...
...one of the Ninjas told me about this long ago ... I've more or less here expounded
upon that wisdom....the consequence of it all however, is that it makes bugs like this
rather difficult to expose. Sometimes, you have to go with your hunches a pick on the
exact debug channel where you think the problem may be mooted -- you get to drink lots
of coffee during a multiple reinstall and test fest, thrilling stuff to be sure 8)
Cheers!
