>createfile: (after allocconsole) : that ensures the opened handle will be linked to the newly created console

Yes, this is what I am doing. My code looks something like this now, and it works well in my Windows VM, popping open a new console window:

FreeConsole(); //Free existing console

AllocConsole();

HANDLE hstdin = CreateFile("CONIN$", ....);

FlushConsoleInputBuffer(hstdin); // Get rid of garbage input at the start

// My test goes here

FreeConsole();

On Mon, 25 May, 2026, 9:49 pm Eric Pouech via Wine-Devel, <wine-devel@list.winehq.org> wrote:
Le 25/05/2026 à 17:50, Barath Rk via Wine-Devel a écrit :
I don't understand this.

> it could also happen that default input handle (depends on how you get it) is not what you'd expect
I don't understand this. Do you mean getting the input handle using GetStdHandle vs using CreateFile? 
yes... getstdhandle will get you what the process that launched you process decides to set as input handle, you want a handle on the console you want to test against

> reopening handle to console could help also
Do you mean to close and open the console handle...?

close: depends where you got it... if from getstdhandle, not recommanded (unless you really understand what you're doing)

createfile: (after allocconsole) : that ensures the opened handle will be linked to the newly created console



On Mon, May 25, 2026 at 1:18 PM Eric Pouech via Wine-Devel <wine-devel@list.winehq.org> wrote:
Le 25/05/2026 à 09:25, Eric Pouech via Wine-Devel a écrit :
Le 24/05/2026 à 17:17, Barath Rk via Wine-Devel a écrit :
I am trying to implement the ReadConsoleInputExW function, and while writing tests for the same, realized that the behaviour of my test programs vary across consoles inside my Windows 10 VM. For example, the output is different when I use cmd to run the tests versus using MSYS2(which uses mintty) to run the tests.

My question is: should the behaviour exhibited by the test program when run on cmd in Windows be taken as the canonical reference in this case? If so, then when testing my implementation on the programs using wine, is it enough for the output in wineconsole to be consistent with the cmd output?

Thanks in advance.

first, tests should be included in the wine non regression test (not sure from reading if it's the case or not)

secondly, tests should be written in a way that they are not sensible to the environment (or IOW, if needed, the env shall be constrained by the tests themselves)

in your case, it's likely the tests are written using "current" console, which may introduce some discrepancies; a suggested work around is to start the tests with FreeConsole()/AllocConsole() which will ensure the test will be run in its dedicated console (note however, that in that case, test should be added towards the end of the list of tests in kernel32/tests/console.c as first tests are supposed to be run agains "current" console)

it could also happen that default input handle (depends on how you get it) is not what you'd expect; reopening handle to console could help also