OK, finally tried the new winedbg, and I'm afraid I'm mystified.
I wanted to debug my pipe regression test. I tried winedbg pipe.exe This starts out ok, printing stuff to stdout like I expect, but then it does something very odd: it switches to reverse video right before it prints "In 32-bit mode." The "Wine-dbg>" prompt comes up, but it doesn't respond to the keyboard. Also, the display is stair-stepped, as if the newline char isn't being interpreted as CR-LF. Sounds like stdin is being put in raw mode. I have to do 'killall wine' from another window. It's just totally, mysteriously broken... Before, I could actually use it, but now I'm just confused.
On the theory that for some unfathomable reason, the correct command is now wineconsole winedbg pipe.exe I tried that. That behaved somewhat better in that it responded to keystrokes, but it scrolls at line 25 no matter what size the window is, and trying to do 'cont' or 'run' fails with messages like No process loaded, cannot execute 'cont' And it's in that horrible reverse video.
Why can't winedbg just behave like gdb with respect to stdin and stdout? I'm at a loss. - Dan
Dan Kegel wrote:
OK, finally tried the new winedbg, and I'm afraid I'm mystified.
I wanted to debug my pipe regression test. I tried winedbg pipe.exe This starts out ok, printing stuff to stdout like I expect, but then it does something very odd: it switches to reverse video right before it prints "In 32-bit mode." The "Wine-dbg>" prompt comes up, but it doesn't respond to the keyboard. Also, the display is stair-stepped, as if the newline char isn't being interpreted as CR-LF. Sounds like stdin is being put in raw mode. I have to do 'killall wine' from another window. It's just totally, mysteriously broken... Before, I could actually use it, but now I'm just confused.
does it behave the same way with other app than pipe.exe or winedbg ? winedbg (in its current implementation) doesn't really control the terminal as gdb does. And I don't intent to make it behave this way, it's supposed to be the job of wineconsole.
On the theory that for some unfathomable reason, the correct command is now wineconsole winedbg pipe.exe I tried that. That behaved somewhat better in that it responded to keystrokes,
good :-)
but it scrolls at line 25 no matter what size the window is,
wineconsole doesn't support dynamic resize yet... it will use the default size for you app in the registry (if you want to change this, run once winedbg under the user console, set the desired size of the console for winedbg (screen buffer size and window size) and save the settings for all the sessions)
and trying to do 'cont' or 'run' fails with messages like No process loaded, cannot execute 'cont'
there's a bug in wineconsole, the patch has just been sent to wine-patches
And it's in that horrible reverse video.
mmm would your curses use a different attribute mapping ?
Why can't winedbg just behave like gdb with respect to stdin and stdout? I'm at a loss.
because winedbg isn't gdb... as I wrote above, IMO it isn't the job of winedbg (as an app) to control the terminal, it's up to wineconsole. so if you don't run your pgm under wineconsole, it won't work.
use winedbg -- --gdb if you really don't want wineconsole but do want proper terminal control
A+
Eric Pouech wrote:
I wanted to debug my pipe regression test. I tried winedbg pipe.exe This starts out ok, printing stuff to stdout like I expect, but then it does something very odd: it switches to reverse video right before it prints "In 32-bit mode." The "Wine-dbg>" prompt comes up, but it doesn't respond to the keyboard. Also, the display is stair-stepped, as if the newline char isn't being interpreted as CR-LF. Sounds like stdin is being put in raw mode. I have to do 'killall wine' from another window. It's just totally, mysteriously broken... Before, I could actually use it, but now I'm just confused.
does it behave the same way with other app than pipe.exe or winedbg ?
winedbg behaves this way with any application.
winedbg (in its current implementation) doesn't really control the terminal as gdb does. And I don't intent to make it behave this way, it's supposed to be the job of wineconsole.
Ah. Perhaps us rebels should start maintaining http://www.winehq.com/hypermail/wine-patches/2001/06/0083.html as an alternative approach, then. And I checked; http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses says it's ok to link libreadline to LGPL or X-licensed code.
but it scrolls at line 25 no matter what size the window is,
wineconsole doesn't support dynamic resize yet... it will use the default size for you app in the registry (if you want to change this, run once winedbg under the user console, set the desired size of the console for winedbg (screen buffer size and window size) and save the settings for all the sessions)
Ah. Something for the to-do list, then.
and trying to do 'cont' or 'run' fails with messages like No process loaded, cannot execute 'cont'
there's a bug in wineconsole, the patch has just been sent to wine-patches
I just did a cvs update and reinstall, but I still have problems. Here's my test procedure: cd ~/wine/programs/winedbg write a hello, world program cl /Zi hello.c ./winedbg hello.exe
This reproduces two problems, and now today shows a third.
1. curses is used. I don't want winedbg, or any console program, to use curses, as it complicates simple things like logging output. (I seem to recall there's a way to switch this off now, but I couldn't see it in any doc or help messages. What's the trick?) The immediate symptom is reverse video, but the annoyance runs far deeper.
2. It doesn't respond to keystrokes.
3. [The new problem.] Sometimes it outputs fixme:wineconsole:WCCURSES_GetEvents Ooch. somebody beat us when I hit the first key. Not every time, though.
If I use wineconsole, I still get
WineDbg starting on pid 0 Wine-dbg>cont No process loaded, cannot execute 'cont' Wine-dbg>
And it's in that horrible reverse video.
mmm would your curses use a different attribute mapping ?
The problem *is* curses. How do I turn that off at runtime?
Why can't winedbg just behave like gdb with respect to stdin and stdout? I'm at a loss.
because winedbg isn't gdb... as I wrote above, IMO it isn't the job of winedbg (as an app) to control the terminal, it's up to wineconsole. so if you don't run your pgm under wineconsole, it won't work.
use winedbg -- --gdb if you really don't want wineconsole but do want proper terminal control
I might try that, but am more tempted to revive the libreadline patch. Would it be possible to have, next to winedbg, a winedbg-readline? Then us curses-haters and libreadline-lovers could coexist happily with those who understand and like wineconsole :-)
BTW, I have no idea what wineconsole is or does, and posts like http://www.winehq.com/hypermail/wine-devel/2002/12/0707.html tend to confirm my hypothesis that wineconsole is a strange, evil beast. It may be time for a good "What is Wineconsole and what does it do?" page in winehq (I looked, but couldn't find one).
Thanks, Dan
I just did a cvs update and reinstall, but I still have problems. Here's my test procedure: cd ~/wine/programs/winedbg write a hello, world program cl /Zi hello.c ./winedbg hello.exe
This reproduces two problems, and now today shows a third.
- curses is used. I don't want winedbg, or any console program,
to use curses, as it complicates simple things like logging output. (I seem to recall there's a way to switch this off now, but I couldn't see it in any doc or help messages. What's the trick?) The immediate symptom is reverse video, but the annoyance runs far deeper.
running winedbg hello.exe shouldn't use curses. the issue here is that since your app is a CUI app, winedbg creates it in a separate console, and the two "consoles" (winedbg's fake one - as unix fd:s -, and the debuggee's one - as a curses wineconsole backend). try removing as a quick hack the CREATE_NEW_CONSOLE flag in the CreateProcess call in programs/winedbg/winedbg.c around line 960, that should cure all your issues (the two other items are related to this)
use winedbg -- --gdb if you really don't want wineconsole but do want proper terminal control
I might try that, but am more tempted to revive the libreadline patch. Would it be possible to have, next to winedbg, a winedbg-readline? Then us curses-haters and libreadline-lovers could coexist happily with those who understand and like wineconsole :-)
I this the work around above should make your happier (even if you won't get all the line-editing facilities of readline) IMO, we shouldn't add readline to winedbg... if we really want to add readline, it should be IMO as a generic feature of all CUI programs supported in Wine, and not on a per app basis
BTW, I have no idea what wineconsole is or does, and posts like http://www.winehq.com/hypermail/wine-devel/2002/12/0707.html tend to confirm my hypothesis that wineconsole is a strange, evil beast. It may be time for a good "What is Wineconsole and what does it do?" page in winehq (I looked, but couldn't find one).
yeah, I have this on my todo list to write down what's really going on with the consoles in Wine, the do:s and dont:s..., comparison between the three modes of consoles in wine (features, invocation...)
A+
Eric Pouech wrote:
I just did a cvs update and reinstall, but I still have problems. Here's my test procedure: cd ~/wine/programs/winedbg write a hello, world program cl /Zi hello.c ./winedbg hello.exe
This reproduces two problems, and now today shows a third.
- curses ...
(I seem to recall there's a way to switch this off now, but I couldn't see it in any doc or help messages. What's the trick?) The immediate symptom is reverse video, but the annoyance runs far deeper.
running winedbg hello.exe shouldn't use curses. the issue here is that since your app is a CUI app, winedbg creates it in a separate console, and the two "consoles" (winedbg's fake one - as unix fd:s -, and the debuggee's one - as a curses wineconsole backend). try removing as a quick hack the CREATE_NEW_CONSOLE flag in the CreateProcess call in programs/winedbg/winedbg.c around line 960, that should cure all your issues (the two other items are related to this)
OK. I'm going offline for a while, but will try this when I get back. BTW I may not have picked up all your patches with my cvs update, who knows.
FWIW, one other problem: backspace wasn't working well. This is a longstanding problem with winedbg whenever it was in reverse video (so probably when curses kicked in).
Thanks for the info! - Dan
http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses says it's ok to link libreadline to LGPL or X-licensed code.
ahhh at least, another license flamewar at sight
libreadline is GPL:ed
if I get the paper right, you're allowed to link together module A (LGPL) + module B (GPL), without A being immediately transformed as GPL... (for sake of mind: A is current Wine, B is readline)
what's the license of module A+B, if you link them against a closed source module C (for sake of mind being a proprietary software, ported to Un*x using winelib) ?
can you use proprietary module (C) with A+B ? The answer seems to be no. So, this cannot be used for winelib (as we allow proprietary source to link against A)
so far Wine's policy has been to refuse to link against GPL for this (unclear) matter
A+
-
Dan Kegel -
Eric Pouech