Eric wrote:
N2: one could try running wineconsole USER backend with ttydrv instead of x11drv, but that's out of the scope of this (maybe for Dimi's fun projects list
ttydrv is not as far out as all that. I use ttydrv now to run commandline windows programs that output to stdout.
I *cannot* use the current Debian wine, because *it uses curses*. Curses renders commandline windows programs useless. Imagine a program that outputs two lines of text. With Wine switching to the alternate text screen on entry, and switching back on exit, *you never see those lines of text, ever*. And with those escape characters gunking up the output, you certainly can't pipe the output of wine running that console program to a file and get anything sensible.
Please help make wine safe for running commandline programs from the unix shell - let us select 'ttydrv, no curses' easily somehow! I'm tired of having a separate .wine directory for console programs, and I'm tired of debian's wine (and possibly also the main tree) breaking commandline programs so badly.
- Dan
Dan Kegel a écrit :
Eric wrote:
N2: one could try running wineconsole USER backend with ttydrv instead of x11drv, but that's out of the scope of this (maybe for Dimi's fun projects list
ttydrv is not as far out as all that. I use ttydrv now to run commandline windows programs that output to stdout.
ttydrv isn't meant to run CUI programs. ttydrv is a graphical backend to gdi (which happens to display on a textual terminal)
I *cannot* use the current Debian wine, because *it uses curses*.
=> because ttydrv uses curses, not because wine uses curses
Please help make wine safe for running commandline programs from the unix shell - let us select 'ttydrv, no curses' easily somehow!
just do wine mypgm
the issue you're having right now is that: - wine, at startup, always create a specific task to handle the desktop (even just a CUI program is run, but you cannot tell in advance) - this requires gdi & user to be loaded - you cannot use x11drv if X11 isn't running - you cannot use ttydrv because it'll control your terminal - therefore, in this case, a null drv would be indeed needed (that should't be too hard to build)
A+
Eric Pouech eric.pouech@wanadoo.fr writes:
the issue you're having right now is that:
- wine, at startup, always create a specific task to handle the desktop
(even just a CUI program is run, but you cannot tell in advance)
- this requires gdi & user to be loaded
Note that this is only for 16-bit apps. 32-bit apps won't load gdi or user unless the app itself imports them; unfortunately most command lines apps import them for no good reason. The right approach would be to delay x11drv initialization until the first gdi or user call, but this is quite a bit of work.
Eric Pouech wrote:
Dan Kegel a écrit :
Eric wrote:
N2: one could try running wineconsole USER backend with ttydrv instead of x11drv, but that's out of the scope of this (maybe for Dimi's fun projects list
ttydrv is not as far out as all that. I use ttydrv now to run commandline windows programs that output to stdout.
ttydrv isn't meant to run CUI programs. ttydrv is a graphical backend to gdi (which happens to display on a textual terminal)
Perhaps that's how it is now, but that's not how it was a year ago... back then, no curses were invoked on startup, and ttydrv was perfect for commandline programs on a headless system.
I *cannot* use the current Debian wine, because *it uses curses*.
=> because ttydrv uses curses, not because wine uses curses
Please help make wine safe for running commandline programs from the unix shell - let us select 'ttydrv, no curses' easily somehow!
just do wine mypgm
the issue you're having right now is that:
- wine, at startup, always create a specific task to handle the desktop
(even just a CUI program is run, but you cannot tell in advance)
- this requires gdi & user to be loaded
- you cannot use x11drv if X11 isn't running
- you cannot use ttydrv because it'll control your terminal
- therefore, in this case, a null drv would be indeed needed (that
should't be too hard to build)
Grr. Maybe I should go look at last year's ttydrv to see how to do it properly :-)
Actually, what I'd like to see is a way to specify the driver to use on the wine commandline. It's bogus to have to have a separate .wine directory to do that...
- Dan
Grr. Maybe I should go look at last year's ttydrv to see how to do it properly :-)
most of the curses loading is protected by ifdef:s (btw curses inclusion is 2 years and 8 months old... perhaps you didn't have the curse-devel package installed by then) did you try recompiling wine with --without-curses option in configure ?
Actually, what I'd like to see is a way to specify the driver to use on the wine commandline. It's bogus to have to have a separate .wine directory to do that...
it would be a better fix, as Alexandre noted, to let true CUI apps run without user/gdi support, rather than tweaking every possible bit
A+
-
Alexandre Julliard -
Dan Kegel -
Eric Pouech