- wine-devel - winehq.org

Quick multiple-patch submission question
by Erich Hoover 29 Jan '10

29 Jan '10

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 28 Jan '10

28 Jan '10

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 28 Jan '10

28 Jan '10

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 28 Jan '10

28 Jan '10

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 28 Jan '10

28 Jan '10

> - 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 28 Jan '10

28 Jan '10

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 27 Jan '10

27 Jan '10

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 27 Jan '10

27 Jan '10

> 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 27 Jan '10

27 Jan '10

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 27 Jan '10

27 Jan '10

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 27 Jan '10

27 Jan '10

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 27 Jan '10

27 Jan '10

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 27 Jan '10

27 Jan '10

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 27 Jan '10

27 Jan '10

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 26 Jan '10

26 Jan '10

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 26 Jan '10

26 Jan '10

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 26 Jan '10

26 Jan '10

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 26 Jan '10

26 Jan '10

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 25 Jan '10

25 Jan '10

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 25 Jan '10

25 Jan '10

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 25 Jan '10

25 Jan '10

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

Re: ukrainian-credui
by Paul Vriens 25 Jan '10

25 Jan '10

On 01/24/2010 09:23 PM, гор Хакер wrote: > ukrainian-credui > Hi, If you send a second (or higher) revision of a patch please mark it as such. For example "(Try x)" at the end. This makes it easier to discard older ones. This one supersedes the one that didn't have the pragma for example. A nicer subject would be appreciated as well. "ukrainian-credui" suggests it's a translation but why not say something like "Adding Ukrainian translations to credui" or "Fixed ...". I'm not sure if our automated patch watcher (http://source.winehq.org/patches/) can cope with non-ascii characters in the "From:" field but your patches don't show up over there. Have a look at http://wiki.winehq.org/SubmittingPatches. Your email address for this mail is different from the generated one in the patch attached to that email and the names are again different from the copyright name in the file itself. -- Cheers, Paul.

4 4

Re: [PATCH 1/2] user32/tests/win.c: Fix Win9x detection
by Dmitry Timoshkov 25 Jan '10

25 Jan '10

Michael Karcher <wine(a)mkarcher.dialup.fu-berlin.de> wrote: > The current code misdetects both Windows XP and Wine as Win9x and skips > some tests due to this. The SetParent tests were not passing on XP, so > this patch also removes the tests that fail on XP SP3. These should be 2 separate patches. And according to http://test.winehq.org/data/e2af560aa3c23a672d8680f91f3e1b8793d5827f/index_… SetParent tests pass under XP just fine. -- Dmitry.

3 6

Re: [PATCH 1/4] [Include]: push/pop pack fixes on 64 bit platforms
by Alexandre Julliard 25 Jan '10

25 Jan '10

Eric Pouech <eric.pouech(a)orange.fr> writes: > diff --git a/include/commctrl.h b/include/commctrl.h > index 27bd745..c841d51 100644 > --- a/include/commctrl.h > +++ b/include/commctrl.h > @@ -2245,7 +2245,9 @@ static const WCHAR WC_PAGESCROLLERW[] = { 'S','y','s','P','a','g','e','r',0 }; > #define PGN_SCROLL (PGN_FIRST-1) > #define PGN_CALCSIZE (PGN_FIRST-2) > > +#ifdef _WIN32 > #include <pshpack1.h> > +#endif That's broken, testing _WIN32 is not useful in Wine. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 5/5] wined3d: Add support for EXT_gpu_shader4 provided sampling functions with explicit derivatives.
by Stefan Dösinger 25 Jan '10

25 Jan '10

Am 24.01.2010 um 21:16 schrieb Henri Verbeet: > if(texrect) { > if(lod) { > sample_function->name = projected ? "texture2DRectProjLod" : "texture2DRectLod"; > - } else if(grad) { > - sample_function->name = projected ? "texture2DRectProjGradARB" : "texture2DRectGradARB"; > - } else { > + } > + else if (grad) > + { > + if (gl_info->supported[EXT_GPU_SHADER4]) > + sample_function->name = projected ? "texture2DRectProjGrad" : "texture2DRectGrad"; > + else if (gl_info->supported[ARB_SHADER_TEXTURE_LOD]) > + sample_function->name = projected ? "texture2DRectProjGradARB" : "texture2DRectGradARB"; > + else > + { > + FIXME("Unsupported RECT grad function.\n"); > + sample_function->name = "unsupported2DRectGrad"; > + } > + } > + else > + { > sample_function->name = projected ? "texture2DRectProj" : "texture2DRect"; > } > } else { I think these if constructs in shader_glsl_get_sample_function are becoming ugly with more and more possibilities added. Isn't there a nicer way, like a table that is either searched, or a multi-dimensional array to look up the end result?

2 1

Re: Fix use of uninitialized variable in dlls/advapi32/tests/eventlog.c
by Paul Vriens 25 Jan '10

25 Jan '10

On 01/25/2010 12:21 PM, Vladimir Pankratov wrote: > Hello all. > > Fix use of uninitialized variable in dlls/advapi32/tests/eventlog.c > > changed files: > dlls/advapi32/tests/eventlog.c > > Thanks. > This is the same patch as you've sent a month ago. This doesn't happen on a clean .wine as there we would never reach this test. The fix should be in the implementation, as initializing 'needed' would only hide the problem. What I'm saying is that an app doesn't need to initialize 'needed' before calling ReadEventLogA. -- Cheers, Paul.

1 0

shell32: SHELL_execute() tries to extract program name and arguments from SHELLEXECUTEINFOW.lpFile
by Илья Басин 25 Jan '10

25 Jan '10

At first sight there's a strange behavior in SHELL_execute() (read ShellExecuteEx() ): at tries to extract program path and arguments from SHELLEXECUTEINFOW.lpFile, if it's unquoted. http://source.winehq.org/source/dlls/shell32/shlexec.c?v=wine-1.1.37#L1709 On WinXP at least ShellExecuteExA() doesn't do it/ haven't yet tested with ShellExecuteExW(). This is harmful when you have 2 documents like "C:\aaa.txt" and "C:\aaa.txt bbb.txt" Found an old thread about this, but it seems abandoned. http://www.mail-archive.com/wine-devel@winehq.org/msg57246.html

1 0

strsafe.h?
by Dan Kegel 25 Jan '10

25 Jan '10

http://msdn.microsoft.com/en-us/library/bb288454.aspx encourages people to use the functions in strsafe.h. (They're inline by default, and optionally available as a static library.) Neither Wine nor mingw currently ship this header. There are a few copies floating around, though: http://baseutils.googlecode.com/svn/trunk/str_strsafe.h http://github.com/janneke/gub/blob/76e5823756ea1eda37542808a82d784df4a20ee2… And then there's the massively more complete one from the mingw-w64 project: http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/trunk/mingw-w64-heade… Can we just use that one directly? - Dan

1 0

Re: [PATCH 1/2] ws2_32: use ntstatus in overlapped functions (try 3)
by Mike Kaplinskiy 24 Jan '10

24 Jan '10

On Fri, Jan 22, 2010 at 6:46 PM, Mike Kaplinskiy <mike.kaplinskiy(a)gmail.com> wrote: > Also some style fixes. Sorry for the fuss over this :) > --- > dlls/ws2_32/socket.c | 45 ++++++++++++++++++++++++++++++++++----------- > 1 files changed, 34 insertions(+), 11 deletions(-) > Don't even look at this patch, didn't mean to send it (yet). Mike.

1 0

Re: winex11.drv: Added missing mouse position clipping. (try 2)
by Lauri Kenttä 24 Jan '10

24 Jan '10

> The SetCursorPos() calls hooks on Wine because Wine has big issue - it doesn't filter pointer move messages that were caused by Wine itself. The first patch (http://source.winehq.org/patches/data/57569) tries to address exactly this. I think XWarpCursor is not a problem, as the event comes asynchronously with some delay. So my patch fixes the easier but worse case, calling hooks directly from SetCursorPos. What's wrong with this, why is it wrong, and do you have a better idea? What else causes Wine to produce extra messages? Also, is there a reason why I shouldn't write a test for this to make the issue better known? >> I'm aware that my version causes hooks to be called with clipped coordinates on mouse move, when they should in that case be called with the unclipped ones. > This particular change will break all games using dinput when mouse pointer goes outside of virtual desktop. (This was the elaboration I was asking for.) I didn't know that, and I don't have any such games. Feel free to reject the patch, I'll rewrite it without this bug and in smaller chunks. (It would be helpful if the first two patches were also either accepted or rejected.) >> returns unclipped coordinates from GetCursorPos > This is what native will do inside hook handler. Add some tests. That's not true. (See below.) >> and even sends incorrect WM_* messages. > Tests please. I've attached a program that outputs coordinates from hookproc and wndproc, both the passed ones and the ones from GetCursorPos. If you try it, you can see that Wine has the following bugs: - incorrect coordinates in some WM:s - incorrect coordinates in some hook calls - incorrect coordinates and missing WM:s after clipping - extra hook calls on SetCursorPos, even if the pos doesn't change - extra WM_MOUSEMOVE after zero-length moves - some other extra hook calls and WM:s due to XWarpPointer The next snippets show the WM bug and how GetCursorPos works inside hook handlers. This first one is from Win2k8 Server. First, the pointer is at (34,34) and clipping is set to (30,30)-(40,40). Then the program calls mouse_event(MOUSEEVENTF_LEFTUP | MOUSEEVENTF_MOVE, 0, 6, 0, 0). 11: hookproc: WM_MOUSEMOVE: (34,40), get = (34,34), injected = 1 11: hookproc: WM_LBUTTONUP: (34,39), get = (34,39), injected = 1 11: wndproc: WM_MOUSEMOVE: (34,39), get = (34,39) 11: wndproc: WM_LBUTTONUP: (34,39), get = (34,39) As you can see, the correct order would be: - call hooks for moving, return old pos from GetCursorPos - clip and store the new position - send the move message using the new position - call hooks and send the button message, both using the clipped position Compare to current Wine output: 11: hookproc: WM_MOUSEMOVE: (34,40), get = (34,34), injected = 1 11: hookproc: WM_LBUTTONUP: (34,40), get = (34,39), injected = 1 11: hookproc: WM_MOUSEMOVE: (34,39), get = (34,39), injected = 0 11: wndproc: WM_MOUSEMOVE: (34,40), get = (34,39) 11: wndproc: WM_LBUTTONUP: (34,40), get = (34,39) 11: wndproc: WM_MOUSEMOVE: (34,39), get = (34,39) Aside of the extra move caused by XWarpPointer, the second hook and both injected messages have incorrect (unclipped) coordinates. > What exactly is wrong with [border scrolling]? Many games (for example, Baldur's Gate) check for mouse coordinates. If the pointer is outside the virtual desktop, Wine gives negative coordinates and the game doesn't scroll left/up, because x != 0 and y != 0. The same thing happens to right/bottom, of course. Correct clipping fixes it. > Who said that Wine should keep the pointer inside virtual desktop? Ok, I'll not do it. But don't you think it's a bit confusing if the pointer moves freely but the program thinks it's clipped to an area? My apologies for bringing up something that is actually none of my business, but I think you should pay more attention to the way you write your comments. First, even small positive comments are considered psychologically very important, but you have given none. Second, most of your negative feedback has only stated that the patches are bad and wrong, often without giving much details or any better ideas. That is, the comments haven't been very constructive. Currently your messages look a bit like "f*** off, noob", which hopefully is not what you had in mind. Anyway, this is certainly not a good way to encourage spending time to Wine development. Some (luckily not me) would take it badly and just rm -rf wine-git and never try again, even if they could be a great help with some guidance. So let's all be nice to each other, and everyone will be happier. -- Lauri Kenttä

4 6

Re: [PATCH 2/8] d3d10: Parse shaders in parse_fx10_local_variable().
by Rico Schüller 24 Jan '10

24 Jan '10

Am 24.01.2010 11:22, schrieb Rico Schüller: > --- > dlls/d3d10/effect.c | 37 +++++++++++++++++++++++++++++++++---- > 1 files changed, 33 insertions(+), 4 deletions(-) > > > > > This patch has a bug in it, it doesn't check the return value. Please don't apply it, I'll send an improved version.

1 0

errno-ntstatus conversion
by Mike Kaplinskiy 24 Jan '10

24 Jan '10

There are many places where we need to do a conversion between the unix errno and the windows ntstatus (and then sometimes to dos errors). Here are some that I found: http://source.winehq.org/source/server/file.c#L582 http://source.winehq.org/source/server/sock.c#L702 http://source.winehq.org/source/dlls/wininet/netconnection.c#L512 http://source.winehq.org/source/dlls/winhttp/net.c#L153 http://source.winehq.org/source/dlls/ntdll/file.c#L312 Would it be a good idea to perhaps create an include file for both the server and the dlls to convert unix error codes to status/winsock error codes? The reason for 2 functions is winsock error codes do not actually map to any status code, they seem to be there to make porting easier (ie STATUS_CONNECTION_RESET maps to ERROR_CONNECTION_RESET). Does this seem reasonable, or should we just keep duplicating the conversion code everywhere? I have not checked whether there are places that have different statuses for the same unix error, but presumably we can pick a reasonable default and just have special cases within the module. This is coming from some conversion within the server. The server should not return wsa-based error codes in its error events list, and just use wsa conversion when sending window messages. Mike.

1 0

Re: [PATCH] Add missing classes for DOMDocument in msxml, and add test-cases back it up.
by Austin English 23 Jan '10

23 Jan '10

On Sat, Jan 23, 2010 at 9:24 AM, Terry <tbos(a)verizon.net> wrote: Forgot the patch. -- -Austin

1 0

cygwin, perl, wine, rebase, and ReBaseImage()
by Dan Kegel 22 Jan '10

22 Jan '10

While building chromium with visual c++ 2005 on wine, step 'webcore_bindings_sources' tries to run WebCore/bindings/scripts/generate-bindings.pl, and sometimes it fails with 13 [main] perl 29 C:\chromium\src\third_party\cygwin\bin\perl.exe: *** fatal error - unable to remap C:\chromium\src\third_party\cygwin\lib\perl5\5.10\i686-cygwin\auto\List\Util\Util.dll to same address as parent(0x1350000) != 0x52760000^M 14 [main] perl 74 fork: child 29 - died waiting for dll loading, errno 11^M http://www.tishler.net/jason/software/rebase/rebase-2.2.README indicates that cygwin's fork() relies on everything mapping to the same address in the child. (Gulp.) This is an occasional problem even on Windows; the usual advice is to run cygwin's rebaseall (carefully). Sure enough, running wine c:\\cygwin\\bin\ash c:\\cygwin\\bin\\rebaseall seems to have solved the problem. Or maybe I just got lucky. Cygwin's rebase command has its own implementation of ReBaseImage(), so it doesn't matter that Wine's is a stub. (Gee, maybe we should ask Ralf sometime if he's willing to relicense it from gpl. We'd have to translate it from C++ to C, too.) - Dan

1 0

comctl32 listview notification assert
by Aric Stewart 22 Jan '10

22 Jan '10

Hello, I am seeing something in listview.c that really make me feel like there is something really wrong going on. So maybe it is something I am having a lack of understanding in. I have an application that is sending 'A' style notification codes to the listview header. Specifically I am seeing an HDN_ITEMCHANGEDA. In the listview code the first thing HDN_ITEMCHANGEDA and HDN_ITEMCHANGEDW does is notify_forward_header. notify_forward_header does not understand HDN_ITEMCHANGEDA and then asserts. It looks straight forward to add the A versions of the notifications to that case statement. But often when something looks that straight forward there is something more underlying it. Especailly since this looks like something we would be seeing a lot of if it was as much of an issue as it appears. does anyone have a deeper understanding of the listview code that would help me figure out what is going on. Or maybe just tell me that I am over thinking it and it really is as easy of a fix as it looks. thanks! -aric

1 0

Re: shell32: Dynamically load an ordinal only export.
by Alexandre Julliard 22 Jan '10

22 Jan '10

Huw Davies <huw(a)codeweavers.com> writes: > --- > dlls/shell32/tests/shlfileop.c | 18 +++++++++--------- > 1 files changed, 9 insertions(+), 9 deletions(-) This shouldn't be needed, import by ordinal works just fine. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: winmm: Add a bunch of new mmio tests which discover some bugs in mmio handling.
by Alexandre Julliard 22 Jan '10

22 Jan '10

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > @@ -45,6 +45,20 @@ static DWORD RIFF_buf[] = > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 > }; > > +#define expect_buf_offset(_hmmio, _off) \ > +do \ > +{ \ > + MMIOINFO _mmio; \ > + LONG _ret; \ > + memset(&_mmio, 0, sizeof(_mmio)); \ > + _ret = mmioGetInfo((_hmmio), &_mmio, 0); \ > + ok(_ret == MMSYSERR_NOERROR, "mmioGetInfo error %u\n", _ret); \ > + ok(_mmio.lBufOffset == 0, "expected 0, got %d\n", _mmio.lBufOffset); \ > + _ret = mmioSeek((_hmmio), 0, SEEK_CUR); \ > + ok(_ret == (_off), "expected %d, got %d\n", (_off), _ret); \ > +} \ > +while (0) Please avoid such multi-line macros, define a function instead. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/2] ws2_32: use ntstatus in overlapped functions (try 2)
by Alexandre Julliard 22 Jan '10

22 Jan '10

Mike Kaplinskiy <mike.kaplinskiy(a)gmail.com> writes: > Also some style fixes and move case 0 to the top - it's the most likely Nothing says that likely cases have to be at the top, and anyway 0 is probably the least likely of all (and should in fact never happen). -- Alexandre Julliard julliard(a)winehq.org

1 0

"Mockba to Berlin" game - mouse not clicking
by Pavel Troller 22 Jan '10

22 Jan '10

Hi! My son bought a game DVD bound to a youngster's magazine. It contains a 5 years old game by Monte Cristo Multimedia, called "Mockba to Berlin". We were trying this game with wine 1.1.36. The game PERFECTLY installs and then PERFECTLY launches, going through all the initial screens and videos. It then renders a primary menu on the screen, allowing to start a new game, load a save, perform some settings, etc. The mouse cursor is fully functional, the hovered item gets brightened and an explanatory text appears, which tells, what the particular item is for. BUT: The mouse buttons are DEAD. All. I cannot left-click, right-click, mid-click, simply nothing. It' very frustrating, it looks that just ONE CLICK remains to start the game, but you can't do it! There is no console output related to the problem, just some warnings from the GL renederer, which seem harmless. There is no AppDB entry for this game (we didn't found any), so we cannot follow any hints, how to solve the problem. The game was tested on 3 different machines but with the same wine installation. The results were identical. Are there any general tips, what we can try to solve the problem ? With regards, Pavel

4 5

Re: [2/2] xmllite/reader: Basic input object creation on IXmlReader::SetInput()
by Paul Vriens 22 Jan '10

22 Jan '10

On 01/21/2010 07:08 PM, Nikolay Sivov wrote: > This patch depends on previously sent, forget it properly, sorry. > Basic input object creation on IXmlReader::SetInput() > > > > Hi Nikolay, This one doesn't apply cleanly on top of: "xmllite/tests: Test query for supported interface sequence while creating IXmlReaderInput instance" -- Cheers, Paul.

2 1

Re: [PATCH 4/5] xmllite/tests: Add basic test structure for IXmlReader
by Paul Vriens 22 Jan '10

22 Jan '10

On 01/18/2010 10:28 PM, Nikolay Sivov wrote: > Add basic test structure for IXmlReader > Hi Nikolay, This one crashes on Vista without a servicepack at: + IXmlReader_Release(reader); +} All the calls before that one look ok (they produce the expected output). I guess "vista without an SP" can be considered broken(), but how do deal with that? -- Cheers, Paul.

3 10

Re: [PATCH 3/3] jscript: Add error handling to Array.reverse
by Paul Vriens 22 Jan '10

22 Jan '10

Hi Piotr, On 01/20/2010 05:23 PM, Piotr Caban wrote: > + if(FAILED(hres1)) > + return hres1; > + > hres2 = jsdisp_propget_idx(jsthis, l,&v2, ei, sp); > + if(FAILED(hres2)) { > + VariantClear(&v1); > + return hres2; > + } > > if(hres1 == DISP_E_UNKNOWNNAME) > - jsdisp_delete_idx(jsthis, l); > + hres1 = jsdisp_delete_idx(jsthis, l); Coverity (CID 1022) correctly spotted that the last if() will never be reached as we are now bailing out on a FAILED(hres1). Could you have a look? The same is true (me thinks) for hres2 but Coverity doesn't complain about that one, strange? -- Cheers, Paul.

1 0

RFC: dwarf merge patch
by André Hentschel 21 Jan '10

21 Jan '10

Hi, I made a patch to merge code from ntdll/signal_x86_64.c to dbghelp/dwarf.c The operator DW_OP_deref_size needs to read different sizes of variables from memory into a fixed size variable. Now i am not sure if my solution is the smallest and easiest one, so i would be happy for every comment on this. http://www.winehq.org/pipermail/wine-patches/2010-January/083899.html -- Best Regards, André Hentschel

2 3

Fwd: [user32/tests] Don't crash on Win9x/WinMe
by Peter Dons Tychsen 21 Jan '10

21 Jan '10

Forgot wine-devel, >>I'm lost here as TrackPopupMenu() is not called in a loop. It's only called once. So which API function are you referring to? I was referring to the "loop" we got into on NT4 where the proc handler would be re-entered again and again. My idea was that if this happened on 9x as well, then this we could cause a crash. Apparently this is not the case. Thanks, /pedro

1 0

Re: winex11.drv: Added missing mouse position clipping. (try 2)
by Vitaliy Margolen 21 Jan '10

21 Jan '10

Lauri Kenttä wrote: > When the cursor position is clipped with ClipCursor, the cursor should be > confined to that area. This patch fixes cursor position clipping in > X11DRV_ClipCursor, X11DRV_GetCursorPos, X11DRV_SetCursorPos and > X11DRV_send_mouse_input and makes the mouse warp to the new position if > moved outside the clip rect. > > The previous try fixed only clipping (not warping) and only in > GetCursorPos, but the problem wasn't that small after all. > --- > dlls/winex11.drv/mouse.c | 52 > ++++++++++++++++++++++++++++++++++++--------- > 1 files changed, 41 insertions(+), 11 deletions(-) > You changing way too many things without a single test. Lots of those areas you touch will break oh so many apps. For starters write some tests and verify what you doing is correct. You should be able to write tests for all injected messages (send_mouse_event). If you can't make an automated test, write a visual test for the rest and send to wine-devel. Especially pay attention to all messages sent, and order of calling hook, sending messages, modifying values returned from GetCursorPos(). You breaking that. And don't try to keep pointer inside Wine's window - this won't get past AJ. Vitaliy.

2 2

