Re: A new demangler test?
On 02/23/2013 02:54 AM, Eric Pouech wrote: Le 21/02/2013 14:33, Max TenEyck Woodbury a écrit : Would it be appropriate to add a test to the name demangler that: 1) Scans all '.dll' and '.spec' files for mangled names, and 2) Tries to decode those names. 3) Prints the mangled and decoded names and where they occur. Success would be that all names decode without the decoder blowing up or failing. adding tests for demangler is good but you just need to have a set of mangled/unmangled strings for the test as core demangler in msvcrt, test should be added here... (but grabbing the mangled strings shall be left out of the test itself) A+ One of the important aspects of name demangling is that it should work on _all_ the names in the current system. The current test does demangle a list of known strings, but that list was incomplete with respect to all the features used in real names the last time I dug into the details (which was none too recently). Scanning for all the real mangled names not only makes sure that the demangler is working properly, it also assures that all the names used are properly formed and decode to their intended values.
Re: [0/13] Patch series description
* On Sat, 23 Feb 2013, André Hentschel wrote: > Am 22.02.2013 15:09, schrieb Saulius Krasuckas: > > * On Thu, 21 Feb 2013, André Hentschel wrote: > > > >> So where do we go from here? > > > > Right to the binary translation (or even dynamic recompilation), I > > guess. > > I won't do that, and i guess there's not much interest out there for > someone else to do it, so have fun :) OK, I understand this. And by main part it probably belongs to different project (qemu-user, I guess). S.
Re: Why complain about X1R5G5B5?
On 23 February 2013 17:20, Henri Verbeet wrote: > Personally, I suspect the test is just overly restrictive. Also, just to clarify something, initially on IRC I was under the impression the driver *only* exposed X1R5G5B5, i.e. instead of X8R8G8B8, while clearly supporting 32 bpp display modes. That would be much more suspicious than just exposing X1R5G5B5 instead of the more common R5G6B5.
Re: Why complain about X1R5G5B5?
On 23 February 2013 16:42, Stefan Dösinger wrote: > There are also potential issues because X1R5G5B5 is a 16 bit format, just > like R5G6B5, which makes depth<->format mapping tricky. If the current setup > uses a color depth of 16 bits and the app does not request a specific adapter > format, which one does the driver choose? > I don't think applications can actually do that. (Although if you mean backbuffer format instead of adapter format there, that would just be whatever format it's currently using.) Personally, I suspect the test is just overly restrictive. Yes, there have been a couple of cases where applications break if you expose e.g. certain texture formats, but I don't think it necessarily makes sense to write tests like that until you actually find an application that breaks because of it. That doesn't mean it isn't a pretty uncommon format and something the QXL people may want to look into, but I don't think we want the tests to fail because of it. CheckDeviceType() probably just fails for every format combination because the driver can't do 3D.
Re: Why complain about X1R5G5B5?
Am 21.02.2013 um 17:24 schrieb Francois Gouget : > In essence our tests say that the driver must not support X1R5G5B5. Why? I think the tests were written this way because we did not find any driver that exposed this format, and we had a lot of cases in other areas where exposing additional features broke games. There are also potential issues because X1R5G5B5 is a 16 bit format, just like R5G6B5, which makes depth<->format mapping tricky. If the current setup uses a color depth of 16 bits and the app does not request a specific adapter format, which one does the driver choose?
Re: [0/13] Patch series description
Am 22.02.2013 15:09, schrieb Saulius Krasuckas: > * On Thu, 21 Feb 2013, André Hentschel wrote: >> Am 21.02.2013 21:31, schrieb Saulius Krasuckas: >>> >>> because I've got new(er) Sparc machine. >> >> You know that you most likely won't ever be able to run x86 apps on that >> machine, only winelib. Do you need that for something? > > Yes, I am aware of endianess issue found by Darwine people when > integrating it with Qemu to run x86/PE binaries on PowerPC: > http://wiki.winehq.org/MacOSX > > It is said byteswapping isn't worth trouble but if Rosetta did it (only in > reverse direction) isn't this issue only about developers work time and > not about performance? > > Then it seems Sparc V9 can switch to little endian to access data. > >> So where do we go from here? > > Right to the binary translation (or even dynamic recompilation), I guess. > > S. > I won't do that, and i guess there's not much interest out there for someone else to do it, so have fun :) -- Best Regards, André Hentschel
