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

Re: Fixed default cyLogical in IFont constructor

by Marvin

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=9650 Your paranoid android. === WNT4WSSP6 (32 bit olefont) === olefont.c:106: Test failed: default scaling: default: get_Size: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:129: Test failed: set ratio: default: gS after SR: Lo=130000, Hi=0; expected Lo=180000, Hi=0. olefont.c:141: Test failed: set ratio: default: hFont has lf.lfHeight=-20, expected -18. olefont.c:106: Test failed: default scaling: ratio1: get_Size: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:129: Test failed: set ratio: ratio1: gS after SR: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:141: Test failed: set ratio: ratio1: hFont has lf.lfHeight=-39, expected -36. olefont.c:106: Test failed: default scaling: ratio2: get_Size: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:129: Test failed: set ratio: ratio2: gS after SR: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:141: Test failed: set ratio: ratio2: hFont has lf.lfHeight=-39, expected -36. olefont.c:106: Test failed: default scaling: zero size: get_Size: Lo=97500, Hi=0; expected Lo=0, Hi=0. olefont.c:129: Test failed: set ratio: zero size: gS after SR: Lo=130000, Hi=0; expected Lo=0, Hi=0. olefont.c:141: Test failed: set ratio: zero size: hFont has lf.lfHeight=-10, expected 0. olefont.c:106: Test failed: default scaling: rounding: get_Size: Lo=195000, Hi=0; expected Lo=186000, Hi=0. olefont.c:129: Test failed: set ratio: rounding: gS after SR: Lo=130000, Hi=0; expected Lo=186000, Hi=0. === W2KPROSP4 (32 bit olefont) === olefont.c:106: Test failed: default scaling: default: get_Size: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:129: Test failed: set ratio: default: gS after SR: Lo=130000, Hi=0; expected Lo=180000, Hi=0. olefont.c:141: Test failed: set ratio: default: hFont has lf.lfHeight=-20, expected -18. olefont.c:106: Test failed: default scaling: ratio1: get_Size: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:129: Test failed: set ratio: ratio1: gS after SR: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:141: Test failed: set ratio: ratio1: hFont has lf.lfHeight=-39, expected -36. olefont.c:106: Test failed: default scaling: ratio2: get_Size: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:129: Test failed: set ratio: ratio2: gS after SR: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:141: Test failed: set ratio: ratio2: hFont has lf.lfHeight=-39, expected -36. olefont.c:106: Test failed: default scaling: zero size: get_Size: Lo=97500, Hi=0; expected Lo=0, Hi=0. olefont.c:129: Test failed: set ratio: zero size: gS after SR: Lo=130000, Hi=0; expected Lo=0, Hi=0. olefont.c:141: Test failed: set ratio: zero size: hFont has lf.lfHeight=-10, expected 0. olefont.c:106: Test failed: default scaling: rounding: get_Size: Lo=195000, Hi=0; expected Lo=186000, Hi=0. olefont.c:129: Test failed: set ratio: rounding: gS after SR: Lo=130000, Hi=0; expected Lo=186000, Hi=0. === WXPPROSP3 (32 bit olefont) === olefont.c:106: Test failed: default scaling: default: get_Size: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:129: Test failed: set ratio: default: gS after SR: Lo=130000, Hi=0; expected Lo=180000, Hi=0. olefont.c:141: Test failed: set ratio: default: hFont has lf.lfHeight=-20, expected -18. olefont.c:106: Test failed: default scaling: ratio1: get_Size: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:129: Test failed: set ratio: ratio1: gS after SR: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:141: Test failed: set ratio: ratio1: hFont has lf.lfHeight=-39, expected -36. olefont.c:106: Test failed: default scaling: ratio2: get_Size: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:129: Test failed: set ratio: ratio2: gS after SR: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:141: Test failed: set ratio: ratio2: hFont has lf.lfHeight=-39, expected -36. olefont.c:106: Test failed: default scaling: zero size: get_Size: Lo=97500, Hi=0; expected Lo=0, Hi=0. olefont.c:129: Test failed: set ratio: zero size: gS after SR: Lo=130000, Hi=0; expected Lo=0, Hi=0. olefont.c:141: Test failed: set ratio: zero size: hFont has lf.lfHeight=-10, expected 0. olefont.c:106: Test failed: default scaling: rounding: get_Size: Lo=195000, Hi=0; expected Lo=186000, Hi=0. olefont.c:129: Test failed: set ratio: rounding: gS after SR: Lo=130000, Hi=0; expected Lo=186000, Hi=0. === W2K3R2SESP2 (32 bit olefont) === olefont.c:106: Test failed: default scaling: default: get_Size: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:129: Test failed: set ratio: default: gS after SR: Lo=130000, Hi=0; expected Lo=180000, Hi=0. olefont.c:141: Test failed: set ratio: default: hFont has lf.lfHeight=-20, expected -18. olefont.c:106: Test failed: default scaling: ratio1: get_Size: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:129: Test failed: set ratio: ratio1: gS after SR: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:141: Test failed: set ratio: ratio1: hFont has lf.lfHeight=-39, expected -36. olefont.c:106: Test failed: default scaling: ratio2: get_Size: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:129: Test failed: set ratio: ratio2: gS after SR: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:141: Test failed: set ratio: ratio2: hFont has lf.lfHeight=-39, expected -36. olefont.c:106: Test failed: default scaling: zero size: get_Size: Lo=97500, Hi=0; expected Lo=0, Hi=0. olefont.c:129: Test failed: set ratio: zero size: gS after SR: Lo=130000, Hi=0; expected Lo=0, Hi=0. olefont.c:141: Test failed: set ratio: zero size: hFont has lf.lfHeight=-10, expected 0. olefont.c:106: Test failed: default scaling: rounding: get_Size: Lo=195000, Hi=0; expected Lo=186000, Hi=0. olefont.c:129: Test failed: set ratio: rounding: gS after SR: Lo=130000, Hi=0; expected Lo=186000, Hi=0. === WVISTAADM (32 bit olefont) === olefont.c:106: Test failed: default scaling: default: get_Size: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:129: Test failed: set ratio: default: gS after SR: Lo=130000, Hi=0; expected Lo=180000, Hi=0. olefont.c:141: Test failed: set ratio: default: hFont has lf.lfHeight=-20, expected -18. olefont.c:106: Test failed: default scaling: ratio1: get_Size: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:129: Test failed: set ratio: ratio1: gS after SR: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:141: Test failed: set ratio: ratio1: hFont has lf.lfHeight=-39, expected -36. olefont.c:106: Test failed: default scaling: ratio2: get_Size: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:129: Test failed: set ratio: ratio2: gS after SR: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:141: Test failed: set ratio: ratio2: hFont has lf.lfHeight=-39, expected -36. olefont.c:106: Test failed: default scaling: zero size: get_Size: Lo=97500, Hi=0; expected Lo=0, Hi=0. olefont.c:129: Test failed: set ratio: zero size: gS after SR: Lo=130000, Hi=0; expected Lo=0, Hi=0. olefont.c:141: Test failed: set ratio: zero size: hFont has lf.lfHeight=-10, expected 0. olefont.c:106: Test failed: default scaling: rounding: get_Size: Lo=195000, Hi=0; expected Lo=186000, Hi=0. olefont.c:129: Test failed: set ratio: rounding: gS after SR: Lo=130000, Hi=0; expected Lo=186000, Hi=0. === W2K8SE (32 bit olefont) === olefont.c:106: Test failed: default scaling: default: get_Size: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:129: Test failed: set ratio: default: gS after SR: Lo=130000, Hi=0; expected Lo=180000, Hi=0. olefont.c:141: Test failed: set ratio: default: hFont has lf.lfHeight=-20, expected -18. olefont.c:106: Test failed: default scaling: ratio1: get_Size: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:129: Test failed: set ratio: ratio1: gS after SR: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:141: Test failed: set ratio: ratio1: hFont has lf.lfHeight=-39, expected -36. olefont.c:106: Test failed: default scaling: ratio2: get_Size: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:129: Test failed: set ratio: ratio2: gS after SR: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:141: Test failed: set ratio: ratio2: hFont has lf.lfHeight=-39, expected -36. olefont.c:106: Test failed: default scaling: zero size: get_Size: Lo=97500, Hi=0; expected Lo=0, Hi=0. olefont.c:129: Test failed: set ratio: zero size: gS after SR: Lo=130000, Hi=0; expected Lo=0, Hi=0. olefont.c:141: Test failed: set ratio: zero size: hFont has lf.lfHeight=-10, expected 0. olefont.c:106: Test failed: default scaling: rounding: get_Size: Lo=195000, Hi=0; expected Lo=186000, Hi=0. olefont.c:129: Test failed: set ratio: rounding: gS after SR: Lo=130000, Hi=0; expected Lo=186000, Hi=0. === W7PRO (32 bit olefont) === olefont.c:106: Test failed: default scaling: default: get_Size: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:129: Test failed: set ratio: default: gS after SR: Lo=130000, Hi=0; expected Lo=180000, Hi=0. olefont.c:141: Test failed: set ratio: default: hFont has lf.lfHeight=-20, expected -18. olefont.c:106: Test failed: default scaling: ratio1: get_Size: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:129: Test failed: set ratio: ratio1: gS after SR: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:141: Test failed: set ratio: ratio1: hFont has lf.lfHeight=-39, expected -36. olefont.c:106: Test failed: default scaling: ratio2: get_Size: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:129: Test failed: set ratio: ratio2: gS after SR: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:141: Test failed: set ratio: ratio2: hFont has lf.lfHeight=-39, expected -36. olefont.c:106: Test failed: default scaling: zero size: get_Size: Lo=97500, Hi=0; expected Lo=0, Hi=0. olefont.c:129: Test failed: set ratio: zero size: gS after SR: Lo=130000, Hi=0; expected Lo=0, Hi=0. olefont.c:141: Test failed: set ratio: zero size: hFont has lf.lfHeight=-10, expected 0. olefont.c:106: Test failed: default scaling: rounding: get_Size: Lo=195000, Hi=0; expected Lo=186000, Hi=0. olefont.c:129: Test failed: set ratio: rounding: gS after SR: Lo=130000, Hi=0; expected Lo=186000, Hi=0. === W7PROX64 (32 bit olefont) === olefont.c:106: Test failed: default scaling: default: get_Size: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:129: Test failed: set ratio: default: gS after SR: Lo=130000, Hi=0; expected Lo=180000, Hi=0. olefont.c:141: Test failed: set ratio: default: hFont has lf.lfHeight=-20, expected -18. olefont.c:106: Test failed: default scaling: ratio1: get_Size: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:129: Test failed: set ratio: ratio1: gS after SR: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:141: Test failed: set ratio: ratio1: hFont has lf.lfHeight=-39, expected -36. olefont.c:106: Test failed: default scaling: ratio2: get_Size: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:129: Test failed: set ratio: ratio2: gS after SR: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:141: Test failed: set ratio: ratio2: hFont has lf.lfHeight=-39, expected -36. olefont.c:106: Test failed: default scaling: zero size: get_Size: Lo=97500, Hi=0; expected Lo=0, Hi=0. olefont.c:129: Test failed: set ratio: zero size: gS after SR: Lo=130000, Hi=0; expected Lo=0, Hi=0. olefont.c:141: Test failed: set ratio: zero size: hFont has lf.lfHeight=-10, expected 0. olefont.c:106: Test failed: default scaling: rounding: get_Size: Lo=195000, Hi=0; expected Lo=186000, Hi=0. olefont.c:129: Test failed: set ratio: rounding: gS after SR: Lo=130000, Hi=0; expected Lo=186000, Hi=0. === W7PROX64 (64 bit olefont) === olefont.c:106: Test failed: default scaling: default: get_Size: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:129: Test failed: set ratio: default: gS after SR: Lo=130000, Hi=0; expected Lo=180000, Hi=0. olefont.c:141: Test failed: set ratio: default: hFont has lf.lfHeight=-20, expected -18. olefont.c:106: Test failed: default scaling: ratio1: get_Size: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:129: Test failed: set ratio: ratio1: gS after SR: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:141: Test failed: set ratio: ratio1: hFont has lf.lfHeight=-39, expected -36. olefont.c:106: Test failed: default scaling: ratio2: get_Size: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:129: Test failed: set ratio: ratio2: gS after SR: Lo=195000, Hi=0; expected Lo=180000, Hi=0. olefont.c:141: Test failed: set ratio: ratio2: hFont has lf.lfHeight=-39, expected -36. olefont.c:106: Test failed: default scaling: zero size: get_Size: Lo=97500, Hi=0; expected Lo=0, Hi=0. olefont.c:129: Test failed: set ratio: zero size: gS after SR: Lo=130000, Hi=0; expected Lo=0, Hi=0. olefont.c:141: Test failed: set ratio: zero size: hFont has lf.lfHeight=-10, expected 0. olefont.c:106: Test failed: default scaling: rounding: get_Size: Lo=195000, Hi=0; expected Lo=186000, Hi=0. olefont.c:129: Test failed: set ratio: rounding: gS after SR: Lo=130000, Hi=0; expected Lo=186000, Hi=0.

