wine-devel

wine-devel@winehq.org

84471 discussions

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

SSTab, Tabctl32.ocx again
by Fabian Cenedese 05 Dec '03

05 Dec '03

Hi I have a VB6 program which fails on wine due to the Tab control SSTab from TabCtl32.ocx as other users have reported too. Should this already work? Is this part of the work of improving wine for VB programs? Maybe it's not the tab control itself but one of its parts. I made a trace and this is the part shortly before the error message comes: fixme:ole:SPCF_CreateInstance (0x412d2408,(nil),{7bf80980-bf32-101a-8bbb-00aa00300cab},0x40669ea4), creating stdpic with PICTYPE_NONE. trace:ole:OleCreatePictureIndirect (0x40911d28,0x212f53d8,1,0x40669ea4) trace:ole:OLEPictureImpl_Construct (0x40911d28) type = 0 0009:Call ntdll.RtlAllocateHeap(405e0000,00000008,00000050) ret=412941cd 0009:Ret ntdll.RtlAllocateHeap() retval=40669f00 ret=412941cd 0009:Call ntdll.RtlAllocateHeap(405e0000,00000000,00000028) ret=41281227 0009:Ret ntdll.RtlAllocateHeap() retval=40669f58 ret=41281227 0009:Call ntdll.RtlAllocateHeap(405e0000,00000008,00000028) ret=41281282 0009:Ret ntdll.RtlAllocateHeap() retval=40669f88 ret=41281282 trace:ole:ConnectionPointImpl_QueryInterface (0x40669f58)->({b196b286-bab4-101a-b69c-00aa00341d07}, 0x40669f3c) trace:ole:ConnectionPointImpl_AddRef (0x40669f58)->(ref=1) trace:ole:ConnectionPointImpl_Release (0x40669f58)->(ref=2) trace:ole:OLEPictureImpl_Construct returning 0x40669f00 trace:ole:OLEPictureImpl_QueryInterface (0x40669f00)->({7bf80980-bf32-101a-8bbb-00aa00300cab}, 0x40669ea4) trace:ole:OLEPictureImpl_AddRef (0x40669f00)->(ref=1) trace:ole:OLEPictureImpl_Release (0x40669f00)->(ref=2) trace:ole:OLEPictureImpl_QueryInterface (0x40669f00)->({00000109-0000-0000-c000-000000000046}, 0x40911dd8) trace:ole:OLEPictureImpl_AddRef (0x40669f00)->(ref=1) trace:ole:OLEPictureImpl_Load (0x40669f00,0x4182036c) 0009:Call ntdll.RtlAllocateHeap(405e0000,00000008,00000000) ret=412968dc 0009:Ret ntdll.RtlAllocateHeap() retval=40669fb8 ret=412968dc 0009:Call user32.CreateIconFromResourceEx(40669fb8,00000000,00000001,00030000,00000000,00000000,00000000) ret=41295ed6 0009:Call gdi32.DIB_BitmapInfoSize(40669fb8,00000000) ret=40b0ae1b 0009:Ret gdi32.DIB_BitmapInfoSize() retval=01780108 ret=40b0ae1b 0009:Ret user32.CreateIconFromResourceEx() retval=00000000 ret=41295ed6 fixme:ole:OLEPictureImpl_Load CreateIcon failed. trace:ole:OLEPictureImpl_Release (0x40669f00)->(ref=2) Looks like it's something with pictures that actually fails. Does this tell anyone anything? Do I need to re-register something else? Maybe some type library? Can I get more info with other debug channels? Or am I out of luck? Thanks bye Fabi

1 0

Status of InstallShield-Setup Engine
by Andreas Rosenberg 05 Dec '03

05 Dec '03

Hi! I'm new to this list. The company I'm working for, is developing software for Windows and as a personal Linux fan I was testing our software with Wine from time to time. The last tries (several month ago) were still pretting bad, but with the Wine from Suse 9.0 (snapshot from August 2003) there were only "trivial" errors (mostly conformance) which we were able to circumwent in our software. I tracked all problems and reported them als bugs: (1844, 1845, 1847, 1848) together with a patch for two of them. b.t.w I'm using a different eMail account with this mailing list as with the Wine Bugzilla. We have a customer, who already asked for a version of our software being able to run on Linux. What's seems to be a big problem, is the InstallShield Setup Engine we are using (like many others). A played around with it and it crashed in different ways. I looked into the bug list and found the rather old "meta bug" #170. Unfortunately the link inside is broken. Perhaps we can contribute in making the InstallShield Setup Engine work. Has anybody tracked what's causing the problem? I read about "global window handles", but this didn't gave me the right clue. Is it related with the API call FindWindow? Is the IS Setup Engine using multiple processes and trying to communicate via window messages or DDE? If anybody could point me in the right direction, this would be great. Otherwise it would be a waste of resources to debug/search stuff others already did. Regards Andy

5 5

Re: PATCH for Bugs 1844 and 1845
by Alexandre Julliard 05 Dec '03

05 Dec '03

Andreas Rosenberg <sonix2003(a)ctf-z.de> writes: > 1844: Point Size in DLG_TEMPLATE may be negative (with DS_SETFONT) > > Within Windows the pointSize parameter (for the FONT in the DLG_TEMPLATE > struct) may be a signed 16-bit integer. With WINE this integers get's > converted to an unsigned int resulting in huge font for the dialog. The size > of the dialog is being computed based on this font and results in invalid > parameters for CreateWindow, that may cause a termination of WINE. We detected > this problem testing our software with WINE. The fix for pointSize is OK, but why did you also change the sign of the font height in the CreateFont call? This doesn't look right. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: menu: nasty bug in menu tracking
by Alexandre Julliard 05 Dec '03

05 Dec '03

Andrew de Quincey <adq_dvb(a)lidskialf.net> writes: > The problem is that MSG.lParam is NOT necessarily in screen coordinates (even > though the comment I have removed says they are). As I can't trust the MSG.pt > either, this means using GetCursorPos() to determine the mouse position in > screen coordinates. This is wrong, you have to use lParam, as the comment says. And the coordinates are always in screen coords when we are tracking the menu. Something else must be going on here. -- Alexandre Julliard julliard(a)winehq.com

2 4

RE: menu: nasty bug in menu tracking
by Mike Jackson 05 Dec '03

05 Dec '03

