I'm back after a long time just lurking. I was realy excited about the conformance testing program. Since I am the IT Administrator of a company that uses a wide variety of windows versions (no NT3 sorry) I will be able to submit a good number of tests results.
The problem I have under windows 98 is that the zip file found here http://afavant.elte.hu/~wferi/wine/ produces an results.txt file but the (newer) exe found here http://vmlinux.org/jakov/Wine/ locks up without producing any output (even when redirected >).
Both tests freeze at the same place. That is they both lock up during the console test (kernel32_crosstest.exe console) the test produces a blue "abc" in the top right hand corner of my dos prompt box and requires that I "Ctrl-C" to get out.
The following is the output results
kernel32.dll:console (test 7 of 55) abcdefgconsole.c:128: Test failed: At (0,0): expecting char 'a'/61 got ' '/20 console.c:128: Test failed: At (0,0): expecting attr 0012 got 0007 console.c:128: Test failed: At (1,0): expecting char 'b'/62 got ' '/20 console.c:128: Test failed: At (1,0): expecting attr 0012 got 0007 console.c:128: Test failed: At (2,0): expecting char 'c'/63 got ' '/20 console.c:128: Test failed: At (2,0): expecting attr 0012 got 0007 console.c:128: Test failed: At (3,0): expecting char 'd'/64 got ' '/20 console.c:128: Test failed: At (3,0): expecting attr 0012 got 0007 console.c:128: Test failed: At (4,0): expecting char 'e'/65 got ' '/20 console.c:128: Test failed: At (4,0): expecting attr 0012 got 0007 console.c:128: Test failed: At (5,0): expecting char 'f'/66 got ' '/20 console.c:128: Test failed: At (5,0): expecting attr 0012 got 0007 console.c:128: Test failed: At (6,0): expecting char 'g'/67 got ' '/20 console.c:128: Test failed: At (6,0): expecting attr 0012 got 0007 console.c:131: Test failed: Expected cursor at (7,0), got (0,0)
I have looked at dlls/kernel/tests/console.c to see if it was something obvious but have not had anything jump out at me. From looking at the code the cursor should be at the top left of the screen but the text is written at the top RIGHT (-3)of it.
Eric since you wrote the test could you shed some light on it.
Tony Lambregts
Eric since you wrote the test could you shed some light on it.
I think the wrapped tests should fail: MSDN states that wrapping isn't supported in 95/98 (the test/console.c believes it's always supported)
but this testSimple() should work in all cases
Eric Pouech on Sunday, September 14, 2003 10:46 AM wrote
Eric since you wrote the test could you shed some light on it.
I think the wrapped tests should fail: MSDN states that wrapping isn't supported in 95/98 (the test/console.c believes it's always supported)
but this testSimple() should work in all cases
I don't grep what you mean. What is this testSimple()
I don't mind the test failing if we expect it to fail. The problem(s) I have is that the output is screwed up and that I have to press CTRL-C to move on. I know we don't want to do a version test in the conformance tests so, should we be testing wrapping as part of the default tests? We s/could keep it as an optional test if the behavior is known not to be consistent in all versions, but is consistent in flavors. IE: NT vs 9x
The bottom line here is that the output is junked for this test under Windows 9x/me and the user has to press CTRL-C to get out of it. If nether of these occured I would keep it as a default test but thats not the case.
Repectfully
Tony Lambregts.
Tony Lambregts wrote:
Eric Pouech on Sunday, September 14, 2003 10:46 AM wrote
Eric since you wrote the test could you shed some light on it.
I think the wrapped tests should fail: MSDN states that wrapping isn't supported in 95/98 (the test/console.c believes it's always supported)
but this testSimple() should work in all cases
I don't grep what you mean. What is this testSimple()
it's the name of the function which fails at line 128 in test/console.c
I don't mind the test failing if we expect it to fail. The problem(s) I have is that the output is screwed up and that I have to press CTRL-C to move on. I know we don't want to do a version test in the conformance tests so, should we be testing wrapping as part of the default tests? We s/could keep it as an optional test if the behavior is known not to be consistent in all versions, but is consistent in flavors. IE: NT vs 9x
agreed. My point was that I could some other tests in console.c to fail under win98, but not this one. Does the same behavior happens if you redirect the output to a file instead of printing it on screen A+
Eric Pouech wrote:
Tony Lambregts wrote:
Eric Pouech on Sunday, September 14, 2003 10:46 AM wrote
Eric since you wrote the test could you shed some light on it.
I think the wrapped tests should fail: MSDN states that wrapping isn't supported in 95/98 (the test/console.c believes it's always supported)
but this testSimple() should work in all cases
I don't grep what you mean. What is this testSimple()
it's the name of the function which fails at line 128 in test/console.c
Ah... But it's name is testWriteSimple() this is what I see in CVS..
113 static void testWriteSimple(HANDLE hCon, COORD sbSize) 114 { 115 COORD c; 116 DWORD len; 117 const char* mytest = "abcdefg"; 118 const size_t mylen = strlen(mytest); 119 120 /* single line write */ 121 c.X = c.Y = 0; 122 ok(SetConsoleCursorPosition(hCon, c) != 0, "Cursor in upper-left"); 123 124 ok(WriteConsole(hCon, mytest, mylen, &len, NULL) != 0 && len == mylen, "WriteConsole"); 125 c.Y = 0; 126 for (c.X = 0; c.X < mylen; c.X++) 127 { 128 okCHAR(hCon, c, mytest[c.X], TEST_ATTRIB); 129 } 130 131 okCURSOR(hCon, c); 132 okCHAR(hCon, c, ' ', DEFAULT_ATTRIB); 133 }
at line 121 c.X and c.Y are set to 0 and line so I would expect that the output should be at the TOP-RIGHT corner of the screen. However what I am seeing is that the ouput for this is showing up at the TOP-LEFT (less 3) corner of the screen.
So I see abc at the top right hand corner of the screen and the test is locked up under Windows 9x. Pressing CTRL-C allows the test to continue.
agreed. My point was that I could some other tests in console.c to fail under win98, but not this one. Does the same behavior happens if you redirect the output to a file instead of printing it on screen
I have attached the results of the test that I ran like so:
kernel32_crosstest.exe console > results.txt
I get the same results if I run it in a DOS box or Full Screen. From the results and behavior of the test I have to wonder what is the actual value of c.Y.
Perplexed....
Tony Lambregts
at line 121 c.X and c.Y are set to 0 and line so I would expect that the output should be at the TOP-RIGHT corner of the screen.
0,0 is TOP LEFT. 79,0 is TOP RIGHT.
However what I am seeing is that the ouput for this is showing up at the TOP-LEFT (less 3) corner of the screen.
if you mean here TOP-RIGHT-3, then this looks like the next testWriteNotWrappedNotProcessed
So I see abc at the top right hand corner of the screen and the test is locked up under Windows 9x. Pressing CTRL-C allows the test to continue.
agreed. My point was that I could some other tests in console.c to fail under win98, but not this one. Does the same behavior happens if you redirect the output to a file instead of printing it on screen
I have attached the results of the test that I ran like so:
kernel32_crosstest.exe console > results.txt
I get the same results if I run it in a DOS box or Full Screen. From the results and behavior of the test I have to wonder what is the actual value of c.Y.
since abcdef appears in the output file, it means that maybe win98 doesn't open CONIN$ the same way NT does. This would suggest CONIN$ actually opens the standard output stream to the process (in your case redirected to file result.txt), even if it should open the output stream to the console attached to the processus. Does the test behaves the same if you comment out the first two CreateFileA in START_TEST(console) ?
A+
Eric Pouech Wrote:
at line 121 c.X and c.Y are set to 0 and line so I would expect that the output should be at the TOP-RIGHT corner of the screen.
0,0 is TOP LEFT. 79,0 is TOP RIGHT.
Yeah, I meant my other right <g>
However what I am seeing is that the ouput for this is showing up at the TOP-LEFT (less 3) corner of the screen.
if you mean here TOP-RIGHT-3, then this looks like the next testWriteNotWrappedNotProcessed
Yes I meant TOP-RIGHT-3. Now It does not make sense to me that it would be choking on the next test but displaying failing results from this one.
So I see abc at the top right hand corner of the screen and the test is locked up under Windows 9x. Pressing CTRL-C allows the test to continue.
agreed. My point was that I could some other tests in console.c to fail under win98, but not this one. Does the same behavior happens if you redirect the output to a file instead of printing it on screen
I have attached the results of the test that I ran like so:
kernel32_crosstest.exe console > results.txt
I get the same results if I run it in a DOS box or Full Screen. From
the
results and behavior of the test I have to wonder what is the actual
value
of c.Y.
since abcdef appears in the output file, it means that maybe win98 doesn't open CONIN$ the same way NT does. This would suggest CONIN$ actually opens the standard output stream to the process (in your case redirected to file result.txt), even if it should open the output stream to the console attached to the processus. Does the test behaves the same if you comment out the first two CreateFileA in START_TEST(console) ?
Well I dont have MSVC so I can't compile the tests if I did that. AFAIK compiling using MinGW still has issues. So... If I make up a diff is anyone interested in doing the compiling useing MSVC?
Hopefully
Tony Lambregts
Tony Lambregts wrote:
Well I dont have MSVC so I can't compile the tests if I did that. AFAIK compiling using MinGW still has issues. So... If I make up a diff is anyone interested in doing the compiling useing MSVC?
Mail it to me.
Jakob
Jakob Eriksson wrote:
Tony Lambregts wrote:
Well I dont have MSVC so I can't compile the tests if I did that. AFAIK compiling using MinGW still has issues. So... If I make up a diff is
anyone
interested in doing the compiling useing MSVC?
Mail it to me.
I really appreciate this Jacob. Sorry I did not get this to you sooner but my paying job....
Thankfully
Tony Lambregts
Tony Lambregts wrote:
I really appreciate this Jacob. Sorry I did not get this to you sooner but my paying job....
Well, the upshot of not having a paying job is I can do more Wine compiles. Of course, I need a lot of time, since Wine takes forever to compile on my box. :-)
regards, Jakob
-
Eric Pouech -
Jakob Eriksson -
Tony Lambregts