August 2012 - Wine-Devel - list.winehq.org

Re: Have there been any problems with Wine on GCC 4.7?

by Austin English

On Thu, Aug 23, 2012 at 12:56 PM, Eric Pouech <eric.pouech(a)orange.fr> wrote: > >> -g was already the default. Most packagers (to my knowledge) provide a >> separate debug package, which isn't installed by default. >> > i'm not especially speaking of packagers, but folks who compile wine > themselves with something like: > ./configure CFLAGS=-O2 > and your patch forces -gdwarf2 (whatever -g is requested or not in CFLAGS) > hence providing debug info when the user didn't ask for it > > A+ AJ's taken care of it: http://source.winehq.org/git/wine.git/commitdiff/ce48e2c8ab4537fb57e4416d03… -- -Austin

Aug. 23, 2012

Re: d3dx9: ID3DXConstantTable

by Rico Schüller

On 23.08.2012 15:43, Józef Kucia wrote: > I would prefer you to clean it up submit it. I hope it gets committed > this time. Ok, I'll try to clean them and send them. I will do it the safe way and compare each handle with all handles we have. If it is slow, we could easily move by using the highest bit for comparison against the D3DXHANDLE. We just have to take care that an easy switch is possible. Thanks for the input. Rico

Aug. 23, 2012

Re: Have there been any problems with Wine on GCC 4.7?

by Eric Pouech

> -g was already the default. Most packagers (to my knowledge) provide a > separate debug package, which isn't installed by default. > i'm not especially speaking of packagers, but folks who compile wine themselves with something like: ./configure CFLAGS=-O2 and your patch forces -gdwarf2 (whatever -g is requested or not in CFLAGS) hence providing debug info when the user didn't ask for it A+

Aug. 23, 2012

Re: hhctrl.ocx: Make MergeChmProperties() static.

by Erich E. Hoover

I'm going to need MergeChmProperties() for HH_SET_WIN_TYPE. I've just been really busy lately and have not had a chance to cleanup my patches yet (from discussions with Jacek it looks like we need to redo storing HH_WINTYPE data a little bit). Erich

Aug. 23, 2012

Re: [PATCH 1/3] dinput: Disable linuxinput or linux joysticks based on registry key (try 2)

by Alexandre Julliard

Lucas Zawacki <lfzawacki(a)gmail.com> writes: >> That's better, thanks. You probably want to put them under a subkey >> though, to avoid mixing up the joystick names with the other >> configuration values. > > No problem. If I put them under a key "Disabled" I think it's ok to > not ask for a value, just a key with the joystick name right? It's better to use something like "Joysticks" and explicit values, we may want more per-joystick options at some point. -- Alexandre Julliard julliard(a)winehq.org

Aug. 23, 2012

Re: [PATCH 1/3] dinput: Disable linuxinput or linux joysticks based on registry key (try 2)

by Lucas Zawacki

> That's better, thanks. You probably want to put them under a subkey > though, to avoid mixing up the joystick names with the other > configuration values. No problem. If I put them under a key "Disabled" I think it's ok to not ask for a value, just a key with the joystick name right?

Aug. 23, 2012

Re: [PATCH 2/3] joy.cpl: Using joystick name suffixed with driver when in Linux (try 2)

by Lucas Zawacki

> I think dinput should be appending that to the returned name, joy.cpl > shouldn't have to know about the specific naming scheme of the driver. Do you mean change the reported name directly at device creation time? I could do that and I guess that would be mostly harmless, do other people working on dinput have something against this?

Aug. 23, 2012

Re: d3dx9: ID3DXConstantTable

by Alexandre Julliard

Rico Schüller <kgbricola(a)web.de> writes: > So in cases, where the exe is linked with LARGEADDRESSAWARE, d3dx9 > would have to be used with D3DXCONSTTABLE_LARGEADDRESSAWARE. Yes, but in practice apps don't do that. Eve Online was reportedly one of the offenders, there are certainly others. -- Alexandre Julliard julliard(a)winehq.org

Aug. 23, 2012

Re: d3dx9: ID3DXConstantTable

by Józef Kucia

On Wed, Aug 22, 2012 at 2:45 PM, Rico Schüller <kgbricola(a)web.de> wrote: > Well, I just had a closer look again. My speed test triggers a problem, so > it's not really comparable. But it looks like native only allocates > handles, if it really needs them. So I'm not sure we like to go the same > approach or if it is fine allocating them all like I've done that. I fixed > the test and native speed advantage was blown away. Although, if that's > fine with your opinion, you could reuse the code or I could clean it up a > bit and send it. I haven't send it and improved it, yet, because the > problem with solution 1. or 2. isn't solved for me. I'm a little bit > against version 1., because I think speed might be an issue and no one had > a technical argument against 2. I don't think a extra handle list for > handles with "small" values is the way to got, because it may also hit the > values where strings could be in memory. The extra handle list would be 3., > but I think it needs a lot more memory for just adding a "layer" for > checking the handles. Thus 2. is a lot better than 3. (which I haven't > explained in detail). > I would prefer you to clean it up submit it. I hope it gets committed this time. > So in cases, where the exe is linked with LARGEADDRESSAWARE, d3dx9 would > have to be used with D3DXCONSTTABLE_LARGEADDRESSAWARE. That way it's the > same for os with 32bit and 64bit. The only problem I see, nowhere is said, > that the 2gb will always be the lowest 2gb. But my tests showed, that I > always get the lower 31bit of addresses in my test runs when allocating > memory. Thus I'm very unlucky by not getting a higher address or this might > be the way it works on windows. Has anyone a technical argument against > this solution? > It seems fine to me. A program compiled without *LARGEADDRESSAWARE* should get all the memory allocated below the 2 GB limit (see http://msdn.microsoft.com/en-us/library/windows/desktop/aa384271%28v=vs.85%… ). -- Józef Kucia

Aug. 23, 2012

Re: Testing Gdi+

by Dmitry Timoshkov

Stepa Nick <hired777(a)gmail.com> wrote: > I`m new in WINE development. I have some tests cases, that works > incorrect in current version of WINE and I want to fix this mistakes. > So, I`m interesting are there some testing systems that compares > bitmap(for example)? I look thru WINE tests, > http://www.winehq.org/docs/winedev-guide/testing and had found only > tests, that compare some variables to constant. I think, that WINE > needs graphics test. Comparing resulting image/bitmap output of gdiplus between Wine and Windows is not useful, because they will always differ, even in small details. Better spend your time comparing numeric values, have a look at existing gdiplus tests how it's done there. If you can't for some reason figire it out just open a bug report and attach your source code there with detailed description of the problem(s). -- Dmitry.

Aug. 23, 2012