December 2009 - Wine-Devel - list.winehq.org

Re: Acting as advisor for wcmd-uplift project?
by Dan Kegel Dec. 31, 2009

Dec. 31, 2009

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 Dec. 30, 2009

Dec. 30, 2009

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 Dec. 30, 2009

Dec. 30, 2009

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 Dec. 30, 2009

Dec. 30, 2009

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 Dec. 30, 2009

Dec. 30, 2009

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 Dec. 30, 2009

Dec. 30, 2009

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 Dec. 30, 2009

Dec. 30, 2009

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 Dec. 29, 2009

Dec. 29, 2009

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 Dec. 29, 2009

Dec. 29, 2009

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

Re: dbghelp: Make sure the ClientPointers flag is set correctly
by Henri Verbeet Dec. 29, 2009

Dec. 29, 2009

2009/12/29 Jason Green <jave27(a)gmail.com>: > commit 317da09400946ca9f97361a47a227595c5bedfe3 > Author: Eric van Beurden <ericvb(a)transgaming.com> > Date: Tue Dec 29 12:35:03 2009 -0500 > > Make sure the ClientPointers flag isn't set incorrectly Mostly out of curiosity, how did you generate this patch? That looks like the kind of output git log gives, not git format-patch.

2 2

Re: [3/4] d3dx9: Implement D3DXAssembleShader function, really basic shader assembler.
by Alexandre Julliard Dec. 29, 2009

Dec. 29, 2009

Matteo Bruni <matteo.mystral(a)gmail.com> writes: > + > +%option reentrant bison-bridge These won't work on old flex versions, and will get you in trouble with the flex police (aka Michael Stefaniuc ;-) -- Alexandre Julliard julliard(a)winehq.org

3 2

Guide for creating new AppInstall tests
by Sam S. Dec. 29, 2009

Dec. 29, 2009

Hello Wine team! After reading the introduction to AppInstall at http://www.winehq.org/wwn/360, I decided to try and write some additional application tests for it. There are at least two freely downloadable win32 apps that I run with Wine, that have in the past (in my experience) been quite sensitive to small improvements/regressions in certain areas of wine (gecko engine and opengl, namely), so having them automatically tested daily could be useful... Unfortunately, however, the wiki page (http://wiki.winehq.org/Appinstall) doesn't really provide a guide for how to go about doing this... It explains the text that will need to be put in the actual test script (which I could have also figured out by looking at the well-documented example scripts), but almost nothing about how you need to set up your working environment, what files to put where, which commands to call, etc, for the purpose of writing/testing a new AppInstall script from scratch. In absence of such a guide, I just downloaded the whole http://winezeug.googlecode.com/svn/trunk/appinstall directory, copied it into a Windows XP environment (because according to the WWN article, you're supposed to write the tests on Windows), and started by duplicating one of the example files. However, when I open a Command Prompt window and try to run one of the .ahk files with AutoHotKey, nothing really happens - all I see is some additional Command Prompt windows popping up for a split second and disappearing again, and then the command returns - nothing downloaded, no output, no error messages, nothing. (Btw, I don't even understand where the dowloads specified in the scripts are supposed to end up...) How am I supposed to do this? More generally: Could someone who knows how to do this maybe put up a step-by-step guide for users who want to contibute by writing new AppInstall tests, with no prior knowledge? Possibly something along the lines of: - what/how do download - on Windows: what files to put where / how to set up the environment - on Windows: how to create a new test-script / where to put it - on Windows: how to get all those checksums - on Windows: how to properly test-run/debug the new script - on Linux+Wine: what files to put where / how to set up the environment - on Linux+Wine: how to test-run the new script previously created on Windows - where to upload/send finished test-scripts to Thanks! Sam PS: When will there be a new WWN?

2 3

Building and packaging Wine Gecko
by Anssi Hannula Dec. 29, 2009

Dec. 29, 2009

