Re: mshtml: Removed tests failing on IE7.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=7145 Your paranoid android. === W98SE (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found
RFC: flipping more than one backbuffer on swapchain
I had patched IWineGDISwapChainImpl_Present, which can now fully support
looping behavior on swapchain for more than one backbuffer. Patch 2/3 allows
more backbuffers creation for GDI surfaces, and last patch is test to ddraw.
From 6dc3ea954a4241147ba8060d1a3272c3c762c013 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pavel=20Proch=C3=A1zka?= pavelvonlost...@seznam.cz
Date: Thu, 18 Nov 2010 10:45:57 +0100
Subject: [RFC:][1/3] wined3d: Implement flipping with more than one backbuffer for gdi surfaces.
---
dlls/wined3d/swapchain_gdi.c | 66 ++
1 files changed, 41 insertions(+), 25 deletions(-)
diff --git a/dlls/wined3d/swapchain_gdi.c b/dlls/wined3d/swapchain_gdi.c
index 8920cae..cfc75c4 100644
--- a/dlls/wined3d/swapchain_gdi.c
+++ b/dlls/wined3d/swapchain_gdi.c
@@ -174,7 +174,9 @@ static HRESULT WINAPI IWineGDISwapChainImpl_SetDestWindowOverride(IWineD3DSwapCh
static HRESULT WINAPI IWineGDISwapChainImpl_Present(IWineD3DSwapChain *iface, CONST RECT *pSourceRect, CONST RECT *pDestRect, HWND hDestWindowOverride, CONST RGNDATA *pDirtyRegion, DWORD dwFlags) {
IWineD3DSwapChainImpl *This = (IWineD3DSwapChainImpl *) iface;
-IWineD3DSurfaceImpl *front, *back;
+IWineD3DSurfaceImpl *front,*hlp1,*hlp2;
+IWineD3DSurfaceImpl back;
+UINT i;
if (!This-back_buffers)
{
@@ -182,50 +184,64 @@ static HRESULT WINAPI IWineGDISwapChainImpl_Present(IWineD3DSwapChain *iface, CO
return WINED3DERR_INVALIDCALL;
}
front = This-front_buffer;
-back = This-back_buffers[0];
+back = *((IWineD3DSurfaceImpl *)This-back_buffers[0]);
+
+/* Presentation algorithm:
+ ^^^
+ | | |
+|front_buffer| |back_buffer0|back_buffer1|back_buffer2||back_bufferN|
+^ v
+||
+^ ^
+||
+
+*/
+
+for(i=0;iThis-presentParms.BackBufferCount-1;i++)
+{
+hlp1 = (IWineD3DSurfaceImpl *)This-back_buffers[i];
+hlp2 = (IWineD3DSurfaceImpl *)This-back_buffers[i+1];
+hlp1-hDC = hlp2-hDC;
+hlp1-dib.DIBsection = hlp2-dib.DIBsection;
+hlp1-dib.bitmap_data = hlp2-dib.bitmap_data;
+hlp1-resource.allocatedMemory = hlp2-resource.allocatedMemory;
+hlp1-dib.client_memory = hlp2-dib.client_memory;
+}
+
+/* move data from front buffer to end of back_buffers array */
+hlp1 = (IWineD3DSurfaceImpl *)This-back_buffers[i];
+hlp1-hDC = front-hDC;
+hlp1-dib.DIBsection = front-dib.DIBsection;
+hlp1-dib.bitmap_data = front-dib.bitmap_data;
+hlp1-resource.allocatedMemory = front-resource.allocatedMemory;
+hlp1-dib.client_memory = front-dib.client_memory;
/* Flip the DC */
{
-HDC tmp;
-tmp = front-hDC;
-front-hDC = back-hDC;
-back-hDC = tmp;
+front-hDC = back.hDC;
}
/* Flip the DIBsection */
{
-HBITMAP tmp;
-tmp = front-dib.DIBsection;
-front-dib.DIBsection = back-dib.DIBsection;
-back-dib.DIBsection = tmp;
+front-dib.DIBsection = back.dib.DIBsection;
}
/* Flip the surface data */
{
-void* tmp;
-
-tmp = front-dib.bitmap_data;
-front-dib.bitmap_data = back-dib.bitmap_data;
-back-dib.bitmap_data = tmp;
-
-tmp = front-resource.allocatedMemory;
-front-resource.allocatedMemory = back-resource.allocatedMemory;
-back-resource.allocatedMemory = tmp;
+front-dib.bitmap_data = back.dib.bitmap_data;
+front-resource.allocatedMemory = back.resource.allocatedMemory;
if(front-resource.heapMemory) {
ERR(GDI Surface %p has heap memory allocated\n, front);
}
-if(back-resource.heapMemory) {
-ERR(GDI Surface %p has heap memory allocated\n, back);
+if(back.resource.heapMemory) {
+ERR(GDI Surface %p has heap memory allocated\n, back);
}
}
/* client_memory should not be different, but just in case */
{
-BOOL tmp;
-tmp = front-dib.client_memory;
-front-dib.client_memory = back-dib.client_memory;
-back-dib.client_memory = tmp;
+front-dib.client_memory = back.dib.client_memory;
}
/* FPS support */
--
1.7.1
From d711a1e7f258732adeec7a974619c8a60afd01a1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pavel=20Proch=C3=A1zka?= pavelvonlost...@seznam.cz
Date: Thu, 18 Nov 2010 10:48:42 +0100
Subject: [RFC:][2/3] wined3d: Allow any count of backbuffers for gdi surfaces.
---
dlls/wined3d/swapchain.c | 21 -
1 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/dlls/wined3d/swapchain.c b/dlls/wined3d/swapchain.c
index a29eeb4..b6b8f0b 100644
--- a/dlls/wined3d/swapchain.c
+++
Re: [PATCH 4/4] ddraw: Return DDERR_INVALIDPARAMS for 0 width / height surface creation.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=7157 Your paranoid android. === W98SE (32 bit dsurface) === dsurface: unhandled exception c005 at 00415849
Re: [PATCH 1/4] wined3d: Disallow empty surfaces.
Am Donnerstag 18 November 2010, 12:21:39 schrieb Henri Verbeet: +if (!resource_size) return WINED3DERR_INVALIDCALL; Shouldn't we add a format flag that controls wether a format can be used to create a resource instead? I'm thinking about the NULL fourcc code that also has a resource size of zero but can be used to create a surface. signature.asc Description: This is a digitally signed message part.
Re: [3/5] gdi32: Add the ability to load a scalable font resource. Take 3.
Dmitry Timoshkov dmi...@codeweavers.com writes: +if (!ReadFile(hfile, dos, sizeof(dos), NULL, NULL)) +goto errexit; + +if (dos.e_magic != IMAGE_DOS_SIGNATURE) +goto errexit; + +if (SetFilePointer(hfile, dos.e_lfanew, NULL, FILE_BEGIN) == INVALID_SET_FILE_POINTER) +goto errexit; + +if (!ReadFile(hfile, os2, sizeof(os2), NULL, NULL)) +goto errexit; Again that's inefficient, you don't want to read it bit by bit. You should read the whole file in one go, or use a memory mapping. If using ReadFile you also have to check the returned size. -- Alexandre Julliard julli...@winehq.org
Re: Patch for bug 25063 - _pclose should wait for the command processor to terminate and return it's exit status
Borut Razem borut.ra...@siol.net writes: I was also thinking abut that. We could add a hProcess member to the ioinfo structure, but this means MSVCRT_MAX_FILES * sizeof(HANDLE) = 2048 * 4 = 8KB additional data space, which will be more then less unused... That's not an issue, if it's unused the cost is minimal. The real problem is that the ioinfo structure can't be changed. The problem is that the highest file descriptor in use (actually the number of popen calls during the process life) is not konwn in advance, that's why I implemented it as dynamically growing array. Or I'm missing something? You are confusing the allocation and the lookup. Yes, you need to grow it dynamically. That doesn't mean you need a linear search. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 1/4] wined3d: Disallow empty surfaces.
On 18 November 2010 14:59, Stefan Dösinger stefandoesin...@gmx.at wrote: Am Donnerstag 18 November 2010, 12:21:39 schrieb Henri Verbeet: + if (!resource_size) return WINED3DERR_INVALIDCALL; Shouldn't we add a format flag that controls wether a format can be used to create a resource instead? I'm thinking about the NULL fourcc code that also has a resource size of zero but can be used to create a surface. NULL is pretty special, and will require changes in a number of places. Maybe it shouldn't go through the regular surface creation path at all. Note that the point of the series is to disallow creating surfaces with a zero width or height; failing NVDB surface creation is just a fortunate side effect. In the longer term we should also disallow e.g. formats without a GL format for resources in the default or managed pools.
Re: [1/2] opengl32/tests: Add tests for special case of SetPixelFormat
I got confused by the relay logs earlier (they don't include the calls to com objects), it's our implementation of IDirect3D9::CreateDevice which is calling SetPixelFormat. The application calls CreateDevice with focus_window a handle from GetDesktopWindow(); You're right that the game isn't actually drawing to this device, it calls a few functions (see attached files) and then it releases this device and creates a new one with an appropriate window for the game itself. There are currently no test cases for using a 'root_window'. What test cases do you want to see? I can duplicate the current tests for use with a root_window, but that's probably not what you want. For the implementation, we might be able to detect this inside CreateDevice, and skip the creation of a swapchain. Not sure if that's a correct fix though. Thanks again, Matijn On Mon, Nov 15, 2010 at 2:24 AM, Roderick Colenbrander thunderbir...@gmail.com wrote: It has been a while since I last looked at this area. The following bug came to my mind which is the same thing http://bugs.winehq.org/show_bug.cgi?id=9786 I would start by figuring out for what purpose and for what calls the game is using GetDC(0). Turn on some d3d debug channels and try to figure that out. You might have to write some test cases (though they might exists already in d3d, but I haven't looked at the test in a while). I don't know for sure but can Direct3D actually render to the 'root_window'? I guess you can't .. Roderick On Sun, Nov 14, 2010 at 3:33 PM, Matijn Woudt tijn...@gmail.com wrote: On Mon, Nov 15, 2010 at 12:06 AM, Roderick Colenbrander thunderbir...@gmail.com wrote: Hi Matijn, What 3D API is this game using? Is it using Direct3D or OpenGL? If it is Direct3D then I have the feeling the 'issue' is getting fixed in the wrong layer. It's using Direct3D, but I don't see how this can be fixed in Direct3D. Further I'm not really sure whether we want to allow pixel format 1 to be used at all. In case of Wine all pixel formats are hardware accelerated (okay, the bitmaps one are set to indirect rendering so might be software based depending on the GLX implementation). On Windows you essentially have two GL implementations namely the Microsoft GDI renderer and the OpenGL ICD driver. The first several pixel formats are the ones from the software based GDI renderer... So even though Windows might allow setting pixel format 1 on HDC 0, I don't think it is the right thing to do. Roderick Not setting the pixel format (e.g. just returning TRUE) won't help the game. Setting a different (hardware accelerated) format will probably work, but that doesn't feel right. I'd really like to fix this bug, but if the patch isn't right I don't have a clue how to fix it 'the right way'. Any hints? Thanks, Matijn ps. Trial for the game is available at: http://www.sandlotgames.com/w5/hearts_medicine_season_1.html (200MB), after installing run bin/prog.exe, launcher doesn't work. On Sun, Nov 14, 2010 at 9:55 AM, Matijn Woudt tijn...@gmail.com wrote: Add tests for special case of SetPixelFormat Tests pass on my Windows XP laptop and Windows 7 PC. The game 'Heart's Medicine Season One' depends on this behaviour. calls Description: Binary data
Re: [1/5] gdi32: Separate font loading from adding a font to global font list. Take 3.
Dmitry Timoshkov dmi...@codeweavers.com writes: --- dlls/gdi32/freetype.c | 304 + 1 files changed, 205 insertions(+), 99 deletions(-) It doesn't build on Mac: gcc -m32 -c -I. -I. -I../../include -I../../include -I/usr/local/include/freetype2 -I/usr/local/include -I/usr/X11/include -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wwrite-strings -Wpointer-arith -g -O2 -o freetype.o freetype.c freetype.c: In function 'load_font': freetype.c:1418: error: 'fake_family' undeclared (first use in this function) freetype.c:1418: error: (Each undeclared identifier is reported only once freetype.c:1418: error: for each function it appears in.) make[1]: *** [freetype.o] Error 1 -- Alexandre Julliard julli...@winehq.org
Re: [1/2] opengl32/tests: Add tests for special case of SetPixelFormat
On 18 November 2010 15:05, Matijn Woudt tijn...@gmail.com wrote: For the implementation, we might be able to detect this inside CreateDevice, and skip the creation of a swapchain. Not sure if that's a correct fix though. Swapchain creation isn't something you want to skip. Perhaps it's possible to delay GL context creation until something actually needs it though. I'm curious if things like DrawPrimitive() shouldn't fail anyway when the device is created with GetDesktopWindow() as window. Another option may be to allow the D3D context to be created, but immediately mark it invalid.
Re: dlls/oledb32: added conversions for I1, I8, UI2, DEC and GetConversionSize
Hi Andreas, Thanks for helping Wine! A few administrivial issues: Please submit only one attachment per post. Also, please avoid sending HTML mail to wine-patches. See http://wiki.winehq.org/SubmittingPatches - Dan On Thu, Nov 18, 2010 at 4:05 AM, Andreas Pflug pf...@pse-consulting.de wrote: This complements my previous post, which is included for completeness' sake below (0001-OLEDB-xxx) convert_DataConvert is extended for the types DBTYPE_I1, DBTYPE_I8 ,DBTYPE_UI2, DBTYPE_DECIMAL. The conversions are performed using the OLEAUT32-Functions VarXXXFromYYY, as far as they exist which made this mostly a carefully handled copy/paste job. Conversion DBTYPE_TIMESTAMP-DBTYPE_DATE have been successfully tested using a commercial app (HIW Rendite 10). GetConversionLength has been implemented trivially for fixed-length dstTypes, and partially for var-length types (as far as the app required it). Original-Nachricht Betreff: dlls/oledb32: added conversions for R8,BOOL,DATE,DBTIMESTAMP Datum: Wed, 17 Nov 2010 13:45:25 +0100 Von: Andreas Pflug pf...@pse-consulting.de An: wine-patc...@winehq.org convert_DataConvert now know the types DBTYPE_R8, DBTYPE_BOOL, DBTYPE_DATE and will convert from all source types supported by VarXXXFromYYY functions. DBTYPE_TIMESTAMP is supported to convert from and to DBTYPE_DATE. get_length is extended accordingly.
Re: [1/2] opengl32/tests: Add tests for special case of SetPixelFormat
On Thu, Nov 18, 2010 at 3:35 PM, Henri Verbeet hverb...@gmail.com wrote: On 18 November 2010 15:05, Matijn Woudt tijn...@gmail.com wrote: For the implementation, we might be able to detect this inside CreateDevice, and skip the creation of a swapchain. Not sure if that's a correct fix though. Swapchain creation isn't something you want to skip. Perhaps it's possible to delay GL context creation until something actually needs it though. I'm curious if things like DrawPrimitive() shouldn't fail anyway when the device is created with GetDesktopWindow() as window. Another option may be to allow the D3D context to be created, but immediately mark it invalid. I gave the visual test suite a shot, normal test run on my Windows 7 x64: visual.c:196: Driver string: atiumdag.dl visual.c:197: Description string: ATI Ra visual.c:199: Device name string: \\.\DI visual.c:201: Driver version 8.14.10.678 visual: 5493 tests executed (0 marked as todo, 75 failures), 3 skipped. now, changing the code in create_window to return GetDesktopWindow(), gives visual.c:196: Driver string: atiumdag.dl visual.c:197: Description string: ATI Ra visual.c:199: Device name string: \\.\DI visual.c:201: Driver version 8.14.10.678 visual: 5493 tests executed (0 marked as todo, 75 failures), 3 skipped. There's only 1 difference, the first one really shows a window with all the triangle's, like it should. Second one doesn't show anything. So all the functions don't fail, they just don't seem to do anything.
building a winelib dll?
Im trying to build a simple winelib. Its not working and is returning 'error
127'. I have some question:
(1) how do i determine which functions are exported by wine? All i see using
nm zmq.dll.so is the names of my proxy function (add_proxy) instead of the
name that is going to be called by the windows program (add)
(2) whats the point of a spec file? what im saying is that i can build my
files without a spec file and no error message is produced. In what stage of
building is the spec file actually used?
(3) is there any way to debug just specifically the errors produced by my
stub dll under wine? somehow specify a debug channel where the real reason
for 'error 127' is? The stub dll being dynamically loaded by a program for
which i have no source code.
I am using these simple test files:
//in zmq.c
#include zmq.h
#include wine/debug.h
#include windef.h
long WINAPI add_proxy(long a,long b) {
return a+b;
}
;;in zmq.dll.spec
@ stdcall add( long long ) add_proxy
and then i do
winegcc -c -o zmq.o zmq.c
winegcc -shared -o zmq.dll.so zmq.o
However, i notice that i can just get rid of the spec file and no error
messages are produced which makes no sense since the dll is supposed to
redirect calls to add to add_proxy.
And once i use the windows program to call function add, i get the 'error
127', which means it cant find the function 'add.'
Re: [PATCH 1/3] ws2_32/tests: add a test for an overlapped send
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=7170 Your paranoid android. === W98SE (32 bit sock) === sock.c:2661: Test failed: Failed to start overlapped send 0 - 0 - 1048576/1048576
Re: [PATCH 2/3] ws2_32: fix up iovecs after transmission in WS2_send instead of WS2_sendto
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=7171 Your paranoid android. === W98SE (32 bit sock) === sock.c:2661: Test failed: Failed to start overlapped send 0 - 0 - 1048576/1048576
Re: [PATCH 2/3] ws2_32: fix up iovecs after transmission in WS2_send instead of WS2_sendto
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=7173 Your paranoid android. === WXPPROSP3 (32 bit sock) === sock.c:3404: Test failed: Expected event sequence [FD_READ(0)], got [] sock.c:3411: Test failed: Expected event sequence [], got [FD_READ(0)] === WVISTAADM (32 bit sock) === sock.c:862: Test failed: gethostbyname() failed unexpectedly: 11004
