Re: shell32: conformance tests for unicode filenames and fix a bug forfile deletion (try 2)
"Nigel Liang" ncliang@gmail.com wrote:
+static const WCHAR UNICODE_PATH[] = {'c',':','\','w',0x00ef,0x00f1,0x00eb,
- 't',0x00e8,'s','t','\0','\0'}; /* "c:\winetest" */
The name above is definitely not "c:\winetest", also if you need a double termination '\0' state it specifically.
+static int IsWin9x(void) +{
- OSVERSIONINFO winver;
- GetVersionEx(&winver);
- return winver.dwPlatformId==VER_PLATFORM_WIN32_WINDOWS;
+}
(GetVersion() & 0x80000000) is much shorter way to detect win9x, but if you need to test whether the platform supports unicode that's wrong, have a look at other tests how it's done there.
On 6/7/07, Dmitry Timoshkov dmitry@codeweavers.com wrote:
"Nigel Liang" ncliang@gmail.com wrote:
+static const WCHAR UNICODE_PATH[] = {'c',':','\','w',0x00ef,0x00f1,0x00eb,
- 't',0x00e8,'s','t','\0','\0'}; /* "c:\winetest" */
The name above is definitely not "c:\winetest", also if you need a double termination '\0' state it specifically.
Yep, you are right, it is actually "c:\wïñëtèst". I will fix it in the next try.
+static int IsWin9x(void) +{
- OSVERSIONINFO winver;
- GetVersionEx(&winver);
- return winver.dwPlatformId==VER_PLATFORM_WIN32_WINDOWS;
+}
(GetVersion() & 0x80000000) is much shorter way to detect win9x, but if you need to test whether the platform supports unicode that's wrong, have a look at other tests how it's done there.
I see that the way it is being done in gdi32/tests/font.c is to look for functions that exist only on Win2k or later, is that the right way to do it? Or is there another place that I should be looking?
Thanks, -Nigel
"Nigel Liang" ncliang@gmail.com wrote:
+static const WCHAR UNICODE_PATH[] = {'c',':','\','w',0x00ef,0x00f1,0x00eb,
- 't',0x00e8,'s','t','\0','\0'}; /* "c:\winetest" */
The name above is definitely not "c:\winetest", also if you need a double termination '\0' state it specifically.
Yep, you are right, it is actually "c:\wïñëtèst". I will fix it in the next try.
That won't work. The actual unicode characters have different codes. Personally I don't see why you need non-acsii characters to test unicode APIs.
(GetVersion() & 0x80000000) is much shorter way to detect win9x, but if you need to test whether the platform supports unicode that's wrong, have a look at other tests how it's done there.
I see that the way it is being done in gdi32/tests/font.c is to look for functions that exist only on Win2k or later, is that the right way to do it? Or is there another place that I should be looking?
You have to check actual functionality, not presence of particular APIs, check for instance user32 tests for is_win9x/isWin9x.
Dmitry Timoshkov wrote:
"Nigel Liang" ncliang@gmail.com wrote:
+static const WCHAR UNICODE_PATH[] =
{'c',':','\','w',0x00ef,0x00f1,0x00eb,
- 't',0x00e8,'s','t','\0','\0'}; /* "c:\winetest" */
The name above is definitely not "c:\winetest", also if you need a
double
termination '\0' state it specifically.
Yep, you are right, it is actually "c:\wïñëtèst". I will fix it in the next try.
That won't work. The actual unicode characters have different codes. Personally I don't see why you need non-acsii characters to test unicode APIs.
(GetVersion() & 0x80000000) is much shorter way to detect win9x, but if you need to test whether the platform supports unicode that's wrong, have a look at other tests how it's done there.
I see that the way it is being done in gdi32/tests/font.c is to look for functions that exist only on Win2k or later, is that the right way to do it? Or is there another place that I should be looking?
You have to check actual functionality, not presence of particular APIs, check for instance user32 tests for is_win9x/isWin9x.
Hi,
Some testing on win98 shows that SHCreateDirectoryExW (as well as SHCreateDirectoryExA but that's already tested for in those tests) is not present on win98.
So just moving your:
+ /* Create directory with unicode filename */ + if(!pSHCreateDirectoryExW) + { + trace("skipping SHCreateDirectoryExW tests\n"); + return; + }
to the top of you're test will do the trick in this particular case. Btw. use skip instead of trace for the above.
Cheers,
Paul.
Paul Vriens wrote:
Dmitry Timoshkov wrote:
"Nigel Liang" ncliang@gmail.com wrote:
+static const WCHAR UNICODE_PATH[] =
{'c',':','\','w',0x00ef,0x00f1,0x00eb,
- 't',0x00e8,'s','t','\0','\0'}; /* "c:\winetest" */
The name above is definitely not "c:\winetest", also if you need a
double
termination '\0' state it specifically.
Yep, you are right, it is actually "c:\wïñëtèst". I will fix it in the next try.
That won't work. The actual unicode characters have different codes. Personally I don't see why you need non-acsii characters to test unicode APIs.
(GetVersion() & 0x80000000) is much shorter way to detect win9x, but if you need to test whether the platform supports unicode that's
wrong,
have a look at other tests how it's done there.
I see that the way it is being done in gdi32/tests/font.c is to look for functions that exist only on Win2k or later, is that the right way to do it? Or is there another place that I should be looking?
You have to check actual functionality, not presence of particular APIs, check for instance user32 tests for is_win9x/isWin9x.
Hi,
Some testing on win98 shows that SHCreateDirectoryExW (as well as SHCreateDirectoryExA but that's already tested for in those tests) is not present on win98.
So just moving your:
- /* Create directory with unicode filename */
- if(!pSHCreateDirectoryExW)
- {
trace("skipping SHCreateDirectoryExW tests\n");return;- }
to the top of you're test will do the trick in this particular case. Btw. use skip instead of trace for the above.
Cheers,
Paul.
Just saw Dmitry's comment. Another thing you can check is the lasterror (GetLastError()) as some of the W-calls are present but will return ERROR_CALL_NOT_IMPLEMENTED when asked for last error.
Cheers,
Paul.
Yep, you are right, it is actually "c:\wïñëtèst". I will fix it in the next try.
That won't work. The actual unicode characters have different codes. Personally I don't see why you need non-acsii characters to test unicode APIs.
In this case, the non-ascii characters are necesary to expose the bug since the bug is enclosed in -- snip -- if (*c<=0x20 || *c>=0x7f || strchr(unsafechars, *c)) ... -- snip -- Regular ascii chars will not enter the buggy block.
to the top of you're test will do the trick in this particular case. Btw. use skip instead of trace for the above.
Cheers,
Paul.
Just saw Dmitry's comment. Another thing you can check is the lasterror (GetLastError()) as some of the W-calls are present but will return ERROR_CALL_NOT_IMPLEMENTED when asked for last error.
Thanks, I see how it is being done in user32 tests. I'll change the code to check for ERROR_CALL_NOT_IMPLEMENTED after making a W-call.
-
Dmitry Timoshkov -
Nigel Liang -
Paul Vriens