I did send a couple of days ago a first patch about the (n)curses backend to wineconsole Alexandre commented a few implementation issues in it, which may change a bit what I started with and how the wineconsole should behave:
console creation can be invoked from different contexts: 1/ the program calls AllocConsole 2/ the user starts wine thru wineconsole for his/her (favorite) CUI app (using from command line something like 'wineconsole foo') 3/ (N1) the program forks a child with CREATE_NEW_CONSOLE flags set in CreateProcess 4/ the program doesn't request anything
on the other hand, wineconsole is now able to handle two types of backend for the user interface: A/ USER: the one already in place B/ Curses: the new one using (n)curses and a regular term for display (N2) C/ no wineconsole support => by default, the windows input & output streams are hooked to stdin and stdout, but we don't provide full console support - cursor motion, screen reading...
now the final question, how to choose between A, B and C. the proposal is to fix the choice with: 1 => A 2 => B 3 => A 4 => C
why such a directive proposal ? 4 => C is rather natural and doesn't need further explanation (one day, we could envisage to support it no longer, but that's another story) 1 => A greatly facilitates the console creation (ncurses requires both terminal control and moreover to keep the process group leader running as long as all the children - hooked to the same terminal - are running). Very few programs use AllocConsole (and even use it). The only issue may be with winedbg which may allocate its own console on startup (N3) 2 => B we could easily add 2 => A too (with some wineconsole parameters). Moreover, if the user wants to have the console in a specific xterm, it's doable with xterm -e 'wineconsole blablabla' 3 => A here again it's easier to deal with. if trying to run a curses backend, we should ensure that two different wineconsoles are not currently hooked to the same terminal
If you have any comments, speak up now !! A+
N1: 3/ can be seen from various aspects as a specific case of 1/, but implementation could implement it as 2/) 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 N3: IMO what's missing is that winedbg should check if has inheried a real console. If so, it should detach from it and recreate a new one.
On Tue, Nov 19, 2002 at 09:38:02PM +0100, Eric Pouech wrote:
I did send a couple of days ago a first patch about the (n)curses backend to wineconsole Alexandre commented a few implementation issues in it, which may change a bit what I started with and how the wineconsole should behave:
console creation can be invoked from different contexts: 1/ the program calls AllocConsole 2/ the user starts wine thru wineconsole for his/her (favorite) CUI app (using from command line something like 'wineconsole foo') 3/ (N1) the program forks a child with CREATE_NEW_CONSOLE flags set in CreateProcess 4/ the program doesn't request anything
on the other hand, wineconsole is now able to handle two types of backend for the user interface: A/ USER: the one already in place B/ Curses: the new one using (n)curses and a regular term for display (N2) C/ no wineconsole support => by default, the windows input & output streams are hooked to stdin and stdout, but we don't provide full console support - cursor motion, screen reading...
now the final question, how to choose between A, B and C. the proposal is to fix the choice with: 1 => A 2 => B 3 => A 4 => C
2 => B we could easily add 2 => A too (with some wineconsole parameters). Moreover, if the user wants to have the console in a specific xterm, it's doable with xterm -e 'wineconsole blablabla'
Hmm, what is wrong with A for all the first 3 cases?
Even the IDA Disassembler now likes the USER based console.
Otherwise ok.
Ciao, MArcus
Marcus Meissner a écrit :
Hmm, what is wrong with A for all the first 3 cases?
nothing. but we need a way to let users pick up 2 => B (it doesn't mean we'll forbid 2 => A for all the wineconsole lovers ;-)
A+
On November 19, 2002 03:38 pm, Eric Pouech wrote:
If you have any comments, speak up now !!
I will not comment directly on the solutions presented, but rather I will try to list my requirements, as a user. Note that some/all of them may be working already, but it's here for as a reference: 1. If I start a command-line app in a terminal, I want the app to make use of the terminal, not NOT start a new one. Unix apps behave like this (eg. Midnight Commander) and command-line Wine apps should not behave any differently. 2. I want to be able to redirect stdin/stdout for command-line apps like on any regular Unix app 3. I want to be able to use Wine command-line apps without X 4. I would love to be able to choose the terminal that's started. That is, instead of having wineconsole pop up, wouldn't it be cool if konsole/gnome-terminal/rxvt/xterm/etc would be fired up depending on desktop-environment/user preference?
I view 1 & 2 as absolutely fundamental. If they are not supported, I'd say our implementation is broken.
Point 4 is very important, at least for me: not only wineconsole is not as good as the Unix consoles, it's also very annoying to not be able to use your console of choice. And besides, from the user's POV, a console, it's a console, it's a console. Why should I be _forced_ to run a particular one? I have customized the hell out of mine, I want _that_ one.
Point 2 is nice to have, but a lot more academic than the others, at least for me, as I always run under X. Mind you however, that there was a time when I used Wine to run some uC assemblers (command line), and it's easy to see that sometimes X is simply not available.
- If I start a command-line app in a terminal, I want the app to make use of the terminal, not NOT start a new one. Unix apps behave like this (eg. Midnight Commander) and command-line Wine apps should not behave any differently.
that's the 2 => B case (or more exactly, that'll be 2 => B) except if the windows app tries to spawn a child which will require a new console. MC (at least the DOS version I remember) is able to switch from child to parent screen we won't do that (in that case a wineconsole/USER will be opened for the child)
- I want to be able to redirect stdin/stdout for command-line apps like on any regular Unix app
works
- I want to be able to use Wine command-line apps without X
ok (see thread with D Kegel who screams for this)
- I would love to be able to choose the terminal that's started. That is, instead of having wineconsole pop up, wouldn't it be cool if konsole/gnome-terminal/rxvt/xterm/etc would be fired up depending on desktop-environment/user preference?
this would rather we choosen by the user with xterm -e 'wine foo.exe bar' or rxvt -e 'wine foo.exe bar' or ...
A+
On November 21, 2002 01:55 pm, Eric Pouech wrote:
- I would love to be able to choose the terminal that's started. That is, instead of having wineconsole pop up, wouldn't it be cool if konsole/gnome-terminal/rxvt/xterm/etc would be fired up depending on desktop-environment/user preference?
this would rather we choosen by the user with xterm -e 'wine foo.exe bar' or rxvt -e 'wine foo.exe bar' or ...
Sure, that's the initial invocation. But beyond that, what if I run a a windows app, and that one starts a command line app? In that case, I don't want wineconsole to pop up, but rather my console of choice. A common example is winedbg: it starts up in wineconsole, but I'd rather have it start in konsole...
It looks like another registry entry...
Sure, that's the initial invocation. But beyond that, what if I run a a windows app, and that one starts a command line app? In that case, I don't want wineconsole to pop up, but rather my console of choice. A common example is winedbg: it starts up in wineconsole, but I'd rather have it start in konsole...
this won't be easily possible, because wine has no knowledge on what currently exists on the terminal the whole point of the proposal is: - if the user launches a wine program from the shell, then wine controls the terminal and we're fine - in any other cases, we don't (easily) know. therefore, wineconsole/user is forced
A+
On November 21, 2002 02:26 pm, Eric Pouech wrote:
this won't be easily possible, because wine has no knowledge on what currently exists on the terminal
Sorry, I don't understand exactly the issues here, but what don't we know to exist? I mean, if we start it, can't we assume a blank slate?
"Dimitrie O. Paun" a écrit :
On November 21, 2002 02:26 pm, Eric Pouech wrote:
this won't be easily possible, because wine has no knowledge on what currently exists on the terminal
Sorry, I don't understand exactly the issues here, but what don't we know to exist? I mean, if we start it, can't we assume a blank slate?
various stuff: - if another wine console is running on the same terminal - when a console is started, we have to wait until all wine processes attached to it have terminated (on a win32 point of view) before restoring the screen and at the same time to exit before the process controlling the terminal (read the process which allocated the win32-console) dies (from a unix point of view)
A+
On November 21, 2002 02:47 pm, Eric Pouech wrote:
various stuff:
- if another wine console is running on the same terminal
How can it, we're talking about the case when _we_ start up the console, so there shouldn't be anything on it, no?
- when a console is started, we have to wait until all wine processes
attached to it have terminated (on a win32 point of view) before restoring the screen and at the same time to exit before the process controlling the terminal (read the process which allocated the win32-console) dies (from a unix point of view)
This seems complicated... :) But, here's how I look at it:
1. If we start the program in our console, it makes use of it: xterm -e "wine myprog.exe" you say it should work just fine.
2. Now, in the case we start a console program from within Wine we do that when we execute: CreateProcess("myprog.exe") The way I see it is that in fact we're supposed to figure out that myprog.exe is a CUI app, and instead execute: CreateProcess("wineconsole myporg.exe") So, why can't we just do: CreateProcess("xterm -e 'wine myprog.exe'") instead?
Of course, this is an oversimplification, but this is how the whole thing looks like from outside, from the user perspective. Why can't we have this run like this?
This seems complicated... :)
that's why we need to simplify what we want to do ;-))
But, here's how I look at it:
If we start the program in our console, it makes use of it: xterm -e "wine myprog.exe" you say it should work just fine.
Now, in the case we start a console program from within Wine we do that when we execute: CreateProcess("myprog.exe") The way I see it is that in fact we're supposed to figure out that myprog.exe is a CUI app, and instead execute: CreateProcess("wineconsole myporg.exe") So, why can't we just do: CreateProcess("xterm -e 'wine myprog.exe'") instead?
this won't work, because CreateProcess passes from parent to child some context information the child get it from wineserver using its parent process id in your case, wine myprog.exe ppid will we xterm, not the parent process
A+
On November 21, 2002 03:25 pm, Eric Pouech wrote:
This seems complicated... :)
that's why we need to simplify what we want to do ;-))
:)))))
this won't work, because CreateProcess passes from parent to child some context information the child get it from wineserver using its parent process id in your case, wine myprog.exe ppid will we xterm, not the parent process
That's fine, I was just saying what the process _looks_ like from outside. That is to say, it's quite counterintuitive why you can not pick your console, as in some cases, it works just fine... (ie. xterm -e "wine...").
So obviously we can't simply do: CreateProcess("xterm -e 'wine myprog.exe'")
but rather something like (in theory): p1 = CreateProcess("xterm") p2 = CreateProcess("myprog.exe'") and somehow tell p2 about p1, so it can bind to it. Now, this is the point, it seems, where you're saying that we don't know stuff about p1, and I'm saying that we've just created it ourselves, what is it that we don't know? Or am I completely off?
"Dimitrie O. Paun" a écrit :
On November 21, 2002 03:25 pm, Eric Pouech wrote:
This seems complicated... :)
that's why we need to simplify what we want to do ;-))
:)))))
this won't work, because CreateProcess passes from parent to child some context information the child get it from wineserver using its parent process id in your case, wine myprog.exe ppid will we xterm, not the parent process
That's fine, I was just saying what the process _looks_ like from outside. That is to say, it's quite counterintuitive why you can not pick your console, as in some cases, it works just fine... (ie. xterm -e "wine...").
So obviously we can't simply do: CreateProcess("xterm -e 'wine myprog.exe'")
but rather something like (in theory): p1 = CreateProcess("xterm") p2 = CreateProcess("myprog.exe'") and somehow tell p2 about p1, so it can bind to it.
well, that won't work out of the box... p2 won't get the right context at start up, binding won't be that easy (basically, p2 needs to inherit p1 stdin & stdout, which is rather easy if p2 is a child of p1 - and then back to square one -...)
assuming this would work (I'm not even sure it'll work in all cases),
Now, this is the point, it seems, where you're saying that we don't know stuff about p1, and I'm saying that we've just created it ourselves, what is it that we don't know? Or am I completely off?
this won't support the case where the app creates it own console after it has started this won't cover the case where, in a X11-less configuration, you try to open two consoles on the same terminal (by two different processes ... A+
On November 21, 2002 04:44 pm, Eric Pouech wrote:
this won't support the case where the app creates it own console after it has started
Duh! Forgot about that one. This is getting funny :) What about this one:
When we create a console, we start a process (say wconsole, since the wineconsole is taken :)) that starts the console of our choice, and then communicates back to us, somehow, the stdin, stdout, and stderr handles.
Sorry to insist on this this much, but it would be so cool if people are not forced to use wineconsole. You know probably 10^10 more about this subject than I do, but I'd like to understand where exactly the problem is.
"Dimitrie O. Paun" a écrit :
On November 21, 2002 04:44 pm, Eric Pouech wrote:
this won't support the case where the app creates it own console after it has started
Duh! Forgot about that one. This is getting funny :) What about this one:
When we create a console, we start a process (say wconsole, since the wineconsole is taken :)) that starts the console of our choice, and then communicates back to us, somehow, the stdin, stdout, and stderr handles.
as I wrote, the issue is not about creating the console (that's doable), it's about keeping it open while all apps attached to this console are running and in all the cases it creates a huge amount of code/work to be created (and I not even sure that's doable in a 100% bullet proof fashion)
A+
On November 22, 2002 01:24 pm, Eric Pouech wrote:
and in all the cases it creates a huge amount of code/work to be created (and I not even sure that's doable in a 100% bullet proof fashion)
I see the problems now, thanks for the explanation. In that case, I would say between to equal methods, pick the one that leaves the door open for such future work, if anyone is inclined to do it.
I see the problems now, thanks for the explanation. In that case, I would say between to equal methods, pick the one that leaves the door open for such future work, if anyone is inclined to do it.
that's also what I had in mind... it's time now to go back to write actually what has been discussed in the RFC A+
-
Dimitrie O. Paun -
Eric Pouech -
Marcus Meissner