March 2011 - Wine-Devel - list.winehq.org

Re: mountmgr.sys: start detecting USB devices
by Maarten Lankhorst March 3, 2011

March 3, 2011

Hi Damjan, Op 02-03-11 18:52, Damjan Jovanovic schreef: > Changelog: > * mountmgr.sys: start detecting USB devices I'd love to get this kind of work in, but since libhal has been deprecated for a while, wouldn't it be better to use libudev directly instead of expanding our usage of libhal? Cheers, Maarten

2 1

Why am I getting create_view out of memory?
by Peter Urbanec March 3, 2011

March 3, 2011

I've got a heavily multithreaded 64-bit app that uses a lot of memory. After a while, I see this: fixme:virtual:create_view out of memory in virtual heap for 0x7f94465b0000-0x7f94466d6000 fixme:virtual:create_view out of memory in virtual heap for 0x7f9446640000-0x7f94466d3000 fixme:virtual:create_view out of memory in virtual heap for 0x7f9446690000-0x7f94466da000 fixme:virtual:create_view out of memory in virtual heap for 0x7f94466b0000-0x7f94466d5000 Could someone please explain to me what's going on here? Quick look at the code indicates that there is a 4MB heap used for "views" (I have no idea what these are) and presumably that heap is exhausted. Is this likely a resource leak somewhere? Some memory stats on the app I'm running: Process: PeakVirtualSize 3f2baf000, VirtualSize 3eccd0000 PeakWorkingSetSize 3762d6000, WorkingSetSize 3689ac000 PeakPagefileUsage 3f2baf000, PagefileUsage 3eccd0000 Global: TotalPhys 3eb4f2000, AvailPhys 0c4d8000 TotalPageFile 66b984000, AvailPageFile 1733eb000 TotalVirtual 7ffffffdffff, AvailVirtual 7ffc1330ffff Cheers, Peter Urbanec

2 1

Re: WineHQ Bug 26271
by Dmitry Timoshkov March 3, 2011

March 3, 2011

[Please do not exclude wine-devel when repying] Andreas Bierfert <andreas.bierfert(a)lowlatency.de> wrote: > > That's precisely my point. How many users are prepared to compile Wine > > from source when they report a bug with such a Wine build, and > > somebody > > asks them to either use a package without custom patches or compile > > Wine > > om their own instead? > > I am not a normal user but the packager. Hence I at least hope to have a > better understanding of what bugs should go upstream and what bugs are > related to some packaging issues or custom patches. In this way I have > no problem to rebuild or try fixes or whatever seems necessary to get > the bug fixed. The question was not about the packager, but about the normal users who has a problem and wants to report a bug. What is a difference between users using your package and crossover/ies4linux/playonlinux/etc. or whatever packager who includes say unofficial DIB engine patches? > > It's very doubtful in the first > > place that the term "official" should be used for such packages. Are > > you going > > to encourage packagers to include whatever patches they deem to be "an > > important > > feature" for the users, and still claim that provide an official Wine > > binary > > package? > > That raises more interesting questions: How would you describe an > official build? What do you do if some libraries are not available and > hence cannot build a full featured wine? But is this really the > important question? There is a Wine wiki page for packagers, and the bugs reporting instructions I pointed out already. Both of them imply using "not modified in any way Wine source". > Of course you may ask the question: Why does the fedora maintainer > include pulseaudio patches in the fedora wine package. And I am glad to > give you an answer: The default fedora spin has been using pulseaudio > for quite some time. It is an important feature of fedora. As I like to > provide users with an out-of-the-box experience wherever possible, it is > my duty to see and investigate where this can be provided for users. In the first place you should ask yourself, what makes you feel that those pulseaudio patches are really necessary? What doesn't work? Have you reported bugs? Where? Have you tested without pulseaudio in the system and can claim that it's the problems implied by Wine and not pulseaudio bugs? > I never understood why wine upstream was so reluctant about including > the pulseaudio patches. They do work well, there are people who maintain > the patches and there is a big userbase for pulseaudio these days. See the relevant bug report about pulseaudio support in Wine, it's been explain many times already. [skipped] -- Dmitry.

1 0

Re: wininet(3/6): Default to 10 minutes expiration for cache entries
by Dmitry Timoshkov March 3, 2011

March 3, 2011

Juan Lang <juan.lang(a)gmail.com> wrote: > + if (!expirationFound) > + { > + SYSTEMTIME st; > + > + /* With no known age, default to 10 minutes until expiration. */ > + GetSystemTime(&st); > + if (st.wMinute < 50) > + st.wMinute += 10; > + else > + { > + st.wHour += 1; > + st.wMinute -= 50; > + } > + SystemTimeToFileTime(&st, &request->expires); > } Well, st.wHour could also everflow, it shuild be easier to add an appropriate period to the resulting 64-bit number. -- Dmitry.

1 0

Re: winex11.drv: Ensure that wintab xinput_handle is not NULL.
by John Klehm March 3, 2011

March 3, 2011

