August 2001 - Wine-Devel - list.winehq.org

Re: _CheckNotSysLevel()

by Alexandre Julliard

Daniel Walker <diwalker(a)earthlink.net> writes: > It seems Wise installers break inside _CheckNotSysLevel() . I think > every Wise installer I've tried breaks .. The cuteftp package was one of > them .. How about posting a backtrace? -- Alexandre Julliard julliard(a)winehq.com

Aug. 23, 2001

Re: ReadFile and other issues

by eric pouech

> > last but not least, recent exchanges made a simple < 1kloc patch a more > > serious project of several kloc :-/ > > I can do the wineserver part if you like. well, the protocol between wineserver and wineconsole has to seen in details too... so, I think I can do everything... however, I still have a few changes in my tree I'd like to finish first... - DDEML (interprocess message passing) - finish the pedump I wrote - several debugger goodies - ... A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Aug. 23, 2001

Re: ReadFile and other issues

by Alexandre Julliard

eric pouech <eric.pouech(a)wanadoo.fr> writes: > anyway, I'd like to get back to simple vs complex consoles if I got > you right, a simple console handle should be in fact nothing more > than a regular file handle which unix fd is set to either 0 or 1 it > means that no enhanced mode is used, nothing but the standard libc > line editing facilities of the input stream so the use would > adequate for a simple program that just uses equivalent of puts/gets > (and associated) functions Exactly yes. > however, I find this very limiting for people who want to use a CUI > exe in a pure unix console mode (either when X11 isn't started, or a > session done over IP in telnet for example) that's why I was > wondering if wineconsole shouldn't also support a (n)curse like > interface (in addition to the USER32 one) to help in this area Sure, once the architecture is in place we can have different implementations of wineconsole, including curses support. The important thing is that this is in a separate application, so that ReadConsole doesn't need to know about things like xterm escape sequences. > last but not least, recent exchanges made a simple < 1kloc patch a more > serious project of several kloc :-/ I can do the wineserver part if you like. -- Alexandre Julliard julliard(a)winehq.com

Aug. 23, 2001

Re: ReadFile and other issues

by eric pouech

Alexandre Julliard wrote: > > eric pouech <eric.pouech(a)wanadoo.fr> writes: > > > well, the issue here is that, even in line editing mode, ReadConsole > > and ReadConsoleInput can be used. the former drops all non keyboard > > events and produces a string, whereas the later returns the available > > input records... > > so, to implement what you propose, the wineconsole would have to know > > in advance which one of the two functions will be called next: > > - in case of ReadConsole, it has to keep all incoming input records, and > > release just the string when it's done editing the line > > - in case of ReadConsoleInput, all generated input records must be > > available in the server to the calling app > > OK I see what you mean. Yes this implies that we must be able to tell > the server to only return input events to the thread doing the > ReadConsole. If I get this right, it also means line editing has to be > done in ReadConsole, and that you can't see what you type when the app > is not reading. Very annoying, but I guess it's more Windows-like... yup, that's the way it is... and more, all the echoing is done in ReadConsole... so if you don't call it, you don't get echo of what you type... so we definitively need the two level approach: - wineconsole generates the input records and stores them in the server - if in line editing mode, a calling thread will ask the server for an exclusive access to the input record queue until the eol is reached echoing is also requested on client side (and transformed into regular WriteConsole calls) anyway, I'd like to get back to simple vs complex consoles if I got you right, a simple console handle should be in fact nothing more than a regular file handle which unix fd is set to either 0 or 1 it means that no enhanced mode is used, nothing but the standard libc line editing facilities of the input stream so the use would adequate for a simple program that just uses equivalent of puts/gets (and associated) functions however, I find this very limiting for people who want to use a CUI exe in a pure unix console mode (either when X11 isn't started, or a session done over IP in telnet for example) that's why I was wondering if wineconsole shouldn't also support a (n)curse like interface (in addition to the USER32 one) to help in this area last but not least, recent exchanges made a simple < 1kloc patch a more serious project of several kloc :-/ A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Aug. 23, 2001

_CheckNotSysLevel()

by Daniel Walker

It seems Wise installers break inside _CheckNotSysLevel() . I think every Wise installer I've tried breaks .. The cuteftp package was one of them .. Daniel Walker

Aug. 23, 2001

Re: ReadFile and other issues

by Alexandre Julliard

eric pouech <eric.pouech(a)wanadoo.fr> writes: > well, the issue here is that, even in line editing mode, ReadConsole > and ReadConsoleInput can be used. the former drops all non keyboard > events and produces a string, whereas the later returns the available > input records... > so, to implement what you propose, the wineconsole would have to know > in advance which one of the two functions will be called next: > - in case of ReadConsole, it has to keep all incoming input records, and > release just the string when it's done editing the line > - in case of ReadConsoleInput, all generated input records must be > available in the server to the calling app OK I see what you mean. Yes this implies that we must be able to tell the server to only return input events to the thread doing the ReadConsole. If I get this right, it also means line editing has to be done in ReadConsole, and that you can't see what you type when the app is not reading. Very annoying, but I guess it's more Windows-like... -- Alexandre Julliard julliard(a)winehq.com

Aug. 22, 2001

Re: ReadFile and other issues

by eric pouech