Re: [user32/tests] Don't crash on Win9x/WinMe
by Peter Dons Tychsen 21 Jan '10

21 Jan '10

> It took a while but I found the culprit. The crash is most likely because > the window is (about to be) destroyed. > > The only thing left to do is to fix the 211 test failures on NT4. > > I fixed a typo while at it and used a define instead of a magic value. > > > Are you sure this is the right fix? Is this crash not caused by the loop, and not the actual call to the menu? Other test-cases call the same API without this problem. /pedro

2 3

Re: wmc: Fix symbol was not declared and using plain integer as NULL pointer sparse warnings.
by Jacek Caban 21 Jan '10

21 Jan '10

Hi Rob, On 1/21/10 12:57 PM, Rob Shearman wrote: > --- > tools/wmc/wmc.c | 8 +++++--- > tools/wmc/wmc.h | 2 +- > 2 files changed, 6 insertions(+), 4 deletions(-) > --- a/tools/wmc/wmc.h +++ b/tools/wmc/wmc.h @@ -65,7 +65,7 @@ extern node_t *nodehead; extern lan_blk_t *lanblockhead; int mcy_lex(void); -FILE *yyin; +extern FILE *yyin; It looks like it worked before your patch only because it's used only in wmc.c, which means that it probably should be static. Thanks, Jacek

2 2

Re: cmd: Added cmd.exe tests.
by Paul Vriens 21 Jan '10

21 Jan '10

On 01/20/2010 06:35 PM, Jacek Caban wrote: > --- > programs/cmd/tests/Makefile.in | 14 ++ > programs/cmd/tests/batch.c | 286 ++++++++++++++++++++++++++++++++++ > programs/cmd/tests/rsrc.rc | 23 +++ > programs/cmd/tests/test_echo.cmd | 9 + > programs/cmd/tests/test_echo.cmd.out | 21 +++ > 5 files changed, 353 insertions(+), 0 deletions(-) > create mode 100644 programs/cmd/tests/Makefile.in > create mode 100644 programs/cmd/tests/batch.c > create mode 100644 programs/cmd/tests/rsrc.rc > create mode 100644 programs/cmd/tests/test_echo.cmd > create mode 100644 programs/cmd/tests/test_echo.cmd.out > Hi Jacek, Is the intention to have these being part of winetest? I do think more makefile magic (Dan's old patches?) is needed to get this actually to compile, not? -- Cheers, Paul.

2 1

Some Wine development statistics
by Paul Vriens 21 Jan '10

21 Jan '10

Hi, Just found this: http://gitstats.sourceforge.net/examples/wine/index.html -- Cheers, Paul.

1 0

Re: [PATCH] user32/tests: check that SetCursorPos doesn't call hooks.
by Nicolas Le Cam 21 Jan '10

21 Jan '10

2010/1/21 Lauri Kenttä <lauri.kentta(a)gmail.com>: > SetCursorPos should not call mouse low-level hooks. > --- > dlls/user32/tests/input.c | 16 ++++++++++++++++ > 1 files changed, 16 insertions(+), 0 deletions(-) > > diff --git a/dlls/user32/tests/input.c b/dlls/user32/tests/input.c > index 7713ff6..a5dba06 100644 > --- a/dlls/user32/tests/input.c > +++ b/dlls/user32/tests/input.c > @@ -1198,6 +1198,7 @@ static void test_keynames(void) > > static POINT pt_old, pt_new; > static BOOL clipped; > +static int hook_proc2_call_times; > #define STEP 3 > > static LRESULT CALLBACK hook_proc1( int code, WPARAM wparam, LPARAM lparam ) > @@ -1231,6 +1232,8 @@ static LRESULT CALLBACK hook_proc2( int code, WPARAM wparam, LPARAM lparam ) > MSLLHOOKSTRUCT *hook = (MSLLHOOKSTRUCT *)lparam; > POINT pt; > > + ++hook_proc2_call_times; > + > if (code == HC_ACTION) > { > ok(hook->pt.x == pt_new.x && hook->pt.y == pt_new.y, > @@ -1281,6 +1284,7 @@ static void test_mouse_ll_hook(void) > HHOOK hook1, hook2; > POINT pt_org, pt; > RECT rc; > + int hook_proc2_call_times_old; > > GetCursorPos(&pt_org); > hwnd = CreateWindow("static", "Title", WS_OVERLAPPEDWINDOW | WS_VISIBLE, > @@ -1347,6 +1351,18 @@ static void test_mouse_ll_hook(void) > GetCursorPos(&pt); > ok(pt.x == pt_new.x && pt.y == pt_new.y, "Position changed: (%d,%d)\n", pt.x, pt.y); > > + /* Check that SetCursorPos doesn't call hooks. > + * Check twice: first moving to old coordinates, then to new. */ > + SetCursorPos(10, 10); > + > + hook_proc2_call_times_old = hook_proc2_call_times; > + SetCursorPos(10, 10); > + ok(hook_proc2_call_times_old == hook_proc2_call_times, "Hooks called\n"); > + > + hook_proc2_call_times_old = hook_proc2_call_times; > + SetCursorPos(20, 20); > + ok(hook_proc2_call_times_old == hook_proc2_call_times, "Hooks called\n"); > + > UnhookWindowsHookEx(hook2); > done: > DestroyWindow(hwnd); > -- > 1.6.6 > > > > Hi Lauri, What about resetting hook_proc2_call_times to 0 before calling SetCursorPos and just checking if it has changed ? Also other static variables used in hook procs aren't prefixed, this is more trivial but everyone is encouraged to follow current code style of the file. -- Nicolas Le Cam

2 1

Re: gdi32: Add OEM charset for processing in TranslateCharsetInfo
by Dmitry Timoshkov 21 Jan '10

21 Jan '10

Ilya Shpigor <shpigor(a)etersoft.ru> wrote: > Some details about this patch: > > The getting charset through the GetTextCharset works with mistakes for OEM > charset. The problem exist in SelectObject where the gdi font is created from > the logical font. Wine try to get information about the charset in this gdi > font creation through TranslateCharsetInfo, but don't able to do it. This > function works with predefined array of supported charsets and code pages. > OEM charset is absent in this array. > > Full list of this array in MSDN: > http://msdn.microsoft.com/en-us/library/dd317754%28VS.85%29.aspx > > This patch add the necessary items to this array. Then you need to add an extensive set of tests for TranslateCharsetInfo() to confirm that it's the source of the problem. Somehow I doubt that this is a correct place for the fix. -- Dmitry.

1 0

example code appending files with w32api broken?
by Hin-Tak Leung 21 Jan '10

21 Jan '10

I needed a WIN32 API based file-appending solution to fix a bug (http://bugs.winehq.org/show_bug.cgi?id=21394) and using the example code http://msdn.microsoft.com/en-us/library/aa363778%28VS.85%29.aspx as reference, I have got a somewhat working solution, except if I follow the code, the WriteFile part for appending fails. Then I have cross-gcc compiling that example source code standard-alone, and the resulting executable won't append under wine cmd either. So it looks like either the example code is wrong, or wine's implementation of WriteFile() is a bit broken sometimes. I have determined the ReadFile succceeds and the SetFilePointer() also work) So I have two questions - (1) can somebody tell if there is something obviously wrong with the example, (2) can somebody say if it is because wine is not working e.g. SetPointer doesn't work? On a general question: what's the policy of patches based on MSDN example code like this? I mean, assuming the example does the job, it is quite difficult to write file-appending code which isn't quite similiar to that.

2 5

Re: [PATCH 1/5] wininet: Add Internet{Set, Query}Option tests, implement POLICY option
by Nikolay Sivov 20 Jan '10

20 Jan '10

On 1/20/2010 23:46, Andrew Eikum wrote: > --- > dlls/wininet/internet.c | 6 ++++++ > dlls/wininet/tests/internet.c | 26 ++++++++++++++++++++++++++ > 2 files changed, 32 insertions(+), 0 deletions(-) > Please mark patches with (tryX) in subject and specify a difference from previous try next time. It's really hard to follow identically named mails without a single line of details.

1 0

Re: user32: Do not allow a change of capture if the currently capture window is a menu unless explicitly specified (try3)
by Paul Vriens 20 Jan '10

20 Jan '10

On 01/11/2010 09:47 PM, Peter Dons Tychsen wrote: > Try 3 of this patch: > > - Moved check to server. > - Removed handling of error code translation after input from AJ. > > Thanks, > > /pedro > > Hi Peter, This patch has introduced test failures on NT4 and below (tested locally): http://test.winehq.org/data/tests/user32:win.html The callback is entered several times on NT4 (only once on XP) so it seems. The test crashes on Win98 btw. Could you have a look? You can use the winetestbot (https://winetestbot.geldorp.nl/) to check the failures on NT4. I can assist with Win9x testing if needed. I'm busy setting up a local winetestbot that includes Win95, Win98 and WinMe. -- Cheers, Paul.

2 2

Re: oleaut32: do not crash in logging if string is NULL
by Alexandre Julliard 20 Jan '10

20 Jan '10

Aric Stewart <aric(a)codeweavers.com> writes: > @@ -68,10 +68,16 @@ typedef struct _marshal_state { > > /* used in the olerelay code to avoid having the L"" stuff added by debugstr_w */ > static char *relaystr(WCHAR *in) { > - char *tmp = (char *)debugstr_w(in); > - tmp += 2; > - tmp[strlen(tmp)-1] = '\0'; > - return tmp; > + static char szNull[] = "<NULL>"; > + if (in) > + { > + char *tmp = (char *)debugstr_w(in); > + tmp += 2; > + tmp[strlen(tmp)-1] = '\0'; > + return tmp; > + } > + else > + return szNull; > } This should never happen. Places that can get a null pointer should use the standard debugstr_w. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: kernel32/tests: do not compare handle with zero directly (Smatch)
by Dan Carpenter 20 Jan '10

20 Jan '10

Sorry, I'm not on the list. - ok( file != 0, "CreateFileMapping PAGE_READWRITE error %u\n", GetLastError() ); + ok( !!file, "CreateFileMapping PAGE_READWRITE error %u\n", GetLastError() ); Smatch sees those as equivelent. (The new version does at least http://repo.or.cz/w/smatch.git). There is a wine_checker.sh script in smatch_scripts so you can quickly test individual files. I just pushed a change to make wine_checker.sh find the smatch binary so you may want to pull the most recent changes. /path/to/smatch_scripts/wine_checker.sh dlls/kernel32/tests/virtual.c Michael said it could be either real bug or a false positive. I sort of decided it was a false positive and pushed a change to fix that. Now if "file" gets 1) reassigned 2) incremented/decremented 3) passed to a function like this: fuction(&file); it stops being called a filehandle. (Unless it gets reassigned another file handle obviously). Hope that is Ok. The check only prints a warning if something is _definitely_ a file handle and it gets compared to zero. I could easily change it to print a message if something is _possibly_ a file handle and gets compared against zero. Like this: if (x) file = CreateFile(); else file = some_func(); if (file) // <- complain I know smatch has been abandonware for a long time, but I hope to do better now. regards, dan carpenter

1 2

WINEDEBUG=+relay: why unicode arguments printed in form L"\0412\044b" and not L"\x412\x44b"? 044b sure not octal
by Илья Басин 20 Jan '10

20 Jan '10

/////////////////////////// #include <windows.h> int main() { MessageBoxExW(NULL, L"\x412\x44b \x434\x435\x439\x441\x442\x432\x438\x442\x435\x43b\x44c\x43d\x43e \x445\x43e\x442\x438\x442\x435 \x443\x434\x430\x43b\x438\x442\x44c \"\x43f\x440\x438\x43f\x430\x440\x43a\x43e\x432\x430\x43d\x43d\x44b\x435\" \x43f\x438\x441\x44c\x43c\x430?\r\r\x410\x442\x440\x438\x431\x443\x442 \x41f\x430\x440", L"The Bat! Voyager", 0x00012133, 0x00000019); } /////////////////////////// # WINEDEBUG=+relay wine msgbox.exe 2>&1 | grep "MessageBoxExW" 0009:Call user32.MessageBoxExW(00000000,0040a028 L"\0412\044b \0434\0435\0439\0441\0442\0432\0438\0442\0435\043b\044c\043d\043e \0445\043e\0442\0438\0442\0435 \0443\0434\0430\043b\0438\0442\044c \"\043f\0440\0438\043f\0430\0440\043a\043e\0432\0430\043d\043d\044b\0435\" \043f\0438\0441\044c\043c\0430?\r\r\0410\0442\0440\0438\0431\0443\0442 \041f\0430\0440",0040a000 L"The Bat! Voyager",00012133,00000019) ret=0040101c 0009:Ret user32.MessageBoxExW() retval=00000000 ret=0040101c

2 1

Re: [PATCH 4/5] wined3d: Don't use the depth range clipping hack when we have ARB_depth_clamp.
by Chris Robinson 20 Jan '10

20 Jan '10

On Tuesday 19 January 2010 2:52:28 pm Henri Verbeet wrote: > ARB_depth_clamp should give pretty much the desired behaviour by clamping > instead of clipping depth values outside the depth range. I think you need to make sure glEnable(GL_DEPTH_CLAMP) gets called in state_clipping if you're going to bypass the depth range hack with it. Currently it's only called if WINED3DRS_CLIPPING is off.

3 8

valgrind run called on account of rain
by Dan Kegel 20 Jan '10

20 Jan '10

Today's scheduled match between Valgrind and Wine was called on account of rain. The roofers think they found where the water was coming in, and the rainstorm can't last forever; I'm hoping to turn the Valgrind build machine on again later this week. Once it dries out :-)

4 4

Re: [PATCH 3/5] wined3d: Don't use the depth range clipping hack when minZ and maxZ are equal.
by Stefan Dösinger 20 Jan '10

20 Jan '10

Am 19.01.2010 um 23:52 schrieb Henri Verbeet: > - if (!stateblock->device->untransformed) > + if (!stateblock->device->untransformed && minZ != maxZ) My tests show that this is not needed, at least in d3d8 and d3d9. My (unsent) tests show that if you pass MinZ == MaxZ SetViewport adjusts one of them to make sure they're apart by at least 0.001. If the parameters are < 0.999 maxZ is incremented by 0.001, otherwise minZ is set to 0.999. (If my memory serves me right) That said, I will be busy the next 2 weeks at university, so don't expect the test and a fix for SetViewport in in that time. Plus, I still haven't ported my tests to ddraw, which may behave differently. If it helps your work feel free to put the patch in in the meantime, although obviously it would be better to skip it to avoid forgetting about it later.

1 0

re: Usage of libxml2 for several modules
by Dan Kegel 19 Jan '10

19 Jan '10

http://xmlsoft.org/threads.html says it's only a problem if the same document is being parsed by both threads. The trouble scenario seems unlikely, offhand.

4 7

Re: [6/10] winemapi: Add MAPIInitialize implementation.
by Alexandre Julliard 19 Jan '10

19 Jan '10

Andrew Nguyen <arethusa26(a)gmail.com> writes: > This seemed to be the easiest and most trivial way to allow > MAPIInitialize to succeed in the tests, which will be added in the > next several patches. That doesn't seem right. The tests should be able to work without an extended provider. -- Alexandre Julliard julliard(a)winehq.org

3 3

Re: [PATCH 1/5] wininet: Add Internet{Set, Query}Option tests, implement POLICY option
by Alexandre Julliard 19 Jan '10

19 Jan '10

Andrew Eikum <aeikum(a)codeweavers.com> writes: > diff --git a/dlls/wininet/tests/Makefile.in b/dlls/wininet/tests/Makefile.in > index ba8f662..66a756f 100644 > --- a/dlls/wininet/tests/Makefile.in > +++ b/dlls/wininet/tests/Makefile.in > @@ -10,6 +10,7 @@ CTESTS = \ > generated.c \ > http.c \ > internet.c \ > + option.c \ This can go with the other internet tests in internet.c, there's no need for a new file. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH 2/6] ws2_32: convert wsa errors to ntstatus in overlapped callbacks
by Alexandre Julliard 19 Jan '10

19 Jan '10

Mike Kaplinskiy <mike.kaplinskiy(a)gmail.com> writes: > @@ -542,6 +542,35 @@ static inline DWORD NtStatusToWSAError( const DWORD status ) > return wserr; > } > > +/* most ws2 overlapped functions return an ntstatus-based error code */ > +static inline NTSTATUS WSAErrorToNtStatus( const DWORD error ) > +{ In general conversions should go status->error, not the other way around. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: winex11.drv: Fix the Ctrl+Break processing
by Dmitry Timoshkov 19 Jan '10

19 Jan '10

Ilya Shpigor <shpigor(a)etersoft.ru> wrote: > + /* Ctrl+Break processing */ > + if ((e->state & ControlMask) && > + (e->keycode == 0x7F)) > + return VK_CANCEL; It's always a good idea to provide some details. Like: pressing the Pause/Break key alone produces VK_PAUSE vkey, while pressing Ctrl+Pause/Break produces VK_CANCEL under Windows, but not under Wine. Ilya, it's better to use a keysym instead of keycode, and add an explanation in the source as well as in the patch comment. -- Dmitry.

1 0

Ubuntu survey
by sacchi antonio 18 Jan '10

18 Jan '10

This is a survey for the apps that users would like to see in upcoming version of Ubuntu: what do you think?? ubuntuforums.org/showthread.php?t=1381221 www.surveymonkey.com/s/GFVQP62 P.S. Please suggest AutoCAD :-D

2 1

Re: [1/2] msi: Support retrieving rows from join tables.
by James Hawkins 18 Jan '10

18 Jan '10

On Mon, Jan 18, 2010 at 4:09 AM, Hans Leidekker <hans(a)codeweavers.com> wrote: > --- > dlls/msi/join.c | 7 +++++-- > 1 files changed, 5 insertions(+), 2 deletions(-) > Tests please? Thanks, James

1 0

Arwinss
by Aleksey Bragin 18 Jan '10

18 Jan '10

Hello, I would like to present my project here too, because I think this information will be interesting for Wine developers. At least, I have not seen anyone gone that far using Wine code. I came up with an idea to create an alternative Win32 subsystem, which would be targeted to NT-alike OSes: Windows NT family and of course ReactOS, based on Wine as much as possible. Detailed presentation with explanations is attached, along with links to some more information. Briefly, what I did: gdi32.dll - source code is nearly unmodified from Wine, but compiled in ReactOS tree, into a real PE DLL. user32.dll - source code is nearly unmodified from Wine, but compiled in ReactOS tree, into a real PE DLL. What about Wineserver, you would ask? SERVER_START_REQ and related macros are rewritten to perform a syscall to win32k.sys (more about win32k.sys below). Server protocol is the same, but of course many requests aren't need. winex11.drv - this is the one if you want X Server to be your interface. This is unchanged Wine source code, again compiled inside a ReactOS source tree into a PE DLL winent.drv - an alternative user/gdi driver, which mostly forwards all calls into a kernel mode graphics engine located in win32k.sys (which is compatible with Windows video drivers, so all acceleration could be used). win32k.sys - kernelmode counterpart of the new Win32 subsystem, contains graphics engine, user server which is based on a small part of platform-independent Wineserver source code adapted to kernelmode, and a simple window manager which calculates visible regions for windows and manages window showing/hiding. All other parts are used from the host OS (be it Windows, or ReactOS). The most funny thing is that this subsystem actually started to work! (I attached a few screenshots in the presentation). There are still some bugs making Arwinss not really usable at the moment, but I'm inviting all developers to participate and help me bring it to a fully usable condition, so that it supports at least all apps which Wine supports plus those which Wine doesn't support due to problems in other parts. The presentation: (links to source code and further information are in the presentation) http://www.reactos.org/media/docs/2010/arwinss.pdf With the best regards, Aleksey Bragin.

1 0

Re: sti: add launch application registry
by Alexandre Julliard 18 Jan '10

18 Jan '10

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > @@ -387,6 +387,7 @@ HKLM,%CurrentVersion%\Controls Folder\PowerCfg,"LastID",,"5" > HKLM,%CurrentVersion%\RunServices,"winemenubuilder",2,"%11%\winemenubuilder.exe -a -r" > HKLM,%CurrentVersion%\Setup,"BootDir",,"%30%" > HKLM,%CurrentVersion%\Setup,"SharedDir",,"%25%" > +HKLM,%CurrentVersion%\StillImage\Registered Applications Unless there's an app that requires the empty key, you should create it as needed from the dll. -- Alexandre Julliard julliard(a)winehq.org

1 0

winetestbot changes
by Greg Geldorp 18 Jan '10

18 Jan '10

A couple of changes to the test bot: - Maximize number of powered on VMs (Paul Vriens) - Make tag prefix for test.winehq.org submissions configurable (Paul Vriens) - Add support for VMs on multiple hosts, add Windows 95/95B/98/98SE VMs - Make the "File" field on the "Submit job" page accept longer file names - Add feedback page Ge.

1 0

Re: [Kernel32]Test for Bug 21292: Createfile creating with illegal char in name (supercedes first patch)
by Paul Vriens 17 Jan '10

17 Jan '10

Hi Uwe, On 01/17/2010 03:56 PM, Uwe Bonnes wrote: > + if (hFile != INVALID_HANDLE_VALUE) > + { > + CloseHandle( hFile ); > + DeleteFileA("test/"); > + } Indentation is a bit off here (probably because you are mixing tabs and spaces). The rest of your patch also mixes tabs and spaces. This file mostly uses spaces so please do that as well. FWIW, the file that is created doesn't have the slash. -- Cheers, Paul.

1 0

re:CPP Check Runs Clean but found these Style Issues on Latest Git...
by Dan Kegel 17 Jan '10

17 Jan '10

You have some false positives, e.g. dlls/gdi32/enhmfdrv/mapping.c 1 The function EMFDRV_ModifyWorldTransform' is never used That function is indeed used in dlls/gdi32/enhmfdrv/init.c; the struct EMFDRV_Funcs is initialized with it. I guess cppcheck doesn't grok function pointers yet? - Dan

1 0

CPP Check Runs Clean but found these Style Issues on Latest Git...
by chris ahrendt 17 Jan '10

17 Jan '10

Don't know if anyone is interested in this or not but I thought I would send this out to the list. CPPCheck is now running clean on the GIT tree... but its showing some style issues. If they are there for API compatibility let me know and I will ignore them from now on. Here they are: File Line Style Problem dlls/dnsapi/ns_name.c 1 The function dns_ns_name_skip' is never used The function dns_ns_name_uncompress' is never used dlls/gdi32/enhmfdrv/mapping.c 1 The function EMFDRV_ModifyWorldTransform' is never used The function EMFDRV_OffsetViewportOrg' is never used The function EMFDRV_OffsetWindowOrg' is never used The function EMFDRV_ScaleViewportExt' is never used The function EMFDRV_ScaleWindowExt' is never used The function EMFDRV_SetMapMode' is never used The function EMFDRV_SetViewportExt' is never used The function EMFDRV_SetViewportOrg' is never used The function EMFDRV_SetWindowExt' is never used The function EMFDRV_SetWindowOrg' is never used The function EMFDRV_SetWorldTransform' is never used dlls/gdi32/mfdrv/dc.c 1 The function MFDRV_AbortPath' is never used The function MFDRV_BeginPath' is never used The function MFDRV_CloseFigure' is never used The function MFDRV_EndPath' is never used The function MFDRV_ExcludeClipRect' is never used The function MFDRV_FillPath' is never used The function MFDRV_FlattenPath' is never used The function MFDRV_IntersectClipRect' is never used The function MFDRV_OffsetClipRgn' is never used The function MFDRV_RestoreDC' is never used The function MFDRV_SaveDC' is never used The function MFDRV_SelectClipPath' is never used The function MFDRV_SetBkMode' is never used The function MFDRV_SetMapperFlags' is never used The function MFDRV_SetPolyFillMode' is never used The function MFDRV_SetRelAbs' is never used The function MFDRV_SetROP2' is never used The function MFDRV_SetStretchBltMode' is never used The function MFDRV_SetTextAlign' is never used The function MFDRV_SetTextCharacterExtra' is never used The function MFDRV_SetTextJustification' is never used The function MFDRV_StrokeAndFillPath' is never used The function MFDRV_StrokePath' is never used The function MFDRV_WidenPath' is never used dlls/rpcrt4/rpc_transport.c 1 The function RpcNetworkIsProtseqValidA' is never used dlls/rpcrt4/rpc_transport.c 700 The scope of the variable b_handle can be reduced dlls/wininet/cookie.c 1 The function IsDomainLegalCookieDomainW' is never used dlls/wininet/cookie.c 225 The scope of the variable len can be reduced dlls/wininet/dialogs.c 132 The scope of the variable q can be reduced dlls/wininet/dialogs.c 181 The scope of the variable u_len can be reduced dlls/wininet/ftp.c 359 The scope of the variable nResCode can be reduced dlls/wininet/ftp.c 1261 The scope of the variable retval can be reduced dlls/wininet/http.c 1 The function IsHostInProxyBypassList' is never used dlls/wininet/http.c 750 The scope of the variable userlen can be reduced dlls/wininet/http.c 751 The scope of the variable passlen can be reduced dlls/wininet/http.c 3355 The scope of the variable lpszCookies can be reduced dlls/wininet/http.c 3365 The scope of the variable cnt can be reduced dlls/wininet/http.c 3868 The scope of the variable headerlen can be reduced dlls/wininet/internet.c 1 The function DllMain' is never used dlls/wininet/internet.c 1464 The scope of the variable lpszNetLoc can be reduced dlls/wininet/internet.c 2712 The scope of the variable len can be reduced dlls/wininet/internet.c 2714 The scope of the variable status can be reduced dlls/wininet/urlcache.c 1 The function CreateUrlCacheContainerA' is never used The function CreateUrlCacheContainerW' is never used The function DeleteUrlCacheContainerA' is never used The function DeleteUrlCacheContainerW' is never used The function FindFirstUrlCacheContainerA' is never used The function FindFirstUrlCacheContainerW' is never used The function FindNextUrlCacheContainerA' is never used The function FindNextUrlCacheContainerW' is never used The function FreeUrlCacheSpaceA' is never used The function FreeUrlCacheSpaceW' is never used The function RegisterUrlCacheNotification' is never used dlls/wininet/urlcache.c 155 struct or union member _URLCACHE_HEADER::dwBlocksInUse' is never used dlls/wininet/urlcache.c 159 struct or union member _URLCACHE_HEADER::dwUnknown4' is never used dlls/wininet/urlcache.c 160 struct or union member _URLCACHE_HEADER::dwUnknown5' is never used dlls/wininet/urlcache.c 161 struct or union member _URLCACHE_HEADER::dwUnknown6' is never used dlls/wininet/urlcache.c 164 struct or union member _URLCACHE_HEADER::Unknown8' is never used dlls/wininet/urlcache.c 673 The scope of the variable error can be reduced dlls/wininet/urlcache.c 2190 The scope of the variable dwError can be reduced dlls/wininet/urlcache.c 2438 The scope of the variable len can be reduced dlls/wininet/urlcache.c 2731 The scope of the variable dwError can be reduced dlls/wininet/urlcache.c 2733 The scope of the variable len can be reduced libs/port/spawn.c 39 The scope of the variable wret can be reduced libs/wpp/ppl.yy.c 393 struct or union member yy_trans_info::yy_verify' is never used libs/wpp/ppl.yy.c 394 struct or union member yy_trans_info::yy_nxt' is never used libs/wpp/ppl.yy.c 3942 The scope of the variable new_alloc can be reduced libs/wpp/ppl.yy.c 4152 The scope of the variable new_alloc can be reduced libs/wpp/ppy.tab.c 265 struct or union member YYSTYPE::iptr' is never used libs/wpp/preproc.c 321 The scope of the variable len can be reduced loader/preloader.c 1 The function __bb_init_func' is never used The function __stack_chk_fail_local' is never used The function __stack_chk_fail' is never used The function wld_start' is never used tools/widl/client.c 80 The scope of the variable method_count can be reduced tools/widl/header.c 717 The scope of the variable first_iface can be reduced tools/widl/header.c 803 The scope of the variable first_iface can be reduced tools/widl/parser.tab.c 432 struct or union member YYSTYPE::array_dims' is never used tools/widl/parser.tab.c 439 struct or union member YYSTYPE::func_list' is never used tools/widl/parser.yy.c 388 struct or union member yy_trans_info::yy_verify' is never used tools/widl/parser.yy.c 389 struct or union member yy_trans_info::yy_nxt' is never used tools/widl/proxy.c 591 The scope of the variable first_func can be reduced tools/winebuild/import.c 227 The scope of the variable i can be reduced tools/winebuild/parser.c 913 The scope of the variable i can be reduced tools/winebuild/res32.c 281 The scope of the variable i can be reduced tools/winebuild/res32.c 600 The scope of the variable err can be reduced Chris

2 1

Re: [PATCH] mmdevapi: Add some basic tests for property store
by Paul Vriens 17 Jan '10

17 Jan '10

On 01/17/2010 02:11 PM, Maarten Lankhorst wrote: > +static void test_propertystore(IPropertyStore *store) > +{ > +} Is that one supposed to be empty ? -- Cheers, Paul.

2 1

Re: [Kernel32]Test for Bug 21292: Createfile creating with illegal char in name
by Paul Vriens 17 Jan '10

17 Jan '10

On 01/17/2010 01:27 PM, Uwe Bonnes wrote: > > CreateFile with an illegal character in the name fail on all systems beside > NT4 and wine when ordered to create the file. No test errors on my mchines > and the winetestbot (Job 319) If creating the file succeeds you should close the handle and delete the file. -- Cheers, Paul.

1 0

Re: sti: add launch application registry
by Paul Vriens 17 Jan '10

17 Jan '10

On 01/17/2010 10:09 AM, Damjan Jovanovic wrote: > + else > + skip("No StiCreateInstanceW function\n"); Shouldn't that be a win_skip() ? Why don't you do something like: if (!pStiCreateInstanceW) { win_skip("No StiCreateInstanceW function\n"); return; } That way you also get rid of one level of indentation for the big block. -- Cheers, Paul.

1 0

Winetest: What to do if NT4 behaves other then W2k and up
by Uwe Bonnes 17 Jan '10

17 Jan '10

Wine Bug 21292 shows a problem with CreateFileA("bla/n", GENERIC_READ, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL) All winebot systems beside WNT4WSSP6 return ERROR_INVALID_NAME 123L, while wine and NT4 happily open the file. How to proceed? === WNT4WSSP6 (NT4 Workstation SP6 (English, IE2)) === file.c:875: Test failed: CreateFileA failed on nonexist.ent/, hFile 000000B4, err=0, should be 123 === W2KPROSP4 (Windows 2000 Professional SP4) === No test failures found === WXPPROSP3 (XP Professional SP3 (English, IE6)) === No test failures found === W2K3R2SESP2 (Server 2003 R2 Standard Edition SP2) === No test failures found === WVISTAADM (Windows Vista (English, IE7)) === No test failures found === W2K8SE (Server 2008 Standard Edition) === No test failures found -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

3 2

Re: include: rename LIST_ENTRY to WINE_LIST_ENTRY to prevent a conflict on *BSD/OSX (resend) (1/7)
by Alexandre Julliard 17 Jan '10

17 Jan '10

Austin English <austinenglish(a)gmail.com> writes: > Subject: [PATCH 1/7] include: rename LIST_ENTRY to WINE_LIST_ENTRY to prevent a conflict on *BSD/OSX Don't do that. Fix the includes order in the files that fail to compile. -- Alexandre Julliard julliard(a)winehq.org

1 0

Unable to connect to #winehackers
by James Mckenzie 17 Jan '10

17 Jan '10

All: I have been trying to connect to #winehackers from my Mac using Conversation. However, this is not working as I am not receiving the welcome screen from irc.freenode.net. Anyone else experiencing this problem and have a workaround. I would really like to get onto winehackers to discuss the patch I've been working on. James McKenzie

3 2

Re: Unable to connect to #winehackers
by James Mckenzie 17 Jan '10

17 Jan '10

>Hi James, > >> I have been trying to connect to #winehackers from my Mac using Conversation. However, this is not working as I am not receiving the welcome screen from irc.freenode.net. > >There's possibly some issue with Freenode, as is not uncommon. Have you >tried connecting to any particular Freenode server manually? I seem to >be on "lindbohm.freenode.net", and it's working fine. > Owen: Thank you. However sending /msg nickserv help caused the program to crash. Also when I attempt to connect to winehackers I don't get the chat window. I will ask another MacOSX developer what he is using these days. James McKenzie

3 2

Code review request, fix for PATH setting bug 21322
by Dan Kegel 16 Jan '10

16 Jan '10

I was surprised to find that Wine didn't handle system-wide and user-local PATH together properly. The bug and a proposed fix are at http://bugs.winehq.org/show_bug.cgi?id=21322 Could someone review the patch before I risk sending it to wine-patches? I think it's clean, but my luck hasn't been good lately. Thanks, Dan

2 1

Re: include: rename LIST_ENTRY to WINE_LIST_ENTRY to prevent a conflict on *BSD/OS X
by Nikolay Sivov 15 Jan '10

15 Jan '10

On 1/16/2010 02:12, Austin English wrote: > See bug 21320. > LIST_FOR_EACH_SAFE is inconsistent after your patch. Also I think a shorter variant something like WLIST_... is preferable, but it's a subject of discussion.

2 1

Usage of libxml2 for several modules
by Nikolay Sivov 15 Jan '10

15 Jan '10

I'm thinking about implementing xmllite library - its interface is almost the same as xmlTextReader/Writer from libxml2 so it's potentially a thin wrapper, and it's good. The problem is that libxml2 is not reentrant. This isn't a problem for xmllite itself, cause it's not thread safe too, but: we already have a msxml3 module that loads libxml2. If let's say a process with 2 threads use msxml3 for first and xmllite for second then it's not safe anymore, cause both modules use the same libxml2 instance. If I'm right then only solution is to link to libxml2 statically from each module. Is it an acceptable way? P.S. having a separate copy of libxml2 allows to tweak its namespace support (I believe there's some discussions of that problem in bugzilla).

1 0

GSoC D3DX9 work
by Tony Wasserka 15 Jan '10

15 Jan '10

Hi everyone, I probably should've written this mail a few months earlier, but I had hoped that I'd get some spare time to work on Wine stuff. But to face reality, I'm having A-levels-like graduation (abitur in Germany) in the comming months. I have to prepare a skilled work until the end of january, put a great bunch of learning for the basic course exams and another one for the abitur exams themselves. The past months weren't any relaxing either. It's not that I was overstrained with school and about to get a burn-out or something, but I just lack the time and/or often motivation to work on the d3dx9 dll. This mail is basically for searching for someone to integrate the texture, mesh and font. The font code may be the easiest to integrate (or at least to understand), the texture stuff is the most profitable (as most games which use d3dx require its texture loading functions) and.. the mesh code is at least useful for the DX SDK samples (although these have yet other problems in Wine ranging from incomplete dx10 support over certain unicode functions to the incompatible msvc++ runtime). I know this may sound like "here, I hacked together some code, now anyone do the dirty work and integrate it, write tests, etc...", but especially concerning the visual tests, I think I'd spend my time better on other stuff than writing visual tests for stuff of which I'm pretty certain about that it works fine (ofc I see a point in tests though, but visual tests are a double-edged sword in that regard). I do have numerous tests for the non-visual part, and some functions don't even need visual tests. Especially the texture code consists basically of a) the file loading routines b) pixel format conversion c) filtering, where a, b and c are needed by only one function and d) functions which call that one function with some fancy magic behing (e.g. compability checks, auto-mipmap generation, combining file loading and conversion, etc). So if the one function (D3DXLoadSurfaceFromMemory) is implemented, things will get a lot easier (it actually is already partially implemented by me). So - if anyone is interested in working with my code (CC'd this to David - maybe you are? If not, never mind), I'd be willing to help that one with understanding the code and to explain what still needs to be done, and how I think things should be done (I still have a meanwhile quite compact list of TODOs). The code can be accessed at http://repo.or.cz/w/wine/d3dx9TW.git (in the "Merge" branch, sorry for ****ing up branching there, was my first public repo) and at http://code.google.com/p/google-summer-of-code-2009-wine/downloads/list (a more compact and organized one). Note that I'm not sure whether the code there is up-to-date, I might still have some patches on my hard disk which improve things. But the code there gives a pretty good insight in what's all this about, in case really anyone steps up I'll provide him with the most up-to-date work of mine. If there's anything anyone might want to ask, just answer this mail or contact me directly on irc at #winehackers, my nick is BigBrain and I'm around quite often. Best regards, Tony Wasserka

1 0

Legal issues with wine development
by Benjamin Zink 15 Jan '10

15 Jan '10

Hello, I understand you aren't allowed to look at the source code. The question I have is are you allowed to look at the headers and is an API that's auto generated from the source ok to look at? http://www.cppdoc.com/ has a javadoc style mfc api auto generated from the mfc source. Is this an ok thing to look at? Thank you, Benjamin Zink

3 2

Re: [2/3] user32/tests: Add test for EM_GETIMESTATUS and EM_SETIMESTATUS.
by Paul Vriens 15 Jan '10

15 Jan '10

On 01/15/2010 02:22 PM, Kusanagi Kouichi wrote: > Signed-off-by: Kusanagi Kouichi<slash(a)ac.auone-net.jp> > --- > dlls/user32/tests/Makefile.in | 2 +- > dlls/user32/tests/edit.c | 59 +++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 60 insertions(+), 1 deletions(-) > Hi Kusanagi, These tests fail on Vista+ so it seems: https://winetestbot.geldorp.nl/JobDetails.pl?Key=309 -- Cheers, Paul.

1 0

Re: msvcrt/tests: add some demangle tests
by Christian Costa 15 Jan '10

15 Jan '10

Maybe you can do it for ?swprintf@@YAHPA_WIPB_WZZ as well... André Hentschel a écrit : > somehow regarding http://source.winehq.org/patches/data/57476 > --- > dlls/msvcrt/tests/cpp.c | 3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/dlls/msvcrt/tests/cpp.c b/dlls/msvcrt/tests/cpp.c > index 106ef73..a75883d 100644 > --- a/dlls/msvcrt/tests/cpp.c > +++ b/dlls/msvcrt/tests/cpp.c > @@ -1034,6 +1034,9 @@ static void test_demangle(void) > /* 113 */ {"?f@T@@QAEHQAY1BE@BO@$$CBD@Z", "public: int __thiscall T::f(char const (* const)[20][30])"}, > /* 114 */ {"??0?$Foo@U?$vector_c@H$00$01$0?1$0A@$0A@$0HPPPPPPP@$0HPPPPPPP@$0HPPPPPPP@$0HPPPPPPP@$0HPPPPPPP@$0HPPPPPPP@$0HPPPPPPP@$0HPPPPPPP@$0HPPPPPPP@$0HPPPPPPP@$0HPPPPPPP@$0HPPPPPPP@$0HPPPPPPP@$0HPPPPPPP@$0HPPPPPPP@@mpl@boost@@@@QAE@XZ", > "public: __thiscall Foo<struct boost::mpl::vector_c<int,1,2,-2,0,0,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647> >::Foo<struct boost::mpl::vector_c<int,1,2,-2,0,0,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647> >(void)"}, > +/* 115 */ {"?swprintf@@YAHPAGIPBGZZ", "int __cdecl swprintf(unsigned short *,unsigned int,unsigned short const *,...)"}, > +/* 116 */ {"?vswprintf@@YAHPAGIPBGPAD@Z", "int __cdecl vswprintf(unsigned short *,unsigned int,unsigned short const *,char *)"}, > +/* 117 */ {"?vswprintf@@YAHPA_WIPB_WPAD@Z", "int __cdecl vswprintf(wchar_t *,unsigned int,wchar_t const *,char *)"}, > > }; > int i, num_test = (sizeof(test)/sizeof(test[0])); >

1 0

Re: [2/3] user32/tests: Add test for EM_GETIMESTATUS and EM_SETIMESTATUS.
by Nikolay Sivov 15 Jan '10

15 Jan '10

On 1/15/2010 16:22, Kusanagi Kouichi wrote: > + > + imc = ImmGetContext(hwEdit); > + if (!imc) > + { > + trace("ImmGetContext failed.\n"); > + DestroyWindow(hwEdit); > + return; > + } > + > Hi. A minor correction needed here - should be win_skip(), not just trace() with something like "not implemented", not just failed.

1 0

MFC42.dll implementation
by Benjamin Zink 15 Jan '10

15 Jan '10

Hello, I was thinking about starting a wine implementation of mfc42.dll and was wondering if anyone had already started or had some tips on where to start. Thank you, Benjamin Zink

2 1

Re: [PATCH 1/4] jscript: Added implementation of Array.reverse
by Jacek Caban 15 Jan '10

15 Jan '10

Hi Piotr, On 1/15/10 1:17 AM, Piotr Caban wrote: > --- > dlls/jscript/array.c | 37 +++++++++++++++++++++++++++++++++++-- > dlls/jscript/tests/api.js | 26 ++++++++++++++++++++++++++ > 2 files changed, 61 insertions(+), 2 deletions(-) > > > + if(hres1 == DISP_E_UNKNOWNNAME) + jsdisp_delete_idx(jsthis, l); + else + jsdisp_propput_idx(jsthis, l,&v1, ei, sp); + + if(hres2 == DISP_E_UNKNOWNNAME) + jsdisp_delete_idx(jsthis, k); + else + jsdisp_propput_idx(jsthis, k,&v2, ei, sp); You should check error codes of these calls. Jacek

1 0

Re: kernel32/tests: do not compare handle with zero directly (Smatch)
by Michael Stefaniuc 14 Jan '10

14 Jan '10

Andre, this is actually a false positive in the file_handles Smatch script. Or a valid bug requiring an other solution; depending on the point of view. On 01/14/2010 11:09 PM, André Hentschel wrote: > --- > dlls/kernel32/tests/virtual.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/kernel32/tests/virtual.c b/dlls/kernel32/tests/virtual.c > index 5187a97..2931374 100644 > --- a/dlls/kernel32/tests/virtual.c > +++ b/dlls/kernel32/tests/virtual.c > @@ -583,7 +583,7 @@ static void test_MapViewOfFile(void) > name = "Foo"; file is used as a HFILE before this line and should be checked against INVALID_HANDLE_VALUE and not NULL. > file = CreateFileMapping( INVALID_HANDLE_VALUE, NULL, PAGE_READWRITE, 0, 4096, name ); file is now a normal HANDLE and should be checked against NULL. > } > - ok( file != 0, "CreateFileMapping PAGE_READWRITE error %u\n", GetLastError() ); This is ok. > + ok( !!file, "CreateFileMapping PAGE_READWRITE error %u\n", GetLastError() ); The real fix is either for me to mark it as a false positives. Or to make file a HFILE and use an other HANDLE variable for the mmap. > SetLastError(0xdeadbeef); > mapping = OpenFileMapping( FILE_MAP_READ, FALSE, name ); bye michael

