- wine-devel - winehq.org

Re: [3/3] ddraw/tests: Add a partial block lock test
by Alexandre Julliard 08 Nov '11

08 Nov '11

Stefan Dösinger <stefan(a)codeweavers.com> writes: > @@ -4,7 +4,7 @@ > * Copyright (C) 2005 Antoine Chavasse (a.chavasse(a)gmail.com) > * Copyright (C) 2005 Christian Costa > * Copyright 2005 Ivan Leo Puoti > - * Copyright (C) 2007 Stefan Dösinger > + * Copyright (C) 2007-2011 Stefan Dösinger for CodeWeavers Adding a range of years in a copyright notice is usually discouraged, because it's only valid if you have actually made significant changes every year, which doesn't seem to be the case here. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH 3/7] ntoskrnl: intialze unknown fields of the irp with 0xce in IoInitializeIrp
by Alexandre Julliard 08 Nov '11

08 Nov '11

Bernhard Loos <bernhardloos(a)googlemail.com> writes: > @@ -864,6 +873,10 @@ VOID WINAPI IoCompleteRequest( IRP *irp, UCHAR priority_boost ) > > iosb = irp->UserIosb; > status = irp->IoStatus.u.Status; > + > + assert( status != STATUS_PENDING ); > + assert( status != 0xdeafbeef ); > + You can't assert on things that are set by the caller. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: kernel32/tests: add tests for GetDllDirectory (try 2)
by Alexandre Julliard 08 Nov '11

08 Nov '11

Thomas Faber <thfabba(a)gmx.de> writes: > + /* no buffer, determine length */ > + SetLastError(0xdeadbeef); > + ret = pGetDllDirectoryA(0, NULL); > + error = GetLastError(); > + ok(ret == length + 1, "Expected %u, got %u\n", length + 1, ret); > + ok(error == 0xdeadbeef, "Error is %u\n", error); Testing last error on success is generally not useful. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [10/11] ddraw/tests: Add assorted D3D3 DrawPrimitive/visual tests.
by Stefan Dösinger 08 Nov '11

08 Nov '11

Hi, Design-wise I think the 8 triangles and readback grid make the test fairly difficult to read. You could set up a structure that contains the d3d parameters you're changing between the tests and the expected color and then loop over the table. Something like this: const struct { BOOL d3drs_lighting; DWORD dp_flags; <- for things like D3DP_DONOTLIGHT DWORD fvf; void *vertices; DWORD expected_color; } test_data[] = { ... }; You can also think about sharing this control table between d3d2, d3d3 and d3d7 by having different color fields for that, but I don't know how well this will work. On Monday 07 November 2011 23:27:13 Octavian Voicu wrote: > + DWORD expected[] = { GRAY, WHITE, YELLOW2, YELLOW, GREEN, GREEN, BLUE, BLUE }; Please make data const where you can. > + /* Note: IDirect3DDevice3::DrawPrimitive calls with D3DVT_ vertex > types should fail. */ + > + /* Triangle 0 -- D3DFVF_VERTEX (vertices with normals, but without > colors). */ + hr = IDirect3DDevice3_DrawPrimitive(Direct3DDevice3, > D3DPT_TRIANGLELIST, D3DVT_VERTEX, > + vertices, 3, D3DDP_WAIT); > + ok(hr != DDERR_INVALIDPARAMS, "DrawPrimitive returned: %08x\n", > hr); I don't think there's a point in testing this, both D3DVT_* and D3DFVF_* are defines / enums that map to integers, and it is obvious that you get wrong behavior if you mix those. The ok condition looks strange. If you're trying to avoid a todo_wine, don't do that, just mark tests that show a difference between Wine and Windows as todo_wine. (I guess Wine currently returns DD_OK, and Windows returns D3DERR_INVALIDVERTEXFORMAT) > + /* Make sure getPixelColor works correctly. */ > + color = getPixelColor(device, 320, 240); > + ok(color == RED, "getPixelColor returned: %08x\n", color); We have some sanity checks for that in the main function Most of this applies to the d3d2 and d3d3 tests as well. I haven't looked over the cleanup patches yet.

2 1

Re: winscard/tests: Add the tests file (try 3)
by Bruno Jesus 07 Nov '11

07 Nov '11