> I guess line editing could be done by wineconsole, and the input > records would only be sent to the server once we have a complete > line. Or do we need more locking than this? well, the issue here is that, even in line editing mode, ReadConsole and ReadConsoleInput can be used. the former drops all non keyboard events and produces a string, whereas the later returns the available input records... so, to implement what you propose, the wineconsole would have to know in advance which one of the two functions will be called next: - in case of ReadConsole, it has to keep all incoming input records, and release just the string when it's done editing the line - in case of ReadConsoleInput, all generated input records must be available in the server to the calling app > > I was thinking of either a anonmymous file or an anonymous mapping for > > the content of the screen buffer... with an array attribute and char > > may be some additional info on each row to indicate the rendering > > program about the rows which have been modified... > > The problem with a shared buffer is that you need to lock against > simultaneous access, which means a hung thread can hang the whole > console. I'd prefer to have the server simply report to wineconsole > the bounding rect of the screen buffer area that has been modified, > and have wineconsole use ReadConsoleOutput to retrieve the buffer > contents from the server. It's only a few Kbytes to copy at most so > performance should be acceptable. ok... -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Aug. 22, 2001

Re: ReadFile and other issues

by Alexandre Julliard

eric pouech <eric.pouech(a)wanadoo.fr> writes: > fairly acceptable ;-) except that in line editing mode we need to lock > the input buffer on a single thread (that's the way the queue is > handled, > at least, on NT 2000 - didn't check the others) (the granularity for > getting access to the queue is not the input record, but the line (up to > '\n')) I guess line editing could be done by wineconsole, and the input records would only be sent to the server once we have a complete line. Or do we need more locking than this? > I was thinking of either a anonmymous file or an anonymous mapping for > the content of the screen buffer... with an array attribute and char > may be some additional info on each row to indicate the rendering > program about the rows which have been modified... The problem with a shared buffer is that you need to lock against simultaneous access, which means a hung thread can hang the whole console. I'd prefer to have the server simply report to wineconsole the bounding rect of the screen buffer area that has been modified, and have wineconsole use ReadConsoleOutput to retrieve the buffer contents from the server. It's only a few Kbytes to copy at most so performance should be acceptable. -- Alexandre Julliard julliard(a)winehq.com

Aug. 22, 2001

Re: ReadFile and other issues

by eric pouech

Alexandre Julliard wrote: > > "Eric Pouech"<eric.pouech(a)voila.fr> writes: > > > if we want to go into this, there are a few points to agree on first: > > - since console handles can be inherited, the Wine console window should > > be run in a different process than the one which uses the console (and > > add communication means between the first process, and the process > > rendering the console) > > - how should we know a program needs either a simple or a complex > > console (we could use a registry key in the per process area) > > We need a separate process yes. I was thinking of something like a > 'wineconsole' Winelib app. Then if you want to run an app with a > separate console you use wineconsole instead of wine to start it. > A new wineconsole could also be launched when the app does an > AllocConsole, or some other function that requires a complex console. hmm I suppose that CREATE_NEW_CONSOLE flag in CreateProcess should be handled that way too... I don't think we should have the ability to change on the fly from a simple to a complex console: current code switches to a complex console when a "complex" operation is requested (cursor motion...) so, if I try to sump up... by default, we start wine with a simple console... if another console is requested (AllocConsole, CreateProcess(...,CREATE_NEW_CONSOLE,...), ...), then we create a complex console default behavior (simple console) at startup could be modified by either: - a per application specific entry in the registry - or using launching thru the wineconsole winelib program we keep the default inheritance rules for console handles... a simple console is inherited as simple (a complex as complex), except for CREATE_NEW_CONSOLE > The communication with the console can probably go through the > server. Input events can simply be put in the queue by wineconsole > using WriteConsoleInput. fairly acceptable ;-) except that in line editing mode we need to lock the input buffer on a single thread (that's the way the queue is handled, at least, on NT 2000 - didn't check the others) (the granularity for getting access to the queue is not the input record, but the line (up to '\n')) > Output should probably go to a server screen > buffer object, which would then signal wineconsole that its contents > changed. I was thinking of either a anonmymous file or an anonymous mapping for the content of the screen buffer... with an array attribute and char may be some additional info on each row to indicate the rendering program about the rows which have been modified... the WriteFile on a screen buffer handle should be done as already discussed for ReadFile on console input handles... fail the regular read operation and fall back to WriteConsole A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Aug. 22, 2001

Re: ReadFile and other issues

by Alexandre Julliard

"Eric Pouech"<eric.pouech(a)voila.fr> writes: > if we want to go into this, there are a few points to agree on first: > - since console handles can be inherited, the Wine console window should > be run in a different process than the one which uses the console (and > add communication means between the first process, and the process > rendering the console) > - how should we know a program needs either a simple or a complex > console (we could use a registry key in the per process area) We need a separate process yes. I was thinking of something like a 'wineconsole' Winelib app. Then if you want to run an app with a separate console you use wineconsole instead of wine to start it. A new wineconsole could also be launched when the app does an AllocConsole, or some other function that requires a complex console. The communication with the console can probably go through the server. Input events can simply be put in the queue by wineconsole using WriteConsoleInput. Output should probably go to a server screen buffer object, which would then signal wineconsole that its contents changed. -- Alexandre Julliard julliard(a)winehq.com

Aug. 22, 2001