wine-devel October 2008

114 participants
340 discussions

by Tobias Jakobi

Short feedback: - Max Payne 2: works as expected, I don't see any visual changes - Morrowind: 3D rendering breaks completly, minor (blending?) issues in the menu as well - however ingame scenes are fully black now How should I report this? Open a bug? Should I do any regression testing (since your patchset consists of more than one patch)? Greets, Tobias

15 years, 6 months

rfc: refactoring msxml3 to get rid of aggregation

by Michael Karcher

Hello developers, the msxml3 code currently uses aggregation to implement IXMLDOMNode on all of the different DOM tree elements. As the interfaces for these elements are all derived from IXMLDOMNode, a lot of forwarding thunks have to be implemented to get the calls into the inner object. The attached patch series modifies the source code to derive the objects instead, which seems like the more natural approach to get derived interfaces implemented. The attached patches still have to be cleaned up: They contain lines ending with whitespace, incosistent spacing around function call parenthesis, incosistent style of using a cast helper function or direct casting and other small nits. A more important problem with these patches that make me write this mail is that they generate lots of compiler warnings like | domdoc.c:1556: warning: initialization from incompatible pointer type which is of no surprise, as the vtable for domdoc expects a function taking an IXMLDOMDocument as "this" pointer while I provide a function taking an interface pointer to an IXMLDOMNode as "this" pointer. Both of these pointers point to the same address (as usual for derived objects), so the conversion is safe, but the simple-minded C compiler can't know that. The question that arises is how to handle these warnings. a) ignore them (most probably not an option) b) add lots of casts (only way to make the idea of these patches fly) c) write lots of little forwarding functions that convert the this pointer. d) ditch the idea of using derivation instead of aggregation Any oppions on that? I (obviously) think that b is the right solution, but as a quick grep over the Wine source code revealed, this solution seems to be used nowhere. Is that because this is the first place where deriving makes sense or is that because I'm completely off-track? Kind regards, Michael Karcher PS: The munged "From " lines in the attached patches are intentional. They keep my email program from choosing "application/mbox" as MIME type.

15 years, 6 months

Conformance test to try on a windows box.

by Jérôme Gardou

I'm currently implementing the D3DXMatrixStack interface. Could someone try these tests on a windows machine before I go further ?

15 years, 6 months

Re: [try 2] [2/2] mlang: Add implementation offnIMLangFontLink_GetCharCodePages

by Dmitry Timoshkov

"Vitaly Perov" <vitperov(a)etersoft.ru> wrote: > Changed since last send: use mlang internal mlang_data structures instead of > static array. You still haven't done the other part: use Win32 APIs EnumSystemCodePages/ GetCPInfo/WideCharToMultiByte instead of accessing Wine internals directly. -- Dmitry.

15 years, 6 months

DIrectSound on top of openAL ?

by Jérôme Gardou

I was wondering why directsound was not implemented using openal. As direct3d is implemented on top of opengl. I see three major advantages : openAL is cross-platform, whereas alsa is linux-specific. openAL is (sometimes) hardware-accelerated. Wine would bring directsound hardware acceleration to windows vista :) See http://connect.creativelabs.com/openal/OpenAL%20Wiki/OpenAL%C2%AE%20and%20W… for manufacturers which bring hardware accelerated openal drivers... Plus, wine would benefit of the system's openal configuration. No need to chosse between OSS and ALSA, the user would have done it through his openAL configuration.

15 years, 6 months

re: patchwatcher problem

by Dan Kegel

Vitaly Perov wrote: >Today I sent the patch "netapi32: add stub for NetShareAdd" > On the old patchwatcher it fails: > winspool.drv:info.c:1281: Test failed: Parameter size wrong! 4 expected got 0 > My patch changes only netapi32. > I have no idea why the winespool.drv test can fail. Sorry, I think that was my fault. I accidentally ran wine on the patchwatcher account by hand around then. - Dan

15 years, 6 months

Re: malloc to HeapAlloc in dlls/kernel32/process.c

by Michael Stefaniuc

Hello Pete, Pete Myers wrote: > Hi, this is my first ever commit to the Wine project. > > In line with http://wiki.winehq.org/ReplaceMalloc this is a small patch > that changes all malloc calls in ./dlls/kernel32/process.c to HeapAlloc. > > Changelog: > * malloc calls in dlls/kernel32/process.c have been change to HeapAlloc as you might have seen Alexandre removed today those malloc calls himself as those weren't trivial patches. bye michael

15 years, 6 months

Re: wininet: let automated testers force all DNS lookups to return localhost

by Hans Leidekker

On Friday 31 October 2008 12:45:58 Dan Kegel wrote: > The public internet can (and does) go pear-shaped > in the middle of test runs, which means any test > that tries to access the public internet is de facto > flaky, even if it tries to protect itself by skipping > if the internet is down. > > So let's provide a way for automated testers to > force all hostname resolution requests to > return the same result (say, 'localhost' or 'mytestserver'). > Only include this in debugging builds. What happened to your /etc/hosts proposal? It has the advantage that we don't need changes to Wine source code. You would need to duplicate this code in every dll that does networking, if possible. I don't think it will work for wldap32, where there is no lookup call to hook into. -Hans

15 years, 6 months

Re: [Re] Vertex pipeline replacement

by James Mckenzie

James Hawkins <truiken(a)gmail.com> at Oct 30, 2008 9:22 PM wrote about Re: [Re] Vertex pipeline replacement > >On Thu, Oct 30, 2008 at 10:07 PM, James McKenzie ><jjmckenzie51(a)earthlink.net> wrote: >> Tobias Jakobi wrote: >>> Short feedback: >>> - Max Payne 2: works as expected, I don't see any visual changes >>> - Morrowind: 3D rendering breaks completly, minor (blending?) issues in >>> the menu as well - however ingame scenes are fully black now >>> >>> How should I report this? Open a bug? Should I do any regression testing >>> (since your patchset consists of more than one patch)? >>> >>> >> Do a regression test to locate which patch breaks Morrowmind. >> >> If you know which patch might have broken this, start there. If you do >> not, a normal regression test is a good idea. >> > >Tobias is referring to Stefan's RFC concerning his vertex pipeline >replacement patch. Stefan asked for users to test the patch to see if >any games break. Thank you. This is a 'good thing' to do before sending the patch through to wine-patches. It looks like this patch needs more work. James McKenzie

15 years, 6 months

patchwatcher problem

by Vitaly Perov

Hi! Today I sent the patch "netapi32: add stub for NetShareAdd" On the old patchwatcher it fails: > winspool.drv:info.c:1281: Test failed: Parameter size wrong! > 4 expected got 0 My patch changes only netapi32. I have no idea why the winespool.drv test can fail. On the new patchwatcher it have passed. -- Best wishes, Vitaly Perov Russia, Saint-Petersburg. www.etersoft.ru

15 years, 6 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel October 2008