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
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 $
This may be a stupid question, but aren't you supposed to use 'wineconsole' for wine console apps?
Kelly
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)
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.
drivers are loaded for USER, not GDI. So the first question is where does ss.exe pull USER32.DLL from ?
Is this the recommended way to run console wine programs without any $&?@!% curses stuff kicking in and without X?
wine pgm.exe if pgm.exe doesn't depend on user & gdi (but that's not your case).
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".
It wouldn't be very difficult to set the User32 Driver on a pgm per pgm basis.
A+
Eric Pouech wrote:
$ wine -- /dos/d/vss/win32/ss.exe x11drv: Can't open display:
That should have worked ...
... first question is where does ss.exe pull USER32.DLL from ?
$ tools/winedump/winedump dump /dos/d/vss/win32/ss.exe ... Subsystem 0x3 (Windows CUI) ...
$ tools/winedump/winedump dump -j import /dos/d/vss/win32/ss.exe ... offset 370196 USER32.dll Hint/Name Table: 00069224 TimeDataStamp: 00000000 (Wed Dec 31 16:00:00 1969) ForwarderChain: 00000000 First thunk RVA: 000693E4 (delta: 4294967295 0xffffffff) Ordn Name 29 CharLowerA 697b6 564 SystemParametersInfoA 697f8 387 LoadStringA 6981e 39 CharToOemA 69810 43 CharUpperA 697c4 418 OemToCharBuffA 697d2 300 GetSystemMetrics 697e4
offset 370216 GDI32.dll Hint/Name Table: 00069094 TimeDataStamp: 00000000 (Wed Dec 31 16:00:00 1969) ForwarderChain: 00000000 First thunk RVA: 00069254 (delta: 4294967295 0xffffffff) Ordn Name ...
$ wine --debugmsg +loaddll /dos/d/vss/win32/ss.exe trace:loaddll:load_dll Loaded module 'C:\WINDOWS\SYSTEM\KERNEL32.dll' : builtin trace:loaddll:load_dll Loaded module 'C:\WINDOWS\SYSTEM\advapi32.dll' : builtin trace:loaddll:load_dll Loaded module 'C:\WINDOWS\SYSTEM\gdi32.dll' : builtin trace:loaddll:load_dll Loaded module 'C:\WINDOWS\SYSTEM\USER32.dll' : builtin trace:loaddll:load_dll Loaded module 'C:\WINDOWS\SYSTEM\rpcrt4.dll' : builtin trace:loaddll:load_dll Loaded module 'C:\WINDOWS\SYSTEM\ole32.dll' : builtin trace:loaddll:load_dll Loaded module 'C:\WINDOWS\SYSTEM\MPR.dll' : builtin trace:loaddll:MODULE_LoadModule16 Loaded module 'krnl386.exe' : builtin trace:loaddll:MODULE_LoadModule16 Loaded module 'system' : builtin trace:loaddll:MODULE_LoadModule16 Loaded module 'GDI.EXE' : builtin trace:loaddll:MODULE_LoadModule16 Loaded module 'USER.EXE' : builtin trace:loaddll:load_dll Loaded module 'C:\WINDOWS\SYSTEM\x11drv.dll' : builtin ...
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".
It wouldn't be very difficult to set the User32 Driver on a pgm per pgm basis.
That'd be nice. A commandline option would be optimal. .wine/config entries wouldn't be as useful, since sometimes you want to run them different ways, and editing one huge config file is a pain to script anyway.
- Dan
Dan Kegel wrote:
29 CharLowerA 697b6564 SystemParametersInfoA 697f8 387 LoadStringA 6981e 39 CharToOemA 69810 43 CharUpperA 697c4 418 OemToCharBuffA 697d2 300 GetSystemMetrics 697e4
I wish one day things could be made right... buffer upper/lower case manipulation has nothing to do with the windowing system... anyway, so it goes in Redmond.
so an empty "None" graphical driver is the easiest way to go.
That'd be nice. A commandline option would be optimal. .wine/config entries wouldn't be as useful, since sometimes you want to run them different ways, and editing one huge config file is a pain to script anyway.
I don't think Alexandre would like the command line option (at least as it is) to the main wine executable, but that's another story.
A+
Eric Pouech pouech-eric@wanadoo.fr writes:
It wouldn't be very difficult to set the User32 Driver on a pgm per pgm basis.
Actually that's far from trivial, since many things access windows from other processes and depend on these using the same graphics driver. The right fix is to delay x11drv initialization until we really need it.
On Fri, 18 Jul 2003, Alexandre Julliard wrote:
: Actually that's far from trivial, since many things access windows : from other processes and depend on these using the same graphics : driver. The right fix is to delay x11drv initialization until we : really need it.
Yes, that would be very wonderful to see someday. It'd be nice to be able to run Win32 command line apps once in a while without $DISPLAY set (7-zip comes to mind), but without having to hack "config" back and forth.
It seems to me that once the initialization of X11 is delayed, it may be possible to roll the frills of ttydrv into x11drv and do away with multiple driver selection altogether. (Keeping it simple?)
On Sat, 19 Jul 2003 07:00, Todd Vierling wrote:
Yes, that would be very wonderful to see someday. It'd be nice to be able to run Win32 command line apps once in a while without $DISPLAY set (7-zip comes to mind), but without having to hack "config" back and forth.
A work-around is to use Xvfb as the X server.
On Tue, 22 Jul 2003, Troy Rollo wrote:
: > Yes, that would be very wonderful to see someday. It'd be nice to be able : > to run Win32 command line apps once in a while without $DISPLAY set (7-zip : > comes to mind), but without having to hack "config" back and forth. : : A work-around is to use Xvfb as the X server.
That's so bloated, that it's like working around a family feud by bombing the other family out of existence. But since my last name isn't Bush, I don't think that's very useful. 8-P
-
Alexandre Julliard -
Bill Medland -
Dan Kegel -
Eric Pouech -
Kelly Leahy -
Todd Vierling -
Troy Rollo