January 2002 - Wine-devel - list.winehq.org

Re: [PATCH] Overlapped recv(), WSARecv()
by Martin Wilck 22 Jan '02

22 Jan '02

As you may see from the different email address, I am currently off work - I'll look deeper into your traces next week. Many thanks for generating them, anyway. >From a first glance, it seems that the app doesn't do overlapped recv(). (lpOverlapped & completion_func are always NULL), so there should actually be no difference (well I'm now using recvmsg() instead of recv(), and the overhead for 16 bit Winsock apps is definitely larger, but I cannot see why that should slow everything down that much). Perhaps I screwed up the blocking semantics of non-overlapped IO. Have you generated the traces under exactly the same conditions? Can you explain what exactly you did? Martin

3 7

Article about WINE on DesktopLinux.com
by Roland 22 Jan '02

22 Jan '02

Hello, I found a very interesting article about WINE there: http://www.desktoplinux.com/articles/AT5502857506.html I have to fully agree with that author, I think he is a real genius! :))) Roland

1 0

Re: Decorationless managed windows again
by Alexandre Julliard 21 Jan '02

21 Jan '02

Ove Kaaven <ovehk(a)ping.uio.no> writes: > The logic in this patch is now somewhat revised according to Alexandre's > comments. I did not make this configurable, though, thinking that if the > user's WM really is too old to support them, then he probably wouldn't > mind getting more top-level windows managed anyway... Top-level windows maybe not, but menus and tooltips with wm decorations are pretty annoying... so I applied it, but without the is_window_managed changes, we will need a better algorithm there. -- Alexandre Julliard julliard(a)winehq.com

2 4

Re: Some fixes for dumb X errors :-)
by Alexandre Julliard 21 Jan '02

21 Jan '02

Lionel Ulmer <lionel.ulmer(a)free.fr> writes: > PS for Alexandre: we once discussed how we could 'streamline' this X error > handling (ie to prevent doing the same kind of code at three different > locations in the Wine code). Did you progress on this issue or not ? Yes, here's what I came up with. Basically you have to wrap the call that might fail with X11DRV_expect_error/X11DRV_check_error. Would this work for what you need to do? Index: dlls/x11drv/x11drv_main.c =================================================================== RCS file: /opt/cvs-commit/wine/dlls/x11drv/x11drv_main.c,v retrieving revision 1.47 diff -u -r1.47 x11drv_main.c --- dlls/x11drv/x11drv_main.c 2001/11/30 23:15:32 1.47 +++ dlls/x11drv/x11drv_main.c 2002/01/21 18:58:48 @@ -63,6 +63,12 @@ static char *desktop_geometry; static XVisualInfo *desktop_vi; +static x11drv_error_callback err_callback; /* current callback for error */ +static Display *err_callback_display; /* display callback is set for */ +static void *err_callback_arg; /* error callback argument */ +static int err_callback_result; /* error callback result */ +static int (*old_error_handler)( Display *, XErrorEvent * ); + #define IS_OPTION_TRUE(ch) \ ((ch) == 'y' || (ch) == 'Y' || (ch) == 't' || (ch) == 'T' || (ch) == '1') #define IS_OPTION_FALSE(ch) \ @@ -97,12 +103,57 @@ } #endif /* NO_REENTRANT_X11 */ + +/*********************************************************************** + * X11DRV_expect_error + * + * Setup a callback function that will be called on an X error. The + * callback must return non-zero if the error is the one it expected. + * This function acquires the x11 lock; X11DRV_check_error must be + * called in all cases to release it. + */ +void X11DRV_expect_error( Display *display, x11drv_error_callback callback, void *arg ) +{ + wine_tsx11_lock(); + XSync( display, False ); + err_callback = callback; + err_callback_display = display; + err_callback_arg = arg; + err_callback_result = 0; +} + + +/*********************************************************************** + * X11DRV_check_error + * + * Check if an expected X11 error occurred; return non-zero if yes. + * Also release the x11 lock obtained in X11DRV_expect_error. + */ +int X11DRV_check_error(void) +{ + int ret = err_callback_result; + XSync( err_callback_display, False ); + err_callback = NULL; + wine_tsx11_unlock(); + return ret; +} + + /*********************************************************************** * error_handler */ -static int error_handler(Display *display, XErrorEvent *error_evt) +static int error_handler( Display *display, XErrorEvent *error_evt ) { - DebugBreak(); /* force an entry in the debugger */ + if (err_callback && display == err_callback_display) + { + if ((err_callback_result = err_callback( display, error_evt, err_callback_arg ))) + { + TRACE( "got expected error\n" ); + return 0; + } + } + if (synchronous) DebugBreak(); /* force an entry in the debugger */ + old_error_handler( display, error_evt ); return 0; } @@ -297,6 +348,7 @@ screen = DefaultScreenOfDisplay( display ); visual = DefaultVisual( display, DefaultScreen(display) ); root_window = DefaultRootWindow( display ); + old_error_handler = XSetErrorHandler( error_handler ); /* Initialize screen depth */ @@ -328,11 +380,7 @@ */ TSXOpenIM( display, NULL, NULL, NULL); - if (synchronous) - { - XSetErrorHandler( error_handler ); - XSynchronize( display, True ); - } + if (synchronous) XSynchronize( display, True ); screen_width = WidthOfScreen( screen ); screen_height = HeightOfScreen( screen ); Index: include/x11drv.h =================================================================== RCS file: /opt/cvs-commit/wine/include/x11drv.h,v retrieving revision 1.95 diff -u -r1.95 x11drv.h --- include/x11drv.h 2002/01/04 18:27:45 1.95 +++ include/x11drv.h 2002/01/21 18:59:08 @@ -391,7 +391,9 @@ extern void X11DRV_SetFocus( HWND hwnd ); extern Cursor X11DRV_GetCursor( Display *display, struct tagCURSORICONINFO *ptr ); -extern void X11DRV_expect_error( unsigned char request, unsigned char error, XID id ); +typedef int (*x11drv_error_callback)( Display *display, XErrorEvent *event, void *arg ); + +extern void X11DRV_expect_error( Display *display, x11drv_error_callback callback, void *arg ); extern int X11DRV_check_error(void); extern void X11DRV_register_window( Display *display, HWND hwnd, struct x11drv_win_data *data ); extern void X11DRV_set_iconic_state( WND *win ); -- Alexandre Julliard julliard(a)winehq.com