On Mon, Oct 31, 2011 at 23:27, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > try 3 - avoid magic constants by using winscard.h defines > try 2 - split the patches and fix win2000 error > > This is the starting point for the winscard implementation. I'll add > dozens of tests and I would like all of them to pass in windows before > we start using pcsclite. > Testbot will probably be useless since it does not have a smartcard > reader connected so I'll ensure all tests succeed in my local machine > before submitting them to wine (i'll append the test results on the patch email) > > In the next days I'll be updating the test file constantly by adding a > new tested function per patch. > Hi, I would like to know if there is anything wrong with this patch? It is currently working on testbot and introduces the tests file for the winscard dll. http://source.winehq.org/patches/data/80485 I really would like to get smart cards working until the wine l337 release. Thanks in advance, Bruno

1 0

Re: [PATCH 3/6] [UnInstall]: No longer use unix stdio functions, but the kernel32 equivalent
by Alexandre Julliard 07 Nov '11

07 Nov '11

Eric Pouech <eric.pouech(a)orange.fr> writes: > #28185 > > A+ > --- > > programs/uninstaller/main.c | 65 ++++++++++++++++++++++++++++++------------- > 1 files changed, 46 insertions(+), 19 deletions(-) I'm not sure that's a good idea. The output of uninstaller is meant to be used by Unix apps, it's not something a user would want to display on the console. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: winealsa: Don't set ALSA's period time.
by Alexandre Julliard 07 Nov '11

07 Nov '11

Joerg-Cyril.Hoehle(a)t-systems.com writes: > Hi, > > perhaps I shouldn't send this one day before release... > > I argue that Wine has no business setting ALSA's period size, > esp. not to a completely random value like duration/10. It doesn't work here: ../../../tools/runtest -q -P wine -M dsound.dll -T ../../.. -p dsound_test.exe.so capture.c && touch capture.ok capture.c:618: Test failed: Should not fail for 8 or 16 bits per sample capture.c:618: Test failed: Should not fail for 8 or 16 bits per sample make: *** [capture.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: cmd: Add helper for 'if' comparison operations evaluation (try 2)
by Octavian Voicu 07 Nov '11

07 Nov '11

2011/11/7 Frédéric Delanoy <frederic.delanoy(a)gmail.com>: > + /* Note: '==' can't be returned by WCMD_parameter since '=' is a separator */ > + p = paramEnd + 1; > + while (*p == ' ' || *p == '\t') > + p++; > + > + if (!p || *p != '=' || !(p+1) || *(p+1) != '=') > + goto syntax_err; > + > + strcpyW(operator, eqeqW); > + p += strlenW(operator); Hi, This doesn't look general enough, I'm not sure how you want to handle the other operators. Wouldn't it be better to just find next space/tab (skip all non-whitespace chars) then assign the part of the string separated by whitespace to be the operator? With this approach you also don't need that syntax check there. Octavian

2 1

Re: [2/2] mscoree: Implement ICorDebug CreateProcess
by Alexandre Julliard 07 Nov '11

07 Nov '11

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > + { > + HANDLE handle, thread; > + DuplicateHandle(GetCurrentProcess(), lpProcessInformation->hProcess, > + GetCurrentProcess(), &handle, 0, FALSE, DUPLICATE_SAME_ACCESS); > + DuplicateHandle(GetCurrentProcess(), lpProcessInformation->hThread, > + GetCurrentProcess(), &thread, 0, FALSE, DUPLICATE_SAME_ACCESS); > + hr = CorDebugProcess_Create(This, (IUnknown**)&pDebugProcess, > + lpProcessInformation->dwProcessId, handle, thread); It would be better to duplicate the handles in CorDebugProcess_Create, and of course check for error and return an appropriate failure. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/2] ntdll: Setting WRITECOPY protection on an image section is allowed.
by Alexandre Julliard 07 Nov '11

07 Nov '11

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > This patch should fix the regression reported in the bug 28994. This needs more test cases, in particular for normal file mappings, as well as for VirtualAlloc behavior. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [1/2] kernel32/tests: add tests for GetDllDirectoryA
by Vitaliy Margolen 06 Nov '11

06 Nov '11

On 11/06/2011 09:14 AM, Thomas Faber wrote: > > + length = strlen(dll_directories[i]); > + assert(sizeof(buffer) > length + 1); Please don't do this. Tests shouldn't assert because programmer failed to pick the right buffer size of hard-coded strings. > + ok(GetLastError() == 0xdeadbeef, "Error is %u\n", GetLastError()); You should get value of GetLastError() before the ok check here. See all places that check values of GetLastError(). > + ok(buffer[length + 1] == 'A', "i=%d, Buffer overflow\n", i); > + ok(buffer[ret] == 0, "i=%d, Wrong length or not null terminated\n", i); > + ok(strcmp(buffer, dll_directories[i]) == 0, "i=%d, Wrong path returned: '%s'\n", i, buffer); You can do all these with one memcmp call. > > + ok(buffer[length + 1] == 'A', "i=%d, Buffer overflow\n", i); > + ok(buffer[ret] == 0, "i=%d, Wrong length or not null terminated\n", i); > + for (j = 0; buffer[j]; j++) > + if (buffer[j] != dll_directories[i][j]) > + { > + ok(0, "i=%d, Wrong path returned: %s\n", i, wine_dbgstr_w(buffer)); > + break; > + } Same for this. > + ok(buffer[0] == 0 || /* XP, 2003 */ > + buffer[0] == 'A', "i=%d, Buffer overflow\n", i); Please mark bad case with broke() to check for correct Wine behavior. Also please combine A & W tests. They do mostly the same things. Vitaliy.

2 1

Re: [1/2] kernel32/tests: add tests for GetDllDirectoryA
by Vincent Povirk 06 Nov '11

06 Nov '11

I don't think you can rely on C:\Windows existing. On Sun, Nov 6, 2011 at 10:14 AM, Thomas Faber <thfabba(a)gmx.de> wrote: > > > >

3 2

Re: [2/2] mscoree: Implement ICorDebug CreateProcess
by Vincent Povirk 05 Nov '11

05 Nov '11

I'm curious why you've chosen to work on this. Is there a program relying on this, or do you have some .NET debugging tools you'd like to use? Or are you thinking we'd implement our own debugging tool as well (perhaps extending winedbg)? Better debugging tools for wine/mono would definitely be nice, but there are a lot of things we need, and this is not the first one I'd pick. The current state of the art in Mono debugging is the soft debugger. >From what I've heard, all other debugger technologies in Mono have been deprecated. http://www.mono-project.com/Mono:Runtime:Documentation:SoftDebugger They have documentation on the wire protocol, which is probably what we'd end up using because .NET libraries are inconvenient to use. >From what I can tell, the soft debugger needs to be configured to listen for TCP connections on a particular port. Ideally, we would want to modify it by adding a new "transport" using something like a named pipe server named based on the process id (it looks straightforward to do so, but we'd have to modify the mono runtime). Otherwise, I'm not sure how we'd identify the socket server for the process we want, and having mono run a TCP server all the time seems like a bad idea. It may also be possible to configure mono to use the soft debugger in the "normal" way and attach to it with a Linux MonoDevelop, if you want a quicker solution. It seems like it's designed to remotely debug any mono process on any platform. If you figure out how to do this, wiki documentation would be appreciated.

2 1

Warning report for wine-1.3.32
by Jerome Leclanche 04 Nov '11

04 Nov '11

warning: variable ‘_qzz_res’ set but not used [-Wunused-but-set-variable] That's valgrind stuff. Apparently I might need a valgrind update or something, I'm not 100% sure what's going on. A few more can be fixed with FIXME()s instead of comments. J. Leclanche

1 0

Re: [3/4] msxml3: Add IDispatchEx support for IXMLDOMNamedNodeMap
by Jacek Caban 04 Nov '11

04 Nov '11

Hi Nikolay, On 11/04/11 16:46, Nikolay Sivov wrote: > + if(This->data->vtbl&& This->data->vtbl->invoke) { > + hres = This->data->vtbl->invoke(This->outer, id, lcid, wFlags, pdp, pvarRes, pei); > + if (hres != E_NOTIMPL) return hres; > + } Using E_NOTIMPL for special meaning here seems wrong to me. DISP_E_UNKNOWNNAME could be a better choice. However, if you'd move custom invoke implementation to be the last choice, after dynamic and typelib-based values, then you could simply return whatever invoke returns. Jacek

3 3

Re: [PATCH] userenv: GetUserProfileDirectoryW should fail with ERROR_INVALID_HANDLE if handle is NULL.
by Alexandre Julliard 04 Nov '11

04 Nov '11

Christian Inci <chris.pcguy.inci(a)gmail.com> writes: > @@ -149,6 +149,12 @@ BOOL WINAPI GetUserProfileDirectoryW( HANDLE hToken, LPWSTR lpProfileDir, > > TRACE( "%p %p %p\n", hToken, lpProfileDir, lpcchSize ); > > + if (!hToken) > + { > + SetLastError( ERROR_INVALID_HANDLE ); > + return FALSE; > + } There's no reason to treat a 0 handle differently. Please stop adding such special cases just to satisfy the tests. Parameter checking needs to fall out of the implementation. -- Alexandre Julliard julliard(a)winehq.org

1 0

winedevice taking up 100% after wine cmd
by Hin-Tak Leung 04 Nov '11

04 Nov '11

I just had a rather odd incident earlier today when I just launched "wine cmd", and saw that my process monitor max-out to 100% - and it continued, until I finished what I intended to do and exited cmd, minutes later. I wasn't doing anything else and no typing anything in the cmd console either, so that was curious. It was winedevice taking up 100%. I tried wine cmd later but couldn't get that odd behavior any more. But is there any reason why winedevice should go into a spin? This is fedora 15 x86_64 running 32-bit wine I built myself.

2 1

Re: [PATCH] shell32: IShellDispatch_NameSpace: Special-folder argument shouldn't be negative.
by Alexander Morozov 03 Nov '11

03 Nov '11

-1 in this test is only a sample of a bad constant. Do you sure that S_OK should be returned for any positive argument?

3 2

Re: winealsa: Don't set ALSA's period time.
by Andrew Eikum 03 Nov '11

03 Nov '11

On Thu, Nov 03, 2011 at 09:41:46AM +0100, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > perhaps I shouldn't send this one day before release... > > I argue that Wine has no business setting ALSA's period size, > esp. not to a completely random value like duration/10. > Better leave it complete freedom, as confirmed in > http://mailman.alsa-project.org/pipermail/alsa-devel/2011-August/042837.html > > What I think may be interesting is set min and/or max of the *buffer* time I completely agree, and have similar patches sitting in Bugs 28723 (don't set period time) and 28282 (request ALSA buffer time near requested MMDevice buffer time; needs more thought), although I was waiting for feedback from users before submitting. I have no problem with this patch getting in today, though it is late in the cycle, yeah ;) Andrew

1 0

Re: [2/3] ntdll: Use PAGE_READWRITE access when resolving DLL imports.
by Alexandre Julliard 03 Nov '11

03 Nov '11

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > diff --git a/dlls/ntdll/loader.c b/dlls/ntdll/loader.c > index 5ee7d0a..314813f 100644 > --- a/dlls/ntdll/loader.c > +++ b/dlls/ntdll/loader.c > @@ -563,7 +563,7 @@ static WINE_MODREF *import_dll( HMODULE module, const IMAGE_IMPORT_DESCRIPTOR *d > protect_base = thunk_list; > protect_size *= sizeof(*thunk_list); > NtProtectVirtualMemory( NtCurrentProcess(), &protect_base, > - &protect_size, PAGE_WRITECOPY, &protect_old ); > + &protect_size, PAGE_READWRITE, &protect_old ); Restoring the permissions is not going to work if it was already writable. -- Alexandre Julliard julliard(a)winehq.org

2 4

RFC: wined3d: Implementing depth/stencil buffer locking
by Octavian Voicu 03 Nov '11

03 Nov '11

Hi, Here is a first shot at implementing depth/stencil buffer locking in wined3d. Currently depth/stencil buffer locations are onscreen and offscreen, with transitions between the two states done in load_ds_location. I added another location, sysmem, and implemented transitions from offscreen to sysmem and from sysmem to offscreen. If buffer is onscreen, it will be moved offscreen first, then to sysmem. Some issues with this implementation: 1) make dsurface.ok in ddraw/tests crashes in context_acquire (wined3d/context.c:2456) called from surface_load_location (wined3d/surface.c:6323), I'm guessing in because there is no swapchain. How can I prevent this crash and still get a context? Loading from offscreen to sysmem shouldn't require a swapchain. 2) When running my test app [1] I also get this error: err:d3d_surface:surface_load_ds_location >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from glTexSubImage2D @ ../../../../wine/dlls/wined3d/surface.c / 5877 3) There are other issues with my test app (looks like it's related to textures), so can't be sure if locking works correctly. There is an improvement over the unpatched version, but can't be sure until the other issue is resolved. Game uses pre-rendered backgrounds and probably loads the Z-buffer by locking the surface, so it can render 3D characters correctly over the pre-rendered backgrounds. It happens in the "if (surface->flags & SFLAG_DS_SYSMEM)" branch of the surface_load_ds_location function. Uploading happens on each frame, this error only happens for the first upload. I'm quite new to wined3d code so I might have missed some obvious things. Any comments and suggestions are welcome. Thanks. Octavian [1] The demo of The Longest Journey, available for download here (to reproduce, click on the Begin Journey, press ESC to skip intro movies; notice how rendered characters look): http://games.softpedia.com/get/Games-Demo/The-Longest-Journey-161-Demo.shtml

3 3

Re: mshtml: call FindMimeFromData with a NULL buffer in ResProtocol_Start
by Paul Chitescu 02 Nov '11

02 Nov '11

On Wednesday 02 November 2011 07:19:02 am Austin English wrote: > Fixes http://bugs.winehq.org/show_bug.cgi?id=27115, a regression > introduced by 0825f4b3ff3718752b5f6addd95bc30c10f75d24. Instead of not passing actual read data please fix FindMimeFromData. Reverting the patch will break many programs that store images (GIF, PNG) in resources with non-descriptive names.

1 0

MS XInput*.dll implementation
by Alexey Loukianov 02 Nov '11

02 Nov '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Good day to all, I've got a general question about the Windows subsystem I'm a bit interested of and considering spending some time trying to implement it. What I'm talking about is "new" input handling API MS positions as the DirectInput successor: XInput 1.x. Looks like currently Wine includes general stubs for older version of XInput dlls ("legacy stipped down" XInput9_1_0, and later versions ranging from 1.1 up to 1.3; XInput 1.4 which is documented to be the core component of upcoming Windows 8 isn't implemented yet). Stubs are pretty much what they are: general placeholders so APPs would be able to link to these DLLs and get semi-correct return codes from procs. What I'm interested in (and that's is the reason I'm posting to devlist) is what are the plans on real implementation of MS XInput API? Are there anybody working on topic? Were there any preliminary patches floating around aimed at implementing this API in Wine? I'm asking this question because I had recently tried to use force-feedback capable gamepad by Thrustmaster under Wine and found it to be working pretty well through DirectInput[8] API, but not being accessible through XInput API and thus failing to properly work with force-feedback enabled applications. Reading the docs on MSDN made me believe that force-feedback on GamePads can't be properly handled through DirectInput API - it was MS design decision to deprecate DI in favor of XInput and no to extend DI effects support with "rumble" effect. Thus to get proper behavior for GamePads force-feedback under Wine it is required to implement XInput API. General investigation on topic shows that this isn't as easy as it might seem at a first glance. Just looking at code sniplet by MS that accomplishes task of filtering out XInput-capable devices from DirectInput enumerated device list shows that MS is just the old-bad MS: relying on third-party low-level system API (WMI) to enumerate all the available PnP devices of a certain class and then filter them out based on VID/PID and a part of PNPID substring isn't a good programming practice IMO. In any case it is a thing that should be somehow dealt with in Wine since current and future games might be already using this technique and are certainly using both DirectInput and XInput to handle various types of "game input devices". That being said, and in case there no one out there is working on the topic, what considerations should I stick with if I would proceed with trying to implement XInput API in Wine? Thanks in advance for answers and insights. - -- Best regards, Alexey Loukianov mailto:mooroon2@mail.ru System Engineer, Mob.:+7(926)218-1320 *nix Specialist -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOr6QoAAoJEPB9BOdTkBULPA4H/1G4IowO2DGXZPX2728Pb/sV Lx+TisQ2fODW4gzCdCKLdh6CuLkaQCwCRbQ4zqrV6ksW3yLtpYHJ7z2I/kHL2RYX wzXBEU5mYY2b/WVPuL9LETCxMA/fZGBN/2RkSAWpjwpNzLwaGD10KUwyXa6rSFkh eAigINhgSkEX+uHV3ZdKvnuXLrluZQsSwZtudMvxiMfBf8mxBuZtgXyIIaWxTF5z Vo4YKn+QFtUi6CwQA8vPYtm4617TPs8cwTr0p1lOigT3gFqgYQGgDiUK7KZGyDlD YhgwezwUAIgDQAEpUMvXtB5j4fAfqyrXtrQzwoCgzBan4Yf7B5FLKxP0RtWrrL4= =d+Dp -----END PGP SIGNATURE-----

3 4

Re: MS XInput*.dll implementation
by Alexey Loukianov 01 Nov '11

01 Nov '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 01.11.2011 11:58, Dan Kegel wrote: > Hi, I doubt anyone's working on it (would like to be wrong about that). > Things to keep in mind: ... Dan, thanks for a quick answer on topic. Besides these general and very valuable keypoints there are some other things that should be clarified (or at least discussed) before proceeding with writing code. Most important things to talk about that I can think of at a first glance: a) Obtaining specs. Black-box testing is always a good thing (had learned it with pain when been studying how to write programs for the Window 3.x). What I've got available to do the tests are three Windows-based PCs, each running different version of OS, namely W2k Prof, WXP Home and Win7 Starter. XP and Seven are surely a good targets for XInput black-box testing and implementing test cases. Not sure for W2k, would need to investigate further. Things getting worse when it comes to hardware: the only "game input device" I have on hand is the aforementioned gamepad by Thrustmaster. MSDN XInput docs state that XInput was primarily targeted at supporting Xbox360 gamepads, and it looks like that there are a bunch of different subtypes of these devices out there in the wild. At the best case I only would be able to investigate XI behavior for most generic XINPUT_DEVSUBTYPE_GAMEPAD type which my gamepad most closely corresponds to. Would try to ask my friends in case they've got some controllers that fit into other XINPUT_DEVSUBTYPE_* categories. b) I'm pretty limited with Linux-only as a host system for Wine. Thus it would be impossible for me to write the code that supports FreeBSD and/or Mac OS X. c) Separate challenge would be to detect the correct XINPUT_DEVSUBTYPE for game input controller under linux. As far as I understand event-driven linux input API correctly, it doesn't have any means of distinction between different game controllers types. What is possible though is to detect VID/PID, the product brand-name and the number of axis and buttons. It makes possible to implement some kind of "device database" and determine the correct XINPUT_DEVSUBTYPE basing on the info from this database, but I don't think it would be the most clear and maintainable solution ever (database should be maintained, populated with new HW defs, e.t.c). d) Code duplication issues. XInput API mirrors DirectInput API at some part and it might be reasonable to re-use code parts from the existing DirectInput linux event-based joystick driver. I am thinking about implementing XInput on top of DirectInput + extending existing DI linux event-based joystick driver COM API with Wine-specific extensions (this is required to add support for "rumble" FF effect). There are Windows drivers out there that work in exactly this way (XBCD in a good example offering drop-in XInput wrapper dll that maps to the DI calls). e) List of games that might benefit from XInput support is pretty big, one may wish to take a look onto this Wiki page for examples: http://en.wikipedia.org/wiki/List_of_XInput_enabled_games Chances are some titles out there are free and open source but investigation is needed to name exact titles. I own some of the commercial titles from that list (for ex. Braid, Borderlands, DiRT, DiRT 2. Fallout 3, Fuel, L4D, L4D2, LIMBO, Grid, RAGE, The Witcher 2, titles from The Orande Box, Portal 2, UT3) so it would be possible for me to test the XInput implementation on the broad range of native apps. Still I would try to search for free (and maybe OSS) Win32 game that might be used by anybody as the "example testcase". - -- Best regards, Alexey Loukianov mailto:mooroon2@mail.ru System Engineer, Mob.:+7(926)218-1320 *nix Specialist -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOr/4kAAoJEPB9BOdTkBULM+QIAKyG73I7BpcWvSqBRpee9ljF HTEMCRG5mKZymSqi+prTQQnQgYs0rdq/paPTzUlYoCtD4ZsoIaNMYRSQUkQuKLHB aO0JFdEJEa6liiABR05y3xfjYqd7am2tHDfHSTTO2o1TCmphJau5QquaSNCG5Sh1 Xe1eoVc6RWMxzgQqFuGtEPV34B1s2wiFzjosXv9NZWSwwxL0m9bgBvDeJKvNcNnT tsymMur2SkWXh9sgKwW0wJ3MENlSk5BP0z4I649EWCHgTf8lfz6HFj8fwShsl3KD SvmP8woqUXl93g5eEqM18bIVFm/gyRYEzVTZJTize8/E9dZtgUbtWoQv3t/c81s= =8M6g -----END PGP SIGNATURE-----

