- Wine-devel - list.winehq.org

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

21 Oct '01

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 21 Oct '01

21 Oct '01

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 21 Oct '01

21 Oct '01

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 19 Oct '01

19 Oct '01

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 19 Oct '01

19 Oct '01

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

Re: File media type
by Alexandre Julliard 19 Oct '01

19 Oct '01

Ove Kaaven <ovehk(a)ping.uio.no> writes: > But since to do this, MapViewOfFile needs to know the media type, and the > file name is only known in CreateFile, I apparently need to store the > media type in the wineserver object to accomplish this. > > Would changing the wineserver protocol in this way be a good idea? It's certainly a possibility. It would be nice to be able to tell directly from the file descriptor, so that we wouldn't depend on the user getting the drive specifications right. But I can't think of a Unix function that would allow doing this cleanly. -- Alexandre Julliard julliard(a)winehq.com

3 2

Re: wine/port.h #include fixes
by Roger Fujii 19 Oct '01

19 Oct '01

> It's slowly coming around (Francois recent patches are key), > but we still have some fairly serious issues. Is this in? As of 10/17, it still blows up in NtCurrentTeb(). What does this function do? - is it trying to use a protected instruction? (in x86 instruction knowledge is pretty dated). > You've hit the first issue - being sure to use the > GNU tool chain. yup... want to try tackling that once I get the program to at least come up... > Doing a cvs update and trying again (after, of course, > Alexandre commits Francois' recent patches) may > bring you more joy. a bold statement.. :) I presume that you don't have to install it to test it out, right? (so long as I have LD_LIBRARY_PATH set to dlls:.). I take it that someone does have something that works on solx86? -r

3 6

Re: wine/port.h #include fixes
by Alexandre Julliard 19 Oct '01

19 Oct '01

Roger Fujii <rmf(a)lookhere.com> writes: > well, I think more to the point is that something says what > steps need to be done to run a specific version. The current > instructions just say to set LD_LIBRARY_PATH, which isn't > really correct. So, just for the record, all you have to do > is set LD_LIBRARY_PATH to srcdir:srcdir/dlls and WINESERVER > to srcdir/server/wineserver? Or do you need access to things > like winebuild? To make absolutely sure you don't pick anything from the configured prefix directory, you have to set WINESERVER, WINELOADER, WINEDLLPATH and LD_LIBRARY_PATH. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Page faults and instruction emulation
by Alexandre Julliard 19 Oct '01

19 Oct '01

Ove Kaaven <ovehk(a)ping.uio.no> writes: > I know of two Wine architecture issues that must be resolved before the > anti-debugger check can succeed in win95 mode. > > 1. it checks that teb->debug_context (TEB offset 0x20) is zero. In Wine, > it isn't (the NT pid is stored there), so this check fails. > > Is it possible to change Wine's TEB structure to fix this? It would probably break some of the NT native dlls. > 2. it messes with the IDT. It uses the sidt instruction and tries to > change the INT5 vector (BOUND exception vector), later to try to execute a > BOUND and expect this vector to be branched to, all protected with > exception handlers. Now, this would actually be possible for Wine to > emulate, even though sidt is not a privileged instruction. The idea is > that sidt returns an address to kernel space, where all access is > prohibited, hence causing page faults. Wine could trap these, and then > emulate the faulting instruction by operating on a fake IDT instead. And > then the segfault caused by BOUND could then look up the fake IDT entry, > and call the vector therein. > > But to emulate an instruction from Wine's pre-exception page fault handler > (VIRTUAL_HandleFault()), the current context must be passed along to it, > so VIRTUAL_HandleFault and all Wine handlers that can be registered with > VIRTUAL_SetFaultHandler must get an extra parameter. Is this too > objectionable to do? The extra parameter is not that bad, but having to do full emulation of all instructions accessing memory, plus the complete IDT handling, is going to lead to major ugliness. Wouldn't it be possible to somehow emulate the kernel driver to make the NT version work? That would be much cleaner. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: wine/port.h #include fixes
by Alexandre Julliard 19 Oct '01

19 Oct '01

Fran�ois Gouget <fgouget(a)codeweavers.com> writes: > Should Wine really try the installed prefix first? It seems to me > that it should try it last instead. After all, if you change the path > you would expect your change to have an effect, no? No, you don't want changing the PATH suddenly to start breaking your applications. > Plus checking the > installed prefix first assumes that whichever version of wine is started > (e.g. /home/fgouget/bin/wine) is the same as that of > /usr/bin/wineserver! Yes of course, if you compiled it with /usr/bin as prefix it assumes that /usr/bin is where its wineserver is. If you don't want that you have to change the prefix, or set WINESERVER explicitly. -- Alexandre Julliard julliard(a)winehq.com

2 1