Re: Re: dos console apps question

> From: Eric Pouech 
> Date: 2002/07/29 Mon PM 12:34:11 EDT
> To: Chris Morgan ,  Jukka Heinonen , 
>    DanKegel 
> CC: [e-mail]
> Subject: Re: dos console apps question
>
> 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+

Having the process use the current term window is exactly what I'm looking for.  How far along is the patch you have and would you be in need of any assistance?

I'm not sure what you mean by not being able to have the parent process communicate with the child process and how this affects things.  Is the problem how to capture and render the output from the application that was directed to the console and the standard handles?  Couldn't this just be done in the appropriate win32 console functions for input/output and with standard unix handles passed around for stdio?

Thanks,
Chris