On July 15, 2003 08:16 pm, Dan Kegel wrote:
OK folks, it's time for my semiannual "I need Wine to run a commandline program, but can't get it to work" rant.
First try: just do a default installation of wine-20030709.
Log:
$ wine -- /dos/d/vss/win32/ss.exe Could not stat /mnt/fd0 (No such file or directory), ignoring drive A: x11drv: Can't open display: $ echo $DISPLAY $
That should have worked, since ss.exe doesn't use any GDI functions.
Moving right along, now let's try the tty driver. I added "GraphicsDriver" = "ttydrv"
dank@dank:~$ wine /dos/d/vss/win32/ss.exe dank@dank:~$
It blipped the display to a second screen, then when the program exited, the screen blipped back so I couldn't read what it said. That's pretty useless. In fact, this is exactly the behavior complained about in bug 1358 ( http://bugs.winehq.com/show_bug.cgi?id=1358 ) subtitled "GraphicsDriver" = "none" wanted.
On the off chance that a "none" driver had been implemented, I tried it. And suprisingly, something sensible happened:
dank@dank:~$ wine /dos/d/vss/win32/ss.exe help Could not load graphics driver 'none' fixme:console:SetConsoleCtrlHandler (0x449460,1) - no error checking or testing yet Username:
It actually seemed to work, once past the warning! I haven't tested it beyond the password prompt yet, but that was pretty convincing.
Is this the recommended way to run console wine programs without any $&?@!% curses stuff kicking in and without X? And is there a chance of setting this behavior on a program-by-program basis? AppDefaults appears to be keyed off the driver already, so is probably not able to say "these apps should not use x11drv or ttydrv".
Thanks, Dan
Have you tried running it outside X (ie at a normal command line terminal, not an xterm). That works for me; I never thought of using ttydrv while under X. (Of course, as far as I am concerned that means there is a bug somewhere; heck, you can't even redirect the stdout when under an xterm)