October 2009 - Wine-devel - list.winehq.org

DirectX Emulation Question
by Paul Janoski 16 Oct '09

16 Oct '09

Can anybody please tell me how complete the DirectMusic wine emulation is on Linux. Thank You, Paul Janoski

3 2

Re: [1/2] oleaut32/tests: Testcase for IPicture_Render with icons, check for drawing size and position
by Paul Vriens 16 Oct '09

16 Oct '09

On 10/14/2009 07:08 PM, Wilfried Pasquazzo wrote: > Yet another testcase+fix for a regression introduced > by one of my previous patches. > > --- > [1/2] oleaut32/tests: ... > > modified files: oleaut32/tests/olepicture.c > > Draws a icon and checks if it is scaled and positioned correctly. > Windows XP passes all tests. > Wine fails at the scaling test (marked with todo_wine). > --- > [2/2] oleaut32: ... > > modified files: oleaut32/olepicture.c > modified files: oleaut32/tests/olepicture.c > > Fix for Wine scaling of Icons when drawing. > Wine now passes the previously implemented scaling test. > todo_wine of scaling test removed. > > Fixes Bug: http://bugs.winehq.org/show_bug.cgi?id=20365 > > Note: I didn't remove the FIXME-Message, because this > implementation seems still not completely right. It does only allow > to draw the whole icon, because it ignores the src width and height > parameters. However it worked well like this for over 8 years and > it is very unlikely that any real application will want to draw only a > part of an icon. > --- > > > Wilfried Pasquazzo > Hi Wilfried, This patch causes test failures on NT4 and lower: http://test.winehq.org/data/tests/oleaut32:olepicture.html Could you have a look? -- Cheers, Paul.

2 1

Re: winmm/tests: Don't complain for Wine drivers that allow multiple wave-out opens.
by Paul Vriens 16 Oct '09

16 Oct '09

On 10/16/2009 02:19 AM, Ken Thomases wrote: > - todo_wine ok(ret == MMSYSERR_NOERROR || broken(ret == MMSYSERR_ALLOCATED), /* winME */ > - "waveOutOpen returns: %x\n", ret); > - if (ret == MMSYSERR_NOERROR) > + if (ret != MMSYSERR_NOERROR) > + { > + todo_wine ok(ret == MMSYSERR_NOERROR, "second waveOutOpen returns: %x\n", ret); > + } > + else You removed the broken() statement for WinME. -- Cheers, Paul.

3 4

Re: winspool/tests: [Patch 3] Add tests for EnumPrintProcessors
by Paul Vriens 16 Oct '09

16 Oct '09

On 10/14/2009 11:56 PM, Detlef Riekenberg wrote: > > > > Hi Detlef, This one introduces a test failure on NT4 (all?) Could you have a look? -- Cheers, Paul.

1 0

Re: [1/10] Check for ms_hook_prologue attribute support, make a first function hookable
by Stefan Dösinger 15 Oct '09

15 Oct '09

Am 13.10.2009 um 22:50 schrieb Nikolay Sivov: > Stefan Dösinger wrote: >> This makes use of the gcc attribute added to gcc svn yesterday: http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00319.html >> ------------------------------------------------------------------------ > Hi, Stefan. Could you explain me briefly if you have time what this > is about? How this hook is about to work? > I guess it's something like hard wrapping for forwarding api calls > to something nondefault, or I'm wrong? CC'ing Wine-devel, since other people will probably have the same question. Steam has a feature which Valve calls "In Game Overlay". You can access certain Steam features, like the chat over voice chat from inside the game. This works without modifying the game. Other apps like Xfire have a similar feature. To make the overlay work, Steam injects a DLL into the game before it starts the game. It creates the process suspended, allocates remote memory, and puts some DLL load code there. Then it changes the entrypoint to that allocated area, which calls LoadLibrary and calls the GameOverlayRenderer.dll DllMain. Then it calls the original game entrypoint. This part works fine already. Now GameOverlayRenderer.dll has to intercept keyboard input, and it has to add its own graphics on top of the game graphics before the final result is sent to D3D. To do this, it tries to intercept calls like opengl32.wglSwapBuffers, IDirect3DSwapChain9::Present. Furthermore it hooks calls like LoadLibrary to find out if the game uses D3D9, and CreateProcess to catch children. Steam's hooker doesn't blindly replace code bytes like other apps do. It disassembles the code, and tries to preserve the instruction. It tries to free the first 5 bytes and places an unconditional immediate jump to its own code there. After this has done its business, it executes the replaced opcodes and jumps to the next instruction. Now Steam doesn't know all possible opcodes. For example, it doesn't know 89 e5 mov %esp, %ebp which is the same as 8b ec mov %esp, %ebp generated by MSVC. Furthermore, it can't deal with the LEA generated on OSX to align the stack, and it doesn't know an xor %eax, %eax used to clear the eax register, etc. Starting with WinXP SP2, microsoft added a 2 byte nop at the start of each function. It also adds 5 nops above the entrypoint. So many Win32 API functions look like this on Windows: 90 nop ; cc int 3 in some functions 90 nop ; cc int 3 90 nop ; cc int 3 90 nop ; cc int 3 90 nop ; cc int 3 func: 8b ff movl.s %edi, %edi. 55 pushl %ebp 8b ec movl.s %esp, %ebp MS' idea is to replace the 8b ff with a -5 byte jump, and replace the 5 nops with a JMP dst. They use this for hotpatching, to apply security fixes to Windows DLLs without restarting the app. They have special compiler and linker switches to create hotpatchable images. Since Steam makes a fairly reasonable assumption when it assumes that a function starts with 8b ff 55 ob ec, Alexandre and I agreed that it makes sense to do this for all Wine functions that Steam and other apps try to hook. However, the MSVC compile switches are pretty obscure. They only add the 8b ff, and they don't work together with / O2 (only /O1), and they break if you use the MSVC equivalent of -fomit- frame-pointer. So we and the gcc maintainer decided that we don't want to clone this feature 1:1 in gcc, instead we added a function attribute. The ms_hook_prologue attrib will make sure the 5 bytes before and after the function entrypoint look as the above code. This happens no matter what other options, attributes etc are used. If e.g. -fomit- frame-pointer is used, it generates this code: 90 90 90 90 90 func: 8b ff movl.s %edi, %edi. 55 pushl %ebp 8b ec movl.s %esp, %ebp ?? popl %ebp < other code > ret The first 5 bytes are marked as unspec volatile, so the optimizer will not try to optimize them away, even at -O6. If %ebp is pushed as part of <other code> the optimizer realizes this though. So gcc first dumps the 8b ff 55 8b ec, and then bothers about reconciling that with what the app actually wants. Currently only the 5 bytes after the function start are generated by gcc, it doesn't yet generate the nops. I am working on this, but it will take a bit longer because it needs some changes in the backend- frontend interaction when generating function alignment. Furthermore there's a bug in binutils that when you explicitly align a function with .align X, 0x90 (ie, you request that 0x90 bytes are used for alignment) it will optimize those nops into a single 3, 4, 5, ... byte nop.

