wine-devel January 2007

wine-devel@winehq.org

137 participants
274 discussions

comctl32/tests/updown failures on xp?
by Dan Kegel 19 Jan '07

19 Jan '07

While getting ready for cs130 (thanks to Lei and James for all the help), I tried building and running comctl32/tests/updown.c standalone on winxp using Visual C++ Express 2005 (the freely downloadable one) and the Platform SDK (also freely downloadable, needed for e.g. user32.lib and .h files). First I tried building it by starting cmd with the visual studio environment vars defined (using the handy Start/Programs/Visual C++/Visual Studio Tools/Visual Studio Command Prompt start menu entry installed by visual C++): cl -DSTANDALONE -D_X86_ -I../../../include updown.c user32.lib gdi32.lib comctl32.lib This failed to compile, complaining about redefinitions in rpc.h. I worked around that as suggested by Lei Zhang by avoiding letting cl see any of the Wine headers but wine/test.h, by doing mkdir wine copy ..\..\..\include\wine\test.h wine cl -DSTANDALONE -D_X86_ updown.c user32.lib gdi32.lib comctl32.lib This failed to compile, complaining about WM_QUERYVISTATE being undefined. I worked around that as suggested by Lei Zhang by defining _WIN32_WINNT to the right value: cl -DSTANDALONE -D_X86_ -D_WIN32_WINNT=0x502 updown.c user32.lib gdi32.lib comctl32.lib That failed to link, complaining it couldn't find user32.lib. I worked around that by doing echo setenv LIB=%LIB% > setenv.bat editing that batch file to append ;C:\Program Files\Microsoft Platform SDK\Lib and running it. That worked (whew), but running the test found two failures: updown.c:509: Test failed: create parent window: the msg 0x0281 was expected, but got msg 0x0007 instead updown.c:522: Test failed: add updown control with edit: in msg 0x0005 expecting lParam 0x4b005b got 0x440065 updown: 133 tests executed (0 marked as todo, 2 failures), 0 skipped. I guess it needs a bit of tweaking. The system I tested it on is running Win XP Professional Version 2002 Service Pack 2. - Dan

2 2

user32/tests: Mysterious WinXP 0xae and 0xef messages.
by Kirill K. Smirnov 19 Jan '07

19 Jan '07

Hi! While improving rejected tests for WM_SETICON: http://www.winehq.org/pipermail/wine-patches/2007-January/034949.html I've noticed, that WinXP sends some mysterious message 0xae, that breaks tests. Googling it, I've found few notes indicating to WM_NCUAHDRAWCAPTION [0xae] message and WM_NCUAHDRAWFRAME[0xaf]. [http://www.werkema.com/ blog/index.php?op=Default&Date=200503&blogId=1] As I understood it, these messages are used to paint WINXP-specific fancy borders and captions. But MSDN shows absolutely absence of any knowledge concerning it. AFAIK wine does not support them too. Should these messages be implemented? Or at least add mnemonics to winuser.h? Anyway, how those tests should be modified to pass under XP and other versions? Thanks, Kirill

2 1

regression from 0.9.28 -> 0.9.29 breaks U.S. tax program
by Tom Lowe 19 Jan '07

19 Jan '07

Using ubuntu 6.10 and wine packages from http://wine.budgetdedicated.com/apt edgy main TaxACT 2006 ( free download from http://www.taxact.com ) works "out-of-the-box" with 0.9.28. Checking for program updates and electronic filing "hang" with 0.9.29. When 0.9.29 hung up on me, I removed it and re-installed 0.9.28 and was able to connect and file my tax return. It has been accepted by IRS. -- Tom Lowe

2 1

iphlpapi - MacOS / BSD support
by Juan Lang 18 Jan '07

18 Jan '07

Hi Gav, > As the iphlpapi DLL is LGPLed, our patches to it are necessarily under > the LGPL as well. In fact that's not true. I added the LGPL headers for inclusion into WineHQ, but I said my patches were MIT/X11 (unless I say otherwise, which I didn't say, but I suppose is implied): http://www.winehq.org/pipermail/wine-patches/2003-May/006174.html Thanks, --Juan ____________________________________________________________________________________ Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html

