On Fri, Feb 6, 2009 at 3:48 AM, Dan Kegel wrote:
> James Mckenzie wrote:
>> It depends on the timeline for the 1.2 release.
>> If this is a long way off, it may be worth the effort.
>
> I don't know. The 1.1 branch has are lots of improvements
> people want; what's so special about Gecko?
> IMHO
James Mckenzie wrote:
> It depends on the timeline for the 1.2 release.
> If this is a long way off, it may be worth the effort.
I don't know. The 1.1 branch has are lots of improvements
people want; what's so special about Gecko?
IMHO we should leave the 1.0 branch alone,
and just get on with 1.
Jacek Caban wrote:
>Sent: Feb 5, 2009 12:28 PM
>To: James Mckenzie
>Cc: Scott Ritchie , wine-devel
>Subject: Re: New Wine Gecko package
>
>James Mckenzie wrote:
>> Jacek Caban wrote:
>>
>>> Scott Ritchie wrote:
>>>
Is this version compatible with Wine 1.0.1 by chance?
On Thu, Feb 05, 2009 at 03:53:04PM +, Rob Shearman wrote:
> 2009/2/4 Marcus Meissner :
> > @@ -442,7 +442,7 @@ static LPWSTR get_url(void)
> >
> > if(size > sizeof(httpW) && !memcmp(url, httpW, sizeof(httpW))) {
> > strcatW(url, v_formatW);
> > -MultiByteToWideChar(CP_ACP, 0
Paul TBBle Hampson wrote:
> On Thu, Feb 05, 2009 at 12:52:23AM +0100, Jacek Caban wrote:
>
>> The last release of Wine Gecko caused a few regressions. Thanks to
>> Alexandre, we've found the reason. The bad news is that the fix
>> requires a new package. I've uploaded RC build to:
>>
>
>
Paul TBBle Hampson schrieb:
> On Thu, Feb 05, 2009 at 12:52:23AM +0100, Jacek Caban wrote:
>
>> The last release of Wine Gecko caused a few regressions. Thanks to
>> Alexandre, we've found the reason. The bad news is that the fix
>> requires a new package. I've uploaded RC build to:
>>
>
>
James Mckenzie wrote:
> Jacek Caban wrote:
>
>> Scott Ritchie wrote:
>>
>>> Is this version compatible with Wine 1.0.1 by chance?
>>>
>>>
>> No, it's technically impossible.
>>
>>
> Is it possible to build a patch upgrade to 1.0.1 to incorporate the new Gecko
> or will we h
Jacek Caban wrote:
>
>Scott Ritchie wrote:
>> Jacek Caban wrote:
>>
>>> Hi all,
>>>
>>> The last release of Wine Gecko caused a few regressions. Thanks to
>>> Alexandre, we've found the reason. The bad news is that the fix requires
>>> a new package. I've uploaded RC build to:
>>>
>>> http://ge
> and no, you _can't_ do "everything in wineserver", because you _still_
> need a mechanism to be able to tell the client (ntdll) to "block".
Well, if there are two fds still, but each end is either a client
(reading or writing) and the other is the wineserver, I believe you
could. That is, the s
2009/2/3 Dmitry Timoshkov :
> "Jeremiah Flerchinger" wrote:
>
>> Stubs basic DDE interface of Progman.exe. Similar to Progman stub in
>> shell32.dll. Both will need to be extended and a 3rd progman interface
>> will need to be added in user32.
>
> Progman DDE interface should be implemented by she
"Jeremiah Flerchinger" wrote:
> The shell32.dll DDE callback isn't always initialized & handling
> Progman calls for all apps. I've seen Progman calls pass
> through the DDE_client and DDE_server of user32.dll instead
> and never go through shell32.dll.
That would IMHO only be possible if the
Detlef Riekenberg wrote:
> I did a speed test for JS with Wine:
>
>
>
> http://v8.googlecode.com/svn/data/benchmarks/v3/run.html
>
> wine 17666004c839a40f1dbc5c98468557091bf3e13c
> Score: 48.5
>
> Richards: 47.7
> DeltaBlue: 56.3
> Crypto: 32.1
>
Scott Ritchie wrote:
> Jacek Caban wrote:
>
>> Hi all,
>>
>> The last release of Wine Gecko caused a few regressions. Thanks to
>> Alexandre, we've found the reason. The bad news is that the fix requires
>> a new package. I've uploaded RC build to:
>>
>> http://gerwazy.lo3.wroc.pl/~jcaban/wine/w
I did a speed test for JS with Wine:
http://v8.googlecode.com/svn/data/benchmarks/v3/run.html
wine 17666004c839a40f1dbc5c98468557091bf3e13c
Score: 48.5
Richards: 47.7
DeltaBlue: 56.3
Crypto: 32.1
RayTrace: 54.9
EarleyBoyer
> i think i've finally come up with an idea that i believe will work:
> double-socketing.
(snip)
> it'll be ok (and desirable) to allow multiple "readers" of the "read"
> socket. what you _don't_ want is more than one reader trying to
> indicate "please start sending a new message" whilst there are
2009/2/4 Marcus Meissner :
> @@ -442,7 +442,7 @@ static LPWSTR get_url(void)
>
> if(size > sizeof(httpW) && !memcmp(url, httpW, sizeof(httpW))) {
> strcatW(url, v_formatW);
> -MultiByteToWideChar(CP_ACP, 0, GECKO_VERSION, -1, url+strlenW(url),
> -1);
> +MultiByteToWideC
I made some tweaks to the mysqld. It seems to have become more stable
and reduced some load on the server in the last 24 hours.
-Newman
Austin English wrote:
> On Wed, Feb 4, 2009 at 11:36 AM, Dan Kegel wrote:
>> It seems hung to me at the moment...
>>
>>
>>
>
> Back up now.
>
On Thu, Feb 05, 2009 at 12:52:23AM +0100, Jacek Caban wrote:
> The last release of Wine Gecko caused a few regressions. Thanks to
> Alexandre, we've found the reason. The bad news is that the fix
> requires a new package. I've uploaded RC build to:
> http://gerwazy.lo3.wroc.pl/~jcaban/wine/wine_ge
Marcus Meissner writes:
> diff --git a/dlls/advapi32/cred.c b/dlls/advapi32/cred.c
> index 9ad4fb1..ab86ed6 100644
> --- a/dlls/advapi32/cred.c
> +++ b/dlls/advapi32/cred.c
> @@ -940,7 +940,8 @@ static void convert_PCREDENTIALW_to_PCREDENTIALA(const
> CREDENTIALW *CredentialW,
> if (Credent
Peter Urbanec writes:
> This patch will save and restore the colours when adding a masked image
> to ImageList.
What's the point of restoring the colors in a DC that gets deleted right
away?
--
Alexandre Julliard
julli...@winehq.org
Christoph von Wittich writes:
> dlls/avifil32/avifile_Uk.rc | 51
> +++
> dlls/avifil32/rsrc.rc |1 +
> 2 files changed, 52 insertions(+), 0 deletions(-)
Please add a From: line with the full name and email of the original
author (or better a
Christoph von Wittich wrote:
> dlls/kernel32/comm.c | 55
> +++--
> 1 files changed, 35 insertions(+), 20 deletions(-)
>
> diff --git a/dlls/kernel32/comm.c b/dlls/kernel32/comm.c
> index d83eacb..11cfda0 100644
> --- a/dlls/kernel32/comm.c
> +++ b/dl
Michael Stefaniuc writes:
> Uwe Bonnes wrote:
>>> "Michael" == Michael Stefaniuc writes:
>>
>> Michael> The change is for Win64 compatibility and it matches the DDK.
>> -MMRESULT WINAPI acmDriverEnum(ACMDRIVERENUMCB fnCallback, DWORD dwInstance,
>>DWORD fdwEnum)
>> +MMRESULT WI
Uwe Bonnes wrote:
>> "Michael" == Michael Stefaniuc writes:
>
> Michael> The change is for Win64 compatibility and it matches the DDK.
> -MMRESULT WINAPI acmDriverEnum(ACMDRIVERENUMCB fnCallback, DWORD dwInstance,
> DWORD fdwEnum)
> +MMRESULT WINAPI acmDriverEnum(ACMDRIVERENUMCB
On Tue, 2009-02-03 at 22:55 +0800, Dmitry Timoshkov wrote:
> "Jeremiah Flerchinger" wrote:
>
> > Stubs basic DDE interface of Progman.exe. Similar to Progman stub in
> > shell32.dll. Both will need to be extended and a 3rd progman interface
> > will need to be added in user32.
>
> Progman DDE in
> main process: blocking-read on namedpipe.
> 5 threads: write to same named pipe
>
> the writes NEVER return (this is with xp).
>
> so that WOULD indicate that there IS a per-pipe mutex (and that there
> are bugs in nt!)
unbelievable.
turns out it's an msvcrt bug (in windows nt). if you use
_
fascinatingly strange observation came out of writing the latest test
(threadwrites) to do namedpipe interoperability testing.
main process: blocking-read on namedpipe.
5 threads: write to same named pipe
the writes NEVER return (this is with xp).
so that WOULD indicate that there IS a per-pipe
> "Michael" == Michael Stefaniuc writes:
Michael> The change is for Win64 compatibility and it matches the DDK.
-MMRESULT WINAPI acmDriverEnum(ACMDRIVERENUMCB fnCallback, DWORD dwInstance,
DWORD fdwEnum)
+MMRESULT WINAPI acmDriverEnum(ACMDRIVERENUMCB fnCallback,
DWOR
Hi Jacek,
"Jacek Caban" wrote in message
news:498a2a37.6070...@codeweavers.com...
> Hi all,
>
> Also the last debug version was accidentally stripped. It will be fixed
> in this release. I'm planning to do the release tomorrow, so it will be
> in Git on Friday.
I've test a few apps (TopStyle, We
29 matches
Mail list logo