2 1

Re: test {IDirect3DTexture8, IDirect3DSurface8}::UnlockRect for rectangles that are not locked
by Stefan Dösinger 15 Oct '09

15 Oct '09

Do I read this correctly that a double unlockrect call on a surface fails, while a double unlockrect call on a texture succeeds? From the context of the patch its a bit hard to read. Here are some more test suggestions: -> Create a texture, retrieve its surface, and call LockRect/ UnlockRect on the surface. Does this show the surface or texture behavior -> What happens if you have a texture, retrieve a surface and mix locks on the surface and texture? -> What is the d3d9 behavior?

1 0

re: Usual oss choices missing in winecfg, in today's git
by Maarten Lankhorst 15 Oct '09

15 Oct '09

Hi, The explanation is probably much simpler: OSS likely won't show up if the sound device is in use, since it claims total control. If anything in the background is using sound, it is possible to not see OSS at all. lsof /dev/dsp* /dev/snd/* probably tells you if anything uses it. Cheers, Maarten.

1 0

Usual oss choices missing in winecfg, in today's git
by Susan Cragin 15 Oct '09

15 Oct '09

Just built today's git, and am running DNS with alsa. (Thanks, Maarten.) Called up winecfg as usual and found there were no options under OSS Driver. No wave-out, no wave-in, no mixer devices. Nada. Peculiar, never saw this before. So I thought I'd call in.

2 1

Re: [PATCH] Add test case to user32 winetests for edit control context menu. Try 2
by Nikolay Sivov 15 Oct '09

15 Oct '09

Michael Martin wrote: > This patch adds test for edit control clipboard context menu. > The test passes on Windows XP as the WM_COMMAND message is not sent to > the edit control by its context menu. > Fails on wine because wine does incorrectly send that message. > This problem shows up using the edit class context menu on application > created with vb6.0, which leads to application crashing. > The code does not use WINE_TODO() because a simple fix for this will > be sent when > this problem is accepted. It isn't a point, your patch shouldn't break tests, resend with todo_wine please. > Mike > Attach your patch as a diff file, your message client formats it now.

1 0

Re: [PATCH 2/4] comctl32/tooltips: Test the way structure size field is validated (try2)
by Paul Vriens 15 Oct '09

15 Oct '09

On 10/15/2009 12:59 PM, Nikolay Sivov wrote: > Changelog: > - try2: skip for W call failure added > - test the way structure size field is validated > > > > Hi, + + /* 1. test size parameter validation rules (ansi messages) */ + hwnd = CreateWindowExA(0, TOOLTIPS_CLASSA, NULL, 0, + 10, 10, 300, 100, + NULL, NULL, NULL, 0); + + ti.cbSize = TTTOOLINFOA_V1_SIZE - 1; + ti.hwnd = NULL; + ti.hinst = GetModuleHandleA(NULL); + ti.uFlags = 0; + ti.uId = 0x1234ABCD; + ti.lpszText = NULL; + ti.lParam = 0xdeadbeef; + GetClientRect(hwnd, &ti.rect); + r = SendMessageW(hwnd, TTM_ADDTOOLA, 0, (LPARAM)&ti); Still some W-calls left. -- Cheers, Paul.

2 1