On Wed, 2005-02-09 at 16:59, Paul Millar wrote:
I haven't worked on any of winetest's innards, so this is largely guess work...
On Wednesday 09 February 2005 13:22, you wrote:
If I run winetest-200502091000-paul-mingw manually on my win98 box I get several messages "Can't parse subtests output of" for the following tests [...] just before the tests actually start.
My guess is that winetest is attempting to run these tests, but that they are dying straight away, with some error message. This error message is not the expected output, hence the error messsage.
[...]
Does this mean that we have a deeper lying problem?
Yes, obviously! The tests are failing and we have no mechanism for detecting this. This, in itself, is a bug.
Or just that more tests are somehow not correct (in combination with mingw)?
I've bundled the individual tests in: http://www.astro.gla.ac.uk/users/paulm/WRT/winetest-bin-20050209.zip (its some 2.6MiB in size, though)
I image you should be able to run the shlwapi test individually, which should help narrow down the cause.
HTH,
Paul.
Hi Paul,
I've included wine-devel again as this must touch others as well.
I wasn't able to run the shlwapi tests on my win98 box, by itself. Running this gives an error box:
The SHLWAPI_.EXE file is linked to missing export SHLWAPI.DLL:PathIsValidCharA
and just for completeness sake:
dsound:
... linked to missing export DSOUND.DLL:DirectSoundCreate8
mlang:
... linked to missing export NTDLL.DLL:atoi
msvcrtd:
A required .DLL, MSVCRTD.DLL, was not found
ole32:
... linked to missing export NTDLL.DLL:atoi
Cheers,
Paul Vriens.
If I run winetest-200502091000-paul-mingw manually on my win98 box I get several messages "Can't parse subtests output of" for the following tests [...] just before the tests actually start.
In the first round winetest runs all the individual test executables to find out the names of subtests they contain. In case of a failure it obiously has no way to run those tests, so they are skipped. You have the freedom the run the problematic executables manually and find out more. Winetest could be massaged to include the unparsable output in the report, but it didn't seem worth it, as most of the time it means that the test doesn't apply for the given system (no such DLL installed).
On Wednesday 09 February 2005 16:57, Ferenc Wagner wrote:
In the first round winetest runs all the individual test executables to find out the names of subtests they contain. In case of a failure it obiously has no way to run those tests, so they are skipped. You have the freedom the run the problematic executables manually and find out more.
To me it seems silly to blanket accept broken programs. Known exclusions could be catered for such as ntdll tests on a W95 box (those fail, right?) either client-side (i.e. within winetest.exe) or server-side.
The current situation supposes that the person debugging the problem has access to the Win box that generated the fault, and so can recreate the problem by running the original xxx_test.exe executable.
By reporting back the error, someone can fix it without needing the specific version of Win98 that demonstrated the error.
Paul (just my 2 euro-cent worth ;^)
Am Mittwoch, 9. Februar 2005 17:16 schrieb Paul Vriens:
On Wed, 2005-02-09 at 16:59, Paul Millar wrote:
[snip]
Hi Paul,
I've included wine-devel again as this must touch others as well.
I wasn't able to run the shlwapi tests on my win98 box, by itself. Running this gives an error box:
The SHLWAPI_.EXE file is linked to missing export SHLWAPI.DLL:PathIsValidCharA
and just for completeness sake:
dsound:
... linked to missing export DSOUND.DLL:DirectSoundCreate8
mlang:
... linked to missing export NTDLL.DLL:atoi
msvcrtd:
A required .DLL, MSVCRTD.DLL, was not found
ole32:
... linked to missing export NTDLL.DLL:atoi
Cheers,
Paul Vriens.
Hello,
mlang.dll and ole32.dll can be linked against msvcrt.dll insted of ntdll (like in the attached patch). Will this cause problems?
Bye Stefan
PS: Is someone working on a fix for the missing import of shlwapi.dll? If nobody 'complains' I will make a patch tomorrow evening
On Wednesday 09 February 2005 21:55, Stefan Leichter wrote:
Am Mittwoch, 9. Februar 2005 17:16 schrieb Paul Vriens:
mlang: linked to missing export NTDLL.DLL:atoi
[...]
ole32: linked to missing export NTDLL.DLL:atoi
mlang.dll and ole32.dll can be linked against msvcrt.dll insted of ntdll (like in the attached patch). Will this cause problems?
Yes, and no.
If msvcrt.dll is available then this will solve the problem. But (from vague memories) although msvcrt is available for W95/98, its by no means installed by default. On Paul's machine, the msvcrt-specific tests are failing due to a lack of that DLL.
Really, someone should write a simple atoi() implementation and the tests link against the portable code. This can't take more than ten minutes, right?
Cheers,
Paul.
* On Wed, 9 Feb 2005, Paul Millar wrote:
- On Wednesday 09 February 2005 21:55, Stefan Leichter wrote:
- Am Mittwoch, 9. Februar 2005 17:16 schrieb Paul Vriens:
mlang: linked to missing export NTDLL.DLL:atoi
[...]
ole32: linked to missing export NTDLL.DLL:atoi
mlang.dll and ole32.dll can be linked against msvcrt.dll insted of ntdll (like in the attached patch). Will this cause problems?
Yes, and no.
If msvcrt.dll is available then this will solve the problem. But (from vague memories) although msvcrt is available for W95/98, its by no means installed by default. On Paul's machine, the msvcrt-specific tests are failing due to a lack of that DLL.
Really, someone should write a simple atoi() implementation and the tests link against the portable code. This can't take more than ten minutes, right?
Is someone working on any atoi() implementation to use it in Winetest now?
Saulius Krasuckas wrote:
Is someone working on any atoi() implementation to use it in Winetest now?
Here you have:
int atoi(char* buf) { int ret = 0; char *c = buf;
if(*c == '-') c++;
while(*c) { if(*c < '0' || *c > '9') return 0; ret = ret*10 + (*c++)-'0'; }
return *buf == '-' ? -ret : ret; }
Jacek
* On Thu, 14 Apr 2005, Jacek Caban wrote:
Saulius Krasuckas wrote:
Is someone working on any atoi() implementation to use it in Winetest now?
Here you have:
It not me who doesn't have it. It's a question: is anyone prepared patch to solve this problem. Just some etiquette, right?
And the second question is: should it go to the "include/wine/test.h" or some separate header like a "include/wine/strings.h".
int atoi(char* buf) { int ret = 0; char *c = buf;
if(*c == '-') c++; while(*c) {
...
}
BTW, Jacek, your implementation lacks ability to skip leading white-spaces which isn't a case for __atoi64() and StrToInt() already implemented by Wine. ;-P
Saulius Krasuckas wrote:
- On Thu, 14 Apr 2005, Jacek Caban wrote:
Saulius Krasuckas wrote:
Is someone working on any atoi() implementation to use it in Winetest now?
Here you have:
It not me who doesn't have it. It's a question: is anyone prepared patch to solve this problem. Just some etiquette, right?
Ok, sorry, it wasn't a good answer. I don't think anyone is working on this as I didn't see any patch on wine-patches.
And the second question is: should it go to the "include/wine/test.h" or some separate header like a "include/wine/strings.h".
wine/test.h doesn't seems to me to be a good place for it. Also, as it's used only in tests, wine/strings.h doesn't need this. I think the best place is the source of the test.
int atoi(char* buf) { int ret = 0; char *c = buf;
if(*c == '-') c++;
while(*c) {
...
}
BTW, Jacek, your implementation lacks ability to skip leading white-spaces which isn't a case for __atoi64() and StrToInt() already implemented by Wine. ;-P
Yeah, you're right. It was just a half-minute exercise:)
Jacek
Hi guys,
On Thursday 14 Apr 2005 20:04, Saulius Krasuckas wrote:
- On Thu, 14 Apr 2005, Jacek Caban wrote:
Saulius Krasuckas wrote:
Is someone working on any atoi() implementation [...]
Here you have:
It not me who doesn't have it. It's a question: is anyone prepared patch to solve this problem. Just some etiquette, right?
Sure.
AFAIK, no one is working on it: up to this point, I certainly hadn't.
And the second question is: should it go to the "include/wine/test.h" or some separate header like a "include/wine/strings.h".
I think really we want a separate module that can be linked in as part of the build process. I've always thought (albeit secretly) that having functions inside include/wine/test.h is a bit of a hack.
int atoi(char* buf)
[...]
BTW, Jacek, your implementation lacks ability to skip leading white-spaces which isn't a case for __atoi64() and StrToInt() already implemented by Wine. ;-P
Also: I wouldn't call the function atoi() -- it would only cause confusion. Although I must admit calling it winetest_atoi() is a bit of a mouthful.
'fraid your code also doesn't handle text (of any type) after the numbers; c.f. http://www.astro.gla.ac.uk/users/paulm/test_atoi.c
HTH,
Paul.
* On Thu, 14 Apr 2005, Jacek Caban wrote:
*Saulius Krasuckas wrote:
And the second question is: should it go to the "include/wine/test.h" or some separate header like a "include/wine/strings.h".
wine/test.h doesn't seems to me to be a good place for it. Also, as it's used only in tests, wine/strings.h doesn't need this. I think the best place is the source of the test.
* On Thu, 14 Apr 2005, Paul Millar wrote:
I think really we want a separate module that can be linked in as part of the build process. I've always thought (albeit secretly) that having functions inside include/wine/test.h is a bit of a hack.
So I see two ways to solve this:
1, writing winetest_atoi() inside a separate file (lets say atoi.c) and duplicating it across some parts of the Winetest (mlang, ole32).
2, linking dinamycally these Winetest binaries to shlwapi.dll, which implements StrToIntA() already:
| [s2@katleriai wine]$ grep -B15 -A1 WINAPI.*StrToIntA dlls/shlwapi/string.c | /************************************************************************* | * StrToIntA [SHLWAPI.@] | * | * Read a signed integer from a string. | * | * PARAMS | * lpszStr [I] String to read integer from | * | * RETURNS | * The signed integer value represented by the string, or 0 if no integer is | * present. | * | * NOTES | * No leading space is allowed before the number, although a leading '-' is. | */ | int WINAPI StrToIntA(LPCSTR lpszStr) | {
Is the latter way acceptable, what does the crew think?
'fraid your code also doesn't handle text (of any type) after the numbers; c.f. http://www.astro.gla.ac.uk/users/paulm/test_atoi.c
Thanks for the test suite, Paul.
But how come, not all Winetest parts misses this import (NTDLL.DLL:atoi)? Given the code:
| [s2@katleriai wine]$ grep -A16 int.*main( include/wine/test.h | int main( int argc, char **argv ) | { | char *p; | | setvbuf (stdout, NULL, _IONBF, 0); | | winetest_argc = argc; | winetest_argv = argv; | | if ((p = getenv( "WINETEST_PLATFORM" ))) winetest_platform = p; | if ((p = getenv( "WINETEST_DEBUG" ))) winetest_debug = atoi(p); | if ((p = getenv( "WINETEST_INTERACTIVE" ))) winetest_interactive = atoi(p); | if ((p = getenv( "WINETEST_REPORT_SUCCESS"))) report_success = atoi(p); | if (!argv[1]) usage( argv[0] ); | | return run_test(argv[1]); | }
why isn't miss happening in every Winetest part?
-
Ferenc Wagner -
Jacek Caban -
Paul Millar -
Paul Millar -
Paul Vriens -
Saulius Krasuckas -
Stefan Leichter