Actually I think the code would work better like this:- if ((msg.message >= WM_MOUSEFIRST) && (msg.message <= WM_MOUSELAST)) { mt.pt.x = (short)LOWORD(msg.lParam); mt.pt.y = (short)HIWORD(msg.lParam); ClientToScreen(msg.hwnd,&mt.pt); -----Original Message----- From: wine-patches-admin(a)winehq.com [mailto:wine-patches-admin@winehq.com] On Behalf Of Andrew de Quincey Sent: Friday, 5 December 2003 8:45 AM To: wine-patches Subject: menu: nasty bug in menu tracking In IDA, the menus don't work correctly... as you move down a menu, the wrong item is highlighted if you move to a submenu.. after that, the wrong menu is opened and other bad things occur. The problem is that MSG.lParam is NOT necessarily in screen coordinates (even though the comment I have removed says they are). As I can't trust the MSG.pt either, this means using GetCursorPos() to determine the mouse position in screen coordinates. BTW: MSDN says this about the MSG.lParam value for WM_MOUSEMOVED events: lParam The low-order word specifies the x-coordinate of the cursor. The coordinate is relative to the upper-left corner of the client area. The high-order word specifies the y-coordinate of the cursor. The coordinate is relative to the upper-left corner of the client area.

2 1

Re: wine/ programs/Makefile.in ./configure.ac ./co ...
by Ferenc Wagner 05 Dec '03

05 Dec '03

Alexandre Julliard <julliard(a)winehq.org> writes: > Added files: > programs/winetest: winetest.h util.c send.c maketest main.c > Makefile.in .cvsignore First of all, thank you very much for adapting and putting this into the tree! Losing some of the automation is not a problem as we seldom have new modules to test. But we've got an error in the cross-configured tree: tba:/usr/local/src/wine/pe/dlls/msvcrt/tests/ $ make i586-mingw32msvc-gcc cpp.o file.o heap.o scanf.o testlist.o -o msvcrt_test.exe -L../../../dlls -lmsvcrt -L../../../libs/wine -lwine -L../../../libs/port -lwine_port -lm ../../../dlls/libmsvcrt.a(ds00464.o)(.text+0x0): multiple definition of `atexit' /usr/lib/gcc-lib/i586-mingw32msvc/2.95.3-7/../../../../i586-mingw32msvc/lib/crt2.o:/home/ron/devel/debian/mingw32-runtime/mingw32-runtime-3.2/build_dir/src/mingw-runtime-3.2/crt1.c:266: first defined here ../../../dlls/libmsvcrt.a(ds00332.o)(.text+0x0): multiple definition of `_onexit' /usr/lib/gcc-lib/i586-mingw32msvc/2.95.3-7/../../../../i586-mingw32msvc/lib/crt2.o:/home/ron/devel/debian/mingw32-runtime/mingw32-runtime-3.2/build_dir/src/mingw-runtime-3.2/crt1.c:274: first defined here make: *** [msvcrt_test.exe] Error 1 On the other hand, $ i586-mingw32msvc-gcc cpp.o file.o heap.o scanf.o testlist.o -o msvcrt_test.exe works all right, and makes winetest.exe build flawlessly. Best wishes, Feri.

4 4

direct X 9 and troubles ..
by Lars Segerlund 04 Dec '03

04 Dec '03

Hi, I don't know how far along the directX9 support in wine is, and I am having trouble getting a game to run to which there is a downloadable demo (http://www.gamershell.com/news_BMotoGP2BDemo.shtml) which I thought might be usefull. The question is, should this run ? Is there something I have configured wrongly ? ( I have tried it on two different machines with different settings and hardware + soft OpenGL and hardware OpenGL ). Still it beats me .. any help appreciated if only 'no this should not work' .. / regards, Lars Segerlund.

2 1

warning fixes in comctl32.dll
by Jonathan Wilson 04 Dec '03

04 Dec '03

I just posted a patch to the reactos list that gets whatever comctl32.dll reactos has building with -Wall -Werror. But I dont have a WINE tree or any way to "port" these fixes over to WINEHQ. Can someone do it for me?

2 1

Re: sysparams: slight optimisation for IDA 3
by Dmitry Timoshkov 04 Dec '03

04 Dec '03

"Andrew de Quincey" <adq_dvb(a)lidskialf.net> wrote: > Version 3 > + spi_idx = SPI_GETICONTITLELOGFONT; > + > + if (!spi_loaded[spi_idx]) > + { > + memcpy(lpLogFont, &iconTitleLogFont, sizeof(LOGFONTA)); > + break; > + } Sorry to bother you again, but probably the comparison statement needs to be reverted... -- Dmitry.

7 10

Sound capture issues...
by Thomas Brix Larsen 04 Dec '03

04 Dec '03

Hi list, in the voice com program Skype (www.skype.org), I'm able to hear other people but I can't talk to them myself. Does anyone have a clue why? I believe this program uses DirectX to capture voice input. Not implented? Greetings, --Thomas _________________ My worst enemy gave me a copy of Windows...

2 3

Font matching algorithms
by Mike Hearn 04 Dec '03

04 Dec '03

Hi, Recently Wine CVS has started always matching "System" to "Bitstream Vera Mono", and nothing I alter in the config file can seem to change it. This is kind of annoying as it's not a very good match, I'd rather it used Vera Sans, is there a way to override Wines choice? thanks -mike

1 0

Re: new old winetests
by Brian Vincent (C) 04 Dec '03

04 Dec '03

>> -- we're linking against ws2_32 >> Is this DLL available on all versions of Windows we >> want to run on? > >As far I know ><http://msdn.microsoft.com/library/en-us/winsock/winsock/windows_sockets_st art_page_2.asp> >yes. But I am not sure whether it is installed in the base >system or only an option if you want to have networking >(like on Win3.1). Probably not too many people would run >the tests on a standalone machine anyway, but who knows... I actually just ran into this the other night. I installed TaxCut 2003 (which, by the way, mostly works with a few native DLL's) when it didn't like Wine's ws2_32. According to the references built into TaxCut this wasn't part of the original Win95 that shipped. It came out shortly after as an add-on and was likely first included in OSR2. --------------- Brian Vincent Copper Mountain Telecom vincentb(a)coppercolorado.com

6 8

Re: Missing msvcmaker .cvsignores 1
by Jakob Eriksson 04 Dec '03

04 Dec '03

:-D Shachar Shemesh wrote: > Ferenc Wagner wrote: > >> There will be no further parts, sorry. >> >> Feri. >> >> >> > Nobody expects the Spanish Inquisition! Our chief weapon is suprise. > Suprise and fear. Fear and suprise. Are TWO weapons are fear, suprise, > and ruthless eficiency. >

1 0

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