wine-devel

wine-devel@winehq.org

10 participants
84459 discussions

rpcrt4 and rpcss with WINE and ReactOS
by Steven Edwards 10 Dec '03

10 Dec '03

Hello, Ok I know this going to start YALD (Yet Another Long Discussion) that wont go anywhere right away but...... ReactOS is getting ready to do a major import of the WINE dlls as you guys know due to my repeated cross-postings to Wine-devel and ros-kernel. When we compile rpcrt and ole32 from WINE with some hacks we can make it work under ReactOS but I would like to develop a implementation that works properly without dirty hacking. I dont know much about WINEs rpcss other than whats in the comments of the code and for that matter I dont know much about Windows rpcss. Can we share these componates? How are we going to break compatiblity by doing this? Thanks Steven __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/

3 5

Adding support for a USB device
by Dan Timis 09 Dec '03

09 Dec '03

Hi, I need help with supporting a particular USB device under wine. I have to start by saying that although I am an experienced C/C++ programmer with some Linux experience, I have almost no Windows or wine experience. The Windows code for which I need to provide support uses CreateFile() to get a handle to the device. The name of the device is something like "\\.\MyDevice0" "\\.\MyDevice1" and so on. Then, the code uses DeviceIoControl() to read and write from/to the device. The requirement is not to change the windows code. I looked through the wine code and I found this in device.c: static const struct VxDInfo VxDList[] I could add another entry into the table and write a deviceio handler (BOOL (*deviceio)(DWORD, LPVOID, DWORD, LPVOID, DWORD, LPDWORD, LPOVERLAPPED);). I wrote some test code in Linux using libusb reading and writing to the device so I know what to do inside the deviceio handler. Is this the right approach? If so, what do I need to do to get CreateFile to return the right handle? Or should I write an external driver that gets loaded by wine? If so, how would I do that? What are the chances that the Windows driver for this device would just work with wine? Thanks, Dan Timis Muse Research, Inc.

2 1

Re: Winewrap change
by Alexandre Julliard 09 Dec '03

09 Dec '03

Shachar Shemesh <wine-patches(a)shemesh.biz> writes: > Slight change to winewrap > Changelog > Shachar Shemesh <winecode(a)shemesh.biz> > tools/winewrapper > > * Add tools into path for wine Hmmm, which program do you need from tools at run time? -- Alexandre Julliard julliard(a)winehq.com

2 2

Sorry for spamming the list..
by Subhobroto Sinha 09 Dec '03

09 Dec '03

Hello I am really sorry for making multiple posts - I got the Rediffmail mailer's verification after 20 minutes (normally Yahoo!'s mailservers notify almost instantaneously..), but before I could realize it, my 4 messages had already been mailed out of the queue... This was the first time I was using an Indian mail server, and well as it turns out, it was slower than a USA server ?! Regards Subhobroto Sinha

1 0

Re: wine/dlls/oleaut32/tests vartest.c
by Jon Griffiths 09 Dec '03

09 Dec '03

Hi Dmitry, > vartest.c:4151: Test failed: VarAbs: expected 0x0,5,1.1, got 0x80020005,0,0 > vartest.c:4217: Test failed: VarNot: expected 0x0, got 0x80020008 vt 20|0x0 > vartest.c:4217: Test failed: VarNot: expected 0x0, got 0x80020008 vt 21|0x0 > vartest: 526958 tests executed, 0 marked as todo, 3 failures. Does this patch fix it? Jon __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/

2 1

DirectX Status Section
by Tom 09 Dec '03

09 Dec '03

Hi, Here is my first draft anyone have any comments?, constructive criticism? Tom

1 0

Help for OLEAUT32 DLL problem
by Robert Iver 09 Dec '03

09 Dec '03

Having a spot of trouble getting this function implemented in Wine so I can install a program for my job. It is basically a VB app that interfaces with a MySQL server database. I have heard that I cannot use a native DLL to do the job since it is OLE, so I have been trying to write a stub for it. Unfortunately, this is my first try at developing for Wine and I have writer's block. The function I am trying to implement is GetRecordInfoFromGuids. Could anyone out there write a basic stub for this program, so I can implement it and at least have an example to work with???? BTW, I have installed DCOM98, Crystal Reports and SQL Network Client Utility with no problems..

3 2

Forte Agent 2.0 (closed beta)
by Boris 'pi' Piwinger 09 Dec '03

09 Dec '03

Hi! I am new to the list and have Linux at home since last Thursday. I am still having some problems getting Forte Agent to work under Wine, but I am involved into (closed) beta testing for Forte Agent for many years and we just got the first shot at 2.0 which will change a lot anyway. Some problems are gone, but some serious problems are new. It is the aim of Forte to have Agent run under Wine. So they asked me to invite Wine developers to join the beta testing people so both sides can see what needs to be done. People on the Agent beta list are in very close contact (I really enjoy it) to the progammer Mark Sidell, he really get's the things done we suggest:-)) If you are a Wine developer and would like to join, please let me know, I'll forward it to the guys at Forte. pi

6 8

Re: wine/dlls/oleaut32/tests vartest.c
by Dmitry Timoshkov 09 Dec '03

09 Dec '03

"Alexandre Julliard" <julliard(a)winehq.org> wrote: > Log message: > Jon Griffiths <jon_p_griffiths(a)yahoo.com> > Fix the tests to pass when locale settings are user-overriden. > Fix those tests which pass now. > Test copying, formatting, VarAbs, VarNot. New tests for VarAbs and VarNot fail for me on win2k SP4 (Russian locale): vartest.c:1760:======== Testing VarUI1FromXXX ======== vartest.c:1848:======== Testing VarUI2FromXXX ======== vartest.c:1935:======== Testing VarUI4FromXXX ======== vartest.c:2021:======== Testing VarI1FromXXX ======== vartest.c:2087:======== Testing VarI2FromXXX ======== vartest.c:2132:======== Testing VarI4FromXXX ======== vartest.c:2176:======== Testing VarR4FromXXX ======== vartest.c:2223:======== Testing VarR8FromXXX ======== vartest.c:2243:======== Testing VarDateFromXXX ======== vartest.c:2298:======== Testing VarBoolFromXXX ======== vartest.c:2354:======== Testing VarBSTRFromXXX ======== vartest.c:2573:======== Testing Hi-Level Variant API ======== vartest.c:2658:======== Testing different VARTYPES ======== vartest.c:3831:Skipping VarFormatNumber tests as decimal seperator is ',' vartest.c:3987:Skipping VarFormat tests for non english language vartest.c:4151: Test failed: VarAbs: expected 0x0,5,1.1, got 0x80020005,0,0 vartest.c:4217: Test failed: VarNot: expected 0x0, got 0x80020008 vt 20|0x0 vartest.c:4217: Test failed: VarNot: expected 0x0, got 0x80020008 vt 21|0x0 vartest: 526958 tests executed, 0 marked as todo, 3 failures. -- Dmitry.