4 5

Re: [PATCH] mmdevapi: Print a winediag message for the registry driver value
by Alexandre Julliard 01 Nov '11

01 Nov '11

Andrew Eikum <aeikum(a)codeweavers.com> writes: > @@ -126,6 +127,8 @@ static BOOL init_driver(void) > > if(RegQueryValueExW(key, drv_value, 0, NULL, (BYTE*)reg_list, > &size) == ERROR_SUCCESS){ > + TRACE_(winediag)("MMDevAPI driver registry value: %s\n", > + wine_dbgstr_w(reg_list)); I'm not sure that's very useful, winediag messages are supposed to be ERRs. If people having an old broken registry key is really a problem, then we should use a different key, or maybe simply get rid of it and do it through dll overrides or something like that. -- Alexandre Julliard julliard(a)winehq.org

1 0

re: MS XInput*.dll implementation
by Dan Kegel 01 Nov '11

01 Nov '11

Hi, I doubt anyone's working on it (would like to be wrong about that). Things to keep in mind: - contributing test cases is good - looking at Microsoft code, even watching traces with Process Monitor, is bad and can get your code rejected - so contributing test cases is very good. blackbox testing, illuminated by msdn or other doc, is the way to establish the real spec. - pointing to a freely downloadable real game that benefits from a patch is helpful - quick and dirty prototype that kind of works would gather some interest - but to get real code in, do it in small useful chunks, each with a test if possible - See of course http://wiki.winehq.org/SubmittingPatches - Generally pay more attention to people with more patches in, git shortlog -s -n --since="(1year)" origin and of course to people who have contributed input code. I'm just an interested bystander at this point. Good luck! - Dan

1 0

Re: [3/4] d3d9/tests: Test partial block locks
by Henri Verbeet 01 Nov '11

01 Nov '11

On 31 October 2011 20:03, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + case D3DPOOL_SCRATCH: > + case D3DPOOL_SYSTEMMEM: > + hr = IDirect3DDevice9_CreateOffscreenPlainSurface(device, 128, 128, formats[i].fmt, > + D3DPOOL_SCRATCH, &surface, 0); That doesn't really test D3DPOOL_SYSTEMMEM.

2 1

Re: [PATCH 2/5] wined3d: Create the DIB section for DDSCAPS_OWNDC surfaces on initialization.
by Stefan Dösinger 31 Oct '11

31 Oct '11

On Monday 31 October 2011 19:48:12 Henri Verbeet wrote: > --- > dlls/ddraw/surface.c | 3 +++ > dlls/wined3d/surface.c | 11 +++++++++++ > include/wine/wined3d.h | 1 + > 3 files changed, 15 insertions(+), 0 deletions(-) > > diff --git a/dlls/ddraw/surface.c b/dlls/ddraw/surface.c > index 3860959..567d086 100644 > --- a/dlls/ddraw/surface.c > +++ b/dlls/ddraw/surface.c > @@ -5273,6 +5273,9 @@ HRESULT ddraw_surface_init(IDirectDrawSurfaceImpl > *surface, IDirectDrawImpl *ddr if (desc->ddsCaps.dwCaps & DDSCAPS_ZBUFFER) > usage |= WINED3DUSAGE_DEPTHSTENCIL; > > + if (desc->ddsCaps.dwCaps & DDSCAPS_OWNDC) > + usage |= WINED3DUSAGE_OWNDC; You would get the same effect by calling GetDC and ReleaseDC from ddraw or ddrawex without another usage flag. Probably ddrawex should do that since it sets DDSCAPS_OWNDC, assuming that IE 8 still uses ddrawex. > + /* Similar to lockable rendertargets above, creating the DIB section > + * during surface initialization prevents the sysmem pointer from > changing + * after a wined3d_surface_getdc() call. */ Is this a property of DDSCAPS_OWNDC, or sysmem surfaces in general? I'd expect that this applies to sysmem surfaces in general. Otoh we don't really want to create a DIB section for every sysmem surface, especially with bug 5535 in mind.

2 2

Re: [4/4] wined3d: YUY2 and UYVY are block based
by Marvin 31 Oct '11

31 Oct '11

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=15193 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: [3/4] d3d9/tests: Test partial block locks
by Marvin 31 Oct '11

31 Oct '11

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=15192 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: ddraw/tests: Move some surface attachment tests from refcount to dsurface and enhance them.
by Marvin 31 Oct '11

31 Oct '11

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=15183 Your paranoid android. === W2KPROSP4 (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === WXPPROSP3 (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === W2K3R2SESP2 (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === WVISTAADM (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === W2K8SE (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === W7PRO (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === W7PROX64 (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === TEST64_W7SP1 (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === W7PROX64 (64 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === TEST64_W7SP1 (64 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a

1 0

Re: [4/4] wined3d: YUY2 and UYVY are block based
by Henri Verbeet 31 Oct '11

31 Oct '11

On 31 October 2011 20:17, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > {WINED3DFMT_ATI2N, GL_COMPRESSED_LUMINANCE_ALPHA_3DC_ATI, GL_COMPRESSED_LUMINANCE_ALPHA_3DC_ATI, 0, > GL_LUMINANCE_ALPHA, GL_UNSIGNED_BYTE, 0, > - WINED3DFMT_FLAG_POSTPIXELSHADER_BLENDING | WINED3DFMT_FLAG_FILTERING, > + WINED3DFMT_FLAG_POSTPIXELSHADER_BLENDING | WINED3DFMT_FLAG_FILTERING | WINED3DFMT_FLAG_COMPRESSED, > GL_COMPRESSED_RED_GREEN_RGTC2 is also compressed.

1 0

Re: [PATCH 4/5] wined3d: Make the buffer parameter to buffer_is_dirty() const.
by Josh Juran 31 Oct '11

31 Oct '11

On Oct 31, 2011, at 11:48 AM, Henri Verbeet wrote: > --- > dlls/wined3d/buffer.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/wined3d/buffer.c b/dlls/wined3d/buffer.c > index 45518cc..69c110a 100644 > --- a/dlls/wined3d/buffer.c > +++ b/dlls/wined3d/buffer.c > @@ -76,9 +76,9 @@ static inline void buffer_clear_dirty_areas(struct wined3d_buffer *This) > This->modified_areas = 0; > } > > -static inline BOOL buffer_is_dirty(struct wined3d_buffer *This) > +static BOOL buffer_is_dirty(const struct wined3d_buffer *buffer) > { > - return !!This->modified_areas; > + return !!buffer->modified_areas; > } > > static inline BOOL buffer_is_fully_dirty(struct wined3d_buffer *This) > -- Looks like you lost an 'inline'. Was that intentional? Josh

2 1

Re: 80199: shdocvw: add a stub for InstallReg_RunDLL
by Dan Kegel 31 Oct '11

31 Oct '11

Fails to build here? On Thu, Oct 20, 2011 at 3:51 PM, <buildbot(a)kegel.com> wrote: > This is an experimental automated build and test service. > Please feel free to ignore this email while we work the kinks out. > > For more info about this message, see http://wiki.winehq.org/BuildBot > > The Buildbot has detected a failed build on builder runtests-default while building Wine. > Full details are available at: http://buildbot.kegel.com/builders/runtests-default/builds/803 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) > BUILD FAILED: failed shell_2 > > Errors: > shdocvw_main.c: In function 'InstallReg_RunDLL': > shdocvw_main.c:547:159: error: format '%p' expects a matching 'void *' argument [-Werror=format] > shdocvw_main.c:547:159: error: format '%p' expects a matching 'void *' argument [-Werror=format] > make[1]: *** [shdocvw_main.o] Error 1 > make: *** [dlls/shdocvw] Error 2 > make: *** Waiting for unfinished jobs.... > >

2 1

Re: [PATCH 2/5] ddraw: Implement copy_mipmap_chain() on top of wined3d_surface_blt().
by Stefan Dösinger 31 Oct '11

31 Oct '11

On Sunday 30 October 2011 18:06:33 Henri Verbeet wrote: > + if (FAILED(hr = > wined3d_surface_blt(dest_level->wined3d_surface, &dst_rect, > + src_level->wined3d_surface, &src_rect, 0, NULL, > WINED3DTEXF_POINT))) Wouldn't wined3d_device_update_surface be a better match? IDirect3DDevice7::Load could probably be handled by wined3d_device_update_texture if it wasn't for color keys/palettes.

2 1

RFC: Make X11 window rect empty for WS_EX_TRANSPARENT windows
by Octavian Voicu 30 Oct '11

30 Oct '11

Hi, Attached patch fixes http://bugs.winehq.org/show_bug.cgi?id=28678. The root problem is that X11 windows cannot be made transparent (allowing other windows to draw over them). My approach I to make the X11 window with WS_EX_TRANSPARENT extended style have an empty region. Obviously, this is very hacky and except for very particular cases (like the bug I'm trying to fix) it won't work at all, so this patch is more like a proof-of-concept than a fix. For example, window decorations aren't drawn and not even the window can paint itself. This becomes kind of a recursive question -- how to draw the contents of the window-less window? Can this approach ever work? Any comments or suggestions are welcome. Octavian

1 0

d3dx9_36: Simplify the computation of a 2-adic valuation
by David Adam 29 Oct '11

29 Oct '11

Hello, please discard this patch. It is logically wrong. David

1 0

Re: cmd: Avoid mixing signed and unsigned type in conditional expression
by Eric Pouech 28 Oct '11

28 Oct '11

why do we check for ptr being null or not, when we deref ptr one line above ? something's wrong in the code logic A+ Le 27 octobre 2011 04:53, Frédéric Delanoy <frederic.delanoy(a)gmail.com> a écrit : > --- > programs/cmd/wcmdmain.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/programs/cmd/wcmdmain.c b/programs/cmd/wcmdmain.c > index 56aa85f..1bcc598 100644 > --- a/programs/cmd/wcmdmain.c > +++ b/programs/cmd/wcmdmain.c > @@ -278,7 +278,7 @@ static void WCMD_output_asis_handle (DWORD std_handle, > const WCHAR *message) { > ptr++; > }; > if (*ptr == '\n') ptr++; > - WCMD_output_asis_len(message, (ptr) ? ptr - message : > strlenW(message), handle); > + WCMD_output_asis_len(message, (ptr) ? (DWORD)(ptr - message) : > strlenW(message), handle); > if (ptr) { > numChars = 0; > if (++line_count >= max_height - 1) { > -- > 1.7.7.1 > > > > -- -- Eric Pouech

3 4

Re: [PATCH 1/2] include: Add a few defines to winscard.h (try 2)
by Alexandre Julliard 28 Oct '11

28 Oct '11

Bruno Jesus <00cpxxx(a)gmail.com> writes: > +/* Max ATR size defined by ISO-7816 */ > +#define MAX_ATR_SIZE 33 I don't see that one in my PSDK, where does it come from? -- Alexandre Julliard julliard(a)winehq.org

3 3

kernel32: Update English resource
by Ken Sharp 28 Oct '11

28 Oct '11

I suspect this is the wrong way to update the US English resource for an .mc file. Could anyone comment? Thanks

1 0

basic_ifstream implementation
by Josh Juran 28 Oct '11

28 Oct '11

I'm ready to begin work on a basic_ifstream implementation for Wine, which is needed for the game Vampire Secrets among others. http://bugs.winehq.org/show_bug.cgi?id=28612 First I'd like to check that Piotr isn't already working on this. If not, I'm open to any advice on how to proceed. My plan is to create fstream.c, and use string.c as a guide. Josh

4 5

Antw.: signal_arc.c failing to cross-compile
by André Hentschel 28 Oct '11

28 Oct '11

Thats not a problem of cross compiling to ARM, but of android. Android is not Linux, not fully. Maybe i can find a solution, but only maybe. BTW all the problems you will find are Android specific. Gesendet mit meinem HTC ----- Reply message ----- Von: "Roger Cruz" <roger_r_cruz(a)yahoo.com> An: "wine-devel(a)winehq.org" <wine-devel(a)winehq.org> Betreff: signal_arc.c failing to cross-compile Datum: Fr., Okt. 28, 2011 06:46 Hi Andre et al, Wondering if any of you know how to get around this? The compiler is barfing at the lack of ucontext_t when doing a typedef of SIGCONTEXT. Thanks in advance, Roger R. Cruz arm-linux-androideabi-gcc -c -I/home/rcruz/sandbox/wine-dev-branch/dlls/ntdll -I. -I/home/rcruz/sandbox/wine-dev-branch/include -I../../include -D__WINESRC__ -D_NTSYSTEM_ -D_REENTRANT -fPIC -Wall -pipe -fno-strength-reduce -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -g -O2 -o signal_arm.o /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:69: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SIGCONTEXT' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:127: warning: type defaults to 'int' in declaration of 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:127: error: expected ';', ',' or ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:149: error: expected declaration specifiers or '...' before 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'restore_context': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: 'sigcontext' undeclared (first use in this function) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: (Each undeclared identifier is reported only once /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: for each function it appears in.) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: At top level: /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:170: warning: type defaults to 'int' in declaration of 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:170: error: expected ';', ',' or ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:181: warning: type defaults to 'int' in declaration of 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:181: error: expected ';', ',' or ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:364: error: expected ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'segv_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:544: error: 'SIGCONTEXT' undeclared (first use in this function) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:544: error: 'context' undeclared (first use in this function) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:545: warning: ISO C90 forbids mixed declarations and code /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:556: warning: implicit declaration of function 'setup_exception_record' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'trap_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:608: warning: implicit declaration of function 'save_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:615: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'fpe_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:629: warning: implicit declaration of function 'save_fpu' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:683: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:684: warning: implicit declaration of function 'restore_fpu' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'int_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:708: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'abrt_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:732: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'usr1_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:758: error: too many arguments to function 'restore_context' make[1]: *** [signal_arm.o] Error 1

2 1

Re: ntdll: Make the VirtualProtect tests pass under Wine. Resend.
by Alexandre Julliard 28 Oct '11

28 Oct '11

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Updated to current git. > --- > dlls/kernel32/tests/virtual.c | 16 ---------------- > dlls/ntdll/virtual.c | 3 +++ > 2 files changed, 3 insertions(+), 16 deletions(-) This completely breaks Wine here. There are several places where we use WRITECOPY for protections, they would have to be fixed first. -- Alexandre Julliard julliard(a)winehq.org

1 0

signal_arc.c failing to cross-compile
by Roger Cruz 28 Oct '11

28 Oct '11

Hi Andre et al, Wondering if any of you know how to get around this? The compiler is barfing at the lack of ucontext_t when doing a typedef of SIGCONTEXT. Thanks in advance, Roger R. Cruz arm-linux-androideabi-gcc -c -I/home/rcruz/sandbox/wine-dev-branch/dlls/ntdll -I. -I/home/rcruz/sandbox/wine-dev-branch/include -I../../include -D__WINESRC__ -D_NTSYSTEM_ -D_REENTRANT -fPIC -Wall -pipe -fno-strength-reduce -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -g -O2 -o signal_arm.o /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:69: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SIGCONTEXT' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:127: warning: type defaults to 'int' in declaration of 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:127: error: expected ';', ',' or ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:149: error: expected declaration specifiers or '...' before 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'restore_context': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: 'sigcontext' undeclared (first use in this function) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: (Each undeclared identifier is reported only once /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:153: error: for each function it appears in.) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: At top level: /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:170: warning: type defaults to 'int' in declaration of 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:170: error: expected ';', ',' or ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:181: warning: type defaults to 'int' in declaration of 'ucontext_t' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:181: error: expected ';', ',' or ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:364: error: expected ')' before '*' token /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'segv_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:544: error: 'SIGCONTEXT' undeclared (first use in this function) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:544: error: 'context' undeclared (first use in this function) /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:545: warning: ISO C90 forbids mixed declarations and code /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:556: warning: implicit declaration of function 'setup_exception_record' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'trap_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:608: warning: implicit declaration of function 'save_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:615: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'fpe_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:629: warning: implicit declaration of function 'save_fpu' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:683: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:684: warning: implicit declaration of function 'restore_fpu' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'int_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:708: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'abrt_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:732: error: too many arguments to function 'restore_context' /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c: In function 'usr1_handler': /home/rcruz/sandbox/wine-dev-branch/dlls/ntdll/signal_arm.c:758: error: too many arguments to function 'restore_context' make[1]: *** [signal_arm.o] Error 1

2 1

Re: winscard/tests: Add the tests file
by Marvin 26 Oct '11

26 Oct '11

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=15123 Your paranoid android. === W2KPROSP4 (32 bit winscard) === winscard.c:53: Test failed: SCardIsValidContext expected SCARD_E_INVALID_HANDLE, received 00000006 winscard.c:64: Test failed: SCardReleaseContext expected SCARD_E_INVALID_HANDLE, received 00000006

2 1

re: [PATCH 1/3] widl: teach widl how to automatically create class factories (resend)
by Dan Kegel 26 Oct '11

26 Oct '11

Hi Bernhard, build fails here: widl.o: In function `write_dlldata': /home/bob/wineslave.dir/sandbox/slave/runtests-default/build/tools/widl/widl.c:423: undefined reference to `write_dlldata_list' widl.o: In function `main': /home/bob/wineslave.dir/sandbox/slave/runtests-default/build/tools/widl/widl.c:781: undefined reference to `write_dlldata_list' http://winehq.org:8010/builders/runtests-default/builds/106 Also, patch 2/3 doesn't apply: error: patch failed: Make.rules.in:20 error: Make.rules.in: patch does not apply http://winehq.org:8010/builders/runtests-default/builds/107

2 2

Re: [PATCH 2/2] d3dx9/test: Fix typo.
by Marvin 26 Oct '11

26 Oct '11

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=15120 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: include: Remove 'l' modifier from numeric constants in d3d9caps.h
by Jacek Caban 26 Oct '11

26 Oct '11

Hi Michael, On 10/26/11 00:30, Michael Stefaniuc wrote: > --- > include/d3d9caps.h | 182 ++++++++++++++++++++++++++-------------------------- > 1 files changed, 91 insertions(+), 91 deletions(-) > > diff --git a/include/d3d9caps.h b/include/d3d9caps.h > index 8ed6598..64dba21 100644 > --- a/include/d3d9caps.h > +++ b/include/d3d9caps.h > @@ -29,13 +29,13 @@ > #define D3DCURSORCAPS_LOWRES 2 > > > -#define D3DDEVCAPS2_STREAMOFFSET 0x00000001L > -#define D3DDEVCAPS2_DMAPNPATCH 0x00000002L > -#define D3DDEVCAPS2_ADAPTIVETESSRTPATCH 0x00000004L > -#define D3DDEVCAPS2_ADAPTIVETESSNPATCH 0x00000008L > -#define D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES 0x00000010L > -#define D3DDEVCAPS2_PRESAMPLEDDMAPNPATCH 0x00000020L > -#define D3DDEVCAPS2_VERTEXELEMENTSCANSHARESTREAMOFFSET 0x00000040L > +#define D3DDEVCAPS2_STREAMOFFSET 0x00000001 > +#define D3DDEVCAPS2_DMAPNPATCH 0x00000002 > +#define D3DDEVCAPS2_ADAPTIVETESSRTPATCH 0x00000004 > +#define D3DDEVCAPS2_ADAPTIVETESSNPATCH 0x00000008 > +#define D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES 0x00000010 > +#define D3DDEVCAPS2_PRESAMPLEDDMAPNPATCH 0x00000020 > +#define D3DDEVCAPS2_VERTEXELEMENTSCANSHARESTREAMOFFSET 0x00000040 > mingw-w64 project imports some of our headers, including most of d3d headers. They would probably prefer to keep them with 'l' modifier since that's the right thing to do. Given that it's mostly harmless for Wine, could we please consider not changing it? Thanks, Jacek

5 7

Re: [PATCH 1/2] d3dx9: Improve argument check in D3DXFindShaderComment().
by Marvin 26 Oct '11

26 Oct '11

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=15119 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

winealsa: 6 Channel Audio
by Joerg-Cyril.Hoehle＠t-systems.com 26 Oct '11

26 Oct '11

Hi, Andrew Eikum wrote: > > A configuration option (in winecfg/control panel) [...] > My reaction to this is "urrrrrrrghhhhhhh". >Tucking stuff away in the registry makes it a pain to screw >up their config, which means they'll probably turn to submitting bug >reports with the default config first, which is exactly what I want. Interesting wish. Somehow understandable, however ... Currently I see the winecfg as the only viable solution to the issue that we (at least I) don't know how to get the best default parameters. E.g. dmix prefers 48000Hz but this is settable somewhere in /etc/alsa or /usr/share/alsa PA seems to use 44100 on my system (and I'm wondering whether PA may end up using dmix as back-end, involving some resampling from 44100 to 48000?!?) All of them will happily accept any rate and resample. I don't know how to get hw:0's preferred rate short of disabling resampling, which will cause compatibility trouble (perhaps open hw:0 twice, once without resampling to investigate the bare bones, then with resampling which is what Wine needs for its operations). >GetMixFormat(). For example, >it should really be a per-device (and therefore per-backend) setting. Huh? it's already dependent on This->pcm_handle, hence the backend. IMHO we need enumeration tests to verify that GetMixFormat exists for every mmdevapi device. Conceptually IMHO, GetMix is all about a mixer. I don't believe MS provides N mixers, rather than one for each of "Default Voice output channel" and "Multimedia output" and perhaps "Comm output" -- should these be different. That's 1-3. OTOH, it's possible that it supplies on-demand mixing services for every mmdevapi backend, e.g. the poor built-in speaker, on-board audio and distinct 5:1 PCI card. Can an app open any device in shared (=mixer) mode, even when it's not one of the default devices? It's quite logical that there's a control panel in Windows Vista-7. Their users must be able to define which is their default (preferred) voice, multimedia and comm output card, and possibly how their 5/7:1 speakers are positioned. Ideally, Wine should detect whether ALSA has a distinct (and working) "surround" or "5.1" output device, use that and detect (or map) its speaker configuration. >Apparently ALSA is capable of handling up to 10,000 channels The message means nothing more than that dmix will accept upto 10000 channels and map that somehow to the underlying device. Not unlike that systematic test performed by a German guy IIRC about channel mapping on MS, where 1-6 channels were also accepted and distributed somehow to the existing speakers. Regards, Jörg Höhle

1 0

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