Hi all! I see that Wine has recently started to always request installation of Gecko, and that it is recommended to use a distribution provided package. We do not yet provide a wine-gecko package in Mandriva, but we'd like to. According to our policy (and the policy of e.g. Debian, Fedora) everything in our main repositories has to be compiled by us without external binaries compiled by a third party. I noticed there are build instructions here: http://wiki.winehq.org/BuildingWineGecko However, the instructions on that page ask for copying binaries directly provided in wine-mozilla tarball, and for modifying mingw32 headers. These actions are rather unacceptable for us (I guess the latter one is workaroundable, though). I saw that http://wiki.winehq.org/Gecko says Gentoo and openSUSE package Gecko properly. I looked at the Gentoo package [1] and saw that they simply download the prebuilt cab, which we can't do. I took a look in openSUSE src.rpm [2], but found no references to Gecko, and I didn't see any separate wine-gecko src.rpm there. I did found wine-gecko OpenSUSE binary packages in Wine's SourceForge page, but no source packages or information on how it was built. Is it really not possible to build Wine Gecko from the source code, on command line, on Linux? Or is it just that nobody has written any instructions on how to do that? [1] http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-emulation/wine/wine-1.1… [2] http://download.opensuse.org/factory/repo/src-oss/suse/src/wine-1.1.28-3.4.… -- Anssi Hannula Mandriva packager

10 24

Re: dlls/user32/combo.c: Fix an issue where pressing 's' in a combobox shows the dropdown isntead of finding an entry starting with 's'.
by Dmitry Timoshkov Dec. 29, 2009

Dec. 29, 2009

"David Quintana (gigaherz)" <gigaherz(a)gmail.com> wrote: > Issue was caused by VK_F4 having the same exact code as a lowercase 's'. > So the code, which treated WM_CHAR and WM_KEYDOWN as the same, executed > the wrong piece of code which was meant to be ONLY for WM_KEYDOWN. Thanks for spotting this bug. Anyway the fix is not correct. Virtual key codes should be tested only in the WM_KEYDOWN handler, WM_CHAR handler should test for character codes. Also, as Nikolay asked please don't use C++ comments in Wine code. -- Dmitry.

2 1

Difficulty fixing a regression in reading text files with MSVCRT
by Erich Hoover Dec. 29, 2009

Dec. 29, 2009

