Re: question for dumps
Juan Carlos Montes [EMAIL PROTECTED] wrote: At this time, i have dumps for WriteFile, ReadFile, WSASendTo and WSARecvFrom. But i need it for Registry set value functions... Do you want that i make a diff with all change? This dumping feature doesn't belong to Wine, if you need it use either specialized traffic shaping tools or add your own custom code for debugging. -- Dmitry.
Re: question for dumps
Ok, i can make the patch. what do you need to make the new channel? I use this code to dump: // Insert to dump buffers // Inserted by Juan Carlos Montes // Date: 23/01/08 char file_name[255] = ; sprintf( file_name, dumps\\wsasendto_%d, GetTickCount()+rand() ); HANDLE file = CreateFileA( file_name, GENERIC_WRITE | GENERIC_READ, 0, NULL, CREATE_ALWAYS, 0, NULL ); DWORD bytes = 0, pos = 0; for (pos=0; posdwBufferCount; pos++) WriteFile( file, lpBuffers[pos].buf, lpBuffers[pos].len, bytes, NULL ); CloseHandle( file ); TRACE( filename %s\n, file_name ); // End to insert At this time, i have dumps for WriteFile, ReadFile, WSASendTo and WSARecvFrom. But i need it for Registry set value functions... Do you want that i make a diff with all change? Alex Villacís Lasso escribió: Alex Villacís Lasso escribió: Juan Carlos Montes escribió: I dont like change the source to use all versions of wine... but... I'll try make a debugger to dump the memory. So... thanks a lot. Stefan Dösinger escribió: Am Dienstag, 22. Januar 2008 16:19:54 schrieb Juan Carlos Montes: Hi all, I need dump the data using the debug log. trace:winsock:WSASendTo socket 00f8, wsabuf 0x34e1e0, nbufs 1, flags 0, to (nil), tolen 0, ovl (nil), func (nil) if have this one, can i dump the data in 0x34e1e0 with another option in debug, or i need change the source? You have to change the source, or attach a debugger and read the memory I think. Could you please explain *why* you need to peek into the buffer data? Is there a mismatch between what the app intends to send to the socket and the actual wire contents of the packet? Do you have a bug opened for whatever issue the app is experiencing? It seems strange that you mention making this change for *all* versions of Wine, unless I have misunderstood your comment, or somehow you are interested in dumping the data for a reason other than debugging Wine itself. BTW: se habla español (fuera de la lista de discusión). You could add a new debugging channel, for example winsock_buffer, that will do what you want. This channel might be actually useful for purposes other than malware scanning, as the buffers the app prepares (or receives) could reveal mistakes in data processed with Wine's implementation of functions. I suggest that you create a patch for this and send it to wine-patches. If your patch is accepted, future versions of Wine will have your required functionality added, which happens to be useful to others too. To the rest of the list, what do you think? -- ___ Juan Carlos Montes Senra INTECO-CERT Instituto Nacional de Tecnologías de la Comunicación email: [EMAIL PROTECTED] | [EMAIL PROTECTED] Tlf. 0034 987 877 189 - ext. 532 ___
Re: gdiplus: bezier test question
Reece Dunn [EMAIL PROTECTED] wrote:
The patch that I have just submitted (gdiplus: fix the bezier arc
path test (on all platforms).) is a simple fix for the failing test
in graphicspath.c. The failure highlights gdiplus behaviour that is
not directly obvious:
If you have a bezier arc:
static path_test_t arc_path[] = {
{600.0, 450.0, PathPointTypeStart, 0, 0}, /*0*/
{600.0, 643.3, PathPointTypeBezier, 0, 0}, /*1*/
{488.1, 800.0, PathPointTypeBezier, 0, 0}, /*2*/
};
the gdiplus code will make the last entry PathPointTypeBezier |
PathPointTypeCloseSubpath.
For the nature of the existing test, I believe the fix is correct (it
is testing the basic arc path functionality). However, there should be
another test to document the above behaviour.
This behaviour matches what GDI32 does with adding PT_CLOSEFIGURE.
--
Dmitry.
Re: winex11.drv: Remove an incorrect FIXME
Dmitry Timoshkov [EMAIL PROTECTED] writes: diff --git a/dlls/winex11.drv/x11drv_main.c b/dlls/winex11.drv/x11drv_main.c index f2bf12c..948c58c 100644 --- a/dlls/winex11.drv/x11drv_main.c +++ b/dlls/winex11.drv/x11drv_main.c @@ -498,10 +498,7 @@ static BOOL process_attach(void) break; case 15: -/* Out tests suggest that windows does not support 15 bpp color depth. - * X11 does, what should we do with these situations? - */ -FIXME(The X server is running at 15 bpp color depth\n); +/* It's the same thing as 16 bpp but with different bit fields */ screen_bpp = 15; Shouldn't screen_bpp be set to 16 then? -- Alexandre Julliard [EMAIL PROTECTED]
Re: winex11.drv: Remove an incorrect FIXME
Dmitry Timoshkov [EMAIL PROTECTED] writes: Alexandre Julliard [EMAIL PROTECTED] wrote: Shouldn't screen_bpp be set to 16 then? I believe that GetDeviceCaps(BITSPIXEL) should return 15 in that case, so that the apps would use correct bit fields for DIBs. There are no correct bit fields for DIBs, by definition DIBs are display-independent, and we have to support both bit field variants on all displays, so the actual screen depth is irrelevant. -- Alexandre Julliard [EMAIL PROTECTED]
Re: winex11.drv: Remove an incorrect FIXME
Alexandre Julliard [EMAIL PROTECTED] wrote: case 15: -/* Out tests suggest that windows does not support 15 bpp color depth. - * X11 does, what should we do with these situations? - */ -FIXME(The X server is running at 15 bpp color depth\n); +/* It's the same thing as 16 bpp but with different bit fields */ screen_bpp = 15; Shouldn't screen_bpp be set to 16 then? I believe that GetDeviceCaps(BITSPIXEL) should return 15 in that case, so that the apps would use correct bit fields for DIBs. -- Dmitry.
Re: No new winetest?
On Friday 25 January 2008 10:00:17 Francois Gouget wrote: There's been no new winetest for about a week. Does anyone know what's up? The front-end machine had stopped responding to network traffic. I'm not physically the machine, so I've asked someone to investigate on my behalf. They rebooted the machine, which appeared to start correctly (from the screen). Unfortunately it is still not responding to any network traffic. So, sorry, winetest will be off-line until Monday at the earliest. Paul.
Wiki Down?
What happened to the wiki? AppDB/WineHQ/Bugzilla are all fine, but wiki.winehq.org seems to be down. -Austin
Re: comctl32: Vista sends an unidentified message when destroyingdatetime and monthcal windows.
On 25/01/2008, Dmitry Timoshkov [EMAIL PROTECTED] wrote:
Reece Dunn [EMAIL PROTECTED] wrote:
When destroying datetime and monthcal controls, Vista sends a message
with the value 0x0090. This messasge is not in winuser.h of the Vista
SDK.
+#define WM_UNKNOWN_VISTA1 0x0090
IMO just adding
{ 0x0090, sent|optional }, /* Vista */
is clear enough, WM_UNKNOWN_VISTA1 clutters the code.
I wanted it to be more descriptive that the message is an unknown
message, but I'm happy to go with your change.
- Reece
Re: dlls/d3d9/tests/visual.c -- address five compiler warnings (RESEND)
On Mon, 14 Jan 2008, Alexandre Julliard wrote: @@ -4348,12 +4349,12 @@ static void vshader_version_varying_test vs_3_0 returned color 0x%08x, expected 0x00203366\n, color); color = getPixelColor(device, 160, 360); ok((color 0x00ff) = 0x003c (color 0x00ff) = 0x004e - (color 0xff00) = 0x (color 0xff00) = 0x + (color 0xff00) = 0x (color 0x00ff) = 0x0066 (color 0x00ff) = 0x00210068, vs_1_1 returned color 0x%08x, expected 0x00808080\n, color); color = getPixelColor(device, 480, 360); ok((color 0x00ff) = 0x003c (color 0x00ff) = 0x004e - (color 0xff00) = 0x (color 0xff00) = 0x + (color 0xff00) = 0x (color 0x00ff) = 0x0066 (color 0x00ff) = 0x00210068, vs_2_0 returned color 0x%08x, expected 0x\n, color); These tests don't make much sense, with or without your fix, plus the error messages don't match the tests. This needs more work. It seems this was added with 2007-11-07 with the following log entry: Stefan Dösinger [EMAIL PROTECTED] wined3d: Shader Model 3.0 varying tests. Stefan, any chance you could look into this at one point? THanks, Gerald
Re: system tray icon regression
On Jan 24, 2008 4:10 PM, Lei Zhang [EMAIL PROTECTED] wrote: Hi, With today's wine-git, tray icons no longer work. There's a spot in the system tray where the icon should be, but nothing is displayed there and I can't interact with it. This occurred on both KDE and Gnome. I found this with Picasa, but you can also see the problem with this sample program: http://bugs.winehq.org/attachment.cgi?id=9725 - Lei Looks like it's working again with Wine 0.9.54.
Re: [PATCH] D3DXGetFVFVertexSize implementation
Am Freitag, 25. Januar 2008 19:41:52 schrieb Victor: This is a DX8 implementation of D3DXGetFVFVertexSize (i.e. D3DFVF_XYZW is commented out).I must note that I've encountered a bug in original/natvie D3DXGetFVFVertexSize - it returned wrong vertex size(one float less than needed(?)) when it was used with D3DFVF_XYZB4.It was more than a year ago, and I'm not sure if this bug still exists in native D3DX. Anyway this bug isn't reproduced here. A few comments: Regarding the possible bug in d3dx8 I recommend to add a test for this, like you're testing other flags already in dlls/d3dx8/tests/math.c . This will shed more light on the issue. If you do not have a Windows box to test on I can run the test for you. If the bug still exists Wine should clone it as well. (I don't think this function belongs to math.c by the way, probably create a new file called vertex.c or fvf.c or something like that) Your code contains some C++ comments (//), please do not use them as Wine is plain C code. I think you can just remove the D3DFVF_XYZW block if this enumeration doesn't exist in d3d8. Also please watch out with the whitespaces: The code is mixing tabs and spaces. Preferably stick to the style that is used in the rest of the file.
Re: No new winetest?
On Fri, 25 Jan 2008, Paul Millar wrote: [...] The front-end machine had stopped responding to network traffic. [...] So, sorry, winetest will be off-line until Monday at the earliest. Thanks for the status update. -- Francois Gouget [EMAIL PROTECTED] http://fgouget.free.fr/ f u kn rd ts, ur wy 2 gky 4 ur wn gd.
