- wine-devel - winehq.org

Re: Using a windows dll from a winelib or possibly native linux app.
by Jon Griffiths 10 Dec '03

10 Dec '03

Hi Arthur, > the generated vendor.dll.so file does contain the correct > symbols but they are undefined. By any chance is the vendor dll implemented in C++? If not, this should work. If so, you have a bit of a problem, and one that no-one has seriously tried to overcome (or at least if they have, they haven't documented it). If the dll exports mangled names (_??xxx in the .spec file) then linking cannot occur when you build with gcc because gcc uses a different name mangling scheme. You would need to include stubs to call the real functions and export these with the gcc-mangled names, either by reimplementing the functions inside the dll, or calling through to the real dll with function pointers and GetProcAddress(). Are the vender dll/headers redistributable? Cheers, Jon __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/

1 0

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

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 makin

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 M

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 makin

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

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

JournalPlayBack hook
by Juan Antonio Boscá Lloret 03 Dec '03

03 Dec '03

Hello, I'm trying to use the JournalPlayBack hook in a Win32 application and it doesn't work. However it looks to work in 16 bits. Any idea? Thank you --------------------------------------------------------------- Juan Antonio Boscá Lloret Departamento Programación CAE, S.A. jabosca(a)edicurs.com ---------------------------------------------------------------

3 2

Question about simple profiling implementation
by Andrew de Quincey 03 Dec '03

03 Dec '03

Hi, the last thing I have to do with the profiling stuff is the trickiest: To decide what is the best way to determine the times. To get times that are useful, I'm using the RDTSC opcode (which returns the number of CPU clock cycles since the machine was powered on).. basically I've added a couple of defines to wine/debug.h: #define GET_COUNTER(__COUNTER) __asm__ __volatile__ ( "rdtsc" : "=a" (__COUNTER.LowPart), "=d" (__COUNTER.HighPart) ) and theres another, GET_ELAPSED which takes a start time, and calculates the difference. (BTW: I don't think these names are very good; I'm going to change them) The elapsed value is output when the relay trace for the function return is printed. I've also created a new script to analyse these to give you the average times, total times etc, and I've fixed tools/examine-relay to cope with the addition to the trace output. The problem is.. not all i386-derived CPUs support this feature. As far as I can see there are three ways of determining this. Which would people prefer? 1) Check in /proc/cpuinfo for the "tsc" flag. 2) I could write a short amount of assembly to interrogate the chip itself for this feature (a couple of instructions) 3) Use the existing QueryPerformanceCounter(). Personally, I'm favouring (2)... but what do other people think?

6 12

Re: debugger problems
by Chris Morgan 03 Dec '03

03 Dec '03

Nope, still doesn't appear to work. Rein, you see the same? Chris On Sunday 30 November 2003 11:08 am, Eric Pouech wrote: > Chris Morgan wrote: > > Still isn't working with build from todays cvs. Is this patch in there? > > it seems that AJ applied it after your mail had been sent > A+

5 10

Re: bc21en209 at Odin
by Dietrich Teickner 03 Dec '03

03 Dec '03

Hi Craig, The best way is for the future the first, removing '\\?\' in Odin and Wine. This way will need some times in odin, we are not prepaired for this, And I have no update access for wine. I will try to inform wine about the problem. I thing You have implemented this methods and You modify this without full forthing w98-api. This can us help for this build. We can test BC2.1 and can work with them as w2k(without , and we can also test the new api modifications. The switch should only force the w98 behavior in the path handling. For 'all', Odin and Wine can set the configuration-file. And Wine and Odin should work in the next time at the \\?\ problem. Please save also the last BC2.0 Build. Dietrich Scooter Support wrote: > Hi Dietrich, > > That would definitely cause problems in BC. We detect the Windows > version on startup and when running under WinNT4/2K/XP we use the \\?\ > notation for all file access, including sessions and rules. Under > Win9x we use the standard ANSI functions. > > In our current usage it wouldn't be a problem if ODIN simply removed > the \\?\ prefix and converted the paths back to ANSI. If it would be > easier I can add a command line switch to force BC to use the Win9x > behavior. > > Best Regards, > Craig > > > >>Hi Craig, > > >>I know where the problenm is in the comunication between BC21 and Odin. >>BC21 used only the long path notation for the filenames if the version >>set in Odin (Wine ?) as w2k or xp. If I set Win98 (nt4.0?), I have no >>problems with accessing folders. >>Currently is the \\?\h:\... notation only partialy supported in >>Odin (for eCS or OS/2) and in >>wine (for Linux). > > >>Start in native w98 ok, >>also in my xp >>Also in w98 in virtual PC. > > >>Can it be that many problems comes from the \\?\ prefix ? >>Also no access to the session database ? > > >>Best regards, >>Dietrich > > >>Log as w2k > > >>t01 ( 0): (FS=150B) KERNEL32: GetVersionExA 19ee88 >>t01 ( 0): (FS=150B) Kernel32:Odin profile:('WinVersion','Version',''): >>returning 'Win2000' >>t01 ( 0): (FS=150B) version 5.0 >>t01 ( 0): (FS=150B) build nr 893 >>t01 ( 0): (FS=150B) Platform Id 2 >>t01 ( 0): (FS=150B) szCSDVersion Service Pack 2 >>... >>t02 ( 0): attachThread to dll NTDLL.DLL >>t02 ( 0): attachThread to dll NTDLL.DLL DONE >>t02 ( 0): attachThread to dll GDI32.DLL >>t02 ( 0): attachThread to dll GDI32.DLL DONE >>t02 ( 0): KERNEL32: ResetEvent 33 >>t02 ( 0): KERNEL32: ResetEvent returned 1 >>t02 ( 0): KERNEL32: ResetEvent 2f >>t02 ( 0): KERNEL32: ResetEvent returned 1 >>t02 ( 0): KERNEL32: GetDriveTypeA 2003f1b8 >>t02 ( 1): KERNEL32: GetDriveType h:\ = 3 >>t02 ( 0): KERNEL32: GetDriveTypeA returned 3 >>t02 ( 0): KERNEL32: GetFileAttributesW 3016994 >>t02 ( 1): KERNEL32: SetLastError to 123 >>t02 ( 1): KERNEL32: GetFileAttributes of \\?\h:\ returned -1 >>t02 ( 0): KERNEL32: GetFileAttributesW returned ffffffff >>t02 ( 0): KERNEL32: GetLastError returned 123 >>t02 ( 0): KERNEL32: SetLastError to 123 >>t02 ( 0): KERNEL32: RaiseException eedfade 1 7 327fd80 >>t02 ( 1): KERNEL32: RaiseException(0eedfadeh) >>t02 ( 1): KERNEL32: RtlDispatchException entered >>t02 ( 1): Win32 exception chain: > > >>Log as w98 > > >>t01 ( 0): (FS=150B) KERNEL32: SetEnvironmentVariable HOMEPATH to \ >>t01 ( 0): (FS=150B) KERNEL32: GetVersionExA 19ee88 >>t01 ( 0): (FS=150B) Kernel32:Odin profile:('WinVersion','Version',''): >>returning 'Win98' >>t01 ( 0): (FS=150B) version 4.a >>t01 ( 0): (FS=150B) build nr 40a07ce >>t01 ( 0): (FS=150B) Platform Id 1 >>t01 ( 0): (FS=150B) szCSDVersion Win98 > > >>.. > > >>t02 ( 0): attachThread to dll GDI32.DLL >>t02 ( 0): attachThread to dll GDI32.DLL DONE >>t02 ( 0): KERNEL32: ResetEvent 33 >>t02 ( 0): KERNEL32: ResetEvent returned 1 >>t02 ( 0): KERNEL32: ResetEvent 2f >>t02 ( 0): KERNEL32: ResetEvent returned 1 >>t02 ( 0): KERNEL32: GetDriveTypeA 2003ea14 >>t02 ( 1): KERNEL32: GetDriveType h:\ = 3 >>t02 ( 0): KERNEL32: GetDriveTypeA returned 3 >>t02 ( 0): KERNEL32: GetFileAttributesA 2003e9f4 >>t02 ( 1): KERNEL32: GetFileAttributes of h:\ returned 16 >>t02 ( 0): KERNEL32: GetFileAttributesA returned 10 >>t02 ( 0): KERNEL32: SetErrorMode 1 >>t02 ( 1): KERNEL32: SetErrorMode(00000001h) >>t02 ( 0): KERNEL32: SetErrorMode returned 0 >>t02 ( 0): KERNEL32: GetVolumeInformationA 2003ea24 329fc8b 104 2003ea3c >>2003ea40 2003ea44 329fb86 104 >>t02 ( 1): GetVolumeInformationA h:\ >>t02 ( 1): KERNEL32: SetErrorMode(00000001h) > > >

1 0

I found what I believe is a bug in include/wine/prsht.h in ReactOS
by Jonathan Wilson 03 Dec '03

03 Dec '03

cc-ing WINE list in case its also present in the WINEHQ CVS this line: typedef const PROPSHEETPAGEA *LPCPROPSHEETPAGEW; should (I believe) be this line: typedef const PROPSHEETPAGEW *LPCPROPSHEETPAGEW; If this is a bug, can someone fix it? If its not, can someone explain why this construct is present (it looks very wierd to mix an A structure and a W structure in this typedef)

4 5

Re: winetest: the Wine test shell
by Ferenc Wagner 03 Dec '03

03 Dec '03

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > -- removed the CROSS compilation support. It should work > with a different build tree, but I haven't tested that Works just fine, thanks! Interestingly, yesterday evening I got all kinds of problems, like the build process trying to run WINDRES=false in the elf tree and other silly things. :) > -- removed striping the tests from the build. This wasn't > right for multiple reasons: > * it was using a hardcoded 'strip' command instead > of the configure one What about the following in maketest(s? cf. 8.3) STRIP="$3" DLLEXT="$4" [...] filename="$BINDIR/${test}_test.exe$DLLEXT" [...] $STRIP -s $filename and in Makefile.in (cf. tests.list vs 8.3 again): winetest.rc: maketest tests.list $(SRCDIR)/maketest -r $(SRCDIR)/tests.list "$(STRIP)" "$(DLLEXT)" > $@ || ( $(RM) $@ && exit 1 ) > * it seems strange that building winetest should > magically affect all the tests Maybe. But nothing depends on those, so I can't see it cause problems. And stripping reduces the final size of the program by an order of magnitude! It counts on a not-so-wide download link. > * why should we strip every time Stripping stripped programs doesn't take much time or effort. > Maybe we should replace this with an explicit > make strip-tests > or some such. Suggestins are welcome. Another possibility is to $STRIP -s -o ${testname}_test.exe$DLLEXT $filename It's sterile, but I'm not sure if it's better. > But I think it looks decent enough that it can go in, so we > can start sending small incremental patches to it. Shall not we put copyright notices into the files? > + if (remove (logname)) > + fatal (strmake (NULL, "Can't remove logfile: %d.", errno)); Maybe a warning would be enough here, too... :) Not that it makes any difference, of course. Best wishes, Feri.

1 0

Re: [clock04] Tidy up resources
by Alexandre Julliard 03 Dec '03

03 Dec '03

Richard Cohen <richard(a)daijobu.co.uk> writes: > Alexandre Julliard wrote: > > Your mailer has corrupted the 8-bit chars, could you please resend >> differently? > > Hmm, .. mozilla sent it as text/plain,8-bit,inline > Looks fine to me, and I can save and apply the patch OK. You are right, the problem was on my side; looks like a recent update had broken my sendmail config. My apologies to your mailer <g> -- Alexandre Julliard julliard(a)winehq.com

1 0

IDA speed problem analysis
by Andrew de Quincey 03 Dec '03

03 Dec '03

Hi, I've been doing some more work on this, and I think I've found the culprit (my apologies to everyone for the crap I've been talking recently). Whenever IDA opens the Save box.. and in fact when it does a lot of operations, it seems to completely regenerate its menus. It uses an MDI interface, and so uses the WM_MDISETMENU message to set menus. The problem function is controls/menu.c/SetMenu(). Specifically, the call to SetWindowPos() passing the SWP_FRAMECHANGED flag. If I comment this call out, IDA becomes very fast... as fast as is it in windows. If I add in Y copies of that call, IDA becomes about Y times slower. Looking at the docs on MSDN for WM_MDISETMENU, it says "After sending this message, an application must call the DrawMenuBar function to update the menu bar". Which implies that the application is in charge of telling the menu bar to redraw, meaning the call to SetWindowPos() is superfluous. However, SetMenu() is used non by MDI menus as well, which DO expect the menu to be updated automatically (MSDN: "The window is redrawn to reflect the menu change"), which means it can't just be removed. Does anyone have any suggestions for the cleanest way to resolve this? Perhaps MDI should have an internal copy of SetMenu() tailored to its needs? BTW, under windows, the MDI code does not call the USER32.SetMenu() function.

1 0

Re: WineX 3.2
by Ivan Leo Murray-Smith 03 Dec '03

03 Dec '03

My free RPMs can't hurt Transgaming. For a start, on my winex page, I have a complete list of the features that only the commercial version has, and an invitation to subscribe to Transgaming if you want those extra features. As the freeware version doesn't include installshield, lots of games won't even install with the freeware version, for a start max payne. Also, even if a game does work, it won't run full screen, so if a users has lots of games that work with the free version, but wants them to run full screen, he'll probably go to the transgaming store. For all these reasons, I don't think my free RPMs are a financial threat to Transgaming in any way. Transgaming has taken a lot from Wine (Well it wouldn't have much to sell without wine), and I don't think there is anything wrong if someone takes something back. I think Transgaming should worry about those web sites that distribute the full commercial version of WineX, you just have to look for winex 3.2 download free on google , I reported this to Transgaming many months ago, and they still haven't taken any action. Ivan.

2 1

64bit Wine?
by J. Grant 02 Dec '03

02 Dec '03

Hello I'm considering getting an Opteron. With this being a 64bit CPU I wondered if there would be any issues with using WINE to make use of win32 software on this 64bit CPU. Kind regards JG p.s. I'm not subscribed to this list from this email address, so please include my email address in any replies.

4 4

wine in the press
by Tom 02 Dec '03

02 Dec '03

http://www.osnews.com/story.php?news_id=5262 ill add it to the press page in a couple days ill look around for other articles as well. Tom

2 1

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