On linuxe I get this:
[s2@katleriai s2]$ wine /usr/local/lib/wine/winetest.exe.so Usage: /tmp/wctW5ad4P/msvcrt_test.exe.so test_name
Valid test names: cpp environ file headers heap scanf string time
..while Wine Test Shell pops up a message box with the error text:
"Can't parse subtests output of msvcrt".
I think that's due to some additional \r\n-s in the output of "msvcrt_test.exe.so". Here goes my observation and comparision to the case of "mlang_test.exe.so" (which works smoothly with the winetest):
[s2@katleriai tests]$ wine msvcrt_test.exe.so | head -n 1 | od -t x1 0000000 55 73 61 67 65 3a 20 6d 73 76 63 72 74 5f 74 65 0000020 73 74 2e 65 78 65 2e 73 6f 20 74 65 73 74 5f 6e 0000040 61 6d 65 0d 0a 0000045
[s2@katleriai tests]$ wine mlang_test.exe.so | head -n 1 | od -t x1 0000000 55 73 61 67 65 3a 20 6d 6c 61 6e 67 5f 74 65 73 0000020 74 2e 65 78 65 2e 73 6f 20 74 65 73 74 5f 6e 61 0000040 6d 65 0a 0000043
As the "Valid test names:" string is printed by calling fprintf(), I suppose some differences arise due to incorrect linkage or such:
[s2@katleriai tests]$ nm msvcrt_test.exe.so | grep fprintf 0001e100 D fprintf 0001e180 D vfprintf
[s2@katleriai tests]$ nm mlang_test.exe.so | grep fprintf U fprintf@@GLIBC_2.0 U vfprintf@@GLIBC_2.0
It seems we realy are using msvcrt version of the fprintf(), which works in true-M$-way and adds an additional \r here. Next goes last lines from the build process:
[s2@katleriai tests]$ (make clean && make) | tail -n 1 ../../../tools/winegcc/winegcc -B../../../tools/winebuild -mconsole cpp.o environ.o file.o headers.o heap.o scanf.o string.o time.o testlist.o -o msvcrt_test.exe.so -L../../../libs/port -lwine_port -L../../../dlls -L../../../libs -lmsvcrt
[s2@katleriai tests]$ (make clean && make) | tail -n 1 ../../../tools/winegcc/winegcc -B../../../tools/winebuild -mconsole mlang.o testlist.o -o mlang_test.exe.so -L../../../libs/port -lwine_port -L../../../dlls -L../../../libs -lole32 -lgdi32 -lkernel32 -lntdll -luuid
Can we fix it? I have no idea on how to link it right with the GLIBC. Of course, I am not sure this is the core of the problem. It would be nice to have winetest running in linux without such two hits (one for the msvcrt and another one for the msvcrtd).
Or is this just my linux box configuration flawed?
Saulius Krasuckas saulius2@ar.fi.lt writes:
I think that's due to some additional \r\n-s in the output of "msvcrt_test.exe.so".
Actually, not quite. The problem is that msvcrt's output functions aren't redirected by libc's filehandle operations, so winetest doesn't get the output (it gets printed to the screen instead). Yeah, it's annoying, but doesn't hurt the meant functionality of winetest, which shouldn't be run under Wine for anything but testing purposes. The native (Windows) run doesn't show this problem, since there we use msvcrt functions exclusively. Still it would be nice to fix, but the proper way would be to fix Wine, and that's not entirely trivial as Alexandre commented.
On Wed, 18 Aug 2004, Ferenc Wagner wrote:
Saulius Krasuckas saulius2@ar.fi.lt writes:
I think that's due to some additional \r\n-s in the output of "msvcrt_test.exe.so".
Actually, not quite. The problem is that msvcrt's output functions aren't redirected by libc's filehandle operations, so winetest doesn't get the output (it gets printed to the screen instead).
Oh.. :-/
Yeah, it's annoying, but doesn't hurt the meant functionality of winetest, which shouldn't be run under Wine for anything but testing purposes. The native (Windows) run doesn't show this problem, since there we use msvcrt functions exclusively. Still it would be nice to fix, but the proper way would be to fix Wine, and that's not entirely trivial as Alexandre commented.
Can you provide a link to the post or maybe some keywords to find it using google? Thanks.
Saulius Krasuckas saulius2@ar.fi.lt writes:
On Wed, 18 Aug 2004, Ferenc Wagner wrote:
Saulius Krasuckas saulius2@ar.fi.lt writes:
I think that's due to some additional \r\n-s in the output of "msvcrt_test.exe.so".
Actually, not quite. The problem is that msvcrt's output functions aren't redirected by libc's filehandle operations, so winetest doesn't get the output (it gets printed to the screen instead).
Oh.. :-/
Yeah, it's annoying, but doesn't hurt the meant functionality of winetest, which shouldn't be run under Wine for anything but testing purposes. The native (Windows) run doesn't show this problem, since there we use msvcrt functions exclusively. Still it would be nice to fix, but the proper way would be to fix Wine, and that's not entirely trivial as Alexandre commented.
Can you provide a link to the post or maybe some keywords to find it using google? Thanks.
Try this for example:
http://search.gmane.org/search.php?query=redirect+winetest&email=&gr...
If you can't help feeling like hacking on winetest, I can send you my todo list, too... :) Or maybe I should put it into the source so that innocent bycomers can see it...
On Wed, 18 Aug 2004, Ferenc Wagner wrote:
Saulius Krasuckas saulius2@ar.fi.lt writes:
On Wed, 18 Aug 2004, Ferenc Wagner wrote:
The problem is that msvcrt's output functions aren't redirected by libc's filehandle operations, so winetest doesn't get the output (it gets printed to the screen instead).
Yeah, it's annoying, but doesn't hurt the meant functionality of winetest, which shouldn't be run under Wine for anything but testing purposes. The native (Windows) run doesn't show this problem, since there we use msvcrt functions exclusively. Still it would be nice to fix, but the proper way would be to fix Wine, and that's not entirely trivial as Alexandre commented.
Can you provide a link to the post or maybe some keywords to find it using google? Thanks.
Try this for example:
http://search.gmane.org/search.php?query=redirect+winetest&email=&gr...
Thanks, I have found the start of the thread [1] using this link. Still I cannot imagine:
why during another tests we are able to redirect output, and namely during the msvcrt* tests we are failing to do so. No, no. I mean, why in the two latter tests we cannot use the way to print the output which is used by the rest of the tests?
MSVCRT.DLL.SO fprintf() doesn't get redirected? OK, lets switch to glibc (or anything who works properly). Isn't it trivial to do?
Maybe here goes the principle of not hiding the bug? If yes, then please tell me that bad way. I will just be using it alone.
If you can't help feeling like hacking on winetest, I can send you my todo list, too... :) Or maybe I should put it into the source so that innocent bycomers can see it...
Heh, I am not sure I would be able to help by anything, but please post your todo, Ferenc. It is always interesting to see such stuff alive. :-)
[1] http://www.winehq.org/hypermail/wine-devel/2004/03/index.html#504
Le ven 27/08/2004 à 11:38, Saulius Krasuckas a écrit : [snip]
MSVCRT.DLL.SO fprintf() doesn't get redirected? OK, lets switch to glibc (or anything who works properly). Isn't it trivial to do?
Just redirecting it to glibc would be trivial, but the problem is that's not the Right Thing To Do (tm) as both don't have exactly the same behavior, and that some apps rely on the msvcrt behavior (ie, break when using glibc's). I'm sure there are some other reasons like the path used by characters to be drawn on screen (glibc's stdlib vs some console handler path for msvcrt), etc.
Vincent
On 27 Aug 2004, Vincent Béron wrote:
Just redirecting it to glibc would be trivial, but the problem is that's not the Right Thing To Do (tm) as both don't have exactly the same behavior, and that some apps rely on the msvcrt behavior (ie, break when using glibc's).
This part if fine. Now please tell me: why printing result of msvcrt* tests should depend on the difference of this behaviour? I mean, why do we need msvcrt functions to print information about the behaviour of another msvcrt functions? I always used to thought this is extremely uncorrelated stuff:
1, testing function of the lib; 2, printing results of the test.
Are both thingies hardly tied? Forgive my ignorance, but I am afraid I won't be able to undrestand this just by digging in the Wine src. Thanks.
I'm sure there are some other reasons like the path used by characters to be drawn on screen (glibc's stdlib vs some console handler path for msvcrt), etc.
Saulius Krasuckas saulius2@ar.fi.lt writes:
On 27 Aug 2004, Vincent Béron wrote:
Just redirecting it to glibc would be trivial, but the problem is that's not the Right Thing To Do (tm) as both don't have exactly the same behavior, and that some apps rely on the msvcrt behavior (ie, break when using glibc's).
This part if fine. Now please tell me: why printing result of msvcrt* tests should depend on the difference of this behaviour? I mean, why do we need msvcrt functions to print information about the behaviour of another msvcrt functions? I always used to thought this is extremely uncorrelated stuff:
1, testing function of the lib; 2, printing results of the test.
Are both thingies hardly tied? Forgive my ignorance, but I am afraid I won't be able to undrestand this just by digging in the Wine src. Thanks.
You are absolutely right, these two things should have nothing to do to each other. On my part it's simply that I've got no idea how to make that distinction. Wine's testing framework (test.h) uses fprintf() to do its output. It usually means glibc's fprintf(), but in the msvcrt* tests in means that of msvcrt, since those tests are linked with -lmsvcrt explicitly before the implicit -lc for the very purpose of the tests. So it's pure technicality at this end (at the other it's the matter of fixing msvcrt to take glibc redirection into account), which I didn't care enough to find a way to fix. It would be trivial if all the test used LoadLibrary() and GetProcAddress() to access the functions they test instead of linking them in, but it's not the case, especially not with such common and widely available functions as fprintf() for example.
Hope I got the explanation right and that it makes sense for you. We are humans, that's to say...
And finally a couple of winetest todos:
1. Implement the Stop button, like eg. first wait for the current test, then force termination. 2. Add an option the extract the tests and stop. 3. Ask for a Tag in the GUI (defaulting to the one given on the command line). 4. Add HTTP proxy support. 5. Remove mystrtok(), which isn't needed anymore.
Out of these 3. and 4. would be the most useful additions, but the show seems to be stopped on the server side, so I will work there first.
-
Ferenc Wagner -
Saulius Krasuckas -
Vincent Béron