Reference terminal for writing conformance tests for console functions
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.
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)
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
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?
reopening handle to console could help also Do you mean to close and open the console handle...?
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
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
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
first, tests should be included in the wine non regression test (not sure from reading if it's the case or not) They eventually will be, assuming you are talking about dlls/kernel32/tests/console.c. But for the moment, I am running my tests apart from the other non-regression tests(My tests are quite ad-hoc right now).
a suggested work around is to start the tests with FreeConsole()/AllocConsole() Hmm alright, I shall try that out. Now that you mention it, I see that some test cases already use such a mechanism.
On Mon, May 25, 2026 at 12:57 PM Eric Pouech via Wine-Devel < wine-devel@list.winehq.org> wrote:
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)
participants (3)
-
Barath Rk -
Eric Pouech -
Eric Pouech