1 0

I made a wish, wrote a letter to Santa...
by Subhobroto Sinha 09 Dec '03

09 Dec '03

With XMas nearing, I thought it was time I made my yearly wish to Santa - that he would let his elves use C++ in WINE. (Just in case, you did not know Santa's email address, it's 'julliard[at]winehq.org', and you can make your wishes at 'wine-devel[at]winehq.com'..) You see, Santa was always so good - he answered people's prayers and got together his obedient elves to run Win32 on Non-Windows platforms! However, soon many of his elves found out that technologies like MFC, WTL, ATL, COM, DCOM, COM+ and other MS bloops were getting too complex to be implemented using plain C, and thus developments in those areas were soon in limbo. But that could be solved using yet another language called C++ - if only Santa would let it be. Oh please Santa ! Let us adultrate WINE with C++, please. It's not that we will rewrite everything in C++ once we get the green signal - things like the loader, scheduler, and most of the Win32 SDK does not need C++ at all, but what about MFC, COM, OLE ? Not that I expect to compile native MFC source using WineLib, but at least we can write the runtimes so that native MFC apps can atleast run under WINE ? DirectX oozes of classes,inheritance,abstaction and everything C++ as does OLE, COM and already our implementations have structure object pointers running wild, whereas encapsulation would have done away with it ! As a simple explanation, we might take our 'This' hack wheras C++ would let have us use it as 'this' without even us worrying about it ! Also, there are many places in shell32, ole and shwlapi (I cannot comment on DirectX source as I do not have a graphics base at all ..) where initializing a few member variables from a constructor would have done away with some redundancy. Most of the time we are passing around multilevel pointers when a simple reference would have done: For example a call like Stream_LoadString( stm, unicode, &This->sString ); [To 'static HRESULT Stream_LoadString( IStream* stm, BOOL unicode,LPWSTR *pstr )'] can be made to a simple Stream_LoadString(sString); using C++ if we had the prototype rewritten to 'static HRESULT Stream_LoadString(LPWSTR& pstr )' and making it a member function of IStream (and thus the 'IStream* stm' and 'BOOL unicode' would be member variables..) We have code like that all over the place whenever COM etc comes into play and "That's Not A Good Thing(TM)" ! Please give us the green card - alternately, a new test branch may also be created just to see if C++ would work.All C++ based modfications would goto that tree. If that test branch works and delivers, it maybe merged into the main WINE tree, otherwise if it fails

2 1

I made a wish, wrote a letter to Santa...
by Subhobroto Sinha 09 Dec '03

09 Dec '03

1 0

I made a wish, wrote a letter to Santa...
by Subhobroto Sinha 09 Dec '03

09 Dec '03

1 0

I made a wish, wrote a letter to Santa...
by Subhobroto Sinha 09 Dec '03

09 Dec '03

1 0

Re: regedit: consistent formatting
by Lionel Ulmer 09 Dec '03

09 Dec '03