1 0

Some musings about DGA2 support in Wine...
by Lionel Ulmer 21 Jan '02

21 Jan '02

Hi all, After being prodded by people on #WineHQ to look at the current DGA2 problem in Wine (it it works fine for graphics, but does not accept any user input at all and needs to either kill Wine remotely or do the three finger salute to the X server), I found the following things : - the DGA2 code (in dlls/x11drv/dga2.c) used the gdi_display connection to open the framebuffer and setting-up all the input handling. But it was the thread->display connection that was used to process the events. This is a no-go as when DGA2 is entered, there is only one connection that receives the event, the one which has grabbed the frame buffer (thanks to Ove to remind me of the 'one connection per thread' thingy). - so I removed all the mentions to 'gdi_display' in dga2.c and replaced them by the current thread display and still no go (although I checked that the event processing in WaitForMultipleEvents and subsequent process_events was done on the correct display). Still no go. So I investigated a bit with a little test program : = I did first try setting up DGA2 in a separate display and then doing all the 'standard' processing on another display (that is Wine does with DGA2 set-up in the init function to test if DGA2 is available and then really use it in another thread). As my test application still was working fine, this was not the problem... = then, I saw in the logs some calls to X11DRV functions after we have entered DGA2 (some due to the DDraw stuff creating DIB sections and so on, some due to the application I think). After adding the same stuff in my test program (ie I created a window just after entering DGA2), I found that it perturbed the event processing (I still had motion events, but neither key presses nor button presses). - so, finally, just to try, I backed off my changes in dga2.c (ie I used again the gdi_display for all the set-up) and had the process_events function in windows/x11drv/event.c use gdi_display instead of data->display when DGA was used (by testing the DGAUsed variable). And now it seems to work just fine.... All this leads now to the 10 � (an Euro sign for all the people not having an iso8859-15 font :-) ) question : how to fix this 'properly' and not with the hack I just did ? The only somewhat 'clean' solution I found would be to create a display connection specifically used for DGA2 (thus we would be sure that no X calls would 'pollute' the link). And in process_events, if DGA2 is used, use this connection instead of the thread connection (we already have some DGA specific variables there, what would be one more :-)) ). After, the question would be how we are sure that it's the 'good' WaitForMultipleEvents that receives the events (if the application is multi-threaded and has multiple threads calling this function). Anyway, if people want just to play some games using DGA2, they can always use my hacky solutions I just described up there :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

