January 2010 - Wine-Devel - list.winehq.org

Re: [2/5] d3d9: Test invalid buffer lock parameters
by Henri Verbeet Jan. 29, 2010

Jan. 29, 2010

On 29 January 2010 11:35, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > +static HMODULE d3d9_handle = 0; This is redundant. > + hr = IDirect3DVertexBuffer9_Lock(buffer, 0, 0, (void *) &bufstart, 0); > + ok(hr == D3D_OK, "IDirect3DVertexBuffer9_Lock failed, 0x%08x\n", hr); > + hr = IDirect3DVertexBuffer9_Unlock(buffer); > + ok(hr == D3D_OK, "IDirect3DVertexBuffer9_Unlock failed, 0x%08x\n", hr); > + > + hr = IDirect3DVertexBuffer9_Lock(buffer, 0, 1024, (void *) &data, 0); > + ok(hr == D3D_OK, "IDirect3DVertexBuffer9_Lock failed, 0x%08x\n", hr); > + hr = IDirect3DVertexBuffer9_Unlock(buffer); > + ok(hr == D3D_OK, "IDirect3DVertexBuffer9_Unlock failed, 0x%08x\n", hr); > + ok(bufstart == data, "Two locks returned different addresses: %p, %p\n", bufstart, data); > Why would we care if the buffer is always mapped at the same address? Also note that the test doesn't necessarily prove this is the case. > + /* This happily wraps around the address space */ > + hr = IDirect3DVertexBuffer9_Lock(buffer, ~0U, 1024, (void *) &data, 0); > + ok(hr == D3D_OK, "IDirect3DVertexBuffer9_Lock(start ~0U) failed, 0x%08x\n", hr); > + hr = IDirect3DVertexBuffer9_Unlock(buffer); > + ok(hr == D3D_OK, "IDirect3DVertexBuffer9_Unlock failed, 0x%08x\n", hr); > + ok(bufstart -1 == data, "~0U start lock returned unexpected address: expected %p, got %p\n", bufstart - 1, data); > I'd expect this to break on 64 bit. Also, like the previous test, why do we care? Do you seriously have an application that does this?

2 1

Re: [PATCH 3/5] wined3d: Prune invalid states from the state table.
by Stefan Dösinger Jan. 29, 2010

Jan. 29, 2010