On Mon, Dec 08, 2003 at 12:03:00AM -0500, Dimitrie O. Paun wrote: > Only whitespace changes. Unfortunately, the formatting was > all messed up by having tabs of 4 and 8 chars (I said it > before, and I'll say it again: the only sane way of dealing > with tabs is to always use the standard size of 8 chars. > Anything else is too complicated to ever work reliably). Just to flame a bit (the lists were a bit quiet lately) : the only sane way to dealing with TABs is when TABs are used properly (ie by an editor that uses them only to go to the current C indenting level and uses spaces for everything that comes after). With such an editor, tab size does not matter at all. No idea if Emacs / Vi can be used to work like that :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

6 10

Question about libwine_unicode functions and others in WINE
by Steven Edwards 08 Dec '03

08 Dec '03

Hello, We are looking at porting more code from WINE to ReactOS and I am having trouble understanding the need for libwine_unicode as a shared library. Some of the functions that it exports such as CompareString are implemented in ntdll as RtlCompareString and then also used in shlwapi as per a recent patch. Wouldnt it better to import the function from ntdll and hide libwine_unicode or make the parts that we need to share a static library? In ReactOS we have created NT compatible NLS files. Could WINE do this also and dump libwine_nicode? Also I was looking at the HeapAlloc stuff in WINE and code we have ported from ReactOS such as the FormatMessage function in kernel32. Doesnt kernel32 HeapAlloc and friends map on top of ntdll RtlHelpAlloc? Can we submit patches to WINE so that everything just calls RtlHeapAlloc so we dont have to change the sources? Thanks Steven __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/

7 19

ATI driver crashes the system with wine
by Gerhard W. Gruber 08 Dec '03

08 Dec '03

I tried to install the ATI 3D acceleration for my card Radeon 9800XT. So far I didn'tsucced and I currently have to use Mesa for that. Now I managed to get at least the fglrx driver working with agpgart but when I use this then my system immediatly crashes when I try to run Agent from wine. I doubt that Agent is the cuplrit, so I guess this is something in wine. The screen goes simply blank and I can't see anything. I have to power off. When I disable the agpgart module I can run wine as well. My system: Kernel 2.4.22 (kernel.org) Suse 8.2 pro (with the drivers from the latest release). Wine is the CVS download from today (I just downloaded it about an hour ago and installed it). Everything else works fine. When I run glxgears it works, even though I have only 400 FPS because of the missing 3D acceleration. Any ideas whats wrong there or how I can debug this? Maybe this will give me a clue as whats wrong with my 3D acceleration as well. -- Gerhard Gruber Maintainer of SoftICE for Linux - http://sourceforge.net/projects/pice Fast application launcher - http://sourceforge.net/projects/launchmenu

4 5

Re: wine/windows painting.c
by Marcelo Duarte 08 Dec '03

08 Dec '03

This patch caused a regression in Winamp 2.91, and the top window is not repainted. I use with the folowing modifications in the ~/.wine/config: ; Winamp 2.91 runs good, but the title is eated. In desktop is better. [AppDefaults\\winamp.exe\\x11drv] "Desktop" = "560x700" Em Sex 05 Dez 2003 01:42, Alexandre Julliard escreveu: > ChangeSet ID: 10338 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2003/12/04 22:42:43 > > Modified files: > windows : painting.c > > Log message: > In RDW_ValidateParent, get rid of the parent update region if it is > empty after the validation, to avoid a useless WM_PAINT. > > Patch: http://cvs.winehq.com/patch.py?id=10338 > > Old revision New revision Changes Path > 1.88 1.89 +9 -1 wine/windows/painting.c Index: wine/windows/painting.c diff -u wine/windows/painting.c:1.88 wine/windows/painting.c:1.89 --- wine/windows/painting.c:1.88 Sun Dec 7 05:54:18 2003 +++ wine/windows/painting.c Sun Dec 7 05:54:18 2003 @@ -379,7 +379,15 @@ ptOffset.x = rect.left - rectParent.left; ptOffset.y = rect.top - rectParent.top; OffsetRgn( hrg, ptOffset.x, ptOffset.y ); - CombineRgn( wndParent->hrgnUpdate, wndParent->hrgnUpdate, hrg, RGN_DIFF ); + if (CombineRgn( wndParent->hrgnUpdate, wndParent->hrgnUpdate, hrg, RGN_DIFF ) == NULLREGION) + { + /* the update region has become empty */ + DeleteObject( wndParent->hrgnUpdate ); + wndParent->hrgnUpdate = 0; + wndParent->flags &= ~WIN_NEEDS_ERASEBKGND; + if( !(wndParent->flags & WIN_INTERNAL_PAINT) ) + add_paint_count( wndParent->hwndSelf, -1 ); + } OffsetRgn( hrg, -ptOffset.x, -ptOffset.y ); } } -- Marcelo Duarte

2 2

Status : Multimedia section
by Tom 07 Dec '03

07 Dec '03

Hi, Here is the new layout of the Multimedia section of the "Status Dll's" page. May I ask what you guys here think of it?, constructive criticism? Tom

5 10

Re: small file reorganisation
by Alexandre Julliard 06 Dec '03

06 Dec '03

Eric Pouech <pouech-eric(a)wanadoo.fr> writes: > I hope Alexandre will not got mad about the introduced circular dep > (kernel32 => (delay) winedos => kernel32). Since, we're now building > the DLLs through the .spec files, I assumed, since it no longer > impacts the make system, it would be ok. I don't think that's a good idea, especially since winedos is not a standard dll. And IMO it's preferable to have kernel export _lclose16 which is a standard API, than replacing it by a new DisposeFileHandle function that doesn't correspond to anything on Windows. -- Alexandre Julliard julliard(a)winehq.com

2 4

Thoughts about fixing bug 1848
by Andreas Rosenberg 06 Dec '03

06 Dec '03

I was thinking about fixing the bug 1848. Here are parts of the involved functions. See my comments/questions with multiple *** inside: ------------------------------- BOOL WINAPI TrackPopupMenu( HMENU hMenu, UINT wFlags, INT x, INT y, INT nReserved, HWND hWnd, const RECT *lpRect ) { BOOL ret = FALSE; MENU_InitTracking(hWnd, hMenu, TRUE, wFlags); /****** returns always TRUE */ /* Send WM_INITMENUPOPUP message only if TPM_NONOTIFY flag is not specified */ if (!(wFlags & TPM_NONOTIFY)) SendMessageW( hWnd, WM_INITMENUPOPUP, (WPARAM)hMenu, 0); if (MENU_ShowPopup( hWnd, hMenu, 0, x, y, 0, 0 )) /****** this may return FALSE if MENU_GetMenu fails */ /****** how can we decide if the call failed, or a click outside the menu happened ???? */ /****** I would suggest to let MENU_TrackMenu return -1 if clicked outside the menu and zero if */ /****** something fails - this requires no other change */ ret = MENU_TrackMenu( hMenu, wFlags | TPM_POPUPMENU, 0, 0, hWnd, lpRect ); MENU_ExitTracking(hWnd); /***** returns always TRUE */ if( (!(wFlags & TPM_RETURNCMD)) && (ret != FALSE) ) /****** FALSE = 0*/ ret = TRUE; return ret; } static INT MENU_TrackMenu( HMENU hmenu, UINT wFlags, INT x, INT y, HWND hwnd, const RECT *lprect ) { ..... INT executedMenuId = -1; .... /*** If I understood things right - simply return executedMenuId */ /*** suggestion: return (executedMenuId) */ /*** could somebody please comment, if my assumption is correct? */ return ((executedMenuId != -1) ? executedMenuId : 0); }

1 0

winetest WineHQ integration
by Ferenc Wagner 06 Dec '03

06 Dec '03

Hi, so we should start working out this one, too. First let me sketch the present picture. I've got a directory structure like this: | + 20030829 + 95 | + 95_michael | + 98 | + 98_joel | + 98_kevin | + etc. | ` 2003s | + 20030916 (similar) ` 20031127 (similar) That is, one directory for each test collection and one subdirectory for each submission of it. For a new submission I create a directory, copy the results.txt into it, create a reporter.txt next to it, add it to archs in the Makefile, and make. For a new test collection I create missing.dll.txt's (presently dsound), Makefile and tests.zip in a new directory. Changes needed at least: 1. Windows version detected automatically. 2. Tester name and contact (?) included in the results. 3. Automatically generated tags, probably simple incremental numbers. 4. Which submission should be the principal one? The first? 5. Makefile at one level higher, archs variable autodetected. But before doing anything, we definitely need the opinion of the website maintainer. We need a very simple CGI to handle the file uploads. Presently it is <http://afavant.elte.hu/~wferi/wine/winetest.pl>. All of the present machinery is available in that directory: Makefile, dissect, gather and the other ingredients. I don't know much about web design or anything about WineHQ's inner workings. What sort of output should we produce? I think the above is enough for a start... Feri.

4 6

Re: System tray integration
by Mike Hearn 05 Dec '03

05 Dec '03

Hi Alexandre, This has missed the last two commits. Is this codes presence in shell32 really a blocking issue? If so then I'd note that quite a lot of people have problems caused by the lack of this patch (can't quit apps etc). thanks -mike On Sun, 2003-11-30 at 16:16, Mike Hearn wrote: > Hi, > > This patch updates my system tray patch to work with the new atom > interning code, fixes a few bugs and replaces the per-icon mutex with a > global one. The critical section handling should therefore be much less > broken now. > > Yes, I know it should be in wineshell.exe but for now this will do, and > the code can always be moved later. > > thanks -mike > > ChangeLog: > Implement support for XEMBED based system trays > > Index: dlls/shell32/systray.c > =================================================================== > RCS file: /home/wine/wine/dlls/shell32/systray.c,v > retrieving revision 1.24 > diff -u -r1.24 systray.c > --- dlls/shell32/systray.c 24 Oct 2003 04:23:37 -0000 1.24 > +++ dlls/shell32/systray.c 30 Nov 2003 16:08:37 -0000 > @@ -1,11 +1,11 @@ > /* > - * Systray > + * System tray handling code (client side) > * > - * Copyright 1999 Kai Morich <kai.morich(a)bigfoot.de> > + * Copyright 1999 Kai Morich <kai.morich(a)bigfoot.de> > + * Copyright 2003 Mike Hearn <mike(a)theoretic.com> > * > - * Manage the systray window. That it actually appears in the docking > - * area of KDE or GNOME is delegated to windows/x11drv/wnd.c, > - * X11DRV_WND_DockWindow. > + * This code creates a window with the WS_EX_TRAYWINDOW style. The actual > + * environment integration code is handled inside the X11 driver. > * > * This library is free software; you can redistribute it and/or > * modify it under the terms of the GNU Lesser General Public > @@ -42,7 +42,17 @@ > #include "commctrl.h" > #include "wine/debug.h" > > -WINE_DEFAULT_DEBUG_CHANNEL(shell); > +WINE_DEFAULT_DEBUG_CHANNEL(systray); > + > +static CRITICAL_SECTION systray_lock; > +static CRITICAL_SECTION_DEBUG critsect_debug = > +{ > + 0, 0, &systray_lock, > + { &critsect_debug.ProcessLocksList, &critsect_debug.ProcessLocksList }, > + 0, 0, { 0, (DWORD)(__FILE__ ": system tray") } > +}; > +static CRITICAL_SECTION systray_lock = { &critsect_debug, -1, 0, 0, 0, 0 }; > + > > typedef struct SystrayItem { > HWND hWnd; > @@ -51,12 +61,11 @@ > struct SystrayItem *nextTrayItem; > } SystrayItem; > > -static SystrayItem *systray=NULL; > -static int firstSystray=TRUE; /* defer creation of window class until first systray item is created */ > +static SystrayItem *systray = NULL; > +static int firstSystray = TRUE; /* defer creation of window class until first systray item is created */ > > static BOOL SYSTRAY_Delete(PNOTIFYICONDATAA pnid); > > - > #define ICON_SIZE GetSystemMetrics(SM_CXSMICON) > /* space around icon (forces icon to center of KDE systray area) */ > #define ICON_BORDER 4 > @@ -74,21 +83,26 @@ > { > HDC hdc; > PAINTSTRUCT ps; > - > + TRACE("hwnd=%p, msg=0x%x\n", hWnd, message); > switch (message) { > case WM_PAINT: > { > RECT rc; > SystrayItem *ptrayItem = systray; > - > + int top; > + EnterCriticalSection(&systray_lock); > + > while (ptrayItem) { > - if (ptrayItem->hWnd==hWnd) { > + if (ptrayItem->hWnd == hWnd) { > if (ptrayItem->notifyIcon.hIcon) { > hdc = BeginPaint(hWnd, &ps); > GetClientRect(hWnd, &rc); > - if (!DrawIconEx(hdc, rc.left+ICON_BORDER, rc.top+ICON_BORDER, ptrayItem->notifyIcon.hIcon, > + /* calculate top so we can deal with arbitrary sized trays */ > + top = ((rc.bottom-rc.top)/2) - ((ICON_SIZE)/2); > + if (!DrawIconEx(hdc, (ICON_BORDER/2), top, ptrayItem->notifyIcon.hIcon, > ICON_SIZE, ICON_SIZE, 0, 0, DI_DEFAULTSIZE|DI_NORMAL)) { > ERR("Paint(SystrayWindow %p) failed -> removing SystrayItem %p\n", hWnd, ptrayItem); > + LeaveCriticalSection(&systray_lock); > SYSTRAY_Delete(&ptrayItem->notifyIcon); > } > } > @@ -97,10 +111,10 @@ > ptrayItem = ptrayItem->nextTrayItem; > } > EndPaint(hWnd, &ps); > + LeaveCriticalSection(&systray_lock); > } > break; > > - case WM_MOUSEMOVE: > case WM_LBUTTONDOWN: > case WM_LBUTTONUP: > case WM_RBUTTONDOWN: > @@ -110,7 +124,8 @@ > { > MSG msg; > SystrayItem *ptrayItem = systray; > - > + /* relay the event to the tooltip */ > + EnterCriticalSection(&systray_lock); > while ( ptrayItem ) { > if (ptrayItem->hWnd == hWnd) { > msg.hwnd=hWnd; > @@ -125,15 +140,17 @@ > } > ptrayItem = ptrayItem->nextTrayItem; > } > + LeaveCriticalSection(&systray_lock); > } > - /* fall through */ > + /* fall through, so the message is sent to the callback as well */ > > case WM_LBUTTONDBLCLK: > case WM_RBUTTONDBLCLK: > case WM_MBUTTONDBLCLK: > { > SystrayItem *ptrayItem = systray; > - > + /* iterate over the currently active tray items */ > + EnterCriticalSection(&systray_lock); > while (ptrayItem) { > if (ptrayItem->hWnd == hWnd) { > if (ptrayItem->notifyIcon.hWnd && ptrayItem->notifyIcon.uCallbackMessage) { > @@ -147,9 +164,18 @@ > } > ptrayItem = ptrayItem->nextTrayItem; > } > + LeaveCriticalSection(&systray_lock); > } > break; > > + case WM_NOTIFYFORMAT: > + { > + TRACE("Received WM_NOTIFYFORMAT, showing the tray window\n"); > + ShowWindow(hWnd, SW_SHOW); > + return (DefWindowProcA(hWnd, message, wParam, lParam)); > + } > + > + > default: > return (DefWindowProcA(hWnd, message, wParam, lParam)); > } > @@ -169,7 +195,7 @@ > wc.hInstance = 0; > wc.hIcon = 0; > wc.hCursor = LoadCursorA(0, (LPSTR)IDC_ARROW); > - wc.hbrBackground = (HBRUSH)(COLOR_WINDOW + 1); > + wc.hbrBackground = (HBRUSH) COLOR_WINDOW; > wc.lpszMenuName = NULL; > wc.lpszClassName = "WineSystray"; > > @@ -181,30 +207,21 @@ > } > > > -BOOL SYSTRAY_ItemInit(SystrayItem *ptrayItem) > -{ > +DWORD WINAPI SYSTRAY_ThreadProc(LPVOID p1) { > + SystrayItem *ptrayItem = (SystrayItem *)p1; > + MSG msg; > RECT rect; > - > - /* Register the class if this is our first tray item. */ > - if ( firstSystray ) { > - firstSystray = FALSE; > - if ( !SYSTRAY_RegisterClass() ) { > - ERR( "RegisterClass(WineSystray) failed\n" ); > - return FALSE; > - } > - } > - > + > /* Initialize the window size. */ > rect.left = 0; > rect.top = 0; > rect.right = ICON_SIZE+2*ICON_BORDER; > rect.bottom = ICON_SIZE+2*ICON_BORDER; > > - ZeroMemory( ptrayItem, sizeof(SystrayItem) ); > /* Create tray window for icon. */ > ptrayItem->hWnd = CreateWindowExA( WS_EX_TRAYWINDOW, > - "WineSystray", "Wine-Systray", > - WS_VISIBLE, > + "WineSystray", "Windows System Tray", > + 0, > CW_USEDEFAULT, CW_USEDEFAULT, > rect.right-rect.left, rect.bottom-rect.top, > 0, 0, 0, 0 ); > @@ -222,31 +239,73 @@ > ERR( "CreateWindow(TOOLTIP) failed\n" ); > return FALSE; > } > + > + /* Enter the message loop */ > + while (GetMessageA (&msg, 0, 0, 0) > 0) { > + TranslateMessage (&msg); > + DispatchMessageA (&msg); > + } > + > + TRACE("Shutting down system tray thread\n"); > + if(ptrayItem->notifyIcon.hIcon) > + DestroyIcon(ptrayItem->notifyIcon.hIcon); > + if(ptrayItem->hWndToolTip) > + DestroyWindow(ptrayItem->hWndToolTip); > + > + return 0; > +} > + > +BOOL SYSTRAY_ItemInit(SystrayItem *ptrayItem) > +{ > + DWORD threadID; > + > + /* Register the class if this is our first tray item. */ > + EnterCriticalSection(&systray_lock); > + if ( firstSystray ) { > + firstSystray = FALSE; > + if ( !SYSTRAY_RegisterClass() ) { > + ERR( "RegisterClass(WineSystray) failed\n" ); > + LeaveCriticalSection(&systray_lock); > + return FALSE; > + } > + } > + LeaveCriticalSection(&systray_lock); > + > + ZeroMemory( ptrayItem, sizeof(SystrayItem) ); > + > + /* We need to run the system tray window in a separate thread, as otherwise if the originating thread > + stops processing messages, the tray window will hang. If another part of the application then does > + for instance a FindWindow call, this can deadlock the application. */ > + if (!CreateThread(NULL, 0, SYSTRAY_ThreadProc, (LPVOID) ptrayItem, 0, &threadID)) { > + ERR("Could not create system tray item thread\n"); > + return FALSE; > + } > return TRUE; > } > > > static void SYSTRAY_ItemTerm(SystrayItem *ptrayItem) > { > - if(ptrayItem->notifyIcon.hIcon) > - DestroyIcon(ptrayItem->notifyIcon.hIcon); > - if(ptrayItem->hWndToolTip) > - DestroyWindow(ptrayItem->hWndToolTip); > - if(ptrayItem->hWnd) > - DestroyWindow(ptrayItem->hWnd); > + /* MSDN says we shouldn't do this, but I can't see another way to make GetMessage() return zero */ > + PostMessageA(ptrayItem->hWnd, WM_QUIT, 0, 0); > return; > } > > > void SYSTRAY_ItemSetMessage(SystrayItem *ptrayItem, UINT uCallbackMessage) > { > + EnterCriticalSection(&systray_lock); > ptrayItem->notifyIcon.uCallbackMessage = uCallbackMessage; > + LeaveCriticalSection(&systray_lock); > } > > > void SYSTRAY_ItemSetIcon(SystrayItem *ptrayItem, HICON hIcon) > { > + EnterCriticalSection(&systray_lock); > ptrayItem->notifyIcon.hIcon = CopyIcon(hIcon); > + LeaveCriticalSection(&systray_lock); > + > InvalidateRect(ptrayItem->hWnd, NULL, TRUE); > } > > @@ -255,9 +314,11 @@ > { > TTTOOLINFOA ti; > > - strncpy(ptrayItem->notifyIcon.szTip, szTip, sizeof(ptrayItem->notifyIcon.szTip)); > + EnterCriticalSection(&systray_lock); > + strncpy(ptrayItem->notifyIcon.szTip, szTip, sizeof(ptrayItem->notifyIcon.szTip)); > ptrayItem->notifyIcon.szTip[sizeof(ptrayItem->notifyIcon.szTip)-1]=0; > - > + LeaveCriticalSection(&systray_lock); > + > ti.cbSize = sizeof(TTTOOLINFOA); > ti.uFlags = 0; > ti.hwnd = ptrayItem->hWnd; > @@ -280,10 +341,15 @@ > { > SystrayItem **ptrayItem = &systray; > > + TRACE("%p\n", pnid); > + > + EnterCriticalSection(&systray_lock); > /* Find last element. */ > while( *ptrayItem ) { > - if ( SYSTRAY_ItemIsEqual(pnid, &(*ptrayItem)->notifyIcon) ) > + if ( SYSTRAY_ItemIsEqual(pnid, &(*ptrayItem)->notifyIcon) ) { > + LeaveCriticalSection(&systray_lock); > return FALSE; > + } > ptrayItem = &((*ptrayItem)->nextTrayItem); > } > /* Allocate SystrayItem for element and add to end of list. */ > @@ -297,6 +363,7 @@ > SYSTRAY_ItemSetMessage(*ptrayItem, (pnid->uFlags&NIF_MESSAGE)?pnid->uCallbackMessage:0); > SYSTRAY_ItemSetTip (*ptrayItem, (pnid->uFlags&NIF_TIP) ?pnid->szTip :"", FALSE); > > + LeaveCriticalSection(&systray_lock); > TRACE("%p: %p %s\n", (*ptrayItem), (*ptrayItem)->notifyIcon.hWnd, > (*ptrayItem)->notifyIcon.szTip); > return TRUE; > @@ -307,8 +374,12 @@ > { > SystrayItem *ptrayItem = systray; > > + TRACE("%p\n", pnid); > + > + EnterCriticalSection(&systray_lock); > while ( ptrayItem ) { > if ( SYSTRAY_ItemIsEqual(pnid, &ptrayItem->notifyIcon) ) { > + LeaveCriticalSection(&systray_lock); > if (pnid->uFlags & NIF_ICON) > SYSTRAY_ItemSetIcon(ptrayItem, pnid->hIcon); > if (pnid->uFlags & NIF_MESSAGE) > @@ -321,6 +392,7 @@ > } > ptrayItem = ptrayItem->nextTrayItem; > } > + LeaveCriticalSection(&systray_lock); > return FALSE; /* not found */ > } > > @@ -329,6 +401,9 @@ > { > SystrayItem **ptrayItem = &systray; > > + TRACE("%p\n", pnid); > + > + EnterCriticalSection(&systray_lock); > while (*ptrayItem) { > if (SYSTRAY_ItemIsEqual(pnid, &(*ptrayItem)->notifyIcon)) { > SystrayItem *next = (*ptrayItem)->nextTrayItem; > @@ -338,10 +413,12 @@ > free(*ptrayItem); > *ptrayItem = next; > > + LeaveCriticalSection(&systray_lock); > return TRUE; > } > ptrayItem = &((*ptrayItem)->nextTrayItem); > } > + LeaveCriticalSection(&systray_lock); > > return FALSE; /* not found */ > } > Index: dlls/x11drv/event.c > =================================================================== > RCS file: /home/wine/wine/dlls/x11drv/event.c,v > retrieving revision 1.29 > diff -u -r1.29 event.c > --- dlls/x11drv/event.c 21 Nov 2003 21:48:36 -0000 1.29 > +++ dlls/x11drv/event.c 30 Nov 2003 16:08:37 -0000 > @@ -3,6 +3,7 @@ > * > * Copyright 1993 Alexandre Julliard > * 1999 Noel Borthwick > + * 2003 Mike Hearn > * > * This library is free software; you can redistribute it and/or > * modify it under the terms of the GNU Lesser General Public > @@ -51,10 +52,15 @@ > > WINE_DEFAULT_DEBUG_CHANNEL(event); > WINE_DECLARE_DEBUG_CHANNEL(clipboard); > +WINE_DECLARE_DEBUG_CHANNEL(systray); > > /* X context to associate a hwnd to an X window */ > extern XContext winContext; > > +extern Atom systray_selection; > +extern Window systray_window; > + > + > #define DndNotDnd -1 /* OffiX drag&drop */ > #define DndUnknown 0 > #define DndRawData 1 > @@ -1213,7 +1219,47 @@ > static void EVENT_ClientMessage( HWND hWnd, XClientMessageEvent *event ) > { > if (event->message_type != None && event->format == 32) { > - if (event->message_type == x11drv_atom(WM_PROTOCOLS)) > + if (event->message_type == x11drv_atom(MANAGER)) { > + if (event->data.l[1] == systray_selection) { > + TRACE_(systray)("New NETWM systray manager detected, id=%ld\n", event->data.l[2]); > + /* NOTE: It turns out that the ability to detect when a new tray applet joins the > + * desktop is not as helpful as you might think. In order to do something useful with it, > + * we would need to be able to "store" icons unmapped as children of the root window while > + * no tray applet is available. > + * > + * The basic problem is that tray icons are always destroyed when the applet is removed. > + * This is apparently an issue with X itself, which the upcoming XFIXES extension should hopefully > + * address. The EggTrayIcon code which will be soon moving into GTK+ doesn't attempt to handle this > + * situation, so for now neither do we. > + * > + * This is theoretically fixable in Wine with enough work, we just have to modify the code in > + * shell32/systray.c to save the image and recreate the window on demand. Exactly how the > + * communication between the x11drv and shell32 takes place is left as an excercise for the > + * reader. > + * -mike (3rd August 2003) > + */ > + } > + } else if (event->message_type == x11drv_atom(_XEMBED)) { > + char* opcode; > + switch (event->data.l[1]) { > + case 0: opcode = "XEMBED_EMBEDDED_NOTIFY"; break; > + case 1: opcode = "XEMBED_WINDOW_ACTIVATE"; break; > + case 2: opcode = "XEMBED_WINDOW_DEACTIVATE"; break; > + case 3: opcode = "XEMBED_REQUEST_FOCUS"; break; > + case 4: opcode = "XEMBED_FOCUS_IN"; break; > + case 5: opcode = "XEMBED_FOCUS_OUT"; break; > + case 6: opcode = "XEMBED_FOCUS_NEXT"; break; > + case 7: opcode = "XEMEBD_FOCUS_PREV"; break; > + case 10: opcode = "XEMBED_MODALITY_ON"; break; > + case 11: opcode = "XEMBED_MODALITY_OFF"; break; > + case 12: opcode = "XEMBED_REGISTER_ACCELERATOR"; break; > + case 13: opcode = "XEMBED_UNREGISTER_ACCELERATOR"; break; > + case 14: opcode = "XEMBED_ACTIVATE_ACCELERATOR"; break; > + default: opcode = "[Unknown opcode]"; break; > + } > + TRACE_(systray)("XEmbed message, opcode is %s : %ld\n", opcode, event->data.l[1]); > + /* we currently don't handle these messages */ > + } else if (event->message_type == x11drv_atom(WM_PROTOCOLS)) > handle_wm_protocols_message( hWnd, event ); > else if (event->message_type == x11drv_atom(DndProtocol)) > { > Index: dlls/x11drv/window.c > =================================================================== > RCS file: /home/wine/wine/dlls/x11drv/window.c,v > retrieving revision 1.65 > diff -u -r1.65 window.c > --- dlls/x11drv/window.c 21 Nov 2003 21:48:36 -0000 1.65 > +++ dlls/x11drv/window.c 30 Nov 2003 16:08:37 -0000 > @@ -4,6 +4,7 @@ > * Copyright 1993, 1994, 1995, 1996, 2001 Alexandre Julliard > * Copyright 1993 David Metcalfe > * Copyright 1995, 1996 Alex Korobka > + * Copyright 2003 Mike Hearn > * > * This library is free software; you can redistribute it and/or > * modify it under the terms of the GNU Lesser General Public > @@ -24,6 +25,7 @@ > > #include <stdarg.h> > #include <stdlib.h> > +#include <stdio.h> > #ifdef HAVE_UNISTD_H > # include <unistd.h> > #endif > @@ -46,6 +48,7 @@ > #include "mwm.h" > > WINE_DEFAULT_DEBUG_CHANNEL(x11drv); > +WINE_DECLARE_DEBUG_CHANNEL(systray); > > extern Pixmap X11DRV_BITMAP_Pixmap( HBITMAP ); > > @@ -73,6 +76,7 @@ > "WM_PROTOCOLS", > "WM_DELETE_WINDOW", > "WM_TAKE_FOCUS", > + "MANAGER", > "KWM_DOCKWINDOW", > "DndProtocol", > "DndSelection", > @@ -81,6 +85,9 @@ > "_NET_WM_PID", > "_NET_WM_PING", > "_NET_WM_NAME", > + "_XEMBED_INFO", > + "_XEMBED", > + "_NET_SYSTEM_TRAY_OPCODE", > "XdndAware", > "XdndEnter", > "XdndPosition", > @@ -103,6 +110,14 @@ > "text/richtext" > }; > > +/* for XDG systray icons */ > +Atom systray_selection; > +Window systray_window; > +#define SYSTEM_TRAY_REQUEST_DOCK 0 > +#define SYSTEM_TRAY_BEGIN_MESSAGE 1 > +#define SYSTEM_TRAY_CANCEL_MESSAGE 2 > + > + > static LPCSTR whole_window_atom; > static LPCSTR client_window_atom; > static LPCSTR icon_window_atom; > @@ -354,11 +369,60 @@ > size_hints->min_height = size_hints->max_height; > size_hints->flags |= PMinSize | PMaxSize; > } > + if (win->dwExStyle & WS_EX_TRAYWINDOW) { > + /* force the window to be the correct width */ > + size_hints->min_width = GetSystemMetrics(SM_CXSMICON) + 5; /* give some padding to make icons not bunched up */ > + } > + > XSetWMNormalHints( display, data->whole_window, size_hints ); > XFree( size_hints ); > } > } > > +/*********************************************************************** > + * X11DRV_systray_dock_window > + * > + * Docks the given X window with the NETWM system tray. > + */ > +BOOL CALLBACK X11DRV_systray_dock_window( HWND hwnd, Display *display ) { > + WND* win = WIN_GetPtr((HWND)hwnd); > + struct x11drv_win_data *data = win->pDriverData; > + XEvent ev; > + unsigned long info[2]; > + LONG exstyle; > + > + /* is the window a tray window? */ > + if (IsWindowUnicode(hwnd)) > + exstyle = GetWindowLongW(hwnd, GWL_EXSTYLE); > + else > + exstyle = GetWindowLongA(hwnd, GWL_EXSTYLE); > + if ( !(exstyle & WS_EX_TRAYWINDOW) ) return TRUE; > + > + TRACE_(systray)("Docking tray icon 0x%x\n", (int)hwnd); > + > + > + /* set XEMBED protocol data on the window */ > + info[0] = 0; /* protocol version */ > + info[1] = 0; /* mapped = true */ > + XChangeProperty(display, data->whole_window, x11drv_atom(_XEMBED_INFO), x11drv_atom(_XEMBED_INFO), 32, PropModeReplace, (unsigned char*)info, 2); > + > + /* send the docking request message */ > + memset(&ev, 0, sizeof(ev)); > + ev.xclient.type = ClientMessage; > + ev.xclient.window = systray_window; > + ev.xclient.message_type = x11drv_atom(_NET_SYSTEM_TRAY_OPCODE); > + ev.xclient.format = 32; > + ev.xclient.data.l[0] = CurrentTime; > + ev.xclient.data.l[1] = SYSTEM_TRAY_REQUEST_DOCK; > + ev.xclient.data.l[2] = data->whole_window; > + XSendEvent(display, systray_window, False, NoEventMask, &ev); > + XSync(display, False); > + > + WIN_ReleasePtr(win); > + return TRUE; > +} > + > + > > /*********************************************************************** > * X11DRV_set_wm_hints > @@ -408,7 +472,7 @@ > set_size_hints( display, win ); > > /* systray properties (KDE only for now) */ > - if (win->dwExStyle & WS_EX_TRAYWINDOW) > + if ((win->dwExStyle & WS_EX_TRAYWINDOW) && (systray_window == None)) > { > int val = 1; > XChangeProperty( display, data->whole_window, x11drv_atom(KWM_DOCKWINDOW), > @@ -709,10 +773,19 @@ > static void create_desktop( Display *display, WND *wndPtr ) > { > X11DRV_WND_DATA *data = wndPtr->pDriverData; > - > + char *systray_buffer; > + > wine_tsx11_lock(); > winContext = XUniqueContext(); > XInternAtoms( display, (char **)atom_names, NB_XATOMS - FIRST_XATOM, False, X11DRV_Atoms ); > + > + /* we can't intern this with the rest as it depends on the screen we are connecting to */ > + systray_buffer = HeapAlloc(GetProcessHeap(), 0, sizeof(char)*20); > + sprintf(systray_buffer, "_NET_SYSTEM_TRAY_S%d", DefaultScreen(display)); > + systray_selection = XInternAtom(display, systray_buffer, False); > + HeapFree(GetProcessHeap(), 0, systray_buffer); > + > + > wine_tsx11_unlock(); > > whole_window_atom = MAKEINTATOMA( GlobalAddAtomA( "__wine_x11_whole_window" )); > @@ -1109,6 +1182,14 @@ > * we do a proper ShowWindow later on */ > if (wndPtr->dwStyle & WS_VISIBLE) cs->style |= WS_VISIBLE; > > + /* if it's a tray window, dock it */ > + if (wndPtr->dwExStyle & WS_EX_TRAYWINDOW) { > + /* get the tray window if present */ > + systray_window = XGetSelectionOwner(display, systray_selection); > + if (systray_window != None) > + X11DRV_systray_dock_window(hwnd, display); > + } > + > WIN_ReleaseWndPtr( wndPtr ); > return TRUE; > > Index: dlls/x11drv/x11drv.h > =================================================================== > RCS file: /home/wine/wine/dlls/x11drv/x11drv.h,v > retrieving revision 1.11 > diff -u -r1.11 x11drv.h > --- dlls/x11drv/x11drv.h 25 Nov 2003 03:27:38 -0000 1.11 > +++ dlls/x11drv/x11drv.h 30 Nov 2003 16:08:37 -0000 > @@ -387,6 +387,7 @@ > XATOM_WM_PROTOCOLS, > XATOM_WM_DELETE_WINDOW, > XATOM_WM_TAKE_FOCUS, > + XATOM_MANAGER, > XATOM_KWM_DOCKWINDOW, > XATOM_DndProtocol, > XATOM_DndSelection, > @@ -395,6 +396,9 @@ > XATOM__NET_WM_PID, > XATOM__NET_WM_PING, > XATOM__NET_WM_NAME, > + XATOM__XEMBED_INFO, > + XATOM__XEMBED, > + XATOM__NET_SYSTEM_TRAY_OPCODE, > XATOM_XdndAware, > XATOM_XdndEnter, > XATOM_XdndPosition, > > >

2 3

Re: Implement support for NETWM utility window type
by Mike Hearn 05 Dec '03

05 Dec '03

Hi Alexandre, This too missed the last couple of commits. Did I get the style stuff wrong? On Mon, 2003-12-01 at 00:40, Mike Hearn wrote: > ChangeLog: > Map (WS_EX_TOOLWINDOW & WS_CAPTION) to _NET_WM_WINDOW_TYPE_UTILITY. > This makes Delphi a bit easier to use, as floating palettes aren't > unmanaged anymore. > > Index: dlls/x11drv/x11drv.h > =================================================================== > RCS file: /home/wine/wine/dlls/x11drv/x11drv.h,v > retrieving revision 1.11 > diff -u -b -r1.11 x11drv.h > --- dlls/x11drv/x11drv.h 25 Nov 2003 03:27:38 -0000 1.11 > +++ dlls/x11drv/x11drv.h 1 Dec 2003 00:38:03 -0000 > @@ -395,6 +395,8 @@ > XATOM__NET_WM_PID, > XATOM__NET_WM_PING, > XATOM__NET_WM_NAME, > + XATOM__NET_WM_WINDOW_TYPE, > + XATOM__NET_WM_WINDOW_TYPE_UTILITY, > XATOM_XdndAware, > XATOM_XdndEnter, > XATOM_XdndPosition, > Index: dlls/x11drv/window.c > =================================================================== > RCS file: /home/wine/wine/dlls/x11drv/window.c,v > retrieving revision 1.65 > diff -u -b -r1.65 window.c > --- dlls/x11drv/window.c 21 Nov 2003 21:48:36 -0000 1.65 > +++ dlls/x11drv/window.c 1 Dec 2003 00:38:03 -0000 > @@ -81,6 +81,8 @@ > "_NET_WM_PID", > "_NET_WM_PING", > "_NET_WM_NAME", > + "_NET_WM_WINDOW_TYPE", > + "_NET_WM_WINDOW_TYPE_UTILITY", > "XdndAware", > "XdndEnter", > "XdndPosition", > @@ -119,7 +121,8 @@ > if (win->dwExStyle & WS_EX_TRAYWINDOW) return TRUE; > /* child windows are not managed */ > if (win->dwStyle & WS_CHILD) return FALSE; > - /* tool windows are not managed */ > + /* tool windows are not managed unless they have a caption */ > + if ((win->dwExStyle & WS_EX_TOOLWINDOW) && ((win->dwStyle & WS_CAPTION) == WS_CAPTION)) return TRUE; > if (win->dwExStyle & WS_EX_TOOLWINDOW) return FALSE; > /* windows with caption or thick frame are managed */ > if ((win->dwStyle & WS_CAPTION) == WS_CAPTION) return TRUE; > @@ -424,6 +427,12 @@ > XChangeProperty(display, data->whole_window, x11drv_atom(_NET_WM_PID), > XA_CARDINAL, 32, PropModeReplace, (char *)&i, 1); > > + /* map WS_EX_TOOLWINDOW to _NET_WM_WINDOW_TYPE_UTILITY */ > + if ((win->dwExStyle & WS_EX_TOOLWINDOW) && (win->dwStyle & WS_CAPTION)) { > + Atom a = x11drv_atom(_NET_WM_WINDOW_TYPE_UTILITY); > + XChangeProperty(display, data->whole_window, x11drv_atom(_NET_WM_WINDOW_TYPE), XA_ATOM, 32, PropModeReplace, (char*)&a, 1); > + } > + > mwm_hints.flags = MWM_HINTS_FUNCTIONS | MWM_HINTS_DECORATIONS; > mwm_hints.functions = 0; > if ((win->dwStyle & WS_CAPTION) == WS_CAPTION) mwm_hints.functions |= MWM_FUNC_MOVE; > @@ -785,6 +794,8 @@ > 0 ); > } > > + > + > /* non-maximized child must be at bottom of Z order */ > if ((win->dwStyle & (WS_CHILD|WS_MAXIMIZE)) == WS_CHILD) > { > > >

