October 2001 - Wine-Devel - list.winehq.org

Re: Improving Wine focus handling
by Alexandre Julliard Oct. 22, 2001

Oct. 22, 2001

Jukka Heinonen <jhei(a)iki.fi> writes: > - There have recently been lots of changes in directory > wine/windows/x11drv and I'm not sure whether the changes > are over yet. Definitely not over, they are only starting ;-) > - Alexandre did mention that this fix is in his todo list, > perhaps he has already planned a better way to do this fix. Yes, I'm going to work on that as part of fixing window activation for shared handles. I'm hoping to start on it this week, so you probably don't want to spend too much time on this right now. > - Mouse clicks over non-active windows should not automatically > result into focus transfer. In these cases, Windows sends a special > message that makes certain that the window really wants to gain focus. I don't think you should change X focus on mouse clicks. That is up to the window manager to decide. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: The big winsock patch
by Gerard Patel Oct. 22, 2001

Oct. 22, 2001

At 12:57 AM 22/10/2001 -0700, you wrote: > Whoops. The patch was malformed but in such a way that it still >applied cleanly (thus fooling me). But a subtential part of winsock.h >was not getting patched. The best is to revert the previous patch and >apply this one. > I am recompiling in a separate tree right now. At least sock.c should >compile fine... Yes, it compiles. However : err:module:BUILTIN32_dlopen failed to load .so lib for builtin ws2_32.dll: /home/gerard/win/wine/dlls/libws2_32.so: undefined symbol: WSOCK32_gethostbyaddr err:module:PE_fixup_imports Module (file) ws2_32.dll (which is needed by wsock32.dll) not found err:module:load_library can't load wsock32.dll err:module:BUILTIN32_LoadLibraryExA loaded .so but dll wsock32.dll still not found Gerard

1 0

Re: The big winsock patch
by Gerard Patel Oct. 22, 2001

Oct. 22, 2001

At 08:39 PM 21/10/2001 -0700, you (Francois Gouget) wrote: > > This patch fixes the issues listed in bug #118: gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -mpreferred-stack-boundary=2 -D__WINE__ -D_REENTRANT -I/usr/X11R6/include -o sock.o sock.c In file included from ../include/winsock2.h:30, from sock.c:44: ../include/winsock.h:630:2: #endif without #if This on my stock Mandrake 8 - gcc 2.96, glibc 2.2.2 if it matters Gerard

1 0

Colour problems with latest DIB fix
by Johan Gill Oct. 21, 2001

Oct. 21, 2001

Since the big DIB fix, red and blue are exchanged in some cases, for example in the install program for The Sims. This happens in both depth 16 and depth 24. /Johan Gill, johane(a)lysator.liu.se

2 2

MCI Question -- sound problem
by raddy Oct. 21, 2001

Oct. 21, 2001

Hello guys. I've had a problem for a week already, and ive tried #winehq but they told me to suscribe to winedevel list so here i am. The problem is with sound support. Ive been able to make counter-strike (half-life game mod) run perfectly on my system, i have network support, opengl support and it all works perfectly ...still, i have no sound. (forgot to say that no sound in ANY applications i run besides this game) I have no previous windows installation, so i grabbed a system.ini file from a working windows 98 system. I also copied all mci* files from a working Windows installation in order to fix my problem but it seems it did not work. I have ALSA installed in a 2.4 kernel (soon 2.4.12). The errors the game prompts me are all about not being able to use the MCI system for playback ( i believe that means the mci wave driver for playing wav files ). Another weird thing is that THERE IS some sound while browsing the game menus (whenever i click in any menu option ) once i accept the error messages. Still, when the real thing starts its all muted. A strange thing i noticed is that my ~/.wine/config file didnt have any mci files in any of its config tags, but other people did, so i added them. using the native and builting options: "mcicda.drv" = "builtin, native" "mciseq.drv" = "builtin, native" "mciwave.drv" = "builtin, native" "mciavi.drv" = "native, builtin" "mcianim.drv" = "native, builtin" Yes, in my override tag. So, im no wine expert at all, but it seems Wine isnt using *at all* my windows 98 mci drivers located in wines c:\windows\system directory. Please, id rather need instant help, the linux gamers require gamming hours daily. Btw, ive downloaded the last source targz file from your site, and i was unable to make Winsock support work at all, ive heard of another guy that had the same problem, so i made him download the previous one and worked as it did for me too. Please check that out. Feel free to check out my cave at : http://community.core-sdi.com/~raddy/ Have a nice day, raddy .-

4 7

(WHOOPS, forgedaboudit) Re: Fix crash with certain debugmsgs
by David Elliott Oct. 21, 2001

Oct. 21, 2001

On 2001.10.21 16:41 David Elliott wrote: [snip] > I noticed that most everything else in the file uses get_info() instead > of > calling NtCurrentTeb()->debug_info directly. And since the issues was > that > debug_info was NULL and it seems the get_info tackles this by creating it > this seemed to be the proper fix. > > -Dave > Looks like someone else noticed this too, and had a slightly better fix -Dave

1 0

datacache
by giorgian Oct. 21, 2001

Oct. 21, 2001

Hi all, I'm working on a program under Wine. It works well using the Microsoft's OLE32, but we *absolutely* need it to work without it. The program crashes little after starting, inside the DataCache_GetAdvise function (in datacache.c), on the instruction: IAdviseSink_QueryInterface(this->sinkInterface, &IID_IAdviseSink, (void**)ppAdvSink); I tried to find out the problem, but I only understood that the structure this (created by the macro _ICOM_THIS_From_IViewObject2(DataCache, iface) ) is corrupted: this->sinkInterface is NULL. Can anybody help? (at least tell me if there's some explanation on the datacache.c file) thank you -- Pietro Giorgianni - Icube s.r.l. Via Ridolfi, 15 Pisa (Italy) giorgian(a)icube.it

2 1

Improving Wine focus handling
by Jukka Heinonen Oct. 21, 2001

Oct. 21, 2001

In order to make Wine ICCCM compliant and to fix focus livelock problems, it is necessary for Wine to use WM_TAKE_FOCUS protocol. This makes it necessary to stop using override-redirect for non-transient windows. I have included below a patch that does both of these things. The patch seems to work fine even with full-screen games and it does make Wine focus handling to cooperate a lot better with window managers. However, I feel reluctant to submit this patch to wine-patches, at least before I do get some feedback about the patch. Here are some notes about the patch: - Done against the latest Wine cvs tree, file wine/dlls/ntdll/debugtools.c has some bugs that might need to be fixed first, though. - There have recently been lots of changes in directory wine/windows/x11drv and I'm not sure whether the changes are over yet. - Alexandre did mention that this fix is in his todo list, perhaps he has already planned a better way to do this fix. - Menus do work but activating them makes parent window lose focus. This does not look particularly nice. - It is highly likely that every single case of Wine using XSetInputFocus breaks ICCCM compliance. These need fixing. - It might be a good idea to make X11DRV_SetFocus call EVENT_TakeFocus, since there seems to be much shared code. - Mouse clicks over non-active windows should not automatically result into focus transfer. In these cases, Windows sends a special message that makes certain that the window really wants to gain focus. However, I don't think this is very important thing to do. Index: wine/windows/x11drv/event.c =================================================================== RCS file: /home/wine/wine/windows/x11drv/event.c,v retrieving revision 1.112 diff -u -r1.112 event.c --- wine/windows/x11drv/event.c 2001/10/18 21:38:59 1.112 +++ wine/windows/x11drv/event.c 2001/10/21 12:26:07 @@ -42,6 +42,7 @@ extern Atom wmProtocols; extern Atom wmDeleteWindow; +extern Atom wmTakeFocus; extern Atom dndProtocol; extern Atom dndSelection; @@ -116,7 +117,59 @@ static INPUT_TYPE current_input_type = X11DRV_INPUT_ABSOLUTE; static BOOL in_transition = FALSE; /* This is not used as for today */ +/*********************************************************************** + * EVENT_TakeFocus + */ +static void EVENT_TakeFocus( HWND hWnd, XAnyEvent *event, Time time ) +{ + XWindowAttributes win_attr; + BOOL bIsDisabled; + Window focusWindow; + HWND focusHandle; + + TRACE("called, X11 window is %08lx, window handle is %04x.\n", + event->window, hWnd); + + if (!hWnd) return; + + bIsDisabled = GetWindowLongA( hWnd, GWL_STYLE ) & WS_DISABLED; + + /* If the window has been disabled, + * revert the X focus back to the last focus window. This is to disallow + * the window manager from switching focus away while the app is + * in a modal state. + */ + if (bIsDisabled) + focusWindow = glastXFocusWin; + else + focusWindow = event->window; + + wine_tsx11_lock(); + + /* Change focus only if focus window is registered and viewable. */ + if (XFindContext( event->display, focusWindow, winContext, (char **)&focusHandle ) || + !XGetWindowAttributes( event->display, focusWindow, &win_attr ) || + (win_attr.map_state != IsViewable)) + { + wine_tsx11_unlock(); + return; + } + + TRACE("Set X11 focus to: %08lx\n", focusWindow); + XSetInputFocus( event->display, focusWindow, RevertToParent, time ); + + wine_tsx11_unlock(); + + glastXFocusWin = focusWindow; + if (focusHandle != GetForegroundWindow()) + { + TRACE("Set foreground window to: %04x\n", focusHandle); + SetForegroundWindow( focusHandle ); + } +} + + /*********************************************************************** * process_events */ @@ -274,6 +327,7 @@ break; case ButtonPress: + EVENT_TakeFocus(hWnd, (XAnyEvent*)event, ((XButtonEvent*)event)->time); X11DRV_ButtonPress( hWnd, (XButtonEvent*)event ); break; @@ -354,39 +408,6 @@ */ static void EVENT_FocusIn( HWND hWnd, XFocusChangeEvent *event ) { - WND *pWndLastFocus; - XWindowAttributes win_attr; - BOOL bIsDisabled; - - if (!hWnd) return; - - bIsDisabled = GetWindowLongA( hWnd, GWL_STYLE ) & WS_DISABLED; - - /* If the window has been disabled and we are in managed mode, - * revert the X focus back to the last focus window. This is to disallow - * the window manager from switching focus away while the app is - * in a modal state. - */ - if ( Options.managed && bIsDisabled && glastXFocusWin) - { - /* Change focus only if saved focus window is registered and viewable */ - wine_tsx11_lock(); - if (XFindContext( event->display, glastXFocusWin, winContext, - (char **)&pWndLastFocus ) == 0 ) - { - if (XGetWindowAttributes( event->display, glastXFocusWin, &win_attr ) && - (win_attr.map_state == IsViewable) ) - { - XSetInputFocus( event->display, glastXFocusWin, RevertToParent, CurrentTime ); - wine_tsx11_unlock(); - return; - } - } - wine_tsx11_unlock(); - } - - if (event->detail != NotifyPointer && hWnd != GetForegroundWindow()) - SetForegroundWindow( hWnd ); } @@ -397,10 +418,7 @@ */ static void EVENT_FocusOut( HWND hWnd, XFocusChangeEvent *event ) { - /* Save the last window which had the focus */ - glastXFocusWin = event->window; if (!hWnd) return; - if (GetWindowLongA( hWnd, GWL_STYLE ) & WS_DISABLED) glastXFocusWin = 0; if (event->detail != NotifyPointer && hWnd == GetForegroundWindow()) { @@ -1252,6 +1270,10 @@ EVENT_DropFromOffiX(hWnd, event); else if (event->data.l[0] == DndURL) EVENT_DropURLs(hWnd, event); + } + else if (event->message_type == wmProtocols && ((Atom)event->data.l[0]) == wmTakeFocus) + { + EVENT_TakeFocus(hWnd, (XAnyEvent*)event, (Time)event->data.l[1]); } else { #if 0 Index: wine/dlls/x11drv/window.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/window.c,v retrieving revision 1.27 diff -u -r1.27 window.c --- wine/dlls/x11drv/window.c 2001/10/18 21:38:59 1.27 +++ wine/dlls/x11drv/window.c 2001/10/21 12:27:57 @@ -44,6 +44,7 @@ Atom wmChangeState = None; Atom kwmDockWindow = None; Atom _kde_net_wm_system_tray_window_for = None; /* KDE 2 Final */ +Atom wmMotifHints = None; static LPCSTR whole_window_atom; static LPCSTR client_window_atom; @@ -109,7 +110,7 @@ if (managed) win->dwExStyle |= WS_EX_MANAGED; else win->dwExStyle &= ~WS_EX_MANAGED; - attr->override_redirect = !managed; + attr->override_redirect = 0; // FIXME: true for transient windows (menus) attr->colormap = X11DRV_PALETTE_PaletteXColormap; attr->save_under = ((win->clsStyle & CS_SAVEBITS) != 0); attr->cursor = None; @@ -332,6 +333,16 @@ wine_tsx11_lock(); + /* motif hints */ + if(!(win->dwExStyle & WS_EX_MANAGED)) + { + INT32 hints[5] = {2,0,0,0,0}; + XChangeProperty( display, data->whole_window, + wmMotifHints, wmMotifHints, + 32, PropModeReplace, + (char*)hints, 5 ); + } + /* wm protocols */ i = 0; protocols[i++] = wmDeleteWindow; @@ -594,8 +605,8 @@ winContext = XUniqueContext(); wmProtocols = XInternAtom( display, "WM_PROTOCOLS", False ); wmDeleteWindow = XInternAtom( display, "WM_DELETE_WINDOW", False ); -/* wmTakeFocus = XInternAtom( display, "WM_TAKE_FOCUS", False );*/ - wmTakeFocus = 0; /* not yet */ + wmTakeFocus = XInternAtom( display, "WM_TAKE_FOCUS", False ); + wmMotifHints = XInternAtom( display, "_MOTIF_WM_HINTS", False ); dndProtocol = XInternAtom( display, "DndProtocol" , False ); dndSelection = XInternAtom( display, "DndSelection" , False ); wmChangeState = XInternAtom (display, "WM_CHANGE_STATE", False); -- Jukka Heinonen <http://www.iki.fi/jhei/>

1 0

Remote Windows Registry API and other Win32 APIs now available
by Luke Kenneth Casson Leighton Oct. 19, 2001

Oct. 19, 2001

hi there, i thought i'd put up a more eye-catching subject line. to clarify: yes, that's right, FreeDCE has a set of remote Win32 APIs. see http://dcerpc.net for details. if anyone would like to help get these integreated into wine, please contact me for more information. luke

1 0

Re: Page faults and instruction emulation
by Alexandre Julliard Oct. 19, 2001

Oct. 19, 2001

Ove Kaaven <ovehk(a)ping.uio.no> writes: > Well, perhaps it could depend on the windows version somehow... No, you really don't want to have the layout of core data structures depend on the version. > Maybe... I was just concerned whether you'd like Wine to be subject to > lawsuits or something (reverse engineering, trade secrets, DMCA, > whatever... not that the kernel driver is really complex, though). > Also, I was afraid some games might refuse to work with --winver nt40 I don't think lawsuits should be a problem, as long as we make a reasonable effort to implement the correct functionality and not just fake it. Of course there's always a risk that someone will sue, but these days the risk exists as soon as you release 3 lines of code. We really should move towards an NT-like architecture as much as possible; this is where Windows is going too, and it's the only one we have a chance of making work 100% correctly. We'll never be able to implement the full brokenness of the Win95 "architecture" anyway, so it's better to concentrate on the things that we can make work right. -- Alexandre Julliard julliard(a)winehq.com

1 0