September 2007 - Wine-devel

DInput mouse - where to go from here?
by Vitaliy Margolen 28 Sep '07

28 Sep '07

As many of you know, Wine have number of serious problems when it comes down to games when using mouse. In fact big number of games suffer one or more of the following problems: 1. Mouse pointer escapes game window (for windowed programs) or confined to arbitrary rectangle (for full-screen) - bug 6971. 2. Mouse is being constantly re-centered (number of bugs). 3. Mouse lags, moves wrong direction or doesn't move at all (number of bugs). 4. Mouse is not smooth with high graphics/system load. There are lots of reasons for these bugs: a) Wine does not grab pointer (doesn't lock it to one particular window). b) Wine's dinput still doing mouse warping while it should not c) Wine relies on an application to process messages so new input events could be received. d) Wine's x11drv is not fine grained - it has only one lock that everything uses, d3d and wgl included. e) The path from x11drv to dinput for input events is long with big overhead. f) X events come from Wine windows for the current process only not whole screen. g) Motion events Wine receives are absolute not relative. Here is what me and others tried but failed: i) XEvIE - buggy, disabled by default, requires server round trip. ii) XInput - does not allow opening of keyboard or mouse devices. iii) Event Device (EvDev) - works perfectly, solves (a,b,c,d,e,f,g) but it's a client only solution (will not work on remote X, because it will try to open remote mouse, not local). iv) Virtualizing mouse pointer in x11drv - depends on (a) moves (b) from dinput into x11drv while same issues remain. v) Writing new X extension - last I've heard about this, it didn't get anywhere past initial proposals. Anything else I missed? Are there are any better ways to solve these problems? Any other ways at all? As you see there are not much options available to solve mouse problems. However I personally do not want to turn this into another "child opengl saga". We ether solving it now, or putting a big red X on any game that's using dinput mouse, that's not already working. The point I'm trying to make is: can we once put our "right ways of doing things" aside and fix something that never worked before? And fix it _for good_! Yes it's a limited fix it will work only for 99% of users who play games on their PC, and not remotely. Vitaliy Margolen.

8 10

AntiAliasing for Source Based games
by christine.youngson＠clear.net.nz 28 Sep '07

28 Sep '07

Hi everyone, I'm exceptionally new to posting messages on mailing lists (ie its my first time) so please forgive me in advance if I've done something wrong! My question for the wine developers is, why is Anti Aliasing not supported for Source based games? I play Day of Defeat Source everyday, and many wine gamers play steam based source engine games such as DoDs and Counterstrike Source, and its nearly at windows xp level fps wise, but the main nuisance for us is that there is no AA! AA greatly improves the look of games, and it seems that there is an emphasis on making the games look nice by adding functionality such as shaders and glsl, so in this respect, a basic feature of games such as AA should be considered to be made. Also Team Fortress Two is coming out fairly shortly and AA would be a nice feature to implement for when it comes out :) I would consider learning C etc myself to try and get this functionality (I learned Java as part of my degree) up and running, but sadly I probably don't have the skills to contribute. Anyways, keep up the excellent work wine developers, you guys do a tremendous job, but please consider adding this one feature, as it would mean a lot to myself and many many others who play steam based source games etc using wine on Linux! Take care!

4 3

Re: iTunes 7.4.2 doesn't even install for me
by Juan Lang 28 Sep '07

28 Sep '07

Hi Paul, > I saw your bug 9765 but I don't even get that far. The install crashes for me > with something that appears to be connected to a driver: Actually, I see that crash too. I meant to log a bug for it, but never did. Would you mind? (snip) > L"C:\\windows\\System32\\Drivers\\GEARAspiWDM.sys" (native) at 0x460000 > trace:module:process_attach (L"GEARAspiWDM.sys",(nil)) - START > trace:module:MODULE_InitDLL (0x460000 L"GEARAspiWDM.sys",PROCESS_ATTACH,(nil)) - > CALL > trace:seh:raise_exception code=c0000005 flags=0 addr=0x464010 > trace:seh:raise_exception info[0]=00000001 > trace:seh:raise_exception info[1]=00460038 > trace:seh:raise_exception eax=0046137e ebx=7bc90dc8 ecx=0000001c edx=00460000 > esi=7bc87f5b edi=00460038 That address (0x00460038) is suspect. It looks like part of a Unicode string. Something about how this driver is loaded is buggy, I'm guessing ntoskrnl.exe is a bit too stubby for it yet. Nevertheless, iTunes starts for me after this crash, it just warns about the registry entries needed for CD/DVD drives being missing, and I suspect that's due to this driver not being registered correctly. I just ignore that warning. > As your so busy with iTunes these days, I thought I contact you directly. I don't mind, but I'm actually off it now. I've tried to stay up to date this week, but no guarantees now that I'm back in school. --Juan

2 1

re: I need help, please
by Dan Kegel 28 Sep '07

28 Sep '07

David, sorry, Wine's not likely to be able to run Corel Draw X3 without several months worth of work, and nobody's focusing on it at the moment. - Dan

5 4

address space layout
by Tijl Coosemans 28 Sep '07

28 Sep '07