1 0

Re: ntoskrnl: Implement ExSystemTimeToLocalTime and ExLocalTimeToSystemTime
by Alexandre Julliard 14 Jan '10

14 Jan '10

Erich Hoover <ehoover(a)mines.edu> writes: > Real Name: > Erich Hoover > Description: > The attached patch implements ExSystemTimeToLocalTime and > ExLocalTimeToSystemTime (Bug #19395), which are necessary to allow the > Sentinel Protection service to load (the Sentinel Protection service > is required by the full version of ZEMAX). Without the patch the > service will crash every time Wine loads, slowing down the launching > of all applications. > Changelog: > ntoskrnl: Implement ExSystemTimeToLocalTime and ExLocalTimeToSystemTime. You most likely want to use RtlSystemTimeToLocalTime etc. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH] Implement OleCreatePropertyFrame (try 2)
by Geoffrey Hausheer 14 Jan '10

14 Jan '10

On Wed, Jan 13, 2010 at 10:38 PM, Piotr Caban wrote: > Hi, > > There're still some things that needs to be changed. Thank you for the continued feedback. > > In pixels_to_dialog_units: > + *basex = ((float)size.cx/26+1)/2; > > + *x_pixels = MulDiv(*x_pixels, 4, *basex); > I proposed doing the computations on floats so the dialog size is more > accurate. If it was working for you correctly than it's probably better > to keep it the way I proposed. The cast in the patch you've sent doesn't > change anything. > If there are reasons to make the computations on integers it's better to > use GdiGetCharDimensions function. My understanding is that your method is to get the average font width. I have no idea if that is similar to how MapDialogRect works, so I have no idea if it more correct or not. So I haven't any idea if the accuracy of using float is really more accurate with respect to Windows or not. Looking through the dialog code in user32, GetDialogBaseUnits just returns the value of GdiGetCharDimensions (which isn't right here), so I don't see a better way than to use a heuristic. > > I think that pixels_to_dialog_units function should be deleted and it's > code move to OleCreatePropertyFrameIndirect. It was originally meant to implement the inverse of MapDialogRect. Now that it is precomputing the base units, it probably doesn't make sense in its current form. > > + /* This was expected to work but didn't: > + * LONG baseunits = GetDialogBaseUnits(); > + * basex = LOWORD(baseunits); > + * basey = HIWORD(baseunits); > + */ > This comment is not correct. GetDialogBaseUnits is somehow strange and > should be avoided. The comment is correct in that it is how MSDN says it should work, but it obviously doesn't. I think it is valuable to make it clear that there is a reason for the heuristic. > > About PropertyPageSite interface: > You have implemented AddRef and Release functions but you don't really > care about reference counter. The object should be freed when the > counter reaches 0. Well, I didn't implement proper COM objects because I didn't see the need. Memory is allocated and freed in OlePropertyFrameIndirect. But COM objects must present AddRef/Release functions, so I have them. Is the preference here to build the proper COM object and allocate/free individually, or can I implement the AddRef/Release functions as stubs (which is basically what they are now) > > +typedef struct { > + struct { > + DLGTEMPLATE dlg; > + WORD menu; > + WORD class; > + WORD caption; > + WORD font; > + } dialog; > + OLEPropertyPageSite pps; > + IPropertyPage *propPage; > +} OLEPropertyFrame; > You don't need font field. But I do need the WORD to be present, as MSDN clearly states that you must reserve 4 WORDS after the DLGTEMPLATE. Since its general use is for 'font' I figured I'd name it properly. If it is really bothersome, I could call it 'reserved' or something equivalent. I probably won't get to this for several days. My development computer will be out of commission for a while. Thanks again, .Geoff

1 0

Patch: bug 19355, Wine web site, link to the previous version announcement in section "changes since"
by Vincent Cadet 14 Jan '10

14 Jan '10

Hi peoople. A couple of months ago, I submitted a patch I wrote to add a backlink to the previous version in WineHQ announcement page. As it has still no been applied I am sending it again here. It actually adds a few (6) lines of PHP code to the web site's template, include/plugins/announce.php . I ahve also submitted this patch into WineHQ bugzilla ( http://bugs.winehq.org/show_bug.cgi?id=19355 ). May I ask for comments about this patch? Thanks a lot in advance, Vince C.

3 4

Re: Wine AppDB xmlexport script
by Austin English 14 Jan '10

14 Jan '10

On Tue, Jan 12, 2010 at 8:17 AM, John Brezerk <brezerk(a)gmail.com> wrote: > Hi to All. > > I'd like to present php scripts ( attached xmlexport.tar.gz ) which make > possible for third party applications to query appdb database. > After processing user requests, script generates xml view. > Originally this script was created for q4wine ( > http://q4wine.brezblock.org.ua/ ) project. Neat! There's been talk about doing something like this for a while, but no one's taken the initiative to do it. However, I don't think you'll have much luck getting it in the AppDB's source repository, without having a discussion on wine-devel about it first. > It's licese is GPL v3. Is there any chance of a different license? Wine is currently LGPL 2.1, it'd be nice to have the same license, if possible... -- -Austin

5 4

Re: [PATCH] Implement OleCreatePropertyFrame (try 2)
by Piotr Caban 14 Jan '10

14 Jan '10

Hi, There're still some things that needs to be changed. In prop_sheet_proc: + case WM_DESTROY: + { + OLEPropertyFrame *opf = (OLEPropertyFrame *)GetWindowLongPtrW(hwnd, DWLP_USER); + if(opf) { + IPropertyPage_Show(opf->propPage, SW_HIDE); + IPropertyPage_Deactivate(opf->propPage); + SetWindowLongPtrW(hwnd, DWLP_USER, (LONG)NULL); + } + } there's no break/return In pixels_to_dialog_units: + *basex = ((float)size.cx/26+1)/2; + *x_pixels = MulDiv(*x_pixels, 4, *basex); I proposed doing the computations on floats so the dialog size is more accurate. If it was working for you correctly than it's probably better to keep it the way I proposed. The cast in the patch you've sent doesn't change anything. If there are reasons to make the computations on integers it's better to use GdiGetCharDimensions function. I think that pixels_to_dialog_units function should be deleted and it's code move to OleCreatePropertyFrameIndirect. + /* This was expected to work but didn't: + * LONG baseunits = GetDialogBaseUnits(); + * basex = LOWORD(baseunits); + * basey = HIWORD(baseunits); + */ This comment is not correct. GetDialogBaseUnits is somehow strange and should be avoided. About PropertyPageSite interface: You have implemented AddRef and Release functions but you don't really care about reference counter. The object should be freed when the counter reaches 0. +typedef struct { + struct { + DLGTEMPLATE dlg; + WORD menu; + WORD class; + WORD caption; + WORD font; + } dialog; + OLEPropertyPageSite pps; + IPropertyPage *propPage; +} OLEPropertyFrame; You don't need font field. Cheers, Piotr

1 0

Re: gdi32: Use the LOGFONT charset field on OEM font creation
by Ilya Shpigor 13 Jan '10

13 Jan '10

Hi, Is this patch incorrect or more tests are needed? Dmitry said that there are needed additional tests, but you wouldn't like to commit these. Please explain my mistakes. -- Best regards, Ilya Shpigor.

1 0

Re: wineoss.drv: Ignore volume settings on primary buffer
by Michael Stefaniuc 13 Jan '10

13 Jan '10

Maarten, Maarten Lankhorst wrote: > dsound shouldn't be able to mess with the system-wide volume if this is a deliberate design decision then the FIXME("stub") is wrong. It needs to be replaced by a TRACE (or WARN if you insist) with a message like: "Explicitly ignoring wodSetVolume request; dsound shouldn't mess with the system-wide volume". > Fixes bug 15710 and makes the bsd's happier > --- > --- a/dlls/wineoss.drv/dsrender.c > +++ b/dlls/wineoss.drv/dsrender.c > @@ -533,14 +533,7 @@ static HRESULT WINAPI IDsDriverBufferImpl_SetVolumePan(PIDSDRIVERBUFFER iface, P > { > DWORD vol; > IDsDriverBufferImpl *This = (IDsDriverBufferImpl *)iface; > - TRACE("(%p,%p)\n",This,pVolPan); > - > - vol = pVolPan->dwTotalLeftAmpFactor | (pVolPan->dwTotalRightAmpFactor << 16); > - > - if (wodSetVolume(This->drv->wDevID, vol) != MMSYSERR_NOERROR) { > - WARN("wodSetVolume failed\n"); > - return DSERR_INVALIDPARAM; > - } > + FIXME("(%p,%p) stub\n",This,pVolPan); > > return DS_OK; > } thanks bye michael

1 0

Re: [rsaenh/tests] Don't check result twice (Coccinelle)
by Michael Stefaniuc 13 Jan '10

13 Jan '10

Hi Paul, Paul Vriens wrote: > We already check and return FALSE a few lines up. > > Found with the help of Coccinelle and the CocciCheck scripts. > > Changelog > Don't check result twice (Coccinelle) > --- a/dlls/rsaenh/tests/rsaenh.c +++ b/dlls/rsaenh/tests/rsaenh.c @@ -275,7 +275,6 @@ static BOOL derive_key(ALG_ID aiAlgid, HCRYPTKEY *phKey, DWORD len) return FALSE; } ok(result, "%08x\n", GetLastError()); - if (!result) return FALSE; result = CryptHashData(hHash, pbData, sizeof(pbData), 0); ok(result, "%08x\n", GetLastError()); if (!result) return FALSE; that is not the same "result"; it gets a new value after the first "return FALSE". bye michael

3 5

Re: [PATCH 3/4] msxml3/xmldoc: IPersistStreamInit::InitNew() seems to do nothing for IXMLDocument
by Alistair Leslie-Hughes 12 Jan '10

12 Jan '10

On 13/01/2010 1:41 AM, Nikolay Sivov wrote: > IPersistStreamInit::InitNew() seems to do nothing for IXMLDocument > > > + hr = IPersistStreamInit_IsDirty(psi); > + todo_wine ok(hr == S_FALSE, "Expected S_OK, got %08x\n", hr); The message doesn't match the condition. Best Regards Alistair Leslie-Hughes

2 1

Re: installation problem with yesterday's git - NEVERMIND
by Susan Cragin 12 Jan '10

12 Jan '10

Somehow, the 4th time was a charm. Must be me? -----Original Message----- >I'm having an installation problem with yesterday's git. >err:msi:ITERATE_Actions Execution halted, action L"InstallSpeechAPI" returned 1627 >err:msi:ITERATE_Actions Execution halted, action L"ExecuteAction" returned 1627 > >Bug? >Regression test? >anyone want to see my whole terminal output?

1 0

installation problem with yesterday's git
by Susan Cragin 12 Jan '10

12 Jan '10

I'm having an installation problem with yesterday's git. err:msi:ITERATE_Actions Execution halted, action L"InstallSpeechAPI" returned 1627 err:msi:ITERATE_Actions Execution halted, action L"ExecuteAction" returned 1627 Bug? Regression test? anyone want to see my whole terminal output?

1 0

Re: Nikolay Sivov : advapi32: Free descriptor if it isn' t returned from GetSecurityInfo().
by Rob Shearman 12 Jan '10

12 Jan '10

2010/1/11 Alexandre Julliard <julliard(a)winehq.org>: > Module: wine > Branch: master > Commit: dbd76575ef8353484afa0b0d2da95760c26f34fe > URL: http://source.winehq.org/git/wine.git/?a=commit;h=dbd76575ef8353484afa0b0d2… > > Author: Nikolay Sivov <bunglehead(a)gmail.com> > Date: Fri Jan 8 21:05:21 2010 +0300 > > advapi32: Free descriptor if it isn't returned from GetSecurityInfo(). > > --- > > dlls/advapi32/security.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/dlls/advapi32/security.c b/dlls/advapi32/security.c > index 629a74a..babe468 100644 > --- a/dlls/advapi32/security.c > +++ b/dlls/advapi32/security.c > @@ -3118,6 +3118,8 @@ DWORD WINAPI GetSecurityInfo( > } > if (ppSecurityDescriptor) > *ppSecurityDescriptor = sd; > + else > + LocalFree(sd); > > return ERROR_SUCCESS; > } This is not correct as per the discussion on wine-devel, so it needs to be reverted. It causes these new Valgrind warnings: http://kegel.com/wine/valgrind/logs/2010-01-11-14.17/diff-advapi32_security… -- Rob Shearman

2 1

Re: d3drm: Merge Direct3DRMCreate with its implementation.
by Christian Costa 12 Jan '10

12 Jan '10

What the hell is the purpose of this patch ? d3drm.c is for the IDirect3DRMx objects implementations and there will be a file for each other object. Direct3DRMCreate is just an entry point and BTW many wine DirectX dlls are implemented this way because some objects can be also created using the class factory. And why are you removing the d3drm_private.h file at all ? More generally, is it really necessary to do some clean-up while I'm doing some work on this dll ? Christian Dmitry Timoshkov a écrit : > --- > dlls/d3drm/d3drm.c | 11 ++++++----- > dlls/d3drm/d3drm_main.c | 16 ---------------- > dlls/d3drm/d3drm_private.h | 31 ------------------------------- > 3 files changed, 6 insertions(+), 52 deletions(-) > delete mode 100644 dlls/d3drm/d3drm_private.h > > diff --git a/dlls/d3drm/d3drm.c b/dlls/d3drm/d3drm.c > index a0d7d3f..ae80d46 100644 > --- a/dlls/d3drm/d3drm.c > +++ b/dlls/d3drm/d3drm.c > @@ -27,20 +27,21 @@ > > #include "winbase.h" > #include "wingdi.h" > - > -#include "d3drm_private.h" > #include "d3drm.h" > > WINE_DEFAULT_DEBUG_CHANNEL(d3drm); > > typedef struct { > - IDirect3DRM lpVtbl; > + const IDirect3DRMVtbl *lpVtbl; > LONG ref; > } IDirect3DRMImpl; > > static const struct IDirect3DRMVtbl Direct3DRM_Vtbl; > > -HRESULT Direct3DRM_create(LPDIRECT3DRM* ppDirect3DRM) > +/*********************************************************************** > + * (D3DRM.@) > + */ > +HRESULT WINAPI Direct3DRMCreate(LPDIRECT3DRM* ppDirect3DRM) > { > IDirect3DRMImpl* object; > > @@ -53,7 +54,7 @@ HRESULT Direct3DRM_create(LPDIRECT3DRM* ppDirect3DRM) > return E_OUTOFMEMORY; > } > > - object->lpVtbl.lpVtbl = &Direct3DRM_Vtbl; > + object->lpVtbl = &Direct3DRM_Vtbl; > object->ref = 1; > > *ppDirect3DRM = (IDirect3DRM*)object; > diff --git a/dlls/d3drm/d3drm_main.c b/dlls/d3drm/d3drm_main.c > index 38a6a6c..d38159d 100644 > --- a/dlls/d3drm/d3drm_main.c > +++ b/dlls/d3drm/d3drm_main.c > @@ -20,12 +20,6 @@ > #include <stdarg.h> > #include "windef.h" > #include "winbase.h" > -#include "wingdi.h" > -#include "d3drm.h" > -#include "d3drm_private.h" > -#include "wine/debug.h" > - > -WINE_DEFAULT_DEBUG_CHANNEL(d3drm); > > /*********************************************************************** > * DllMain (D3DRM.@) > @@ -42,13 +36,3 @@ BOOL WINAPI DllMain( HINSTANCE inst, DWORD reason, LPVOID reserved ) > } > return TRUE; > } > - > -/*********************************************************************** > - * (D3DRM.@) > - */ > -HRESULT WINAPI Direct3DRMCreate(LPDIRECT3DRM* ppDirect3DRM) > -{ > - TRACE("(%p)\n", ppDirect3DRM); > - > - return Direct3DRM_create(ppDirect3DRM); > -} > diff --git a/dlls/d3drm/d3drm_private.h b/dlls/d3drm/d3drm_private.h > deleted file mode 100644 > index 091b076..0000000 > --- a/dlls/d3drm/d3drm_private.h > +++ /dev/null > @@ -1,31 +0,0 @@ > -/* > - * Direct3DRM private interfaces (D3DRM.DLL) > - * > - * Copyright 2010 Christian Costa > - * > - * This file contains the (internal) driver registration functions, > - * driver enumeration APIs and DirectDraw creation functions. > - * > - * This library is free software; you can redistribute it and/or > - * modify it under the terms of the GNU Lesser General Public > - * License as published by the Free Software Foundation; either > - * version 2.1 of the License, or (at your option) any later version. > - * > - * This library is distributed in the hope that it will be useful, > - * but WITHOUT ANY WARRANTY; without even the implied warranty of > - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > - * Lesser General Public License for more details. > - * > - * You should have received a copy of the GNU Lesser General Public > - * License along with this library; if not, write to the Free Software > - * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > - */ > - > -#ifndef __D3DRM_PRIVATE_INCLUDED__ > -#define __D3DRM_PRIVATE_INCLUDED__ > - > -#include "d3drm.h" > - > -HRESULT Direct3DRM_create(LPDIRECT3DRM* ppDirect3DRM); > - > -#endif /* __D3DRM_PRIVATE_INCLUDED__ */ >

2 4

Re: d3d8: Fix a ptrdiff_t warning on 64-bit.
by Alexandre Julliard 12 Jan '10

12 Jan '10

Nicolas Le Cam <niko.lecam(a)gmail.com> writes: > @@ -175,7 +175,7 @@ static DWORD d3d8_allocate_handle(struct d3d8_handle_table *t, void *object, enu > entry = t->free_entries; > if (entry->type != D3D8_HANDLE_FREE) > { > - ERR("Handle %u(%p) is in the free list, but has type %#x.\n", (entry - t->entries), entry, entry->type); > + ERR("Handle %tu(%p) is in the free list, but has type %#x.\n", (entry - t->entries), entry, entry->type); Please don't use that kind of printf formats, they are not portable. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH] wined3d: Do not try to use not available texture stages in set_tex_op_nvr
by Stefan Dösinger 12 Jan '10

12 Jan '10

> + if (stage > (gl_info->limits.texture_stages-1)) > + { > + ERR("Texture stage %d invalid (only %d availables)\n", stage, gl_info->limits.texture_stages); > + return; > + } In which situations does this occur? I guess its on some older nvidia GPU. I don't like the ERR here. If this occurs because an app ignores the d3d limits, then this should be a WARN. If this code is called because some other wined3d code doesn't honor the limits this should be fixed elsewhere. If this code is called correctly, and catching the limit violation in the state setter is the correct thing to do this should be a TRACE(e.g. the state handler is called because device creation dirtifies all states).

3 10

Re: dbghelp: merge dwarf code from ntdll/signal_x86_64.c
by Eric Pouech 11 Jan '10

11 Jan '10

André Hentschel a écrit : > thanks Eric Pouech for the reviews > --- > dlls/dbghelp/dwarf.c | 229 +++++++++++++++++++++++++++++++++++++++++--------- > dlls/dbghelp/dwarf.h | 15 ++++ > 2 files changed, 204 insertions(+), 40 deletions(-) > > diff --git a/dlls/dbghelp/dwarf.c b/dlls/dbghelp/dwarf.c > index 48e6351..d7f4f50 100644 > --- a/dlls/dbghelp/dwarf.c > +++ b/dlls/dbghelp/dwarf.c > @@ -241,6 +241,13 @@ static DWORD64 dwarf2_get_u8(const unsigned char* ptr) > return *(const UINT64*)ptr; > } > > +static DWORD64 dwarf2_parse_u8(dwarf2_traverse_context_t* ctx) > +{ > + unsigned long uvalue = dwarf2_get_u8(ctx->data); > + ctx->data += 8; > + return uvalue; > +} > + > static unsigned long dwarf2_get_leb128_as_unsigned(const unsigned char* ptr, const unsigned char** end) > { > unsigned long ret = 0; > @@ -344,6 +351,58 @@ static unsigned long dwarf2_parse_addr(dwarf2_traverse_context_t* ctx) > return ret; > } > > +static ULONG_PTR dwarf2_get_ptr( const unsigned char **p, unsigned char encoding, unsigned word_size) > +{ > + ULONG_PTR base; > + > + if (encoding == DW_EH_PE_omit) return 0; > + > + switch (encoding & 0xf0) > + { > + case DW_EH_PE_abs: > + base = 0; > + break; > + case DW_EH_PE_pcrel: > + base = (ULONG_PTR)*p; > I'm afraid I've got some further comments this is wrong, as it implies that the underlying ELF section (relative to p) is mapped at same address between the process dbghelp is working on (it has been mapped by the ELF loader) and where dbghelp has mapped some ELF sections (likely in another process) a proper fix will require some extra work I've started doing it So either so you do it properly, or you drop the EH frame support out of this patch A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

2 2

Re: MSVCRT: Handle \r at buffer boundary
by Alexandre Julliard 11 Jan '10

11 Jan '10

Uwe Bonnes <bon(a)hertz.ikp.physik.tu-darmstadt.de> writes: > @@ -1767,6 +1771,12 @@ static int read_i(int fd, void *buf, unsigned int count) > if (MSVCRT_fdesc[fd].wxflag & WX_TEXT) > { > DWORD i, j; > + if (bufstart[num_read-1] == '\r') > + { > + if(pushback) > + MSVCRT__lseeki64(fd, -1, SEEK_CUR); You can't use lseek for this, the file may not be seekable. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: user32: Do not allow a change of capture if the currently capture window is a menu unless explicitly specified (try2)
by Alexandre Julliard 11 Jan '10

11 Jan '10

Peter Dons Tychsen <donpedro(a)tdcadsl.dk> writes: > @@ -85,6 +85,17 @@ BOOL set_capture_window( HWND hwnd, UINT gui_flags, HWND *prev_ret ) > HWND previous = 0; > UINT flags = 0; > BOOL ret; > + GUITHREADINFO info; > + if(!GetGUIThreadInfo(GetCurrentThreadId(), &info)) > + { > + return FALSE; > + } > + > + /* if in menu mode, reject all requests to change focus, except if the menu bit is set */ > + if((info.flags & GUI_INMENUMODE) && !(gui_flags & GUI_INMENUMODE)) > + { > + return FALSE; > + } This should be handled on the server side. -- Alexandre Julliard julliard(a)winehq.org

2 5

Re: msvcrt: Add support for sprintf_s
by Jason Edmeades 11 Jan '10

11 Jan '10

>This doesn't seem correct to me You are right, its incomplete, but it also was based on the logic already in MSVCRT_vswprintf_s, which is just as incomplete! I'll happily just raise a bug report if the patch is insufficient, but in general all the _s special processing is missing from the printf* family, and the patch implements enough to get the basic functionality working. I probably should have put a fixme comment in like MSVCRT_vswprintf_s though but would that be enough? Jason

1 0

Re: msvcrt: Add support for sprintf_s
by Chris Robinson 11 Jan '10

11 Jan '10

This doesn't seem correct to me. According to MSDN, sprintf_s checks for valid formatting chars (in addition to the buffer and format arguments) and invokes an invalid parameter handler if something bad turns up. It then returns -1 with errno set to EINVAL if execution is allowed to continue. Additionally, if the buffer is too small to hold the resulting string, it is made an empty string and invokes the invalid parameter handler. It also guarantees the output buffer is null terminated. http://msdn.microsoft.com/en-us/library/ce3zzk1k(VS.80).aspx

2 1

Re: Implement OleCreatePropertyFrame
by Piotr Caban 11 Jan '10

11 Jan '10

Hi, In prop_sheet_proc you wrote: case PSN_APPLY: FIXME("(%p, %s, %s)\n", hwnd, "WM_NOTIFY", "PSN_APPLY"); IPropertyPage_Apply(opf->propPage); return TRUE; If I understand it correctly applying changes is fully implemented. Why there's a FIXME? Probably you wanted to use TRACE here. default: FIXME("(%p, %d, %ld, %p)\n", hwnd, msg, wparam, (void *)lparam); There's lots of messages that your're not going to handle (e.g. WM_SETCURSOR) so this FIXME will be very loud. In pixels_to_dialog_units function: You're using some hardcoded values here. Probably something like this would be better, but I'm not sure if it's correct: static void pixels_to_dialog_units(short *x_pixels, short *y_pixels) { int basey; float basex; HFONT font = GetStockObject(DEFAULT_GUI_FONT); HDC hdc = GetDC(NULL); TEXTMETRICW tm; SIZE size; font = SelectObject(hdc, font); GetTextMetricsW(hdc, &tm); GetTextExtentPoint32A(hdc, "ABCDEFGHIJKLMNOPQRSTUVWXYZ" "abcdefghijklmnopqrstuvwxyz", 52, &size); SelectObject(hdc, font); basex = ((float)size.cx/26+1)/2; basey = tm.tmHeight; *x_pixels = (float)(*x_pixels)*4/basex; *y_pixels = MulDiv(*y_pixels, 8, basey); } Of course the basex and basey values should be computed once. In OleCreatePropertyFrameIndirect it's probably good to add a FIXME, that dispidInitialProperty value is ignored. Please try to use the same formatting in whole file (e.g. you sometimes use white chars before brackets). Cheers, Piotr

1 0

Re: advpack: Use GetModuleHandle instead of LoadLibrary.
by Paul Vriens 11 Jan '10

11 Jan '10

On 01/05/2010 02:46 AM, James Hawkins wrote: > --- > dlls/advpack/tests/advpack.c | 7 +------ > 1 files changed, 1 insertions(+), 6 deletions(-) > Hi James, Don't think this works: advpack: 0 tests executed (0 marked as todo, 0 failures), 0 skipped. -- Cheers, Paul.

2 2

Re: [2/4] avifil32/tests: Initial-test-data-and-simple-test-for-avifil32-depends
by James McKenzie 10 Jan '10

10 Jan '10

Julius Schwartzenberg wrote: > These are resents of last week which are cleaned up more and with > Detlef's patch on which they depend in front. > > While looking at avifile, I noticed some strange behaviour. Because > some fixes may seem strange, I felt a test suite was really necessary > to show that this is really what's happening on Windows. All the tests > pass on both Windows 98 and Windows XP. > > C++ type comments are not allowed. Please mark second and subsequent submissions with [Try #] in the message header. It keeps us from guessing which submission is the latest. There is no requirement to submit subsequent parts of a patchset if there are no changes to them if changes in prior sections do not affect the code in them. James McKenzie

2 1

Re: avifil32: Overwrite dwRate in the audiostream with the nBlockAlign from the wave header
by Paul Vriens 10 Jan '10

10 Jan '10

On 01/10/2010 03:18 AM, Julius Schwartzenberg wrote: > I was stupid last week and sent patches in a serie that didn't actually > depend on each other. I'm resending them properly now. All fixes are > actually independent from each other. > > I started looking into some problems avifil32 had because Civilization > II would crash if it tried to play it's intro movie. > I created a small program to print information about the different > headers in AVI files and to play back the audio stream. Also with this > program, many AVI files failed to play (while they worked on Windows > with it). The fixes I introduce also allow my testing program to play > back everything correctly. > > These patches solve this problem and several other problems. > Hi Julius, Do any of these patches fix any of the tests? If so you should also change the tests by removing one or more todo_wine()'s. This could become tricky though if your tests patches are not committed before these ones. -- Cheers, Paul.

3 2

Re: ntdll/tests: Fix a test failure on NT4
by Paul Vriens 10 Jan '10

10 Jan '10

On 01/10/2010 05:44 PM, André Hentschel wrote: > --- > dlls/ntdll/tests/om.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/dlls/ntdll/tests/om.c b/dlls/ntdll/tests/om.c > index 1bab21d..e351813 100644 > --- a/dlls/ntdll/tests/om.c > +++ b/dlls/ntdll/tests/om.c > @@ -677,7 +677,8 @@ static void test_query_object(void) > ok( status == STATUS_SUCCESS, "NtQueryObject failed %x\n", status ); > ok( len> sizeof(UNICODE_STRING), "unexpected len %u\n", len ); > str = (UNICODE_STRING *)buffer; > - ok( sizeof(UNICODE_STRING) + str->Length + sizeof(WCHAR) == len, "unexpected len %u\n", len ); > + ok( sizeof(UNICODE_STRING) + str->Length == len /* WinNT */ || > + sizeof(UNICODE_STRING) + str->Length + sizeof(WCHAR) == len, "unexpected len %u\n", len ); > trace( "got %s len %u\n", wine_dbgstr_w(str->Buffer), len ); > pNtClose( handle ); > } Looks a bit like: http://source.winehq.org/patches/data/57319 Except that I used broken() for NT4 which IMHO makes more sense as this is the only platform with this issue. -- Cheers, Paul.

2 2

Re: Resent of [1/4] and [2/4] from avifil32/test serie
by Paul Vriens 10 Jan '10

10 Jan '10

On 01/10/2010 05:35 PM, Julius Schwartzenberg wrote: > First of all, my apologies for all the junk. I didn't fully understand > how the mail moderation exactly worked and made some wrong guesses. > > I'm going to use git send-email now as Henri suggested me, to resent two > patches from the serie as replies to this e-mail. Both with included > suggestions from Paul & Henri wine-devel. > > [1/4]: This is Detlef's patch from June 2008 with just the import > changed from "vfw32" to "avifil32" to work around bug 14085. > > http://www.winehq.org/pipermail/wine-patches/2008-June/056310.html > > > [2/4]: These are resents of last week which are cleaned up more and with > Detlef's patch on which they depend in front. > > While looking at avifile, I noticed some strange behaviour. Because some > fixes may seem strange, I felt a test suite was really necessary to show > that this is really what's happening on Windows. All the tests pass on > both Windows 98 and Windows XP. Remember that we have that great winetestbot (https://winetestbot.geldorp.nl/index.pl) which I encourage people to use as it covers NT4 up to W2K8R2 if needed. -- Cheers, Paul.

1 0

Re: Sorry!! Please drop the previous mails ^^^
by Henri Verbeet 10 Jan '10

10 Jan '10

2010/1/10 Julius Schwartzenberg <j.schwartzenberg(a)student.utwente.nl>: > My apologies to who'll read this. I found out a bit late my mailclient > sucked and used the wrong 'from' address. I've resent all my patches with > the proper address now, so all other mails from me may be dropped. > I'm not sure what was wrong with it? Afaik the address in the "From: " line in the patch is leading, unless it's obviously invalid. Note that just using "git send-email" avoids a lot of the common issues with patch submission.

2 1

Re: d3drm: The input quaternions are not changed when calling D3DRMQuaternionSlerp
by Henri Verbeet 10 Jan '10

10 Jan '10

2010/1/10 David Adam <david.adam.cnrs(a)gmail.com>: > + > +/* Test to show that the input quaternions are not changed */ > + expect_quat(q1,q1final); > + expect_quat(q2,q2final); > + You have some trailing spaces here.

1 0

Re: [1/4] avifil32/tests: Add initial tests
by Henri Verbeet 10 Jan '10

10 Jan '10

2010/1/10 Julius Schwartzenberg <julius.schwartzenberg(a)gmail.com>: > This is Detlef's patch from June 2008 with just the import changed from > "vfw32" to "avifil32" to work around bug 14085. > > http://www.winehq.org/pipermail/wine-patches/2008-June/056310.html > You should add a proper "From: " line to the patch when submitting patches for other people. If you use "git format-patch" it will do this automatically, provided you gave correct author information to "git commit".

1 0

Re: [PATCH] shell32: handle bad menu handle (Coverity)
by Nikolay Sivov 10 Jan '10

10 Jan '10

On 1/9/2010 16:59, Marcus Meissner wrote: > Hi, > > handle "invalid menu" return -1. Now with test. > > Ciao, Marcus > --- > dlls/shell32/shlmenu.c | 5 +++-- > dlls/shell32/tests/shlfileop.c | 13 +++++++++++++ > 2 files changed, 16 insertions(+), 2 deletions(-) > > > { > diff --git a/dlls/shell32/tests/shlfileop.c b/dlls/shell32/tests/shlfileop.c > index 0a5cdca..4d74b93 100644 > --- a/dlls/shell32/tests/shlfileop.c > +++ b/dlls/shell32/tests/shlfileop.c > Wrong file to place test in I think. > @@ -2224,6 +2224,17 @@ static void test_unicode(void) > ok(!file_existsW(UNICODE_PATH), "The directory should have been removed\n"); > } > > +extern HRESULT WINAPI Shell_MergeMenus (HMENU hmDst, HMENU hmSrc, UINT uInsert, UINT uIDAdjust, UINT uIDAdjustMax, ULONG uFlags); > + > This should got to shlobj.h. > +static void > +test_shlmenu(void) { > + HRESULT hres; > + hres = Shell_MergeMenus (0, 0, 0x42, 0x4242, 0x424242, 0); > + ok (hres == 0x4242, "expected 0x4242 but got %x\n", hres); > + hres = Shell_MergeMenus ((HMENU)42, 0, 0x42, 0x4242, 0x424242, 0); > + ok (hres == 0x4242, "expected 0x4242 but got %x\n", hres); > +} > + > Use a valid empty menu handle here as first parameter. Also I'd like to use more sane const values. > START_TEST(shlfileop) > { > InitFunctionPointers(); > @@ -2263,4 +2274,6 @@ START_TEST(shlfileop) > clean_after_shfo_tests(); > > test_unicode(); > + > + test_shlmenu(); > } > Function is available starting XP SP2 per msdn, so dynamic load should be used.

3 4

Re: [2/4] avifil32/tests: Initial-test-data-and-simple-test-for-avifil32-depends
by Paul Vriens 10 Jan '10

10 Jan '10

On 01/10/2010 03:15 AM, Julius Schwartzenberg wrote: > +static void create_avi_file(const COMMON_AVI_HEADERS *cah, char *filename) > +{ > + HANDLE hFile; > + DWORD written; > + > + hFile = CreateFile(filename, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL); > + > + ok(hFile != INVALID_HANDLE_VALUE, "Couldn't create file\n"); // GetTempFileName and GetTempPath Hi Julius, No C++ comment style please. -- Cheers, Paul.

1 0

Re: [PATCH] shell32: handle bad menu handle (Coverity)
by Nikolay Sivov 09 Jan '10

09 Jan '10

On 1/9/2010 16:59, Marcus Meissner wrote: > Hi, > > handle "invalid menu" return -1. > > Ciao, Marcus > --- > dlls/shell32/shlmenu.c | 5 +++-- > 1 files changed, 3 insertions(+), 2 deletions(-) > > nItem = GetMenuItemCount(hmDst); > + if (nItem == -1) > + return uIDMax; > Hi, Marcus. Could you please add a test for that? It seems trivial.

1 0

Re: [PATCH 1/2] mmdevapi: Add code to enumerate NOTPRESENT devices
by Alexandre Julliard 09 Jan '10

09 Jan '10

Maarten Lankhorst <m.b.lankhorst(a)gmail.com> writes: > @@ -33,6 +35,13 @@ > > WINE_DEFAULT_DEBUG_CHANNEL(mmdevapi); > > +static const WCHAR software_wine_mmdevapi[] = > + { 'S','o','f','t','w','a','r','e','\\','W','i','n','e','\\','m','m','d','e','v','a','p','i',0}; This looks suspicious. Why do you need a Wine-specific config for this? -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [d3d9/tests] Fix size parameter for memcmp (Coccinelle)
by Henri Verbeet 09 Jan '10

09 Jan '10

2010/1/8 Paul Vriens <paul.vriens.wine(a)gmail.com>: > - i = memcmp(decl, vertex_decl, sizeof(vertex_decl)); > + i = memcmp(decl, vertex_decl, sizeof(*vertex_decl)); I think that should be "num_elements * sizeof(*vertex_decl)" even.

1 0

Less than 300 Coverity errors !!
by Paul Vriens 08 Jan '10

08 Jan '10

Hi, Just wanted to mention the fact that Marcus (almost single-handedly for the last months) got the number of issues below 300. Only 11 of those are marked as either a bug or are pending. The rest is either false (Coverity thinks there is an error, but we don't) or to be ignored (for example: windows bug-for-bug compatibility or some deliberate tests). -- Cheers, Paul.

3 2

How should AVI files be detected in avifile?
by Julius Schwartzenberg 08 Jan '10

08 Jan '10

Hi, Maybe you know, I hope to submit several fixes and tests for avifile soon. Vitaliy Margolen pointed out I should be create proper temporary files in the system's tmp directory so I implemented this. This actually showed a new bug in Wine's avifile: Wine's avifile does not handle normal avi files with an filename extension different than avi (f.e. tmp), while Windows XP's avifile has no problems with those at all. The problem is in this part of the code: http://source.winehq.org/source/dlls/avifil32/api.c#L244 I discussed it with Roderick a bit on IRC and he said the whole registry check is flawed and there should be detection for AVI files based on the content of the file. I then did some tests and replaced line 247 (return AVIERR_UNSUPPORTED;) with "clsidHandler = CLSID_AVIFile;" which always forces the correct handler for AVI files. With that change I get the exact same behaviour as on Windows: Proper AVI files always work, irregardless of their filename extension. Files in which I replaced "AVI LIST" (the magic with which AVI files can be detected) with "AV2 LIST" in a hex editor fail on both Windows and Wine. On both they immediately fail with the error that my file is not an AVI file. So this means that there already is proper detection in Wine based on the content of the file! There is just one extra obstacle in front now. I'm not very familiar (yet) with COM, CLASS IDs and how files are generally handled in Wine. Also I don't really know much about VFW, I especially cannot imagine what other files than AVI files would need to be read using avifile (but from the code I except this is possible). So my question is: What do you think would be an appropriate way to solve this? Should I just remove the obstacle or add my change? Or do something completely different? Also if anyone can shed more light on the current idea behind the code, this would be welcome! Thanks a lot in advance, Julius

2 2

Re: Wine release 1.1.36
by James Hawkins 08 Jan '10

08 Jan '10

On Fri, Jan 8, 2010 at 11:28 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > The Wine development release 1.1.36 is now available. > > What's new in this release (see below for details): > - Completion of the 16-bit separation. Congrats Alexandre and co.! -- James Hawkins

1 0

IHlink::Navigate mystery value
by Andrew Eikum 08 Jan '10

08 Jan '10

I've been working the past few days on cleaning up low-hanging-fruit bugs relating to MSOffice. I've run into one bug for which I have a solution, but I have no explanation as to why the solution is correct. It's what Windows does, but I don't know why! This email's a bit long, but it describes the problem and various things I've tried to understand the solution. Hopefully someone reading this list has some ideas :) The bug is in PowerPoint. On native, when a slideshow is exited (i.e. go out of 'presentation mode'), the currently-displayed slide should become activated in the main 'editor' PowerPoint window. In Wine, however, the main window shows the slide that was active when the slideshow began. This makes resuming the slideshow from where you left off a big pain. The problem is in the hlink module, specifically with IHlink::Navigate (implemented in Wine as IHlink_fnNavigate around dlls/hlink/link.c:436). IHlink objects can contain an IHlinkSite reference, which the Navigate function makes calls to as it proceeds through navigation, as a sort of callback. The last call in IHlink::Navigate is to IHlinkSite::OnNavigationComplete. This function takes an HRESULT argument which, according to MSDN, should contain the final result of the navigation. Again, according to MSDN, IHlink::Navigate should return S_OK on success, error otherwise. Of course, reality is different from what MSDN claims. On native, IHlinkSite::OnNavigationComplete is consistently called by IHlink::Navigate with its HRESULT argument set to 0x40100. I have no idea what this value is supposed to represent. Every Windows version with an hlink DLL, on both x86 and x86_64, passes 0x40100 to the IHlinkSite when IHlink::Navigate is called. It doesn't seem to matter what the target of the navigation is (website, file on filesystem). See the tests linked below. Currently in Wine our IHlink::Navigate passes S_OK, as you'd expect from both the documentation and common sense. For whatever bizarre reason, however, PowerPoint requires that this HRESULT value be greater than zero. If zero (S_OK) is passed, then PowerPoint fails to restore the proper slide and just does nothing. If an error code is passed, PowerPoint pops up an error message, as you'd expect. But if a value greater than zero is passed (it's not picky about 0x40100), PowerPoint correctly opens the proper slide. So unfortunately, we need to do this "right" for PowerPoint to behave. Interpreted as an HRESULT, 0x40100 is DRAGDROP_S_DROP, a successful DND operation, as returned by DoDragDrop. Is it possible that Windows navigates to items by drag-dropping into the appropriate application? IHlink _does_ also implement IOleObject, which is the "object" passed by DoDragDrop. This interpretation seems unlikely, though, since all programs that are associated with a filetype (i.e. open with ShellExecute) must then implement IDropTarget. I'm not ruling this interpretation out, but I can't make sense of it. You'll note that the value looks something like a set of two bitflags. File access permissions were the first thing to come to mind, but Julliard said it looks nothing like permission flags that he's seen. I've looked at every constant in include with the value 0x40000 and seen nothing that looks relevant. I sent a hack implementation off to wine-patches, but it was rejected. Alexandre said he'd like a better investigation of where 0x40100 comes from. I've exhausted my knowledge and can think of no place to derive this value from. I'm here asking if the value stands out to anyone, or if there are any suggestions of things to probe or functions to poke to get some meaning attached to this number. Any ideas? My hackish fix, with tests: http://www.winehq.org/pipermail/wine-patches/2010-January/083470.html MSDN IHlink documentation: http://msdn.microsoft.com/en-us/library/aa767974%28VS.85%29.aspx MSDN IHlinkSite documentation: http://msdn.microsoft.com/en-us/library/aa767933%28VS.85%29.aspx Andrew

3 3

Re: advapi32/security: Free descriptor if it isn't returned from GetSecurityInfo()
by James Hawkins 08 Jan '10

08 Jan '10

On Fri, Jan 8, 2010 at 10:08 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > Free descriptor if it isn't returned from GetSecurityInfo() (Valgrind). > This is very wrong :-) You should read the comment above the test that causes the leak. Dan has notice to suppress this valgrind error, so it shouldn't show up in the logs after he adds the suppression. Thanks, James Hawkins

2 1

Re: [2/3] ntdll: fill unused tails of heap blocks if HEAP_FREE_CHECKING_ENABLED (take 3)
by Alexandre Julliard 08 Jan '10

08 Jan '10

Dan Kegel <dank(a)kegel.com> writes: > To check whether we're too early in process setup to > check global flags, I compare the arguments of RtlCreateHeap > with the ones used by the call in virtual_init(). This is > not especially clean, but I couldn't think of anything > better. I can hear Alexandre hitting the 'd' key already, > so if anyone has a better idea, please let me know. That's a sure hint that you shouldn't have submitted the patch. As I told you on IRC, you have to make the patch the best you possibly can *before* showing it to me. That's doubly true for a patch that has already seen several rounds. If you truly can't find a better way you can always ask for suggestions on IRC or wine-devel. Submitting broken patches (worse, that you already know are broken) is only going to make it harder for you to get anything in. -- Alexandre Julliard julliard(a)winehq.org

2 4

[2/3] ntdll: fill unused tails of heap blocks if HEAP_FREE_CHECKING_ENABLED (take 3)
by Joris Huizer 08 Jan '10

08 Jan '10

Dan Kegel, you wrote: To check whether we're too early in process setup to check global flags, I compare the arguments of RtlCreateHeap with the ones used by the call in virtual_init(). This is not especially clean, but I couldn't think of anything better. I was thinking, couldn't you place the RtlCreateHeap implementation with an internal function, that takes an extra argument (boolean or flags) to indicate whether to do this initialization step or not ? Then, call the internal function from virtual_init() with the boolean set, and have RtlCreateHeap just calling it, without the boolean set. I've seen something like this being done elsewhere (but for different reasons) I'm not sure whether this would be acceptable (performance-wise?) but it'd be cleaner I think. HTH, Joris

1 0

Re: Patch feedback requested for OleCreatePropertyFrame()
by Geoffrey Hausheer 08 Jan '10

08 Jan '10

Ok, I have reimplemented OleCreatePropertyFrame() from scratch. There is no code from Hidenori's patch in mine, nor did I use it as a reference (though of course I can't claim that I didn't learn anything from his patch during my previous cleanup) Would someone mind reviewing this for style/content? I still have no idea how to write a test for a modal dialog, so if a test is required for submission, I'd really appreciate someone giving me pointers on how to go about it. There are some features I didn't implement because I didn't really understand MDSN sufficiently (specifcially the IPropertyPageSite stuff), but it is mostly complete. .Geoff

3 2

Re: [2/3] ntdll: fill unused tails of heap blocks if HEAP_FREE_CHECKING_ENABLED (take 3)
by Alexandre Julliard 08 Jan '10

08 Jan '10

Dan Kegel <dank(a)kegel.com> writes: > @@ -1254,14 +1291,20 @@ HANDLE WINAPI RtlCreateHeap( ULONG flags, PVOID addr, SIZE_T totalSize, SIZE_T c > { > SUBHEAP *subheap; > > - /* Allocate the heap block */ > + /* Check global flags unless we're being called in virtual_init before they > + * are available. Recognize that by comparing the arguments we know > + * wine's virtual_init calls us with. > + */ > + if (flags != HEAP_NO_SERIALIZE && totalSize != VIRTUAL_HEAP_SIZE) > + if ((RtlGetNtGlobalFlags() & FLG_HEAP_ENABLE_FREE_CHECK) != 0) > + flags |= HEAP_FREE_CHECKING_ENABLED; This makes no sense, there's nothing unique about these arguments. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: crypt32: check for NULL target pointers (Coverity)
by Juan Lang 07 Jan '10

07 Jan '10

Hi Marcus, Ideally this patch would be accompanied by a test. Also, this change: @@ -212,6 +212,10 @@ static BOOL CRYPT_DecodeEnsureSpace(DWORD dwFlags, if (dwFlags & CRYPT_DECODE_ALLOC_FLAG) { + if (!pvStructInfo) { + SetLastError(ERROR_INVALID_PARAMETER); + return FALSE; + } is a noop in all but one case: all the callers of CRYPT_DecodeEnsureSpace, save one, check pvStructInfo before calling it. It would be clearer, IMO, to change the single caller that doesn't check pvStructInfo (CryptDecodeObjectEx) rather than adding a check that is useless in most cases. A similar statement applies to the encode.c change: just change CryptEncodeObjectEx, not CRYPT_EncodeEnsureSpace. Finally, please indent consistently with the rest of the file. If you prefer, I can try to fix this. Triaging the Coverity bugs is probably enough work by itself, without being expected to fix them too ;-) Thanks, --Juan

2 1

patch 57244: (try 3) msi: queue dynamically allocated strings in cond.y...
by Nate Gallaher 07 Jan '10

07 Jan '10

Anything I can do to help move this along? ~Nate

1 0

FIXMEs in DllCanUnloadNow and friends (and how to handle them)
by Reece Dunn 07 Jan '10

07 Jan '10

Hi, As a result of the "Wine FIXME Report 2009 Aug - Dec" thread, I created the following to hunt for DllCanUnloadNow calls that were marked as being FIXME stubs: cat > DllCanUnloadNow.pl < EOF #!/usr/local/bin/perl # Based on http://www.unix.com/unix-dummies-questions-answers/56703-multiline-grep.html use strict; my $filename = shift; open (FILE, "<", $filename) or die "Failed to read file $filename : $! \n"; my $whole_file; { local $/; $whole_file = <FILE>; } close(FILE); if ($whole_file =~ m#HRESULT WINAPI DllCanUnloadNow ?$ ?(void|VOID) ?$[\n ]{\n\s+FIXME#sg) { print $filename . "\n"; } EOF and used it with the following: $ grep -F DllCanUnloadNow -r dlls | grep -F HRESULT | sed -e 's/:.*//' | while read line ; do perl DllCanUnloadNow.pl $line ; done | sort | tee results.log This gives the following results: ----- 8< ----- dlls/ddrawex/main.c dlls/dinput/dinput_main.c dlls/dpnhpast/main.c dlls/dsound/dsound_main.c dlls/hlink/hlink_main.c dlls/hnetcfg/hnetcfg.c dlls/inetcomm/inetcomm_main.c dlls/infosoft/infosoft_main.c dlls/inseng/inseng_main.c dlls/itircl/itircl_main.c dlls/mmdevapi/main.c dlls/mpr/mpr_main.c dlls/mscoree/mscoree_main.c dlls/msimtf/main.c dlls/msxml3/main.c dlls/oledb32/main.c dlls/olepro32/olepro32stubs.c dlls/pstorec/pstorec.c dlls/query/query_main.c dlls/shell32/shell32_main.c dlls/sti/sti_main.c dlls/wbemprox/main.c dlls/winhttp/main.c dlls/wmiutils/main.c dlls/wuapi/main.c ----- >8 ----- I am currently going through the results and removing the FIXME stubs for the DllCanUnloadNow calls, as returning S_FALSE is a perfectly valid implementation (see the "Wine FIXME Report 2009 Aug - Dec" discussion). While doing this, I noticed that some implementations of DllGetClassObject, DllRegisterServer and DllUnregisterServer also have FIXMEs. This is because the DLLs implement COM objects, but the wine versions are incomplete. For the DllRegister/UnregisterServer calls, the FIXMEs should be removed -- the FIXMEs do not add any value, and are only likely to appear during install or when calling regsvr32. For DllGetClassObject, the FIXME should output the GUID of the object that is trying to be created. NOTE: I have also seen some implementations of DllCanUnloadNow that always return S_OK (e.g. dlls/hlink/hlink_main.c, even though it is implementing COM objects). I will keep a note of these and look to see whether they implement COM objects or not. I will sent a separate patch to address this issue. - Reece

3 3

Re: user32: Do not allow a change of capture if the currently capture window is a menu unless explicitly specified
by Paul Vriens 07 Jan '10

07 Jan '10

On 01/07/2010 03:33 AM, Peter Dons Tychsen wrote: > + /* check that SetCapture fails for another window and that it does not touch the error code */ > + set_cap_wnd = SetCapture(hWnd); > + err = GetLastError(); > + ok(!set_cap_wnd, "ReleaseCapture should have failed!\n"); > + ok(err == ERROR_SUCCESS, "Bad error-code from SetCapture. got %08X expected %08X\n", err, 0); > + > + /* check that ReleaseCapture fails and does not touch the error code */ > + status = ReleaseCapture(); > + err = GetLastError(); > + ok(!status, "ReleaseCapture should have failed!\n"); > + ok(err == ERROR_SUCCESS, "Bad error-code from ReleaseCapture. got %08X expected %08X\n", err, 0); Hi Peter, The comment says 'does not touch the error code' but the tests don't actually prove this. In general when we try to get a true hold of the last error to see if it changed we set it first, f.e. "SetLastError(0xdeadbeef)". -- Cheers, Paul.

1 0

Re: mlang: [RESEND] Print a FIXME only for unused parameter (Wine FIXME Report)
by James Hawkins 06 Jan '10

06 Jan '10

On Wed, Jan 6, 2010 at 3:28 PM, Detlef Riekenberg <wine.dev(a)web.de> wrote: > According to MSDN, both parameter are unused and must be 0/NULL > A FIXME for every call is useless > > (there is no PATCH 1/2, so a resend without that prefix) > > -- > By by ... Detlef > > > --- > dlls/mlang/mlang.c | 8 ++++---- > 1 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/dlls/mlang/mlang.c b/dlls/mlang/mlang.c > index 49f0605..9abe124 100644 > --- a/dlls/mlang/mlang.c > +++ b/dlls/mlang/mlang.c > @@ -3007,9 +3007,6 @@ exit: > return hr; > } > > -/* > - * TODO: handle dwFlag and lpFallBack > -*/ > static HRESULT WINAPI fnIMultiLanguage2_ConvertStringToUnicodeEx( > IMultiLanguage3* iface, > DWORD* pdwMode, > @@ -3021,7 +3018,10 @@ static HRESULT WINAPI fnIMultiLanguage2_ConvertStringToUnicodeEx( > DWORD dwFlag, > WCHAR* lpFallBack) > { > - FIXME("\n"); > + if (dwFlag || (lpFallBack != NULL)) > + FIXME("Ignoring dwFlag (0x%x/%d) and lpFallBack (%p)\n", > + dwFlag, dwFlag, lpFallBack); > + if (dwFlag || lpFallBack) seems to be simpler and easier to read. -- James Hawkins

1 0

New Icon set
by Detlef Riekenberg 06 Jan '10

06 Jan '10

Hi Joel When I read your preview page in Firefox, the lens for print preview in idb_std_small.bmp is to large. You can't detect the printer behind the lens. (LCD Resolution here is 1400x1050) As an Idea for an improvement, the print preview menu icon in Firefox is readable: The lens is a bit smaller but more important, the inner circle of the lens is transparent. Thanks for your artwork. -- By by ... Detlef ___________________________________________________________ Preisknaller: WEB.DE DSL Flatrate für nur 16,99 Euro/mtl.! http://produkte.web.de/go/02/

1 0

re: [PATCH] kernel32: GetPrivateProfileSectionNamesA error checking (Coverity)
by Dan Kegel 06 Jan '10

06 Jan '10

AJ wrote: > Marcus Meissner <marcus at jet.franken.de> writes: >> buffer and size need to be either 0 at the same time or not, >> otherwise this breaks up. Windows is inconsistent (either crashes >> or returns invalids), so we can just add checking. > >If Windows crashes we don't need extra checks. Just tell Coverity that >crashing is allowed here. If later versions of Windows return INVALID_PARAMETER, wouldn't it be ok for Wine to do so rather than crashing? In other words, isn't it ok to emulate the 'best' behaved version of windows in cases like this, rather than the 'worst'?

3 3

Re: [PATCH] Don't generate FIXME warnings for DllCanUnloadNow.
by Maarten Lankhorst 06 Jan '10

06 Jan '10

Hi Reece, Reece Dunn schreef: > NOTE: Some of the DllCanUnloadNow functions always return S_OK. I > intend to address that in a separate patch once I have investigated > whether the DLLs implement COM objects or not. > When a dll is first implemented it probably returns S_OK since no interfaces were used yet, but some programs just depended on the dll being present. However the FIXME should not be removed then, since if it does implement interfaces and it gets freed while in use this can be a serious crash. I'd rather have that message then as a red flag for investigation. Returning nothing in case of S_FALSE is fine though, but a TRACE() would still be nice there just in case. Cheers, Maarten.

2 1

Fwd: The (Casual) Game Support Report in Wine (Jan 2009)
by David Gerard 06 Jan '10

06 Jan '10

whoops, sending to list as well! ---------- Forwarded message ---------- From: David Gerard <dgerard(a)gmail.com> Date: 2010/1/6 Subject: Re: The (Casual) Game Support Report in Wine (Jan 2009) To: Reece Dunn <msclrhd(a)googlemail.com> 2010/1/5 Reece Dunn <msclrhd(a)googlemail.com>: > 2/ the major issues appear to be in the application launchers used > by different game providers (most of which are in the current wine > implementation of the IE browser ActiveX control); Curious question: you tested with IE6, how do things work if you install IE7? Any better? (I installed IE7 with winetricks to see if I could get the ActiveX control for our work VPN going. It didn't work, and I didn't expect it to - it uses ActiveX to completely take over and try to secure a Windows installation, and I think it just recoiled in horror when it found itself in Wine on Linux - but I routinely use it now to check website rendering. It's really horrible. But useful.) - d.

2 1

Re: [PATCH] kernel32: GetPrivateProfileSectionNamesA error checking (Coverity)
by Alexandre Julliard 06 Jan '10

06 Jan '10

Marcus Meissner <marcus(a)jet.franken.de> writes: > buffer and size need to be either 0 at the same time or not, > otherwise this breaks up. Windows is inconsistent (either crashes > or returns invalids), so we can just add checking. If Windows crashes we don't need extra checks. Just tell Coverity that crashing is allowed here. -- Alexandre Julliard julliard(a)winehq.org

3 3

Re: [PATCH] kernel32: GetPrivateProfileSectionNamesA error checking (Coverity)
by Paul Vriens 06 Jan '10

06 Jan '10

On 01/06/2010 01:26 PM, Marcus Meissner wrote: > + if (!RtlCreateUnicodeStringFromAsciiz(&filenameW, filename)) { > + SetLastError(ERROR_OUTOFMEMORY); > + return 0; > + } Aren't you leaking bufferW here? -- Cheers, Paul.

1 0

Re: [4/5] WineD3D: Implement manual fencing with GL_APPLE_flush_buffer_range
by Henri Verbeet 06 Jan '10

06 Jan '10

2010/1/4 Stefan Dösinger <stefan(a)codeweavers.com>: > + if(This->query.context) context_free_event_query(&This->query); > + This->query.context = NULL; context_free_event_query() already clears the context field. > + if(This->resource.device->adapter->gl_info.supported[APPLE_FENCE]) You already have a gl_info pointer in buffer_create_buffer_object(), you're using it a few lines up. I'm not sure you can test for APPLE_fence to determine if event queries are available. > +static inline void buffer_sync_apple(struct wined3d_buffer *This, struct wined3d_context *context, DWORD flags) Do you have a good reason for adding that inline? I think it mostly just causes the compiler to not notice when the function is unused. > + /* TODO: Test and implement D3DLOCK_DONOTWAIT */ > + GL_EXTCALL(glFinishFenceAPPLE(This->query.id)); > + checkGLcall("glFinishFenceAPPLE(This->query.id)"); The buffer code can't assume an event query is implemented with APPLE_fence. > + GL_EXTCALL(glSetFenceAPPLE(cur->query.id)); > + checkGLcall("glSetFenceAPPLE(cur->query.id)"); ...and neither can the draw code. The assumption is currently true of course, but that's just an accident of the code order in context_alloc_event_query(). Adding e.g. ARB_sync support to event queries will break that.

2 4

Re: gdi32: Use the LOGFONT charset field on OEM font creation
by Dmitry Timoshkov 06 Jan '10

06 Jan '10

"Ilya Shpigor" <shpigor(a)etersoft.ru> wrote: > Some explanation for this patch: > > The fsCsb is bitfield that is used as boolean value. If this is false the > DEFAULT_CHARSET is using and the real charset is choosen through the current > ANSI codepage. But this is mistake in case of the OEM charset. A real fix would be to add "Terminal" font to Wine. -- Dmitry.

2 2

Re: ole32/tests: remove a test, as it fails or hangs on Vista+
by Paul Vriens 06 Jan '10

06 Jan '10

On 01/05/2010 08:05 PM, André Hentschel wrote: > vista and 2k8: fails > w7: timeout > --- > dlls/ole32/tests/clipboard.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/dlls/ole32/tests/clipboard.c b/dlls/ole32/tests/clipboard.c > index 626d244..4a9e234 100644 > --- a/dlls/ole32/tests/clipboard.c > +++ b/dlls/ole32/tests/clipboard.c > @@ -1186,6 +1186,7 @@ static void test_flushed_getdata(void) > "got %08x\n", hr); > if(SUCCEEDED(hr)) ReleaseStgMedium(&med); > > +#if 0 /* broken on Vista+ */ > InitFormatEtc(fmt, cf_another, 0xffff); > memset(&dm, 0, sizeof(dm)); > dm.dmSize = sizeof(dm); > @@ -1204,6 +1205,7 @@ static void test_flushed_getdata(void) > ok(hr == S_OK, "got %08x\n", hr); > ok(med.tymed == TYMED_ISTORAGE, "got %x\n", med.tymed); > if(SUCCEEDED(hr)) ReleaseStgMedium(&med); > +#endif > > HeapFree(GetProcessHeap(), 0, fmt.ptd); > The test doesn't fail or hang on all Vista+ boxes though. There have been several attempts to fix these failures but I'm not sure just removing them is the best option. Apart from that I think "if (0)" is preferred over "#if 0". -- Cheers, Paul.

1 0

The (Casual) Game Support Report in Wine (Jan 2009)
by Reece Dunn 06 Jan '10

06 Jan '10

Hi, With Dan reporting on the success of Visual C++ 2005, I thought I would post my findings of various casual (and other) games. In general, my observations are that: 1/ the games themselves tend to work very well (and have done for a long while now thanks to the great work CodeWeavers did in getting DirectDraw and Direct3D working); 2/ the major issues appear to be in the application launchers used by different game providers (most of which are in the current wine implementation of the IE browser ActiveX control); 3/ the success varies from provider to provider, but the same tricks usually work for a given provider; 4/ a game is usually distributed by more than one provider, so you should be able to find a provider that works with wine that distributes the game; 5/ the recent Xrender support has provided major improvements to games (to the point where Azgard Defense is actually playable :D). Oberon Media Oberon Media have two versions of their game launcher. The older one renders with the buttons drawn, but the text and links are not functional; installing IE6 causes the text to render and the links to work, but when registering the games, you cannot enter any text in the text fields and there is no visible cursor. The newer launcher (which has a different UI) causes an SEH exception; I suspect that this is due to tightened DRM in the launcher. In addition to this, entering the details directly into the registry doesn't appear to work any more (and in the newer versions of the launcher, a different mechanism is used). Verdict: Rubbish! PopCap Games The PopCap games launcher works without problems out of the box. I haven't tried registering/buying a game through their launcher interface, though. Verdict: Flawless Blizzard Entertainment I have successfully installed and registered Warcraft III (and the expansion), StarCraft and Diablo II using the installer/launcher from the download version. StarCraft and Diablo II work flawlessly; WarCraft III crashes at random points (usually when transitioning between parts of a scenario). Verdict: Almost-but-not-quite Flawless Big Fish Games These use a special downloader client that makes extensive use of IE to provide its functionality. Although this does not currently work with wine out of the box, it works flawlessly in IE6 (using winetricks to install) -- the games download (although the download animation button background does blink), launch and you can successfully register/purchase them from the Big Fish Games UI. NOTE: Using IE7 results in a crash when starting the Big Fish Games launcher, and I have not yet been able to get IE8 installing/working properly from winetricks (using the IE7 recipe). Verdict: Excellent Awem Studios The Awem Studios game launcher works flawlessly in a clean wine prefix (only gecko is needed). The games launch and you can even register/purchase the games from within the Awem game launcher. Verdict: Flawless YoudaGames The launcher used by YoudaGames does not work in wine out of the box, but requires IE6. I haven't tried registering/purchasing any of their games yet, so I don't know how well this works. Verdict: Excellent - Reece

2 3

visual c++ 2005 success
by Dan Kegel 05 Jan '10

05 Jan '10

Well, golly. Now that Rob has fixed the /Zi bug, Visual C++ 2005 seems to be building small apps pretty well. There are three or so gotchas to be aware of: 1) apps like gyp's unit test won't be able to build until you've run the IDE once so it can register itself 2) you have to install winbind or /Zi will still be broken 3) the first run of a devenv /Zi build will hang after starting the pdb service; you have to kill it to recovert. Further runs (until reboot) will work fine. See http://bugs.winehq.org/show_bug.cgi?id=21259 for a nice script to demonstrate the latter problem. Oh, and you can't create projects; our ie implementation isn't good enough to run the wizard yet. But you can use projects that were created earlier.

1 0

valgrind progress: only 426 errors left?!
by Dan Kegel 05 Jan '10

05 Jan '10

Rob Shearman's commit, http://source.winehq.org/git/wine.git/?a=commit;h=9dc584d0a2cae7cfb4816fe98… seems to have caused a spectacular improvement in jscript/tests/run.c's leakage: LEAK SUMMARY: - definitely lost: NNN bytes in 19,001 blocks + definitely lost: NNN bytes in 4 blocks woot! The stats are now 1 Invalid free/ delete / delete[] 1 Use of uninitialised value of size 4 2 Source and destination overlap in memcpy 3 Syscall param writev 6 Invalid write of size 4 7 Invalid read of size 2 8 Invalid write of size 1 22 Invalid read of size 4 41 Conditional jump or move depends on uninitialised value 335 XXX bytes in XXX blocks are definitely lost total: 426 Amazing progress for December. I'll be happy if in January we cut the error count by 10% down to 380... There were two runs today; http://kegel.com/wine/valgrind/logs/2010-01-04-06.56 covered last Thursday's git, http://kegel.com/wine/valgrind/logs/2010-01-04-10.14 was fresh. Also: I'm deleting really old valgrind logs to avoid going over quota.

1 1

Re: [PATCH 1/2] msi: queue dynamically allocated strings in cond.y
by James Hawkins 05 Jan '10

05 Jan '10

On Sat, Jan 2, 2010 at 10:36 AM, Nathan Gallaher <ngallaher(a)deepthought.org> wrote: > > +struct cond_mem { + struct list entry; + void *ptr; +}; + +static void cond_free( void *info, void *ptr ) +{ + COND_input *cond = (COND_input*) info; + struct cond_mem *mem, *safety; + + LIST_FOR_EACH_ENTRY_SAFE( mem, safety, &cond->mem, struct cond_mem, entry ) + { + if( mem->ptr == ptr ) + { + msi_free( mem->ptr ); + list_remove( &(mem->entry) ); + msi_free( mem ); + return; + } + } + ERR("Error freeing %p\n", ptr); +} This won't fly. cond_free needs to be an O(1) operation, like your original patch. -- James Hawkins

2 4

Re: [tools]winetest: fix child-result coloring and counting
by Paul Vriens 05 Jan '10

05 Jan '10

On 01/04/2010 08:50 PM, André Hentschel wrote: > You can see wrong coloring e.g. here http://test.winehq.org/data/f74e312bf81032c46bd2ce080a5f6a33c7ac3ee3/wine_a… > Also the counting is wrong, that unit test is shown in the summary with 2 errors, but only has 1 > This patch fixes the issue. The totalize of those variables is already made in the "offline" software > --- > winetest/dissect | 6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/winetest/dissect b/winetest/dissect > index 16cc118..ce90bda 100755 > --- a/winetest/dissect > +++ b/winetest/dissect > @@ -252,9 +252,9 @@ while (<IN>) { > } elsif (/^(.*$unit.*: (\d+) tests executed $(\d+) marked as todo, (\d+) failures?$, (\d+) skipped\.)\r?$/) { > $lines++; > $total += $2; > - $todo += $3; > - $failed += $4; > - $skipped += $5; > + $todo = $3; > + $failed = $4; > + $skipped = $5; > chomp; > s/\r+$//; > my $class = "test result"; Hi André, That log also shows "server: 1 failures in child process". I'm not a 100% sure but from the looks of it this is that one/1 failure mentioned in that last line: server: 120 tests executed (1 marked as todo, 1 failure), 0 skipped. If I'm correct it does mean that we have 2 failures and 1 todo. (cc-ing AJ as he wrote that winetest_wait_child_process() thingy). -- Cheers, Paul.

3 6

Re: dmloader: Fix a possible null dereference
by Paul Vriens 05 Jan '10

05 Jan '10

On 01/05/2010 02:18 PM, David Adam wrote: > Hello > > This patch fixes the bug 13986 > > A+ > > David > Searc > Hi David, + hr = CoInitialize(NULL); + if ( FAILED(hr) ) + { + skip("CoInitializeEx failed.\n"); + return; + } The skip() message doesn't match the actual function called. + hr = CoCreateInstance(&CLSID_DirectMusicLoader, NULL, CLSCTX_INPROC, &IID_IDirectMusicLoader8, (void**)&loader); + if (FAILED(hr)) + { + skip("CoCreateInstance failed.\n"); + return; + } Your mixing tabs and spaces here. Shouldn't 'loader' be released on return? -- Cheers, Paul.

1 0

Re: Revert "dsound: Remove refcounting in classfactory."
by Alexandre Julliard 05 Jan '10

05 Jan '10

Maarten Lankhorst <m.b.lankhorst(a)gmail.com> writes: > This reverts commit 1b94450f789791908a370f16e125087b84f35bcb. > > See bug 21196 Again, when sending a revert you need to include a justification for why it must be reverted. Referencing a bug is not good enough, the git log must be understandable on its own. Also I don't see anything in that bug related to ref counting. -- Alexandre Julliard julliard(a)winehq.org

2 1

Version test crashing
by Stefan Dösinger 05 Jan '10

05 Jan '10

Hi, Since a few days my nightly cxtest runs show crashes in the version:info test: http://test.winehq.org/data/f74e312bf81032c46bd2ce080a5f6a33c7ac3ee3/wine_s… (Ubuntu 8.10, 64 bit build) Test.winehq.org has more results, for this wine build I am seeing 3 more timeouts(most likely because the crash error message wasn't ack'ed, so the process didn't exit). I don't know when this started, but I think it was somewhen mid-december. If needed I can run a regression test. The test runs in a clean wine prefix - my modified cxtest script cleans everything up, runs winetest, cleans up again, then runs a bunch of games and writes down the performance. Cheers, Stefan

2 2

Re: (try2)[PATCH 1/2] d3d10: Add a function to initialize the null variables.
by Alexandre Julliard 05 Jan '10

05 Jan '10

Rico Schüller <kgbricola(a)web.de> writes: > +static void d3d10_null_effect_variable_init(struct d3d10_effect_variable *v, struct ID3D10EffectVariableVtbl *vtbl) > +{ > + v->vtbl = vtbl; > + v->buffer = &null_local_buffer; > + v->type = &null_type; > +} > + > +void d3d10_null_effect_variable_init_all() > +{ > + d3d10_null_effect_variable_init(&null_local_buffer, (ID3D10EffectVariableVtbl *)&d3d10_effect_constant_buffer_vtbl); > + d3d10_null_effect_variable_init(&null_variable, (ID3D10EffectVariableVtbl *)&d3d10_effect_variable_vtbl); > + d3d10_null_effect_variable_init(&null_scalar_variable, (ID3D10EffectVariableVtbl *)&d3d10_effect_scalar_variable_vtbl); > + d3d10_null_effect_variable_init(&null_vector_variable, (ID3D10EffectVariableVtbl *)&d3d10_effect_vector_variable_vtbl); > + d3d10_null_effect_variable_init(&null_matrix_variable, (ID3D10EffectVariableVtbl *)&d3d10_effect_matrix_variable_vtbl); > + d3d10_null_effect_variable_init(&null_string_variable, (ID3D10EffectVariableVtbl *)&d3d10_effect_string_variable_vtbl); > + d3d10_null_effect_variable_init(&null_shader_resource_variable, (ID3D10EffectVariableVtbl *)&d3d10_effect_shader_resource_variable_vtbl); > + d3d10_null_effect_variable_init(&null_render_target_view_variable, (ID3D10EffectVariableVtbl *)&d3d10_effect_render_target_view_variable_vtbl); > + d3d10_null_effect_variable_init(&null_depth_stencil_view_variable, (ID3D10EffectVariableVtbl *)&d3d10_effect_depth_stencil_view_variable_vtbl); > + d3d10_null_effect_variable_init(&null_shader_variable, (ID3D10EffectVariableVtbl *)&d3d10_effect_shader_variable_vtbl); > + d3d10_null_effect_variable_init(&null_blend_variable, (ID3D10EffectVariableVtbl *)&d3d10_effect_blend_variable_vtbl); > + d3d10_null_effect_variable_init(&null_depth_stencil_variable, (ID3D10EffectVariableVtbl *)&d3d10_effect_depth_stencil_variable_vtbl); > + d3d10_null_effect_variable_init(&null_rasterizer_variable, (ID3D10EffectVariableVtbl *)&d3d10_effect_rasterizer_variable_vtbl); > + d3d10_null_effect_variable_init(&null_sampler_variable, (ID3D10EffectVariableVtbl *)&d3d10_effect_sampler_variable_vtbl); > +} > + That's not much of an improvement, static initialization is nicer. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [2/5] WineD3D: Call the non-wrapped GLfinish in the PBO test
by Henri Verbeet 05 Jan '10

05 Jan '10

2010/1/4 Stefan Dösinger <stefan(a)codeweavers.com>: > In this case you can just release the GL lock, although the call is just an OS X hack in the first place.

1 0

Re: shell32: Initialize the APPBARDATA struct to avoid use of uninitialized memory in SHAppBarMessage.
by Paul Vriens 05 Jan '10

05 Jan '10

On 01/05/2010 02:47 AM, James Hawkins wrote: > --- > dlls/shell32/tests/appbar.c | 3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > Hi James, Both Vincent and I tried something along those lines but AJ's response was: "That's just hiding the problem, an app can pass the same structure." and "We need to define a platform-independent struct for marshalling that data across processes anyway, we can't blindly send the structure." Vincent also mentioned http://bugs.winehq.org/show_bug.cgi?id=20982 -- Cheers, Paul.

1 0

Tango Icon Questions
by Joel Holdsworth 04 Jan '10

04 Jan '10

Ok, We seem to have two questions that need to be resolved before the tango icons can be merged. First: The SVGs. A little background on how I make the icon set: The icon set has been assembled from different sources of artwork. Some my own, some from other people, so there's a certain amount of variation in the formats that I've received. In every case, I have had to do a certain amount of work to produce the 9 or 10 sub-images of an ico. Rather like fonts, in icon art, the size of a pixel is significant relative to the size of graphical elements. This effect is particularly pronounced at the smaller sizes: 16x16 and 22x22. At smaller sizes, manual intervention in the vector artwork becomes increasingly necessary. Graphical elements have to be tweaked to align to pixel boundaries or resized, rearranged, or removed altogether. Low colour depths pose further problems. In 8-bit icons we only have 1-bit transparency. Drop shadows must be removed, and the icon must be adjusted in a raster editor to remove jagginess in the boundaries. These are exported as PNGs, and in some cases I kept the GIMP xcf.bz2s. 4-bit icons are still harder. Here the icon has to be so radically adjusted, that the original SVG really only forms a template for a piece of pixel art. I tend to do this work with the wine glass hidden in the SVG rendering, and then overlay a pre-rendered wine glass. Again, these are expored as PNGs, and in most cases I kept the GIMP xcf.bz2s. In an ideal world, we would have one SVG source file, which would be versioned in Git, which we would render to different sizes and depths as part of the build process. I hope you can see how this would be impractical because of the amount of manual raster work that has been needed. The only build scripts that I have are scripts that automatically compile my PNGs into ICOs, but this step wouldn't really help the project much, because the PNG is no less a binary blob than the ICO. To further compound the issue, I've found 2 bugs in icotool that cause it to create ICOs that are formatted incorrectly, and cause Wine to misbehave. For my ICO scripts I wrote a simple tool called "fix-icon" which tweaks the files, to correct the 2 types of problem. I've tried to contact the author of icotool about this, but as yet haven't got a response. So in conclusion, I think the best thing would be for me to tidy my icons project folder, and submit that to git or wine-pub-ftp. I think we need to accept that some images are PNG, some SVG and some XCF.BZ2, depending on the original source, and I don't think we can do automated render steps as part of the build. The other question is about attribution. By now, ALL the icons have had some input from me in one way or another; they're all a derivative work. I'm planning to just submit the icons in the current round, as shown on the website: http://www.airwebreathe.org.uk/wine-icon/ - no bitmaps this round, just shell32.dll, user32.dll, and Programs icons. The sources of these are: * Tango Base - Public Domain * Scott Ritchie - oic_winlogo.ico - the Wine Glass * Jakub Steiner - oic_bang.ico - GPLd, but I have an e-mail of him agreeing to relicense * Ulisse Perusin - winemine - GPLd, but have e-mail agreeing a relicense. * Joel Holdsworth - my original work - LGPLd. What would be the best way for us to attribute these? I guess we need to do things properly with regard to licensing, but I think the authors are all quite easy-going. Any thoughts Thanks Joel

1 0

Re: Patch feedback requested for OleCreatePropertyFrame()
by Geoffrey Hausheer 04 Jan '10

04 Jan '10

On Mon, Jan 4, 2010 at 9:06 AM, Wolfram Sang wrote: >> task. There doesn't appear to be anything in this code that would be >> patent encumbered, but the code itself certainly falls under >> Hidenori's copyright which he has effectively revoked permission to >> use. > > Strictly speaking, this is not possible. Although IANAL, this code is LGPL, > so he can't revoke permission for this version of the code. He can ask to > not use it, and this wish can be granted. You still should be allowed to > pick it up. Next question is then, if a modified version will be picked up > (still respecting the author's wish)? Or how much modifications are needed? > Geez, such things are never trivial :( > Well, I put the LGPL header on the code. I thought I had that right since the code was posted to wine-patches Anyhow, the legal side isn't really relevant. The question is what Alexandre will accept as far as it goes. The current code is certainly copyright by Hienori, and since I couldn't contact him, I must assume he doesn't want any of it in Wine. Thus my assumption is that I need to rewrite the entire thing, if we want to obey his wishes (which I do). However, my hope was that I could use the knowledge I gained from his implementation to do it myself. As I'm already biased by that knowledge, if that won't be allowed, then I can't do the work at all.

2 1

Re: Patch feedback requested for OleCreatePropertyFrame()
by Geoffrey Hausheer 04 Jan '10

04 Jan '10

On Mon, Jan 4, 2010 at 4:39 AM, John Klehm wrote: > On Mon, Jan 4, 2010 at 4:46 AM, Huw Davies <huw(a)codeweavers.com> wrote: >> On Sun, Jan 03, 2010 at 03:00:12PM -0800, Geoffrey Hausheer wrote: >>> I found a patch from 2001 written by TAKESHIMA Hidenori that >>> was posted to wine-patches >>> (http://www.winehq.org/pipermail/wine-patches/2001-October/001229.html) >>> but never committed. >> >> Actually it was commited (2843934af5515c7f2b8370324aa98d3964a40324) >> but was then removed (140e7222e0d7ce76068cddc64c68105c2e569257) at >> his request. >> > > In case anyone was just slightly less curious than me about it: > http://www.winehq.org/wwn/122#Quartz.dll%20Removal > Thanks for turning that up. I did look through the archives to see what hapened, but aparently not hard enough. So now the only solution appears to be to rewrite the code from scratch. The question is, can I do that now that I've looked over his code? It does turn this from a simple fix to a much more daunting task. There doesn't appear to be anything in this code that would be patent encumbered, but the code itself certainly falls under Hidenori's copyright which he has effectively revoked permission to use. .Geoff

2 1

Re: [PATCH] Revert "dsound: Only initialize one guid for capture and renderer."
by Alexandre Julliard 04 Jan '10

04 Jan '10

Maarten Lankhorst <m.b.lankhorst(a)gmail.com> writes: > This reverts commit b474649e0e9491f938f1daec74cdca01343dd97e. Please explain why. -- Alexandre Julliard julliard(a)winehq.org

2 1

Patch feedback requested for OleCreatePropertyFrame()
by Geoffrey Hausheer 04 Jan '10

04 Jan '10

Some software I'm using is configured via an OleCreatePropertyFrame call which isn't implemented in Wine (ticket #16564). I can use winetricks + dcom98 to get it working, but would prefer not to need that. I found a patch from 2001 written by TAKESHIMA Hidenori that was posted to wine-patches (http://www.winehq.org/pipermail/wine-patches/2001-October/001229.html) but never committed. I cleaned up the patch to compile against current Git and am including it here for inspection. I can't find any documentation on why it wasn't included at that time, and haven't done any Wine development for a long time, so I'm not sure what it will take to get it included. I have tested it, and it works pretty much fine for me (not quite as pretty as the dcom menu, but it is functional). I'd be happy to write a test for it if I had any idea how to do that, but I'm not sure where to begin for a function like this. Anyhow, I'm open to feedback on what should be done before I submit the patch for inclusion FYI: I was unable to find a currently valid email address for Takeshima .Geoff

4 3

RE: WineTestBot changes
by Greg Geldorp 04 Jan '10

04 Jan '10

> > I've completed phase 2 of the testbot: besides (32 and 64 bit) Windows > > executables you can now also submit patch files to the bot. The bot will > > apply the patch files to a clean git tree, cross-compile the test and run the > > test on Windows VMs. You'll also be able to download the cross-compiled test > > executable to test it on different Windows machines. > > I've had to reverse this change for now as it causes major problems. Fixed the problem (race condition which didn't show up on my uniprocessor test system but became very visible on the multiprocessor production system) and reinstated the change. You can submit patches to the bot again. Ge.

1 0

Re: [1/7] avifile: Initial test data and simple test for avifil32 depends
by Paul Vriens 03 Jan '10

03 Jan '10

On 12/30/2009 03:21 AM, Julius Schwartzenberg wrote: > This patch depends on Detlef Riekenberg's patch from June 2008 and > expects it to have been applied: > http://www.winehq.org/pipermail/wine-patches/2008-June/056310.html > > It was not committed due to bug 14085: > http://bugs.winehq.org/show_bug.cgi?id=14085 Can't you just submit that initial test framework with the 3 imports (if all 3 are indeed needed)? The bug will of course not be closed but at least some of your work could be committed. -- Cheers, Paul.

4 3

Re: comctl32: cchTextMax needs to be set for LVS_OWNERDATA as it uses LVN_GETDISPINFO notifications
by Nikolay Sivov 02 Jan '10

02 Jan '10

On 1/2/2010 12:48, Jeff Latimer wrote: > --- > dlls/comctl32/listview.c | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > + dispInfo.item.cchTextMax = textlenT(pszText, isW)+2; > What does this '2' mean?

2 4

Re: comctl32: cchTextMax needs to be set for LVS_OWNERDATA as it uses LVN_GETDISPINFO notifications
by Nikolay Sivov 02 Jan '10

02 Jan '10

On 1/2/2010 12:48, Jeff Latimer wrote: > --- > dlls/comctl32/listview.c | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) Actually setting buffer count is noop here, cause buffer pointer is not set up for dispInfo.item. A test required for this - let's say check that an ownerdata listview send LVN_GETDISPINFO before text update and the same thing for callback text (don't remember now maybe similar tests are already in).

3 3

Re: comctl32: Get the test in the correct format
by Nikolay Sivov 02 Jan '10

02 Jan '10

On 1/2/2010 12:47, Jeff Latimer wrote: > --- > dlls/comctl32/listview.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) You don't need this. Conversion is done next lines if needed: --- if (isW) bSame = (lstrcmpW(dispInfo.item.pszText, pszText) == 0); else { LPWSTR tmp = textdupTtoW(pszText, FALSE); bSame = (lstrcmpW(dispInfo.item.pszText, tmp) == 0); textfreeT(tmp, FALSE); } ---

2 1

[rfc] initial conformance test for programs/cmd
by Dan Kegel 02 Jan '10

02 Jan '10

How's this look? I've only tested it lightly, but it should be pretty close; with this, "make test" ought to recurse down into programs/cmd/tests and run the cmd tests, too. Shortcomings: - I don't think I need chomp() in tests/cmd.c anymore, that was a workaround - I think I can turn on echo again in tests/*.cmd, that was another workaround - I have yet to add a way to specify that a test is todo_wine Feedback welcome. I'll try to submit something tomorrow that takes care of the above known issues and any issues anyone else points out. (I'm actually kind of amazed the build machinery changes work, I didn't really take the time to understand all of the gears and pulleys.)

3 3

merge wine-website's Todo
by Thomas Heckel 02 Jan '10

02 Jan '10

Hi, the last days I had some free time and tried to make some cleanups to the wiki. I mainly worked on the pages related to quality assurance because my little contributions was to Austin's AppInstall which is on this topic. I hope this way I can contribute to the project. At the moment I stumbled over this old page at the website: http://www.winehq.org/status/todo It seems to me this would be a good candidate to be merged into wiki too. What do you think? Bye -- Thomas Heckel

2 1

Thanks Wylda
by Austin English 02 Jan '10

02 Jan '10

I just wanted to extend a thanks to Wylda for all her work on bugzilla. It helps a lot when users help to confirm bugs, find fixed bugs, etc. So thanks! -- -Austin

3 3

Is native dbghelp useful?
by Austin English 02 Jan '10

02 Jan '10

I noticed Microsoft's got dbghelp in a download available...would the native dll be useful to anyone? E.g., should I add it to winetricks? http://www.microsoft.com/downloads/details.aspx?FamilyID=cd1fc4b2-0885-47f4… -- -Austin

3 3

Re: [4/6] WineD3D: Add GL_APPLE_flush_buffer_range
by Henri Verbeet 02 Jan '10

02 Jan '10

2010/1/1 Stefan Dösinger <stefan(a)codeweavers.com>: > +typedef void (WINE_GLAPI *PGLBUFFERPARAMETERIAPPLE) (GLenum target, GLenum pname, GLint param); > +typedef void (WINE_GLAPI *PGLFLUSHMAPPEDBUFFERRANGEAPPLE) (GLenum target, ptrdiff_t offset, ptrdiff_t size); Any reason for not using the same naming convention as the rest of the file? Also, "ptrdiff_t" doesn't match the spec at http://www.opengl.org/registry/specs/APPLE/flush_buffer_range.txt.

1 0

Re: dinput: Initialize js state with sane values when the application acquires the device instead of at allocation.
by Vitaliy Margolen 01 Jan '10

01 Jan '10

Loïc Hoguin wrote: > See the attached patch. > > + /* Get sane state values for the joystick before giving control to the application. > + Before this call was made in alloc_device, before the application sets the joystick > + properties, so the values given by fake_current_js_state weren't in the range > + of values expected by a few applications. */ > + fake_current_js_state(This); > + The comment is a bit too verbose. First line is enough. However my main problem with your patch is you doing it on every acquire call which invalidates prior state of the joystick which could have been correct. I'm afraid you'll need to find a way to do it once or pull the real device state from the device. Vitaliy

2 1

RE: winetestbot busted?
by Greg Geldorp 01 Jan '10

01 Jan '10

Hi Dan, (adding wine-devel, this info might be interesting for other people as well) > Does the queuing system prioritize jobs at all? e.g. > do quick interactive jobs with low timeouts have > to wait behind the massive three hour daily runs? There is some prioritization, you can see the assigned job priority on the main status page. The priority levels I'm currently using (or plan to use): 1 (highest) - Daily run for base VMs 3 - Rebuild of Wine (cross) tests after Alexandre pushes out git updates 5 - User submitted jobs 7 - Daily run for extra and 64-bit VMs 9 - Jobs automatically generated from wine-patches submissions So user jobs will be blocked during the daily run on base VMs, that takes about 45 min. However, they will have higher priority than the daily run for extra/64-bit VMs. It might take some time for user-submitted jobs to actually start, they might need a VM that's "dirty" and needs to be reverted to a clean snapshot. Ge.

1 0

avifile tests
by Julius Schwartzenberg 01 Jan '10

01 Jan '10

Hi, I still have some fixes for avifile here, but because they are quite nasty, I thought it'd be useful to have proper tests to show the fixes are really correct. Unfortunately there is still a problem with the avifile tests as Detlef indicated in this mail: http://www.winehq.org/pipermail/wine-devel/2009-November/079693.html Based on Detlef's patch however, I was able to create an initial patch which should provide the base for the tests I want to add. I have attached it here. The idea of the tests is that I write out a complete AVI file with the stdio functions and then read it back in using the VFW API and test the values in the different headers through the API. Later tests will change the values of the default headers and test how this affects the headers when they are being read back in. (I discovered Windows' avifil32 overrides some headers with values from other headers, there is some more info in my previous mails.) The inlining structure of the current header file is now actually based on the RIFF tree in the AVI file. Is this useful or should I just use plain indentation? Should the avi file data really be put in an extra header or should it be merged with api.c? What do you think of the general idea of the tests? Thanks a lot in advance for your feedback! Julius From 00dc5fa4d767b2edbb0e9d42931c0fd9585c1b90 Mon Sep 17 00:00:00 2001 From: Julius Schwartzenberg <julius.schwartzenberg(a)gmail.com> Date: Fri, 25 Dec 2009 20:29:43 +0100 Subject: initial version of avifile testing framework --- dlls/avifil32/tests/api.c | 72 ++++++++++++++++++ dlls/avifil32/tests/api_test.h | 160 ++++++++++++++++++++++++++++++++++++++++ 2 files changed, 232 insertions(+), 0 deletions(-) create mode 100644 dlls/avifil32/tests/api_test.h diff --git a/dlls/avifil32/tests/api.c b/dlls/avifil32/tests/api.c index 55b194f..c41ebfb 100644 --- a/dlls/avifil32/tests/api.c +++ b/dlls/avifil32/tests/api.c @@ -20,6 +20,7 @@ */ #include <stdarg.h> +#include <stdio.h> #include "windef.h" #include "winbase.h" @@ -28,6 +29,8 @@ #include "vfw.h" #include "wine/test.h" +#include "api_test.h" + /* ########################### */ static const CHAR winetest0[] = "winetest0"; @@ -87,11 +90,80 @@ static void test_AVISaveOptions(void) /* ########################### */ +void init_test_struct(COMMON_AVI_HEADERS *cah) +{ + MainAVIHeader *mah = malloc(sizeof(MainAVIHeader)); + AVIStreamHeader *ash0 = malloc(sizeof(AVIStreamHeader)); + AVIStreamHeader *ash1 = malloc(sizeof(AVIStreamHeader)); + PCMWAVEFORMAT *pcmwf = malloc(sizeof(PCMWAVEFORMAT)); + memcpy(mah, &defmah, sizeof(defmah)); + memcpy(ash0, &defash0, sizeof(defash0)); + memcpy(ash1, &defash1, sizeof(defash1)); + memcpy(pcmwf, &defpcmwf, sizeof(defpcmwf)); + cah->mah = mah; + cah->ash0 = ash0; + cah->ash1 = ash1; + cah->pcmwf = pcmwf; +} + +void create_avi_file(COMMON_AVI_HEADERS *cah) +{ + FILE * pFile; + pFile = fopen("small.avi", "wb"); + + fwrite(file_header, 1, sizeof(file_header), pFile); /* de file wordt hier niet goed aangemaakt */ + fwrite(cah->mah, 1, sizeof(MainAVIHeader), pFile); + fwrite(streamlist, 1, sizeof(streamlist), pFile); + fwrite(cah->ash0, 1, 0x38, pFile); + fwrite(videostreamformat, 1, sizeof(videostreamformat), pFile); + fwrite(padding1, 1, sizeof(padding1), pFile); + fwrite(videopropheader, 1, sizeof(videopropheader), pFile); + fwrite(cah->ash1, 1, 0x38, pFile); + fwrite(audiostreamformat_pre, 1, sizeof(audiostreamformat_pre), pFile); + fwrite(cah->pcmwf, 1, sizeof(PCMWAVEFORMAT), pFile); + fwrite(data, 1, sizeof(data), pFile); + + fclose (pFile); +} + +void test_default_data() +{ + COMMON_AVI_HEADERS *cah; + PAVIFILE pFile; + int res; + LONG lSize; + WAVEFORMATEX wfx; + PAVISTREAM pStream; + + cah = calloc(sizeof(int),4); + init_test_struct(cah); + create_avi_file(cah); + + res = AVIFileOpen(&pFile, "small.avi", OF_SHARE_DENY_WRITE, 0L); + ok(res == 0, "Unable to open file: error=%u\n", res); + + res = AVIFileGetStream(pFile, &pStream, 0, 1); + ok(res == 0, "Unable to open audio stream: error=%u\n", res); + + ok(AVIStreamReadFormat(pStream, AVIStreamStart(pStream), NULL, &lSize) == 0, "Unable to read format size\n"); + ok(AVIStreamReadFormat(pStream, AVIStreamStart(pStream), &wfx, &lSize) == 0, "Unable to read format\n"); + + ok(wfx.wFormatTag == 1, "got %u (expected 1)\n",wfx.wFormatTag); + ok(wfx.nChannels == 2, "got %u (expected 2)\n",wfx.nChannels); + ok(wfx.wFormatTag == 1, "got %u (expected 1)\n",wfx.wFormatTag); + ok(wfx.nSamplesPerSec == 11025, "got %u (expected 11025)\n",wfx.nSamplesPerSec); + ok(wfx.nAvgBytesPerSec == 22050, "got %u (expected 22050)\n",wfx.nAvgBytesPerSec); + ok(wfx.nBlockAlign == 2, "got %u (expected 2)\n",wfx.nBlockAlign); +} + +/* ########################### */ + START_TEST(api) { AVIFileInit(); test_AVISaveOptions(); + test_default_data(); AVIFileExit(); } diff --git a/dlls/avifil32/tests/api_test.h b/dlls/avifil32/tests/api_test.h new file mode 100644 index 0000000..395cfa3 --- /dev/null +++ b/dlls/avifil32/tests/api_test.h @@ -0,0 +1,160 @@ +/* + * Unit test suite header for AVI Functions + * + * Copyright 2009 Julius Schwartzenberg + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA + * + */ + + +typedef struct common_avi_headers { + MainAVIHeader *mah; + AVIStreamHeader *ash0; + AVIStreamHeader *ash1; + PCMWAVEFORMAT *pcmwf; +} COMMON_AVI_HEADERS; + +static const MainAVIHeader defmah = +{ + 0x00008256, /* dwMicroSecPerFrame */ + 0x000080e8, /* dwMaxBytesPerSec */ + 0x00000000, /* dwPaddingGranularity */ + 0x00000910, /* dwFlags */ + 1, /* dwTotalFrames */ + 0, /* dwInitialFrames */ + 2, /* dwStreams */ + 0x00100000, /* dwSuggestedBufferSize*/ + 8, /* dwWidth */ + 6, /* dwHeight */ + { 0, 0, 0, 0 } /* dwReserved[4] */ +}; + +static const AVIStreamHeader defash0 = +{ + streamtypeVIDEO, /* fccType */ + 0x30323449, /* fccHandler */ + 0x00000000, /* dwFlags */ + 0, /* wPriority */ + 0, /* wLanguage */ + 0, /* dwInitialFrames */ + 0x000003e9, /* dwScale */ + 0x00007530, /* dwRate */ + 0, /* dwStart */ + 1, /* dwLength */ + 0x00100000, /* dwSuggestedBufferSize*/ + 0xffffffff, /* dwQuality */ + 0, /* dwSampleSize */ + { 0, 0, 0, 0 } /* short left right top bottom */ +}; + +static const AVIStreamHeader defash1 = +{ + /* AVIStreamHeader */ + streamtypeAUDIO, /* fccType */ + 1, /* fccHandler */ + 0, /* dwFlags */ + 0, /* wPriority */ + 0, /* wLanguage */ + 0, /* dwInitialFrames */ + 1, /* dwScale */ + 0x00002b11, /* dwRate */ + 0, /* dwStart */ + 0x00000665, /* dwLength */ + 0x00003000, /* dwSuggestedBufferSize*/ + 0xffffffff, /* dwQuality */ + 2, /* dwSampleSize */ + { 0, 0, 0, 0 } /* short left right top bottom */ +}; + +static const PCMWAVEFORMAT defpcmwf = +{ + { + 1, /* wFormatTag */ + 2, /* nChannels */ + 11025, /* nSamplesPerSec */ + 22050, /* nAvgBytesPerSec */ + 2, /* nBlockAlign */ + }, + 8, /* wBitsPerSample */ +}; + +/* Extra data needed to get the VFW API to load the file */ +DWORD file_header[] = +{ + FOURCC_RIFF, 0x34c6 /* length */, formtypeAVI, + FOURCC_LIST, 0x1ac /* length */, + listtypeAVIHEADER, ckidAVIMAINHDR, sizeof(MainAVIHeader), +}; + +/* MainAVIHeader mah */ + +DWORD streamlist[] = +{ + FOURCC_LIST, 0xd4 /* length */, + listtypeSTREAMHEADER, ckidSTREAMHEADER, 0x38 /* length */, +}; + +/* AVIStreamHeader ash0 */ + +DWORD videostreamformat[] = +{ + ckidSTREAMFORMAT, 0x28 /* length */, + 0x00000028, 0x00000008, 0x00000006, 0x00180001, + 0x30323449, 0x00000090, 0x00000000, 0x00000000, + 0x00000000, 0x00000000, +}; +DWORD padding1[] = +{ + ckidAVIPADDING, 0xc /* length */, + 0x00000004, 0x00000000, 0x63643030 +}; +DWORD videopropheader[] = +{ + 0x70727076, 0x44 /* length */, + 0x00000000, 0x00000000, + 0x0000001e, 0x00000008, 0x00000006, 0x00100009, + 0x00000008, 0x00000006, 0x00000001, 0x00000006, + 0x00000008, 0x00000006, 0x00000008, 0x00000000, + 0x00000000, 0x00000000, 0x00000000, + FOURCC_LIST, 0x70 /* length */, + listtypeSTREAMHEADER, ckidSTREAMHEADER, 0x38 /* length */, +}; + +/* AVIStreamHeader ash1 */ + +DWORD audiostreamformat_pre[] = +{ + ckidSTREAMFORMAT, sizeof(PCMWAVEFORMAT) /* length */, +}; + +/* PCMWAVEFORMAT pcmwf */ + +DWORD data[] = +{ + ckidAVIPADDING, 0xc /* length */, + 0x00000004, 0x00000000, 0x62773130, + ckidAVIPADDING, 0xc /* length */, + 0x6c6d646f, 0x686c6d64, 0x000000f8, + FOURCC_LIST, 0x18 /* length */, + 0x4f464e49, + 0x54465349, 0xc /* length */, + 0x6676614c, 0x332e3235, 0x00302e37, + ckidAVIPADDING, 0x4 /* length */, + 0, + + FOURCC_LIST, 0xd1b /* length */, listtypeAVIMOVIE, + 0, 0 +}; -- 1.6.3.3

4 6

LsaLookupNames2 allocated buffers
by Nikolay Sivov 01 Jan '10

01 Jan '10

Currently valgrind reports leaks after that calls, cause returned buffers contains data pointers too, including SIDs. So the question is about LsaFreeMemory usage - should advapi track allocated structures and then free properly depending on passed pointer or caller is responsible for cleanup?

1 0

RE: WineTestBot changes
by Greg Geldorp 01 Jan '10

01 Jan '10

> I've completed phase 2 of the testbot: besides (32 and 64 bit) Windows > executables you can now also submit patch files to the bot. The bot will > apply the patch files to a clean git tree, cross-compile the test and run the > test on Windows VMs. You'll also be able to download the cross-compiled test > executable to test it on different Windows machines. I've had to reverse this change for now as it causes major problems. Ge.

1 0

Tango Icons Ready to Go
by Joel Holdsworth 01 Jan '10

01 Jan '10

Hi All, I've spoken to the authors of the two icons that needed their licenses resolving. They've agreed to relicense them, so the Tango icons are ready to go. I've sent a pull request to wine-patches. Best Regards Joel Holdsworth

1 0

valgrind bot back online
by Dan Kegel 31 Dec '09

31 Dec '09

The valgrind bot seems to have locked up soon after I left for vacation, but it's back up. Today's results: http://kegel.com/wine/valgrind/logs/2009-12-31-09.07/ Stats: 1 Invalid free/ delete / delete[] 1 Use of uninitialised value of size 4 2 Invalid write of size 4 2 Source and destination overlap in memcpy 3 Syscall param writev 6 Invalid read of size 2 8 Invalid write of size 1 12 Invalid read of size 4 49 Conditional jump or move depends on uninitialised value 598 XXX bytes in XXX blocks are definitely lost total: 682 The total on Dec 18th was 807. Nice progress!

1 0

va_list breakage introduced today
by Gerald Pfeifer 31 Dec '09

31 Dec '09

I believe the following patch commit 8268ed978389662c7b43212e008037cae3ce900e Author: Alexandre Julliard <julliard(a)winehq.org> Date: Mon Dec 28 22:19:31 2009 +0100 kernel32: Do not include 16-bit headers in 32-bit files. is causing gmake[2]: Entering directory `/usr/test/Wine/dlls/kernel32' /files/pfeifer/gcc/bin/gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_KERNEL32_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wwrite-strings -Wtype-limits -Wpointer-arith -I/usr/local/include -g -O2 -o module.o module.c In file included from module.c:36:0: ../../include/winbase.h:1560:84: error: expected declaration specifiers or '...' before 'va_list' ../../include/winbase.h:1561:85: error: expected declaration specifiers or '...' before 'va_list' In file included from module.c:37:0: ../../include/winternl.h:2223:81: error: expected declaration specifiers or '...' before 'va_list' ../../include/winternl.h:2389:58: error: expected declaration specifiers or '...' before 'va_list' ../../include/winternl.h:2390:75: error: expected declaration specifiers or '...' before 'va_list' over here on my FreeBSD 7.2 tester. Gerald

2 2

WineTestBot changes
by Greg Geldorp 31 Dec '09

31 Dec '09

I've completed phase 2 of the testbot: besides (32 and 64 bit) Windows executables you can now also submit patch files to the bot. The bot will apply the patch files to a clean git tree, cross-compile the test and run the test on Windows VMs. You'll also be able to download the cross-compiled test executable to test it on different Windows machines. Ge.

3 2

Re: [PATCH 2/2] d3d10: Parse effect shaders as anonymous shaders.
by Henri Verbeet 31 Dec '09

31 Dec '09

2009/12/31 Rico Schüller <kgbricola(a)web.de>: > struct d3d10_effect_shader_variable *s; ... > + v->data = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(struct d3d10_effect_shader_variable)); ... > + s = v->data; I think this would be nicer: s = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*s)); ... v->data = s; That's mostly my fault for writing it like that in the first place, but we might as well fix that. > + default: > + ERR("This should not happen!\n"); > + break; You'll probably want to return E_FAIL here. > + struct d3d10_effect_variable *v = &e->anonymous_shaders[e->anonymous_shader_current]; > + struct d3d10_effect_type *t = &e->anonymous_shader_type[e->anonymous_shader_current]; ... > + hr = parse_fx10_anonymous_shader(o->pass->technique->effect, o->type); ... > + o->data = &o->pass->technique->effect->anonymous_shaders[o->pass->technique->effect->anonymous_shader_current-1]; If you create a structure for anonymous shaders, you can store that in a single array. You can then pass a pointer to that structure to parse_fx10_anonymous_shader(), and handle "anonymous_shader_current" in parse_fx10_object(). E.g.: struct d3d10_effect *effect = o->pass->technique->effect; struct d3d10_effect_anonymous_shader *shader = &effect->anonymous_shaders[effect->anonymous_shader_current]; hr = parse_fx10_anonymous_shader(effect, o->type, shader); if (FAILED(hr)) return hr; ++effect->anonymous_shader_current; o->data = shader; Note that you should also validate that "anonymous_shader_current" < "anonymous_shader_count". The count is supposed to be correct, but the .fx might lie about it, possibly on purpose.

1 0

Re: [PATCH 1/2] d3d10: Add a function to initialize the null variables.
by Henri Verbeet 31 Dec '09

31 Dec '09

2009/12/31 Rico Schüller <kgbricola(a)web.de>: > +static struct d3d10_effect_variable null_local_buffer = {0}; > +static struct d3d10_effect_variable null_variable = {0}; > +static struct d3d10_effect_variable null_scalar_variable = {0}; > +static struct d3d10_effect_variable null_vector_variable = {0}; > +static struct d3d10_effect_variable null_matrix_variable = {0}; > +static struct d3d10_effect_variable null_string_variable = {0}; > +static struct d3d10_effect_variable null_shader_resource_variable = {0}; > +static struct d3d10_effect_variable null_render_target_view_variable = {0}; > +static struct d3d10_effect_variable null_depth_stencil_view_variable = {0}; > +static struct d3d10_effect_variable null_shader_variable = {0}; > +static struct d3d10_effect_variable null_blend_variable = {0}; > +static struct d3d10_effect_variable null_depth_stencil_variable = {0}; > +static struct d3d10_effect_variable null_rasterizer_variable = {0}; > +static struct d3d10_effect_variable null_sampler_variable = {0}; This doesn't hurt (much), but since a lot of people seem to be unaware of this I think it's worth mentioning again. Global variables as well as static (local) variables are initialized to 0 / NULL by default. The way this works in the language spec is that objects with static storage duration (i.e. the entire lifetime of the program/module) are initialized to 0 / NULL unless explicitly initialized. In practice that means global and static variables (but note that static on a global variable or function has a different meaning from static on a local variable). > +static void d3d10_null_effect_variable_init(struct d3d10_effect_variable *v, struct ID3D10EffectVariableVtbl *vtbl) > +{ > + v->vtbl = vtbl; > + v->buffer = &null_local_buffer; > + v->effect = NULL; > + v->name = NULL; > + v->semantic = NULL; > + v->buffer_offset = 0; > + v->annotation_count = 0; > + v->flag = 0; > + v->data_size = 0; > + v->type = &null_type; > + v->elements = NULL; > + v->members = NULL; > + v->annotations = NULL; > +} Most of these are redundant, since the variable will be already initialized with zeroes.

1 0

Tango Icons (Almost) Ready to Go!!
by Joel Holdsworth 31 Dec '09

31 Dec '09

Hi All, I'm pleased to announce that after a lot of work lately I've pretty much completed the graphics for the icons for shell32, user32 and the programs all sizes and screen depths: http://www.airwebreathe.org.uk/wine-icon/ There are a few minor things left to do: * comctl32: Finish and submit - only idb_std_small.bmp needs to be upgraded. Only idb_std_small.bmp is 32-bit in XP, and Vista * comdlg32: Convert bitmaps to 8-bit. Maybe rework comdlg32 so that the graphics are stored as a icons not bitmaps for so that different colour depths can be handled elegantly. What does windows do? * credui: Test on a low bit-depth platform, and submit. * cryptui: Redo emblems on certwarning.bmp, certerror.bmp, and convert bitmaps into icons for so that different colour depths can be handled elegantly. * winecfg: new transparent bitmap won't work without xrender on a 32-bpp screen. Think again. * wine: image lists still strip the alpha channel. talk to thunderbird about 32-bit DDBs * control, dxdiag, iexplore, winecfg: These programs currently do not have an icon, and although my patches add the icon to the src dir, further patches will be needed to add the icon to the progam's resources, and display them in the app windows. These things are all relatively minor, and I think at this stage it would be good to merge as soon as possible. The only major issue that remains is that there are 3 icons from Gnome that need to be relicensed as LGPL for our use. I've e-mailed the gnome artists mailing list, so hopefully we'll hear back from them soon. Once this is done I'm suggesting we merge the icons for shell32, user32 and the programs. If you're interested you can try them right now at the public-beta-2 branch of my gitorious repo: http://gitorious.org/wine-tango/wine-tango/commits/public-beta-2 My final question is about what to do with my source artwork. The artwork has been collected from a variety of sources. Some is SVGs, some gimp .xcf.bz2s, and some plain PNGs. I guess these shouldn't go into the wine source repo, but does anyone have any bright ideas where these files *should* go? They'll need to be published in case the icons ever need to be changed in any way. Any thoughts? Best Regards Joel

3 3

Re: [3/4] jscript: Fix various memory and reference count leaks.
by Jacek Caban 31 Dec '09

31 Dec '09

Hi Rob, Thanks for your work on jscript. Unfortunately fixing Valgrind on jscript is not going to be easy. Most of your fixes are good, except clear_global part and "jscript: Fix a circular reference caused by object and function objects being able to have properties that are objects and functions." patch. I've sent a test showing that Windows doesn't do that. To fix it properly we need to implement a garbage collector. I've designed it in the very early days of jscript, but I never had time to implement it. Thanks, Jacek

2 2

Re: Tango Icons (Almost) Ready to Go!!
by Joel Holdsworth 31 Dec '09

31 Dec '09

On Thu, 2009-12-31 at 10:20 +0100, Warren Dumortier wrote: > Thanks for all your work (is there some screenshot)? > There's no doubt that the Tango icons are good, but would it be > possible to easily make icon themes maybe, to have Oxygen icons for > example? If i understand it's hardcoded, like on Windows, but making a > theming feature is probably a lot of work right? There will be some theming work coming later when someone finishes implementing the uxtheme stuff. My icons are about getting a base theme that works well. The point of Tango is that it shouldn't look to badly out of place on Mac, KDE, Gnome or even Windows. That's a good starting point, which we can build upon if someone can implement a wine theme bridge.

1 0

Re: [PATCH] hlink/tests: Repair test to work as intended
by Paul Vriens 31 Dec '09

31 Dec '09

On 12/29/2009 12:40 AM, Andrew Eikum wrote: > > Paul Vriens 'fixed' this test to ensure that two strings are not the > same. Instead, the test should test that two strings _are_ the same, > but I accidentally compared the wrong strings in the original version. > --- > dlls/hlink/tests/browse_ctx.c | 19 +++++++++++-------- > 1 files changed, 11 insertions(+), 8 deletions(-) > > Hi Andrew, Sorry about that. Thanks for really fixing it this time. -- Cheers, Paul.

2 1

Re: [2/3] kernel32: Generate the CommonProgramFiles and ProgramFiles environment variables.
by Alexandre Julliard 31 Dec '09

31 Dec '09

Andrew Nguyen <arethusa26(a)gmail.com> writes: > Some experimentation showed that the registry values that are read do > control the CommonProgramFiles and ProgramFiles environment variables. Is there any reason to not define it like the other environment variables? Is there really an app that would change the CurrentVersion key and expect the environment variable to change? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [2/3] kernel32: Generate the CommonProgramFiles and ProgramFiles environment variables.
by Nikolay Sivov 31 Dec '09

31 Dec '09

On 12/31/2009 05:47, Andrew Nguyen wrote: > Some experimentation showed that the registry values that are read do > control the CommonProgramFiles and ProgramFiles environment variables. > --- > dlls/kernel32/process.c | 27 ++++++++++++++++++++++++++- > 1 files changed, 26 insertions(+), 1 deletions(-) > Hi, Andrew. Alexandre recently removed 16bit headers inclusion, I don't think you should revert this.

1 0

Re: Acting as advisor for wcmd-uplift project?
by Dan Kegel 31 Dec '09

31 Dec '09

Peter Dons Tychen wrote: > Why not place the test in the source tree along with all of > the other tests. Of course this requires the tests to be run from a C > based file Yep. I should have a patch ready to submit tomorrow that is a barebones batch file test driver written in C suitable for use with winetestbot. > It would however mean that one could add tests for all of the > other command line utility programs much easier > (not possible now at all). Good point. The cmd tests can test not just cmd, but things like expand and extrac32, too. So, where should the tests live? I had been thinking programs/cmd/tests, but maybe something like programs/tests would be better given that it can test more than just cmd. - Dan

10 18

Wine prefix creation status
by Erich Hoover 30 Dec '09

30 Dec '09

I recently installed the bundled Wine for Mac OS X for someone and noticed something that would be nice for "normal Wine." In the bundled Mac OS X version a progress dialog* is displayed when prefix creation is occurring, are there any plans to do something like this for Wine 1.2? Erich Hoover ehoover(a)mines.edu *Note that this dialog doesn't show "real" progress, but at least lets the user know something is happening.

1 0

Re: CPPCheck Dec 29
by chris ahrendt 30 Dec '09

30 Dec '09

On 12/29/2009 11:17 PM, Alasdair Sinclair wrote: > > return size; ok will file a false positive... thanks chris

1 0

Removing WPARAM/LPARAM Casts
by James Mckenzie 30 Dec '09

30 Dec '09

I've noticed that Michael Stefuic (sp?) has removed quite a few WPARAM/LPARAM casts when calling SendMessage() and was wondering/inquiring if he was going do this to riched20/tests/editor.c since I noticed he put in a change for riched20. Michael are you going to do so, or are you going to leave this to others? Thank you. James McKenzie

2 3

Re: [PATCH 2/2] user32/uitools: Fix FillRect behaviour for invalid brush passed
by Alexandre Julliard 30 Dec '09

30 Dec '09

Nikolay Sivov <bunglehead(a)gmail.com> writes: > diff --git a/dlls/user32/tests/Makefile.in b/dlls/user32/tests/Makefile.in > index 102653f..4f4e812 100644 > --- a/dlls/user32/tests/Makefile.in > +++ b/dlls/user32/tests/Makefile.in > @@ -19,6 +19,7 @@ CTESTS = \ > input.c \ > listbox.c \ > menu.c \ > + misc.c \ > monitor.c \ > msg.c \ > resource.c \ Names like misc.c should be avoided. Something like uitools.c would be preferable, particularly since that's where the tested function resides in user32. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: wined3d: Added further Nvidia Geforce 8xxx detection.
by Roderick Colenbrander 30 Dec '09

30 Dec '09

Since we group cards, there is no need to add a lot of extra PCI ids. On Wed, Dec 30, 2009 at 1:02 PM, Aaron Brazener <rnbrznr(a)googlemail.com> wrote: > The attached patch is to add the missing PCI device information for > the Nvidia 8xxx series of cards. > > > >

1 0

CPPCheck Dec 29
by chris ahrendt 30 Dec '09

30 Dec '09

I just ran CPP check this evening and got the following : rpcrt4/rpc_transport.c 490 (error) Uninitialized variable smb_floor 761 (error) Uninitialized variable pipe_floor 885 (error) Uninitialized variable tcp_floor If you look at the code : static size_t rpcrt4_ncacn_np_get_top_of_tower(unsigned char *tower_data, const char *networkaddr, const char *endpoint) { twr_empty_floor_t *smb_floor; twr_empty_floor_t *nb_floor; size_t size; size_t networkaddr_size; size_t endpoint_size; TRACE("(%p, %s, %s)\n", tower_data, networkaddr, endpoint); networkaddr_size = networkaddr ? strlen(networkaddr) + 1 : 1; endpoint_size = endpoint ? strlen(endpoint) + 1 : 1; size = sizeof(*smb_floor) + endpoint_size + sizeof(*nb_floor) + networkaddr_size; if (!tower_data) return size; It is correct in that these three are not initialised and could point to anything on the local stack. Additionally if you look above you can get potentially a bogus return.. Additionally for tcp_floor: static size_t rpcrt4_ip_tcp_get_top_of_tower(unsigned char *tower_data, const char *networkaddr, unsigned char tcp_protid, const char *endpoint) { twr_tcp_floor_t *tcp_floor; twr_ipv4_floor_t *ipv4_floor; struct addrinfo *ai; struct addrinfo hints; int ret; size_t size = sizeof(*tcp_floor) + sizeof(*ipv4_floor); TRACE("(%p, %s, %s)\n", tower_data, networkaddr, endpoint); if (!tower_data) return size; Same problem here as well Chris

2 1

Re: [3/4] d3dx9: Implement D3DXAssembleShader function, really basic shader assembler.
by Henri Verbeet 29 Dec '09

29 Dec '09

2009/12/28 Matteo Bruni <matteo.mystral(a)gmail.com>: > Why do you need the fake parser? Can't you just not support those shader versions yet? There's also (in general) not much of a point in adding structure fields that aren't used yet. > +/* This file needs the original d3d9 definitions. The bwriter ones > + * aren't useable because they are wine-internal things. We're writing > + * d3d8/9 shaders here, so we need the d3d9 definitions (which are > + * equal to the d3d8 ones) > + */ This doesn't seem to match what the code actually does. > +/* Debug utility routines. Some are not reentrant, check asmutils.c */ Same as above. > +const char *debug_print_dstreg(const struct shader_reg *reg, shader_type st) { > + return wine_dbg_sprintf("%s", get_regname(reg, st)); > +} > + > +const char *debug_print_srcreg(const struct shader_reg *reg, shader_type st) { > + switch(reg->srcmod) { > + case BWRITERSPSM_NONE: > + return wine_dbg_sprintf("%s", get_regname(reg, st)); > + } > + return "Unknown modifier"; > +} "return get_regname(reg, st);" should work at least as well. > +/* Mutex used to guarantee a single invocation > + of the D3DXAssembleShader function (or its variants) at a time. > + This is needed as wpp isn't thread-safe */ > +extern CRITICAL_SECTION wpp_mutex; It's probably easier to just statically initialize the critical section in shader.c. As for splitting things up, I think it's ok to e.g. add the pre-processor first, and just return E_NOTIMPL from assemble_shader().

2 3

Linux Gaming: Are We There Yet?
by Jaime Rave 29 Dec '09

29 Dec '09

Excelent review from the guys in AnandTech of the current status of gaming in Linux, they have tested Wine vs CrossOver Games vs Cedega vs Windows 7 and the results are quite good. http://www.anandtech.com/linux/showdoc.aspx?i=3700 -- Jaime Rave Torres Ingeniero de Sistemas Miembro de la Fundación de Software Libre de Colombia http://www.fslcol.org/ http://sobrelibertad.blogspot.com/ 3003160361

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel