calling *W functions in wt (Was: dlls/shell32/shfldr_desktop.c)

[Saulius Krasuckas]

Hello Ge and especially unicoders: 
Alexandre, Dimi, Dmitry, Rob, Shachar, Troy and others.

I am not sure of how should be file operations implemented in winetest:

* On Sat, 13 Aug 2005, Ge van Geldorp wrote:
> --- dlls/shell32/tests/shlfolder.c	12 Aug 2005 10:33:37 -0000	1.29
> +++ dlls/shell32/tests/shlfolder.c	13 Aug 2005 18:49:59 -0000

...
> +    PathAddBackslashW(wszFileName);
> +    lstrcatW(wszFileName, wszTestFile);
> +    hTestFile = CreateFileW(wszFileName, GENERIC_WRITE, 0, NULL, CREATE_NEW, 0, NULL);
> +    ok(hTestFile != INVALID_HANDLE_VALUE, "CreateFileW failed! Last error: %08lx\n", GetLastError());
> +    if (hTestFile == INVALID_HANDLE_VALUE) {
> +        IShellFolder_Release(psfDesktop);
> +        return;
> +    }
> +    CloseHandle(hTestFile);
> +
> +    hr = IShellFolder_ParseDisplayName(psfDesktop, NULL, NULL, wszTestFile, NULL, &pidlTestFile, NULL);
> +    ok (SUCCEEDED(hr), "Desktop's ParseDisplayName failed to parse filename hr = %08lx\n", hr);
> +    if (FAILED(hr)) {
> +        IShellFolder_Release(psfDesktop);
> +        DeleteFileW(wszFileName);
> +        IMalloc_Free(ppM, pidlTestFile);
> +        return;
> +    }

*FileW and *DirectoryW functions fail on every win9x box as they are 
unimplemented here. They succeed only when app is linked to MS Layer for 
Unicode (MSLU) and MSLU is installed. [1]

I was trying to replace every failing unicode function with its ascii 
counterpart in one of the wt files [2], but that looked ugly to me.

Maybe it would be really nice and possible to link wt to unicows.lib on 
windows.  In this case we need a corresponding static lib in Wine too, 
right?  It probably will be "empty" because UNICOWS.DLL shouldn't be 
loaded as Wine doesn't lack implementation of mentioned functions.  
Though, I have no guess if this could be done easily.

What could be a clean and acceptable solution?  Your comments, please.


[1] http://msdn.microsoft.com/msdnmag/issues/01/10/MSLU/default.aspx
[2] http://www.winehq.org/hypermail/wine-patches/2005/08/0267.html

[Shachar Shemesh]

Saulius Krasuckas wrote:
> *FileW and *DirectoryW functions fail on every win9x box as they are 
> unimplemented here.

Makes sense.
> They succeed only when app is linked to MS Layer for 
> Unicode (MSLU) and MSLU is installed. [1]

A royal pain.
> I was trying to replace every failing unicode function with its ascii 
> counterpart in one of the wt files [2], but that looked ugly to me.
>
> Maybe it would be really nice and possible to link wt to unicows.lib on 
> windows.  In this case we need a corresponding static lib in Wine too, 
> right?  It probably will be "empty" because UNICOWS.DLL shouldn't be 
> loaded as Wine doesn't lack implementation of mentioned functions.  
> Though, I have no guess if this could be done easily.

Unicows is a pain. First of all, in order to link with it, you will have 
to remove all standard links (kernel, gdi, advapi, etc), put unicows.lib 
at the beginning, and then put all standard library links again. Unicows 
takes over all of the function calls, and on NT and above just redirects 
them to the usual places. On Windows 98 it does ugly simulations of the 
actual original call.

What I am most afraid of, if using Unicows, is that we will be 
destroying the validity of the tests. The main question, I guess, is 
whether these are Unicode tests (i.e. - tests meant to find out whether 
the Unicode functions are working correctly), or whether these are 
unrelated tests that merely use the Unicode interface.

As for defining unicows.lib - we could do that, sure. We could either 
export everything there (Unicows.dll today is merely a redirection to 
the other functions), or we could make it a lib exporting nothing. The 
first is truer to what the real unicows.dll does (not 100% the same 
still, thankfully), but the second would probably work better. I would 
really prefer it if unicows.dll was only ever referenced by PE programs 
compiled on Windows.
> What could be a clean and acceptable solution?  Your comments, please.

The these are Unicode tests, use the Unicode interface. If these are 
just file system tests, I suggest you use the TCHAR functions. In other 
words, define your buffers as TCHAR buffer[] (rather than char or 
wchar), and call the functions without any prefix (neither W nor A). 
When compiling under NT, define a compiler variable "UNICODE", which 
will map TCHAR to WCHAR.

Now, I know that Wine code is forbidden from using the non-suffixed 
calls, but the wine tests are not Wine code, they are winelib 
applications. I don't think there is any problem in using these 
functions there. We could even run the tests both in ANSI and in Unicode 
mode, to compare results.

          Shachar

-- 
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/

[Ge van Geldorp]

> From: Saulius Krasuckas
>
> Hello Ge and especially unicoders: 
> Alexandre, Dimi, Dmitry, Rob, Shachar, Troy and others.
>
> I am not sure of how should be file operations implemented in 
> winetest:
>
> *FileW and *DirectoryW functions fail on every win9x box as 
> they are unimplemented here. They succeed only when app is 
> linked to MS Layer for Unicode (MSLU) and MSLU is installed. [1]

Yeah, I see your point. I just followed the existing stuff in there, which
was all Unicode. For routines which implement the Ansi function by calling
the Unicode function with appropriate conversions, I guess it would be
better to test the the Ansi function, since this implicitly tests the
Unicode function too. Then again, this would make the test depend on
internals of the functions, not good. So the only solution seems to be to
test functions which have Ansi and Unicode implementations both ways (which
is kind of boring to write) on NT and skip the Unicode tests on Win9x.
Difficult stuff. I guess it's not an option to drop Win9x compatibility in
Wine <g>.

Ge van Geldorp.