- wine-devel - winehq.org

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

D3DXCreatePolygon
by paulo lesgaz 26 Oct '11

26 Oct '11

Hello, any problem with my D3DXCreatePolygon patch? Thanks in advance. David

2 1

Re: Wine's configure script when cross-compiling
by Roger Cruz 26 Oct '11

26 Oct '11

Hi Dan, So far that autoconf script has been a nightmare. It doesn't include string.h (where strerror.h is defined) directly BUT I did include unistd.h in order to get autoconf to find getpagesize(). I'm building under the Android development which uses GCC for cross-compiling for ARM. I decided to continue making progress on my project by taking autoconf's output (config.h) and hand tweaking the #define HAVE_xxx functions that I know the cross-compile environment provide. I get a lot farther now but a new error arises, for which I have no clues yet on how to fix. make[1]: Entering directory `/development/rcruz/sandbox/wine-builds/winearm3/dlls/acledit' arm-linux-androideabi-gcc -c -I/home/rcruz/sandbox/wine-dev-branch/dlls/acledit -I. -I/home/rcruz/sandbox/wine-dev-branch/include -I../../include -D__WINESRC__ -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 main.o /home/rcruz/sandbox/wine-dev-branch/dlls/acledit/main.c /home/rcruz/sandbox/wine-builds/wine32-dev/tools/winegcc/winegcc -b arm-linux-androideabi -B/home/rcruz/sandbox/wine-builds/wine32-dev/tools/winebuild --sysroot=../.. -fasynchronous-unwind-tables -shared /home/rcruz/sandbox/wine-dev-branch/dlls/acledit/acledit.spec main.o -o acledit.dll.so ../../libs/port/libwine_port.a ../../dlls/winecrt0/libwinecrt0.a(dll_entry.o): In function `__wine_spec_dll_entry': /home/rcruz/sandbox/wine-dev-branch/dlls/winecrt0/dll_entry.c:42: undefined reference to `_fini' /home/rcruz/sandbox/wine-dev-branch/dlls/winecrt0/dll_entry.c:37: undefined reference to `_init' /home/rcruz/sandbox/tools/toolchain9/bin/../lib/gcc/arm-linux-androideabi/4.4.3/../../../../arm-linux-androideabi/bin/ld: acledit.dll.so: hidden symbol `_init' isn't defined /home/rcruz/sandbox/tools/toolchain9/bin/../lib/gcc/arm-linux-androideabi/4.4.3/../../../../arm-linux-androideabi/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status winegcc: arm-linux-androideabi-gcc failed make[1]: *** [acledit.dll.so] Error 2 make[1]: Leaving directory `/development/rcruz/sandbox/wine-builds/winearm3/dlls/acledit' ________________________________ From: Dan Kegel <dank(a)kegel.com> To: wine-devel(a)winehq.org Cc: roger_r_cruz(a)yahoo.com Sent: Wednesday, October 26, 2011 12:49 AM Subject: re: Wine's configure script when cross-compiling Welcome to the wonderful world of autoconf! > The code that generates conftest.c does not provide for an argument to strerror. Why doesn't it? And how does the configure script succeed when compiling for x86? If I recall correctly: Because conftest.c doesn't include the .h file that declares strerror(), and C doesn't have typesafe linkage, checking for the presence of a function by linking to it with a totally bogus call with no arguments should work fine. It's not clear why the compiler is complaining - did it somehow see a .h file that declared strerror()? What compiler are you using?

1 0

re: Wine's configure script when cross-compiling
by Dan Kegel 26 Oct '11

26 Oct '11

Welcome to the wonderful world of autoconf! > The code that generates conftest.c does not provide for an argument to strerror. Why doesn't it? And how does the configure script succeed when compiling for x86? If I recall correctly: Because conftest.c doesn't include the .h file that declares strerror(), and C doesn't have typesafe linkage, checking for the presence of a function by linking to it with a totally bogus call with no arguments should work fine. It's not clear why the compiler is complaining - did it somehow see a .h file that declared strerror()? What compiler are you using?

1 0

Wine's configure script when cross-compiling
by Roger Cruz 26 Oct '11

26 Oct '11

I'm still attempting to cross-compile Wine to ARM and I'm running into many compile errors right off the bat. I have tracked these down to the lack of HAVE_xxx in the config.h file generated from configure script. Many of the functions being checked from this list fail when they are compiled by ac_fn_c_check_func () for ac_func in \ _finite \ _isnan \ _pclose \ _popen \ ... snprintf \ spawnvp \ statfs \ statvfs \ strcasecmp \ strdup \ strerror \ One example of a failure is strerror which does not compile because it is missing one argument conftest.c:165: error: too few arguments to function 'strerror' The code that generates conftest.c does not provide for an argument to strerror. Why doesn't it? And how does the configure script succeed when compiling for x86? int main () { return $2 (); ; return 0; } Thanks in advance Roger R. Cruz

1 0

Regression testing breakthrough
by Damjan Jovanovic 25 Oct '11

25 Oct '11

Hi Since the beginning, I've had issues with regression testing. Despite the fact it's very useful, it takes forever, it's easy to make a mistake (especially during "reverse regression testing"), users find it too long and technical, and only a small minority of regressions are ever bisected. And several patches need backporting to allow older versions of Wine to compile and run on today's make, gcc, and libraries - this is the case even for the 1.0.x releases from less than 3 years ago! The problem is of course compilation. "configure" takes at least 40 seconds, without any way to speed it up on multi-core CPUs. "make" takes > 5 minutes, and it's only taking longer as Wine gets bigger. Compilation is fundamentally complex and technical to users. But what if we had precompiled binaries, and regression testing consisted of just running different versions of Wine? Wine binaries take up about 122 MB and take over 5 minutes to compile. There's now 35770 commits between 36def4af0ca85a1d0e66b5207056775bcb3b09ff (Release 1.0) and "origin". That's about 4.4 terrabytes of storage and over 4 months of compilation, if each of those versions had to be compiled and installed into its own prefix, way beyond what most users are willing or able to store or do. Most patches however end up affecting only a few binary files in the end, and compiling successive versions allows "make" to be very quick. So I've written a tool that compiles Wine and adds each commit's binaries into a Git repository. It knows how to compile old versions of Wine (currently as far back as 1.0). It knows that commits affecting only ANNOUNCE, .gitignore, and files in dll/ or programs/ ending with .c and such don't need to go through the endlessly slow "configure", only "make". It is stateless: if interrupted, it can resume from the last successful commit. It works around bugs in GNU make (you won't believe how many there are...). This tool compiled all 35000 or so commits from Wine 1.0 to around 4th October 2011 in only 7 days, generating a Git repository of Wine binaries that's only 26 gigabytes in size. Regression testing with binaries is a pleasure: it takes only a few seconds :-) on each bisection. I bisected a 16 step regression in just 20 minutes, and most of that time was spent running the application and dealing with 2 X-server crashes. I haven't figured out how to make the binaries available to users. Few users can clone a 26 gigabyte repository, and even fewer places can serve that much to multiple users. Maybe Git can compress it further? The other idea I had is that users should be able to regression test through a GUI tool. Maybe the GUI tool can just download and run the +/- 122 MB binary snapshots for specific commits, instead of having the entire binary repository locally? Any other ideas? Would you like to see this tool? Can I send an attachment with it? Thank you Damjan Jovanovic

12 22

Re: [PATCH] kernel32: Output message to stderr in UTF-8
by Alex Henrie 25 Oct '11

25 Oct '11

Hello, Last week I submitted a patch to make kernel32 output an error message in UTF-8 rather than the current codepage. This fixed a bug in which the command "wine /." would produce a garbled error message in languages other than English. However, thinking about this some more, I'm not sure that my patch fixes the bug correctly. I made WideCharToMultiByte use CP_UTF8 instead of CP_ACP, but reading more about the codepage setting, I think I should have used either CP_UNIXCP or CP_OEMCP. Could anyone help clarify which should be used? -Alex

2 1

Re: [PATCH 2/5] d3d8/tests: Add a small test for multisampled CopyRects().
by Francois Gouget 25 Oct '11

25 Oct '11

commit fd1afd24f4af20646ce0f3a7ac2064e8e49b1e7d Author: Henri Verbeet <hverbeet(a)codeweavers.com> Date: Wed Oct 19 22:03:11 2011 +0200 d3d8/tests: Add a small test for multisampled CopyRects(). This commit causes the d3d8:visual to crash on my desktop (Debian Testing, 9600GT, 285.05.09-1 proprietary driver): wine: Unhandled stack overflow at address 0x7e3ab8bf (thread 0009), starting debugger... err:seh:setup_exception_record stack overflow 1100 bytes in thread 0009 eip 7ef8952b esp 00240ee4 stack 0x240000-0x241000-0x340000 The call that causes the crash is: hr = IDirect3DDevice8_CopyRects(device, rt, NULL, 0, readback, NULL); The stack trace seems to point towards an out of hand recursion problem that eventually causes a stack overrun: Backtrace: =>0 0x7e3a7a32 d3dfmt_get_conv+0x12(surface=0x161728, need_alpha_ck=0x1, use_texturing=0x1, format=0x242074, convert=0x24210c) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:4372] in wined3d (0x00242018) 1 0x7e3b05ee surface_load_texture+0xcd(surface=0x161728, gl_info=0x12b078, rect=(nil), srgb=0) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5953] in wined3d (0x00242128) 2 0x7e3abc50 surface_load_location+0x39f(surface=0x161728, location=0x40000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:6136] in wined3d (0x00242258) 3 0x7e3ac1c0 surface_load_location+0x90f(surface=0x161728, location=0x20000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5771] in wined3d (0x00242388) 4 0x7e3b063b surface_load_texture+0x11a(surface=0x161728, gl_info=0x12b078, rect=(nil), srgb=0) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5979] in wined3d (0x00242498) 5 0x7e3abc50 surface_load_location+0x39f(surface=0x161728, location=0x40000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:6136] in wined3d (0x002425c8) 6 0x7e3ac1c0 surface_load_location+0x90f(surface=0x161728, location=0x20000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5771] in wined3d (0x002426f8) 7 0x7e3b063b surface_load_texture+0x11a(surface=0x161728, gl_info=0x12b078, rect=(nil), srgb=0) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5979] in wined3d (0x00242808) 8 0x7e3abc50 surface_load_location+0x39f(surface=0x161728, location=0x40000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:6136] in wined3d (0x00242938) 9 0x7e3ac1c0 surface_load_location+0x90f(surface=0x161728, location=0x20000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5771] in wined3d (0x00242a68) 10 0x7e3b063b surface_load_texture+0x11a(surface=0x161728, gl_info=0x12b078, rect=(nil), srgb=0) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5979] in wined3d (0x00242b78) 11 0x7e3abc50 surface_load_location+0x39f(surface=0x161728, location=0x40000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:6136] in wined3d (0x00242ca8) 12 0x7e3ac1c0 surface_load_location+0x90f(surface=0x161728, location=0x20000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5771] in wined3d (0x00242dd8) 13 0x7e3b063b surface_load_texture+0x11a(surface=0x161728, gl_info=0x12b078, rect=(nil), srgb=0) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5979] in wined3d (0x00242ee8) 14 0x7e3abc50 surface_load_location+0x39f(surface=0x161728, location=0x40000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:6136] in wined3d (0x00243018) 15 0x7e3ac1c0 surface_load_location+0x90f(surface=0x161728, location=0x20000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5771] in wined3d (0x00243148) 16 0x7e3b063b surface_load_texture+0x11a(surface=0x161728, gl_info=0x12b078, rect=(nil), srgb=0) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5979] in wined3d (0x00243258) 17 0x7e3abc50 surface_load_location+0x39f(surface=0x161728, location=0x40000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:6136] in wined3d (0x00243388) 18 0x7e3ac1c0 surface_load_location+0x90f(surface=0x161728, location=0x20000, rect=(nil)) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5771] in wined3d (0x002434b8) 19 0x7e3b063b surface_load_texture+0x11a(surface=0x161728, gl_info=0x12b078, rect=(nil), srgb=0) [/home/fgouget/wine/wine/dlls/wined3d/surface.c:5979] in wined3d (0x002435c8) [...] -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Advice is what we ask for when we already know the answer but wish we didn't -- Eric Jong

1 0

D3DXCreatePolygon
by David Adam 25 Oct '11

25 Oct '11

Any problem with my D3DXCreatePolygon patch? Thanks in advance. David

1 0

Re: riched20: do not return incorrect values from ME_CharFromPoint[Cursor]
by Alexandre Julliard 24 Oct '11

24 Oct '11

Thomas Faber <thfabba(a)gmx.de> writes: > Windows's version of GetTextExtentExPointW, which is called in that function, > returns a value of 1 in this case (Wine's does not, which would appear to be > a bug), leading to the "i<len" assertion failure if there is no text in the > control. > The patch fixes riched20 to correctly handle either behavior by > adding a fast path for cx <= 0 (the function obviously needs to return 0 in > the cx == 0 case too, so it can skip the calculation). You should not be adding workarounds for Wine bugs, the bugs need to be fixed instead. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: riched20: explicitly cast WPARAM to character types
by Michael Stefaniuc 24 Oct '11

24 Oct '11

On 10/22/2011 10:38 PM, Thomas Faber wrote: > This makes the use of casts more consistent and shows the conversion > from WPARAM to CHAR/WCHAR is intentional for WM_CHAR/EM_SETPASSWORDCHAR. > Also fixes two MSVC warnings. To make it consistent remove the WCHAR cast 3 lines above. Casts are *not* there to show a conversion is intentional. They tell the compiler to STFU and to the human reader they mean "*WARNING* doing something odd here". So don't cry wolf when there's no wolf in sight. No clue anyway why MSVC even warns, integer to integer conversions are allowed. If you still want to get rid of those warnings the fix would be to change the type of charCode to WCHAR. To correctly unmarshal the WCHAR out of the WPARAM when passing it to ME_Char() use LOWORD(). bye michael

3 2

Re: [PATCH 4/5] wined3d: Refuse to create a D3D10 wined3d device if it is not supported by the GPU.
by Henri Verbeet 24 Oct '11

24 Oct '11

On 24 October 2011 18:58, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + if (wined3d->dxVersion >= 10 && (shader_caps.VertexShaderVersion < WINED3DVS_VERSION(4,0) > + || shader_caps.PixelShaderVersion < WINED3DPS_VERSION(4,0))) This should probably be handled in dxgi_device_init().

1 0

Re: [PATCH 2/5] d3d9: Limit VS/PS reported version.
by Henri Verbeet 24 Oct '11

24 Oct '11

On 24 October 2011 18:58, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + if (pCaps->VertexShaderVersion > D3DVS_VERSION(3,0)) > + pCaps->VertexShaderVersion = D3DVS_VERSION(3,0); > + if (pCaps->PixelShaderVersion > D3DPS_VERSION(3,0)) > + pCaps->PixelShaderVersion = D3DPS_VERSION(3,0); > + This should probably go into filter_caps().

1 0

Re: [PATCH 1/5] d3d8: Limit VS/PS reported version.
by Henri Verbeet 24 Oct '11

24 Oct '11

On 24 October 2011 18:58, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + if (pCaps->VertexShaderVersion > D3DVS_VERSION(1,1)) > + pCaps->VertexShaderVersion = D3DVS_VERSION(1,1); > + if (pCaps->PixelShaderVersion > D3DPS_VERSION(1,4)) > + pCaps->PixelShaderVersion = D3DPS_VERSION(1,4); > + fixup_caps() should already do this.

1 0

Re: [PATCH 5/7] msxml3: Make positions returned by ISAXLocator compatible with msxml6
by Nikolay Sivov 24 Oct '11

24 Oct '11

On 10/24/2011 14:55, Piotr Caban wrote: > --- > dlls/msxml3/factory.c | 8 ++++- > dlls/msxml3/msxml_private.h | 1 + > dlls/msxml3/saxreader.c | 62 > +++++++++++++++++++++++++++++++++++++++--- > 3 files changed, 64 insertions(+), 7 deletions(-) > > > > static ClassFactory saxreadcf = { {&ClassFactoryVtbl }, SAXXMLReader_create }; > +static ClassFactory saxread6cf = { {&ClassFactoryVtbl }, SAXXMLReader6_create }; > static ClassFactory httpreqcf = { {&ClassFactoryVtbl }, XMLHTTPRequest_create }; Such version dependent behaviour is handled currently with additional argument of MSXML_VERSION enum type. It's better to do it the same way in SAX too, to be consistent.

1 0

Re: [1/2] d3dx9: Implemented non-equal declaration support in CloneMesh.
by Matteo Bruni 24 Oct '11

24 Oct '11

Hi Michael, + for (i = 0; declaration1[i].Stream != 0xff; i++) + { + if (memcmp(&declaration1[i], &declaration2[i], sizeof(*declaration1))) Doesn't that loop need to stop at the first end marker of either declaration? I.e. may the first vertex declaration be longer than the second one?

2 2

winealsa: 6 Channel Audio
by Jonathan McCrohan 24 Oct '11

24 Oct '11

Hi, Using foobar2000 (Wine 1.3.31) to output 6 channel audio via WASAPI, I get an error in foobar2000, and the following Wine errors in the terminal: fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels However, when using a patched version of Wine with hardcoded support for 6 channel audio, foobar2000 6 channel audio works correctly (patch attached). While this works, it is just a hack and doesn't fix the underlying issue; the additional 9,994 audio channels. This also merely just changes the error message from 2s channel to 6 channels: fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 6 channels Would someone with a better knowledge of Wine and/or ALSA be able to assist me in tracking down the source of this bug? Thanks, Jonathan

3 4

Patch resend etiquette
by Erich Hoover 24 Oct '11

24 Oct '11

How long should one wait to resend patches marked as "New" on the patch list? It seems that once they've gone "far enough" down on the list that there's no chance they'll be looked at. Thanks in advance for your advice. Erich Hoover ehoover(a)mines.edu

3 3

Re: vbscript: Fixed local variable count calculation
by Marvin 24 Oct '11

24 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=15088 Your paranoid android. === WNT4WSSP6 (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 === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

re: winmm: Avoid casting return value of Heap(Re)Alloc calls.
by Dan Kegel 23 Oct '11

23 Oct '11

Doesn't build here: ccache gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_WINMM_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings -fno-omit-frame-pointer -Wpointer-arith -Wlogical-op -I/usr/include/freetype2 -g -O0 -Werror -Wno-unused-but-set-variable -Wno-unused-but-set-parameter -o lolvldrv.o lolvldrv.c lolvldrv.c: In function 'MMDRV_InitPerType': lolvldrv.c:406:13: error: pointer of type 'void *' used in arithmetic [-Werror=pointer-arith] lolvldrv.c:411:13: error: pointer of type 'void *' used in arithmetic [-Werror=pointer-arith] cc1: all warnings being treated as errors make[1]: Leaving directory `/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/winmm' make[1]: *** [lolvldrv.o] Error 1 make: *** [dlls/winmm] Error 2 http://buildbot.kegel.com/builders/runtests-default/builds/874

5 8

Re: [3/6] dinput: SetActionMap saving simple configurations to an .ini file
by Vitaliy Margolen 23 Oct '11

23 Oct '11

Few nit picks. On 10/22/2011 02:53 PM, Lucas Fialho Zawacki wrote: > +static void _write_private_profile_intW(const char *format, WCHAR* section, WCHAR* key, int value, WCHAR* file) > +{ > + WCHAR* value_str = heap_printfW(format, value); Here and everywhere else you not checking if memory allocation succeeded. > + WCHAR path[] = { > + '%','C','o','m','m','o','n','P','r','o','g','r','a','m','F','i','l','e','s','%','\\', > + 'D','i','r','e','c','t','X','\\', > + 'D','i','r','e','c','t','I','n','p','u','t','\\', > + 'U','s','e','r',' ','M','a','p','s','\0'}; Missing static const qualifiers. Also the above directory does not exists and you not explicitly creating it. > + guid_strA = debugstr_guid(&lpdiaf->guidActionMap); > + guid_size = MultiByteToWideChar(CP_ACP, 0, guid_strA, -1, NULL, 0); I'm not sure debug function is ok to be used in the regular code. Also, if need it as unicode why not print it as unicode from the beginning? > + IDirectInputDevice_GetDeviceInfo(&This->IDirectInputDevice8W_iface, &didevi); You should use IDirectInputDevice8W_from_impl() function instead of directly accessing internals. > + memcpy(username, find_data.cFileName, (end - find_data.cFileName + 1) * sizeof(WCHAR)); No checking for big enough buffer. Assuming that file names are in specified format. Also I'm not exactly sure why do you need a mapping user name anyway? Wine does not support multiple users. The user currently running Wine would be the one created all the files. All this seems to be redundant. Vitaliy.

1 0

Compilation error when cross-compiling Wine to ARM.
by Roger Cruz 23 Oct '11

23 Oct '11

I'm attempting to cross-compile Wine for ARM and during the compilation of the first file, I get the following error about some strings.h routines not being portable. I have tracked this down to the redefinitions for these routines in include/port.h. How do I get around this issue? Is there a certain #define that needs to be enabled to allow me to use the native strings.h without redefinition (namely this #define NO_LIBWINE_PORT). What is the purpose of having these redefined? Any insight would be most welcome. gcc -c -I/home/rcruz/sandbox/dev-branch/tools -I. -I/home/rcruz/sandbox/dev-branch/include -I../include -D__WINESRC__ -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 makedep.o /home/rcruz/sandbox/dev-branch/tools/makedep.c In file included from /home/rcruz/sandbox/tools/toolchain9/bin/../sysroot/usr/include/stdlib.h:42, from /home/rcruz/sandbox/dev-branch/tools/makedep.c:29: /home/rcruz/sandbox/tools/toolchain9/bin/../sysroot/usr/include/strings.h:49: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ffs_is_not_portable' /home/rcruz/sandbox/tools/toolchain9/bin/../sysroot/usr/include/strings.h:52: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'strcasecmp_is_not_portable' /home/rcruz/sandbox/tools/toolchain9/bin/../sysroot/usr/include/strings.h:53: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'strncasecmp_is_not_portable' Regards, Roger R. Cruz

3 3

Re: riched20: do not return incorrect values from ME_CharFromPoint[Cursor]
by Thomas Faber 23 Oct '11

23 Oct '11

Hi, On 2011-10-22 22:45, Thomas Faber wrote: > Windows's version of GetTextExtentExPointW, which is called in that function, > returns a value of 1 in this case (Wine's does not, which would appear to be > a bug), leading to the "i<len" assertion failure if there is no text in the > control. this description isn't 100% complete (the fix is correct nonetheless). With the help of the corresponding gdi32 tests [1], I can describe it better: The nAvailWidth in a zero-width richedit control will be -2 (as borders are subtracted by the format rect, resulting in an invalid rect, as previously demonstrated), which will be passed as max_extent to GetTextExtentExPointW. Wine's version would return 0 as expected, while Windows's would interpret this as a large unsigned number and return the length of the text (1 in my test case, mIRC). This eventually led to the i<len assertion failing, as i was set to len exactly. I hope this clears up any doubts. Wine's riched20 now works nicely as a replacement for its counterpart. :) Best regards and have a nice Sunday. Tom [1] http://www.winehq.org/pipermail/wine-patches/2011-October/108186.html

1 0

Re: 80245: riched20/tests: test format rect adaption to window size and behavior with zero-sized windows
by Dan Kegel 22 Oct '11

22 Oct '11

Fails to build here... On Oct 22, 2011 1:48 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/898 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) BUILD FAILED: failed shell_2 Errors: editor.c: In function 'test_format_rect': editor.c:6369:5: error: passing argument 4 of 'SendMessageA' makes integer from pointer without a cast [-Werror] make[1]: *** [editor.o] Error 1 make: *** [dlls/riched20/tests] Error 2 make: *** Waiting for unfinished jobs.... _______________________________________________ wine-tests-results mailing list wine-tests-results(a)winehq.org http://www.winehq.org/mailman/listinfo/wine-tests-results

2 1

Re: msctf: increase buffer to have room for full key
by Austin English 22 Oct '11

22 Oct '11

On Fri, Oct 21, 2011 at 20:26, Aric Stewart <aric(a)codeweavers.com> wrote: > > found by Dan Kegel with Valgrind. > Fixes bug 25826 And Clang :). -- -Austin

1 0

Re: [PATCH 1/5] wined3d: Move the cursor in wined3d_device_set_cursor_position().
by Stefan Dösinger 21 Oct '11

21 Oct '11

Hi, Does this address Alexandre's need for a software cursor, or is this unrelated? In the tests I recommend to test a bigger cursor in addition to the 32x32 cursor to see what happens in situations where Windows falls back to a software cursor. Stefan On Thursday 20 October 2011 12:42:55 Henri Verbeet wrote: > --- > dlls/wined3d/device.c | 8 +++++++- > 1 files changed, 7 insertions(+), 1 deletions(-) > > diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c > index 67e50b5..6f43715 100644 > --- a/dlls/wined3d/device.c > +++ b/dlls/wined3d/device.c > @@ -5251,10 +5251,16 @@ void CDECL > wined3d_device_set_cursor_position(struct wined3d_device *device, > device->xScreenSpace = x_screen_space; > device->yScreenSpace = y_screen_space; > > - /* switch to the software cursor if position diverges from the > hardware one */ if (device->hardwareCursor) > { > POINT pt; > + > + GetCursorPos( &pt ); > + if (x_screen_space == pt.x && y_screen_space == pt.y) > + return; > + SetCursorPos( x_screen_space, y_screen_space ); > + > + /* Switch to the software cursor if position diverges from the > hardware one. */ GetCursorPos( &pt ); > if (x_screen_space != pt.x || y_screen_space != pt.y) > {

2 1

Re: [PATCH 2/2] vbscript: Added remaining week day constants implementations
by Marvin 21 Oct '11