Hi all! I had a user running FreeBSD 6.2, Xorg 7.3, ATI r200 DRI driver report a problem where running Warcraft3 crashed because it ran out of malloc heap space. The error was: Assertion failed: (texObj->DriverData != NULL), function r200BindTexture, file r200_tex.c, line 1098. fixme:ntdll:FILE_GetNtStatus Converting errno 12 to STATUS_UNSUCCESSFUL This error happens inside the r200 driver, errno 12 means ENOMEM. There was a bug report with a patch over at http://bugs.freedesktop.org/show_bug.cgi?id=12184 The patch gets rid of the assertion failure by doing proper error checking, but it doesn't solve the underlying problem of course, causing a NULL pointer dereference in Wine somewhat later: wine: Unhandled page fault on read access to 0x00000058 at address 0x7e99cc84 (thread 0009), starting debugger... This isn't the first time such a problem appears, especially with games, so ultimately a solution has to be found. The problem is that the way Wine wants to setup the address space is really somewhat incompatible with the way FreeBSD mmap and malloc work. FreeBSD mmap allocates from the end of a process data segment upwards towards the stack. Linux mmap allocates from the stack downwards. FreeBSD (<7.x) malloc doesn't fall back to mmap when it runs out of space in the data segment. Linux malloc does (I've been told). Because the wine process loads itself at 0x7bf00000, this means on FreeBSD with mmap going up, both the data segment and all shared objects (like builtin dlls) sit squeezed between that address and 0x80000000 since addresses above 0x80000000 can't be used for builtin dlls. It's about 64Mb which is currently split 50/50 between heap space and shared objects. This works in a lot of cases, but sometimes a 32Mb heap isn't enough like in the example above, where I assume it's been taken up by textures and other graphics data. Linux doesn't have this problem because mmap allocates shared objects from 0x80000000 downwards and can go beyond the address where wine is loaded if necessary. It can allocate extra heap space this way too when needed. Alexandre and I discussed this a couple weeks ago, but didn't really come up with anything. The problem back then (WoW) has since gone away (turned out to be a memory leak somewhere) so everything was left the way it was. Now it has turned up again however with a different program on a different setup, so it's something that really needs to be looked at. It could again be a memory leak in some other project's code, but then that just means the current situation isn't robust enough to deal with that, since it all does work on Linux. It appears that the only solution is to locate wine somewhere after 0x80000000 instead of at 0x7bf00000 and to allow mmap to allocate memory there. Then the data segment size limit can be set to 256Mb or something instead of 32Mb. The problem is then that builtin dlls are mmapped (by the runtime linker) well beyond 0x80000000. Now I'm thinking, would it be possible to load dummy dlls somewhere in the first 2Gb of address space? Through which API calls can a program determine a dll is above 0x80000000 by the way?

2 1

Re: msvcrt: move error condition before memory allocation (found by Smatch) [1/3, resend]
by Alexandre Julliard 28 Sep '07

28 Sep '07

Lionel_Debroux <lionel_debroux(a)yahoo.fr> writes: > _wfullpath leaks some heap memory in an error paths. Found in Michael > Stefaniuc's list of Wine potential bugs detected by Smatch. > Fixed by moving the error treatment before the allocation, since the > error treatment doesn't fire up if there was a memory allocation (due to > size = MAX_PATH; assignment). > > Is there anything wrong with this patch ? Yes, you are using the size before checking if the buffer is NULL (in which case the size is meaningless), and as you said yourself the error treatment isn't used if there was an allocation, so there's no leak to fix here. -- Alexandre Julliard julliard(a)winehq.org

1 0

Wine gets exposed in Norway :)
by Tomas Zijdemans 28 Sep '07

28 Sep '07

The most visited and respected technology related site in Norway (210 000 unique norwegian hits a week), is now launching a series of articles where they will test 3 games thoroughly in wine each month! Today the first article tested Fahrenheit, Guild Wars: Nightfall and Civilization IV: Warlords. The results where good and focused on what users should do to make them work smoothly. Hope this is an encouragement for Stefan and all the others of you working to get games working :)

2 2

Re: version resource for ole2nls.dll
by Dmitry Timoshkov 27 Sep '07

27 Sep '07

"Stefan Leichter" <Stefan.Leichter(a)camline.com> wrote: > This patch fixes Bug 9747 > > ChangeLog > --------- > added version resource for ole2nls.dll > +#define WINE_FILEVERSION_STR "2.10.3050.1" > +#define WINE_FILEDESCRIPTION_STR "Wine OLE dll" > +#define WINE_FILENAME_STR "OLE2NLS.DLL" > + > +#include "wine/wine_common_ver.rc" Why do you define WINE_FILEVERSION_STR but not WINE_FILEVERSION? That not creates a confusion but could lead to hard debuggable problems with application which test only one of them. -- Dmitry.

1 1

Re: bits[1/3]: Minimal Background Intelligent Transfer Service (bits) implementation
by Alexandre Julliard 27 Sep '07

27 Sep '07

Roy Shea <roy(a)cs.hmc.edu> writes: > Resubmission of a bare bones bits implementation. There is no bits.dll on any Windows version I've checked. Where does this dll come from? -- Alexandre Julliard julliard(a)winehq.org

3 3

Re: mpr: Changes comparison of dwScope in WNetOpenEnum function
by Juan Lang 27 Sep '07

27 Sep '07

Hi Konstantin, - providerTable->table[index].dwEnumScopes & dwScope) + providerTable->table[index].dwEnumScopes & WNNC_ENUM_GLOBAL) This change looks correct, but it should be changed in the next block as well: ret = providerTable->table[index].openEnum( dwScope, dwType, dwUsage, lpNet, &handle); It also looks incorrect in _enumerateGlobalPassthroughW: ret = providerTable->table[enumerator->providerIndex]. openEnum(enumerator->dwScope, enumerator->dwType, enumerator->dwUsage, enumerator->lpNet, &enumerator->handle); In fact, all of these usages of dwScope look to confuse the two meanings. (D'oh.) --Juan

2 4