2 3

Who maintains the imagehlp dll?
by Andrew de Quincey 05 Dec '03

05 Dec '03

Now that I have IDA nearly sorted, I was wondering.. who maintains the imagehlp dll? It seems kinda empty, and I'm sure it was at one point more complete (I looked into wine some time ago). I ask this because about a year or so ago I got about 3/4 of the way through reverse engineering the Windows PDB formats (up to those supported by VS.NET). If I had an actual implementation goal in mind and feedback from people using it, I might actually be bothered to finish it off.... Incidentally, I have years of reverse engineering experience.. if anyone wants me to look at anything, feel free to drop me a line (for an example, see the recently released reverse engineered opensource nforce ethernet driver, forcedeth).

5 4

Re: wine/dlls/x11drv x11drv_main.c
by Rein Klazes 05 Dec '03

05 Dec '03

On Thu, 4 Dec 2003 15:59:51 -0600, you wrote: > Log message: > Initialize Xlib threading support to see what it breaks... Thanks for the warning! Just about everything here halts after a few minutes: | err:ntdll:RtlpWaitForCriticalSection section 0x40380db0 "?" wait timed out in thread 000e, blocked by 0000, retrying (60 sec) | err:ntdll:RtlpWaitForCriticalSection section 0x40380db0 "?" wait timed out in thread 000e, blocked by 0000, retrying (60 sec) | err:ntdll:RtlpWaitForCriticalSection section 0x40380db0 "?" wait timed out in thread 000e, blocked by 0000, retrying (60 sec) | err:ntdll:RtlpWaitForCriticalSection section 0x40380db0 "?" wait timed out in thread 000e, blocked by 0000, retrying (60 sec) | err:ntdll:RtlpWaitForCriticalSection section 0x40380db0 "?" wait timed out in thread 000e, blocked by 0000, retrying (60 sec) The easiest way to reproduce it here is switching to another workspace and back again. After reversing the patch everything is as stable as before. Debian unstable, glibc 2.3.2 on standard kernel 2.4.22 - no nptl - and xfree86 4.2.1. Rein. -- Rein Klazes rklazes(a)xs4all.nl

2 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel