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

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

Re: dbghelp: Make sure the ClientPointers flag is set correctly
by Henri Verbeet 29 Dec '09

29 Dec '09

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 29 Dec '09

29 Dec '09

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. 29 Dec '09

29 Dec '09

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 29 Dec '09

29 Dec '09

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 29 Dec '09

29 Dec '09

"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 29 Dec '09

29 Dec '09

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