August 2005 - Wine-Devel - list.winehq.org

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

by 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.

Aug. 15, 2005

RE: dlls/shell32/pidl.c

by Ge van Geldorp

> From: Michael Jung > > SHBindToParent does not allocate a > new PIDL for pidlLast, but returns a pointer to right > location in pidl. This means you should not free it. > There's still the problem that the shell folder isn't > released in failure cases. > > Sorry, I didn't realize this. I feel a bit silly for not catching it either. MSDN is very clear about this. I've resubmitted a patch which only releases the interface pointer. Gé van Geldorp.

Aug. 15, 2005

Re: Lostwages: howto.diff

by Andreas Mohr

Hi, On Mon, Aug 15, 2005 at 05:39:39AM -0400, Tom Wickline wrote: > On 8/15/05, Paul Vriens <Paul.Vriens(a)xs4all.nl> wrote: > > As winecfg is currently THE tool why not refer to this (and maybe also to Winetools) this way more > > and more people will use it (and make it better?). > > for new versions of Wine winecfg is the default tool to setup/edit a setup. > So I figured most people would use it in new versions. There is the > possibility even probability new users won't know about winecfg... I > was just recommending WineTools for people still using older versions > of Wine. I'm sure the WineTools guys will fix there nifty tool to > comply with the changes that have taken place. And I will be editing > this page again to tell people to choose the front end of there > choice. > > So do you think I should say if you use a version of Wine from > 20050628 forward we recommend that you use winecfg, and for versions > older than 20050628 use WineTools? I'd do it like that. winecfg can make use of some good testing, so we should "trick" people into using it... Just try to make sure that people won't get the impression that WineTools is simply a wine configuration tool, just like winecfg. It's a bit more than that, with its extension package installation (MSI, ODBC, IE, ...) and installation entries for common well-tested applications. Andreas

Aug. 15, 2005

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

by 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/

Aug. 15, 2005

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

by 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

Aug. 15, 2005

Re: dlls/shell32/pidl.c

by Michael Jung

Hi Ge, On Saturday 13 August 2005 20:55, Ge van Geldorp wrote: > dwAttributes = SFGAO_FILESYSTEM; > hr = IShellFolder_GetAttributesOf(psfFolder, 1, &pidlLast, > &dwAttributes); - if (FAILED(hr) || !(dwAttributes & SFGAO_FILESYSTEM)) > return FALSE; + if (FAILED(hr) || !(dwAttributes & SFGAO_FILESYSTEM)) { > + IShellFolder_Release(psfFolder); > + ILFree((LPITEMIDLIST) pidlLast); > + return FALSE; > + } > I had another look at this after realising that Alexandre did'nt apply the patch. SHBindToParent does not allocate a new PIDL for pidlLast, but returns a pointer to right location in pidl. This means you should not free it. There's still the problem that the shell folder isn't released in failure cases. Sorry, I didn't realize this. Once again I'm impressed that Alexandre always catches those things. Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

Aug. 15, 2005

Re: Lostwages: howto.diff

by Tom Wickline

On 8/15/05, Paul Vriens <Paul.Vriens(a)xs4all.nl> wrote: > As winecfg is currently THE tool why not refer to this (and maybe also to Winetools) this way more > and more people will use it (and make it better?). for new versions of Wine winecfg is the default tool to setup/edit a setup. So I figured most people would use it in new versions. There is the possibility even probability new users won't know about winecfg... I was just recommending WineTools for people still using older versions of Wine. I'm sure the WineTools guys will fix there nifty tool to comply with the changes that have taken place. And I will be editing this page again to tell people to choose the front end of there choice. So do you think I should say if you use a version of Wine from 20050628 forward we recommend that you use winecfg, and for versions older than 20050628 use WineTools? Tom > > Cheers, > > Paul. > > >

Aug. 15, 2005

Re: Lostwages: howto.diff

by Paul Vriens

On Mon, 2005-08-15 at 08:44, Tom Wickline wrote: > Hello All, > > We have moved to winecfg...... > > Tom > > Changelog: > spelling fix, doc update Hi Tom, you're patch shows: -<p>Wine is currently in a transitionary phase. We are working on replacing the -cryptic configuration file with an easy to use graphical utility called winecfg. -In the meantime, however, we recommend that you use a handy program called +<p>If your using an old version of Wine we recommend that you use a handy program called As winecfg is currently THE tool why not refer to this (and maybe also to Winetools) this way more and more people will use it (and make it better?). Cheers, Paul.

Aug. 15, 2005

Re: Frequent and annoying Wine bug

by Robbert Xerox

