eric pouech eric.pouech@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.
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...
-
Alexandre Julliard -
eric pouech