On Thursday 28 January 2010 23:40:25 Henri Verbeet wrote: > +static void prune_invalid_states(struct StateEntry *state_table, const > struct wined3d_gl_info *gl_info) +{ > + unsigned int start, last, i; > + > + start = STATE_TEXTURESTAGE(gl_info->limits.texture_stages, 0); > + last = STATE_TEXTURESTAGE(MAX_TEXTURES - 1, > WINED3D_HIGHEST_TEXTURE_STATE); + for (i = start; i <= last; ++i) > + { > + state_table[i].representative = 0; > + state_table[i].apply = state_undefined; > + } Please use the number of texture blend stages reported from the fragment pipeline rather than gl_limits.texture_stages. texture_stages only works with the nvrc and ffp pipelines, but not arbfp or atifs(it works out ok by chance on most GL cards). There's a deeper issue with how we manage texture limits, because currently the extension loading code picks limits.texture_stages, already anticipating which pipeline we'll choose later. We should handle this in the way shader constants are handled: Rename limits.texture_stages to limits.max_nv_general_combiners, make only the nvrc and nvts pipelines read this extension specific value, and use the pipeline reported d3d texture blend stages in fragment pipeline independent code. We're also (still) mixing up blend stages with fixed function vertex coordinates. Regarding masking out unsupported / invalid states, Ivan once suggested the idea to make the pipeline template's needed extension field more powerful, e.g. via a callback function. That way the pipeline would have more control over which state handlers it registers. I am fine with a pipeline independent function, I guess it will work just fine for our needs, just digging out the old idea.

2 4

Re: [2/5] d3d9: Test invalid buffer lock parameters
by Henri Verbeet Jan. 29, 2010

Jan. 29, 2010

On 28 January 2010 22:50, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + * Copyright (C) 2010 Stefan Dösinger(For CodeWeavers) Please use UTF-8 like the other source files. (I'd also suggest a space and a lowercase 'F').

2 1

Loader, mapping and sharing issues with main exe
by Jason Edmeades Jan. 29, 2010

Jan. 29, 2010

Hello, I've been debugging a problem with an application which checks itself for consistency before it runs. It does this extremely simply and fails in a trivial way under wine, but for the life of me I do not know how to fix it, and I would appreciate any thoughts - its not everyday I delve into the loader and server logic! I have cut this down to a 2 line test program, which basically fails because a native executable called eg. test.exe subsequently calls CreateFile(".\\test.exe", GENERIC_READ, 0 /* no share*/ - ie it's opening itself for read access and non-shared access. It suffers a sharing violation on wine whereas it works fine on windows Diagnosing the wine side, we are in trouble here - the act of loading a module ends up in load_dll which call find_dll_file which in turn calls NtOpenFile for GENERIC_READ access. This returns a file handle which is then used to create the in memory file mapping for the executable code, and the handle returned from the NtOpenFile is then closed. However, when we come along to the application code and try the open we end up checking the sharing and there are 3 things on the inode->open chain: The original open, with access of read The mapping, with access of mapping The open in progress (which is ignored for sharing checks) which does not want to SHARE_READ,and hence the sharing violation occurs. For reference we are failing in the 3rd (last) case of check_sharing returning STATUS_SHARING_VIOLATION, ie existing access if for read purposes, but the requested sharing doesnt allow this. What I dont understand is why the NtClose for the handle does not remove it from the 'open' list - I think from my reading of the fd_destroy code it will put it onto the closed list if there are other references to the same inode, although thats where my debugging will head next. This whole area has me confused now! Can anyone shed some light on how its all supposed to work please? Thanks, Jason

2 2

Quick multiple-patch submission question
by Erich Hoover Jan. 29, 2010

Jan. 29, 2010

When submitting multiple patches that apply to the same component but each patch is unrelated (ie. each one fixes a different issue), is it still appropriate to label the patches with the [PATCH X/Y] notation? In the case I have at hand the patches are even for different files of the same component, so the apply order completely doesn't matter. Erich Hoover ehoover(a)mines.edu

4 3

Re: [2/2] kernel32: Fix GetVolumeNameForVolumeMountPointW to match
by srrose Jan. 28, 2010

Jan. 28, 2010

What does this mean? Iim using a USB 2.0 Flash Drive and a LAUNCHU3.EXE file says it is linked to a missing export. It then says KERNEL32.DLL:GetVolumeMountPointW. Can you help me? Thank you!! srrose(a)commspeed.net

2 1

Windows-version dependent callback?
by Joerg-Cyril.Hoehle＠t-systems.com Jan. 28, 2010

Jan. 28, 2010

Hi, my (unreleased) MIDI tests have spotted that not all versions of MS-Windows seem to send out the MM_MOM_POSITIONCB callback/notification resulting from a MEVT_F_CALLBACK event in midiStreamOut(). w9X/ME appears not to know about it. Machines since NT honour it (even though I've seen mixed results about w2k). More generally, I'm wondering whether Wine should behave similarly based on the version setting in winecfg? What is Wine.wisdom on this topic? We've seen apps hang because of missing callbacks or notifications from Wine. Perhaps an app receiving extra callbacks or messages that it does not know about will cause as much trouble? Thanks for your help, Jörg Höhle

3 2

tell wine not to use the mouse
by Mihai Donțu Jan. 28, 2010

Jan. 28, 2010

Hi, I use wine to run cl.exe and build some dll-s. However, each time make invokes wine, my mouse short-jumps from one position to another or stops responding for a brief period of time. Is there any way to tell wine to skip any GUI initialization or to not touch the mouse? Thanks, -- Mihai Donțu

1 1

Re: [PATCH 3/5] wined3d: Ensure draw ordering across contexts.
by Stefan Dösinger Jan. 28, 2010

Jan. 28, 2010

> - if (SUCCEEDED(IWineD3DSurface_GetContainer((IWineD3DSurface *)target, &IID_IWineD3DSwapChain, (void **)&swapchain))) { > - if (target == (IWineD3DSurfaceImpl*) swapchain->frontBuffer) { > - wglFlush(); > - } > - IWineD3DSwapChain_Release((IWineD3DSwapChain *) swapchain); > - } > + wglFlush(); /* Flush to ensure ordering across contexts. */ Why do we have to do this even when there is only one context? In the event another context is created after the draw?

2 1

WINEDLLPATH and /usr/lib/wine
by Michael Ost Jan. 28, 2010

Jan. 28, 2010

Hi, I am wanting to direct wine to launch a specific APP.exe.so program by using WINEDLLPATH during the development of APP.exe. Unfortunately (and undocumented-ely if you know what I mean) WINEDLLPATH is superseded by /usr/lib/wine. So if /usr/lib/wine/APP.exe.so exists, WINEDLLPATH will find that one instead of the one I am trying to target. So, if these files exist: /usr/lib/wine/APP.exe.so /MY_DIR/APP.exe.so Then this command... WINEDLLPATH=MY_DIR wine APP.exe ... will start /usr/lib/wine/APP.exe.so and not /MY_DIR/APP.exe.so. Is this on purpose? It doesn't seem right at first glance. I would assume that WINEDLLPATH would take precedence. Otherwise what purpose would it serve? Thanks for tips or background, Michael Ost Muse Research, Inc.

4 22

re: Student Interested in Google Summer of Code 2010
by Dan Kegel Jan. 27, 2010

Jan. 27, 2010

Howdy! While you're figuring out your proposal, you might want to look over the code from previous SoC (or university) Wine projects that didn't quite make it in. One easy one might be the dxdiag written by the UCLA students. Dusting it off and bringing some of its features into the wine tree might be a nice way to warm up. - Dan

1 0

Re: GSoC D3DX9 work
by Tony Wasserka Jan. 27, 2010

Jan. 27, 2010

> Hello, > I might be interested as a side project. I've been poking around in the > wine code looking for something interesting for the last few weeks and > this might be it. However I know I wouldn't have much interest in it if > it doesn't actually help me, so I'd like to know a few additional > details about it. > > * Do you have list of bugs that your changes are known to fix? > * Same question for what bugs a completed work should fix. > * Could I see the TODO list to get a better idea of what needs to be done? > > Thank you. > (note that I replied to wine-devel since this might be useful for someone else as well) Okay, so here we go: Generally, I don't have visual (wine) tests for any of the stuff I wrote, not sure whether they're needed actually though. font code: - Probably the easiest to start with, although it might be a bit confusing if you're unfamiliar with the code. - Requires D3DXFilterTexture with D3DX_DEFAULT filter on A8R8G8B8 textures first though (that one's relatively easy to implement). - Requires this http://repo.or.cz/w/wine/d3dx9TW.git?a=commit;h=e4dfdb7c2cc4264bbe89ef938c9… patch to be applied first (fixes a bug in D3DXSprite implementation) - Not sure whether PreloadGlyphs was working correctly when I last worked on it. Glyphs are cached into textures and if an app caches to many glyphs new textures must be generated, which I didn't do first. I added this functionality but can't tell if it still works. Could be tested pretty easy with my testing demos. - Glyph positions in the texture cache (which are returned by GetGlyphData) differ by 1 or 2 from the native dll. At least they did, maybe I figured out why and fixed it meanwhile. It doesn't really matter anyways since it doesn't really affect applications, but just wanted to tell you ;) - two flags in DrawText aren't implemented, yet (DT_NOCLIP could be important to speed up things). Generally that one function (and its bunch of helper functions) really needs some cleanup before actually submitting it to wine-patches. It's forked from user32 code (or whereever DrawText is implemented in), so it's not /that/ clean. In conclusion, the only problematic bit here should be the last one. texture code, D3DXLoadSurfaceFromMemory: - implement other color conversion and filtering routines, you REALLY should talk to me in case you really want to do this, since I have thought much about how to organize code to be efficient and relatively clean as well, and I'm having a fairly good idea how it probably should be done. - What's missing for color conversion: about any format which is not unsigned 1,2,3 or 4 b(yte)pp ARGB, but my design allows fairly easy addition of support for large ARGB formats, signed formats, luminance channels and other non-compressed stuff. compressed formats might be hard, but not a necessarity to implement in the first place anyway. - other filters to be implemented: point filtering is the only one necessary here actually, since it can be used as a fallback for more advanced filters for now. texture code, other stuff: - not really much to fix here, it just all depends on a working D3DXLoadSurfaceFromMemory implementation. - only thing: my d3dx9 implementation implements W(indows)I(maging)C(omponent) codecs, and I'm not really sure how to integrate that one into Wine. right now they reside in the d3dx9 folder itself, but it could also be possible to create a new dll for it (since it might be usefull for d3dx10 as well)... you should talk to madewokherd (sorry if I'm misspelling that nick; he's the one who implemented most of the WIC stuff) and julliard (since he is the one to decide whether the integration method actually goes into mainline) on IRC about how to it properly I guess. mesh code: - right now dependent on d3dxof for .x file loading routines, but d3dx9 actually provides its own file loading routines, which should be reimplemented using d3dxof's methods. The current code must be ported over to using the d3dx9 methods. - Optimize() is not really implemented, I have a few ideas how to do it, but it's not of greates priority anyway - D3DXCreateMesh might work with some vertex declarations which do NOT map directy to a FVF, this might require architectural changes to the core code... - generally, the COM interfaces might not be implemented cleanly (maybe they are though, I wasn't sure how to do it properly since dsound and wined3d are doing this different, I went for the way wined3d does it). - .x file parsing doesn't read texture file names... this one might be trivial but I just couldn't get it working, for whatever reason - D3DXFVFFromDeclarator might not cover everything - I just forked it from some wined3d or d3d9 code (it does work fairly good at least) As for the affected bug reports, just search for the "d3dx" or "createtexture" terms on bugzilla ;) No non-DX-SDK apps are really dependant on the mesh stuff AFAIK, only few on the font stuff (e.g. the Dolphin emulator), so there aren't really any bug reports for them. - generally there aren't that many bugs, since most d3dx9 code just wasn't implemented, yet... There are numerous games though which don't run with our d3dx9 implementation, since they often require the texture loading functions.

2 2

Re: wintrust: Close file handle on error loading a message from it
by Alexandre Julliard Jan. 27, 2010

Jan. 27, 2010

Juan Lang <juan.lang(a)gmail.com> writes: > Fix for bug 21501. It doesn't work here: ../../../tools/runtest -q -P wine -M wintrust.dll -T ../../.. -p wintrust_test.exe.so softpub.c && touch softpub.ok softpub.c:491: Test failed: expected TRUST_E_NOSIGNATURE or CRYPT_E_FILE_ERROR, got 00000006 make[2]: *** [softpub.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: gdi32: Tests for the codepages supported by TranslateCharsetInfo
by Dmitry Timoshkov Jan. 27, 2010

Jan. 27, 2010

Ilya Shpigor <shpigor(a)etersoft.ru> wrote: > +static void test_TranslateCharsetInfo(void) > +{ > + /* Any other codepages are not supported > + * by TranslateCharsetInfo in Windows XP > + */ > + test_codepage(42, 2); > + test_codepage(874, 222); > + test_codepage(932, 128); > + test_codepage(936, 134); > + test_codepage(949, 129); > + test_codepage(950, 136); > + test_codepage(1250, 238); > + test_codepage(1251, 204); > + test_codepage(1252, 0); > + test_codepage(1253, 161); > + test_codepage(1254, 162); > + test_codepage(1255, 177); > + test_codepage(1256, 178); > + test_codepage(1257, 186); > + test_codepage(1258, 163); > + test_codepage(1361, 130); It would be better to create a table and run the tests in the loop, use symbolic charset names, and actually test some codepages which would fail. -- Dmitry.

1 0

Re: gdi32: Tests for the codepages supported by TranslateCharsetInfo
by Paul Vriens Jan. 27, 2010

Jan. 27, 2010

On 01/27/2010 11:01 AM, Ilya Shpigor wrote: > Hi Ilya, These tests introduce failures on Win9x/NT4: https://winetestbot.geldorp.nl/JobDetails.pl?Key=456 It would maybe be worthwhile to add some more info to the traces by using __LINE__ for example (see examples in other tests). You can request an account on this winetestbot so you can check other platforms yourself if needed. -- Cheers, Paul.

1 0

trace() and testing asynchronous callbacks and concurrency
by Joerg-Cyril.Hoehle＠t-systems.com Jan. 27, 2010

Jan. 27, 2010

Hi, I'm seeking advice and ideas about 2 issues: A) I've added trace() output to a callback function. On a dual-core XP box, output comes out like follows: mmidiid.ci:56.: Ccall:bac7k! 9m: sTg=e3c9s 1t2 fef58 a0 iled: Message 3c9 from command midiStreamOut which is a mixture of characters from: midi.c:56: Callback! msg=3c9... and midi.c:79:Test fa[iled...] What can I do if trace() may produce such valuable output that I don't want to miss it from a test log, i.e. I don't want to remove the trace() entirely? BTW, this is interesting on its own because it proves that at least the MM_MOM_DONE (3c9) callback from midiStreamOut may be sent from another thread than the application's. B) How to sanely test the effects of callbacks yet be compatible with ok() and broken()? The reason is that some callbacks are not invoked on w2k. They are on XP. If you look at my test_notification() pattern in winmm/tests/mci.c, you'll notice that while it's barely useable with ok(), it does not work together with broken(). What I need to express is rc = midiXYZ() ok(callback=MM_MOM_3c9 || broken(callback=none) /* w2k and presumably w9x */) Yet this is incomplete: Not only must the type be tested (MM_MOM_xyz), but also the parameters and other slots of the MSG (e.g. msg.hwnd) or callback function (e.g. midihdr). That's why I created the function test_notification(x,y,z) back then for MCI, which does all that. A possibility may be get_notification() /* retrieve data from callback function or message */ ok(cb_type == MM_MOM_3c9 || broken(cb_type==0)) if (cb_type==MM_MOM_3c9) { if (cb_type==CALLBACK_WINDOW || THREAD) { ok(cb_hwnd == hwnd); } ok(cb_parm1 == mhdr && cb_parm2 == 0); ...} This is getting too verbose fast. Any better suggestion? Thanks for your help, Jörg Höhle

1 0

GSoC 2010 is on
by Kai Blin Jan. 27, 2010

Jan. 27, 2010

Hi folks, Google announced this year's GSoC incarnation. It would be nice if everybody could have a look at http://wiki.winehq.org/SummerOfCode and check if the project they want to mentor is on there. Also, feel free to propose new projects, assuming a student with low prior knowledge about Wine can complete them in 2 months of time. (They have 3 months, but past experience tells us this almost always takes longer than planned). Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

1 0

Student Interested in Google Summer of Code 2010
by Arjun Comar Jan. 27, 2010

Jan. 27, 2010

Hey all, I'm new here and interested in the Wine project for GSoC this year and figured I'd start by introducing myself and hopefully getting to know who's who on this list. I'm a Sophomore CS major at Rose-Hulman Institute of Technology, a science and engineering school in Indiana. I've been writing code since I taught myself how in 7th grade, and I've been using Linux since around that same time. In high school, I volunteered large chunks of my time to various open source projects: Ubuntu, Compiz, etc.. Now that I'm in college, I regret not having quite as much time as I'd like to devote to the Linux community as a whole, so I'm hoping to spend this summer giving something back. A quick explanation of what experience I have (relevant stuff only): Linux, C, OpenGL I've been scanning the wiki for GSoC from last year and noticed that most of the projects didn't have any sort of a status associated with them. I checked in the irc channel, and was told that most of the projects were still open. Of those that don't have a status listed, I'm kinda interested in the d3d9_xx DLLs problem. While I'm not too familiar with DirectX, I figure if I start now I'll have plenty of time to get up to speed. Is this still a problem that needs work? If so, is the mentor listed on the page still accurate? I attempted to contact the listed mentor but wasn't successful. I'd also be interested in working on almost anything else, that project just stuck out to me as something important that hadn't gotten done in a long time. If you have any suggestions for useful projects, or how to go about getting caught up to speed on what I need to know (Windows API, DirectX, and/or the Wine codebase itself), I would appreciate that. It's slow going trying to find all the information on my own, but I'm sure other people have had the same problem before and have found good resources to solve it. I'm very interested in working with all of you for the next few months and hopefully through the summer and beyond. If anyone would like more information, feel free to ask. I've never done this before, so I'm not too sure what kind of information you guys are looking for in a GSoC candidate. Any critique/commentary is appreciated. TL;DR: I'm a student interested in GSoC, help me out! --- Arjun Comar, Rose-Hulman '12 Computer Science

1 0

Re: [PATCH 2/5] d3d9: Add depth clamp tests.
by Stefan Dösinger Jan. 26, 2010

Jan. 26, 2010

Am 26.01.2010 um 18:31 schrieb Henri Verbeet: > +/* This test tests depth clamping / clipping behaviour: > + * - When D3DRS_CLIPPING is disabled depth values are *clamped* to the > + * minimum/maximum z value.+ hr = IDirect3DDevice9_SetRenderState(device, D3DRS_ZFUNC, D3DCMP_LESSEQUAL); > + ok(SUCCEEDED(hr), "SetRenderState failed, hr %#x.\n", hr); It would be interesting to see how D3DCMP_GREATER behaves with clipping off. Does the clamping occur before the depth test, or after the test but before writing the values into the depth buffer. (ie, is 3.0 > 1.0 or is 3.0 == 1.0) A floating point depth buffer might be interesting as well to see if the clamping is done explicitly, or if just happens due to the limited value range in the depth buffer. I'm fine with postponing this until we get serious about float depth buffers though. (fwiw, ARB_depth_buffer_float suggests that the app will be able to use depths outside 0;1, but doesn't expose this yet, and is left open for future extensions)

2 2

Wine coding style
by Uwe Bonnes Jan. 26, 2010

Jan. 26, 2010

Hello, are there any examples for Editor settings (e.g. emacs c-mode) resulting in acceptable indentation? Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

4 3

Re: [PATCH] [Include]: push/pop pack fixes on 64 bit platforms
by Alexandre Julliard Jan. 26, 2010

Jan. 26, 2010

Eric Pouech <eric.pouech(a)orange.fr> writes: > (try #2) > > A+ > --- > > include/commctrl.h | 16 ++++++++++++++++ > include/fci.h | 4 ++++ > include/fdi.h | 8 ++++++++ > include/mmsystem.h | 4 ++++ > include/richedit.h | 4 ++++ > include/shlwapi.h | 6 +++++- > include/wingdi.h | 6 ++++++ > include/ws2spi.h | 4 ++++ > 8 files changed, 51 insertions(+), 1 deletions(-) Many of these don't match the PSDK. Also please split the patch. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [kernel32] Add testcase for bug 21292(corrected)
by Paul Vriens Jan. 26, 2010

Jan. 26, 2010

On 01/25/2010 06:30 PM, Uwe Bonnes wrote: > This time deleting an eventual created file and with hopefully better > indentation Indentation is still not what it's supposed to be. You are not sticking to the surrounding style, but worse your own patch uses different styles as well. -- Cheers, Paul.

1 0

Re: [PATCH 3/3] xmllite/tests: Add test for XML declaration parsing
by Alexandre Julliard Jan. 25, 2010

Jan. 25, 2010

Nikolay Sivov <bunglehead(a)gmail.com> writes: > This applies over previous 2 patches series. > > Add test for XML declaration parsing It doesn't work: ../../../tools/runtest -q -P wine -M xmllite.dll -T ../../.. -p xmllite_test.exe.so reader.c && touch reader.ok reader.c:546: Test failed: Expected (0,0), got (0,1751353550) make[2]: *** [reader.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: winemp3: incorrect stream handling
by Austin English Jan. 25, 2010

Jan. 25, 2010

On Sun, Jan 24, 2010 at 6:13 PM, Stefano Guidoni <s.guidoni(a)tin.it> wrote: > One of the examples in the API doc of MPG123 states: "we are not in > feeder mode, so MPG123_OK, MPG123_ERR and MPG123_NEW_FORMAT are the > only possibilities"; however in winemp3 the function MPEG3_StreamOpen > uses mpg123_open_feed(), so those are not the only possibilities in > this case. > > This patch restores background music in Irisu Syndrome > (freeware game, http://appdb.winehq.org/objectManager.php?sClass=version&iId=15598 > , in Crusader Kings and possibly other applications too (like > virtualdub, bug 21091). Please don't send patches as compressed files. -- -Austin

1 0

Re: [4/4] winhttp: Store the context passed to WinHttpSendRequest.
by Alexandre Julliard Jan. 25, 2010

Jan. 25, 2010

Hans Leidekker <hans(a)codeweavers.com> writes: > See http://bugs.winehq.org/show_bug.cgi?id=21442 > --- > dlls/winhttp/request.c | 1 + > dlls/winhttp/tests/winhttp.c | 16 +++++++++++++--- > 2 files changed, 14 insertions(+), 3 deletions(-) It doesn't work: ../../../tools/runtest -q -P wine -M winhttp.dll -T ../../.. -p winhttp_test.exe.so winhttp.c && touch winhttp.ok winhttp.c:297: Test failed: WinHttpQueryOption failed: 122 winhttp.c:298: Test failed: expected 0xdeadbef0, got 0 make[2]: *** [winhttp.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

1 0