> so it would make more sense to simply let WriteConsoleW fail when
> is_console_handle(hConsoleOutput) is FALSE ?
> (similar functions as WriteConsoleA, ReadConsoleA/W should be protected
> the same way)
Currently only three APIs in console.c check is_console_handle():
VerifyConsoleIoHandle(), DuplicateConsoleHandle() and
CloseConsoleHandle(). That could certainly be extended to others and
things even seems to work if I add a simple 'if
(!is_console_handle(hConsoleOutput)) return FALSE;' at the start of
WriteConsoleW().
then that's the correct way to fix it
One could then rip out the code in the WriteFile() branch but I'm not
sure what the consequences of all this would be or why the WriteFile()
case was added in the first place. The author of that code would
probably know better than me<g>.
no, the WriteFile stuff must be kept
basically, we need to handle three cases (h being the handle passed to WriteConsole)
C1/ h isn't a console handle (ie lower bits not set) => fail (return FALSE)
C2/ h is a console handle, and removing the lower bits we have a handle to a console object in wine server => call wineserver
C3/ h is a console handle, and removing the lower bits we have a handle to a file object in wine server => call WriteFile => ...
you get :
- C1 when output is redirected to a file/pipe...
- C2 when running wineconsole net.exe
- C3 when running wine net.exe
note that we're playing with handles, and hidding behind console handles (with lower bit sets) handles to other objects...
(in fact, from your first post, there is no infinite loop as the calls are made on different objects)
you can safely provide the patches with protecting WriteConsole and friends with a if (!is_console_handle(???)) return FALSE; line
A+
--
Eric Pouech