dos console apps question

[Chris Morgan]

Lately I've been trying to get some dos console apps running under wine.  
These apps run great under wineconsole but not so much just under wine due to 
the lack of a server side console for the routines in dlls/msdos/vga.c to 
output too.  So, after poking all around it seems that at some point during 
the normal loading of an app that we should be calling out to the server with 
alloc_console to create a default console, and binding this console to the 
current terminal.  Does anyone have any suggestions about this?  What 
function this should be done in?

Thanks,
Chris

[Eric Pouech]

Chris Morgan a écrit :
> Lately I've been trying to get some dos console apps running under wine.
> These apps run great under wineconsole but not so much just under wine due to
> the lack of a server side console for the routines in dlls/msdos/vga.c to
> output too.  So, after poking all around it seems that at some point during
> the normal loading of an app that we should be calling out to the server with
> alloc_console to create a default console, and binding this console to the
> current terminal.  Does anyone have any suggestions about this?  What
> function this should be done in?

I don't think this is needed... normally, a program doesn't have to deal
with the creation of it's console
it's up to its parent

however, what you're facing right now is running a DOS program directly
from the unix prompt (like wine mydospgm.com)
in this case, there is no way for the parent process to tell something
to its child, you it's up to you to do it by running the program with
wineconsole mydospgm.com
the only programs so far that may have to deal with creating a console
are:
- wcmd (but in fact it could deal with the current one)
- winedbg because we don't want the debugger to mix it's output with the
debuggee's one

maybe something that will be done when the process creation bits are
done is as follows:
- the wine (or winewrapper) will just parse the unix parameters and then
call CreateProcess to spawn the child process
- this wine executable could then be in charge (if the process requested
for execution is a CUI process) to allocate a new console and ask
CreateProcess to make the child process inherit it.
- however, this scheme must also deal with the situation where we want
the child process to either use the current unix shell (btw, I have a
working version of wineconsole using (n)curses which does just that
(1)), or be retargeted to /dev/null (for example)
- in any case, we will need some more parameters to be giving at the
starting time (and yes, this could also be a per app setting in the
registry)

(1): what's currently missing is a clean way to choose in wineconsole
between the (well known) windows (GDI/USER) version and (not yet
committed) (n)curse for display

A+

Eric Pouech wrote:
> however, what you're facing right now is running a DOS program directly
> from the unix prompt (like wine mydospgm.com)
> in this case, there is no way for the parent process to tell something
> to its child, you it's up to you to do it by running the program with
> wineconsole mydospgm.com

In my favorie case, i.e. running programs like sed.exe or ss.exe
from the unix commandline, what you really want is for Wine to
just get out of the way, do no graphics whatsoever, not even do any X calls
at all, and run the bloody commandline program hooked up to the
existing unix stdin and stdout.

For instance, the Wine 20020509 that comes with redhat 7.3 seems to do about the
right thing when you run it on the sed.exe from http://unxutils.sourceforge.net/UnxUpdates.zip
It starts up quickly and processes input from stdin right away.
Running the same program in wineconsole takes forever (as it loads fonts
and creates a window) and doesn't work.

So wineconsole isn't the answer for any programs I run.
> (1): what's currently missing is a clean way to choose in wineconsole
> between the (well known) windows (GDI/USER) version and (not yet
> committed) (n)curse for display

I saw ncurses in a recent wine... it was horrible, there was no
way to turn it off.  I couldn't run any commandline programs
properly anymore.  Hopefully the work you're talking about
would make it easy to run programs which want neither GDI nor ncurses.

- Dan

[Vincent Béron]

Le mar 30/07/2002 à 00:09, [e-mail] a écrit :
> Eric Pouech wrote:
> > however, what you're facing right now is running a DOS program directly
> > from the unix prompt (like wine mydospgm.com)
> > in this case, there is no way for the parent process to tell something
> > to its child, you it's up to you to do it by running the program with
> > wineconsole mydospgm.com
>
> In my favorie case, i.e. running programs like sed.exe or ss.exe
> from the unix commandline, what you really want is for Wine to
> just get out of the way, do no graphics whatsoever, not even do any X calls
> at all, and run the bloody commandline program hooked up to the
> existing unix stdin and stdout.

When I did some small test cases and needed to test them through ssh
(because I don't have a Windows compiler here), I was able to run them
correctly with the ttydrv rather than x11drv. I don't know about the
stdin/out redirection (or usage), but for what I needed it was fine (I
think I was using wine program.exe>somefile, but I'm not sure).

As it's been a couple months now, I don't know if the ttydrv is still
usable or not.

Vincent