Ekkehard Morgenstern ekkehard.morgenstern@onlinehome.de writes:
This small patch provides command line option output, a "--help" option and a default user backend ("--backend=user" is default) to "wineconsole".
Your mailer wrapped the patch, please resend it. Also please send separate changes as separate patches, and try to follow the coding conventions of the surrounding code.
Alexandre Julliard wrote:
Ekkehard Morgenstern ekkehard.morgenstern@onlinehome.de writes:
This small patch provides command line option output, a "--help" option and a default user backend ("--backend=user" is default) to "wineconsole".
Your mailer wrapped the patch, please resend it. Also please send separate changes as separate patches, and try to follow the coding conventions of the surrounding code.
also changing the default to user is a bad idea... especially for users wanting to run a text only win32 app from a linux console without X started A+
Eric Pouech eric.pouech@wanadoo.fr writes:
also changing the default to user is a bad idea... especially for users wanting to run a text only win32 app from a linux console without X started
I think that's a very small minority, what most people want is a real console in a separate window. We could certainly fall back to the curses backend when we aren't under X and can't create a user32 window.
On Tue, August 8, 2006 4:18 am, Alexandre Julliard wrote:
I think that's a very small minority, what most people want is a real console in a separate window. We could certainly fall back to the curses backend when we aren't under X and can't create a user32 window.
I used Wine for a while to run some command line tools (like some embedded assembler and linker). I certainly did not want a new console popup on each invocation. Not sure if this would be the case here, but it's certainly one of the most irritating Windows behaviours.
"Dimi Paun" dimi@lattica.com writes:
I used Wine for a while to run some command line tools (like some embedded assembler and linker). I certainly did not want a new console popup on each invocation. Not sure if this would be the case here, but it's certainly one of the most irritating Windows behaviours.
Real command-line tools shouldn't pop up anything, it's only for stuff that requires console functionality. Currently it will pop up the curses stuff, which frankly isn't that much better than opening a separate window.
On Tuesday 08 August 2006 04:18, Alexandre Julliard wrote:
Eric Pouech eric.pouech@wanadoo.fr writes:
also changing the default to user is a bad idea... especially for users wanting to run a text only win32 app from a linux console without X started
I think that's a very small minority
On my dev boxes, about 95% of the CPU time used up by wine is solely for running windows command line applications such as Visual Studio and Zilog's ZDS II compilers under linux and I'd be sorely pissed off if they suddenly stopped working. Popping up console windows is equal to not working for me.
I'm logging their output and using them for automated builds (under aegis) on hosts where DISPLAY is empty and there's no X server present. I can't see why you'd need X and console windows in order to run those. That's a big step backwards.
Also, I'd love it a lot if all the ncurses crap was avoided. The compilers output plain text on the standard output (whatever that is on windows). I'd hate to have some terminal crap inserted into that.
I know that not too many people are using wine like that, but right now it works fine and I'd kindly ask for it to keep working, rather than get broken.
If anyone needs me to put money where my mouth is, I offer $100 via PayPal if someone in charge wants financial coercion to avoid putting in the X/graphical/ncurses crap for console applications. I'm dead serious.
Cheers, Kuba
Kuba Ober kuba@mareimbrium.org writes:
Also, I'd love it a lot if all the ncurses crap was avoided. The compilers output plain text on the standard output (whatever that is on windows). I'd hate to have some terminal crap inserted into that.
I know that not too many people are using wine like that, but right now it works fine and I'd kindly ask for it to keep working, rather than get broken.
Nobody is suggesting to change the behavior for apps that don't use wineconsole. The only suggested change is to default to X instead of curses for the console window. If you don't see curses crap now, you won't see X crap with the change.
I know that not too many people are using wine like that, but right now it works fine and I'd kindly ask for it to keep working, rather than get broken.
Nobody is suggesting to change the behavior for apps that don't use wineconsole. The only suggested change is to default to X instead of curses for the console window. If you don't see curses crap now, you won't see X crap with the change.
Cool :) Keeping things excrement-free is the way (aren't I in a funny mood today) :)
Kuba
On 8/8/06, Kuba Ober kuba@mareimbrium.org wrote:
On Tuesday 08 August 2006 04:18, Alexandre Julliard wrote:
Eric Pouech eric.pouech@wanadoo.fr writes:
also changing the default to user is a bad idea... especially for users wanting to run a text only win32 app from a linux console without X started
I think that's a very small minority
Breaking text only win32 apps is not an option.
If anyone needs me to put money where my mouth is, I offer $100 via PayPal if someone in charge wants financial coercion to avoid putting in the X/graphical/ncurses crap for console applications. I'm dead serious.
I'll see your bet, and raise you $150. The requirements are: 1) text mode win32 apps should not invoke curses unless they start using cursor motion 2) text mode win32 apps should not use user unless they dynamically load user32.dll 3) whatever solution is picked, it should be similar to the one used on Windows NT/2000/XP 4) wine should be able to run a windows telnet server that invokes cmd to parse commands without tripping over itself.
If anyone needs me to put money where my mouth is, I offer $100 via PayPal if someone in charge wants financial coercion to avoid putting in the X/graphical/ncurses crap for console applications. I'm dead serious.
I'll see your bet, and raise you $150.
Wow, so you're saying that you add $50 to my offer? If that's so -- nice. As it is, things work for me now, but just in case someone wanted to break it (it seems not!), I'd be paying to stop the breakage from getting into a release. Whitemailing of sorts ;) http://en.wikipedia.org/wiki/Anti-crime#Anti-crime
The requirements are:
- text mode win32 apps should not invoke curses unless they start using
cursor motion
Second that.
- text mode win32 apps should not use user unless they dynamically load
user32.dll
Yep.
- whatever solution is picked, it should be similar to the one used on
Windows NT/2000/XP
No clue here.
- wine should be able to run a windows telnet server
that invokes cmd to parse commands without tripping over itself.
Yes.
Kuba
Kuba Ober wrote:
Popping up console windows is equal to not working for me. (...)
Also, I'd love it a lot if all the ncurses crap was avoided. The compilers output plain text on the standard output (whatever that is on windows).
Why don't you just use "wcmd <app>"?
As I gather, "wineconsole" is for providing a Windows console environment. Unfortunately, the ncurses implementation seems to be broken (doesn't work properly on my box), that's why I suggest using a separate window, because it works.
For running text-mode applications that don't need a user interface, you can use "wcmd" stand-alone.
Alexandre Julliard wrote:
Your mailer wrapped the patch, please resend it.
How? Do you think it will work as an attachment? I'm using Mozilla Mail.
Also please send separate changes as separate patches,
OK
and try to follow the coding conventions of the surrounding code.
I will have another look at it shortly.
After apparently 7 years of no-one doing anything on that code, I think a couple of days in delay will not hurt! ;-)
This is also the first time I ever contributed to an open-source project! So, the entire thing is new to me! :-)
I would also like to replace WCMD with a compatible, but much better version, sometime. How would I go about that? Can I provide a patch for a whole folder?
Ekkehard Morgenstern ekkehard.morgenstern@onlinehome.de writes:
I would also like to replace WCMD with a compatible, but much better version, sometime. How would I go about that? Can I provide a patch for a whole folder?
The usual way is to fix one bug at a time... If you are suggesting a complete rewrite you'll need to make a very convincing case that throwing away the existing code is preferable to fixing it.
Alexandre Julliard wrote:
The usual way is to fix one bug at a time... If you are suggesting a complete rewrite you'll need to make a very convincing case that throwing away the existing code is preferable to fixing it.
Well, WCMD allows only 2 arguments, for instance. IMNSHO the code is effed-up beyond repair, and I would rather rewrite it than expand on it.
But I won't bother writing a replacement if it's not desired by the WINE community.
What I want to do is basically provide a true reimplementation of Windows' CMD.EXE program, including, but not limited to, all commands that are available on Windows XP.
Extensions I plan to include are graphics commands and more console control commands, among others. Plus more ksh-like redirection operators. CMD.EXE already supports a few, and I would add the full suite.
The extensions would check if a Wine console window was present by calling GetConsoleWindow() (which is currently not implemented) and posting a message there that would alter the screen font, cursor location, color, etc.
Ekkehard Morgenstern ekkehard.morgenstern@onlinehome.de writes:
Well, WCMD allows only 2 arguments, for instance. IMNSHO the code is effed-up beyond repair, and I would rather rewrite it than expand on it.
But I won't bother writing a replacement if it's not desired by the WINE community.
wcmd certainly needs a lot of love, and improvements would be welcome. But it's usually not a good idea to start with the "throw it away and rewrite" attitude; and to be blunt, I'm not going to accept a rewrite unless you demonstrate that a) you thorougly understand the existing code, and b) you can really do better. And the only way to demonstrate both is by first submitting good patches against the existing code.
-
Alexandre Julliard -
Dan Kegel -
Dimi Paun -
Ekkehard Morgenstern -
Eric Pouech -
Kuba Ober