2 2

Re: _UNICODE vs UNICODE
by Andriy Palamarchuk 21 Jan '02

21 Jan '02

Francois Gouget wrote: > On Fri, 18 Jan 2002, Andriy Palamarchuk wrote: > > Using macro name "UNICODE" instead of "_UNICODE" is a > > typo, right? > > No, not necessarily. Windows has both and dinput.h, > for instance, > uses UNICODE, not _UNICODE. > > But I have no idea why they have two. I did a little research and found in a few places information that UNICODE is used by Windows headers, _UNICODE is used by C-runtime/MFC headers. However I did not find official explanation of this. Some examples, including a few MSDN ones, define both. E.g. see: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wss/wss/_e… Can you tell now where we need to use which one? Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

2 1

Re: GetPrivateProfileInt*() fix
by Alexandre Julliard 21 Jan '02

21 Jan '02

Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes: > these functions were pretty much broken (overflow and signed/unsigned > behaviour), so I fixed almost every problem. Why did you add an exception handler? Do you have an app that passes garbage pointers to GetPrivateProfileInt? -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Unnecessary imports?
by Ove Kaaven 21 Jan '02

21 Jan '02

On Mon, 21 Jan 2002, Francois Gouget wrote: > Compiling Wine I noticed many warnings saying that the dlls we import > are not used. Is there any reason to still import them? I suppose it could in many cases be because someone *plan* to import stuff from there sometime later (after they've churned out some code to fill the stubs in the dll implementation with)...

3 2

Re: struct async-private - now tested and cleaned up
by Mike McCormack 21 Jan '02

21 Jan '02

Hi Martin, Each DLL should only import standard win32 api functions exported by other (lower level) DLLs. Where possible, the code should be able to be compiled and run on a windows box. (ok, that excludes kernel, gdi, user, winsock, etc). That is necessary to support dll=native linking. In theory, we should only have to implement ntdll and the device driver interfaces, then Microsoft's kernel, gdi, user, etc. would all run on top of those too. Practically, some of our low level DLLs need the wineserver interface. Your client side register_async() func should be present in all the dlls that use it because Windows has no equivilent export from NTDLL (or any other dll). Maybe you could create an inline function in a header? My guess is that WinNT implements WSARecv() and ReadFile() using something like NtReadFile(). http://www.osr.com/ntinsider/1996/native.htm Mike > On 16 Jan 2002, Alexandre Julliard wrote: > > > Also note that because of dll separation you cannot use functions like > > register_async() from winsock. If absolutely necessary they could be > > exported, but I think it would be much better to use straight server > > calls (and in theory these functions shouldn't be used from comm.c > > either). > > Hmm. I guess I don't fully understand dll separation. Are you telling me > that the scheduling mechanism for async requests shouls be implemented > separately in each DLL? If so, I could have spared my efforts to build > a "generic" interface to async requests. I'd just mention that > this would be error-prone, because different parts of wine with > equivalent functionality would need to be maintained. Note > that an app is allowed to mix ReadFile() and WSARecv() calls > for a socket (however braindead that would be). I'd assume that > in Windows there must be a hidden layer for asynchronous requests > somewhere, too, or do you think their respective code is completely > separate? ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

MapVirtualKeyExA fixme
by John Atkinson 21 Jan '02

21 Jan '02

I've been using an app that the shortcut keys don't work, I get the following messages. fixme:keyboard:MapVirtualKeyExA (17,0,0x04090409), hkl unhandled! fixme:keyboard:MapVirtualKeyExA (68,0,0x04090409), hkl unhandled! fixme:keyboard:MapVirtualKeyExA (18,0,0x04090409), hkl unhandled! fixme:keyboard:MapVirtualKeyExA (90,0,0x04090409), hkl unhandled! Does anyone know how to fix this type of problem. TIA

1 0