Re: [PATCH 4/5] [kernel] Support opening of console for read (try 2)
Eric Pouech writes: > - seperate the process to read input from fd(0) and the current > running process > (hence ensuring that we get the correct rights for writing) > this is what we do with wineconsole (for other backends). > moving bare console to wineconsole > could also other benefits, as ensuring that the process > controling the unix console doesn't > die until the last wine process using it dies (and resetting > the terminal control at exit) That would probably be a better approach, yes. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 4/5] [kernel] Support opening of console for read (try 2)
On 20 November 2012 12:31, Alexandre Julliard wrote: > > That doesn't guarantee that it's the process console, console handles > can be passed across processes. > > So apologies if this is an ignorant question, I dont really understand this console logic properly so I was researching the options. MSDN help for DuplicateHandle ( http://msdn.microsoft.com/en-gb/library/windows/desktop/ms724251(v=vs.85).aspx) states console handles cannot be duplicated for use in other processes, is there another context that I am missing? Any hints/suggestions on the best way to solve this problem - Ideally we would want to duplicate the handle extending to add write access, since the original device was opened read only, but I am not aware of a clean way to do this. Jason
Re: [PATCH 4/5] [kernel] Support opening of console for read (try 2)
Le 20/11/2012 13:31, Alexandre Julliard a écrit : Eric Pouech writes: That doesn't look right. There's no guarantee that the handle is for the current process console. in fact, it's guaranted, because we check before (in the function calling this helper) that the handle is really a console handler and that it's in bare mode one could make it clearer by adding a comment to the helper function saying that those two conditions are met That doesn't guarantee that it's the process console, console handles can be passed across processes. yes, but the base console code is already broken wrt this point (we use the current process' console wait object instead of the wait object of the passed console) potential solutions ? - extending the server calls to support this behavior would break rights enforcement. not good IMO. - seperate the process to read input from fd(0) and the current running process (hence ensuring that we get the correct rights for writing) this is what we do with wineconsole (for other backends). moving bare console to wineconsole could also other benefits, as ensuring that the process controling the unix console doesn't die until the last wine process using it dies (and resetting the terminal control at exit) - any other ideas ? A+
Re: [PATCH 4/5] [kernel] Support opening of console for read (try 2)
Eric Pouech writes: >> That doesn't look right. There's no guarantee that the handle is for the >> current process console. > in fact, it's guaranted, because we check before (in the function > calling this helper) that the handle is really a console handler and > that it's in bare mode > one could make it clearer by adding a comment to the helper function > saying that those two conditions are met That doesn't guarantee that it's the process console, console handles can be passed across processes. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 4/5] [kernel] Support opening of console for read (try 2)
> That doesn't look right. There's no guarantee that the handle is for the > current process console. in fact, it's guaranted, because we check before (in the function calling this helper) that the handle is really a console handler and that it's in bare mode one could make it clearer by adding a comment to the helper function saying that those two conditions are met A+ -- Eric Pouech
Re: [PATCH 4/5] [kernel] Support opening of console for read (try 2)
Ann and Jason Edmeades writes:
> +BOOL WINAPI write_console_input( HANDLE handle, const INPUT_RECORD *buffer,
> + DWORD count, LPDWORD written )
> +{
> +BOOL result = WriteConsoleInputW(handle, buffer, count, written);
> +
> +/* If this fails with access denied */
> +if (!result && GetLastError() == ERROR_ACCESS_DENIED)
> +{
> +HANDLE hConRW = CreateFileW(coninW, GENERIC_READ | GENERIC_WRITE,
> +FILE_SHARE_READ, NULL, OPEN_EXISTING,
> +FILE_ATTRIBUTE_NORMAL, 0);
> +if (hConRW != INVALID_HANDLE_VALUE)
> +{
> +result = WriteConsoleInputW(hConRW, buffer, count, written);
> +CloseHandle(hConRW);
> +}
That doesn't look right. There's no guarantee that the handle is for the
current process console.
--
Alexandre Julliard
julli...@winehq.org
