On 24 August 2010 05:00, Jacek Caban wrote:
> The attached patch contains remaining bits.
Haven't tested it, but I was having a flick through, and noticed that
the second hunk for dlls/mshtml/nsembed.c has:
ERR("Could not get nsIDontent interface: %08x\n", nsres);
instead of
ERR("Could not get n
André Hentschel wrote:
> -static const char * const DefSysColors[] =
> +static struct {
> +const char *name;
> +const COLORREF rgb;
> +} DefSysColors[] =
It should be 'static const struct {'.
--
Dmitry.
Morten Rønne wrote:
> 16 bit programs require a compiler that is able to create the old style
> address method in order to be able to test those parts of wine. I have
> been told by Dmitry Timoshkov that I should use OpenWatcom for that. So
> that is what I have done.
I didn't tell you that.
On Tuesday 24 August 2010 00:14:31 Octavian Voicu wrote:
> 2010/8/24 Oldřich Jedlička :
> > +ok((GetRValue(color) == 0xFF && GetGValue(color) == 0xFF &&
> > GetBValue(color) == 0xFF) || + broken(GetRValue(color) == 0xFF
> > && GetGValue(color) == 0 && GetBValue(color) == 0), // b
On Wed, Aug 4, 2010 at 1:29 AM, Mike Kaplinskiy
wrote:
> ---
> server/change.c | 2 ++
> server/device.c | 1 +
> server/fd.c | 18 --
> server/file.c | 1 +
> server/file.h | 3 +++
> server/mailslot.c | 3 +++
> server/mapping.c
Anton Khirnov wrote:
On Sat, Aug 21, 2010 at 07:50:50PM -0700, James McKenzie wrote:
Looks like you did not test the build before running it against the
testbot (I've been guilty of this as well.)
actually i did test it and it worked for some reason, must be magic :)
in any case, after
Morten Rønne wrote:
> I have been working on creating tests for the 16 bit implementation of wine
Great!
Have you seen http://code.google.com/p/win16test/ ?
That's for Win16 binaries, not DOS, but it might have some similarities.
For instance, it also uses openwatcom.
I had trouble back then get
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=4696
Your paranoid android.
2010/8/24 Oldřich Jedlička :
> + ok((GetRValue(color) == 0xFF && GetGValue(color) == 0xFF &&
> GetBValue(color) == 0xFF) ||
> + broken(GetRValue(color) == 0xFF && GetGValue(color) == 0 &&
> GetBValue(color) == 0), // broken driver
> + "got R %02X G %02X B %02X, ex
On Mon, Aug 23, 2010 at 4:47 PM, Vincent Povirk wrote:
> You need to add it to the .spec file too.
Thanks. Bad cut and paste...
--
-Austin
You need to add it to the .spec file too.
On Mon, Aug 23, 2010 at 4:45 PM, Austin English wrote:
> --
> -Austin
>
>
>
>
On 08/23/2010 12:59 PM, GOUJON Alexandre wrote:
Anyway, I've seen mainly two approaches
- if(0)
- /* comment
the crashing ok()
*/
What's the difference ? And why not #if 0 ?
Using if(0) means the code in the body of the if-statement still has to
compile. This can check against errors while m
On Monday 23 August 2010 23:00:24 Octavian Voicu wrote:
> 2010/8/23 Oldřich Jedlička :
> > +// Check it out
>
> You have a C++ style comment in this patch and I don't think it's allowed.
My mistake, I've mixed up the C and C++ comments. I thought // is the C style
(for a while). I will send
2010/8/23 Oldřich Jedlička :
> + // Check it out
You have a C++ style comment in this patch and I don't think it's allowed.
Octavian
Hi
I have been working on creating tests for the 16 bit implementation of
wine, and now I have come so far that I would like some comments on the
way I have chosen to do it.
16 bit programs require a compiler that is able to create the old style
address method in order to be able to test tho
HI all,
(If you're not interested in details, please read the last paragraph).
It's been over year since the last Gecko update. A lot has happen since
then. I've been planning to update our build a bit later, with Firefox 4
codebase, but plans have changed. We had some serious problems with
On Fri, Aug 20, 2010 at 4:00 PM, Ben Klein wrote:
> Hello everyone,
>
> My health has not improved at all since my last call for help with the
> Debian package management. I really need someone to take over from me, or at
> least some help to devise a new set of (semi-)automated build scripts. Any
Hi guys,
A patch has been committed today saying "Make .. crashing like it does
on native".
I know we have to follow (genuine) Windows behavior but I'm wondering
how to handle these cases.
For instance, how to add a test crashing on every Windows ?
Is it useful ? I mean, none program can rely
On 23 August 2010 19:02, paulo lesgaz wrote:
> Both patches work very well (they passed the todo_wine tests)
> But, I think that the second one does not answer to Julliard 's complain
> about tons of if...then
I'm not sure I remember reading that specific comment. I know there
was one about the
Both patches work very well (they passed the todo_wine tests)
But, I think that the second one does not answer to Julliard 's complain about
tons of if...then
Or maybe there is no way to simplify the patch
David
De : Henri Verbeet
À : paulo lesgaz
Cc : wine
On 8/23/10 6:26 PM, Dan Kegel wrote:
Jacek wrote:
I still hope that gecko will be removed from winetricks at some point.
It clearly doesn't belong to winetricks.
That would be nice. Does every distro install wine-gecko yet?
I don't know, but I think we may assume that yes. Otherwise distros
Jacek wrote:
> I still hope that gecko will be removed from winetricks at some point.
> It clearly doesn't belong to winetricks.
That would be nice. Does every distro install wine-gecko yet?
> Also fakeie6 doesn't make sense anymore. We set these registries
> by default for over 2.5 years now.
Am Montag 23 August 2010, 16:03:51 schrieb Alexandre Julliard:
> Stefan Dösinger writes:
> > From 98e8cc5d0b5b2d397c1d904d2537c326ed36d43c Mon Sep 17 00:00:00 2001
> > From: =?UTF-8?q?Stefan=20D=C3=B6singer?=
> > Date: Sun, 22 Aug 2010 19:49:58 +0200
> > Subject: [PATCH 4/4] Enable prelink on x86
Marko Nikolic wrote:
> Andrey Turkin wrote:
>
>> On Monday 23 August 2010 13:16:07 Michael Stefaniuc wrote:
>>> IMHO gcc is *wrong* in emitting a warning there. sizeof(PCMWAVEFORMAT)
>>> is a compile time constant and gcc can see that sizeof(PCMWAVEFORMAT)
>>> falls well inside the number range ex
Alexandre Julliard wrote:
> Marko Nikolic writes:
>
>> What remains is how to correctly remove warning. In this case (and there are
>> many similar in the code), signed function parameter is comparing with
>> values that are natively unsigned. Changing type of the parameter is not
>> possible,
Marko Nikolic writes:
> What remains is how to correctly remove warning. In this case (and there are
> many similar in the code), signed function parameter is comparing with
> values that are natively unsigned. Changing type of the parameter is not
> possible, the same if with sizeof operator.
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=4681
Your paranoid android.
Scott Ritchie wrote:
>Sent: Aug 23, 2010 6:37 AM
>To: Wine Devel
>Subject: Re: New winetricks 20100822: new verb lucida
>
>On 08/23/2010 05:01 AM, Jacek Caban wrote:
>> Hi Dan,
>>
>> On 8/22/10 8:57 PM, Dan Kegel wrote:
>>> Dan Kegel:
>>> gecko: make it work even if WINE isn't set. (How did
Andrey Turkin wrote:
> On Monday 23 August 2010 13:16:07 Michael Stefaniuc wrote:
>> IMHO gcc is *wrong* in emitting a warning there. sizeof(PCMWAVEFORMAT)
>> is a compile time constant and gcc can see that sizeof(PCMWAVEFORMAT)
>> falls well inside the number range expressible by a LONG. Logicall
Marcus Meissner writes:
> So a call to change the protection without calling mprotect() in the end?
> like VIRTUAL_SetProtData() or something?
Something like that yes (and please do it all in virtual.c, that's not
the sort of function you want to make global).
--
Alexandre Julliard
julli...@wi
On Mon, Aug 23, 2010 at 06:37:44AM -0700, Scott Ritchie wrote:
> On 08/23/2010 05:01 AM, Jacek Caban wrote:
> > Hi Dan,
> >
> > On 8/22/10 8:57 PM, Dan Kegel wrote:
> >> Dan Kegel:
> >> gecko: make it work even if WINE isn't set. (How did this get
> >> through?)
> >
> > I still hope that geck
On Mon, Aug 23, 2010 at 03:43:35PM +0200, Alexandre Julliard wrote:
> Marcus Meissner writes:
>
> > @@ -1406,7 +1409,18 @@ static void load_builtin_callback( void *module,
> > const char *filename )
> > }
> > virtual_create_system_view( module, nt->OptionalHeader.SizeOfImage,
> >
Stefan Dösinger writes:
> From 98e8cc5d0b5b2d397c1d904d2537c326ed36d43c Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Stefan=20D=C3=B6singer?=
> Date: Sun, 22 Aug 2010 19:49:58 +0200
> Subject: [PATCH 4/4] Enable prelink on x86_64
Which app needs this?
--
Alexandre Julliard
julli...@winehq.org
Marcus Meissner writes:
> @@ -1406,7 +1409,18 @@ static void load_builtin_callback( void *module, const
> char *filename )
> }
> virtual_create_system_view( module, nt->OptionalHeader.SizeOfImage,
> VPROT_SYSTEM | VPROT_IMAGE | VPROT_COMMITTED
> |
> -
On 08/23/2010 05:01 AM, Jacek Caban wrote:
> Hi Dan,
>
> On 8/22/10 8:57 PM, Dan Kegel wrote:
>> Dan Kegel:
>> gecko: make it work even if WINE isn't set. (How did this get
>> through?)
>
> I still hope that gecko will be removed from winetricks at some point.
> It clearly doesn't belong to w
David Hedberg writes:
> +#define EBE_IMPL(iface) \
> +((IExplorerBrowserEventsImpl*)iface)
> [...]
> +static ULONG WINAPI IExplorerBrowserEvents_fnAddRef(IExplorerBrowserEvents
> *iface)
> +{
> +return InterlockedIncrement(&(EBE_IMPL(iface)->ref));
That's ugly, d
Andrey Turkin wrote:
> On Monday 23 August 2010 13:16:07 Michael Stefaniuc wrote:
>> IMHO gcc is *wrong* in emitting a warning there. sizeof(PCMWAVEFORMAT)
>> is a compile time constant and gcc can see that sizeof(PCMWAVEFORMAT)
>> falls well inside the number range expressible by a LONG. Logically
Hi Dan,
On 8/22/10 8:57 PM, Dan Kegel wrote:
Dan Kegel:
gecko: make it work even if WINE isn't set. (How did this get through?)
I still hope that gecko will be removed from winetricks at some point. It
clearly doesn't belong to winetricks.
Also fakeie6 doesn't make sense anymore. We set
On 23 August 2010 13:49, paulo lesgaz wrote:
> I already sent such a patch. Julliard did not like the gazillions of
> conditions if then.
> I never found a way to avoid them.
> The offset can be computed thanks to the function D3DXGetDeclVertexSize
>
You know, just give the attached patches
I already sent such a patch. Julliard did not like the gazillions of conditions
if then.
I never found a way to avoid them.
The offset can be computed thanks to the function D3DXGetDeclVertexSize
A+
David
De : Henri Verbeet
À : wine-devel@winehq.org
E
Stefan Dösinger writes:
> @@ -31,6 +31,14 @@ int isinf(double x)
>return (!(finite(x) || isnand(x)));
> }
>
> +#elif defined(HAVE_FLOAT_H) && defined(_MSC_VER)
> +#include
You should use proper configure checks instead of _MSC_VER, like we do
for other similar cases.
--
Alexandre Julli
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=4676
Your paranoid android.
Damjan Jovanovic writes:
> Changelog:
> * wincodec.idl: invent an ICNS encoder CLSID
If it's invented it shouldn't be in a public header.
--
Alexandre Julliard
julli...@winehq.org
On 8/23/2010 00:51, Gerald Pfeifer wrote:
---
dlls/comctl32/tooltips.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/dlls/comctl32/tooltips.c b/dlls/comctl32/tooltips.c
index 688d3b5..d17f067 100644
--- a/dlls/comctl32/tooltips.c
+++ b/dlls/comctl32/tooltips.c
On 20 August 2010 21:16, Misha Koshelev wrote:
> Thank you for your helpful feedback on my tests.
>
> This is based mostly on dlls/d3d9/vertexdeclaration.c with some
> changes specific to D3DXDeclaratorFromFVF.
>
> Again, if there are any suggested changes please let me know.
>
As you already ment
On Monday 23 August 2010 13:16:07 Michael Stefaniuc wrote:
> IMHO gcc is *wrong* in emitting a warning there. sizeof(PCMWAVEFORMAT)
> is a compile time constant and gcc can see that sizeof(PCMWAVEFORMAT)
> falls well inside the number range expressible by a LONG. Logically
> there is no difference
Marko Nikolic wrote:
> sizeof expresion always return unsigned type, so it is casted
> when comparing with signed values.
This is ugly.
> ---
> dlls/avifil32/wavfile.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/dlls/avifil32/wavfile.c b/dlls/avifil32/wavfile
47 matches
Mail list logo
