Hi,
On Thu, Feb 4, 2010 at 7:08 PM, Luca Bennati wrote:
>> Technically, winemenubuilder should be using windowscodecs for its png
>> support, like the rest of wine. I believe Steven Edwards has done some
>> work on this.
>
> Don't know about this. What i know is that currently winemenubuilder sho
> As a side note, you need to do a similar work on winemenubuilder, as it uses
> libpng and fails linking without modifications. to test this images i
> statically linked it to libpng, just to make it work, as it wasn't needed in
> your test.
> Thank you for working on this, since i'm not really an
> * http://www.libpng.org/pub/png/PngSuite/basn4a16.png - This is a
> grayscale png with an alpha channel. That's the situation where we use
> the png_set_gray... function that was removed.
Errr.. I may actually be thinking of
http://www.libpng.org/pub/png/PngSuite/tbbn1g04.png
Could you test the attached patch? It builds with libpng 1.2 and seems
to work, but I'd like to verify that it also solves the problems with
1.4.
If it's not too much trouble, I'd like you to also test the functionality.
There's a program at
http://code.google.com/p/winezeug/source/browse/trunk/a
>On 2/4/2010 00:08, Susan Cragin wrote:
>> wine-1.1.37-412-g9a92f9c
>> With today's git got a debug, dump, etc., while installing dragon
>> naturallyspeaking.
>> have log
>>
>> wine: Call from 0x7b8364e2 to unimplemented function
>> msxml4.dll.DllRegisterServer, aborting
>> wine: Unimplemented fu
png_jmpbuf used to be a macro that accessed fields of png structures
directly. In 1.4.0 it was apparently changed to call
png_set_longjmp_fn.
This is probably because the png developers hate that programmers can
directly access fields in their structures. As I recall, they whine
about this frequen
On 2/4/2010 00:08, Susan Cragin wrote:
wine-1.1.37-412-g9a92f9c
With today's git got a debug, dump, etc., while installing dragon
naturallyspeaking.
have log
wine: Call from 0x7b8364e2 to unimplemented function
msxml4.dll.DllRegisterServer, aborting
wine: Unimplemented function msxml4.dll.DllR
On 2/4/2010 18:24, Reece Dunn wrote:
On 4 February 2010 14:54, Dan Kegel wrote:
This message is being sent in gmail in Chromium running on Wine
with options --no-sandbox --use-nss-for-ssl.
(--use-nss-for-ssl turns on a new alternate https stack that works
in wine.)
This copy of Chromium w
Oh, and the build is slow because it's in wine. It builds about three times
faster on windows.
On Feb 4, 2010 7:11 AM, "Ben Klein" wrote:
On 5 February 2010 01:54, Dan Kegel wrote:
> This message is being sent in gmail in...
Google seriously needs to depend on system libraries rather than buil
The 'new' ssl stack is just the one from Firefox.
On Linux, chromium uses the system's ssl.
On Feb 4, 2010 7:11 AM, "Ben Klein" wrote:
On 5 February 2010 01:54, Dan Kegel wrote:
> This message is being sent in gmail in...
Google seriously needs to depend on system libraries rather than build
th
On 4 February 2010 14:54, Dan Kegel wrote:
> This message is being sent in gmail in Chromium running on Wine
> with options --no-sandbox --use-nss-for-ssl.
>
> (--use-nss-for-ssl turns on a new alternate https stack that works
> in wine.)
>
> This copy of Chromium was built in Wine, too. It took
On 2/4/2010 17:54, Dan Kegel wrote:
This message is being sent in gmail in Chromium running on Wine
with options --no-sandbox --use-nss-for-ssl.
(--use-nss-for-ssl turns on a new alternate https stack that works
in wine.)
This copy of Chromium was built in Wine, too. It took 1 hour
55 minutes
Dan Kegel wrote:
> This message is being sent in gmail in Chromium running on Wine
> with options --no-sandbox --use-nss-for-ssl.
w00t!
Dan Kegel wrote:
> This message is being sent in gmail in Chromium running on Wine
> with options --no-sandbox --use-nss-for-ssl.
>
> (--use-nss-for-ssl turns on a new alternate https stack that works
> in wine.)
>
> This copy of Chromium was built in Wine, too. It took 1 hour
> 55 minutes to co
On 5 February 2010 01:54, Dan Kegel wrote:
> This message is being sent in gmail in Chromium running on Wine
> with options --no-sandbox --use-nss-for-ssl.
>
> (--use-nss-for-ssl turns on a new alternate https stack that works
> in wine.)
>
> This copy of Chromium was built in Wine, too. It took
This message is being sent in gmail in Chromium running on Wine
with options --no-sandbox --use-nss-for-ssl.
(--use-nss-for-ssl turns on a new alternate https stack that works
in wine.)
This copy of Chromium was built in Wine, too. It took 1 hour
55 minutes to compile and link from scratch using
Maarten Lankhorst writes:
> +extern inline LONG WINAPI InterlockedCompareExchange64( LONG64 volatile
> *dest, LONG64 xchg, LONG64 compare );
> +extern inline LONG WINAPI InterlockedCompareExchange64( LONG64 volatile
> *dest, LONG64 xchg, LONG64 compare )
> +{
> +LONG64 ret;
> +__asm__ _
Detlef Riekenberg writes:
> The old tests depend on user language settings, used
> SetLastError(ERROR_SUCCESS) before and GetLastError()
> after the api call for a function, that returns a HRESULT
> and didn't know how the default language fallback works
>
> Tested on all winetestbot machines
It
Hi all,
Just thought I'd post an update on my work, after working a few weeks on
it I am finally at the point where the first applications that use this
new sound api start to work.
Currently it's at
http://repo.or.cz/w/wine/multimedia.git/shortlog/refs/heads/mmdevapi but
I will clean it up
Damjan Jovanovic writes:
> * server: store each window's drop target
>
> The patch series allows OLE drag and drop to work across process boundaries.
ole32 has no business making wineserver calls. This should go through
standard user32 functions.
--
Alexandre Julliard
julli...@winehq.org
Am 03.02.2010 um 19:53 schrieb Henri Verbeet:
> On 3 February 2010 19:06, Stefan Dösinger wrote:
>>
>> Am 03.02.2010 um 18:17 schrieb Henri Verbeet:
>>
>>> On the subject of actually supporting software devices, we should probably
>>> implement those by creating a software or reference adapter
21 matches
Mail list logo