March 4, 2011

RFC: mmap override patch #2

by Chris Robinson

An updated attempt at the mmap override patch that I previously sent. This version properly uses a signed type for the mmap wrapper (as off_t/off64_t are signed types), fixes a few things with the munmap wrapper relating to truncated and sliced file_views, and implements a mremap wrapper for Linux. There's some debugging stuff left in the mremap wrapper since I have yet to catch anything that uses it, particularly using ERR instead of TRACE and an explicit abort() call so it isn't missed. There's also a %lld formatter in the mmap wrapper that will be fixed later. I'd be interested to hear how well it does or doesn't work, as well as any comments or critiques on the code.

March 3, 2011

d3dcompiler_41: reflection interface.

by Rico Schüller

Hi, attached is a hacky patch which forwards the reflection interface from d3dcompiler_41 to d3dcompiler_43. I have a question to that implementation: DEFINE_GUID is used twice (dlls/dxguid/dx10guid.c and dlls/d3dcompiler_41/reflection.c) which could be bad. But the define was removed from the d3d11shader.h from ms, so it isn't officially available anymore. Should that be in a separate header to reduce redundancy or is the usage of both defines fine here? Cheers Rico

March 3, 2011

Re: Please help me with document extraction.

by Max TenEyck Woodbury

On 02/27/2011 05:55 PM, Alexandre Julliard wrote: > > The other reason is that a decent documentation of the Windows API would > be huge; look at how much information there is on MSDN, and that's still > incomplete. It's completely impossible to maintain something of that > size in the middle of the source code. As long as it's inside the > source, it will just be one or two sentences per function, and maybe a > list of parameters. That's not useful documentation. > Hmm. Reviewing c2man.pl: The reason there are only one line comments on the parameters is because that is all the extraction program allows. I had access to commercial grade source code for some years (_NOT_ Microsoft!) and the library function documentation was indeed in the source files and there was a program that extracted the documentation and that was published and sold. So, I have to disagree that the situation is impossible. Yes, it is _hard_ to do, and duplicating MSDN should not be the goal. If done right the embedded documentation should add value to the code. Such things as what has and has not been implemented and _why_ might be helpful. It might even be useful to describe _how_ some of the stuff is done. Oh, and the total amount is indeed huge, but each piece is not. It's just that there are _lots_ of pieces. The way to eat an elephant is one bite at a time... Max

March 3, 2011

Re: wininet(2/6): Store entries in url cache with valid expiration date

by Alexandre Julliard

Juan Lang <juan.lang(a)gmail.com> writes: > + if (ret) > + { > + ret = FALSE; > + num = strtoulW(ptr, &nextPtr, 10); > + if (nextPtr > ptr && *nextPtr == ':' && num <= 59) > + { > + ptr = nextPtr + 1; > + st.wMinute = (WORD)num; > + ret = TRUE; > + } > + } > + if (ret) > + { > + ret = FALSE; > + num = strtoulW(ptr, &nextPtr, 10); > + if (nextPtr > ptr && isspaceW(*nextPtr) && num <= 59) > + { > + ptr = nextPtr + 1; > + st.wSecond = (WORD)num; > + ret = TRUE; > + } > + } > + if (ret) > + { > + static const WCHAR gmt[]= { 'G','M','T',0 }; > + > + ret = FALSE; > + while (isspaceW(*ptr)) > + ptr++; > + if (!strcmpW(ptr, gmt)) > + ret = TRUE; > + } You may want to consider using 'return', it's quite convenient... -- Alexandre Julliard julliard(a)winehq.org

March 3, 2011

Re: [PATCH 3/3] mshtml: Added support for indexed access to form elements

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > On 3/3/11 2:45 PM, Alexandre Julliard wrote: >> Jacek Caban<jacek(a)codeweavers.com> writes: >> >>> + /* FIXME: Implement in more generic and safe way */ >>> + for(ptr = name; *ptr&& isdigitW(*ptr); ptr++) >>> + i = i*10 + (*ptr-'0'); >> What's wrong with strtoulW? > > We don't want to use strings like "+1" or with leasing spaces for > indexed access. You can check the first character before passing it to strtoulW, that would already be better than doing it all by hand. Note that isdigitW won't do the right thing, not all Unicode digits are between '0' and '9'. -- Alexandre Julliard julliard(a)winehq.org

March 3, 2011

Re: [PATCH 3/3] mshtml: Added support for indexed access to form elements

by Jacek Caban

On 3/3/11 2:45 PM, Alexandre Julliard wrote: > Jacek Caban<jacek(a)codeweavers.com> writes: > >> + /* FIXME: Implement in more generic and safe way */ >> + for(ptr = name; *ptr&& isdigitW(*ptr); ptr++) >> + i = i*10 + (*ptr-'0'); > What's wrong with strtoulW? We don't want to use strings like "+1" or with leasing spaces for indexed access. The comment was more about considering moving it to IDispatchEx implementation layer than parsing itself. BTW, it's a really broken design of IDispatchEx. When a scripts accesses property by integer index, the integer is converted to string and passed to GetDispID, which parses it back. Thanks, Jacek

March 3, 2011

Re: [PATCH 3/3] mshtml: Added support for indexed access to form elements

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > + /* FIXME: Implement in more generic and safe way */ > + for(ptr = name; *ptr && isdigitW(*ptr); ptr++) > + i = i*10 + (*ptr-'0'); What's wrong with strtoulW? -- Alexandre Julliard julliard(a)winehq.org

March 3, 2011

Re: mountmgr.sys: start detecting USB devices

by Damjan Jovanovic

On Thu, Mar 3, 2011 at 1:45 PM, Maarten Lankhorst <m.b.lankhorst(a)gmail.com> wrote: > 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 > Hi Maarten I see the deprecation of HAL as a major loss for everybody. HAL was the one piece of software that worked on multiple *nixes and allowed a portable way for software to detect hardware and read hardware properties. HAL's replacements, like udev, have deteriorated to being 100% Linux-only: if we go that way we'll eventually end up detecting hardware using OS-specific code on each OS [1][2]. If HAL is not acceptable for detecting USB devices, then I'd rather use only libusb to do it, instead of hacking support for each operating system in its own way. Regards Damjan [1] http://www.freedesktop.org/wiki/Software/DeviceKit ("On Linux, ... On other platforms, native hardware enumeration systems should be used"). [2] eg. DragonFlyBSD only has vague plans to port DeviceKit: http://bugs.dragonflybsd.org/issue1477

March 3, 2011

Re: mountmgr.sys: start detecting USB devices

by Maarten Lankhorst

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

March 3, 2011

Re: Why am I getting create_view out of memory?

by Alexandre Julliard

Peter Urbanec <winehq.org(a)urbanec.net> writes: > 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? Not necessarily. The view structures are larger on 64-bit, and you can of course create a lot more of them, so it's possible to run out of heap space. Probably the heap should expand dynamically on 64-bit. -- Alexandre Julliard julliard(a)winehq.org

March 3, 2011

Re: WineHQ Bug 26271

by Dmitry Timoshkov

[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.

March 3, 2011

Re: wininet(3/6): Default to 10 minutes expiration for cache entries

by Dmitry Timoshkov

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.

March 3, 2011

Re: winex11.drv: Ensure that wintab xinput_handle is not NULL.

by Peter Urbanec

On 01/03/11 17:13, John Klehm wrote: > Nice find on this code path being able to run without loading xinput. It was as a result of a user sending me some crash logs. I never managed to reproduce this issue. I don't even have access to a tablet to test. My patch was pretty much a result of "NULL pointers seen in the wild -> better check for them" reaction. > In short GetCurrentPacket won't get called if xinput isn't loaded so I > don't believe it needs the xinput check. Fair enough, I can remove that check and resend the patch. > 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. Sounds good. I'll get that done, but my testing is going to be limited due to the fact that I actually don't have a tablet to test with.

March 3, 2011

Re: WineHQ Bug 26271

by Dmitry Timoshkov

Michael Stefaniuc <mstefani(a)redhat.com> wrote: > > 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 > I disagree with this statement. Each distribution modifies the upstream > Wine in one way or the other. Could you please list other Wine packages provided by distributions with custom patches applied you are aware of? > And a blanket "Screw you, use upstream > Wine if you want support" doesn't cut it. The distributions are for us > the main consumers of Wine and we should help them provide a good Wine > experience to their users. > > Of course in this specific case aka bug 26271 we cannot help as it > involves winepulse.drv which is an unsupported outside patch. 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? What are the advantages of this "support"? Do the unsuspecting users really deserve to get such a hidden problem with presumably "official" Wine package they have recieved? 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? -- Dmitry.

March 3, 2011

Why am I getting create_view out of memory?

by Peter Urbanec

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

March 3, 2011

Re: USB Osciloscope

by Martin Owens

On Tue, 2011-03-01 at 17:09 -0700, Archie Robertson wrote: > so If somebody could point me in the > right direction I should be able to get this working.

March 2, 2011

Re: [PATCH] shldocvw: Fixed typo = vs == (Coverity)

by Marcus Meissner

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

March 2, 2011

Re: WineHQ Bug 26271

by Juan Lang

> Wine is big and those patches cover only a small aspect. E.g. if a > distribution reports a crypt32 bug it doesn't matter if they use > winepulse.drv or not, right? I'm just opposing the blanket "reject all" > distribution Wine binaries created from modified source. For the Wine > aspects modified by the distributions the distributions will have to do > the heavy lifting. But the way we word that matters too. And of course > we are always free to request a bug reporter to try to reproduce the bug > with unmodified/latest Wine source. Ah. Yes, you're right. The nuances of your disagreement escaped me, as this bug was clearly in an area affected by the unsupported patches. Thanks for the clarification. --Juan

March 2, 2011

Re: WineHQ Bug 26271

by Michael Stefaniuc

Hello Juan, Juan Lang wrote: >>> 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 >> I disagree with this statement. Each distribution modifies the upstream >> Wine in one way or the other. And a blanket "Screw you, use upstream >> Wine if you want support" doesn't cut it. The distributions are for us >> the main consumers of Wine and we should help them provide a good Wine >> experience to their users. > > I don't understand. How are we supposed to support our distributions > when they include unsupported patches? Wine is big and those patches cover only a small aspect. E.g. if a distribution reports a crypt32 bug it doesn't matter if they use winepulse.drv or not, right? I'm just opposing the blanket "reject all" distribution Wine binaries created from modified source. For the Wine aspects modified by the distributions the distributions will have to do the heavy lifting. But the way we word that matters too. And of course we are always free to request a bug reporter to try to reproduce the bug with unmodified/latest Wine source. bye michael

March 2, 2011

Re: USB Osciloscope

by Damjan Jovanovic

On Wed, Mar 2, 2011 at 12:56 PM, Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote: >>>>>> "Shachar" == Shachar Shemesh <shachar(a)shemesh.biz> writes: > Also > Damjan Jovanovic Jan 23 91/4337 "USB architecture: driver loading question" > tried to take up the subject, again with no feedback. For the record, I haven't had much feedback on that "driver loading question" either, so I've had little to go on. But since I see many people are interested, I am increasing the priority of that project. > Linux users in the elektronic area would love to see Wine supporting USB > drivers... I've been waiting since 2004... > Archie Damjan Jovanovic

March 2, 2011

Re: WineHQ Bug 26271

by Juan Lang

Hello Michael, >> 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 > I disagree with this statement. Each distribution modifies the upstream > Wine in one way or the other. And a blanket "Screw you, use upstream > Wine if you want support" doesn't cut it. The distributions are for us > the main consumers of Wine and we should help them provide a good Wine > experience to their users. I don't understand. How are we supposed to support our distributions when they include unsupported patches? --Juan

March 2, 2011

Re: WineHQ Bug 26271

by Andreas Bierfert

On Wed, 2011-03-02 at 17:15 +0100, Michael Stefaniuc wrote: > I disagree with this statement. Each distribution modifies the > upstream > Wine in one way or the other. And a blanket "Screw you, use upstream > Wine if you want support" doesn't cut it. The distributions are for us > the main consumers of Wine and we should help them provide a good Wine > experience to their users. Thanks. > Of course in this specific case aka bug 26271 we cannot help as it > involves winepulse.drv which is an unsupported outside patch As stated in 26271 the problem also occurs if build without the pulse patches. Help/insight in fixing this would be appreciated. - Andreas -- BRef Andreas Bierfert, M.Sc. | phone: +49 6897 1721738 | GPG: C58CF1CB andreas.bierfert(a)lowlatency.de | fax: +49 6897 1722828 | signed/encrypted http://lowlatency.de | cell: +49 170 9665206 | mail preferred

March 2, 2011

Re: WineHQ Bug 26271

by Michael Stefaniuc

Hello Dmitry, Dmitry Timoshkov wrote: > 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 I disagree with this statement. Each distribution modifies the upstream Wine in one way or the other. And a blanket "Screw you, use upstream Wine if you want support" doesn't cut it. The distributions are for us the main consumers of Wine and we should help them provide a good Wine experience to their users. Of course in this specific case aka bug 26271 we cannot help as it involves winepulse.drv which is an unsupported outside patch. > 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. bye michael

March 2, 2011

Re: t2embed: Add stub for _TTEmbedFont

by Dmitry Timoshkov

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.

March 2, 2011