September 2002 - Wine-Devel

Re: [PATCH] winsock-test.diff
by Alexandre Julliard Sept. 5, 2002

Sept. 5, 2002

Martin Wilck <Martin.Wilck(a)Fujitsu-Siemens.com> writes: > Rationale: > - Make it easier to add new unit tests. > - Conform better to the usual wine unit testing scheme > (instead of running different tests from the same file, > run separate files testing different functionality) That's not really the usual scheme. It may look that way because we have few tests at the moment, but we can't put each test in a separate file, or we will end up with thousands of them. The right approach is to follow more or less the layout of the source files, that is if two APIs are implemented in the same source file they should be tested in the same test file; so I think the current winsock tests are OK as they are. And in any case #including .c files is strongly discouraged. -- Alexandre Julliard julliard(a)winehq.com

2 1

Tab Controls without name
by Fabian Cenedese Sept. 5, 2002

Sept. 5, 2002

Hi I found something that would be easy to fix in case it really should be fixed. Working with tab controls I have the case where I set the tab name to empty because it's too big to be shown. In the TCITEM structure I set the text pointer to NULL instead of a "". Thus Wine stopped at some point doing a strlen on a NULL pointer. Obvious. Then I checked MSDN if this is allowed or not. It always says string pointer, never is a NULL pointer a possible value. Ok, so my code is wrong, easy to change. But still (the often cited sentence): It used to work in Windows. So now I don't know if Wine should be clean (and NULL pointer in tab name is not allowed) or if it should behave as Windows (no matter what docs say) and a NULL pointer is just an empty name... bye Fabi

2 2

VersionNumber reg. key
by Ender Sept. 4, 2002

Sept. 4, 2002

Hi all, A few weeks ago I was setting up a fake-windows install, and ran across a few pieces of software that just crashed.. like the Visual Studio installer. After a little bit of investigation, I discovered these were trying to read the HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\VersionNumber key. And of course, as this is a 'required' key in Windows, there was no code to cope with failure :) At the very least this should be added to the default registry with a dummy value (oh yeah, values are like: "4.90.3000"). But my question is whether or not Wine should dynamically 'lie' about this registry key, depending what winver the current thread is running in. Thoughts? - Ender

1 0

Re: Partial implementation of NotifyRegister notifications
by Alexandre Julliard Sept. 4, 2002

Sept. 4, 2002

Joshua Thielen <thielen(a)netprince.net> writes: > I expect there to be problems with this patch (some of it is probably > a bit over my head) so eyes are requested, please! I already know that > the number and order of the segment messages (NFY_LOADSEG and FREESEG) > doesn't exactly match those sent in Windows, and I'm not totally sure > of the affect this patch will have on 16-bit memory and threading > details in wine. You should really have some kind of TOOLHELP_SendNotification function instead of calling wine_call_to_16_regs all over the place. Also the handling of segmented pointers (especially the lpstrModuleName) doesn't look right. Apart from that, it looks quite reasonable. -- Alexandre Julliard julliard(a)winehq.com

1 0

Catching MFC exception
by Fabian Cenedese Sept. 4, 2002

Sept. 4, 2002