In a surprise last-minute request it became necessary for me to get Athena Visual Studio running under Wine again (http://appdb.winehq.org/objectManager.php?sClass=version&iId=15183) A couple of commits to MSVCRT (that are needed for other reasons) caused regressions in Wine's ability to run this application and I am having a lot of difficulty getting Athena working again. The commits that revealed the problem are: ebe4a9e321800fbe6d2004a640cd276a28d15c38: Remove CRs earlier in ascii mode. 7f3c70c52fe470d431a51b3363ed4f7336d5f7f5: Remove CRs earlier in ascii mode in fseek, too. After tracing down a lot of rabbit holes, it appears that the problem is somehow related to how the buffer boundary influences the file position reported by ftell. I've attached a test case that appears related to the issue. I can use a native MSVCRT for now, but I would appreciate some assistance so that this issue can be properly resolved at some point. Erich Hoover ehoover(a)mines.edu

2 1

Re: dlls/user32/combo.c: Fix an issue where pressing 's' in a combobox shows the dropdown isntead of finding an entry starting with 's'.
by Nikolay Sivov Dec. 28, 2009

Dec. 28, 2009

On 12/28/2009 22:18, David Quintana (gigaherz) wrote: > Issue was caused by VK_F4 having the same exact code as a lowercase 's'. > So the code, which treated WM_CHAR and WM_KEYDOWN as the same, executed > the wrong piece of code which was meant to be ONLY for WM_KEYDOWN. > > Patch is attached. > > > > Please resubmit without cpp style comments.

1 0

Re: [PATCH 3/5] wined3d: Introduce "context_apply_state()" to setup a context for a specific usage.
by Stefan Dösinger Dec. 28, 2009

Dec. 28, 2009

Am 27.12.2009 um 19:57 schrieb Henri Verbeet: > +/* Context activation is done by the caller. */ > +static void context_apply_state(struct wined3d_context *context, IWineD3DDeviceImpl *device, enum ContextUsage usage) The patch looks ok to me, but out of curiosity: Do you intend to make this function available to other wined3d code like context_acquire is, or is the main motivation of the patch to tidy up the context_acquire() function?

2 2

Remove Macintosh platform
by Austin English Dec. 28, 2009

Dec. 28, 2009

I just moved the last macintosh platforms to ppc32/x86, so can someone with the appropriate permissions remove that option. Thanks! -Austin

2 3

Re: [PATCH 1/3] wininet: Test also InternetCrackUrlW in test_crack_url.
by Paul Vriens Dec. 28, 2009

Dec. 28, 2009

On 12/27/2009 01:27 AM, Jacek Caban wrote: > --- > dlls/wininet/tests/url.c | 77 > ++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 77 insertions(+), 0 deletions(-) > Hi Jacek, Looks like these tests need at least IE7 to succeed. Could you have a look? -- Cheers, Paul.

1 0

Defining missing DirectInput constants
by Javier Kohen Dec. 28, 2009

Dec. 28, 2009

Hi, I'm implementing DInput's SetActionFormat call. I need to add the DInput Action Mapping Constants to Wine's dinput.h so I can map between the user requested action and the DIJOFS_* Joystick Device Constants. Is it OK to copy constant definitions from Microsoft's SDK? If not, can somebody help me or give some pointers on how to figure them out? This API call is needed at least for the Overlord game, which now works with my XBox 360 gamepad, but all action mappings are currently wrong. Thanks,

2 1

Re: [PATCH 2/3] wininet: Always set lpszUrlPath in InternetCrackUrlW.
by Alexandre Julliard Dec. 28, 2009

Dec. 28, 2009

Jacek Caban <jacek(a)codeweavers.com> writes: > --- > dlls/wininet/internet.c | 38 +++++++++++++------------------------- > 1 files changed, 13 insertions(+), 25 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M wininet.dll -T ../../.. -p wininet_test.exe.so internet.c && touch internet.ok wine: Unhandled page fault on read access to 0x00000000 at address 0x68699521 (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x68699521). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:68699521 ESP:0032d180 EBP:0032d1f8 EFLAGS:00010297( R- -- I S -A-P-C) EAX:cbcd24a4 EBX:686b1894 ECX:3432db62 EDX:6865b6c4 ESI:00000000 EDI:00000000 Stack dump: 0x0032d180: 00000000 00000000 00000000 00000000 0x0032d190: 00000000 00000000 00000000 00000000 0x0032d1a0: 00000000 00000000 00000000 0000000c 0x0032d1b0: 00000000 00000000 6865b6b8 00000000 0x0032d1c0: 00000006 00000000 00000000 00000000 0x0032d1d0: 00000000 00000000 00000000 00000000 Backtrace: =>0 0x68699521 InternetCrackUrlW+0x3c1(lpszUrl_orig=0x6865b6b8, dwUrlLength_orig=6, dwFlags=0, lpUC=0x32fb44) [/home/julliard/wine/wine/dlls/wininet/../../include/wine/unicode.h:311] in wininet (0x0032d1f8) 1 0x6869cd2c INTERNET_InternetOpenUrlW+0xec(hIC=0x148d18, lpszUrl=<register EDI not in topmost frame>, lpszHeaders=(nil), dwHeadersLength=0, dwFlags=0, dwContext=0) [/home/julliard/wine/wine/dlls/wininet/internet.c:2846] in wininet (0x0032fb98) 2 0x6869d34e InternetOpenUrlW+0x10e(hInternet=0x1, lpszUrl=<register EDI not in topmost frame>, lpszHeaders=(nil), dwHeadersLength=0, dwFlags=0, dwContext=0) [/home/julliard/wine/wine/dlls/wininet/internet.c:2990] in wininet (0x0032fbf8) 3 0x6864d4f3 test_null+0x3f3() [/home/julliard/wine/wine/dlls/wininet/tests/internet.c:400] in wininet_test (0x0032fca8) 4 0x6864f71b func_internet+0xbab() [/home/julliard/wine/wine/dlls/wininet/tests/internet.c:850] in wininet_test (0x0032fd98) 5 0x686560c0 run_test+0x130(name="internet.c") [/home/julliard/wine/wine/dlls/wininet/tests/../../../include/wine/test.h:537] in wininet_test (0x0032fdd8) 6 0x686562ae main+0x11e(argc=<register ECX not in topmost frame>, argv=<register ECX not in topmost frame>) [/home/julliard/wine/wine/dlls/wininet/tests/../../../include/wine/test.h:586] in wininet_test (0x0032fe88) 7 0x68656d34 __wine_spec_exe_entry+0x84(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in wininet_test (0x0032feb8) 8 0x7b8769d5 start_process+0x55(peb=<register ESI not in topmost frame>) [/home/julliard/wine/wine/dlls/kernel32/process.c:1038] in kernel32 (0x0032fee8) 9 0x7bc6f9e4 call_thread_func+0xc() in ntdll (0x0032fef8) 10 0x7bc6fbc0 call_thread_entry_point+0x70(entry=0x7b876980, arg=0x7ffdf000) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2391] in ntdll (0x0032ffc8) 11 0x7bc4cd5a in ntdll (+0x3cd5a) (0x0032ffe8) 0x68699521 InternetCrackUrlW+0x3c1 [/home/julliard/wine/wine/dlls/wininet/../../include/wine/unicode.h:311] in wininet: cmpw $10,0x0(%edi) 311 for (end = ptr + n; ptr < end; ptr++) if (*ptr == ch) return (WCHAR *)(ULONG_PTR)ptr; -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [TRY 2] extrac32: Create directory tree before extraction
by Ilya Shpigor Dec. 28, 2009

Dec. 28, 2009

Hi, Why this patch don't have been commited? There are mistakes? I really want to make extrac32 better, but I don't know what to do if nobody answer me. -- Best regards, Ilya Shpigor.

1 0

Re: Remove cpp_quote hackery from wined3d.idl (was: tools/widl: Split expr_int_const off from expr)
by Henri Verbeet Dec. 28, 2009

Dec. 28, 2009

2009/12/24 Gerald Pfeifer <gerald(a)pfeifer.com>: > On Mon, 21 Dec 2009, Henri Verbeet wrote: >>> How shall we best tackle this? >> At least for the wined3d ones, we might as well just add them to the >> enum, the macros aren't strictly necessary. > > Done thusly. We just need to move WINEMAKEFOURCC to a local header, > the rest of the cpp_quote can go and we lose a couple of dozen warning > messages (rightfully) issued by GCC 4.5 snapshots. > I already sent pretty much the same patch, http://source.winehq.org/git/wine.git/?a=commitdiff;h=3288911ae3e3cbd7124ed…

2 2

Re: msvcrt: add some demangle features
by Eric Pouech Dec. 28, 2009

Dec. 28, 2009

André Hentschel a écrit : > - > + if (*sym->current == 'A') sym->current++; > I don't understand how this would be necessary? Are you sure it's needed ? A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

2 2

Re: wined3d: adjust glPolygonOffset size
by Henri Verbeet Dec. 27, 2009

Dec. 27, 2009

2009/12/27 Austin English <austinenglish(a)gmail.com>: > See bug 18993. Original author is credited in patch ( Dorek Biglari ). > This doesn't look right from my understanding of the d3d9 depth bias behaviour. Afaik D3DRS_SLOPESCALEDEPTHBIAS is a multiplication factor for the maximum depth slope (i.e. difference in z-value over distance for a polygon's vertices), just like in OpenGL. I attached an alternative patch to the bug.

1 0