Hi, late response, been on holiday :). The patch from francios gougetdoesn't fix the error. I dug a little deeper into this:I had a knoppix live cd lying around and there bug is not present. A program like Neatimage (www.neatimage.com) startsup just fine there. I also did some tracing to see where the difference is. I'm quite noobish in this so correct me plz if i'm wrong: On knoppix running neatimage fine i see this: 0009:Ret user32.LoadStringA() retval=0000001b ret=00527b86 0009:Call kernel32.RaiseException(0eedfade,00000001,00000007,4067f930) ret=004aefac 0009:Call ntdll.RtlRaiseException(4067f7d8) ret=404a5393 fs=1007 eax=4067f7d8 ebx=40569244 ecx=00000000 edx=00000018 esi=4067f94c edi=4067f808 ebp=4067f834 esp=4067f7d8 ds=002b es=002b gs=0000 flags=00200216 trace:seh:EXC_RtlRaiseException code=eedfade flags=1 addr=0x404a5300 trace:seh:EXC_RtlRaiseException info[0]=004aefac trace:seh:EXC_RtlRaiseException info[1]=411d3068 trace:seh:EXC_RtlRaiseException info[2]=411d2fb0 trace:seh:EXC_RtlRaiseException info[3]=411d3058 trace:seh:EXC_RtlRaiseException info[4]=4067f974 trace:seh:EXC_RtlRaiseException info[5]=4067f964 trace:seh:EXC_RtlRaiseException info[6]=4067f94c trace:seh:EXC_RtlRaiseException eax=4067f7d8 ebx=40569244 ecx=00000000 edx=00000018 esi=4067f94c edi=4067f808 trace:seh:EXC_RtlRaiseException ebp=4067f834 esp=4067f7d8 cs=0023 ds=002b es=002b fs=1007 gs=0000 flags=00200216 trace:seh:EXC_CallHandler calling handler at 0x538243 code=eedfade flags=1 0009:Call ntdll.RtlUnwind(4067f990,0053916b,4067f7d8,00000000) ret=0053916b fs=1007 eax=4067f990 ebx=4067f7d8 ecx=00549d68 edx=4067f7d8 esi=0000001c edi=4067f7d8 ebp=4067f0a4 esp=4067f040 ds=002b es=002b gs=0000 flags=00200206 trace:seh:EXC_RtlUnwind code=eedfade flags=3 trace:seh:EXC_CallHandler calling handler at 0x538243 code=eedfade flags=3 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x401ae2c0 code=eedfade flags=3 trace:seh:EXC_CallHandler handler returned 1 0009:Ret ntdll.RtlUnwind() retval=00000000 ret=0053916b fs=1007 eax=00000000 ebx=4067f7d8 ecx=00549d68 edx=4067f7d8 esi=0000001c edi=4067f7d8 ebp=4067f0a4 esp=4067f040 ds=002b es=002b gs=0000 flags=00200206 0009:Call advapi32.RegSetValueExA(0000005c,411d3058 "StartCount",00000000,00000004,4067f97c,00000004) ret=004aef22 Looks to me as if an exception is thrown, wine is handling the exception and the program continues fine On my fc3 computer i see this: 000b:Ret user32.LoadStringA() retval=0000001b ret=00527b86 000b:Call kernel32.RaiseException(0eedfade,00000001,00000007,7fa9f93c) ret=004aefac 000b:Call ntdll.RtlRaiseException(7fa9f824) ret=7fcfe544 fs=003b eax=7fcec305 ebx=7fd5bacc ecx=00000000 edx=0eedfade esi=7fa9f958 edi=7fa9f854 ebp=7fa9f880 esp=7fa9f824 ds=007b es=007b gs=0033 flags=00200212 trace:seh:__regs_RtlRaiseException code=eedfade flags=1 addr=0x7fcfe4e0 trace:seh:__regs_RtlRaiseException info[0]=004aefac trace:seh:__regs_RtlRaiseException info[1]=7e4c32f4 trace:seh:__regs_RtlRaiseException info[2]=7e4c323c trace:seh:__regs_RtlRaiseException info[3]=7e4c32e4 trace:seh:__regs_RtlRaiseException info[4]=7fa9f980 trace:seh:__regs_RtlRaiseException info[5]=7fa9f970 trace:seh:__regs_RtlRaiseException info[6]=7fa9f958 trace:seh:__regs_RtlRaiseException eax=7fcec305 ebx=7fd5bacc ecx=00000000 edx=0eedfade esi=7fa9f958 edi=7fa9f854 trace:seh:__regs_RtlRaiseException ebp=7fa9f880 esp=7fa9f824 cs=0073 ds=007b es=007b fs=003b gs=0033 flags=00200212 trace:seh:EXC_CallHandler calling handler at 0x538243 code=eedfade flags=1 000b:Call kernel32.GetModuleFileNameA(00000000,7fa9f0c8,00000080) ret=00541424 000b:Call ntdll.RtlAllocateHeap(7fdb0000,00000000,00000100) ret=7fd06d22 000b:Ret ntdll.RtlAllocateHeap() retval=7fdef278 ret=7fd06d22 000b:Call ntdll.LdrLockLoaderLock(00000000,00000000,7fa9efdc) ret=7fd1638f 000b:Ret ntdll.LdrLockLoaderLock() retval=00000000 ret=7fd1638f 000b:Call ntdll.LdrFindEntryForAddress(00400000,7fa9efd8) ret=7fd163a1 000b:Ret ntdll.LdrFindEntryForAddress() retval=00000000 ret=7fd163a1 000b:Call ntdll.LdrUnlockLoaderLock(00000000,0000000b) ret=7fd163e5 000b:Ret ntdll.LdrUnlockLoaderLock() retval=00000000 ret=7fd163e5 000b:Call ntdll.RtlUnicodeToMultiByteN(7fa9f0c8,00000080,7fa9efdc,7fdef278,00000052) ret=7fcff857 000b:Ret ntdll.RtlUnicodeToMultiByteN() retval=00000000 ret=7fcff857 000b:Call ntdll.RtlFreeHeap(7fdb0000,00000000,7fdef278) ret=7fd06d4a 000b:Ret ntdll.RtlFreeHeap() retval=00000001 ret=7fd06d4a 000b:Ret kernel32.GetModuleFileNameA() retval=00000029 ret=00541424 000b:Call kernel32.GetVersion() ret=005413a7 000b:Call ntdll.RtlGetVersion(7fa9eef8) ret=7fd3d280 000b:Ret ntdll.RtlGetVersion() retval=00000000 ret=7fd3d280 000b:Ret kernel32.GetVersion() retval=c0000a04 ret=005413a7 000b:Call kernel32.GetCurrentThreadId() ret=005413c6 000b:Ret kernel32.GetCurrentThreadId() retval=0000000b ret=005413c6 000b:Call user32.EnumThreadWindows(0000000b,00541388,7fa9f0b8) ret=005413cc 000b:Call kernel32.94(7f8909a0) ret=7f84adbc 000b:Ret kernel32.94() retval=0000000b ret=7f84adbc 000b:Call ntdll.RtlAllocateHeap(7fdb0000,00000000,00000080) ret=7f84b762 000b:Ret ntdll.RtlAllocateHeap() retval=7fdef278 ret=7f84b762 000b:Call ntdll.RtlFreeHeap(7fdb0000,00000000,7fdef278) ret=7f8502e6 000b:Ret ntdll.RtlFreeHeap() retval=00000001 ret=7f8502e6 000b:Ret user32.EnumThreadWindows() retval=00000001 ret=005413cc 000b:Call user32.MessageBoxA(00000000,0057ff94 "Assertion failed: !\"bogus context in _ExceptionHandler()\", file xx.cpp, line 3072",7fa9f0e4 "NeatImage.exe",00012010) ret=0054146f Looks to me as if an exception is thrown, now the program itself tries to handle the exception, and the program exits with a window abnormal termination. My question really is why the exception is handled in two different ways, what could be the cause of this? If this helps: one guy on the buglist got this error after upgrading from Fedora Core 1 with vanilla kernel 2.6.10 (which worked fine) to Fedora Core 3 with kernel 2.6.10-1.766_FC3 --- Francois Gouget <fgouget(a)codeweavers.com> wrote: > Hi, > > Robbert Xerox wrote: > > Hi , i know this is not a wine-bug channel, but > this > > bug is affecting quite some apps, and seems to > affect > > more and more ... > > At least five apps from wine-bug mailinglist throw > up > > an exception which either reads: "Assertion Failed > > !bogus context in Local_Unwind()" or "in > > Exception_Handler". > > I have seen a bug pretty much like this in an > application and here's > what Mike Hearn had to say about it: > > > There were actually two bugs here: > > > > * Despite what the unit tests indicate, > IShellFolder::BindToObject > > with a NULL pidl can sometimes work. I guess it > depends on the exact > > class implementation. In this case I fixed it > with an application > > specific hack, we just return the desktop folder > (it should probably > > return an addreffed This). > > > > * The app apparently relies on an old Win98 > specific bug where > > SFGAO_FILESYSTEM is set on My Computer. This bug > is documented here: > > > > > http://msdn.microsoft.com/msdnmag/issues/05/06/CAtWork/default.aspx > > > > at the bottom. But it's not present in Windows > NT, as our unit tests > > actually prove (we should pay more attention to > 98/NT differences!!): > > > > > http://test.winehq.com/data/200506231000/98_PaulVriensW98SEFull/shell32:shl… > > > > It can be fixed with the patch to wine.inf, if > you then do "make > > install" in the tools directory and re-run > wineprefixcreate. > > I've attached the patch so you can try it. That's > not code I can comment > on but maybe Mike will when he's back from his > not-quite-vacations. > > -- > Francois Gouget > fgouget(a)codeweavers.com > > > Index: dlls/shell32/shlfolder.c > =================================================================== > RCS file: /var/cvs/wine/dlls/shell32/shlfolder.c,v > retrieving revision 1.104 > diff -u -p -r1.104 shlfolder.c > --- dlls/shell32/shlfolder.c 20 Jul 2005 10:29:05 > -0000 1.104 > +++ dlls/shell32/shlfolder.c 28 Jul 2005 21:33:11 > -0000 > @@ -272,6 +272,15 @@ HRESULT SHELL32_BindToChild > (LPCITEMIDLI > HRESULT hr; > LPITEMIDLIST pidlChild; > > + TRACE("pidlRoot=%p, pathRoot=%s, > pidlComplete=%p, riid=%s, ppvOut=%p\n", > + pidlRoot, pathRoot, pidlComplete, > debugstr_guid(riid), ppvOut); > + > + if (!pidlComplete) > + { > + SHELL32_CoCreateInitSF(_ILCreateDesktop(), > pathRoot, NULL, &CLSID_ShellDesktop, riid, ppvOut); > + return S_OK; > + } > + > if (!pidlRoot || !ppvOut || !pidlComplete || > !pidlComplete->mkid.cb) > return E_INVALIDARG; > > Index: tools/wine.inf > =================================================================== > RCS file: /var/cvs/wine/tools/wine.inf,v > retrieving revision 1.37 > diff -u -p -r1.37 wine.inf > --- tools/wine.inf 27 Jul 2005 15:42:40 -0000 1.37 > +++ tools/wine.inf 28 Jul 2005 21:30:35 -0000 > @@ -100,6 +100,8 @@ > HKCR,TypeLib\{00020430-0000-0000-C000-00 > > HKCR,TypeLib\{00020430-0000-0000-C000-000000000046}\2.0,,,"OLE > Automation" > > HKCR,TypeLib\{00020430-0000-0000-C000-000000000046}\2.0\0\win32,,,"stdole2.tlb" > > HKCR,TypeLib\{00020430-0000-0000-C000-000000000046}\2.0\FLAGS,,,"0" > +; FIXME: this is to emulate a Windows 98 bug which > is gone in NT: very few apps need it > +HKCR,CLSID\{20d04fe0-3aea-1069-a2d8-08002b30309d}\ShellFolder,"Attributes",0x10001,f0000154 > > [ControlClass] > > HKLM,System\CurrentControlSet\Control\Class\{4d36e978-e325-11ce-bfc1-08002be10318},,,"Ports > (COM & LPT)" > ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