2 1

File buffering
by Teemu Ikonen 18 Jan '07

18 Jan '07

Hi, I have a Visual Fortran application which exhibits problems related to concurrency and file buffer flushing when run under wine (it works under all versions of windows). The program does essentially this: opens a file writes to it closes it forks another program to read the file just written deletes the file in the original process Under wine, the forked program does not find the file just written. If I run the program under winedbg and set a breakpoint somewhere between writing and deletion, the buffers are flushed when the breakpoint is reached, and the program works as it does under windows. To my mind this would indicate that windows flushes all open buffers before forking a new process (the api call I see in wine debug output is CreateProcessW). Would it make sense to add flush-calls to the wine implementation as well? I tried to make the program work by adding calls to the Fortran subroutine FLUSH between closing and forking, but somewhat surprisingly, that didn't help. Teemu

3 3

[1/4] D3D9: Implement IDirect3DDevice9::StretchRect
by Christoph Bumiller 18 Jan '07

18 Jan '07

This also (partially) fixes the issue with NFS:MW where nothing except the menus appears to be draw when setting the Visual Treatment option to high. The scene is now visible, but its scaled down in the y direction and only covers about the top 2/3 of the screen ...

1 0

Re: wined3d: Synchronize window style correcting code with ddraw
by H. Verbeet 18 Jan '07

18 Jan '07

On 18/01/07, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > Hello, > > this patch should fix the regression reported on #wine-hackers. > > Changelog: > wined3d: Synchronize window style correcting code with ddraw. > Although afaik there's nothing wrong with this patch, I do have a patch myself that moves the ddraw code for doing this to wined3d so that both use the same code.

1 0

Re: [PATCH 1/4] ntdll: Implement RtlEncode/DecodePointer
by Alexandre Julliard 18 Jan '07

18 Jan '07

