calling *W functions in wt (Was: dlls/shell32/shfldr_desktop.c)
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.c12 Aug 2005 10:33:37 - 1.29
+++ dlls/shell32/tests/shlfolder.c13 Aug 2005 18:49:59 -
...
+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
Re: calling *W functions in wt (Was: dlls/shell32/shfldr_desktop.c)
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/
RE: calling *W functions in wt (Was: dlls/shell32/shfldr_desktop.c)
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.