Aug. 15, 2005

Re: PATCH: GlobalAddAtomA check for invalid ptr

by Marcus Meissner

On Sun, Aug 14, 2005 at 10:27:20PM +0200, Felix Nawothnig wrote: > Marcus Meissner wrote: > >>Yes, but please don't use the IsBad* functions, use a proper exception > >>handler. > >Next try, is this what you imagined. > > The reason for using an exception handler is thread safety - to achieve > that you have to put it around the ATOM_AddAtomA call. Next try... Ciao, Marcus Changelog: Wrap GlobalAddAtomA() internal call with exception handler. Index: dlls/kernel/atom.c =================================================================== RCS file: /home/wine/wine/dlls/kernel/atom.c,v retrieving revision 1.8 diff -u -r1.8 atom.c --- dlls/kernel/atom.c 10 May 2005 15:15:50 -0000 1.8 +++ dlls/kernel/atom.c 15 Aug 2005 05:35:29 -0000 @@ -38,6 +38,8 @@ #include "winbase.h" #include "winerror.h" +#include "wine/exception.h" +#include "excpt.h" #include "wine/server.h" #include "wine/unicode.h" #include "kernel_private.h" @@ -48,6 +50,14 @@ #define MAX_ATOM_LEN 255 +/* filter for page-fault exceptions */ +static WINE_EXCEPTION_FILTER(page_fault) +{ + if (GetExceptionCode() == EXCEPTION_ACCESS_VIOLATION) + return EXCEPTION_EXECUTE_HANDLER; + return EXCEPTION_CONTINUE_SEARCH; +} + static struct atom_table* get_local_table(DWORD entries) { static struct atom_table* local_table; @@ -183,7 +193,14 @@ */ ATOM WINAPI GlobalAddAtomA( LPCSTR str /* [in] String to add */ ) { - return ATOM_AddAtomA( str, NULL ); + __TRY { + return ATOM_AddAtomA( str, NULL ); + } + __EXCEPT(page_fault) { + SetLastError( ERROR_INVALID_PARAMETER ); + return 0; + } + __ENDTRY }

Aug. 15, 2005