Mike McCormack <mike(a)codeweavers.com> writes: > diff --git a/dlls/ntdll/loader.c b/dlls/ntdll/loader.c > index 999687a..468e5b6 100644 > --- a/dlls/ntdll/loader.c > +++ b/dlls/ntdll/loader.c > @@ -2161,6 +2161,7 @@ void WINAPI LdrInitializeThunk( ULONG unknown1, ULONG unknown2, ULONG unknown3, > > RtlEnterCriticalSection( &loader_section ); > > + rtl_generate_pointer_obfuscator(); > load_path = NtCurrentTeb()->Peb->ProcessParameters->DllPath.Buffer; > if ((status = fixup_imports( wm, load_path )) != STATUS_SUCCESS) goto error; > if ((status = alloc_process_tls()) != STATUS_SUCCESS) goto error; It would be cleaner to initialize this the first time it's needed, instead of having to export a global function and do more work at init time for a rarely used feature. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: user32: invalidate button area instead of painting immediatly
by James Hawkins 18 Jan '07

18 Jan '07

On 1/17/07, Clinton Stimpson <cjstimpson(a)utwire.net> wrote: > > WM_SETFONT on a button should invalidate the area so the system can send > a WM_PAINT event, instead of painting the button immediately. > This is a partial fix for bug# 6006. > The other part of the fix is for ShowWindow(button, SW_HIDE) to cause a > WM_PAINT event on the button's parent to paint in the newly exposed region. > > Thanks, > Clinton Stimpson > > ChangeLog: > user32: invalidate button area instead of painting button immediately. > Can you write a message test for this in dlls/user32/tests/msg.c to verify your fix? Thanks, James Hawkins

1 0

Re: [1/4] D3D9: Implement IDirect3DDevice9::StretchRect
by Mirek 18 Jan '07

18 Jan '07

Hi, this patch caused big performance regression in some D3D games (Flatout 2, Tomb Raider: Legend, HalfLife 2: Episode One). Mirek Slugen Stefan Dösinger napsal(a): > This time with a FIXME for unsupported filtering options. If we implement > them, it should be done in Blt and private blitting flags used. > > > ------------------------------------------------------------------------ > > From 95f4217d366770b9b05214ae68274ce4ab4b9fb6 Mon Sep 17 00:00:00 2001 > From: Stefan Doesinger <stefan(a)codeweavers.com> > Date: Thu, 11 Jan 2007 22:39:03 +0100 > Subject: [PATCH] D3D9: Implement IDirect3DDevice9::StretchRect > > --- > dlls/d3d9/device.c | 10 +++++++--- > dlls/d3d9/directx.c | 3 +++ > dlls/wined3d/device.c | 9 --------- > include/wine/wined3d_interface.h | 2 -- > 4 files changed, 10 insertions(+), 14 deletions(-) > > diff --git a/dlls/d3d9/device.c b/dlls/d3d9/device.c > index aa788af..4c27853 100644 > --- a/dlls/d3d9/device.c > +++ b/dlls/d3d9/device.c > @@ -356,9 +356,13 @@ static HRESULT WINAPI IDirect3DDevice9Impl_GetFrontBufferData(LPDIRECT3DDEVICE > } > > static HRESULT WINAPI IDirect3DDevice9Impl_StretchRect(LPDIRECT3DDEVICE9 iface, IDirect3DSurface9* pSourceSurface, CONST RECT* pSourceRect, IDirect3DSurface9* pDestSurface, CONST RECT* pDestRect, D3DTEXTUREFILTERTYPE Filter) { > - IDirect3DDevice9Impl *This = (IDirect3DDevice9Impl *)iface; > - TRACE("(%p) Relay\n" , This); > - return IWineD3DDevice_StretchRect(This->WineD3DDevice, ((IDirect3DSurface9Impl *)pSourceSurface)->wineD3DSurface, pSourceRect, ((IDirect3DSurface9Impl *)pDestSurface)->wineD3DSurface, pDestRect, (WINED3DTEXTUREFILTERTYPE) Filter); > + IDirect3DDevice9Impl *This = (IDirect3DDevice9Impl *)iface; > + IDirect3DSurface9Impl *src = (IDirect3DSurface9Impl *) pSourceSurface; > + IDirect3DSurface9Impl *dst = (IDirect3DSurface9Impl *) pDestSurface; > + > + TRACE("(%p)->(%p,%p,%p,%p,%d)\n" , This, src, pSourceRect, dst, pDestRect, Filter); > + if(Filter != D3DTEXF_NONE) ERR("Texture filters not supported yet\n"); > + return IWineD3DSurface_Blt(dst->wineD3DSurface, (RECT *) pDestRect, src->wineD3DSurface, (RECT *) pSourceRect, 0, NULL); > } > > static HRESULT WINAPI IDirect3DDevice9Impl_ColorFill(LPDIRECT3DDEVICE9 iface, IDirect3DSurface9* pSurface, CONST RECT* pRect, D3DCOLOR color) { > diff --git a/dlls/d3d9/directx.c b/dlls/d3d9/directx.c > index f360b4e..57062b2 100644 > --- a/dlls/d3d9/directx.c > +++ b/dlls/d3d9/directx.c > @@ -170,6 +170,9 @@ static HRESULT WINAPI IDirect3D9Impl_GetDeviceCaps(LPDIRECT3D9 iface, UINT Adapt > D3D9CAPSTOWINECAPS(pCaps, pWineCaps) > hrc = IWineD3D_GetDeviceCaps(This->WineD3D, Adapter, DeviceType, pWineCaps); > HeapFree(GetProcessHeap(), 0, pWineCaps); > + > + /* Some functionality is implemented in d3d9.dll, not wined3d.dll. Add the needed caps */ > + pCaps->Caps2 |= D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES; > TRACE("(%p) returning %p\n", This, pCaps); > return hrc; > } > diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c > index 7b81f0e..5f964fb 100644 > --- a/dlls/wined3d/device.c > +++ b/dlls/wined3d/device.c > @@ -4930,14 +4930,6 @@ static HRESULT WINAPI IWineD3DDeviceImpl_UpdateTexture (IWineD3DDevice *iface, I > return hr; > } > > -static HRESULT WINAPI IWineD3DDeviceImpl_StretchRect(IWineD3DDevice *iface, IWineD3DSurface *pSourceSurface, > - CONST RECT* pSourceRect, IWineD3DSurface *pDestinationSurface, > - CONST RECT* pDestRect, WINED3DTEXTUREFILTERTYPE Filter) { > - IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *)iface; > - > - TRACE("(%p) : stub\n", This); > - return WINED3D_OK; > -} > static HRESULT WINAPI IWineD3DDeviceImpl_GetRenderTargetData(IWineD3DDevice *iface, IWineD3DSurface *pRenderTarget, IWineD3DSurface *pSurface) { > IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *)iface; > /** TODO: remove remove casts to IWineD3DSurfaceImpl * > @@ -6776,7 +6768,6 @@ const IWineD3DDeviceVtbl IWineD3DDevice_Vtbl = > IWineD3DDeviceImpl_ColorFill, > IWineD3DDeviceImpl_UpdateTexture, > IWineD3DDeviceImpl_UpdateSurface, > - IWineD3DDeviceImpl_StretchRect, > IWineD3DDeviceImpl_GetRenderTargetData, > IWineD3DDeviceImpl_GetFrontBufferData, > /*** object tracking ***/ > diff --git a/include/wine/wined3d_interface.h b/include/wine/wined3d_interface.h > index 8a685f0..4a24636 100644 > --- a/include/wine/wined3d_interface.h > +++ b/include/wine/wined3d_interface.h > @@ -469,7 +469,6 @@ DECLARE_INTERFACE_(IWineD3DDevice,IWineD3DBase) > STDMETHOD(ColorFill)(THIS_ struct IWineD3DSurface* pSurface, CONST WINED3DRECT* pRect, WINED3DCOLOR color) PURE; > STDMETHOD(UpdateTexture)(THIS_ struct IWineD3DBaseTexture *pSourceTexture, struct IWineD3DBaseTexture *pDestinationTexture) PURE; > STDMETHOD(UpdateSurface)(THIS_ struct IWineD3DSurface* pSourceSurface, CONST RECT* pSourceRect, struct IWineD3DSurface* pDestinationSurface, CONST POINT* pDestPoint) PURE; > - STDMETHOD(StretchRect)(THIS_ struct IWineD3DSurface* pSourceSurface, CONST RECT* pSourceRect, struct IWineD3DSurface* pDestinationSurface, CONST RECT* pDestRect, WINED3DTEXTUREFILTERTYPE Filter) PURE; > STDMETHOD(GetRenderTargetData)(THIS_ struct IWineD3DSurface* pRenderTarget, struct IWineD3DSurface* pSurface) PURE; > STDMETHOD(GetFrontBufferData)(THIS_ UINT iSwapChain,struct IWineD3DSurface* pSurface) PURE; > /*** object tracking ***/ > @@ -608,7 +607,6 @@ DECLARE_INTERFACE_(IWineD3DDevice,IWineD3DBase) > #define IWineD3DDevice_ColorFill(p,a,b,c) (p)->lpVtbl->ColorFill(p,a,b,c) > #define IWineD3DDevice_UpdateTexture(p,a,b) (p)->lpVtbl->UpdateTexture(p,a,b) > #define IWineD3DDevice_UpdateSurface(p,a,b,c,d) (p)->lpVtbl->UpdateSurface(p,a,b,c,d) > -#define IWineD3DDevice_StretchRect(p,a,b,c,d,e) (p)->lpVtbl->StretchRect(p,a,b,c,d,e) > #define IWineD3DDevice_GetRenderTargetData(p,a,b) (p)->lpVtbl->GetRenderTargetData(p,a,b) > #define IWineD3DDevice_GetFrontBufferData(p,a,b) (p)->lpVtbl->GetFrontBufferData(p,a,b) > #define IWineD3DDevice_ResourceReleased(p,a) (p)->lpVtbl->ResourceReleased(p,a) > > > ------------------------------------------------------------------------ > >

3 2

← Newer
1
...
7
8
9
10
11
12
13
...
28
Older →

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 January 2007