wine-devel November 2008

110 participants
239 discussions

General script for installing Wine build dependencies

by Dan Kegel

I have in the past written one script per version of Ubuntu to install Wine's build dependencies. Many versions on, that's getting old, and I figure it'd be better to have a single script that handles all common versions on Linux. I've taken a first stab at that, combining my scripts for gutsy and hardy, and adding ibex. The result is at http://winezeug.googlecode.com/svn/trunk/install-wine-deps.sh If anyone wants to add support to that script for another OS, please do, and send me the patch. I'd like to see this in the wine tree sometime. It's kind of silly we have to direct people to a big, confusing wiki page (or set of them) to explain how to install the needed packages; let's just have a unified script and be done with it.

15 years, 5 months

patchwatcher status: still offline

by Dan Kegel

Let me know if these updates get annoying. I'm bringing up a three-node patchwatcher cluster (master plus two build slaves), and updating http://winezeug.googlecode.com/svn/trunk/patchwatcher/readme.txt as I go. It's coming along ok, but it'll probably be another few days before it's up. - Dan

15 years, 5 months

[Re] Vertex pipeline replacement

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, 5 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, 5 months

Re: [PATCH] mountmgr: Add and remove drives when they are (un)mounted.

by Vitaliy Margolen

Lei Zhang wrote: > Hi, > > It looks like mountmgr.sys does not remove drives when devices are > unmounted. We should look at the is_mounted property and take the > appropriate action when it changes. This is going the wrong way. Wine already can't deal with blank media without some "hackish" workarounds. With this patch you will break even that. Wine should keep drive visible for applications even if there is not media or a blank media inserted. Vitaliy.

15 years, 5 months

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

by Rob Shearman

2008/10/31 Dan Kegel <dank(a)kegel.com>: > 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. > > Later we should provide a script to set up > a local test server that can handle all of > our conformance tests' requests, but for > now, just letting patchwatcher or winetest > redirect everything to localhost will let tests > fail reliably instead of randomly. > See http://bugs.winehq.org/show_bug.cgi?id=15716 This approach won't help users of the Wine conformance tests running on Windows, so it appears to me to be a flawed approach. We should instead rewrite any existing tests that use a public server to instead use a server started by the Wine test code (see dlls/wininet/tests/http.c:server_thread). This has the additional benefit of allowing us to be much more precise with what we're testing and to be able to emulate the implementations of different HTTP servers, instead of just what winehq.org runs. -- Rob Shearman

15 years, 5 months

patchwatcher status: offline

by Dan Kegel

I'm taking the patchwatcher machines down to upgrade them to Intrepid Ibex this weekend. Incidentally, a jaguar plowed through the corner of our garage here at home. For a short while it was a 2.1 car garage :-) I may be somewhat distracted until that's dealt with somehow. - Dan

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

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 November 2008