October 2008 - Wine-Devel - list.winehq.org

Re: [Re] Vertex pipeline replacement

by James McKenzie

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. James McKenzie

Oct. 31, 2008

Re: Patchwatcher status

by IneedAname

On Thu, 4 Sep 2008 09:45:52 -0700 "Dan Kegel" <dank(a)kegel.com> wrote: > The new machine has a fairly modern nvidia card, so > more of the tests are actually run. Where can I find the spec of the new machine ? Are you using the closed source driver ? I want to see the full system spec hardware and software please. By the way thank you for your hard work.

Oct. 31, 2008

Re: [PATCH] gdi32: Small patch to fix the return vars of WineEngRemoveFontResourceEx

by James McKenzie

James Hawkins wrote: > On Wed, Oct 29, 2008 at 4:18 PM, Daniel Jakob <wolverine(a)stuniverse.de> wrote: > >> Hi >> >> My first post on the list is just a small patch. >> WineEngRemoveFontResourceEx is currently a stub and should return a zero >> on fail instead of true. >> >> > > Have you thought about the possibility that we return TRUE for a > reason? Maybe an app fails if an error percolates up from > WineEngRemoveFontResourceEx? > > James: The function should return an INT, not a BOOL. Maybe returning a one is better than returning TRUE, if TRUE = 1. However, I don't like changing a TRUE to a FALSE, as is done in both executions of teh called function. A little explanation on why the change is needed is in order here. The question that needs to be answered is: Should the call return a FALSE (0) or a TRUE (1) and then a patch formulated around the answer to this question. James McKenzie

Oct. 31, 2008

patchwatcher status

by Dan Kegel

Both old and new patchwatcher: - fixed the displayed time of patches on the results web page. New patchwatcher: - for some reason it wasn't looking for all the errors the old one did. Fixed. - for some reason I had forgotten to have it actually watch for new commits in git. Fixed. - Better at logging errors during 'make depend' etc.

Oct. 31, 2008

[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

Oct. 31, 2008

Re: [2/2] [PATCH] msxml3: fixed if nesting / ptr checking problems inxmlnode_transformNodemarcus

by Alistair Leslie-Hughes

Hi Marcus, "Marcus Meissner" <marcus(a)jet.franken.de> wrote in message news:35191.4944280454$1225405489(a)news.gmane.org... > Hi,> > htmlDocContentDumpOutput(pOutput, result->doc, NULL);> - if(pOutput)> - { Should this be changed to if(pOutput->buffer), I don't remember if pOutput->buffer can be NULL. Best Regards Alistair Leslie-Hughes _________________________________________________________________

Oct. 31, 2008

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.

Oct. 31, 2008

Re: [PATCH] ntdll: Don't append directory entries if the filename length is less than 1.

by Alexandre Julliard

"Lei Zhang" <thestig(a)google.com> writes: > On Thu, Oct 30, 2008 at 4:08 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: >> "Lei Zhang" <thestig(a)google.com> writes: >> >>> I saw the following in a +file trace a user sent me: >>> >>> trace:file:FindNextFileW returning L"" (L"") >>> >>> I tried fixing FindNextFileW(), but that patch didn't get accepted. >>> I'm guessing we should fix the problem in NtQueryDirectoryFile() so >>> nobody who call it will get back an empty file name. >> >> This should never happen. You should figure out where the empty name >> comes from and fix the caller. > > It's probably because we didn't check d_ino, patch sent. Though > wouldn't it be good to have some sanity checking in append_entry(), > since all the read_directory helper functions use it? I'm not a big fan of the belt-and-suspenders approach. If the callers are behaving correctly there's no need for an extra check, and if they aren't then we shouldn't attempt to cope with their bugs. Besides, there's no guarantee that invalid entries would be empty, they may also contain garbage, and we can't fix that in append_entry. -- Alexandre Julliard julliard(a)winehq.org

Oct. 30, 2008

Re: Wine 1.0.2

by Austin English

On Thu, Oct 30, 2008 at 3:35 AM, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > Why is that needed? I believe Alexandre mentioned that 1.0.1 would be the last release. > > Roderick > >> Please add 1.0.2 target milestone to Bugzilla. >> >> -- >> -Austin >> > > -- > Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger > Asked Alexandre in IRC, who said he wasn't planning on it unless there were enough patches to justify it. I asked because I wasn't sure how to mark any bugs that warrant nomination for 1.0.2. I'll mark them as 1.0.1 for now, if any come up. -- -Austin

Oct. 30, 2008

Re: [PATCH] gdi32: Small patch to fix the return vars of WineEngRemoveFontResourceEx

by James Hawkins

On Wed, Oct 29, 2008 at 4:18 PM, Daniel Jakob <wolverine(a)stuniverse.de> wrote: > Hi > > My first post on the list is just a small patch. > WineEngRemoveFontResourceEx is currently a stub and should return a zero > on fail instead of true. > Have you thought about the possibility that we return TRUE for a reason? Maybe an app fails if an error percolates up from WineEngRemoveFontResourceEx? -- James Hawkins

Oct. 30, 2008