Hi I found one of the wrong behaviours though I don't know where to solve it. For creating an ocx one can give a window title. I gave a "" to the CreateControl function. But this poses a problem to MFC, it's only prepared for valid strings or NULL pointers. That's why it generates the exception: void AFXAPI AfxThrowOleException(SCODE sc){ #ifdef _DEBUG TRACE1("Warning: constructing COleException, scode = %s.\n", AfxGetFullScodeString(sc)); #endif COleException* pException = new COleException; pException->m_sc = sc; THROW(pException); } In Windows this is caught by another function in MFC and doesn't do any harm: BOOL AFX_CDECL COleControlSite::SafeSetProperty(DISPID dwDispID, VARTYPE vtProp, ...) { va_list argList; // really only one arg, but... va_start(argList, vtProp); BOOL bSuccess; TRY { SetPropertyV(dwDispID, vtProp, argList); bSuccess = TRUE; } CATCH_ALL(e) { DELETE_EXCEPTION(e); bSuccess = FALSE; } END_CATCH_ALL va_end(argList); return bSuccess; } Now it seems that the exception handling inside (or wherever) the MFC.dll doesn't work if running in Wine or the MFC exceptions are different and the exception comes right through. I can overcome this problem by giving a valid window title but that solves it only for me. I have no idea how and if this can be solved but maybe this description gives a hint to a programmer with more insight. Thanks Fabi

2 1

Re: LsaNtStatusToWinError implementation
by Andriy Palamarchuk Sept. 4, 2002

Sept. 4, 2002

--- Andriy Palamarchuk <apa3a(a)yahoo.com> wrote: > Changelog: > Implemented LsaNtStatusToWinError, conformance > tests, added definitions of the error and status > constants, used by the function. Please ignore this patch. I just found out that I should call RtlNtStatusToDosError from this function instead of implementing the mapping myself. Andriy __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com

1 0

Wine error codes
by Sylvain Petreolle Sept. 4, 2002

Sept. 4, 2002

hi, having problem with IE 6 exiting immediately using a patched shdocvw, I would know if wine exit codes are documented somewhere ? ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

2 1

Problem with regression tests getting stuck
by Paul Millar Sept. 4, 2002

Sept. 4, 2002

Hi everyone, I've had the regression tests freeze on me again (see [1] for previous report). Sylvain has reported problems with the wininet regression tests (described in [2]). The symptoms are the same, but for me the problem is only intermittent. This time I caught the problem with gdb and obtained the following info: [...] Loaded symbols for /lib/libresolv.so.2 0x402e7744 in __libc_close () at __libc_close:-1 -1 __libc_close: No such file or directory. in __libc_close (gdb) bt #0 0x402e7744 in __libc_close () at __libc_close:-1 #1 0x400ec9a4 in __DTOR_END__ () from /home/paulm/WINE-cvs/wine/dlls/libntdll.dll.so #2 0x400b3df5 in WaitForMultipleObjectsEx (count=0, handles=0x0, wait_all=0, timeout=100, alertable=0) at ../../scheduler/synchro.c:257 #3 0x400b3b88 in Sleep (timeout=100) at ../../scheduler/synchro.c:178 #4 0x40358747 in winapi_test (flags=268435456) at tests/http.c:121 #5 0x40358b36 in func_http () at tests/http.c:184 #6 0x40358f9d in run_test (name=0xbffffc63 "http.c") at wtmain.c:244 #7 0x40357037 in __wine_exe_main () at wininet_test.exe.spec.c:133 #8 0x400aff84 in start_process () at ../../scheduler/process.c:528 #9 0x400b3f3f in call_on_thread_stack (func=0x400afd2c) at ../../scheduler/sysdeps.c:108 So, to summarise (with some extra bits of information): The problem occurs when wininet/tests/http.c is testing asynchronous HttpSendRequest(), so flags > 0. The problem is triggered at line 121 of http.c, i.e.: 120 while ((flags)&&(!goon)) 121 Sleep(100); Sleep(), in turn, just calls WaitForMultipleObjectsEx(). From scheduler/synchro.c: 176 VOID WINAPI Sleep( DWORD timeout ) 177 { 178 WaitForMultipleObjectsEx( 0, NULL, FALSE, timeout, FALSE ); 179 } WaitForMultipleObjectsEx() has problems when it gets to 257: 256 SERVER_END_REQ; 257 if (ret == STATUS_PENDING) ret = wait_reply( &cookie ); 258 if (ret != STATUS_USER_APC) break; ret is 1079729528, btw. AFAIK, __DTOR_END__ (see near bottom of stack) is the destructor for a function call in ntdll. I'm probably missing something obvious, but I don't see the connection between scheduler/synchro.c:257 and ntdll. The closest is wait_reply() (in scheduler/client.c) calls wait_reply_data (in same file), which calls NtCurrentTeb(), which is commented as an NTDLL function. But there doesn't seem to be an implementation of NtCurrentTeb in ntdll. Any ideas? Cheers, Paul. [1] http://www.winehq.com/hypermail/wine-devel/2002/08/0006.html [2] http://www.winehq.com/hypermail/wine-devel/2002/07/0386.html PS, I'll create a bugzilla in a bit. ---- Paul Millar

2 4

Re: Implements shdocvw.101
by Eric Pouech Sept. 3, 2002

Sept. 3, 2002

Sylvain Petreolle a écrit : > > Changelog: > Implements shdocvw.101, which is a call to shlwapi.PathRemoveBackslashW wouldn't a forward in the spec file be more appropriate ? 1+

2 2

Help solving Bug 434
by Rick Romero Sept. 3, 2002

Sept. 3, 2002

Hello all, I'm taking yet another look at bug 434, where a left mouse click won't release in Visual FoxPro. Alexandre applied a patch on 6/13/02 that fixed the issue for the opener of the bug, but is general issue still exists for me, I havn't heard from the submitter of the Illustrator 8 report. First question: Since the original report has been resolved, should a new report be opened? Second: I feel like the solution is pretty close, but I'm probably treading water in deep fog, FEELING like I'm getting close to shore :) The one weird thing that I can't figure out is why I can run wine --debugmsg +scroll,+event,+toolbar,+gdi,+heap /mnt/windows/DevStu dio/vfp/vfp.exe and have the button up WORK for a few clicks. If I hold the button down, then release, the issue occurs. Since the mouse issue started when input functions were moved into the wine server, it makes sense to me that there might be some issue related to synchro.c as shown below in gdb output. ------- Additional Comments From rick(a)havokmon.com 2002-08-31 21:22 ------- Ok - ivanovich(a)menta.net determined the fix for Flash 5 to be patch at: http://www.winehq.com/hypermail/wine-cvs/2002/06/0098.html from 6/14/02. This patch does not affect the mousebutton issue in Visual FoxPro, but his posts on using gdb now make sense to me.. Using Wine-20020804. wine test.exe (using vfp5test.zip - Installer works now!) - available from Bug Report Here's my output of GDB: (gdb) bt #0 0x402ddfe4 in read () from /lib/i686/libc.so.6 #1 0x40102130 in __JCR_LIST__ () from /usr/local/lib/libntdll.dll.so #2 0x400c6cac in WaitForMultipleObjectsEx (count=1095856128, handles=0x0, wait_all=0, timeout=220, alertable=0) at ../../scheduler/synchro.c:265 #3 0x400c69e1 in Sleep (timeout=220) at ../../scheduler/synchro.c:178 #4 0x10001011 in ?? () #5 0x400c704e in SYSDEPS_StartThread (teb=0x41517000) at ../../scheduler/sysdeps.c:158 (gdb) n Single stepping until exit from function read, which has no line number information. wait_reply (cookie=0x41506e58) at ../../scheduler/synchro.c:96 96 if (ret == sizeof(reply)) (gdb) n 98 if (!reply.cookie) break; /* thread got killed */ (gdb) n 99 if (reply.cookie == cookie) return reply.signaled; (gdb) n 0x400c6cac in WaitForMultipleObjectsEx (count=259, handles=0x0, wait_all=0, timeout=220, alertable=0) at ../../scheduler/synchro.c:265 265 ret = WAIT_FAILED; (gdb) n 258 if (ret != STATUS_USER_APC) break; (gdb) n 262 if (HIWORD(ret)) /* is it an error code? */ (gdb) n 267 return ret; (gdb) n 268 } (gdb) n Sleep (timeout=220) at ../../scheduler/synchro.c:179 179 } (gdb) n Here, just like ivanovich(a)menta.net's post, the gdb hangs and the wine process takes 100% cpu. If the scheduler is not working properly with FoxPro, that might explain the weird 'Slowness Solution' I described above, with extra debug info delaying the button up issue. If I ctrl-C and detach from that process, and attach to a second wine process, I get: (gdb) bt #0 0x402de024 in write () from /lib/i686/libc.so.6 #1 0x40997d48 in _XlcPublicMethods () from /usr/X11R6/lib/libX11.so.6 #2 0x4092122f in _X11TransWrite () from /usr/X11R6/lib/libX11.so.6 #3 0x40904bc2 in _XScreenOfWindow () from /usr/X11R6/lib/libX11.so.6 #4 0x40902717 in _XReply () from /usr/X11R6/lib/libX11.so.6 #5 0x408f881b in XQueryPointer () from /usr/X11R6/lib/libX11.so.6 #6 0x40893452 in TSXQueryPointer (a0=0x809e030, a1=70, a2=0x405a5cbc, a3=0x405a5cc0, a4=0x405a5cc4, a5=0x405a5cc8, a6=0x405a5ccc, a7=0x405a5cd0, a8=0x405a5cd4) at ts_xlib.c:846 #7 0x4086e1a8 in X11DRV_GetCursorPos (pos=0x405a5d20) at mouse.c:514 #8 0x406a55a8 in GetCursorPos (pt=0x8) at ../../windows/input.c:476 #9 0x10008fc7 in ?? () #10 0x101aa657 in ?? () (gdb) n Single stepping until exit from function write, which has no line number information. 0x40922050 in _X11TransGetConnectionNumber () from /usr/X11R6/lib/libX11.so.6 (gdb) n Single stepping until exit from function _X11TransGetConnectionNumber, which has no line number information. 0x4092122f in _X11TransWrite () from /usr/X11R6/lib/libX11.so.6 (gdb) n Single stepping until exit from function _X11TransWrite, which has no line number information. 0x40904bc2 in _XScreenOfWindow () from /usr/X11R6/lib/libX11.so.6 (gdb) n Single stepping until exit from function _XScreenOfWindow, which has no line number information. 0x40902717 in _XReply () from /usr/X11R6/lib/libX11.so.6 (gdb) n Single stepping until exit from function _XReply, which has no line number information. 0x408f881b in XQueryPointer () from /usr/X11R6/lib/libX11.so.6 (gdb) n Single stepping until exit from function XQueryPointer, which has no line number information. TSXQueryPointer (a0=0x809e030, a1=70, a2=0x405a5cbc, a3=0x405a5cc0, a4=0x405a5cc4, a5=0x405a5cc8, a6=0x405a5ccc, a7=0x405a5cd0, a8=0x405a5cd4) at ts_xlib.c:847 847 wine_tsx11_unlock(); (gdb) n 846 r = XQueryPointer(a0, a1, a2, a3, a4, a5, a6, a7, a8); (gdb) n 847 wine_tsx11_unlock(); (gdb) n 849 } (gdb) n X11DRV_GetCursorPos (pos=0x405a5d20) at mouse.c:518 518 update_key_state( xstate ); (gdb) n 519 TRACE("pointer at (%d,%d)\n", winX, winY ); (gdb) n 520 pos->x = winX; (gdb) n 521 pos->y = winY; (gdb) n 522 } (gdb) n 0x406a55a8 in GetCursorPos (pt=0x40887b03) at ../../windows/input.c:476 476 } (gdb) n 475 return 1; (gdb) n 476 } (gdb) n Here, just like ivanovich(a)menta.net's post, the gdb hangs and the wine process takes 100% cpu. I tried putting a while loop in synchro.c, so that it would loop until !(HIWORD(ret)), but I did something wrong: --- synchro.c line 231 int ret, cookie,testparm; struct timeval tv; testparm = 0; while (testparm == 0){ testparm = 1; if (count > MAXIMUM_WAIT_OBJECTS) ... ... if (HIWORD(ret)) /* is it an error code? */ { SetLastError( RtlNtStatusToDosError(ret) ); ret = WAIT_FAILED; testparm = 0; } } return ret; --- I don't know if something like that would actually work, but my last gdb step through showed testparm set to 0 before returning ret ;) - so I whatever I did, I didn't do it right. ------- End Comments From rick(a)havokmon.com 2002-08-31 21:22 ------- Any direction to take would be greatly appreciated. Thanks Rick -- -- Rick Romero IT Manager Valeo, Inc. ph: 262.695.4841 Sussex, WI. fax: 262.695.4850 Rick(a)valeoinc.com

1 0