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
* 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
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. Th
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,
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 feat
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
