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

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. 27, 2010

Jan. 27, 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