21 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=15047 Your paranoid android. === WNT4WSSP6 (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 === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Re: [PATCH 1/2] vbscript: Added vbSunday constant implementation
by Marvin 21 Oct '11

21 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=15046 Your paranoid android. === WNT4WSSP6 (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 === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Re: dpnet/tests: Avoid casting return value of HeapAlloc calls
by Marvin 21 Oct '11

21 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=15042 Your paranoid android. === WNT4WSSP6 (32 bit peer) === peer.c:52: Test failed: CoCreateInstance failed with 0x80040154 peer: unhandled exception c0000005 at 004013BF === W2KPROSP4 (32 bit peer) === peer.c:52: Test failed: CoCreateInstance failed with 0x80040154 peer: unhandled exception c0000005 at 004013BF

3 2

Re: 80186: [PATCH 2/2] dinput: Restore checks for DirectX 3 buffer size.
by Dan Kegel 21 Oct '11

21 Oct '11

Hi Vitaliy, could you check on win64? I had a test failure there with your patch. - Dan On Thu, Oct 20, 2011 at 7:49 AM, <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-x86_64 while building Wine. > Full details are available at: http://buildbot.kegel.com/builders/runtests-default-x86_64/builds/769 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) > BUILD FAILED: failed shell_3 > > Errors: > alarum: failed command was ../../../wine dinput_test.exe.so device.c > device.c:117: Test failed: GetDeviceData() should have failed: 80040207 > device.c:120: Test failed: GetDeviceData() should have failed: 80040207 > device.c:117: Test failed: GetDeviceData() should have failed: 80040207 > device.c:120: Test failed: GetDeviceData() should have failed: 80040207 > device.c:117: Test failed: GetDeviceData() should have failed: 80040207 > device.c:120: Test failed: GetDeviceData() should have failed: 80040207 > device.c:117: Test failed: GetDeviceData() should have failed: 80040207 > device.c:120: Test failed: GetDeviceData() should have failed: 80040207 > make: *** [device.ok] Error 8 > >

3 5

Anyone wants to ban spammer on forum
by Vitaliy Margolen 20 Oct '11

20 Oct '11

So any admins actually watching and want to bad roberbdib3a on forum? Also why aren't every moderator has these rights to block spammers, since we have only one forum. - Vitaliy

10 19

Re: 80200: wininet: add a stub for ShowClientAuthCerts
by Dan Kegel 20 Oct '11

20 Oct '11

Fails to build here? On Thu, Oct 20, 2011 at 3:52 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/804 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) > BUILD FAILED: failed shell_2 > > Errors: > internet.c: In function 'ShowClientAuthCerts': > internet.c:4391:159: error: format '%p' expects a matching 'void *' argument [-Werror=format] > make[1]: *** [internet.o] Error 1 > make: *** [dlls/wininet] Error 2 > make: *** Waiting for unfinished jobs.... > >

1 0

Re: attrib: Use FormatMessageW() for better internationalization support.
by Alexandre Julliard 20 Oct '11

20 Oct '11

Francois Gouget <fgouget(a)free.fr> writes: > @@ -72,10 +72,12 @@ static int ATTRIB_wprintf(const WCHAR *format, ...) { > } > > va_start(parms, format); > - len = vsnprintfW(output_bufW, MAX_WRITECONSOLE_SIZE/sizeof(WCHAR), format, parms); > + SetLastError(NO_ERROR); > + len = FormatMessageW(FORMAT_MESSAGE_FROM_STRING, format, 0, 0, output_bufW, > + MAX_WRITECONSOLE_SIZE/sizeof(*output_bufW), &parms); You have to use __ms_va_list with FormatMessage for it to work properly on 64-bit. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: vbscript: Added Global_isNull implementation
by Marvin 20 Oct '11

20 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=15023 Your paranoid android. === WNT4WSSP6 (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 === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Re: Regression testing breakthrough
by Hin-Tak Leung 20 Oct '11

20 Oct '11

I have two suggestions - - git clone has a "--depth" option which does a shallow clone (i.e. with some history removed). - you can use "git-archive" to export arbitrary commits out as a tar ball dynamically; there is no need to have store a tar ball permanently. That said, I am doubtful about the usefulness of this in a linux environment, because the system libraries (in the general sense - libjpeg, etc) varies between different linux distros. --- On Wed, 19/10/11, Joel Holdsworth <joel(a)airwebreathe.org.uk> wrote: Alternatively, have you considered doing a .tar.gz of every build snapshot, and placing that on a server somewhere? e.g. a folder full of 36def4af0ca85a1d0e66b5207056775bcb3b09ff.tar.gz files? Then one could write a simple wine regression bisect tool that implements similar semantics to git bisect, but would essentially wrap wget. Then in your server you could have an index file which is a list of the sha commit ids. This would save the user having to clone a 26Gb repository when most of the commits will be irrelevant. Extra bonus points for doing a better job of compressing the small deltas between binaries*, rather than compressing full wine builds. Joel * Are binaries deterministic like this? or do they tend to be completely scrambled? On 18 October 2011 at 09:45 Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > Hi > > Since the beginning, I've had issues with regression testing. Despite the > fact it's very useful, it takes forever, it's easy to make a mistake > (especially during "reverse regression testing"), users find it too long and > technical, and only a small minority of regressions are ever bisected. And > several patches need backporting to allow older versions of Wine to compile > and run on today's make, gcc, and libraries - this is the case even for the > 1.0.x releases from less than 3 years ago! > > The problem is of course compilation. "configure" takes at least 40 seconds, > without any way to speed it up on multi-core CPUs. "make" takes > 5 minutes, > and it's only taking longer as Wine gets bigger. Compilation is > fundamentally complex and technical to users. > > But what if we had precompiled binaries, and regression testing consisted of > just running different versions of Wine? > > Wine binaries take up about 122 MB and take over 5 minutes to compile. > There's now 35770 commits between 36def4af0ca85a1d0e66b5207056775bcb3b09ff > (Release 1.0) and "origin". That's about 4.4 terrabytes of storage and over > 4 months of compilation, if each of those versions had to be compiled and > installed into its own prefix, way beyond what most users are willing or > able to store or do. Most patches however end up affecting only a few binary > files in the end, and compiling successive versions allows "make" to be very > quick. > > So I've written a tool that compiles Wine and adds each commit's binaries > into a Git repository. It knows how to compile old versions of Wine > (currently as far back as 1.0). It knows that commits affecting only > ANNOUNCE, .gitignore, and files in dll/ or programs/ ending with .c and such > don't need to go through the endlessly slow "configure", only "make". It is > stateless: if interrupted, it can resume from the last successful commit. It > works around bugs in GNU make (you won't believe how many there are...). > > This tool compiled all 35000 or so commits from Wine 1.0 to around 4th > October 2011 in only 7 days, generating a Git repository of Wine binaries > that's only 26 gigabytes in size. Regression testing with binaries is a > pleasure: it takes only a few seconds :-) on each bisection. I bisected a 16 > step regression in just 20 minutes, and most of that time was spent running > the application and dealing with 2 X-server crashes. > > I haven't figured out how to make the binaries available to users. Few users > can clone a 26 gigabyte repository, and even fewer places can serve that > much to multiple users. Maybe Git can compress it further? The other idea I > had is that users should be able to regression test through a GUI tool. > Maybe the GUI tool can just download and run the +/- 122 MB binary snapshots > for specific commits, instead of having the entire binary repository > locally? > > Any other ideas? Would you like to see this tool? Can I send an attachment > with it? > > Thank you > Damjan Jovanovic

1 0

Re: Bug 28791: ensure that dashes value is not 0 for PS_USERSTYLE linestyles
by Alexandre Julliard 19 Oct '11

19 Oct '11

damian dixon <damian.dixon(a)gmail.com> writes: > diff --git a/dlls/winex11.drv/pen.c b/dlls/winex11.drv/pen.c > index b677515..71b1bea 100644 > --- a/dlls/winex11.drv/pen.c > +++ b/dlls/winex11.drv/pen.c > @@ -108,7 +108,7 @@ HPEN X11DRV_SelectPen( PHYSDEV dev, HPEN hpen ) > case PS_USERSTYLE: > physDev->pen.dash_len = min(elp->elpNumEntries, MAX_DASHLEN); > for(i = 0; i < physDev->pen.dash_len ; i++) > - physDev->pen.dashes[i] = min(elp->elpStyleEntry[i], 255); > + physDev->pen.dashes[i] = min(elp->elpStyleEntry[i], 255) ? min(elp->elpStyleEntry[i], 255) : 1; Removing 0 entries (and merging the adjacent entries) would probably be more correct. It could also use some test cases. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH 2/2] vbscript: Added Global_IsEmpty implementation
by Marvin 19 Oct '11

19 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=15011 Your paranoid android. === WNT4WSSP6 (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 === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Fix Bug 23124 with an "ln -s"
by Ken Sharp 19 Oct '11

19 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=23124 Could someone tell me if the attached patch would actually work? It does compile and works correctly with LANG=en_PH.utf-8 but I'm don't know that: 1. Using an "ln -s" is acceptable, nor if it will work given some file systems may be unable to use soft links. 2. I have correctly edited configure, configure.ac and LINGUAS, or even if I need to edit both. Thanks all, Ken

2 1

Re: vbscript: Added Global_IsEmpty implementation
by Marvin 19 Oct '11

19 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=15010 Your paranoid android. === WNT4WSSP6 (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 === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Re: vbscript: Added Global_IsEmpty implementation
by Marvin 19 Oct '11

19 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=15010 Your paranoid android. === WNT4WSSP6 (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 === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Re: 80141: vbscript: Added Global_IsEmpty implementation
by Dan Kegel 19 Oct '11

19 Oct '11

Hi Jacek, build failed here... did you forget #include <assert.h> ? On Wed, Oct 19, 2011 at 9:56 AM, <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/715 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) > BUILD FAILED: failed shell_2 > > Errors: > global.c: In function 'Global_IsEmpty': > global.c:281:5: error: implicit declaration of function 'assert' [-Werror=implicit-function-declaration] > make[1]: *** [global.o] Error 1 > make: *** [dlls/vbscript] Error 2 > make: *** Waiting for unfinished jobs.... > >

2 1

Re: 80135: [PATCH 05/10] gdi32: Implement SetPixel.
by Dan Kegel 19 Oct '11

19 Oct '11

Patches 5-7 failed on WINEDEBUG=warn+heap here: ../../../tools/runtest -q -P wine -M gdi32.dll -T ../../.. -p gdi32_test.exe.so palette.c && touch palette.ok ... palette.c:104: Test failed: getColor=00280000 Might be flaky; patch 8 passed. patches 9 and 10 aren't done testing yet. On Wed, Oct 19, 2011 at 6:18 AM, <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-heaptest while building Wine. > Full details are available at: http://buildbot.kegel.com/builders/runtests-heaptest/builds/673 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) > BUILD FAILED: failed shell_3 > > Errors: > alarum: failed command was ../../../wine gdi32_test.exe.so palette.c > palette.c:104: Test failed: getColor=00280000 > make: *** [palette.ok] Error 1 > * Call to xpconnect wrapped JSObject produced this error: * > * Call to xpconnect wrapped JSObject produced this error: * > GnuTLS error: A TLS packet with unexpected length was received. > >

2 3

Re: [PATCH 1/2] gdi32: Add a string table resource for the translation.
by Alexandre Julliard 19 Oct '11

19 Oct '11

Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > @@ -1,7 +1,7 @@ > EXTRADEFS = -D_GDI32_ > MODULE = gdi32.dll > IMPORTLIB = gdi32 > -IMPORTS = advapi32 > +IMPORTS = advapi32 user32 You don't want to import user32 from gdi32. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [3/7] d3d9/tests: Add a test for locking partial blocks (try 2)
by Henri Verbeet 19 Oct '11

19 Oct '11

On 18 October 2011 12:43, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Changes: Check for dynamic texture support, moved the format-specific tests to > this patch. > That's not really what I meant with "make this part of the test in patch 3/7". The point is that test_lockrect_offset() is about the offset calculation, not so much about what valid rectangles for block based formats are. And it probably wouldn't hurt to run test_partial_block_lock() on the other formats like e.g. ATI2N anyway.

2 5

Re: [PATCH] kernel32: Output message to stderr in UTF-8
by Dmitry Timoshkov 19 Oct '11

19 Oct '11

Alex Henrie <alexhenrie24(a)gmail.com> wrote: > - WideCharToMultiByte( CP_ACP, 0, msgW, -1, msg, sizeof(msg), NULL, NULL ); > + WideCharToMultiByte( CP_UTF8, 0, msgW, -1, msg, sizeof(msg), NULL, NULL ); > MESSAGE( "wine: %s", msg ); Try CP_UNIXCP intead. -- Dmitry.

1 0

Re: 80121: aclocal.m4: fix compiles on systems that don't support ln -s
by Austin English 18 Oct '11

18 Oct '11

On Tue, Oct 18, 2011 at 16:34, <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/678 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) > BUILD FAILED: failed shell_2 > > Errors: > make[1]: *** [avifile.dll16.so] Error 2 > make: *** [dlls/avifile.dll16] Error 2 > make: *** Waiting for unfinished jobs.... Hm, worked here, though trying it again with plain make rather than make -jX, fails. Needs more investigation. Please don't commit. -- -Austin

1 0

Odd valgrind warning on ubuntu 11.10 related to set_wm_hints
by Dan Kegel 18 Oct '11

18 Oct '11

I've added a suppression for this already to http://code.google.com/p/winezeug/source/browse/trunk/valgrind/valgrind-sup… It looks benign, but it's annoying because the suppression it needs is so wide. I wonder if the gcc bug on ubuntu 11.10 is why there's no useful backtrace there... Syscall param writev(vector[...]) points to uninitialised byte(s) at writev (writev.c:51) by 0x40004: ??? Address 0x4598748 is 160 bytes inside a block of size 16,384 alloc'd at calloc (vg_replace_malloc.c:467) by XOpenDisplay (in /usr/lib/i386-linux-gnu/libX11.so.6.3.0) by x11drv_init_thread_data (x11drv_main.c:689) by thread_init_display (x11drv.h:580) by X11DRV_create_win_data (window.c:2030) by X11DRV_WindowPosChanging (window.c:2429) by set_window_pos (winpos.c:1951) by USER_SetWindowPos (winpos.c:2077) by SetWindowPos (winpos.c:2151) by show_window (winpos.c:1088) by ShowWindow (winpos.c:1186) by WIN_CreateWindowEx (win.c:1498) by CreateWindowExA (win.c:1550) by init (comboex.c:505) by func_comboex (comboex.c:598) by run_test (test.h:556) by main (test.h:624) Uninitialised value was created by a stack allocation at set_wm_hints (window.c:1128)

1 0

Re: registry keys of serial ports
by Uwe Bonnes 18 Oct '11

18 Oct '11

Hello, while hunting down why a drop down box didn't offer me the serial port I configured, I stumbled across Stefans proposal from Summer 09. The patch still applied cleanly, and after setting up hal and the hal development library, the progarm worked as expected. What is the status of that proposal? Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Re: po: Update English (US) translation
by Alexandre Julliard 18 Oct '11

18 Oct '11

Ken Sharp <kennybobs(a)o2.co.uk> writes: > From 68519bf26da3d912bf92febc13a34ec00cfd7cc4 Mon Sep 17 00:00:00 2001 > From: Ken Sharp <kennybobs(a)o2.co.uk> > Date: Sat, 15 Oct 2011 03:50:43 +0100 > Subject: [PATCH] po: Update English (US) translation There's no translation to update, the rc files are already en_US. If the strings need changing they have to be changed in the rc files. -- Alexandre Julliard julliard(a)winehq.org

4 10

Re: mshtml: Added IHTMLDocument2::elementFromPoint implementation
by Marvin 18 Oct '11

18 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=14979 Your paranoid android. === TEST64_W7SP1 (32 bit htmldoc) === htmldoc.c:2865: Test failed: unexpected cmd 109 of CGID_Explorer htmldoc.c:4446: Test failed: tag = L"BODY" === TEST64_W7SP1 (64 bit htmldoc) === htmldoc.c:2865: Test failed: unexpected cmd 109 of CGID_Explorer htmldoc.c:4446: Test failed: tag = L"BODY"

2 1

Re: vbscript: Added support for hex literals not ending with '&'
by Marvin 18 Oct '11

18 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=14970 Your paranoid android. === WNT4WSSP6 (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 === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

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

17 Oct '11

On 16 October 2011 23:05, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + BOOL gl_compressed; I think the "gl_" prefix is somewhat questionable since the format being compressed or not is a property of the D3D format, it doesn't depend on what GL format we use, at least in the way the flag is currently used. You can change the meaning of the flag to be specific to the GL format, but then you'd have to set it in the format_texture_info[] table. > static const struct wined3d_format_compression_info format_compression_info[] = > { > - {WINED3DFMT_DXT1, 4, 4, 8}, > - {WINED3DFMT_DXT2, 4, 4, 16}, > - {WINED3DFMT_DXT3, 4, 4, 16}, > - {WINED3DFMT_DXT4, 4, 4, 16}, > - {WINED3DFMT_DXT5, 4, 4, 16}, > - {WINED3DFMT_ATI2N, 4, 4, 16}, > + {WINED3DFMT_DXT1, 4, 4, 8, TRUE }, > + {WINED3DFMT_DXT2, 4, 4, 16, TRUE }, > + {WINED3DFMT_DXT3, 4, 4, 16, TRUE }, > + {WINED3DFMT_DXT4, 4, 4, 16, TRUE }, > + {WINED3DFMT_DXT5, 4, 4, 16, TRUE }, > + {WINED3DFMT_ATI2N, 4, 4, 16, TRUE }, > + > + {WINED3DFMT_YUY2, 2, 1, 4, FALSE }, > + {WINED3DFMT_UYVY, 2, 1, 4, FALSE }, > }; If you decouple "block-based" and "compressed", it doesn't make sense anymore to set them in the same table like this. The "compressed" property should go to either the format_texture_info[] or the format_base_flags[] table, depending on whether it's considered a basic property of the format, or specific to the GL format we use for it. > + /* Block-based formats can't be rendered to with FBOs even if GL accepts them > + * (e.g. WINED3DFMT_YV12, which is just a GL_ALPHA texture). Even fragment shaders > + * can't account for that if a block is partially drawn. There's no such restriction on the GL side, the internal format just has to be color-renderable. The reason we can't render directly to these is because there a fixup associated with the format, but that has nothing to do with either being FBO-attachable or being block-based, and applies to e.g. P8 as well. > + * > + * Furthermore some drivers crash instead of generating an error if we attempt to > + * attach s3tc textures to an FBO */ This was an issue with some versions of fglrx, but should be fixed in current versions.

2 3

Still need patch review please (wineps.drv)
by Daniel Santos 17 Oct '11

17 Oct '11

Of particular concern is making sure my dynamically allocated memory is being freed. The new data is stored in PSPEN and is allocated when SelectObject (on a wineps.drv device of course) passing a pen and is freed whenever a subsequent pen is selected or the device context is deleted. I'm just not intimately familiar enough with this part of the API to know for certain that this eliminates all room for leaks. Thanks! Daniel

1 1

Re: ntdll: avoid buffer overrun in lookup_manifest_file
by Alexandre Julliard 17 Oct '11

17 Oct '11

Dan Kegel <dank(a)kegel.com> writes: > @@ -1877,7 +1877,7 @@ static WCHAR *lookup_manifest_file( HANDLE dir, struct assembly_identity *ai ) > if (build == min_build && revision < min_revision) continue; > tmp = strchrW(tmp, '_') + 1; > tmp = strchrW(tmp, '_') + 1; > - if (!strcmpiW( tmp, wine_trailerW )) > + if (!strncmpiW( tmp, wine_trailerW, dir_info->FileNameLength/sizeof(WCHAR) - (tmp - dir_info->FileName) )) That doesn't do the same thing. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: vbscript: Added lexer support for '_'
by Bruno Jesus 17 Oct '11

17 Oct '11

On Fri, Oct 14, 2011 at 13:44, Jacek Caban <jacek(a)codeweavers.com> wrote: > --- > dlls/vbscript/lex.c | 10 ++++++++++ > dlls/vbscript/tests/lang.vbs | 7 +++++++ > dlls/vbscript/tests/run.c | 2 ++ > 3 files changed, 19 insertions(+), 0 deletions(-) > Hi, Jacek, I'm far away from my linux box and I'm just passing by to remember that there is a 24 continuation limit. Here is an invalid operation because it has 26 continuations: x = _ 3 _ + 3 _ + 3 _ + 3 _ + 3 - _ 3 + _ 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 And this is another test that must pass too (there is no new operand after the last _ ) : x = _ 3 _ + 3 _ + 3 _ + 3 _ As I said I can't test in wine but maybe you will find this information useful. Best wishes, Bruno -- universe* god::bigbang (void); //and then it all began...

2 2

Re: [3/7] d3d9/tests: Add a test for locking partial blocks with different pools
by Henri Verbeet 17 Oct '11

17 Oct '11

On 16 October 2011 23:01, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + hr = IDirect3DDevice9_CreateTexture(device, 4, 4, 1, > + pools[i].pool == D3DPOOL_DEFAULT ? D3DUSAGE_DYNAMIC : 0, > + D3DFMT_DXT5, pools[i].pool, &texture, NULL); Same comment about dynamic textures as for patch 2/7. > + rect.left = 0; rect.top = 0; rect.right = 2; rect.bottom = 2; I don't care strongly about this, but note that SetRect() exists.

1 0

Re: [2/7] wined3d: Locking partial blocks is not allowed in DEFAULT pool resources
by Henri Verbeet 17 Oct '11

17 Oct '11

On 16 October 2011 22:56, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + hr = IDirect3DDevice9_CreateTexture(device, 128, 128, 1, D3DUSAGE_DYNAMIC, dxt_formats[i].fmt, > + D3DPOOL_DEFAULT, &texture, NULL); You should check D3DCAPS2_DYNAMICTEXTURES before using dynamic textures. Also, wouldn't it be more appropriate to make this part of the test in patch 3/7?

1 0

Re: d3dx9_36: Buffer size does not depend on the size of the created buffer
by Henri Verbeet 17 Oct '11

17 Oct '11

This is because the buffer is supposed to be created by D3DXCreateBox().

1 0

Re: riched20: Prevent setting an invalid default format rect
by Thomas Faber 17 Oct '11

17 Oct '11

Hey, On 2011-10-15 12:10, Thomas Faber wrote: > The patch fixes this by adding checks to ME_SetDefaultFormatRect to > use the minimal rectangle that is still valid in this case. I've made some tests (will post them later) and it turns out this rectangle is also invalid in Windows in this case, so this is not the correct solution. Please ignore the patch, I will try to come up with a better one soon. Regards, Tom

1 0

Re: [patch] Support NULL puLen in VerQueryValue
by Andrew Nguyen 15 Oct '11

15 Oct '11

On 01/03/2011 09:25 PM, Rafael Ávila de Espíndola wrote: > I couldn't find any documentation saying that this must be supported, > but running google code search on VerQueryValue.*NULL found some uses. > > Cheers, > Rafael > > > > You should write some tests to examine the behavior of VerQueryValue with NULL puLen.

3 2

Fwd: [Announce] Google Code-in 2011
by Austin English 14 Oct '11

14 Oct '11

---------- Forwarded message ---------- From: Carol Smith <carols(a)google.com> Date: Fri, Oct 14, 2011 at 15:28 Subject: [Announce] Google Code-in 2011 To: Google Summer of Code Mentors List <google-summer-of-code-mentors-list(a)googlegroups.com> Hi everyone, We’re pleased to announce that we are planning to run the Google Code-in contest again this November. We had a successful contest last year with 20 mentoring organizations and 361 participating students. We will again be giving 13-17 year old students around the world an opportunity to get involved with open source projects doing tasks ranging from documentation to outreach to coding programs. We’re looking forward to a fun contest this year and hope you’ll consider participating as a mentor and/or org admin yourself, and spreading the word to friends, family, and colleagues about the program. Please check out the timeline [0] for more details on the program. We will soon be accepting applications for open source organizations to become mentoring organizations for this year’s contest. There will be a separate email thread to this list inviting you to apply to be a mentoring organization on Monday, 17 October. Please take some time to discuss with your respective organizations about whether you feel you have the time and mentor capacity to participate this year. We won’t kid you: working with teengers can be demanding. It’s important that your mentors/org be prepared to put the time in over the holiday, but if you participate you will all have the satisfaction of sharing your project and your passion for open source with a truly amazing collection of young people, and getting them started in our community. We've put together an Information Page [1] for this year's program to give you some lessons learned from last year's program. *Please* look this over before deciding to apply to participate in the program. We encourage you to join the Google Code-in contest discussion list [2] and announcement list [3]. Please see our blog post [4] for further details and contact us directly if you have specific questions that aren’t answered in the FAQs [5]. [0] - http://www.google-melange.com/gci/events/google/gci2011 [1] - http://code.google.com/p/google-code-in/wiki/GCIAdminMentorInformation [2] - http://groups.google.com/group/gci-discuss [3] - http://groups.google.com/group/gci-announce [4] - http://google-opensource.blogspot.com/2011/10/google-code-in-are-you-in.html [5] - http://www.google-melange.com/gci/document/show/gci_program/google/gci2011/… Cheers, The Google OSPO Team -- You received this message because you are subscribed to the Google Groups "Google Summer of Code Mentors List" group. To post to this group, send email to google-summer-of-code-mentors-list(a)googlegroups.com. To unsubscribe from this group, send email to google-summer-of-code-mentors-list+unsubscribe(a)googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-summer-of-code-mentors-list?hl=en. -- -Austin

1 0

Re: [6/6] wined3d: Catch nop palette updates
by Henri Verbeet 14 Oct '11

14 Oct '11

This looks questionable. Which applications does this help?

2 3

Re: 79927: [3/3] cmd: Make RENAME work for read-only files
by Dan Kegel 14 Oct '11

14 Oct '11

gcc complains here: builtins.c: In function 'WCMD_rename': builtins.c:1782:9: error: unused variable 'attribs' [-Werror=unused-variable] On Fri, Oct 14, 2011 at 2:27 AM, <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/383 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) > BUILD FAILED: failed shell_2 > > Errors: > builtins.c: In function 'WCMD_rename': > builtins.c:1782:9: error: unused variable 'attribs' [-Werror=unused-variable] > make[1]: *** [builtins.o] Error 1 > make: *** [programs/cmd] Error 2 > make: *** Waiting for unfinished jobs.... > >

2 1

Re: ddraw: Keep track of interface attached by AddAttachedSurface and detach correct interface when parent is released. (try 3)
by Saulius Krasuckas 14 Oct '11

14 Oct '11

Hello, Octavian. * On Tue, 11 Oct 2011, Octavian Voicu wrote: > > try 3: > - fix test failure by moving error check from *_DeleteAttachedSurface to > ddraw_surface_delete_attached_surface, after another check (thanks Henri). > > try 2: > - use IUnknown_Release(attached_iface) instead of manual dispatch, > as suggested by Henri; > - change type of attached_iface from void* to IUnknown* to reflect > fact that it's a pointer to an interface; > - add test to show that attaching a surface only attaches a specific > interface and return error if DeleteAttachedSurface is called with > another interface than the attached one (instead of detaching the > surface anyway). > > Fixes a bug that causes a stencil buffer leak in the game The Longest Journey. > Problem can be seen in the console output log attached to bug #11819. > This patch doesn't fix the original bug, but now game exits cleanly. > > The root of the problem is that when releasing a surface, its attached > surfaces are detached using IDirectDraw7_DeleteAttachedSurface, regardless > of what interface was originally attached. I am troubled by seeing (via test.winehq.org) your ddraw:refcount tests to account only results for "VMware SVGA 3D" adapter/driver (and only those with 3D acceleration disabled), I guess. But if this driver is 3D-enabled or just present real physical adapter (with no 3d acceleration) then ddraw:refcount contains 6 static failures such as: refcount.c:214: Test failed: AddAttachedSurface returned 8876000a refcount.c:235: Test failed: AddAttachedSurface returned 8876000a refcount.c:237: Test failed: Got refcount 1, expected 2 refcount.c:262: Test failed: AddAttachedSurface returned 8876000a refcount.c:275: Test failed: AddAttachedSurface returned 8876000a refcount.c:277: Test failed: Got refcount 1, expected 2 refcount: 112 tests executed (0 marked as todo, 6 failures), 0 skipped This relation can be easily tracked by looking at d3d9:visual or (if they aren't present) at opengl32:opgenl tests. Eg. failures occuring here: * Intel(R) 82865G Graphics Controller http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/xp_af-… http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/xp_af-… * NVIDIA GeForce FX 5200 http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/win7_s… http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/win7_s… http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/xp_s2-… http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/xp_s2-… * ATI Radeon HD 4800 Series (telling it has no IDirect3D[7] support for DDraw) http://test.winehq.org/data/a843acef5567bc30901612ce5013da543259b21b/win7_w… http://test.winehq.org/data/a843acef5567bc30901612ce5013da543259b21b/win7_w… * VMware SVGA II http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/2000_f… http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/2000_f… http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/2000_f… http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/2000_f… * VMware SVGA 3D (telling it has not IDirect3D[7] support for DDraw) http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/win7_f… http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/win7_f… All other cases succeed. AFAICS all of them represent the only driver (with 3D support turned off): * VMware SVGA 3D http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/win7_w… visual.c:194: Driver string: "vm3dum.dll" visual.c:195: Description string: "VMware SVGA 3D (Microsoft Corporation - WDDM)" visual.c:197: Device name string: "\\.\DISPLAY1" visual.c:199: Driver version 7.14.1.40 visual.c:12627: Tests skipped: Creating the device failed visual: 5 tests executed (0 marked as todo, 0 failures), 1 skipped. with following results: http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/win7_w… refcount: 121 tests executed (0 marked as todo, 0 failures), 0 skipped. IMHO, it would be nice to conform to real world configuration. Wish you best luck with fixing your tests:) S.

3 2

Re: [2/6] wined3d: Pass the destination surface to blitters
by Henri Verbeet 14 Oct '11

14 Oct '11

On 13 October 2011 01:07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > -static HRESULT arbfp_blit_set(void *blit_priv, struct wined3d_context *context, struct wined3d_surface *surface) > + static HRESULT arbfp_blit_set(void *blit_priv, struct wined3d_context *context, struct wined3d_surface *src, > + const struct wined3d_surface *dst) Whitespace error. The parameter you're adding isn't used anywhere, not even in the same patchset. Perhaps more important though is the point that "set_shader" is pretty much the wrong interface for blitters and should go away. Note that the blitter interface is something I'm actually working on as part of the ddraw work, it's just that other things keep coming up.

2 3

One more review: wineps.drv: Implement PS_USERSTYLE on printers
by Daniel Santos 14 Oct '11

14 Oct '11

Is anybody intimately familiar with the life cycle of device context and pens? I don't necessarily mean that you went to bed with either of them, but that would be OK too. I mean, this is the 2010s, we're supposed to be modern here. Specifically, I want to make sure I'm not leaking my dynamically allocated memory block. This block is allocated when the pen is selected (not when it's created). Thanks in advance Daniel

1 1

Re: 79921: ntdll: Move adding VPROT_READ for Solaris to the same place where it's done for FreeBSD. Take 2.
by Dan Kegel 14 Oct '11

14 Oct '11

Fails to apply here: $ patch -p1 < vprot.patch patching file dlls/ntdll/virtual.c Hunk #1 FAILED at 187. 1 out of 2 hunks FAILED -- saving rejects to file dlls/ntdll/virtual.c.rej On Thu, Oct 13, 2011 at 10:02 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/373 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) > BUILD FAILED: failed git > > Errors: > error: patch failed: dlls/ntdll/virtual.c:187 > error: dlls/ntdll/virtual.c: patch does not apply > >

2 1

Re: [3/6] wined3d: Use the destination palette when blitting between P8 surfaces
by Henri Verbeet 13 Oct '11

13 Oct '11

On 13 October 2011 01:07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Native transfers the 8 bit data without modifications to the destination > surface and does the palette lookup when showing the final front buffer > contents on the screen. Which makes much more sense.

2 2

Re: [1/6] wined3d: YUV formats are block-based
by Henri Verbeet 13 Oct '11

13 Oct '11

On 13 October 2011 01:07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > diff --git a/dlls/d3d9/tests/surface.c b/dlls/d3d9/tests/surface.c > diff --git a/dlls/ddraw/tests/overlay.c b/dlls/ddraw/tests/overlay.c These tests don't prove anything, they pass on current Wine as well. > + {WINED3DFMT_YUY2, 2, 1, 4, FALSE }, > + {WINED3DFMT_UYVY, 2, 1, 4, FALSE }, > + /* YV12 actually has 2x2 blocks with 6 bytes per block, but the blocks > + * are spread across the surface. */ > + {WINED3DFMT_YV12, 1, 1, 1, FALSE}, Blocks with 1 height aren't really blocks.

2 1

Re: wined3d: Refuse to create a shader unsupported by the backend.
by Alexandre Julliard 13 Oct '11

13 Oct '11

Matteo Bruni <mbruni(a)codeweavers.com> writes: > --- > dlls/d3d9/tests/shader.c | 22 ++++++++++++++++++++-- > dlls/wined3d/device.c | 2 ++ > dlls/wined3d/shader.c | 19 +++++++++++++++++++ > dlls/wined3d/wined3d_private.h | 1 + > 4 files changed, 42 insertions(+), 2 deletions(-) It breaks the tests here: ../../../tools/runtest -q -P wine -M d3d10.dll -T ../../.. -p d3d10_test.exe.so effect.c && touch effect.ok effect.c:2661: Test failed: D3D10CreateEffectFromMemory failed! wine: Unhandled page fault on read access to 0x00000000 at address 0x6869a2a3 (thread 0024), starting debugger... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 5/5] server/named_pipe.c: remove the ps_disconnected_server state, if DisconnectNamedPipe is called, the server i
by Marvin 13 Oct '11

13 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=14877 Your paranoid android. === WXPPROSP3 (32 bit pipe) === pipe.c:1605: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 1368 === W2K3R2SESP2 (32 bit pipe) === pipe.c:1605: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 1368 === WVISTAADM (32 bit pipe) === pipe.c:1605: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 1368 === W2K8SE (32 bit pipe) === pipe.c:1605: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 1368 === W7PRO (32 bit pipe) === pipe.c:1605: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 1368 === W7PROX64 (32 bit pipe) === pipe.c:1605: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 1368 === TEST64_W7SP1 (32 bit pipe) === pipe.c:1605: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 1368 === W7PROX64 (64 bit pipe) === pipe.c:1605: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 1368 === TEST64_W7SP1 (64 bit pipe) === pipe.c:1605: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 1368

1 0

Re: [PATCH 4/5] kernel32, ntdll: implement most of GetNamedPipeHandleState (try 3)
by Marvin 13 Oct '11

13 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=14876 Your paranoid android. === WXPPROSP3 (32 bit pipe) === pipe.c:1561: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 1368 === W2K3R2SESP2 (32 bit pipe) === pipe.c:1561: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 1368 === WVISTAADM (32 bit pipe) === pipe.c:1561: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 1368 === W2K8SE (32 bit pipe) === pipe.c:1561: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 1368 === W7PRO (32 bit pipe) === pipe.c:1561: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 1368 === W7PROX64 (32 bit pipe) === pipe.c:1561: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 1368 === TEST64_W7SP1 (32 bit pipe) === pipe.c:1561: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 1368 === W7PROX64 (64 bit pipe) === pipe.c:1561: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 1368 === TEST64_W7SP1 (64 bit pipe) === pipe.c:1561: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 1368

1 0

For review please: wineps.drv: Implement PS_USERSTYLE on printers
by Daniel 13 Oct '11

13 Oct '11

Hello guys. I would like to get a little review on this patch, a follow up to the patches that fix this problem on the screen. Specifically, I'm most concerned about making sure my dynamically allocated memory is freed under all conditions and there's no potential snafus that I'm not aware of. Then, of course, if somebody sees something off, please do comment. It does indeed completely fix http://bugs.winehq.org/show_bug.cgi?id=26091 (printed a cute piece of music with dashed lines). Thanks all! Daniel

2 1

Re: wined3d: recognize "Brian Paul" as a mesa card vendor
by Henri Verbeet 13 Oct '11

13 Oct '11

On 13 October 2011 02:23, Austin English <austinenglish(a)gmail.com> wrote: > See http://bugs.winehq.org/show_bug.cgi?id=28684 / > http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/main/getstring.c#n88 > Yeah, this makes sense. You'd probably mostly run into this if you're not using the regular dri based drivers, but that's valid, if somewhat obscure.

1 0

Re: [1/4] winex11.drv: Add on-screen PS_USERSTYLE support to pens (take 4)
by Frédéric Delanoy 13 Oct '11

13 Oct '11

On Thu, Oct 13, 2011 at 06:08, Daniel <danielfsantos(a)att.net> wrote: > Fixes on-screen portion of http://bugs.winehq.org/show_bug.cgi?id=26091 You should configure your mail/git config so your real name appears in patches, and not just your first name "Daniel"

1 0

Re: mscoree: Register interfaces
by Alexandre Julliard 13 Oct '11

13 Oct '11

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > @@ -10,4 +10,6 @@ C_SRCS = \ > metahost.c \ > mscoree_main.c > > +IDL_R_SRCS = mscoree_v1.idl There's no reason to name the file v1, that's a leftover from stdole.tlb but it doesn't make sense here. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/3] winex11.drv: Add on-screen PS_USERSTYLE support to pens (bugbot feeding #5)
by Alexandre Julliard 13 Oct '11

13 Oct '11

Daniel <danielfsantos(a)att.net> writes: > @@ -42,29 +42,23 @@ HPEN X11DRV_SelectPen( PHYSDEV dev, HPEN hpen ) > X11DRV_PDEVICE *physDev = get_x11drv_dev( dev ); > LOGPEN logpen; > int i; > + EXTLOGPEN *elp = NULL; > + INT size = GetObjectW( hpen, 0, NULL ); > > - if (!GetObjectW( hpen, sizeof(logpen), &logpen )) > - { > - /* must be an extended pen */ > - EXTLOGPEN *elp; > - INT size = GetObjectW( hpen, 0, NULL ); > - > - if (!size) return 0; > - > + if (!size) return 0; > + else if (size == sizeof(logpen)) { > + GetObjectW( hpen, sizeof(logpen), &logpen ); > + physDev->pen.ext = 0; > + } else { You are changing too much here, there's no reason to duplicate the GetObject call for the standard case. Also please make sure to include your full name in your mail headers. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [msi] initialize variable to placate static analyzers
by Michael Stefaniuc 13 Oct '11

13 Oct '11

Hello Dan, Dan Kegel wrote: > Avoids the spurious compiler warning > > msi.c: In function 'MSI_ApplyPatchW': > msi.c:353:10: error: 'r' may be used uninitialized in this function > > Hans says "It's compiler confusion but I'm fine with a patch that initializes > r with ERROR_FUNCTION_FAILED." why don't you just initialize r in the declaration of r? It's the standard way of doing it and doesn't require a suboptimal comment (that warning is gcc version dependent). bye michael

1 0

Re: 79869: [2/4] gdi32: remove PS_USERSTYLE FIXME and work-arounds (take 4)
by Dan Kegel 13 Oct '11

13 Oct '11

Still fails tests here. Sorry if I wasn't clear before. The wine tests are supposed to pass after *every* patch in your series. That means you have to merge patches 2 and 3 together, I think. On Wed, Oct 12, 2011 at 9:27 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/297 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) > BUILD FAILED: failed shell_3 > > Errors: > alarum: failed command was ../../../wine gdi32_test.exe.so pen.c > pen.c:317: Test succeeded inside todo block: expected 7, got 7 > make: *** [pen.ok] Error 1 > * Call to xpconnect wrapped JSObject produced this error: * > * Call to xpconnect wrapped JSObject produced this error: * > GnuTLS error: GnuTLS internal error. > >

1 0

re: ntdll: Define PATH_MAX when needed
by Dan Kegel 13 Oct '11

13 Oct '11

When is PATH_MAX not defined? It's part of posix (see http://pubs.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html ) Are you trying to build on Gnu Hurd?

3 2

WineHQ database compromise
by Jeremy White 13 Oct '11

13 Oct '11

Hi, I am sad to say that there was a compromise of the WineHQ database system. What we know at this point that someone was able to obtain unauthorized access to the phpmyadmin utility. We do not exactly how they obtained access; it was either by compromising an admins credentials, or by exploiting an unpatched vulnerability in phpmyadmin. We had reluctantly provided access to phpmyadmin to the appdb developers (it is a very handy tool, and something they very much wanted). But it is a prime target for hackers, and apparently our best efforts at obscuring it and patching it were not sufficient. So we have removed all access to phpmyadmin from the outside world. We do not believe the attackers obtained any other form of access to the system. On the one hand, we saw no evidence of harm to any database. We saw no evidence of any attempt to change the database (and candidly, using the real appdb or bugzilla is the easy way to change the database). Unfortunately, the attackers were able to download the full login database for both the appdb and bugzilla. This means that they have all of those emails, as well as the passwords. The passwords are stored encrypted, but with enough effort and depending on the quality of the password, they can be cracked. This, I'm afraid, is a serious threat; it means that anyone who uses the same email / password on other systems is now vulnerable to a malicious attacker using that information to access their account. We are going to be resetting every password and sending a private email to every affected user. This is again another reminder to never use a common username / password pair. This web site provides further advice as well: http://asiknews.wordpress.com/2011/03/02/best-practice-password-management-… I am very sad to have to report this. We have so many challenges in our world today that this is a particularly painful form of salt for our wounds. However, I think it is urgent for everyone to know what happened. Cheers, Jeremy

11 16

Re: [4/3] gdi32/tests: update test for PS_USERSTYLE
by Austin English 13 Oct '11

13 Oct '11

On Wed, Oct 12, 2011 at 19:06, Daniel <danielfsantos(a)att.net> wrote: > OK, I hope [4/3] is acceptable. These are the test updates I forgot > (removes a todo_wine). Two problems: A) It needs to be combined with the original patch, so that it passes make test. B) Why remove the test? Just remove 'todo_wine' itself, since the test now passes on wine.. -- -Austin

2 1

re: [4/3] gdi32/tests: update test for PS_USERSTYLE
by Dan Kegel 13 Oct '11

13 Oct '11

> OK, I hope [4/3] is acceptable. It's fine for humans, but for buildbot, you really need to send the whole patch series again, with the test fixes right in the same patch as the code that fixes them (so that the wine tree passes all tests after each patch in the series). Otherwise your code will not be tested.

1 0

Re: 79857: [2/3] gdi32: remove PS_USERSTYLE FIXME and work-arounds (take 3)
by Dan Kegel 12 Oct '11

12 Oct '11

Fails the gdi32/pen.ok test here, with error pen.c:317: Test succeeded inside todo block: expected 7, got 7 Looks like you need to update a test. On Wed, Oct 12, 2011 at 4:00 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/280 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) > BUILD FAILED: failed shell_3 > > Errors: > alarum: failed command was ../../../wine gdi32_test.exe.so pen.c > pen.c:317: Test succeeded inside todo block: expected 7, got 7 > make: *** [pen.ok] Error 1 > * Call to xpconnect wrapped JSObject produced this error: * > * Call to xpconnect wrapped JSObject produced this error: * > GnuTLS error: GnuTLS internal error. > >

2 1

[RFC] Use ICU in wine ?
by Rafał Mużyło 12 Oct '11

12 Oct '11

Right now, wine claims to use DUCET data for lingustic sorting, but by section 1.9.2 of that document (as of version 6.0.0), uses it in a wrong way. The result of it are bugs such as #10767 and #9583. A possible way around it would beby using ICU to get language specific tailoring and applying some of wine-specific for the parts addressed by #10767. In a way, wine already *indirectly* depends on icu on many distros (a potential libxml2 dep) - they were quite a few patches already addressing build failures caused by this in recent past. I've cooked up a patch, that's unfortunately isn't working properly yet, it's more of a draft on where to go, if such road were to be taken. Main issue with this patch ain't it's not ignoring the proper list of symbols, as this would be easy to fix, if not for one problem: the part that I put inside 'if (0)' block. For some reason (threading, perhaps ?), if I pass a non-zero lenght string to ucol_openRules, wineboot hangs. Oddly, if the string lenght is 0, the hang doesn't happen. I can't really tell, what going wrong, as the almost same code works in native linux testcase. Also, while in this patch UCOL_ALTERNATE_HANDLING would have been used for NORM_IGNORESYMBOLS, it would be much better to manipulate some of the settings by a custom rule and VariableTop value, but to do that, first such rule would have to be passed and that odd hang prevents it at the moment. It would also be nice, if it was possible to initialize the collator only once for an app instance - after all, in Windows locale change requires a reboot, so while (AFAIK) one wineserver instance can have apps in different locales running, locale can't change for an already running app. So if you have any idea of why exactly the hang happens and how to get around it or know any *technical* reasons of why ICU couldn't be used in wine, CC me with comments.

5 7

Re: wined3d: Report every texture format as filterable and blendable.
by Dan Kegel 12 Oct '11

12 Oct '11

Fails d3d9's visual tests here. os: Linux 3.0.0-12-generic, Ubuntu 11.10 gpu: GeForce GT 240/PCI/SSE2 3.3.0 NVIDIA 280.13 On Wed, Oct 12, 2011 at 2:52 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/273 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) > BUILD FAILED: failed shell_3 > > Errors: > alarum: failed command was ../../../wine d3d9_test.exe.so visual.c > fixme:win:EnumDisplayDevicesW ((null),0,0x33f0cc,0x00000000), stub! > fixme:d3d_draw:drawPrimitive Using software emulation because manual fog coordinates are provided > fixme:d3d:state_shademode WINED3DSHADE_PHONG isn't supported > fixme:d3d:state_shademode WINED3DSHADE_PHONG isn't supported > visual.c:9147: Tests skipped: D3DFMT_G16R16 textures not supported as render targets. > visual.c:9239: Test failed: Offscreen failed for D3DFMT_R16F: Got color 0x20ffff, expected 0x18ffff. > visual.c:9239: Test failed: Offscreen failed for D3DFMT_G16R16F: Got color 0x2010ff, expected 0x1818ff. > visual.c:9239: Test failed: Offscreen failed for D3DFMT_R32F: Got color 0x20ffff, expected 0x18ffff. > visual.c:9239: Test failed: Offscreen failed for D3DFMT_G32R32F: Got color 0x2010ff, expected 0x1818ff. > visual.c:9239: Test failed: Offscreen failed for D3DFMT_A32B32G32R32F: Got color 0x201000, expected 0x181800. > visual.c:7741: Tests skipped: Card has unconditional pow2 support, skipping conditional NP2 tests > make: *** [visual.ok] Error 5 > * Call to xpconnect wrapped JSObject produced this error: * > * Call to xpconnect wrapped JSObject produced this error: * > GnuTLS error: GnuTLS internal error. > >

2 1

Please Test again, user32: use uniscribe in the single line edit control
by Aric Stewart 12 Oct '11

12 Oct '11

Apologies I sent this to the wrong list just now. Ok, Thanks to Dan I have found and corrected the issues that this created with the tests. I believe all the tests should continue to pass with this version of the patch. Has anyone tried it live in any applications? -aric --- dlls/user32/edit.c | 252 +++++++++++++++++++++++++++++----------------------- 1 files changed, 142 insertions(+), 110 deletions(-)

1 0

Re: shell32/tests: Better check the result of SHGetDesktopFolder
by Austin English 12 Oct '11

12 Oct '11

2011/10/12 André Hentschel <nerv(a)dawncrow.de>: > Might fix the crash in some NT4 systems > --- > dlls/shell32/tests/brsfolder.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/dlls/shell32/tests/brsfolder.c b/dlls/shell32/tests/brsfolder.c > index 7b87967..6e5e73b 100644 > --- a/dlls/shell32/tests/brsfolder.c > +++ b/dlls/shell32/tests/brsfolder.c > @@ -331,7 +331,8 @@ static void test_selection(void) > > hr = SHGetDesktopFolder(&desktop_object); > ok (SUCCEEDED(hr), "SHGetDesktopFolder failed with hr 0x%08x\n", hr); > - if (FAILED(hr)) { > + ok (desktop_object, "Expected desktop_object to be a valid interface\n"); > + if (FAILED(hr) || !desktop_object) { > skip("SHGetDesktopFolder failed - skipping\n"); > return; > } > -- > > Best Regards, André Hentschel Causes a compiler warning on Buildbot: Errors: brsfolder.c: In function 'test_selection': brsfolder.c:334:5: error: passing argument 1 of 'winetest_ok' makes integer from pointer without a cast [-Werror] make[1]: *** [brsfolder.o] Error 1 -- -Austin

1 0

Warning report for wine-1.3.30-55-g583e887
by Jerome Leclanche 12 Oct '11

12 Oct '11

It would be nice to fix the "array subscript is above array bounds" warning spam for 1.4.0. They make up 90% of the warnings. Apart from those, theres 25 more warning blocks to fix, most of them unused-but-set-variables. JL

5 5

Re: [Corrected^2] dlls/ntdll/serial.c: Generate a single EV_TXEMPTY when the\ TX buffer turns empty
by Alexandre Julliard 12 Oct '11

12 Oct '11

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > @@ -807,8 +808,22 @@ typedef struct async_commio > static NTSTATUS get_irq_info(int fd, serial_irq_info *irq_info) > { > NTSTATUS status = STATUS_NOT_IMPLEMENTED; > -#ifdef TIOCGICOUNT > struct serial_icounter_struct einfo; You can't move this out of the #idef. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: d3d8/tests: skip the visual test if d3d cannot be initialized
by Henri Verbeet 12 Oct '11

12 Oct '11

On 12 October 2011 01:51, Austin English <austinenglish(a)gmail.com> wrote: > Current d3d8 does a win_skip(), while d3d9 does a skip(). This unifies > the behavior to match the d3d9 behavior. > I seem to recall this being intentional, so that you get a failure if your setup has e.g. no OpenGL.

2 1

Re: [4/4] wined3d: Don't allow fbo blits to frontbuffers that need fixups.
by Henri Verbeet 12 Oct '11

12 Oct '11

On 11 October 2011 22:31, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > static BOOL fbo_blit_supported(const struct wined3d_gl_info *gl_info, enum wined3d_blit_op blit_op, > const RECT *src_rect, DWORD src_usage, WINED3DPOOL src_pool, const struct wined3d_format *src_format, > - const RECT *dst_rect, DWORD dst_usage, WINED3DPOOL dst_pool, const struct wined3d_format *dst_format) > + const RECT *dst_rect, DWORD dst_usage, WINED3DPOOL dst_pool, const struct wined3d_format *dst_format, > + const struct wined3d_surface *dst_surface) I don't think we want this. Does this actually ever happen?

2 1

Re: 79794: Help Test Please: use uniscribe in the single line edit control
by Dan Kegel 12 Oct '11

12 Oct '11

Hi Aric, failed again on second run, http://buildbot.kegel.com:8010/builders/runtests-default/builds/209 Failing tests are comctl32_test.exe.so listview.c comctl32_test.exe.so updown.c user32_test.exe.so edit.c On Tue, Oct 11, 2011 at 1:26 PM, Dan Kegel <dank(a)kegel.com> wrote: > Hey Aric, > don't know if I trust the bot at the moment, but it says the tests > failed here... > I'll rerun them to see if the failure is repeatable. > > ---------- Forwarded message ---------- > From: <buildbot(a)kegel.com> > Date: Tue, Oct 11, 2011 at 1:21 PM > Subject: Re: 79794: Help Test Please: use uniscribe in the single line > edit control > To: dank(a)kegel.com, wine-tests-results(a)winehq.org > > > 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/186 (though > maybe not for long, as I'm still reinstalling the buildbot > periodically while experimenting) > BUILD FAILED: failed shell_3 > > Errors: > alarum: Timeout! Killing child ../../../wine. > alarum: failed command was ../../../wine comctl32_test.exe.so listview.c > alarum: ../../../wine terminated abnormally > make: *** [listview.ok] Error 99 > alarum: Timeout! Killing child ../../../wine. > alarum: failed command was ../../../wine comctl32_test.exe.so updown.c > alarum: ../../../wine terminated abnormally > make: *** [updown.ok] Error 99 > * Call to xpconnect wrapped JSObject produced this error: * > * Call to xpconnect wrapped JSObject produced this error: * > alarum: failed command was ../../../wine user32_test.exe.so edit.c > edit.c:1138: Test failed: expected 1 got 0 > edit.c:1156: Test failed: expected 1 got 0 > edit.c:1174: Test failed: expected 1 got 0 > make: *** [edit.ok] Error 3 > GnuTLS error: GnuTLS internal error. >

2 1

Re: [PATCH 5/5] server/named_pipe.c: remove the ps_disconnected_server state, if DisconnectNamedPipe is called, the server i
by Marvin 12 Oct '11

12 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=14844 Your paranoid android. === WNT4WSSP6 (32 bit pipe) === pipe.c:1603: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 203 === W2KPROSP4 (32 bit pipe) === pipe.c:1603: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 997

1 0

Re: [PATCH 4/5] kernel32, ntdll: implement most of GetNamedPipeHandleState (try 2)
by Marvin 12 Oct '11

12 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=14843 Your paranoid android. === WNT4WSSP6 (32 bit pipe) === pipe.c:1559: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 203 === W2KPROSP4 (32 bit pipe) === pipe.c:1559: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 997

1 0

Re: [2/4] wined3d: reject ARB shader blits if the destination is not fbo attachable
by Henri Verbeet 12 Oct '11

12 Oct '11

On 11 October 2011 22:30, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + if (wined3d_settings.offscreen_rendering_mode == ORM_FBO) > + { > + if (!((dst_format->flags & WINED3DFMT_FLAG_FBO_ATTACHABLE) || (dst_usage & WINED3DUSAGE_RENDERTARGET))) > + return FALSE; > + } > + else if (!(dst_usage & WINED3DUSAGE_RENDERTARGET)) > + { > + return FALSE; > + } This is redundant. Formats are never FBO-attachable if we don't have FBOs. It's not clear this is what you want either way though. This pretty much looks like a copy/paste from fbo_blit_supported(), and the WINED3DUSAGE_RENDERTARGET check there is to allow formats that don't have a FBO-attachable internal format, but were created with the rtInternal format (which should always be attachable). There's really no equivalent check for backbuffer ORM, it just renders something and hopes we can read it back.

2 1

Re: [1/4] wined3d: Use an rbtree for the blit programs
by Henri Verbeet 12 Oct '11

12 Oct '11

Why do you need this?

2 3

Re: [3/4] wined3d: reject ffp blits if the destination is not fbo attachable
by Henri Verbeet 12 Oct '11

12 Oct '11

On 11 October 2011 22:30, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + if (wined3d_settings.offscreen_rendering_mode == ORM_FBO) > + { > + if (!((dst_format->flags & WINED3DFMT_FLAG_FBO_ATTACHABLE) || (dst_usage & WINED3DUSAGE_RENDERTARGET))) > + return FALSE; > + } > + else if (!(dst_usage & WINED3DUSAGE_RENDERTARGET)) > + { > + return FALSE; > + } Same consideration as for 2/4. Guess I should have caught this when bccfd7cc introduced it.

1 0

Re: [PATCH] dsound: Don't claim to support hardware buffers
by Marvin 11 Oct '11

11 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=14829 Your paranoid android. === W2K3R2SESP2 (32 bit dsound) === dsound.c:329: Test failed: IDirectSound_CreateSoundBuffer() failed to create a secondary buffer 88780032

1 0

Re: [PATCH] dsound: Don't claim to support hardware buffers
by Chris Robinson 11 Oct '11

11 Oct '11

Hi. On Tuesday, October 11, 2011 3:31:59 PM Andrew Eikum wrote: > The specific drvcaps values and error code were tested against Windows > 7. How does this affect the primary buffer? Is it not allowed to be a hardware buffer either?

1 0

Re: [PATCH 1/7] msi/custom.c: unify thread handling of different custom action types (resend)
by Hans Leidekker 11 Oct '11

11 Oct '11

On Tue, 2011-10-11 at 13:20 +0200, Bernhard Loos wrote: +static HRESULT get_action_info( msi_custom_action_info *info, INT *type, + BSTR *source, BSTR *target, BSTR *name, + IWineMsiRemotePackage **package ) { - IClassFactory *cf = NULL; - IWineMsiRemoteCustomAction *rca = NULL; - HRESULT r; - - r = DllGetClassObject( &CLSID_WineMsiRemoteCustomAction, - &IID_IClassFactory, (LPVOID *)&cf ); - if (FAILED(r)) - { - ERR("failed to get IClassFactory interface\n"); - return ERROR_FUNCTION_FAILED; - } - - r = IClassFactory_CreateInstance( cf, NULL, &IID_IWineMsiRemoteCustomAction, (LPVOID *)&rca ); - if (FAILED(r)) - { - ERR("failed to get IWineMsiRemoteCustomAction interface\n"); - return ERROR_FUNCTION_FAILED; - } - - r = IWineMsiRemoteCustomAction_GetActionInfo( rca, guid, type, handle, dll, funcname, package ); - IWineMsiRemoteCustomAction_Release( rca ); - if (FAILED(r)) - { - ERR("GetActionInfo failed\n"); - return ERROR_FUNCTION_FAILED; + IWineMsiRemotePackage *rp; + HRESULT res; + *source = *target = *name = NULL; + + res = create_msi_remote_package( NULL, (void **) &rp ); + if (FAILED( res )) + return res; + res = IWineMsiRemotePackage_SetMsiHandle( rp, alloc_msihandle( &info->package->hdr ) ); You should check for failure from alloc_msihandle. + if (FAILED( res )) + goto error; + + *source = SysAllocString( info->source ); + *target = SysAllocString( info->target ); + *name = SysAllocString( info->action ); + if (!*source || !*target || !*name) { + res = E_OUTOFMEMORY; + goto error; } - + + *package = rp; + *type = info->type; + return ERROR_SUCCESS; This should become S_OK. You are mixing up return types in more places.

2 1

Re: [PATCH 5/7] msi/custom.c: get rid of MSIRUNNINGACTION
by Hans Leidekker 11 Oct '11

11 Oct '11

> -static UINT HANDLE_CustomType50(MSIPACKAGE *package, LPCWSTR source, > +static msi_custom_action_info *HANDLE_CustomType50(MSIPACKAGE *package, LPCWSTR source, > LPCWSTR target, const INT type, LPCWSTR action) > { > WCHAR *exe, *arg; > msi_custom_action_info *info; > > - if (!(exe = msi_dup_property( package->db, source ))) return ERROR_SUCCESS; > + if (!(exe = msi_dup_property( package->db, source ))) return NULL; Are you sure this should be an error? Native might ignore a missing property. > -static UINT HANDLE_CustomType53_54(MSIPACKAGE *package, LPCWSTR source, > +static msi_custom_action_info *HANDLE_CustomType53_54(MSIPACKAGE *package, LPCWSTR source, > LPCWSTR target, const INT type, LPCWSTR action) > { > msi_custom_action_info *info; > WCHAR *prop; > - UINT r; > > TRACE("%s %s\n", debugstr_w(source), debugstr_w(target)); > > prop = msi_dup_property( package->db, source ); > - if (!prop) return ERROR_SUCCESS; > + if (!prop) return NULL; Same here.

2 1

re: [PATCH 1/2] ntdll: windows refuses to load an image; if sections overlap the header size as given in the SizeOfHeaders field
by Dan Kegel 11 Oct '11

11 Oct '11

Hi Bernhard, Build fails here: loader.c: In function ‘test_section_mapping’: loader.c:706:9: error: unused variable ‘i’ [-Werror=unused-variable] cc1: all warnings being treated as errors make[1]: *** [loader.o] Error 1 make[1]: Leaving directory `/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/kernel32/tests' make: *** [dlls/kernel32/tests] Error 2 http://buildbot.kegel.com:8010/builders/runtests-default/builds/159 Can you fix and resubmit the series?

3 4

Re: [3/3] ddraw: Keep track of interface attached by AddAttachedSurface and detach correct interface when parent is released. (try 2)
by Alexandre Julliard 11 Oct '11

11 Oct '11

Octavian Voicu <octavian.voicu(a)gmail.com> writes: > Fixes a bug that causes a stencil buffer leak in the game The Longest Journey. > Problem can be seen in the console output log attached to bug #11819. > This patch doesn't fix the original bug, but now game exits cleanly. > > The root of the problem is that when releasing a surface, its attached > surfaces are detached using IDirectDraw7_DeleteAttachedSurface, regardless > of what interface was originally attached. It doesn't work here: ../../../tools/runtest -q -P wine -M ddraw.dll -T ../../.. -p ddraw_test.exe.so dsurface.c && touch dsurface.ok dsurface.c:1603: Test failed: DeleteAttachedSurface returned 887601cc dsurface.c:3534: Tests skipped: IDirectDraw7_CreateSurface failed, hr = 0x88760091, format D3DFMT_X8B8G8R8 dsurface.c:3534: Tests skipped: IDirectDraw7_CreateSurface failed, hr = 0x88760091, format D3DFMT_X8B8G8R8 dsurface.c:3534: Tests skipped: IDirectDraw7_CreateSurface failed, hr = 0x88760091, format D3DFMT_A2R10G10B10 dsurface.c:3534: Tests skipped: IDirectDraw7_CreateSurface failed, hr = 0x88760091, format D3DFMT_A8L8 make[1]: *** [dsurface.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 4/4] kernel32, ntdll: implement most of GetNamedPipeHandleState
by Juan Lang 11 Oct '11

11 Oct '11

Hi Bernhard, nit: - todo_wine - ok(!ret && GetLastError() == ERROR_INVALID_PARAMETER, + todo_wine ok(!ret && GetLastError() == ERROR_INVALID_PARAMETER, This change is a no-op. --Juan

2 1

Re: [PATCH 4/4] kernel32, ntdll: implement most of GetNamedPipeHandleState
by Marvin 11 Oct '11

11 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=14813 Your paranoid android. === WNT4WSSP6 (32 bit pipe) === pipe.c:1559: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 203 === W2KPROSP4 (32 bit pipe) === pipe.c:1559: Test failed: expected ERROR_CANNOT_IMPERSONATE, got 997

1 0

Re: [PATCH 3/3] vbscript: Added Hex function tests
by Marvin 11 Oct '11

11 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=14804 Your paranoid android. === WNT4WSSP6 (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 === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Re: winex11.drv/keyboard: MAPVK_VK_TO_CHAR correction (Bug 28168)
by Frédéric Delanoy 10 Oct '11

10 Oct '11

On Mon, Oct 10, 2011 at 22:46, <sebastian.riemer(a)gmx.de> wrote: > --- > dlls/winex11.drv/keyboard.c | 563 ++++++++++++++++++++++++++++++++++++++----- > 1 files changed, 499 insertions(+), 64 deletions(-) Please follow patch submission rules from http://wiki.winehq.org/SubmittingPatches

1 0

winex11.drv/keyboard: MAPVK_VK_TO_CHAR direct mapping
by Sebastian Riemer 10 Oct '11

10 Oct '11

Hi developers, I've just sent my first patch I would like to see in mainline. I did quite some efforts to verify that my patch is correct by doing extensive compares with Windows, the wine before and the patched wine as well as a special testing version of wine. I want to fix this bug http://bugs.winehq.org/show_bug.cgi?id=28168 and I've attached my verification data there, because this is difficult to integrate into the test suite. Could someone please look at my files and help me with some tips and advice or want to become my mentor? I'm really tired of just writing test data into the AppDB and only little changes over the time for the applications I maintain. So, I want to improve wine for the applications I like. Cheers, Sebastian

1 0

Re: mscoree: Implement ICorDebug SetManagedHandler (try 3)
by Vincent Povirk 10 Oct '11

10 Oct '11

Should SetManagedHandler really fail if the given object doesn't support ICorDebugManagedCallback2 ? You've got a stray whitespace change in RuntimeHost_Destroy. Otherwise, this looks good to me. On Mon, Oct 10, 2011 at 5:12 AM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > Hi, > > Only Release the interfaces after we have a valid callback. > Allow multiple Interfaces per runtime. > > > Changelog: > mscoree: Implement ICorDebug SetManagedHandler > > > Best Regards > Alistair Leslie-Hughes > > > > > >

2 2

DEVELOPMENTAL: use uniscribe in the edit control
by Aric Stewart 10 Oct '11

10 Oct '11

This patch is experimental but people had some interest in testing it and I would love some more testing. What is currently known not to be working: * Tabs * Font Fallback * Complex composed glyphs are not breaking or highlighting properly. Testing is appreceated. Send me crashes or incorrect behavior. It should work with both native and builtin usp10. The patch will be cleaned and broken up before being send it this is just for testing. thanks! -aric --- dlls/user32/edit.c | 495 +++++++++++++++++++++++++++------------------------- 1 files changed, 256 insertions(+), 239 deletions(-)

1 0

Re: [1/5] d3d8: Never announce support for palettized textures
by Henri Verbeet 10 Oct '11

10 Oct '11

On 9 October 2011 15:21, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > This is the first set of my P8 patches, they remove dead code that is left over > from d3d8/9 style palettized texture support. See > http://www.winehq.org/pipermail/wine-devel/2011-October/092744.html for the > entire patchset. > I thought you asked me not to look at these patches yet because you still had some issues to fix. Regardless, I gave this a cursory look: - I can't say I find e.g. sprinkling d3dformat_is_palettized() over the code particularly elegant. - Do you have tests for the D3DERR_INVALIDCALL returns? - In patch 5 you remove wined3d_device_get_current_texture_palette() from the spec but not from the public header.

2 3

Re: [ 3/3] ddraw: Keep track of interface attached by AddAttachedSurface and detach correct interface when parent is released.
by Henri Verbeet 10 Oct '11

10 Oct '11

On 10 October 2011 08:07, Octavian Voicu <octavian.voicu(a)gmail.com> wrote: > +static HRESULT delete_attached_surface_helper(IDirectDrawSurfaceImpl *root, IDirectDrawSurfaceImpl *detach) > +{ > + if (detach->attached_iface == &detach->IDirectDrawSurface4_iface) > + return IDirectDrawSurface4_DeleteAttachedSurface(&root->IDirectDrawSurface4_iface, 0, > + &detach->IDirectDrawSurface4_iface); > + else if (detach->attached_iface == &detach->IDirectDrawSurface3_iface) > + return IDirectDrawSurface3_DeleteAttachedSurface(&root->IDirectDrawSurface3_iface, 0, > + &detach->IDirectDrawSurface3_iface); > + else if (detach->attached_iface == &detach->IDirectDrawSurface2_iface) > + return IDirectDrawSurface2_DeleteAttachedSurface(&root->IDirectDrawSurface2_iface, 0, > + &detach->IDirectDrawSurface2_iface); > + else if (detach->attached_iface == &detach->IDirectDrawSurface_iface) > + return IDirectDrawSurface_DeleteAttachedSurface(&root->IDirectDrawSurface_iface, 0, > + &detach->IDirectDrawSurface_iface); > + else if (detach->attached_iface != &detach->IDirectDrawSurface7_iface) > + FIXME("attached_iface %p is invalid for surface %p\n", detach->attached_iface, detach); > + > + return IDirectDrawSurface7_DeleteAttachedSurface(&root->IDirectDrawSurface7_iface, 0, > + &detach->IDirectDrawSurface7_iface); > +} > + Can't you just handle this in ddraw_surface_delete_attached_surface()? I.e., replace the Release calls in ddraw_surface?_DeleteAttachedSurface() with a IUnknown_Release(Surf->attached_iface) in ddraw_surface_delete_attached_surface(), and then just call ddraw_surface_delete_attached_surface() where you're using delete_attached_surface_helper() now.

2 1

Re: [PATCH] ntdll: deal with images which override the section table during mapping
by Marcus Meissner 10 Oct '11

10 Oct '11

On Mon, Oct 10, 2011 at 11:36:33AM +0200, Bernhard Loos wrote: > --- > dlls/ntdll/virtual.c | 38 ++++++++++++++++++++++++++++++++++---- > 1 files changed, 34 insertions(+), 4 deletions(-) I think this needs tests, the algorithms are very fragile. Ciao, Marcus > diff --git a/dlls/ntdll/virtual.c b/dlls/ntdll/virtual.c > index 5e69eb9..7841d9c 100644 > --- a/dlls/ntdll/virtual.c > +++ b/dlls/ntdll/virtual.c > @@ -1114,6 +1114,7 @@ static NTSTATUS map_image( HANDLE hmapping, int fd, char *base, SIZE_T total_siz > IMAGE_DOS_HEADER *dos; > IMAGE_NT_HEADERS *nt; > IMAGE_SECTION_HEADER *sec; > + IMAGE_SECTION_HEADER *section_table = NULL; > IMAGE_DATA_DIRECTORY *imports; > NTSTATUS status = STATUS_CONFLICTING_ADDRESSES; > int i; > @@ -1123,6 +1124,7 @@ static NTSTATUS map_image( HANDLE hmapping, int fd, char *base, SIZE_T total_siz > struct file_view *view = NULL; > char *ptr, *header_end; > INT_PTR delta = 0; > + DWORD SizeOfHeaders; > > /* zero-map the whole range */ > > @@ -1158,8 +1160,11 @@ static NTSTATUS map_image( HANDLE hmapping, int fd, char *base, SIZE_T total_siz > header_end = ptr + ROUND_SIZE( 0, header_size ); > memset( ptr + header_size, 0, header_end - (ptr + header_size) ); > if ((char *)(nt + 1) > header_end) goto error; > - sec = (IMAGE_SECTION_HEADER*)((char*)&nt->OptionalHeader+nt->FileHeader.SizeOfOptionalHeader); > - if ((char *)(sec + nt->FileHeader.NumberOfSections) > header_end) goto error; > + section_table = (IMAGE_SECTION_HEADER*)((char*)&nt->OptionalHeader+nt->FileHeader.SizeOfOptionalHeader); > + /* make sure we mapped enough memory */ > + if ((char *)(section_table + nt->FileHeader.NumberOfSections) > header_end) goto error; > + /* windows is only interested in the size as given by OptionalHeader.SizeOfHeaders */ > + SizeOfHeaders = ROUND_SIZE( 0, nt->OptionalHeader.SizeOfHeaders ); > > imports = nt->OptionalHeader.DataDirectory + IMAGE_DIRECTORY_ENTRY_IMPORT; > if (!imports->Size || !imports->VirtualAddress) imports = NULL; > @@ -1180,7 +1185,7 @@ static NTSTATUS map_image( HANDLE hmapping, int fd, char *base, SIZE_T total_siz > if (nt->OptionalHeader.FileAlignment != nt->OptionalHeader.SectionAlignment) goto error; > for (i = 0; i < nt->FileHeader.NumberOfSections; i++) > { > - if (sec[i].VirtualAddress != sec[i].PointerToRawData) > + if (section_table[i].VirtualAddress != section_table[i].PointerToRawData) > goto error; /* Windows refuses to load in that case too */ > } > > @@ -1192,6 +1197,24 @@ static NTSTATUS map_image( HANDLE hmapping, int fd, char *base, SIZE_T total_siz > goto done; > } > > + if ((char *)(section_table + nt->FileHeader.NumberOfSections) > ptr + SizeOfHeaders) > + { > + /* part of the section table is outside of SizeOfHeaders > + * at this point, it's likely that a section will get mapped over > + * the section table (Borderlands does this) > + * Not sure how it works on Windows, but we make a copy of the > + * table at this point */ > + sec = RtlAllocateHeap( virtual_heap, 0, sizeof(*sec) * nt->FileHeader.NumberOfSections); > + if (!sec) > + { > + status = STATUS_NO_MEMORY; > + goto error; > + } > + memcpy( sec, section_table, sizeof(*sec) * nt->FileHeader.NumberOfSections); > + section_table = sec; > + } > + else > + sec = section_table; > > /* map all the sections */ > > @@ -1200,6 +1223,9 @@ static NTSTATUS map_image( HANDLE hmapping, int fd, char *base, SIZE_T total_siz > static const SIZE_T sector_align = 0x1ff; > SIZE_T map_size, file_start, file_size, end; > > + if (sec->VirtualAddress < SizeOfHeaders) > + goto error; > + > if (!sec->Misc.VirtualSize) > map_size = ROUND_SIZE( 0, sec->SizeOfRawData ); > else > @@ -1329,7 +1355,7 @@ static NTSTATUS map_image( HANDLE hmapping, int fd, char *base, SIZE_T total_siz > > VIRTUAL_SetProt( view, ptr, ROUND_SIZE( 0, header_size ), VPROT_COMMITTED | VPROT_READ ); > > - sec = (IMAGE_SECTION_HEADER*)((char *)&nt->OptionalHeader+nt->FileHeader.SizeOfOptionalHeader); > + sec = section_table; > for (i = 0; i < nt->FileHeader.NumberOfSections; i++, sec++) > { > SIZE_T size; > @@ -1361,6 +1387,8 @@ static NTSTATUS map_image( HANDLE hmapping, int fd, char *base, SIZE_T total_siz > } > > done: > + if (section_table && (char *)section_table != (char *)&nt->OptionalHeader+nt->FileHeader.SizeOfOptionalHeader) > + RtlFreeHeap( virtual_heap, 0, section_table ); > view->mapping = dup_mapping; > server_leave_uninterrupted_section( &csVirtual, &sigset ); > > @@ -1373,6 +1401,8 @@ static NTSTATUS map_image( HANDLE hmapping, int fd, char *base, SIZE_T total_siz > > error: > if (view) delete_view( view ); > + if (section_table && (char *)section_table != (char *)&nt->OptionalHeader+nt->FileHeader.SizeOfOptionalHeader) > + RtlFreeHeap( virtual_heap, 0, section_table ); > server_leave_uninterrupted_section( &csVirtual, &sigset ); > if (dup_mapping) NtClose( dup_mapping ); > return status; >

1 0

Re: [PATCH] server: if a debugger is attached to a process, child processes shouldn't get debugged (resend)
by Dmitry Timoshkov 09 Oct '11

09 Oct '11

Bernhard Loos <bernhardloos(a)googlemail.com> wrote: > + int debug_childs:1; /* also debug all child processes */ 'debug_children' would be a better name. -- Dmitry.

4 3

The major mmdevapi and winmm audio bugs
by Joerg-Cyril.Hoehle＠t-systems.com 09 Oct '11

09 Oct '11

Hi, Bugzilla admins, please set the 1.4 milestone on all bugs mentioned here. I'm not yet looking at dsound issues since I first want a correct foundation upon which to build to upper layers. o #28039 IAudioClock_GetPosition must ignore underruns (MacOS) Here I've no idea how to solve this. My initial query remained unanswered: http://lists.apple.com/archives/coreaudio-api//2011/Sep/msg00024.html Ken? Andrew's yesterday patch (using GetCurrentPadding) is an interim work-around. GetPosition (speaker) is unrelated to padding which is solely about buffering. o #28093 GetCurrentPadding must slowly decrease (MacOS) may cause an app to play audio using a single buffer, causing underruns and audio drop outs. o #28056 Problems with sound under FreeBSD which became "blocking calls with OSS" recently addressed by Andrew. o snd_pcm_drop causes incorrect GetPosition after mmdevapi Stop which I believe to be the cause of: #27901 winmm tests timing out waiting for hevent after waveOutRestart May get solved by Andrew's work in: #28517 Pikachu Volleyball stops playing sound effects Every snd_pcm_drop and reset must be inspected with care w.r.t. its effect on GetPosition. Wine must ensure that after playing ends, GetPosition == sum of written samples for both mmdevapi and winmm. o #27937 winmm kept busy playing silence after play finishes IIRC because winmm writes silence. Once mmdevapi handles underruns correctly, my patch "winmm: Never write silence, mmdevapi must handle underruns." will become applicable: http://www.winehq.org/pipermail/wine-patches/2011-September/107108.html Playing silence causes: #28027 μ-law rendering with pauses and repetitions (MacOS) as well as presumably: #28413 Sound play in games and programs causes brief "pauses" at the time dsound used winmm prior to 1.3.29. o #28047 IAudioClock_GetPosition must not depend on buffering (ALSA/Pulse) ALSA must derive GetPosition from snd_pcm_delay, not snd_pcm_avail_update There are other issues not associated with a bug entry. I'm off for vacation, but here's a snippet from my TODO list: - OSS GetPosition from DSP_GETODELAY - ALSA+OSS: ReleaseBuffer: check method ordering and max size - GetStreamLatency = Xms + SHAREDMODE:period Stream latency is a static property of the audio graph's components. - wineoss GetStreamLatency must be constant, and SNDCTL_DSP_GETODELAY is only usable once running - Check WHDR_BEGIN/ENDLOOP code and write tests - WINMM_GetPosition is simply written_frames, not even minus padding (as the old alsa driver did), later use mmdevapi:GetPosition. - winmm PushData without IAC_Reset or last_clock_pos=0 in case of underrun - Investigate OSS4 underrun behaviour - Align wineOSS on newest ALSA code improvements - Submit CoreAudio memory leak fix to #28023; Write error handling patch - Check ALSA laptop suspend w.r.t. GetPosition - Add run-time consistency checks in renderer and abort audio stream (GetData) upon trouble instead of hanging. and finally: - Test compatibility with native DSound and file bug if unusable. There are several reports in bugzilla mentioning that this work-around ceased to work since 1.3.25. Loss of interoperability is not acceptable. Regards, Jörg Höhle

3 2

Re: [PATCH] server: Use syscall(2) instead of inline assembly on Mac OS, too.
by Alexandre Julliard 09 Oct '11

09 Oct '11

Charles Davis <cdavis(a)mymail.mines.edu> writes: > @@ -268,9 +256,9 @@ int send_thread_signal( struct thread *thread, int sig ) > if (!mach_port_extract_right( process_port, thread->unix_tid, > MACH_MSG_TYPE_COPY_SEND, &port, &type )) > { > - if ((ret = pthread_kill_syscall( port, sig )) < 0) > + if ((ret = syscall( SYS___pthread_kill, port, sig )) != 0) > { > - errno = -ret; > + errno = ret; syscall is supposed to take care of errno. -- Alexandre Julliard julliard(a)winehq.org

3 2

valgrind and buildbot
by Dan Kegel 09 Oct '11

09 Oct '11

As always, http://buildbot.kegel.com is just now starting to look stable (kind of like fusion power is always nearly practical). So I'm starting to look at adding valgrind to the buildbot. I won't check for memory leaks at all, since those are too numerous to count. And I'll only valgrind the tests immediately related to each proposed patch. First, though, I need a complete suppressions file for all existing wine valgrind warnings. That's going to take a while to put together, since some of the warnings don't show up on every run. And before I bother to automate anything, I'm taking a little detour, looking at the existing warnings, and trying to see if we can make a little progress on some of them. The script http://code.google.com/p/winezeug/source/browse/trunk/buildbot/runval.sh is how I'm starting to do a manual sweep for valgrind errors. I'm going DLL by DLL, starting with advapi32, looking carefully at each valgrind error. For each error that looks spurious or expected, I will add a suppression to the existing global suppressions file, http://code.google.com/p/winezeug/source/browse/trunk/valgrind/valgrind-sup… For each error that looks real, I'll try to understand it and fix it if the error is not deep, or file a wine bug and add a matching suppression to http://code.google.com/p/winezeug/source/browse/trunk/buildbot/valgrind-bla… When bugs get fixed, I'll remove the matching suppressions from that file. This morning I looked at a grand total of one valgrind warning (in advapi32/security.c), and filed http://bugs.winehq.org/show_bug.cgi?id=28628 for it. I did glance at a couple more; advapi32/crypt.c has a bunch of expected errors (which I'll probably add to valgrind-suppressions), and atl/atl_ax has a bunch of what look like real errors (which I'll probably file a bug for and add to valgrind-blacklist). It'll probably take quite a while to catalog the baseline errors and get a complete blacklist. If it takes too long (more than a few weeks), I'll chuck it and do a dumb blanket suppression of all existing warnings.

1 0

Palettized ddraw surface patches
by Stefan Dösinger 09 Oct '11

09 Oct '11

Hi, I'll start sending my patches for blitting palettized surfaces with opengl. There are quite a few patches and I won't send them all in one, so this mail shows where I am headed. Palettized surfaces are in a bad shape right now, both in terms of code quality and functionality. My patches will not fix all issues because this would require a shadow frontbuffer in wined3d, and Henri and I agreed that this should wait until after Wine 1.4. However, my patches fix a number of issues and eliminate a lot of dead code and hacks. Other work that needs to be done, but is separate from those patches: *) Emulate color keying in the ARBfp fragment pipeline. That way the upload- time color keying conversion can be limited to situations where shaders are not available and the alpha = 0.0 hack in patch 20 removed. *) Finish the blit infrastructure cleanup. Mainly, get rid of the hardcoded arbfp_blit backend in wined3d_surface_blt, get rid of arbfp_blit_surface and the remains of IWineD3DSurfaceImpl_BltOverride. *) Investigate if there's any point in P8 blitting with ATIfs and nvrc. The fixed function pipeline replacements would profit from proper 3D color keying, but that only works if we have blitters that can blit without color keying during texture upload. *) Make overlays work properly again. The overlay tests work, but the d3d7 sdk samples refuse to run for some reason. With the GL ddraw renderer as default we can also look into games like Settlers 3 that use overlays to draw the mouse pointer. @Henri and Matteo: The difference between this patchset and the one I sent you a few days ago is that my old patchset made onscreen surfaces as a whole a special case, while this one only has special handling for blits to onscreen surfaces. The new way needs less infrastructure changes, works better with palette changes and is a lot closer to how things should work with a shadow frontbuffer in wined3d. Stefan

1 0

Re: inetmib1: Avoid idempotent operation in findSupportedQuery function (Clang)
by Octavian Voicu 09 Oct '11

09 Oct '11

2011/10/2 Frédéric Delanoy <frederic.delanoy(a)gmail.com> > - for (i = (indexLow + indexHigh) / 2; !impl && indexLow <= indexHigh; > - i = (indexLow + indexHigh) / 2) > + for (i = indexHigh / 2; !impl && indexLow <= indexHigh; i = (indexLow + indexHigh) / 2) How about following code: while (!impl && indexLow <= indexHigh) { /* ... */ i = (indexLow + indexHigh) / 2; /* ... */ } Octavian

1 0

Re: jscript: Mark some fall-throughs in switch statements
by Alexandre Julliard 08 Oct '11

08 Oct '11

Andrew Talbot <andrew.talbot(a)talbotville.com> writes: > @@ -4037,6 +4037,7 @@ static HRESULT RegExpConstr_leftContext(script_ctx_t *ctx, vdisp_t *jsthis, WORD > > V_VT(retv) = VT_BSTR; > V_BSTR(retv) = ret; > + /* fall through */ > } > case DISPATCH_PROPERTYPUT: > return S_OK; I don't think that PROPERTYGET is supposed to fall through to PROPERTYPUT. -- Alexandre Julliard julliard(a)winehq.org

3 2

Re: trunk build
by Charles Davis 08 Oct '11

08 Oct '11

This can't be related to my syscall patch. On Oct 8, 2011, at 12:12 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/74 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) > BUILD FAILED: failed shell_3 > > Errors: > alarum: failed command was ../../../wine ddraw_test.exe.so visual.c > fixme:win:EnumDisplayDevicesW ((null),0,0x32f54c,0x00000000), stub! > fixme:d3d_draw:drawPrimitive Using software emulation because manual fog coordinates are provided > err:d3d:wined3d_device_uninit_3d Something is still holding a reference to depth/stencil buffer 0x15f090. > fixme:win:EnumDisplayDevicesW ((null),0,0x32f53c,0x00000000), stub! > visual.c:1903: Tests skipped: device has no P8 texture support, skipping test > fixme:ddraw:IDirect3DDeviceImpl_7_Release Texture handle 0x2 (0x1aff68) not unset properly. > fixme:win:EnumDisplayDevicesW ((null),0,0x32f47c,0x00000000), stub! > fixme:win:EnumDisplayDevicesW ((null),0,0x32ecbc,0x00000000), stub! > err:d3d_surface:d3dfmt_p8_init_palette This code should never get entered for DirectDraw!, expect problems > err:d3d_surface:d3dfmt_p8_init_palette This code should never get entered for DirectDraw!, expect problems > err:d3d_surface:d3dfmt_p8_init_palette This code should never get entered for DirectDraw!, expect problems > XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0" > after 1272 requests (1271 known processed) with 0 events remaining. > make: *** [visual.ok] Error 1 > alarum: failed command was ../../../wine ddrawex_test.exe.so surface.c > Application tried to create a window, but no driver could be loaded. > Make sure that your X server is running and that $DISPLAY is set correctly. > err:d3d_caps:WineD3D_CreateFakeGLContext Failed to create a window. > err:d3d:InitAdapters Failed to get a gl context for default adapter > err:ddraw:PixelFormat_WineD3DtoDD Can't translate this Pixelformat 0 > surface.c:87: Test failed: IDirectDraw_CreateSurface failed: 0x88760091 > wine: Unhandled page fault on read access to 0x00000000 at address 0x684b5510 (thread 003b), starting debugger... > Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x684b5510). > Register dump: > CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b > EIP:684b5510 ESP:0032fa40 EBP:0032fb68 EFLAGS:00210206( R- -- I - -P- ) > EAX:00000000 EBX:684bbff4 ECX:00000078 EDX:0032fae8 > ESI:0032fe38 EDI:00000000 > Stack dump: > 0x0032fa40: 0032fa6c 00000000 0000007c 40013497 > 0x0032fa50: 00000000 00004800 88760091 00124ce8 > 0x0032fa60: 0011ce9c 40027ff4 0032fb38 0000007c > 0x0032fa70: 00000000 00000000 00000000 00000000 > 0x0032fa80: 00000000 00000000 00000000 00000000 > 0x0032fa90: 00000000 00000000 00000000 00000000 > Backtrace: > =>0 0x684b5510 dctest_surf+0x69(surf=(nil), ddsdver=0x1) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ddrawex/tests/surface.c:54] in ddrawex_test (0x0032fb68) > 1 0x684b57ef GetDCTest_main+0xc3(ddsd=0x32fc54, ddsd2=0x32fbd8, testfunc=0x684b54a7) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ddrawex/tests/surface.c:88] in ddrawex_test (0x0032fbb8) > 2 0x684b5ce4 GetDCTest+0xc1() [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ddrawex/tests/surface.c:153] in ddrawex_test (0x0032fcc8) > 3 0x684b732c func_surface+0x1e0() [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ddrawex/tests/surface.c:436] in ddrawex_test (0x0032fcf8) > 4 0x684b8073 run_test+0x9e(name="surface.c") [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ddrawex/tests/../../../include/wine/test.h:556] in ddrawex_test (0x0032fd58) > 5 0x684b8488 main+0x23a(argc=<couldn't compute location>, argv=0x1103d0) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ddrawex/tests/../../../include/wine/test.h:624] in ddrawex_test (0x0032fe28) > 6 0x684b8516 __wine_spec_exe_entry+0x69(peb=0x7ffdf000) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/winecrt0/exe_entry.c:36] in ddrawex_test (0x0032fe60) > 7 0x7b85fe84 call_process_entry+0xb() in kernel32 (0x0032fe78) > 8 0x7b85ffca start_process+0x143(peb=0x7ffdf000) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/kernel32/process.c:1091] in kernel32 (0x0032fec8) > 9 0x7bc7c104 call_thread_func+0xb() in ntdll (0x0032fed8) > 10 0x7bc7c142 call_thread_entry_point+0x33(entry=0x7b85fe86, arg=0x7ffdf000) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ntdll/signal_i386.c:2499] in ntdll (0x0032ffb8) > 11 0x7bc53699 start_process+0x23(kernel_start=0x7b85fe86) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ntdll/loader.c:2612] in ntdll (0x0032ffe8) > 12 0x680280b9 wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) > 0x684b5510 dctest_surf+0x69 [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ddrawex/tests/surface.c:54] in ddrawex_test: movl 0x0(%eax),%eax > 54 hr = IDirectDrawSurface_GetDC(surf, &dc); > Modules: > Module Address Debug info Name (38 modules) > ELF 40000000-40029000 Deferred ddrawex<elf> > \-PE 40010000-40029000 \ ddrawex > ELF 40029000-40096000 Deferred ddraw<elf> > \-PE 40030000-40096000 \ ddraw > ELF 40096000-40201000 Deferred wined3d<elf> > \-PE 400a0000-40201000 \ wined3d > ELF 40201000-40355000 Deferred user32<elf> > \-PE 40210000-40355000 \ user32 > ELF 40355000-40370000 Deferred version<elf> > \-PE 40360000-40370000 \ version > ELF 4045f000-4046f000 Deferred libxext.so.6 > ELF 4046f000-4058c000 Deferred libx11.so.6 > ELF 40591000-405ab000 Deferred libxcb.so.1 > ELF 405ab000-405af000 Deferred libxau.so.6 > ELF 405af000-405b5000 Deferred libxdmcp.so.6 > ELF 68000000-6801d000 Deferred ld-linux.so.2 > ELF 6801f000-68160000 Dwarf libwine.so.1 > ELF 68172000-6818b000 Deferred libpthread.so.0 > ELF 6818b000-682e5000 Deferred libc.so.6 > ELF 682e6000-682ea000 Deferred libdl.so.2 > ELF 682eb000-68311000 Deferred libm.so.6 > ELF 68311000-68319000 Deferred libnss_compat.so.2 > ELF 68319000-68330000 Deferred libnsl.so.1 > ELF 68330000-6833a000 Deferred libnss_nis.so.2 > ELF 6833a000-68346000 Deferred libnss_files.so.2 > ELF 684a3000-684bd000 Dwarf ddrawex_test<elf> > \-PE 684b0000-684bd000 \ ddrawex_test > ELF 684bd000-68579000 Deferred gdi32<elf> > \-PE 684d0000-68579000 \ gdi32 > ELF 68579000-685df000 Deferred advapi32<elf> > \-PE 68590000-685df000 \ advapi32 > ELF 685f1000-68667000 Deferred libfreetype.so.6 > ELF 68667000-6867c000 Deferred libz.so.1 > ELF 7b800000-7b9b1000 Dwarf kernel32<elf> > \-PE 7b810000-7b9b1000 \ kernel32 > ELF 7bc00000-7bccd000 Dwarf ntdll<elf> > \-PE 7bc10000-7bccd000 \ ntdll > ELF 7bf00000-7bf04000 Deferred <wine-loader> > Threads: > process tid prio (all id:s are in hex) > 0000000e services.exe > 0000001f 0 > 0000001e 0 > 00000015 0 > 00000010 0 > 0000000f 0 > 00000012 winedevice.exe > 0000001a 0 > 00000019 0 > 00000014 0 > 00000013 0 > 0000001b plugplay.exe > 00000020 0 > 0000001d 0 > 0000001c 0 > 0000003d explorer.exe > 0000003e 0 > 0000003c (D) Z:\home\bob\wineslave.dir\sandbox\slave\runtests-default\build\dlls\ddrawex\tests\ddrawex_test.exe > 0000003b 0 <== > Backtrace: > =>0 0x684b5510 dctest_surf+0x69(surf=(nil), ddsdver=0x1) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ddrawex/tests/surface.c:54] in ddrawex_test (0x0032fb68) > 1 0x684b57ef GetDCTest_main+0xc3(ddsd=0x32fc54, ddsd2=0x32fbd8, testfunc=0x684b54a7) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ddrawex/tests/surface.c:88] in ddrawex_test (0x0032fbb8) > 2 0x684b5ce4 GetDCTest+0xc1() [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ddrawex/tests/surface.c:153] in ddrawex_test (0x0032fcc8) > 3 0x684b732c func_surface+0x1e0() [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ddrawex/tests/surface.c:436] in ddrawex_test (0x0032fcf8) > 4 0x684b8073 run_test+0x9e(name="surface.c") [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ddrawex/tests/../../../include/wine/test.h:556] in ddrawex_test (0x0032fd58) > 5 0x684b8488 main+0x23a(argc=<couldn't compute location>, argv=0x1103d0) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ddrawex/tests/../../../include/wine/test.h:624] in ddrawex_test (0x0032fe28) > 6 0x684b8516 __wine_spec_exe_entry+0x69(peb=0x7ffdf000) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/winecrt0/exe_entry.c:36] in ddrawex_test (0x0032fe60) > 7 0x7b85fe84 call_process_entry+0xb() in kernel32 (0x0032fe78) > 8 0x7b85ffca start_process+0x143(peb=0x7ffdf000) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/kernel32/process.c:1091] in kernel32 (0x0032fec8) > 9 0x7bc7c104 call_thread_func+0xb() in ntdll (0x0032fed8) > 10 0x7bc7c142 call_thread_entry_point+0x33(entry=0x7b85fe86, arg=0x7ffdf000) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ntdll/signal_i386.c:2499] in ntdll (0x0032ffb8) > 11 0x7bc53699 start_process+0x23(kernel_start=0x7b85fe86) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ntdll/loader.c:2612] in ntdll (0x0032ffe8) > 12 0x680280b9 wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) > make: *** [surface.ok] Error 5 > alarum: failed command was ../../../wine dinput_test.exe.so device.c > Application tried to create a window, but no driver could be loaded. > Make sure that your X server is running and that $DISPLAY is set correctly. > device.c:195: Test failed: err: 2 > make: *** [device.ok] Error 1 > alarum: failed command was ../../../wine dinput_test.exe.so keyboard.c > Application tried to create a window, but no driver could be loaded. > Make sure that your X server is running and that $DISPLAY is set correctly. > keyboard.c:174: Test failed: err: 2 > make: *** [keyboard.ok] Error 1 > alarum: failed command was ../../../wine dinput_test.exe.so mouse.c > Application tried to create a window, but no driver could be loaded. > Make sure that your X server is running and that $DISPLAY is set correctly. > mouse.c:140: Test failed: err: 2 > make: *** [mouse.ok] Error 1 > alarum: failed command was ../../../wine dinput8_test.exe.so device.c > fixme:dinput:IDirectInput8AImpl_EnumDevicesBySemantics (this=0x1251e8,(null),0x32fb84,0x684b59f4,0x32fb50,0000): semi-stub > fixme:dinput:_dump_diactionformatA diaf.dwSize = 328 > fixme:dinput:_dump_diactionformatA diaf.dwActionSize = 40 > fixme:dinput:_dump_diactionformatA diaf.dwDataSize = 20 > fixme:dinput:_dump_diactionformatA diaf.dwNumActions = 5 > fixme:dinput:_dump_diactionformatA diaf.rgoAction = 0x684bd400 > fixme:dinput:_dump_diactionformatA diaf.guidActionMap = {00000001-0002-0003-0405-060708090a0b} > fixme:dinput:_dump_diactionformatA diaf.dwGenre = 0x01000000 > fixme:dinput:_dump_diactionformatA diaf.dwBufferSize = 32 > fixme:dinput:_dump_diactionformatA diaf.lAxisMin = 0 > fixme:dinput:_dump_diactionformatA diaf.lAxisMax = 0 > fixme:dinput:_dump_diactionformatA diaf.hInstString = (nil) > fixme:dinput:_dump_diactionformatA diaf.ftTimeStamp ... > fixme:dinput:_dump_diactionformatA diaf.dwCRC = 0x0 > fixme:dinput:_dump_diactionformatA diaf.tszActionMap = "" > fixme:dinput:_dump_diactionformatA diaf.rgoAction[0]: > fixme:dinput:_dump_diactionformatA uAppData=0x0 > fixme:dinput:_dump_diactionformatA dwSemantic=0x01008a01 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Steer" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[1]: > fixme:dinput:_dump_diactionformatA uAppData=0x1 > fixme:dinput:_dump_diactionformatA dwSemantic=0x01000c01 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Upshift" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[2]: > fixme:dinput:_dump_diactionformatA uAppData=0x2 > fixme:dinput:_dump_diactionformatA dwSemantic=0x81000439 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Missile" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[3]: > fixme:dinput:_dump_diactionformatA uAppData=0x3 > fixme:dinput:_dump_diactionformatA dwSemantic=0x8200040c > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Select" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[4]: > fixme:dinput:_dump_diactionformatA uAppData=0x4 > fixme:dinput:_dump_diactionformatA dwSemantic=0x82000304 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Y Axis" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:IDirectInput8AImpl_EnumDevicesBySemantics (this=0x1251e8,(null),0x32fb84,0x684b59f4,0x32fb50,0100): semi-stub > fixme:dinput:IDirectInput8AImpl_EnumDevicesBySemantics dwFlags |= DIEDBSFL_FORCEFEEDBACK > fixme:dinput:_dump_diactionformatA diaf.dwSize = 328 > fixme:dinput:_dump_diactionformatA diaf.dwActionSize = 40 > fixme:dinput:_dump_diactionformatA diaf.dwDataSize = 20 > fixme:dinput:_dump_diactionformatA diaf.dwNumActions = 5 > fixme:dinput:_dump_diactionformatA diaf.rgoAction = 0x684bd400 > fixme:dinput:_dump_diactionformatA diaf.guidActionMap = {00000001-0002-0003-0405-060708090a0b} > fixme:dinput:_dump_diactionformatA diaf.dwGenre = 0x01000000 > fixme:dinput:_dump_diactionformatA diaf.dwBufferSize = 32 > fixme:dinput:_dump_diactionformatA diaf.lAxisMin = 0 > fixme:dinput:_dump_diactionformatA diaf.lAxisMax = 0 > fixme:dinput:_dump_diactionformatA diaf.hInstString = (nil) > fixme:dinput:_dump_diactionformatA diaf.ftTimeStamp ... > fixme:dinput:_dump_diactionformatA diaf.dwCRC = 0x0 > fixme:dinput:_dump_diactionformatA diaf.tszActionMap = "" > fixme:dinput:_dump_diactionformatA diaf.rgoAction[0]: > fixme:dinput:_dump_diactionformatA uAppData=0x0 > fixme:dinput:_dump_diactionformatA dwSemantic=0x01008a01 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Steer" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[1]: > fixme:dinput:_dump_diactionformatA uAppData=0x1 > fixme:dinput:_dump_diactionformatA dwSemantic=0x01000c01 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Upshift" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[2]: > fixme:dinput:_dump_diactionformatA uAppData=0x2 > fixme:dinput:_dump_diactionformatA dwSemantic=0x81000439 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Missile" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[3]: > fixme:dinput:_dump_diactionformatA uAppData=0x3 > fixme:dinput:_dump_diactionformatA dwSemantic=0x8200040c > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Select" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[4]: > fixme:dinput:_dump_diactionformatA uAppData=0x4 > fixme:dinput:_dump_diactionformatA dwSemantic=0x82000304 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Y Axis" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:IDirectInput8AImpl_EnumDevicesBySemantics (this=0x1251e8,(null),0x32fb84,0x684b59f4,0x32fb50,1000): semi-stub > fixme:dinput:IDirectInput8AImpl_EnumDevicesBySemantics dwFlags |= DIEDBSFL_AVAILABLEDEVICES > fixme:dinput:_dump_diactionformatA diaf.dwSize = 328 > fixme:dinput:_dump_diactionformatA diaf.dwActionSize = 40 > fixme:dinput:_dump_diactionformatA diaf.dwDataSize = 20 > fixme:dinput:_dump_diactionformatA diaf.dwNumActions = 5 > fixme:dinput:_dump_diactionformatA diaf.rgoAction = 0x684bd400 > fixme:dinput:_dump_diactionformatA diaf.guidActionMap = {00000001-0002-0003-0405-060708090a0b} > fixme:dinput:_dump_diactionformatA diaf.dwGenre = 0x01000000 > fixme:dinput:_dump_diactionformatA diaf.dwBufferSize = 32 > fixme:dinput:_dump_diactionformatA diaf.lAxisMin = 0 > fixme:dinput:_dump_diactionformatA diaf.lAxisMax = 0 > fixme:dinput:_dump_diactionformatA diaf.hInstString = (nil) > fixme:dinput:_dump_diactionformatA diaf.ftTimeStamp ... > fixme:dinput:_dump_diactionformatA diaf.dwCRC = 0x0 > fixme:dinput:_dump_diactionformatA diaf.tszActionMap = "" > fixme:dinput:_dump_diactionformatA diaf.rgoAction[0]: > fixme:dinput:_dump_diactionformatA uAppData=0x0 > fixme:dinput:_dump_diactionformatA dwSemantic=0x01008a01 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Steer" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[1]: > fixme:dinput:_dump_diactionformatA uAppData=0x1 > fixme:dinput:_dump_diactionformatA dwSemantic=0x01000c01 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Upshift" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[2]: > fixme:dinput:_dump_diactionformatA uAppData=0x2 > fixme:dinput:_dump_diactionformatA dwSemantic=0x81000439 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Missile" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[3]: > fixme:dinput:_dump_diactionformatA uAppData=0x3 > fixme:dinput:_dump_diactionformatA dwSemantic=0x8200040c > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Select" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[4]: > fixme:dinput:_dump_diactionformatA uAppData=0x4 > fixme:dinput:_dump_diactionformatA dwSemantic=0x82000304 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Y Axis" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:IDirectInput8AImpl_EnumDevicesBySemantics (this=0x1251e8,(null),0x32fb84,0x684b54fe,0x32fb64,0000): semi-stub > fixme:dinput:_dump_diactionformatA diaf.dwSize = 328 > fixme:dinput:_dump_diactionformatA diaf.dwActionSize = 40 > fixme:dinput:_dump_diactionformatA diaf.dwDataSize = 20 > fixme:dinput:_dump_diactionformatA diaf.dwNumActions = 5 > fixme:dinput:_dump_diactionformatA diaf.rgoAction = 0x684bd400 > fixme:dinput:_dump_diactionformatA diaf.guidActionMap = {00000001-0002-0003-0405-060708090a0b} > fixme:dinput:_dump_diactionformatA diaf.dwGenre = 0x01000000 > fixme:dinput:_dump_diactionformatA diaf.dwBufferSize = 32 > fixme:dinput:_dump_diactionformatA diaf.lAxisMin = 0 > fixme:dinput:_dump_diactionformatA diaf.lAxisMax = 0 > fixme:dinput:_dump_diactionformatA diaf.hInstString = (nil) > fixme:dinput:_dump_diactionformatA diaf.ftTimeStamp ... > fixme:dinput:_dump_diactionformatA diaf.dwCRC = 0x0 > fixme:dinput:_dump_diactionformatA diaf.tszActionMap = "" > fixme:dinput:_dump_diactionformatA diaf.rgoAction[0]: > fixme:dinput:_dump_diactionformatA uAppData=0x0 > fixme:dinput:_dump_diactionformatA dwSemantic=0x01008a01 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Steer" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[1]: > fixme:dinput:_dump_diactionformatA uAppData=0x1 > fixme:dinput:_dump_diactionformatA dwSemantic=0x01000c01 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Upshift" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[2]: > fixme:dinput:_dump_diactionformatA uAppData=0x2 > fixme:dinput:_dump_diactionformatA dwSemantic=0x81000439 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Missile" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[3]: > fixme:dinput:_dump_diactionformatA uAppData=0x3 > fixme:dinput:_dump_diactionformatA dwSemantic=0x8200040c > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Select" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[4]: > fixme:dinput:_dump_diactionformatA uAppData=0x4 > fixme:dinput:_dump_diactionformatA dwSemantic=0x82000304 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Y Axis" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:SysKeyboardWImpl_BuildActionMap (0x12b81c)->(0x32f570,(null),00000002): semi-stub ! > fixme:dinput:SysKeyboardWImpl_SetActionMap (0x12b81c)->(0x32f570,(null),00000000): semi-stub ! > fixme:dinput:SysMouseWImpl_BuildActionMap (0x12c9fc)->(0x32f570,(null),00000002): semi-stub ! > fixme:dinput:IDirectInputDevice8WImpl_BuildActionMap (0x12c9fc)->(0x32f570,(null),00000002): semi-stub ! > fixme:dinput:IDirectInputDevice8WImpl_BuildActionMap dwFlags =|DIDBAM_INITIALIZE > fixme:dinput:SysMouseWImpl_SetActionMap (0x12c9fc)->(0x32f570,(null),00000000): semi-stub ! > fixme:dinput:IDirectInputDevice8WImpl_SetActionMap (0x12c9fc)->(0x32f570,(null),00000000): semi-stub ! > fixme:dinput:SysMouseWImpl_SetActionMap (0x12c9fc)->(0x32f570,(null),00000000): semi-stub ! > fixme:dinput:IDirectInput8AImpl_EnumDevicesBySemantics (this=0x1251e8,(null),0x32fb84,0x684b59f4,0x32fb50,1000): semi-stub > fixme:dinput:IDirectInput8AImpl_EnumDevicesBySemantics dwFlags |= DIEDBSFL_AVAILABLEDEVICES > fixme:dinput:_dump_diactionformatA diaf.dwSize = 328 > fixme:dinput:_dump_diactionformatA diaf.dwActionSize = 40 > fixme:dinput:_dump_diactionformatA diaf.dwDataSize = 20 > fixme:dinput:_dump_diactionformatA diaf.dwNumActions = 5 > fixme:dinput:_dump_diactionformatA diaf.rgoAction = 0x684bd400 > fixme:dinput:_dump_diactionformatA diaf.guidActionMap = {00000001-0002-0003-0405-060708090a0b} > fixme:dinput:_dump_diactionformatA diaf.dwGenre = 0x01000000 > fixme:dinput:_dump_diactionformatA diaf.dwBufferSize = 32 > fixme:dinput:_dump_diactionformatA diaf.lAxisMin = 0 > fixme:dinput:_dump_diactionformatA diaf.lAxisMax = 0 > fixme:dinput:_dump_diactionformatA diaf.hInstString = (nil) > fixme:dinput:_dump_diactionformatA diaf.ftTimeStamp ... > fixme:dinput:_dump_diactionformatA diaf.dwCRC = 0x0 > fixme:dinput:_dump_diactionformatA diaf.tszActionMap = "" > fixme:dinput:_dump_diactionformatA diaf.rgoAction[0]: > fixme:dinput:_dump_diactionformatA uAppData=0x0 > fixme:dinput:_dump_diactionformatA dwSemantic=0x01008a01 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Steer" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[1]: > fixme:dinput:_dump_diactionformatA uAppData=0x1 > fixme:dinput:_dump_diactionformatA dwSemantic=0x01000c01 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Upshift" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[2]: > fixme:dinput:_dump_diactionformatA uAppData=0x2 > fixme:dinput:_dump_diactionformatA dwSemantic=0x81000439 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Missile" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[3]: > fixme:dinput:_dump_diactionformatA uAppData=0x3 > fixme:dinput:_dump_diactionformatA dwSemantic=0x8200040c > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Select" > fixme:dinput:_dump_diactionformatA guidInstance={6f1d2b60-d5a0-11cf-bfc7-444553540000} > fixme:dinput:_dump_diactionformatA dwObjID=0x304 > fixme:dinput:_dump_diactionformatA dwHow=0x20 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[4]: > fixme:dinput:_dump_diactionformatA uAppData=0x4 > fixme:dinput:_dump_diactionformatA dwSemantic=0x82000304 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Y Axis" > fixme:dinput:_dump_diactionformatA guidInstance={6f1d2b60-d5a0-11cf-bfc7-444553540000} > fixme:dinput:_dump_diactionformatA dwObjID=0x101 > fixme:dinput:_dump_diactionformatA dwHow=0x20 > fixme:dinput:SysKeyboardWImpl_BuildActionMap (0x12b81c)->(0x32f630,(null),00000002): semi-stub ! > device.c:120: Test failed: Action was not set dwHow=00000000 > device.c:121: Test failed: Action not mapped correctly instance=00000000 expected=00000039 > device.c:122: Test failed: Action type not mapped correctly type=00000000 expected=00000004 > device.c:123: Test failed: Action and device GUID do not match action=2 > device.c:74: Test failed: Failed to acquire device hr=80070057 > device.c:91: Test failed: Retrieval of action failed uAppData=0 expected=2 > fixme:dinput:SysKeyboardWImpl_BuildActionMap (0x12b81c)->(0x32f8d0,(null),00000002): semi-stub ! > fixme:dinput:SysKeyboardWImpl_SetActionMap (0x12b81c)->(0x32f8d0,(null),00000000): semi-stub ! > fixme:dinput:SysMouseWImpl_BuildActionMap (0x12c9fc)->(0x32f630,(null),00000002): semi-stub ! > fixme:dinput:IDirectInputDevice8WImpl_BuildActionMap (0x12c9fc)->(0x32f630,(null),00000002): semi-stub ! > fixme:dinput:IDirectInputDevice8WImpl_BuildActionMap dwFlags =|DIDBAM_INITIALIZE > fixme:dinput:SysMouseWImpl_BuildActionMap (0x12c9fc)->(0x32f630,(null),00000002): semi-stub ! > fixme:dinput:IDirectInputDevice8WImpl_BuildActionMap (0x12c9fc)->(0x32f630,(null),00000002): semi-stub ! > fixme:dinput:IDirectInputDevice8WImpl_BuildActionMap dwFlags =|DIDBAM_INITIALIZE > fixme:dinput:IDirectInput8AImpl_EnumDevicesBySemantics (this=0x1251e8,(null),0x32fb84,0x684b54fe,(nil),0000): semi-stub > fixme:dinput:_dump_diactionformatA diaf.dwSize = 328 > fixme:dinput:_dump_diactionformatA diaf.dwActionSize = 40 > fixme:dinput:_dump_diactionformatA diaf.dwDataSize = 20 > fixme:dinput:_dump_diactionformatA diaf.dwNumActions = 5 > fixme:dinput:_dump_diactionformatA diaf.rgoAction = 0x684bd400 > fixme:dinput:_dump_diactionformatA diaf.guidActionMap = {00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA diaf.dwGenre = 0x01000000 > fixme:dinput:_dump_diactionformatA diaf.dwBufferSize = 32 > fixme:dinput:_dump_diactionformatA diaf.lAxisMin = 0 > fixme:dinput:_dump_diactionformatA diaf.lAxisMax = 0 > fixme:dinput:_dump_diactionformatA diaf.hInstString = (nil) > fixme:dinput:_dump_diactionformatA diaf.ftTimeStamp ... > fixme:dinput:_dump_diactionformatA diaf.dwCRC = 0x0 > fixme:dinput:_dump_diactionformatA diaf.tszActionMap = "" > fixme:dinput:_dump_diactionformatA diaf.rgoAction[0]: > fixme:dinput:_dump_diactionformatA uAppData=0x0 > fixme:dinput:_dump_diactionformatA dwSemantic=0x01008a01 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Steer" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[1]: > fixme:dinput:_dump_diactionformatA uAppData=0x1 > fixme:dinput:_dump_diactionformatA dwSemantic=0x01000c01 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Upshift" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[2]: > fixme:dinput:_dump_diactionformatA uAppData=0x2 > fixme:dinput:_dump_diactionformatA dwSemantic=0x81000439 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Missile" > fixme:dinput:_dump_diactionformatA guidInstance={00000000-0000-0000-0000-000000000000} > fixme:dinput:_dump_diactionformatA dwObjID=0x0 > fixme:dinput:_dump_diactionformatA dwHow=0x0 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[3]: > fixme:dinput:_dump_diactionformatA uAppData=0x3 > fixme:dinput:_dump_diactionformatA dwSemantic=0x8200040c > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Select" > fixme:dinput:_dump_diactionformatA guidInstance={6f1d2b60-d5a0-11cf-bfc7-444553540000} > fixme:dinput:_dump_diactionformatA dwObjID=0x304 > fixme:dinput:_dump_diactionformatA dwHow=0x20 > fixme:dinput:_dump_diactionformatA diaf.rgoAction[4]: > fixme:dinput:_dump_diactionformatA uAppData=0x4 > fixme:dinput:_dump_diactionformatA dwSemantic=0x82000304 > fixme:dinput:_dump_diactionformatA dwFlags=0x0 > fixme:dinput:_dump_diactionformatA szActionName="Y Axis" > fixme:dinput:_dump_diactionformatA guidInstance={6f1d2b60-d5a0-11cf-bfc7-444553540000} > fixme:dinput:_dump_diactionformatA dwObjID=0x101 > fixme:dinput:_dump_diactionformatA dwHow=0x20 > make: *** [device.ok] Error 6 > alarum: failed command was ../../../wine dsound_test.exe.so capture.c > XOpenDisplay() failed > fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels > fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels > fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels > fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels > fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels > fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels > fixme:ole:CoCreateInstance no instance created for interface {11ab3ec0-25ec-11d1-a4d8-00c04fc28aca} of class {b0210780-89cd-11d0-af08-00a0c925cd16}, hres is 0x80004002 > ALSA lib pcm_direct.c:1117:(snd1_pcm_direct_initialize_poll_fd) unable to open timer 'hw:CLASS=3,SCLASS=0,CARD=0,DEV=0,SUBDEV=1' > ALSA lib pcm_dsnoop.c:662:(snd_pcm_dsnoop_open) unable to initialize poll_fd > capture.c:618: Test failed: Should not fail for 8 or 16 bits per sample > ALSA lib confmisc.c:768:(parse_card) cannot find card '0' > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib pcm.c:2211:(snd_pcm_open_noupdate) Unknown PCM default > ALSA lib confmisc.c:768:(parse_card) cannot find card '0' > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib pcm.c:2211:(snd_pcm_open_noupdate) Unknown PCM default > ALSA lib confmisc.c:768:(parse_card) cannot find card '0' > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib pcm.c:2211:(snd_pcm_open_noupdate) Unknown PCM default > ALSA lib confmisc.c:768:(parse_card) cannot find card '0' > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib pcm.c:2211:(snd_pcm_open_noupdate) Unknown PCM default > ALSA lib confmisc.c:768:(parse_card) cannot find card '0' > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib pcm.c:2211:(snd_pcm_open_noupdate) Unknown PCM default > ALSA lib pcm_hw.c:1401:(_snd_pcm_hw_open) Invalid value for card > make: *** [capture.ok] Error 1 > alarum: failed command was ../../../wine dsound_test.exe.so duplex.c > fixme:ole:CoCreateInstance no instance created for interface {11ab3ec0-25ec-11d1-a4d8-00c04fc28aca} of class {fea4300c-7959-4147-b26a-2377b9e7a91d}, hres is 0x80004002 > XOpenDisplay() failed > ALSA lib confmisc.c:768:(parse_card) cannot find card '0' > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib pcm.c:2211:(snd_pcm_open_noupdate) Unknown PCM default > ALSA lib confmisc.c:768:(parse_card) cannot find card '0' > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib confmisc.c:1251:(snd_func_refer) error evaluating name > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib pcm.c:2211:(snd_pcm_open_noupdate) Unknown PCM default > duplex.c:187: Test failed: DirectSoundFullDuplexCreate(NULL,NULL) failed: 80070057 > duplex.c:197: Test failed: DirectSoundFullDuplexCreate(DSDEVID_DefaultCapture,DSDEVID_DefaultPlayback) failed: 80070057 > duplex.c:208: Test failed: DirectSoundFullDuplexCreate(DSDEVID_DefaultVoiceCapture,DSDEVID_DefaultVoicePlayback) failed: 80070057 > make: *** [duplex.ok] Error 3 > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > alarum: failed command was ../../../wine gdi32_test.exe.so clipping.c > Application tried to create a window, but no driver could be loaded. > Make sure that your X server is running and that $DISPLAY is set correctly. > clipping.c:35: Test failed: CreateWindow failed > clipping.c:115: Test failed: GetRandomRgn 0,0 - 0,0 > clipping.c:435: Test failed: expected SIMPLEREGION, got 1 > clipping.c:441: Test failed: expected SIMPLEREGION, got 1 > clipping.c:442: Test failed: expected 0,0-640,480, got 0,0-0,0 > make: *** [clipping.ok] Error 5 > alarum: failed command was ../../../wine gdi32_test.exe.so dc.c > Application tried to create a window, but no driver could be loaded. > Make sure that your X server is running and that $DISPLAY is set correctly. > dc.c:66: test_savedc_2: Assertion `hwnd != 0' failed. > wine: Assertion failed at address 0x68000832 (thread 0032), starting debugger... > Unhandled exception: assertion failed in 32-bit code (0x68000832). > Register dump: > CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b > EIP:68000832 ESP:0032fa8c EBP:0032fa98 EFLAGS:00200202( - -- I - - - ) > EAX:00000000 EBX:0000356b ECX:0000356b EDX:00000006 > ESI:682bc8df EDI:682e0ff4 > Stack dump: > 0x0032fa8c: 681b5651 682e0ff4 0032fbb8 0032fbc0 > 0x0032fa9c: 681b8a82 00000006 0032fb38 00000000 > 0x0032faac: 0032fae0 681fbf9d 00000068 00000040 > 0x0032fabc: 0032fbd0 0032fafc 00000068 00000040 > 0x0032facc: 00000037 7caf9570 682e0ff4 00000037 > 0x0032fadc: 00000036 0032fba8 681eb182 7caf9578 > Backtrace: > =>0 0x68000832 GLIBC_2+0x832() in ld-linux.so.2 (0x0032fa98) > 1 0x681b8a82 abort+0x181() in libc.so.6 (0x0032fbc0) > 2 0x681ae718 __assert_fail+0xf7() in libc.so.6 (0x0032fc08) > 3 0x684dfce4 test_savedc_2+0xb4() [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/tests/dc.c:66] in gdi32_test (0x0032fcd8) > 4 0x684e4510 func_dc+0x47() [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/tests/dc.c:790] in gdi32_test (0x0032fcf8) > 5 0x68520bd7 run_test+0x9e(name="dc.c") [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/tests/../../../include/wine/test.h:556] in gdi32_test (0x0032fd58) > 6 0x68520fec main+0x23a(argc=<couldn't compute location>, argv=0x1103c8) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/tests/../../../include/wine/test.h:624] in gdi32_test (0x0032fe28) > 7 0x6852107a __wine_spec_exe_entry+0x69(peb=0x7ffdf000) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/winecrt0/exe_entry.c:36] in gdi32_test (0x0032fe60) > 8 0x7b85fe84 call_process_entry+0xb() in kernel32 (0x0032fe78) > 9 0x7b85ffca start_process+0x143(peb=0x7ffdf000) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/kernel32/process.c:1091] in kernel32 (0x0032fec8) > 10 0x7bc7c104 call_thread_func+0xb() in ntdll (0x0032fed8) > 11 0x7bc7c142 call_thread_entry_point+0x33(entry=0x7b85fe86, arg=0x7ffdf000) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ntdll/signal_i386.c:2499] in ntdll (0x0032ffb8) > 12 0x7bc53699 start_process+0x23(kernel_start=0x7b85fe86) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ntdll/loader.c:2612] in ntdll (0x0032ffe8) > 13 0x680280b9 wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) > 0x68000832 GLIBC_2+0x832 in ld-linux.so.2: ret > Modules: > Module Address Debug info Name (32 modules) > ELF 68000000-6801d000 Dwarf ld-linux.so.2 > ELF 6801f000-68160000 Dwarf libwine.so.1 > ELF 68172000-6818b000 Deferred libpthread.so.0 > ELF 6818b000-682e5000 Dwarf libc.so.6 > ELF 682e6000-682ea000 Deferred libdl.so.2 > ELF 682eb000-68311000 Deferred libm.so.6 > ELF 68311000-68319000 Deferred libnss_compat.so.2 > ELF 68319000-68330000 Deferred libnsl.so.1 > ELF 68330000-6833a000 Deferred libnss_nis.so.2 > ELF 6833a000-68346000 Deferred libnss_files.so.2 > ELF 684a3000-6853b000 Dwarf gdi32_test<elf> > \-PE 684b0000-6853b000 \ gdi32_test > ELF 6853b000-6868f000 Deferred user32<elf> > \-PE 68550000-6868f000 \ user32 > ELF 6868f000-6874b000 Deferred gdi32<elf> > \-PE 686a0000-6874b000 \ gdi32 > ELF 6874b000-687b1000 Deferred advapi32<elf> > \-PE 68760000-687b1000 \ advapi32 > ELF 687b1000-687cc000 Deferred version<elf> > \-PE 687c0000-687cc000 \ version > ELF 687de000-68854000 Deferred libfreetype.so.6 > ELF 68854000-68869000 Deferred libz.so.1 > ELF 68946000-68956000 Deferred libxext.so.6 > ELF 68956000-68a73000 Deferred libx11.so.6 > ELF 68a78000-68a92000 Deferred libxcb.so.1 > ELF 68a92000-68a96000 Deferred libxau.so.6 > ELF 68a96000-68a9c000 Deferred libxdmcp.so.6 > ELF 7b800000-7b9b1000 Dwarf kernel32<elf> > \-PE 7b810000-7b9b1000 \ kernel32 > ELF 7bc00000-7bccd000 Dwarf ntdll<elf> > \-PE 7bc10000-7bccd000 \ ntdll > ELF 7bf00000-7bf04000 Deferred <wine-loader> > Threads: > process tid prio (all id:s are in hex) > 0000000e services.exe > 0000001f 0 > 0000001e 0 > 00000015 0 > 00000010 0 > 0000000f 0 > 00000012 winedevice.exe > 0000001a 0 > 00000019 0 > 00000014 0 > 00000013 0 > 0000001b plugplay.exe > 00000020 0 > 0000001d 0 > 0000001c 0 > 0000003d explorer.exe > 0000003e 0 > 0000002f (D) Z:\home\bob\wineslave.dir\sandbox\slave\runtests-default\build\dlls\gdi32\tests\gdi32_test.exe > 00000032 0 <== > Backtrace: > =>0 0x68000832 GLIBC_2+0x832() in ld-linux.so.2 (0x0032fa98) > 1 0x681b8a82 abort+0x181() in libc.so.6 (0x0032fbc0) > 2 0x681ae718 __assert_fail+0xf7() in libc.so.6 (0x0032fc08) > 3 0x684dfce4 test_savedc_2+0xb4() [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/tests/dc.c:66] in gdi32_test (0x0032fcd8) > 4 0x684e4510 func_dc+0x47() [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/tests/dc.c:790] in gdi32_test (0x0032fcf8) > 5 0x68520bd7 run_test+0x9e(name="dc.c") [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/tests/../../../include/wine/test.h:556] in gdi32_test (0x0032fd58) > 6 0x68520fec main+0x23a(argc=<couldn't compute location>, argv=0x1103c8) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/tests/../../../include/wine/test.h:624] in gdi32_test (0x0032fe28) > 7 0x6852107a __wine_spec_exe_entry+0x69(peb=0x7ffdf000) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/winecrt0/exe_entry.c:36] in gdi32_test (0x0032fe60) > 8 0x7b85fe84 call_process_entry+0xb() in kernel32 (0x0032fe78) > 9 0x7b85ffca start_process+0x143(peb=0x7ffdf000) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/kernel32/process.c:1091] in kernel32 (0x0032fec8) > 10 0x7bc7c104 call_thread_func+0xb() in ntdll (0x0032fed8) > 11 0x7bc7c142 call_thread_entry_point+0x33(entry=0x7b85fe86, arg=0x7ffdf000) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ntdll/signal_i386.c:2499] in ntdll (0x0032ffb8) > 12 0x7bc53699 start_process+0x23(kernel_start=0x7b85fe86) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ntdll/loader.c:2612] in ntdll (0x0032ffe8) > 13 0x680280b9 wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) > alarum: ../../../wine terminated abnormally > make: *** [dc.ok] Error 99 > alarum: failed command was ../../../wine gdi32_test.exe.so font.c > font.c:279: Test failed: tm.tmDescent should be > 0 > font.c:291: Test failed: height 2288: expected scale_x 1, scale_y 1, got cx -2375535, cy -938585 > font.c:293: Test failed: height -2147483648 != 2288 > font.c:294: Test failed: ascent -2147483648 != 1854 > font.c:295: Test failed: descent -2147483648 != 434 > font.c:296: Test failed: ave width -2147483648 != 904 > font.c:297: Test failed: max width -2147483648 != 5515 > font.c:310: Test failed: cx -2147483648 != 9902 > font.c:311: Test failed: cy -2147483648 != 2288 > font.c:315: Test failed: width A -2147483648 != 1366 > font.c:610: Test failed: incX 0 != -2147483648 > font.c:620: Test failed: incX -32768 != -1073741823 > font.c:621: Test failed: incY -32768 != 0 > Application tried to create a window, but no driver could be loaded. > Make sure that your X server is running and that $DISPLAY is set correctly. > font.c:3543: Tests skipped: Unable to locate and load font sserife.fon > font.c:2249: Tests skipped: Font KacstOne doesn't contain 'x', skipping the test > font.c:2249: Tests skipped: Font Kedage doesn't contain 'x', skipping the test > font.c:2249: Tests skipped: Font Lohit Bengali doesn't contain 'x', skipping the test > font.c:2249: Tests skipped: Font Lohit Gujarati doesn't contain 'x', skipping the test > font.c:2249: Tests skipped: Font Lohit Hindi doesn't contain 'x', skipping the test > font.c:2249: Tests skipped: Font Lohit Punjabi doesn't contain 'x', skipping the test > font.c:2249: Tests skipped: Font Lohit Tamil doesn't contain 'x', skipping the test > font.c:2249: Tests skipped: Font Mallige doesn't contain 'x', skipping the test > font.c:2249: Tests skipped: Font OpenSymbol doesn't contain 'x', skipping the test > font.c:2249: Tests skipped: Font Pothana2000 doesn't contain 'x', skipping the test > font.c:2249: Tests skipped: Font Purisa doesn't contain 'x', skipping the test > font.c:2249: Tests skipped: Font Saab doesn't contain 'x', skipping the test > font.c:2249: Tests skipped: Font UnBatang doesn't contain 'x', skipping the test > font.c:2249: Tests skipped: Font UnDotum doesn't contain 'x', skipping the test > font.c:2249: Tests skipped: Font utkal doesn't contain 'x', skipping the test > font.c:2249: Tests skipped: Font Vemana2000 doesn't contain 'x', skipping the test > fixme:font:WineEngRealizationInfo (0x11ecb0, 0x32fc70): stub! > fixme:font:WineEngRealizationInfo (0x12b8e8, 0x32fc70): stub! > fixme:font:WineEngCreateFontInstance Untranslated charset 255 > font.c:3786: Tests skipped: Lucida Sans Demibold Roman is not installed > font.c:3786: Tests skipped: Lucida Sans Italic is not installed > font.c:3786: Tests skipped: Lucida Sans Regular is not installed > fixme:font:CreateScalableFontResourceW (0,L"C:\\users\\bob\\Temp\\fotedc.tmp",L"C:\\users\\bob\\Temp\\ttfedb.tmp",(null)): stub > fixme:font:CreateScalableFontResourceW (0,L"C:\\users\\bob\\Temp\\fotedc.tmp",L"C:\\users\\bob\\Temp\\ttfedb.tmp",L""): stub > fixme:font:CreateScalableFontResourceW (0,L"C:\\users\\bob\\Temp\\fotedc.tmp",L"\\ttfedb.tmp",L"C:\\users\\bob\\Temp\\"): stub > fixme:font:CreateScalableFontResourceW (0,L"C:\\users\\bob\\Temp\\fotedc.tmp",L"random file name",L"C:\\users\\bob\\Temp\\"): stub > fixme:font:CreateScalableFontResourceW (0,L"C:\\users\\bob\\Temp\\fotedc.tmp",(null),L"C:\\users\\bob\\Temp\\ttfedb.tmp"): stub > fixme:font:WineEngRemoveFontResourceEx (L"C:\\users\\bob\\Temp\\fotedc.tmp", 0, (nil)): stub > make: *** [font.ok] Error 13 > alarum: failed command was ../../../wine gdi32_test.exe.so gdiobj.c > gdiobj.c:173: Test failed: GetDeviceCaps(TECHNOLOGY) should return DT_RASDISPLAY not 0 > make: *** [gdiobj.ok] Error 1 > alarum: failed command was ../../../wine gdi32_test.exe.so icm.c > icm.c:64: Test failed: expected size > 0 > icm.c:66: Test failed: got -559038737, expected ERROR_INSUFFICIENT_BUFFER > icm.c:73: Test failed: GetICMProfileA failed -559038737 > icm.c:116: Test failed: expected size > 0 > icm.c:117: Test failed: got -559038737, expected ERROR_INSUFFICIENT_BUFFER > icm.c:121: Test failed: GetICMProfileW failed -559038737 > fixme:icm:SetICMProfileA (nil) (null) stub > icm.c:229: Test failed: GetICMProfileA failed 87 > fixme:icm:SetICMProfileA (nil) (null) stub > fixme:icm:SetICMProfileA (nil) "\xf8\xfb2" stub > fixme:icm:SetICMProfileA 0x1b8 (null) stub > fixme:icm:SetICMProfileA 0x1b8 "\xf8\xfb2" stub > fixme:icm:SetICMProfileW (nil) (null) stub > icm.c:272: Test failed: GetICMProfileW failed 87 > fixme:icm:SetICMProfileW (nil) (null) stub > fixme:icm:SetICMProfileW (nil) L"\0017" stub > fixme:icm:SetICMProfileW 0x1b8 (null) stub > fixme:icm:SetICMProfileW 0x1b8 L"\0017" stub > make: *** [icm.ok] Error 8 > alarum: failed command was ../../../wine gdi32_test.exe.so mapping.c > mapping.c:454: Test failed: Viewport extents have not been properly adjusted: Expected 6400x-4800, got 6400x-2147483648 > mapping.c:428: Test failed: Viewport extents have not been properly adjusted: Expected 6400x-4800, got 6400x-2147483648 > mapping.c:428: Test failed: Viewport extents have not been properly adjusted: Expected 6400x-2400, got 6400x-2147483648 > mapping.c:428: Test failed: Viewport extents have not been properly adjusted: Expected 3200x-2400, got 6400x-2147483648 > mapping.c:454: Test failed: Viewport extents have not been properly adjusted: Expected 1280x-960, got 2560x-2147483648 > mapping.c:454: Test failed: Viewport extents have not been properly adjusted: Expected 1280x-960, got 2560x-2147483648 > mapping.c:428: Test failed: Viewport extents have not been properly adjusted: Expected 1280x-480, got 2560x-2147483648 > mapping.c:428: Test failed: Viewport extents have not been properly adjusted: Expected -640x480, got -1280x-2147483648 > mapping.c:614: Test failed: 663: got inf expect inf > mapping.c:617: Test failed: 663: got -inf expect -inf > mapping.c:618: Test failed: 663: got -nan expect 0.000000 > mapping.c:619: Test failed: 663: got -nan expect 0.000000 > mapping.c:614: Test failed: 667: got inf expect inf > mapping.c:615: Test failed: 667: got -nan expect 0.000000 > mapping.c:616: Test failed: 667: got -nan expect 0.000000 > mapping.c:617: Test failed: 667: got -inf expect -inf > mapping.c:618: Test failed: 667: got -nan expect 0.000000 > mapping.c:619: Test failed: 667: got -nan expect 0.000000 > mapping.c:614: Test failed: 673: got -nan expect 0.000000 > mapping.c:615: Test failed: 673: got nan expect 0.000000 > mapping.c:616: Test failed: 673: got nan expect 0.000000 > mapping.c:617: Test failed: 673: got -nan expect -0.000000 > mapping.c:618: Test failed: 673: got nan expect 0.000000 > mapping.c:619: Test failed: 673: got nan expect 0.000000 > mapping.c:614: Test failed: 689: got inf expect inf > mapping.c:617: Test failed: 689: got -inf expect -inf > mapping.c:618: Test failed: 689: got -nan expect 0.000000 > mapping.c:619: Test failed: 689: got -nan expect 0.000000 > mapping.c:614: Test failed: 695: got inf expect inf > mapping.c:615: Test failed: 695: got -nan expect 0.000000 > mapping.c:616: Test failed: 695: got -nan expect 0.000000 > mapping.c:617: Test failed: 695: got -inf expect -inf > mapping.c:618: Test failed: 695: got -nan expect 0.000000 > mapping.c:619: Test failed: 695: got -nan expect 0.000000 > mapping.c:614: Test failed: 701: got -nan expect 0.000000 > mapping.c:615: Test failed: 701: got nan expect 0.000000 > mapping.c:616: Test failed: 701: got nan expect 0.000000 > mapping.c:617: Test failed: 701: got -nan expect -0.000000 > mapping.c:618: Test failed: 701: got nan expect 0.000000 > mapping.c:619: Test failed: 701: got nan expect 0.000000 > fixme:dc:GetTransform Unknown code 102 > fixme:dc:GetTransform Unknown code 103 > fixme:dc:GetTransform Unknown code 104 > fixme:dc:GetTransform Unknown code 202 > fixme:dc:GetTransform Unknown code 302 > fixme:dc:GetTransform Unknown code 303 > fixme:dc:GetTransform Unknown code 403 > fixme:dc:GetTransform Unknown code 404 > fixme:dc:GetTransform Unknown code ffff > make: *** [mapping.ok] Error 40 > alarum: failed command was ../../../wine gdi32_test.exe.so metafile.c > Application tried to create a window, but no driver could be loaded. > Make sure that your X server is running and that $DISPLAY is set correctly. > metafile.c:174: Test failed: CreateWindowExA error 2 > metafile.c:209: Test failed: GetDeviceCaps(TECHNOLOGY) has to return DT_RASDISPLAY for a display based EMF > metafile.c:318: Test failed: CreateWindowExA failed > metafile.c:327: Test failed: GetDeviceCaps failed > metafile.c:293: Test failed: Got exScale -nan, expected -nan > metafile.c:295: Test failed: Got eyScale -nan, expected -nan > metafile.c:293: Test failed: Got exScale -nan, expected -nan > metafile.c:295: Test failed: Got eyScale -nan, expected -nan > metafile.c:293: Test failed: Got exScale -nan, expected -nan > metafile.c:295: Test failed: Got eyScale -nan, expected -nan > metafile.c:293: Test failed: Got exScale -nan, expected -nan > metafile.c:295: Test failed: Got eyScale -nan, expected -nan > metafile.c:293: Test failed: Got exScale -nan, expected -nan > metafile.c:295: Test failed: Got eyScale -nan, expected -nan > metafile.c:641: Test failed: CreateWindowExA error 5 > metafile.c:2161: Test failed: CreateWindowExA error 13 > metafile.c:2398: Test failed: CreateWindowExA error -559038737 > err:enhmetafile:EMF_Update_MF_Xform World transform failed! > err:enhmetafile:EMF_Update_MF_Xform World transform failed! > err:enhmetafile:EMF_Update_MF_Xform World transform failed! > err:enhmetafile:EMF_Update_MF_Xform World transform failed! > err:enhmetafile:EMF_Update_MF_Xform World transform failed! > err:enhmetafile:EMF_Update_MF_Xform World transform failed! > metafile.c:2460: Test failed: (0,0)->(10,10), expected (0,0)->(0,0) > err:enhmetafile:EMF_Update_MF_Xform World transform failed! > err:enhmetafile:EMF_Update_MF_Xform World transform failed! > err:enhmetafile:EMF_Update_MF_Xform World transform failed! > err:enhmetafile:EMF_Update_MF_Xform World transform failed! > err:enhmetafile:EMF_Update_MF_Xform World transform failed! > err:enhmetafile:EMF_Update_MF_Xform World transform failed! > metafile.c:2460: Test failed: (0,0)->(10,10), expected (0,0)->(18,67) > metafile.c:2460: Test failed: (0,0)->(10,10), expected (0,0)->(18,67) > metafile.c:2713: Test failed: SetWinMetaFileBits: Reference bounds: Left and top bound must be zero > metafile.c:2724: Test failed: SetWinMetaFileBits (MM_ISOTROPIC): Reference bounds are not isotropic > metafile.c:2747: Test succeeded inside todo block: SetWinMetaFileBits (MM_ANISOTROPIC): Reference frame: The whole device surface must be used (0x0), but got (0x0) > metafile.c:2781: Test failed: SetWinMetaFileBits (MM_ANISOTROPIC): rclBounds contains invalid values > wine: Unhandled division by zero at address 0x68721d5b (thread 0026), starting debugger... > Unhandled exception: divide by zero in 32-bit code (0x68721d5b). > Register dump: > CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b > EIP:68721d5b ESP:0032f970 EBP:0032f998 EFLAGS:00210246( R- -- I Z- -P- ) > EAX:00000001 EBX:68735ff4 ECX:00000000 EDX:00000000 > ESI:00000000 EDI:00000000 > Stack dump: > 0x0032f970: 0000034c 68735ff4 0032f998 68701559 > 0x0032f980: 68739e40 00000000 000ea600 00000000 > 0x0032f990: 00000000 00000000 0032fa08 6870861e > 0x0032f9a0: 000ea600 00000000 00000000 00000000 > 0x0032f9b0: 00000026 00000000 000ea600 00000000 > 0x0032f9c0: ffffffff 00132194 00132194 00000000 > Backtrace: > =>0 0x68721d5b __divdi3+0x8b() in gdi32 (0x0032f998) > 1 0x6870861e muldiv+0x8a(m1=0x7d0, m2=0x1e0, d=0) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/metafile.c:1234] in gdi32 (0x0032fa08) > 2 0x687087d8 set_window+0xde(hdc=0x6c4, emf=0x6c0, ref_dc=0x34c, map_mode=0x1) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/metafile.c:1269] in gdi32 (0x0032fac8) > 3 0x68708b3b GetWinMetaFileBits+0xfa(hemf=0x6c0, cbBuffer=0, lpbBuffer=0x0(nil), map_mode=0x1, hdcRef=0x34c) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/metafile.c:1325] in gdi32 (0x0032fb48) > 4 0x6851848a getwinmetafilebits+0x3f3(mode=0x1, scale=0x1, rc=0x32fc28) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/tests/metafile.c:2869] in gdi32_test (0x0032fbf8) > 5 0x68519287 test_GetWinMetaFileBits+0xd7() [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/tests/metafile.c:3007] in gdi32_test (0x0032fce8) > 6 0x68519bca func_metafile+0x64() [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/tests/metafile.c:3140] in gdi32_test (0x0032fcf8) > 7 0x68520bd7 run_test+0x9e(name="metafile.c") [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/tests/../../../include/wine/test.h:556] in gdi32_test (0x0032fd58) > 8 0x68520fec main+0x23a(argc=<couldn't compute location>, argv=0x1103d0) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/tests/../../../include/wine/test.h:624] in gdi32_test (0x0032fe28) > 9 0x6852107a __wine_spec_exe_entry+0x69(peb=0x7ffdf000) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/winecrt0/exe_entry.c:36] in gdi32_test (0x0032fe60) > 10 0x7b85fe84 call_process_entry+0xb() in kernel32 (0x0032fe78) > 11 0x7b85ffca start_process+0x143(peb=0x7ffdf000) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/kernel32/process.c:1091] in kernel32 (0x0032fec8) > 12 0x7bc7c104 call_thread_func+0xb() in ntdll (0x0032fed8) > 13 0x7bc7c142 call_thread_entry_point+0x33(entry=0x7b85fe86, arg=0x7ffdf000) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ntdll/signal_i386.c:2499] in ntdll (0x0032ffb8) > 14 0x7bc53699 start_process+0x23(kernel_start=0x7b85fe86) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ntdll/loader.c:2612] in ntdll (0x0032ffe8) > 15 0x680280b9 wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) > 0x68721d5b __divdi3+0x8b in gdi32: divl %esi,%eax > Modules: > Module Address Debug info Name (32 modules) > ELF 68000000-6801d000 Deferred ld-linux.so.2 > ELF 6801f000-68160000 Dwarf libwine.so.1 > ELF 68172000-6818b000 Deferred libpthread.so.0 > ELF 6818b000-682e5000 Deferred libc.so.6 > ELF 682e6000-682ea000 Deferred libdl.so.2 > ELF 682eb000-68311000 Deferred libm.so.6 > ELF 68311000-68319000 Deferred libnss_compat.so.2 > ELF 68319000-68330000 Deferred libnsl.so.1 > ELF 68330000-6833a000 Deferred libnss_nis.so.2 > ELF 6833a000-68346000 Deferred libnss_files.so.2 > ELF 684a3000-6853b000 Dwarf gdi32_test<elf> > \-PE 684b0000-6853b000 \ gdi32_test > ELF 6853b000-6868f000 Deferred user32<elf> > \-PE 68550000-6868f000 \ user32 > ELF 6868f000-6874b000 Dwarf gdi32<elf> > \-PE 686a0000-6874b000 \ gdi32 > ELF 6874b000-687b1000 Deferred advapi32<elf> > \-PE 68760000-687b1000 \ advapi32 > ELF 687b1000-687cc000 Deferred version<elf> > \-PE 687c0000-687cc000 \ version > ELF 687de000-68854000 Deferred libfreetype.so.6 > ELF 68854000-68869000 Deferred libz.so.1 > ELF 68946000-68956000 Deferred libxext.so.6 > ELF 68956000-68a73000 Deferred libx11.so.6 > ELF 68a78000-68a92000 Deferred libxcb.so.1 > ELF 68a92000-68a96000 Deferred libxau.so.6 > ELF 68a96000-68a9c000 Deferred libxdmcp.so.6 > ELF 7b800000-7b9b1000 Dwarf kernel32<elf> > \-PE 7b810000-7b9b1000 \ kernel32 > ELF 7bc00000-7bccd000 Dwarf ntdll<elf> > \-PE 7bc10000-7bccd000 \ ntdll > ELF 7bf00000-7bf04000 Deferred <wine-loader> > Threads: > process tid prio (all id:s are in hex) > 0000000e services.exe > 0000001f 0 > 0000001e 0 > 00000015 0 > 00000010 0 > 0000000f 0 > 00000012 winedevice.exe > 0000001a 0 > 00000019 0 > 00000014 0 > 00000013 0 > 0000001b plugplay.exe > 00000020 0 > 0000001d 0 > 0000001c 0 > 0000003d explorer.exe > 0000003e 0 > 00000009 (D) Z:\home\bob\wineslave.dir\sandbox\slave\runtests-default\build\dlls\gdi32\tests\gdi32_test.exe > 00000026 0 <== > Backtrace: > =>0 0x68721d5b __divdi3+0x8b() in gdi32 (0x0032f998) > 1 0x6870861e muldiv+0x8a(m1=0x7d0, m2=0x1e0, d=0) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/metafile.c:1234] in gdi32 (0x0032fa08) > 2 0x687087d8 set_window+0xde(hdc=0x6c4, emf=0x6c0, ref_dc=0x34c, map_mode=0x1) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/metafile.c:1269] in gdi32 (0x0032fac8) > 3 0x68708b3b GetWinMetaFileBits+0xfa(hemf=0x6c0, cbBuffer=0, lpbBuffer=0x0(nil), map_mode=0x1, hdcRef=0x34c) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/metafile.c:1325] in gdi32 (0x0032fb48) > 4 0x6851848a getwinmetafilebits+0x3f3(mode=0x1, scale=0x1, rc=0x32fc28) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/tests/metafile.c:2869] in gdi32_test (0x0032fbf8) > 5 0x68519287 test_GetWinMetaFileBits+0xd7() [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/tests/metafile.c:3007] in gdi32_test (0x0032fce8) > 6 0x68519bca func_metafile+0x64() [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/tests/metafile.c:3140] in gdi32_test (0x0032fcf8) > 7 0x68520bd7 run_test+0x9e(name="metafile.c") [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/tests/../../../include/wine/test.h:556] in gdi32_test (0x0032fd58) > 8 0x68520fec main+0x23a(argc=<couldn't compute location>, argv=0x1103d0) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/gdi32/tests/../../../include/wine/test.h:624] in gdi32_test (0x0032fe28) > 9 0x6852107a __wine_spec_exe_entry+0x69(peb=0x7ffdf000) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/winecrt0/exe_entry.c:36] in gdi32_test (0x0032fe60) > 10 0x7b85fe84 call_process_entry+0xb() in kernel32 (0x0032fe78) > 11 0x7b85ffca start_process+0x143(peb=0x7ffdf000) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/kernel32/process.c:1091] in kernel32 (0x0032fec8) > 12 0x7bc7c104 call_thread_func+0xb() in ntdll (0x0032fed8) > 13 0x7bc7c142 call_thread_entry_point+0x33(entry=0x7b85fe86, arg=0x7ffdf000) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ntdll/signal_i386.c:2499] in ntdll (0x0032ffb8) > 14 0x7bc53699 start_process+0x23(kernel_start=0x7b85fe86) [/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/ntdll/loader.c:2612] in ntdll (0x0032ffe8) > 15 0x680280b9 wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) > make: *** [metafile.ok] Error 148 > alarum: failed command was ../../../wine gdi32_test.exe.so palette.c > palette.c:90: Test failed: getColor=00000000 > palette.c:97: Test failed: getColor=00000000 > palette.c:112: Test failed: getColor=00000000 > make: *** [palette.ok] Error 3 > alarum: failed command was ../../../wine gdi32_test.exe.so pen.c > fixme:gdi:ExtCreatePen PS_COSMETIC | PS_USERSTYLE not handled > fixme:gdi:ExtCreatePen PS_COSMETIC | PS_USERSTYLE not handled > pen.c:505: Test failed: Expected 00000080, got 00000000 > pen.c:506: Test failed: Expected 00000080, got 00000000 > pen.c:507: Test failed: Expected 000000a0, got 00000000 > pen.c:508: Test failed: Expected 000000a0, got 00000000 > pen.c:509: Test failed: Expected 00000050, got 00000000 > pen.c:510: Test failed: Expected 00000050, got 00000000 > pen.c:511: Test failed: Expected 0000000a, got 00000000 > make: *** [pen.ok] Error 7 > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > * Call to xpconnect wrapped JSObject produced this error: * > * Call to xpconnect wrapped JSObject produced this error: * > alarum: failed command was ../../../wine opengl32_test.exe.so opengl.c > Xlib: extension "GLX" missing on display ":0.0". > err:wgl:X11DRV_WineGL_InitOpenglInfo couldn't initialize OpenGL, expect problems > opengl.c:1295: Test failed: Unable to find pixel format. > fixme:event:wait_for_withdrawn_state window 0x2300d2/800001 wait timed out > make: *** [opengl.ok] Error 1 > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > alarum: failed command was ../../../wine user32_test.exe.so sysparams.c > sysparams.c:2399: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out > sysparams.c:2399: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out > err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found 800x600x24 @0! (XRandR) > sysparams.c:2404: Tests skipped: Setting depth 24 failed(ret = -2) > sysparams.c:2399: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out > sysparams.c:2412: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1 > make: *** [sysparams.ok] Error 4 > alarum: failed command was ../../../wine shell32_test.exe.so ebrowser.c > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (1, 0, 0, 0, 0x32fcb8) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1026, a003, 1, 0x32fcb8) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (1, 0, 0, 0, (nil)) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (3, 0, 0, 0, (nil)) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (8, 0, 0, 0, (nil)) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (1, 0, 0, 0, (nil)) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 0, 0, 0, 0x32fcb8) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (1, 0, 0, 0, 0x32fcb8) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (1234, 0, 0, 0, 0x32fcb8) > fixme:shell:IShellBrowser_fnSetStatusTextSB stub, 0x12d030 ((null)) > fixme:shell:IShellBrowser_fnContextSensitiveHelp stub, 0x12d030 (0) > fixme:shell:IShellBrowser_fnEnableModelessSB stub, 0x12d030 (1) > fixme:shell:IShellBrowser_fnSetToolbarItems stub, 0x12d030 ((nil), 1, 0x1) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1026, a003, 0, 0x32f9fc) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1026, a004, 1, 0x32f9fc) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1025, a003, 1, 0x32f9fc) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1025, a004, 1, 0x32f9fc) > fixme:win:DeferWindowPos other process handle 0xdeadbeef? > fixme:shell:IExplorerBrowser_fnSetOptions Flags 0xdeadbeef contains unsupported options. > fixme:nstc:NSTC2_fnSetControlStyle2 mask & style (0x00000004) contains unsupported style(s): 0x00000004 > fixme:shell:IExplorerBrowser_fnSetPropertyBag stub, 0x12d030 ((null)) > fixme:shell:IExplorerBrowser_fnSetPropertyBag stub, 0x12d030 (L"WineTest") > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1026, a003, 0, 0x32f9ec) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1026, a004, 1, 0x32f9ec) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1025, a003, 1, 0x32f9ec) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1025, a004, 1, 0x32f9ec) > err:shell:IExplorerBrowser_fnBrowseToIDList Failed to get absolute pidl. > err:shell:IExplorerBrowser_fnBrowseToIDList Failed to get absolute pidl. > err:shell:IExplorerBrowser_fnBrowseToIDList Failed to get absolute pidl. > err:shell:IExplorerBrowser_fnBrowseToIDList Failed to get absolute pidl. > err:shell:IExplorerBrowser_fnBrowseToIDList Failed to get parent pidl. > err:shell:IExplorerBrowser_fnBrowseToIDList Failed to get parent pidl. > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1026, a003, 0, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1026, a004, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1025, a003, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1025, a004, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1026, a003, 0, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1026, a004, 1, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1025, a003, 1, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1025, a004, 1, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1026, a003, 0, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1026, a004, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1025, a003, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1025, a004, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1026, a003, 0, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1026, a004, 1, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1025, a003, 1, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1025, a004, 1, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1026, a003, 0, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1026, a004, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1025, a003, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1025, a004, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1026, a003, 0, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1026, a004, 1, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1025, a003, 1, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1025, a004, 1, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1026, a003, 0, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1026, a004, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1025, a003, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1025, a004, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1026, a003, 0, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1026, a004, 1, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1025, a003, 1, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1025, a004, 1, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1026, a003, 0, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1026, a004, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1025, a003, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1025, a004, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1026, a003, 0, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1026, a004, 1, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1025, a003, 1, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1025, a004, 1, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1026, a003, 0, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1026, a004, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1025, a003, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12d030 (2, 1025, a004, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1026, a003, 0, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1026, a004, 1, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1025, a003, 1, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1025, a004, 1, 0x32f56c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1026, a003, 0, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1026, a004, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1025, a003, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1025, a004, 1, 0x32f5ac) > fixme:shell:IExplorerBrowser_fnSetOptions Flags 0x00000004 contains unsupported options. > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1026, a003, 0, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1026, a004, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1025, a003, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1025, a004, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1026, a003, 0, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1026, a004, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1025, a003, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12f388 (2, 1025, a004, 1, 0x32f5ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12e808 (2, 1026, a003, 0, 0x32fa0c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12e808 (2, 1026, a004, 1, 0x32fa0c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12e808 (2, 1025, a003, 1, 0x32fa0c) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12e808 (2, 1025, a004, 1, 0x32fa0c) > fixme:nstc:NSTC2_fnSetControlStyle2 mask & style (0x00000004) contains unsupported style(s): 0x00000004 > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12e808 (2, 1026, a003, 0, 0x32f7ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12e808 (2, 1026, a004, 1, 0x32f7ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12e808 (2, 1025, a003, 1, 0x32f7ac) > fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x12e808 (2, 1025, a004, 1, 0x32f7ac) > XIO: fatal IO error 104 (Connection reset by peer) on X server ":0.0" > after 2790 requests (1173 known processed) with 0 events remaining. > make: *** [ebrowser.ok] Error 1 > alarum: failed command was ../../../wine shell32_test.exe.so shlexec.c > fixme:exec:SHELL_execute flags ignored: 0x00004000 > fixme:exec:SHELL_execute flags ignored: 0x00004000 > fixme:exec:SHELL_execute flags ignored: 0x00004000 > fixme:exec:SHELL_execute flags ignored: 0x00004000 > fixme:exec:SHELL_execute flags ignored: 0x00004000 > fixme:exec:SHELL_execute flags ignored: 0x00004000 > fixme:exec:SHELL_execute flags ignored: 0x00004000 > fixme:exec:SHELL_execute flags ignored: 0x00000100 > fixme:exec:SHELL_execute flags ignored: 0x00000100 > fixme:exec:SHELL_execute flags ignored: 0x00000100 > Application tried to create a window, but no driver could be loaded. > Make sure that your X server is running and that $DISPLAY is set correctly. > Application tried to create a window, but no driver could be loaded. > Make sure that your X server is running and that $DISPLAY is set correctly. > shlexec.c:1767: Test failed: ShellExecuteEx(null, "C:\users\bob\Temp\wt1ff9.tmp\test file.sde", null, null) failed: rc=30 err=32 > fixme:exec:SHELL_execute flags ignored: 0x00000100 > shlexec.c:1767: Test failed: ShellExecuteEx(null, "C:\users\bob\Temp\wt1ff9.tmp\test file.sde", null, null) failed: rc=30 err=0 > fixme:exec:SHELL_execute flags ignored: 0x00000100 > shlexec.c:1767: Test failed: ShellExecuteEx(null, "C:\users\bob\Temp\wt1ff9.tmp\test file.sde", null, null) failed: rc=30 err=32 > fixme:exec:SHELL_execute flags ignored: 0x00000100 > shlexec.c:1767: Test failed: ShellExecuteEx(null, "C:\users\bob\Temp\wt1ff9.tmp\test file.sde", null, null) failed: rc=30 err=0 > fixme:exec:SHELL_execute flags ignored: 0x00000100 > shlexec.c:1767: Test failed: ShellExecuteEx(null, "C:\users\bob\Temp\wt1ff9.tmp\test file.sde", null, null) failed: rc=30 err=32 > fixme:exec:SHELL_execute flags ignored: 0x00000100 > shlexec.c:1767: Test failed: ShellExecuteEx(null, "C:\users\bob\Temp\wt1ff9.tmp\test file.sde", null, null) failed: rc=30 err=0 > fixme:exec:SHELL_execute flags ignored: 0x00000100 > shlexec.c:1946: Tests skipped: Default DDE application test does not match any available results, using first expected data set. > shlexec.c:1951: Test failed: ShellExecuteEx(null, "C:\users\bob\Temp\wt1ff9.tmp\test file.sde", null, null) failed: rc=11 err=87 > fixme:exec:SHELL_execute flags ignored: 0x00000100 > shlexec.c:1951: Test failed: ShellExecuteEx(null, "C:\users\bob\Temp\wt1ff9.tmp\test file.sde", null, null) failed: rc=11 err=87 > fixme:exec:SHELL_execute flags ignored: 0x00000100 > shlexec.c:1951: Test failed: ShellExecuteEx(null, "C:\users\bob\Temp\wt1ff9.tmp\test file.sde", null, null) failed: rc=11 err=87 > fixme:exec:SHELL_execute flags ignored: 0x00000100 > shlexec.c:1951: Test failed: ShellExecuteEx(null, "C:\users\bob\Temp\wt1ff9.tmp\test file.sde", null, null) failed: rc=11 err=87 > fixme:exec:SHELL_execute flags ignored: 0x00000100 > shlexec.c:1951: Test failed: ShellExecuteEx(null, "C:\users\bob\Temp\wt1ff9.tmp\test file.sde", null, null) failed: rc=11 err=87 > fixme:exec:SHELL_execute flags ignored: 0x00000100 > shlexec.c:1951: Test failed: ShellExecuteEx(null, "C:\users\bob\Temp\wt1ff9.tmp\test file.sde", null, null) failed: rc=11 err=87 > fixme:exec:SHELL_execute flags ignored: 0x00000100 > err:exec:dde_connect Unable to find application path for command L"\"C:\\users\\bob\\Temp\\wt1ff9.tmp\\test2 file.exe\"" > fixme:exec:SHELL_execute flags ignored: 0x00000100 > err:exec:dde_connect Unable to find application path for command L"\"C:\\users\\bob\\Temp\\wt1ff9.tmp\\test2 file.exe\" param" > fixme:exec:SHELL_execute flags ignored: 0x00000100 > shlexec.c:1951: Test failed: ShellExecuteEx(null, "C:\users\bob\Temp\wt1ff9.tmp\test file.sde", null, null) failed: rc=11 err=87 > fixme:exec:SHELL_execute flags ignored: 0x00000100 > shlexec.c:1951: Test failed: ShellExecuteEx(null, "C:\users\bob\Temp\wt1ff9.tmp\test file.sde", null, null) failed: rc=11 err=87 > fixme:exec:SHELL_execute flags ignored: 0x00000100 > err:exec:dde_connect Unable to find application path for command L"C:\\users\\bob\\Temp\\wt1ff9.tmp\\notexist.exe" > fixme:exec:SHELL_execute flags ignored: 0x00000100 > err:exec:dde_connect Unable to find application path for command L"C:\\users\\bob\\Temp\\wt1ff9.tmp\\notexist.exe param" > fixme:exec:SHELL_execute flags ignored: 0x00000100 > shlexec.c:1951: Test failed: ShellExecuteEx(null, "C:\users\bob\Temp\wt1ff9.tmp\test file.sde", null, null) failed: rc=30 err=87 > fixme:exec:SHELL_execute flags ignored: 0x00000100 > shlexec.c:1951: Test failed: ShellExecuteEx(null, "C:\users\bob\Temp\wt1ff9.tmp\test file.sde", null, null) failed: rc=30 err=87 > fixme:exec:SHELL_execute flags ignored: 0x00000100 > err:exec:dde_connect Unable to find application path for command L"xyzwxyzwxyz" > fixme:exec:SHELL_execute flags ignored: 0x00000100 > err:exec:dde_connect Unable to find application path for command L"xyzwxyzwxyz param" > CMD Version 1.3.29 > > Z:\home\bob\wineslave.dir\sandbox\slave\runtests-default\build\dlls\shell32\tests>CMD Version 1.3.29 > > Z:\home\bob\wineslave.dir\sandbox\slave\runtests-default\build\dlls\shell32\tests>alarum: elapsed time 96 seconds > make: *** [shlexec.ok] Error 16 > alarum: failed command was ../../../wine shell32_test.exe.so systray.c > systray.c:52: Test failed: NIM_DELETE failed! > systray.c:55: Test failed: The icon was not deleted > systray.c:66: Test failed: NIM_ADD failed! > systray.c:73: Test failed: NIM_DELETE failed! > systray.c:76: Test failed: The icon was not deleted > fixme:event:wait_for_withdrawn_state window 0x160076/c00001 wait timed out > make: *** [systray.ok] Error 5 > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory > ALSA lib conf.c:4154:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory > ALSA lib conf.c:4633:(snd_config_expand) Evaluate error: No such file or directory > > _______________________________________________ > wine-tests-results mailing list > wine-tests-results(a)winehq.org > http://www.winehq.org/mailman/listinfo/wine-tests-results

1 0

Re: inetmib1: Avoid idempotent operation in findSupportedQuery function (Clang)
by Alexandre Julliard 08 Oct '11

08 Oct '11

Frédéric Delanoy <frederic.delanoy(a)gmail.com> writes: > indexLow is always 0 at that point This makes it harder to understand what the code is doing here. Probably needs some restructuring. -- Alexandre Julliard julliard(a)winehq.org

1 0

re: Governance of Wine with respect to the Software Freedom Conservancy (update October 2011)
by Dan Kegel 08 Oct '11

08 Oct '11

The real way to mount a revolt, of course, would be to fork wine and maintain a better version of it. The likelihood of that ever happening seems slim, but perhaps in 15 years, after HTML 5 takes over and users no longer run win32 apps, it's possible that something like that would happen naturally (say, some computer museum might become the maintainer).

1 0

Re: mpr: Remove DllCanUnloadNow and DllGetClassObject
by André Hentschel 08 Oct '11

08 Oct '11

Am 08.10.2011 12:13, schrieb Alistair Leslie-Hughes: > Hi, > The native mpr.DLL doesn't have these functions. > > > Changelog: > mpr: Remove DllCanUnloadNow and DllGetClassObject > > > Best Regards > Alistair Leslie-Hughes > > no patch? -- Best Regards, André Hentschel

1 0

Re: user32: Add support for iPaddedBorderWidth in NONCLIENTMETRICS structure.
by Marvin 08 Oct '11

08 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=14764 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

Re: [PATCH] server: Use syscall(2) instead of inline assembly on Mac OS; too.
by Dan Kegel 07 Oct '11

07 Oct '11

Fails tests on x86_64? On Fri, Oct 7, 2011 at 11:52 AM, <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-x86_64 while building Wine. > Full details are available at: http://buildbot.kegel.com/builders/runtests-default-x86_64/builds/35 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) > BUILD FAILED: failed shell_3 > > Errors: > alarum: failed command was ../../../wine rpcrt4_test.exe.so rpc.c > fixme:rpc:RpcNetworkIsProtseqValidW Unknown protseq L"foo" > err:rpc:rpcrt4_protseq_ncacn_ip_tcp_open_endpoint couldn't listen on port 4114 > rpc.c:238: Test failed: RpcServerUseProtseqEp failed (1740) > fixme:rpc:RpcBindingInqAuthInfoExW authorization service not implemented > make: *** [rpc.ok] Error 1 > >

2 2

Solved: Problems with drawing text in 1.3.29
by Damian Dixon 07 Oct '11

07 Oct '11

I have narrowed the issue down to a difference in behaviour between Windows and Wine. The problem boils down to the following code: NONCLIENTMETRICS ncm; memset(&ncm, 0, sizeof(NONCLIENTMETRICS)); ncm.cbSize = sizeof(NONCLIENTMETRICS); VERIFY(SystemParametersInfo(SPI_GETNONCLIENTMETRICS, sizeof(NONCLIENTMETRICS), &ncm, 0)); I used the font's returned from this call for drawing text and this caused the crash. The problem is that I upgraded to VS2010 and changed the target to WINVER=0x600. This means that I needed to change my code to the following. NONCLIENTMETRICS ncm; memset(&ncm, 0, sizeof(NONCLIENTMETRICS)); ncm.cbSize = sizeof(NONCLIENTMETRICS); #if(WINVER >= 0x0600) OSVERSIONINFO osvi; memset(&osvi,0,sizeof(osvi)); osvi.dwOSVersionInfoSize = sizeof(osvi); GetVersionEx(&osvi); if (osvi.dwMajorVersion < 6) ncm.cbSize -= sizeof(ncm.iPaddedBorderWidth); #endif VERIFY(SystemParametersInfo(SPI_GETNONCLIENTMETRICS, sizeof(NONCLIENTMETRICS), &ncm, 0)); Note: On windows my application does not actually crash or stop working with my original code and the text is displayed at a size I would kind of expect it to be. I will raise a bug for this one... as a difference in behaviour. On 7 October 2011 08:50, Damian Dixon <damian.dixon(a)gmail.com> wrote: > Thanks for the suggestions. > > I've narrowed one of the issues down to WineEngGetGlyphOutline > in dlls/gdi32/freetype.c. > > The pitch is 6640 and the height is 53003. This means that a buffer of > ~335Mb has been allocated and then memset. > > This is where the slow down is occurring (because of the memset). I suspect > the resultant crash is also because of this. > > I would suggest that limits need to be placed on the maximum pitch and > height. > > > I do not however believe that this is the root cause just one of the > symptoms. > > > > On 5 October 2011 18:37, Marcus Meissner <marcus(a)jet.franken.de> wrote: > >> On Wed, Oct 05, 2011 at 04:53:18PM +0100, Damian Dixon wrote: >> > Hi, >> > >> > I was attempting to use Wine 1.3.29 (in OpenSUSE 11.4 x86) and because >> of >> > issues pulled the source from git last night and still have problems. >> > >> > I am having performance issues with DrawText (5 odd seconds to draw a >> simple >> > string) and the occasional X Error and crash. >> > >> > The X Error is consistent and is as follows: >> > >> > fixme:advapi:SetSecurityInfo stub >> > X Error of failed request: BadLength (poly request too large or >> internal >> > Xlib length error) >> > Major opcode of failed request: 151 (RENDER) >> > Minor opcode of failed request: 17 (RenderCreateGlyphSet) >> > Serial number of failed request: 41091 >> > Current serial number in output stream: 41571 >> > Process of pid=0023 has terminated >> > >> > >> > The crash less consistent but is dependent upon the amount of text I >> attempt >> > to draw. >> > >> > The last version I know this worked in was 1.1.39. >> > >> > I've a few things to still try out before I attempt to create an RBT. >> >> To get a backtrace and be able to dump some datastructures, run with >> >> WINEDEBUG=+synchronous wine foo.exe >> >> This will bring it into the debugger once the condition happens. >> >> CIao, MArcus >> > >

1 0

Governance of Wine with respect to the Software Freedom Conservancy (update October 2011)
by Jeremy White 07 Oct '11

07 Oct '11

Hi Folks, I try to send out a periodic message to the wine-devel mailing list outlining the 'corporate' structure of Wine and how some decisions are made. We work with the Software Freedom Conservancy. They manage the pieces of Wine that benefit from a formal organization, such as managing money, holding Trademarks, and so on. The primary activity we have conducted with them over the past several years is managing money - about $3,000 each year. They manage all funds donated to Wine - the donate button goes into a bank account they manage and any larger private donations go there as well. For decisions on how to spend funds, we've adopted a loose set of guidelines. That is, we have a decision group and we require a majority of members to approve any spending. Alexandre and I are the current members of that group. We also claim the right to appoint anyone else to replace or augment the decision group. We CC all decisions to an auditor. We have recently asked Michael Stefanuic to replace Zachary Goldberg in that role. A critical requirement, we feel, is that a non CodeWeavers staff member be fully aware of all decisions made. We choose this strategy rather than a fully public process so that we can apply discretion and protect privacy of people that ask for help with travel funding. The SFC will recognize a 'revolt' by the Wine project. That is, the designated decision group can be overthrown, once you figure out our evil plans, if the SFC is persuaded that the majority of Wine contributors agree on that point. Patch count in the Wine tree will be the primary mechanism to recognize a contributor. Finally, all spending by the SFC on Wine's behalf for the last few years has been related to Wineconf. That has primarily been to help defray travel costs for Wine contributors to come to Wineconf. Wine's income has been around $3,000 / year for the past few years; we tend to spend down much of the balance each year for Wineconf. Cheers, Jeremy p.s. One note - the SFC also manages the GSOC payments, although I believe that they ostensibly manage that on behalf of Google, not really Wine. That is generally coordinated by Wine's GSOC coordinator, and Alexandre and I have nothing to do with it.

3 4

Wine Gecko 1.4-beta1
by Jacek Caban 07 Oct '11

07 Oct '11

Hi all, I've just uploaded new Gecko builds [1]. To use it, you need the attached patch and the build installed to the right place [2]. As usually, everything that uses MSHTML is worth testing. All testing and feedback will be appreciated. Thanks, Jacek [1] http://sourceforge.net/projects/wine/files/Wine%20Gecko/1.4-beta1/ [2] http://wiki.winehq.org/Gecko

2 3

Re: mshtml: Implement IHTMLDOMNode replaceChild
by Jacek Caban 07 Oct '11

07 Oct '11

Hi Alistair, On 10/7/11 4:50 AM, Alistair Leslie-Hughes wrote: > + HTMLDOMNode *nodeNew; > + HTMLDOMNode *nodeOld; Please use names consistent with the rest of the file. + if(NS_FAILED(nsres)) { + nsnode = nodeNew->nsnode; + } That seems questionable, why do you pretend to success on failure? Jacek

1 0

Re: [2/5] urlmon: Improved MapUrlToZone{Ex2} and GetSecurityId support
by Jacek Caban 07 Oct '11

07 Oct '11

Hi Thomas, On 10/6/11 6:42 PM, Thomas Mullaly wrote: > --- > dlls/urlmon/sec_mgr.c | 41 +++++++++++++++++++++++++++++++++++++++-- > dlls/urlmon/tests/sec_mgr.c | 30 +++++++++++++++++++++++++++++- > 2 files changed, 68 insertions(+), 3 deletions(-) + if(hres == S_FALSE){ + DWORD scheme_type; + BOOL has_host; + + hres = IUri_GetScheme(uri,&scheme_type); + if(FAILED(hres)) { + SysFreeString(scheme); + return hres; + } + + hres = IUri_HasProperty(uri, Uri_PROPERTY_HOST,&has_host); + if(FAILED(hres)) { + SysFreeString(scheme); + return hres; + } + + /* Known hierarchical scheme types must have a host. If they don't Windows + * assigns URLZONE_INVALID to the zone. + */ + if((scheme_type != URL_SCHEME_UNKNOWN&& scheme_type != URL_SCHEME_FILE) +&& is_hierarchical_scheme(scheme_type)&& !has_host) { + *zone = URLZONE_INVALID; It looks like get_zone_from_domains would be more logical place for this. It already does GetScheme call and you could just handle differently GetHost returning empty host. if(FAILED(hres)) return hres == 0x80041001 ? E_INVALIDARG : hres; + else if(zone == URLZONE_INVALID) + return E_INVALIDARG; You don't need 'else' here since if the previous if expression is true, we return anyways. Jacek

1 0

Re: mmdevapi/tests: Add format tests.
by Andrew Eikum 07 Oct '11

07 Oct '11

Hi J�rg, Thanks for adding these tests. It would have been nicer to split the patch up into discrete chunks. That would make the patch much easier to review. Overall it looks pretty good. Some remarks follow... > BTW, I've not touched > render.c:223: Test failed: IsFormatSupported(0xffffffff) call returns 8889000e > capture.ok has a similar random failure. I believe that test is bogus. It > should avoid ending up calling the exclusive mode "audio endpoint" and hope/show > that the shared mode mixer aka. "audio engine" reports E_INVALIDARG. Perhaps > using ~AUDCLNT_SHAREMODE_EXCLUSIVE is a means to enforce this, even though > that's actually an enum, not a flag. Yeah, that's a pretty uninteresting test. If it's flaky, I don't see any compelling reason to keep it around. > + unk = (void*)0xDEADF00D; > hr = IAudioClient_GetService(ac, &IID_IAudioStreamVolume, (void**)&unk); > ok(hr == AUDCLNT_E_NOT_INITIALIZED, "Uninitialized GetService call returns %08x\n", hr); > + todo_wine ok(broken(unk != NULL), "GetService %08x &out pointer %p\n", hr, unk); This test is strange. broken() basically means "should fail on Windows, should not fail in Wine." It's used when some particular version of Windows does something unexpected which we are uninterested in duplicating. Do you expect unk to always be non-NULL? If so, then just test for that without the broken() macro. > > +static void test_formats(AUDCLNT_SHAREMODE mode) The code in this function is very difficult to follow. I wonder if it couldn't be written more clearly with explicit conditions and a bit more code duplication. > + ok((hr == S_FALSE)^(pwfx2 == NULL), "hr %x<->suggest %p\n", hr, pwfx2); > + if (pwfx2 == (WAVEFORMATEX*)0xDEADF00D) /* bug in Wine */ > + pwfx2 = NULL; Would be nicer to both fix the bug in Wine and have a test showing the correct behavior. > @@ -1378,7 +1535,7 @@ START_TEST(render) > hr = CoCreateInstance(&CLSID_MMDeviceEnumerator, NULL, CLSCTX_INPROC_SERVER, &IID_IMMDeviceEnumerator, (void**)&mme); > if (FAILED(hr)) > { > - skip("mmdevapi not available: 0x%08x\n", hr); > + win_skip("mmdevapi not available: 0x%08x\n", hr); If the user has an invalid driver, CoCreateInstance() will fail to create the enumerator object. I think that's valid behavior, so we shouldn't fail. Andrew

3 3

DLLCanUnloadNow Question
by Alistair Leslie-Hughes 07 Oct '11

07 Oct '11

Hi, The Following sample code causes a crash under WINE, but not in windows. IUnknown *p LoadLibrary("mscoree.dll") GetProcAddress("CreateDebuggingInterfaceFromVersion") CreateDebuggingInterfaceFromVersion(..., (void**)&p) <-- Com Reference FreeLibrary("mscoree.dll") p->QueryInterface(....); <-- Cause Crash under WINE. The DLL shouldn't be unloaded since mscoree.DLLCanUnloadNow() return S_FALSE; Is this a bug with the unloading of DLL's? Is there way to stop the unloading of a DLL? I know the logic isn't the best, but I'm seeing this type of behavior in an application. Best Regards Alistair Leslie-Hughes

2 1

Problems with drawing text in 1.3.29
by Damian Dixon 07 Oct '11

07 Oct '11

Hi, I was attempting to use Wine 1.3.29 (in OpenSUSE 11.4 x86) and because of issues pulled the source from git last night and still have problems. I am having performance issues with DrawText (5 odd seconds to draw a simple string) and the occasional X Error and crash. The X Error is consistent and is as follows: fixme:advapi:SetSecurityInfo stub X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 151 (RENDER) Minor opcode of failed request: 17 (RenderCreateGlyphSet) Serial number of failed request: 41091 Current serial number in output stream: 41571 Process of pid=0023 has terminated The crash less consistent but is dependent upon the amount of text I attempt to draw. The last version I know this worked in was 1.1.39. I've a few things to still try out before I attempt to create an RBT. However I would like to know if anyone else is experiencing similar problems and f they have solved the problem. Thanks Damian

3 3

Re: [PATCH] winecoreaudio.drv: Reimplement IAudioClock::GetPosition()
by Alexandre Julliard 06 Oct '11

06 Oct '11

Andrew Eikum <aeikum(a)codeweavers.com> writes: > --- > dlls/winecoreaudio.drv/mmdevdrv.c | 27 +++++++++------------------ > 1 files changed, 9 insertions(+), 18 deletions(-) This fails for me: ../../../tools/runtest -q -P wine -M winmm.dll -T ../../.. -p winmm_test.exe.so wave.c && touch wave.ok wave.c:498: Test failed: waveOutGetPosition(0): returned 19845 bytes, should be 22050 wave.c:509: Test failed: waveOutGetPosition(0): returned 19845 samples (19845 bytes), should be 22050 (22050 bytes) wave.c:522: Test failed: waveOutGetPosition(0): returned 900 ms, (19845 bytes), should be 1000 (22050 bytes) wave.c:535: Test failed: waveOutGetPosition(0): SMPTE test failed wave.c:546: Test failed: waveOutGetPosition(0): MIDI test failed wave.c:557: Test failed: waveOutGetPosition(0): TICKS test failed wave.c:498: Test failed: waveOutGetPosition(0): returned 19845 bytes, should be 22050 wave.c:509: Test failed: waveOutGetPosition(0): returned 19845 samples (19845 bytes), should be 22050 (22050 bytes) wave.c:522: Test failed: waveOutGetPosition(0): returned 900 ms, (19845 bytes), should be 1000 (22050 bytes) wave.c:535: Test failed: waveOutGetPosition(0): SMPTE test failed wave.c:546: Test failed: waveOutGetPosition(0): MIDI test failed wave.c:557: Test failed: waveOutGetPosition(0): TICKS test failed wave.c:498: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 19845 bytes, should be 22050 wave.c:509: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 19845 samples (19845 bytes), should be 22050 (22050 bytes) wave.c:522: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 900 ms, (19845 bytes), should be 1000 (22050 bytes) wave.c:535: Test failed: waveOutGetPosition(WAVE_MAPPER): SMPTE test failed wave.c:546: Test failed: waveOutGetPosition(WAVE_MAPPER): MIDI test failed wave.c:557: Test failed: waveOutGetPosition(WAVE_MAPPER): TICKS test failed wave.c:498: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 19845 bytes, should be 22050 wave.c:509: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 19845 samples (19845 bytes), should be 22050 (22050 bytes) wave.c:522: Test failed: waveOutGetPosition(WAVE_MAPPER): returned 900 ms, (19845 bytes), should be 1000 (22050 bytes) wave.c:535: Test failed: waveOutGetPosition(WAVE_MAPPER): SMPTE test failed wave.c:546: Test failed: waveOutGetPosition(WAVE_MAPPER): MIDI test failed wave.c:557: Test failed: waveOutGetPosition(WAVE_MAPPER): TICKS test failed make: *** [wave.ok] Error 24 -- Alexandre Julliard julliard(a)winehq.org

1 0

[patch] Fake display interface
by Jari Vetoniemi 06 Oct '11

06 Oct '11

Yeah, I'm aware of virtual desktop and used to create scripts to launch applications using wine explorer \desktop=WIDTHxHEIGHT or whatever the parameters were, it works well. But means that you have to create always new shell script, and it also can prevent desktop integration for certain application. If you globally enable that also, it means that every application opens on the same virtual desktop. Also virtual desktop won't fake the display resolutions to application which is useful in certain cases. 2011/9/2 Hin-Tak Leung <hintak_leung(a)yahoo.co.uk>: > --- On Fri, 2/9/11, Jari Vetoniemi <mailroxas(a)gmail.com> wrote: > >> Hello, >> >> I personally hate when applications decide to change my >> screen >> resolution without asking me, or some applications just >> won't run >> inside window. >> So I did fake display interface for the winex11.drv. It >> allows you to >> send any display resolution and frequency to the >> application, but it >> does not change resolution. >> It's small and simple patch, and won't probably ever be >> included into >> the mainline wine. However I'll post it here as it might be >> useful for >> some. >> >> To enable, create string key UseFakeDisp with value Y in >> H_C_U/Software/Wine/X11 Driver >> Default fake resolution is 800x600 60HZ, you can change >> default with >> registry keys FakeDispHeight, FakeDispWidth, FakeDispFreq >> You can also use env variable >> WINE_FAKEDISP=WIDTHxHEIGHT_FREQ (eg. >> WINE_FAKEDISP=1024x768_60) >> >> Might improve it later to use the same syntax for default >> resolution >> and allow multiple fake resolutions to be defined with ; >> separator. >> This is also useful for dual head setups where you may want >> to run >> game or application fullscreen on other monitor while still >> keeping >> the other alive. >> There is also interesting side effect: While some >> applications throw >> error or won't run on resolutions they don't support, some >> applications that don't support them still run with the >> resolution >> specified. Eg. I can run Ys games with 1440x900 resolution >> where they >> normally would not run, and they look great. > > In winecfg there is a way of configuring wine to run under its own desktop window (and having any window application's windows running inside that), instead of having the unix host's window manager managing the window application's window. Have you tried using that? Granted it is a bit awkward for what you want to do (having to go into winecfg to change the desktop's resolution and resetting it afterwards, instead of passing the resolution in per application), but may be improving on that functionality in winecfg could get your code included eventually somehow. >

3 8

WINMM_OpenDevice Activate failed
by GOUJON Alexandre 06 Oct '11

06 Oct '11

Hi Andrew, I saw you modified the Audio tab of winecfg to let the user choose a device. You're really doing a great job considering the mess behind it (audio architecture & drivers). I tested the latest wine and noticed that when you click the "Test Sound" button, there is no error but if you do it again (or several times), there is a err:winmm:WINMM_OpenDevice Activate failed: 80004005 on the console. Harmless but probably worth fixing.

1 0

Re: [1/4] winscard: implementation
by André Hentschel 06 Oct '11

06 Oct '11

Am 03.10.2011 09:31, schrieb Vincent Hardy: > First submitted on wine-devel and modified following comments from Marcus Meissner (MAX_ATR_SIZE / bytecount). > OK, some notes: "winscard: implementation" is a very bad name for a patch, especially for 4. Splitting the patches is a good idea, but you need to split it different (you are adding dead code). In the first patch you might want to add the configure.ac and library loading stuff together with only the things needed for e.g. SCardListReadersA (why no SCardListReadersW?) and then e.g. a patch for every new function. I didn't looked at the code, but i want to remember you to read http://wiki.winehq.org/SubmittingPatches -- Best Regards, André Hentschel

4 3

Re: Vista/w2k8/w7 users, please test mmdevapi base render test
by Erik Inge Bolsø 06 Oct '11

06 Oct '11

Hi Jörg, on my W7 machine I get some failures. I'm using a semi-pro usb soundcard, Creative E-MU 0202 USB. It's set to use 24-bit, 48 kHz as standard in shared mode. In addition, I turned off the E-MU and connected my cheap C-Media USB headset and left it set to default settings (44100 hz, 16-bit). I get some failures both in exclusive and non-exclusive mode. (And how does the test handle multiple soundcards?) E-MU, Exclusive allowed: render.c:167: Returned periods: 10.0000 ms 3.0000 ms render.c:179: pwfx: 00751AA8 render.c:180: Tag: fffe render.c:181: bits: 32 render.c:182: chan: 2 render.c:183: rate: 48000 render.c:184: align: 8 render.c:185: extra: 22 render.c:190: Res: 32 render.c:191: Mask: 3 render.c:192: Alg: FLOAT render.c:308: Returned latency: 10.6666 ms render.c:381: IsSupported(1, 44100x16x2) render.c:381: IsSupported(1, 48000x16x2) render.c:381: IsSupported(0, 48000x 8x2) render.c:381: IsSupported(0, 48000x16x2) render.c:887: Test failed: Initialize failed: 8889000f render.c:890: Test failed: GetService failed: 88890001 render.c:921: this is the last test seen before the exception render: unhandled exception c0000005 at 00409E1C E-MU, Exclusive disabled: render.c:167: Returned periods: 10.0000 ms 3.0000 ms render.c:179: pwfx: 00701AA8 render.c:180: Tag: fffe render.c:181: bits: 32 render.c:182: chan: 2 render.c:183: rate: 48000 render.c:184: align: 8 render.c:185: extra: 22 render.c:190: Res: 32 render.c:191: Mask: 3 render.c:192: Alg: FLOAT render.c:308: Returned latency: 10.6666 ms render.c:413: Test failed: Initialize(1, 44100x16x2) returns 8889000e render.c:413: Test failed: Initialize(1, 48000x16x2) returns 8889000e render.c:381: IsSupported(0, 48000x 8x2) render.c:381: IsSupported(0, 48000x16x2) render.c:887: Test failed: Initialize failed: 8889000f render.c:890: Test failed: GetService failed: 88890001 render.c:921: this is the last test seen before the exception render: unhandled exception c0000005 at 00409E1C C-Media USB headphone, Exclusive enabled: render.c:167: Returned periods: 10.0000 ms 3.0000 ms render.c:179: pwfx: 00A81AA8 render.c:180: Tag: fffe render.c:181: bits: 32 render.c:182: chan: 2 render.c:183: rate: 44100 render.c:184: align: 8 render.c:185: extra: 22 render.c:190: Res: 32 render.c:191: Mask: 3 render.c:192: Alg: FLOAT render.c:308: Returned latency: 11.6100 ms render.c:381: IsSupported(1, 44100x16x2) render.c:381: IsSupported(1, 48000x16x2) render.c:381: IsSupported(0, 44100x 8x2) render.c:381: IsSupported(0, 44100x16x2) render.c:1457: Test failed: Got wrong volume: 0.000000 render.c:1480: Test failed: Got wrong volume: 0.000000 render: 705 tests executed (0 marked as todo, 2 failures), 0 skipped. C-Media USB headphone, Exclusive disabled: render.c:167: Returned periods: 10.0000 ms 3.0000 ms render.c:179: pwfx: 009E1AA8 render.c:180: Tag: fffe render.c:181: bits: 32 render.c:182: chan: 2 render.c:183: rate: 44100 render.c:184: align: 8 render.c:185: extra: 22 render.c:190: Res: 32 render.c:191: Mask: 3 render.c:192: Alg: FLOAT render.c:308: Returned latency: 11.6100 ms render.c:413: Test failed: Initialize(1, 44100x16x2) returns 8889000e render.c:413: Test failed: Initialize(1, 48000x16x2) returns 8889000e render.c:381: IsSupported(0, 44100x 8x2) render.c:381: IsSupported(0, 44100x16x2) render.c:1457: Test failed: Got wrong volume: 0.000000 render.c:1480: Test failed: Got wrong volume: 0.000000 render: 705 tests executed (0 marked as todo, 4 failures), 0 skipped. -- -erik http://useofwords.blogspot.com/

2 2

Re: mscoree: Implement ICorDebug SetManagedHandler (try 2)
by Vincent Povirk 06 Oct '11

06 Oct '11

Still not sure there should be only one ICorDebug per runtime host. It seems like you might want to create multiple interfaces and use them independently.

1 0

Re: mscoree: Implement ICorDebug SetManagedHandler (try 2)
by Marvin 06 Oct '11

06 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=14737 Your paranoid android. === WVISTAADM (32 bit debugging) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation

1 0

Re: mscoree: Implement ICorDebug SetManagedHandler
by Alexandre Julliard 05 Oct '11

05 Oct '11

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > @@ -99,8 +99,28 @@ static HRESULT WINAPI CorDebug_Terminate(ICorDebug *iface) > static HRESULT WINAPI CorDebug_SetManagedHandler(ICorDebug *iface, ICorDebugManagedCallback *pCallback) > { > RuntimeHost *This = impl_from_ICorDebug( iface ); > - FIXME("stub %p %p\n", This, pCallback); > - return E_NOTIMPL; > + HRESULT hr; > + > + TRACE("%p (%p)\n", This, pCallback); > + > + if(!pCallback) > + return E_INVALIDARG; > + > + if(This->pCallback2) > + ICorDebugManagedCallback2_Release(This->pCallback2); > + > + if(This->pCallback) > + ICorDebugManagedCallback_Release(This->pCallback); > + > + hr = ICorDebugManagedCallback_QueryInterface(pCallback, &IID_ICorDebugManagedCallback2, (void**)&This->pCallback2); > + if(hr == S_OK) > + { > + This->pCallback = pCallback; > + > + ICorDebugManagedCallback_AddRef(This->pCallback); > + } You can't release the old interfaces before the new ones are in place. -- Alexandre Julliard julliard(a)winehq.org

1 0

[Question] Built-in indeo drivers
by Maxim 05 Oct '11

05 Oct '11

Hi crews, I want to propose a solution for the well-known problem with Indeo codecs. Details here: http://www.ligos.com/index.php/home/support/indeosupport/ There is a bunch of (old) games still using indeo in their cut scenes. For that reason the installation of the Intel DLLs is required. Unfortunately, old indeo codecs prior the version 5 contain bugs and their support has been discontinued for years. Moreover, Microsoft has disabled indeo in the latest OSes due to security issues. I volunteer myself to create an open-source bult-in replacement for indeo v3,4 and 5 based on my patches for ffmpeg. The code will be reworked in order to remove ffmpeg/libav library dependencies. Only decoding will be implemented. Encoding would require a huge amount of time and it doesn't worth it... Would be such a patch appreciated? Best regards Maxim Poliakovski

2 1

Re: comctl32/tests: Removed sign comparison warning in datetime tests.
by Joris Huizer 05 Oct '11

05 Oct '11

On 10/05/2011 04:43 PM, Marko Nikolic wrote: > static void test_mccolor_types(HWND hWndDateTime, int mccolor_type, const char* mccolor_name) > { > - LRESULT r; > - COLORREF theColor, prevColor; > + //LRESULT r; > + COLORREF theColor, prevColor, crColor; > Please avoid C++/C99-style comments in Wine code In this case you should remove the 'r' variable instead of commenting it out.

2 1

Re: netapi32: add stub for NetScheduleJobEnum
by Austin English 05 Oct '11

05 Oct '11

On Wed, Oct 5, 2011 at 11:35, Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote: > this fixes a crash in app SysIsdpector (http://download.eset.com/download/sysinspector/32/ENU/SysInspector.exe) You should've made this a series, otherwise the build fails: -- -Austin ---------- Forwarded message ---------- From: <buildbot(a)kegel.com> Date: Wed, Oct 5, 2011 at 11:41 Subject: Re: 79589: netapi32: add stub for NetScheduleJobEnum To: dank(a)kegel.com, wine-tests-results(a)winehq.org 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/134 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) BUILD FAILED: failed shell_2 Errors: netapi32.c:23: error: lmat.h: No such file or directory make[1]: *** [depend] Error 1 make: *** [dlls/netapi32/__depend__] Error 2

1 0

Re: [PATCH 1/4 (resend)] audio: Load winmm only on demand
by Alexandre Julliard 05 Oct '11

05 Oct '11

Andrew Eikum <aeikum(a)codeweavers.com> writes: > resend: Fix subject, to make buildbot happy. > > dlls/winealsa.drv/Makefile.in | 2 +- > dlls/winealsa.drv/midi.c | 21 ++++++++++++++++++++- > dlls/winecoreaudio.drv/Makefile.in | 2 +- > dlls/winecoreaudio.drv/coreaudio.c | 2 +- > dlls/winecoreaudio.drv/midi.c | 21 ++++++++++++++++++++- > dlls/wineoss.drv/Makefile.in | 2 +- > dlls/wineoss.drv/midi.c | 21 ++++++++++++++++++++- > 7 files changed, 64 insertions(+), 7 deletions(-) Making winmm a delayed import should work just as well, with no code changes. -- Alexandre Julliard julliard(a)winehq.org

1 0

[Question] Built-in indeo drivers
by Joerg-Cyril.Hoehle＠t-systems.com 05 Oct '11

05 Oct '11

Maxim Poliakovski wrote: >I volunteer myself to create an open-source Go ahead! Some apps still crash in Wine because their installers don't install them, and not every user is able to figure out from the fixme messages what's missing. OSS is not enough, your license must be compatible with Wine's. I don't know whether Indeo is covered by patents and whether that may cause trouble. Which Wine video codec is recommended for copy&paste? iccvid? Encoding only is like iccvid. Regards, Jörg Höhle

1 0

Vista/w2k8/w7 users, please test mmdevapi base render test
by Joerg-Cyril.Hoehle＠t-systems.com 05 Oct '11

05 Oct '11

Hi, please run on native machines my newest mmdevapi tests at http://testbot.winehq.org/JobDetails.pl?Key=14691 You'll find both patch and .exe there. I've split my former test in two. This is part one, without the GetPosition tests. WINETEST_DEBUG does not matter in part 1. wine mmdevapi_test.exe render I'd be pleased if you could test this with various configurations: - with exclusive mode disabled in the MS control panel - with non-standard settings in the MS control panel - with 5:1 audio chosen (if possible) in the MS control panel - audio entirely disabled - sound card without capture (does "capture only" exist?) Please report any failures such that I can later submit this part one test, given confidence that it's been tested with a variety of configurations. Thank you for testing, Jörg Höhle

4 3

Re: ws2_32: Patch to selectively bind to interfaces while still allowing broadcast packets (try 2)
by Marcus Meissner 04 Oct '11

04 Oct '11

On Tue, Oct 04, 2011 at 10:51:26AM -0600, Erich Hoover wrote: > Real Name: > Erich Hoover > > Description: > I know it's been quite a while, but I'm back with another solution > for Bug #7929. This patch uses SO_BINDTODEVICE in order to bind a > socket to a specific interface while still allowing broadcast packets > (a Linux-only feature). While this feature normally requires root > privileges, it can also be enabled by giving wine-preloader the > CAP_NET_RAW capability. Should insufficient permissions be available, > the patch outputs an appropriate error message notifying the user that > broadcast packets will not function properly. Frankly, no sane distributor will ever do this. Ciao, Marcus > Changelog: > ws2_32: Patch to selectively bind to interfaces while still > allowing broadcast packets. > From f4c904b9b21da7664eff33be918da71795db01af Mon Sep 17 00:00:00 2001 > From: Erich Hoover <ehoover(a)mines.edu> > Date: Tue, 4 Oct 2011 10:43:06 -0600 > Subject: ws2_32: Selectively bind UDP sockets to interfaces while still allowing broadcast packets. > > --- > dlls/ws2_32/socket.c | 94 ++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 94 insertions(+), 0 deletions(-) > > diff --git a/dlls/ws2_32/socket.c b/dlls/ws2_32/socket.c > index f0313fc..174ec15 100644 > --- a/dlls/ws2_32/socket.c > +++ b/dlls/ws2_32/socket.c > @@ -2101,6 +2101,94 @@ static int WINAPI WS2_WSARecvMsg( SOCKET s, LPWSAMSG msg, LPDWORD lpNumberOfByte > } > > /*********************************************************************** > + * interface_bind (INTERNAL) > + * > + * Bind the given socket exclusively to a specific interface. > + */ > +static int interface_bind( int fd, struct sockaddr *addr ) > +{ > + struct sockaddr_in *in_sock = (struct sockaddr_in *) addr; > + PIP_ADAPTER_INFO adapters = NULL, adapter; > + unsigned int sock_type = 0, optlen; > + int ret = FALSE; > + DWORD adap_size; > + > + if (in_sock->sin_addr.s_addr == htonl(WS_INADDR_ANY)) > + { > + /* Not binding to specific interface, use default route */ > + goto cleanup; > + } > + optlen = sizeof(sock_type); > + if (getsockopt(fd, SOL_SOCKET, SO_TYPE, &sock_type, &optlen) == -1 > + || sock_type != SOCK_DGRAM) > + { > + /* Not a UDP socket, interface-specific bind is irrelevant. */ > + goto cleanup; > + } > + /* Obtain the size of the IPv4 adapter list and allocate structure memory */ > + if (GetAdaptersInfo(NULL, &adap_size) != ERROR_BUFFER_OVERFLOW) > + { > + ERR("Failed to get the size of the adapter list, " > + "bound broadcast packets will not work on this socket.\n"); > + goto cleanup; > + } > + adapters = HeapAlloc(GetProcessHeap(), 0, adap_size); > + if (adapters == NULL) > + { > + ERR("Failed to allocate the adapter list, " > + "bound broadcast packets will not work on this socket.\n"); > + goto cleanup; > + } > + /* Obtain the IPv4 adapter list */ > + if (GetAdaptersInfo(adapters, &adap_size) != NO_ERROR) > + { > + ERR("Failed to obtain the adapter list, " > + "bound broadcast packets will not work on this socket.\n"); > + goto cleanup; > + } > + /* Search the IPv4 adapter list for the appropriate binding IP */ > + for (adapter = adapters; adapter != NULL; adapter = adapter->Next) > + { > + char *ip = adapter->IpAddressList.IpAddress.String; > + in_addr_t adapter_addr = (in_addr_t) inet_addr(ip); > + > + if (in_sock->sin_addr.s_addr == adapter_addr) > + { > +#ifdef SO_BINDTODEVICE > + struct ifreq ifr; > + > + memset(&ifr, 0, sizeof(ifr)); > + lstrcpynA(ifr.ifr_name, adapter->AdapterName, sizeof(ifr.ifr_name)); > + if (setsockopt(fd, SOL_SOCKET, SO_BINDTODEVICE, (void*)&ifr, sizeof(ifr)) == 0) > + { > + /* Success! All packets sent on this socket will go through the > + * specified interface. */ > + TRACE("Bound to interface '%s' (corresponds to local address %s).\n", > + adapter->AdapterName, inet_ntoa(in_sock->sin_addr)); > + ret = TRUE; > + break; > + } > + > + /* If we are unable to bind to a specific interface then notify the > + * user that broadcast packets will not work for this socket. The > + * user can correct this by giving CAP_NET_RAW access to the > + * wine-preloader binary. */ > + ERR("SO_BINDTODEVICE failed (requires CAP_NET_RAW), " > + "broadcast packets will not work on this socket.\n"); > +#else /* SO_BINDTODEVICE */ > + WARN("SO_BINDTODEVICE is unsupported on this platform, " > + "broadcast packets will not work on this socket.\n"); > +#endif /* SO_BINDTODEVICE */ > + break; > + } > + } > + > +cleanup: > + HeapFree(GetProcessHeap(), 0, adapters); > + return ret; > +} > + > +/*********************************************************************** > * bind (WS2_32.2) > */ > int WINAPI WS_bind(SOCKET s, const struct WS_sockaddr* name, int namelen) > @@ -2151,6 +2239,12 @@ int WINAPI WS_bind(SOCKET s, const struct WS_sockaddr* name, int namelen) > "INADDR_ANY instead.\n"); > in4->sin_addr.s_addr = htonl(WS_INADDR_ANY); > } > + else if (interface_bind(fd, &uaddr.addr)) > + { > + /* Bound to a specific interface, change the binding > + * address so that broadcast packets work properly */ > + in4->sin_addr.s_addr = htonl(WS_INADDR_ANY); > + } > } > if (bind(fd, &uaddr.addr, uaddrlen) < 0) > { > -- > 1.7.1 > >

2 1

Re: [1/4] cmd: Avoid checking handle type when already known in WCMD_ReadFile
by Frédéric Delanoy 04 Oct '11

04 Oct '11

2011/10/4 Dan Kegel <dank(a)kegel.com>: > + * handle_type: type of hIn handle > + * 0 if file, 1 if console, anything else if unknown (autodetect) > > I suspect you want an enum for that. Well I thought about that, but found it a bit overkill for such a limited set of possible values. Also, if I used sthg like enum CMD_HANDLE_TYPE { CMD_HT_FILE = 0, CMD_HT_CONSOLE = 1, CMD_HT_UNKNOWN = 2 } , I'd have to add error checking for unknown parameters passed to WCMD_ReadFile, or never check for CMD_HT_UNKNOWN, and just use it as default value. So TBH I don't think an enum is really necessary (especially since it's just a corner case; all "similar" functions use a BOOL is_console_handle, covering cases 0 and 1. I wouldn't want to change those)

4 6

Re: [2/2] gdi32/tests: fix MSVC build in bitmap.c
by Marvin 04 Oct '11

04 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=14695 Your paranoid android. === WNT4WSSP6 (32 bit bitmap) === bitmap: unhandled exception c0000005 at 00416287 === W2KPROSP4 (32 bit bitmap) === bitmap: unhandled exception c0000005 at 00416287 === WXPPROSP3 (32 bit bitmap) === bitmap: unhandled exception 80000003 at 7C90120E === W2K3R2SESP2 (32 bit bitmap) === bitmap: unhandled exception c0000005 at 7C83F11C === WVISTAADM (32 bit bitmap) === bitmap: unhandled exception c0000005 at 7749653F === W2K8SE (32 bit bitmap) === bitmap: unhandled exception c0000005 at 00000000 === W7PRO (32 bit bitmap) === bitmap: unhandled exception c0000005 at 772D5A15 === W7PROX64 (32 bit bitmap) === bitmap: unhandled exception c0000005 at 00000000 === TEST64_W7SP1 (32 bit bitmap) === bitmap: unhandled exception c0000005 at 77593CDB === W7PROX64 (64 bit bitmap) === Timeout === TEST64_W7SP1 (64 bit bitmap) === Timeout

1 0

re: kernel32: Implement GetVolumePathName.
by Dan Kegel 04 Oct '11

04 Oct '11

Fails test here? ../../../tools/runtest -q -P wine -M ntdll.dll -T ../../.. -p ntdll_test.exe.so file.c && touch file.ok Unhandled exception: page fault on read access to 0x00212b18 in 32-bit code (0x7bc47995). Backtrace: =>0 HEAP_CreateFreeBlock+0xbb(subheap=0x110014, ptr=0x122b48, size=0xeffd0) [dlls/ntdll/heap.c:583] 1 HEAP_ShrinkBlock+0x42(subheap=0x110014, pArena=0x122b08, size=0x38) [dlls/ntdll/heap.c:685] 2 RtlAllocateHeap+0x2a8(heap=0x110000, flags=0x2, size=0x38) [dlls/ntdll/heap.c:1699] 3 RtlDosPathNameToNtPathName_U+0x35c(dos_path="C:\windows\system32", ntpath=0x32fbb4, file_part=(nil), cd=(nil)) [dlls/ntdll/path.c:394] 4 GetVolumePathNameW+0x107(filename="C:\windows\system32", volumepathname="?Ir\sandbox\slave\(", buflen=0x14) [dlls/kernel32/volume.c:1767] 5 test_file_name_information+0x179() [dlls/ntdll/tests/file.c:1304] 6 func_file+0x374() [dlls/ntdll/tests/file.c:1726] 7 run_test+0x9e(name="file.c") [include/wine/test.h:556] 8 main+0x23a(argc=<?>, argv=0x1103c8) [include/wine/test.h:624] 0x7bc47995 HEAP_CreateFreeBlock+0xbb [dlls/ntdll/heap.c:583] in ntdll: movl 0x0(%eax),%eax 583 (*(DWORD *)((char *)ptr + size) & ARENA_FLAG_FREE))

4 5

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