On Mon, Feb 28, 2011 at 8:50 PM, Peter Urbanec <winehq.org(a)urbanec.net> wrote: > --- > dlls/winex11.drv/wintab.c | 13 ++++++++++--- > 1 files changed, 10 insertions(+), 3 deletions(-) > Nice find on this code path being able to run without loading xinput. I have a couple comments: You don't need to guard inside GetCurrentPacket. It's only called when WT_PACKET is passed to the global tablet event hwnd message queue. WT_PACKET is only sent to that queue from XInput event handlers that get registered when xinput is loaded. In short GetCurrentPacket won't get called if xinput isn't loaded so I don't believe it needs the xinput check. As for the AttachEventQueue and WTInfoW checks: I think we'd achieve the same end by having a loaded check in WTOpen just like we do in WTInfo. The benefit would be that we'd let the app know sooner that something was wrong. As it is right now we try to load but don't return 0 if we fail to load in dll/wintab32/context.c:WTInfoT: 370 if (gLoaded == FALSE) 371 LoadTablet(); 372 If we return 0 when loading fails in the dll/wintab32 WTInfo and WTOpen entry points we save the trouble of running through a bunch of function calls that are doomed to fail anyway. Even worse in most places in the wintab code we don't check if the winex11 calls succeed or fail. This would require modifications to LoadTablet and its winex11 buddy LoadTabletInfo so they could bubble up the failure. Regards, --John Klehm

2 1

Re: WineHQ Bug 26271
by Dmitry Timoshkov March 3, 2011

March 3, 2011

Andreas Bierfert <andreas.bierfert(a)lowlatency.de> wrote: > could you please stop arguing about the validity of the bug. What you > are stating in comment 6 is really not exclusive. The Fedora wine > packages are in fact 'prepackaged binary'. Using the term 'prepackaged binary' doesn't make the package suddenly valid for WineHQ bugzilla, since it clearly contains not supported patches. Same applies for instance to crossover, ies4linux, wineskin or any other. > For the Fedora users pulse support in wine is an important feature. This > is why the patches are in the Fedora build in the first place. I'd much > rather have them included with upstream... Maybe sometime wine will gain > openal support for audio input/output and this issue will go away. Once again, packages with custom patches can't be supported through WineHQ bugzilla for obvious reasons. If the packager knows what he/she is dooing by including such patches - he/she should take the full resposibility for that, including accepting bug reports for his package. If he/she doesn't want to carry the support burden then using Wine source without any custom patches is the way to go. -- Dmitry.

4 6

Re: [PATCH] shldocvw: Fixed typo = vs == (Coverity)
by Marcus Meissner March 2, 2011

March 2, 2011

On Fri, Feb 25, 2011 at 09:30:21PM +0100, Eric Pouech wrote: > Le 25/02/2011 14:16, Marcus Meissner a écrit : > >CID1801 > >--- > > dlls/shdocvw/shlinstobj.c | 2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > >diff --git a/dlls/shdocvw/shlinstobj.c b/dlls/shdocvw/shlinstobj.c > >index d272c91..067e678 100644 > >--- a/dlls/shdocvw/shlinstobj.c > >+++ b/dlls/shdocvw/shlinstobj.c > >@@ -376,7 +376,7 @@ HRESULT SHDOCVW_GetShellInstanceObjectClassObject(REFCLSID rclsid, REFIID riid, > > > > /* Figure if there is an 'Instance' subkey for the given CLSID and acquire a handle. */ > > if (!StringFromGUID2(rclsid, wszInstanceKey + 6, CHARS_IN_GUID) || > >- !(wszInstanceKey[5+CHARS_IN_GUID]='\\') || /* Repair the null-termination. */ > >+ !(wszInstanceKey[5+CHARS_IN_GUID] == '\\') || /* Repair the null-termination. */ > > ERROR_SUCCESS != RegOpenKeyExW(HKEY_CLASSES_ROOT, wszInstanceKey, 0, KEY_READ,&hInstanceKey)) > > { > > /* If there is no 'Instance' subkey, then it's not a Shell Instance Object. */ > are you sure about the fix ? > it looks like it's intentional that the test always succeed (it just > replaces the null termination char written in StringFromGUID2 with a > '\\') > (and this would explain the comment as well ;-) > I'm not familiar with the code... just being suspicious This was right, I fixed it. :) Ciao, Marcus

1 0

Re: t2embed: Add stub for _TTEmbedFont
by Dmitry Timoshkov March 2, 2011

March 2, 2011

André Hentschel <nerv(a)dawncrow.de> wrote: > diff --git a/dlls/t2embed/t2embed.spec b/dlls/t2embed/t2embed.spec > index 2566fa2..729a71b 100644 > --- a/dlls/t2embed/t2embed.spec > +++ b/dlls/t2embed/t2embed.spec > @@ -11,7 +11,7 @@ > @ stub TTRunValidationTests > @ stub _TTCharToUnicode(a)24 > @ stub _TTDeleteEmbeddedFont(a)12 > -@ stub _TTEmbedFont(a)44 > +@ stdcall _TTEmbedFont(ptr long long ptr ptr ptr ptr ptr long long ptr) This change is not correct, the exported name is _TTEmbedFont(a)44. -- Dmitry.

1 0

Re: [PATCH 5/5] mshtml: Added more attribute object tests
by Marvin March 2, 2011

March 2, 2011

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=9625 Your paranoid android. === W2K3R2SESP2 (32 bit dom) === Timeout === W2K8SE (32 bit dom) === Timeout

1 0

Problems with change to cursor and keyboard handling
by Erich Hoover March 2, 2011

March 2, 2011

The recent changes to the cursor and keyboard handling absolutely kill performance in Fallout: New Vegas. The cursor changes cause the mouse to jump around (when you move the mouse while using the keyboard) and the keyboard-specific changes cause the entire game to lock up temporarily about once a second when moving solely by keyboard. I believe I've narrowed down the problem with the keyboard changes (the issue is caused by commit bc4afb078677095468d4ee8f9a15c18cbb47bbbf, see attached proposed fix), but I did not have time this evening to explore the root cause of the cursor problem. Since I'm not certain why this particular line in the commit was changed in the first place, I figured I'd bring it up here, in case I'm missing something, before sending the attached to wine-patches. Erich Hoover ehoover(a)mines.edu

1 0