Hi Eric, Thanks for taking the time to reply

The issue is that WriteConsoleInputW requires GENERIC_WRITE access, but the CON device (\\.\CON) was opened as GENERIC_READ (and in fact fails if I try to open it with GENERIC_WRITE). 

You said... 
- you're using a bare console, ie didn't run your app under wineconsole, but simply as wine foo.exe
- if so, does running your app under wineconsole provides the same bad effects ?

Correct, I was running wine <testpgm> (Program is attached to bug 32183). I had not tried it under wineconsole but just have. It works (passes) for all 3 test cases, ie read only file i/o, read and r/w CONIN$. (It does give a slightly different GetLastError result to windows for the 4th testcase, which I really dont care about as it is supposed to fail!)). So its really only failing in bare console mode.

- another item to test would be to see if writeconsoleinput really enforces the generic_write flag as msdn states

So some tests seem to show on windows:
- WriteConsoleInput does fail if CONIN$ isnt opened for write
- WriteConsoleInput does not seem to work at all for a handle opened with WriteFile, which I do not understand (Returns gle 3). 
 
but, for a bare handle, we have to convert unix console keystrokes into win32 keycodes, so we need to feed the keycodes into wine server
if we really have to enforce generic_write, then we should wrap for TERM_ functions the calls to writeconsoleinput with a helper that reopens the console with the right mode

 Do you mean TERM_? The only caller to WriteConsoleInput is console.c, and I think the 'guilty' routine is bare_console_fetch_input. I think you are saying that in read_console_input where we determine that it is a bare fd (get_console_bare_fd == -1), we wrap the call to bare_console_fetch_input by reopening the handle with r/w first?  If so, is there any obvious way to do this.. ideally we would want to test for write ability first, but I cant see an API to do that, so I could just open CONIN$ r/w, call bare_console_fetch_input and then close CONIN$ afterwards, is that what you mean? 

I tested the following
          HANDLE hConRW = CreateFileA("CONIN$"
                             , GENERIC_READ | GENERIC_WRITE,
                             FILE_SHARE_READ, NULL, OPEN_EXISTING,
                             FILE_ATTRIBUTE_NORMAL, 0);
          if (hConRW == INVALID_HANDLE_VALUE) hConRW = handle;
          ret = bare_console_fetch_input(hConRW, fd, timeout);
          if (hConRW!=handle) CloseHandle(hConRW);

It works a charm, although feels inefficient for the times handle was already r/w - (it feels slightly odd that the 'handle' we are working on is unrelated to the handle passed in (I was worried about stdin redirection, but that seems to work fine even after the change).

Was this what you meant or have I gone off on a tangent?

Jason