Changelog: mshtml: Correct test for unknown dispID
Best Regards
Alistair Leslie-Hughes
>From 1d422d3162a048f354671301e9a58e41d7641d94 Mon Sep 17 00:00:00 2001
From: Alistair Leslie-Hughes
Date: Wed, 8 Sep 2010 14:39:53 +1000
Subject: [PATCH] Correct test for unknown dispID
To: wine-patches
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=5096
Your paranoid android.
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=5095
Your paranoid android.
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=5092
Your paranoid android.
2010/9/7 Austin English
> I initially noticed the wrong hemisphere label, but then the
> capitalization was bugging me :-)
>
> --
> -Austin
Hi Austin,
@@ -449,18 +449,18 @@ static void test_TzSpecificLocalTimeToSystemTime(void)
> tzW.DaylightBias=-60;
> tzW.StandardDate.wMonth=10;
>
On 07.09.2010 22:37, Hans Leidekker wrote:
Hi Mikko,
diff --git a/dlls/secur32/schannel.c b/dlls/secur32/schannel.c
index 78757ac..192f9cb 100644
--- a/dlls/secur32/schannel.c
+++ b/dlls/secur32/schannel.c
@@ -1244,6 +1244,15 @@ static SECURITY_STATUS SEC_ENTRY
schan_DecryptMessage(PCtxtHandle
On 07.09.2010 21:29, Juan Lang wrote:
Hi Mikko,
+// This is a bit weird, but windows does it too
You can't use C++-style comments in Wine. You do the same in your
tests patch, too.
Sorry, my bad. I'll fix them up.
--
Mikko
On 07.09.2010 22:37, Hans Leidekker wrote:
@@ -116,6 +128,10 @@ static void InitFunctionPtrs(void)
if(!secdll)
secdll = LoadLibraryA("security.dll");
advapi32dll = GetModuleHandleA("advapi32.dll");
+wsockdll = LoadLibraryA("ws2_32.dll");
+
+if(!wsockdll)
+
On Tue, Sep 7, 2010 at 9:42 PM, Lei Zhang wrote:
> It would be helpful if you provide the content of your debian/
> directory. I wrote my own debian/control file and what not and built a
> wine-gecko-1.1.0 .deb over the weekend. I haven't finished working on
> the main Wine packages, but I'll tak
> @@ -116,6 +128,10 @@ static void InitFunctionPtrs(void)
> if(!secdll)
> secdll = LoadLibraryA("security.dll");
> advapi32dll = GetModuleHandleA("advapi32.dll");
> +wsockdll = LoadLibraryA("ws2_32.dll");
> +
> +if(!wsockdll)
> + printf("Couldn't open ws2_32.d
Hi Mikko,
> diff --git a/dlls/secur32/schannel.c b/dlls/secur32/schannel.c
> index 78757ac..192f9cb 100644
> --- a/dlls/secur32/schannel.c
> +++ b/dlls/secur32/schannel.c
> @@ -1244,6 +1244,15 @@ static SECURITY_STATUS SEC_ENTRY
> schan_DecryptMessage(PCtxtHandle context_handle
> if(buffer->
On Sat, Sep 4, 2010 at 1:09 PM, Ben Klein wrote:
> On 25 August 2010 11:31, Lei Zhang wrote:
>> On Tue, Aug 24, 2010 at 3:06 PM, Ben Klein wrote:
>>> On 24 August 2010 04:34, Lei Zhang wrote:
On Fri, Aug 20, 2010 at 4:00 PM, Ben Klein wrote:
> Hello everyone,
>
> My he
On Tue, Sep 7, 2010 at 10:44 AM, Mikko Rasa wrote:
> ---
> dlls/secur32/schannel.c | 9 +
> 1 files changed, 9 insertions(+), 0 deletions(-)
Howdy Mikko,
> diff --git a/dlls/secur32/schannel.c b/dlls/secur32/schannel.c
> index 78757ac..192f9cb 100644
> --- a/dlls/secur32/schannel.c
>
Hi Mikko,
+// This is a bit weird, but windows does it too
You can't use C++-style comments in Wine. You do the same in your
tests patch, too.
--Juan
Hi,
I see some specfiles that contain 'str' instead of the correct 'wstr'.
Is it worth sending a patch to fix these? If so, only one?
--
Cheers,
Paul.
> From: Paul Chitescu
>
> In a typical Win32 environment the executables don't have relocations since
> they load at a fixed address. Old (Visual C 4.x and older) executables had
> relocations so they could run on Win32s.
Not all that relevant to the patch, but... Newer executables do tend to hav
Ken Thomases wrote:
>Sent: Sep 7, 2010 9:17 AM
>To: James McKenzie
>Cc: "wine-devel@winehq.org"
>Subject: Re: Wine Introduction Page
>
>On Sep 4, 2010, at 2:20 PM, James McKenzie wrote:
>
>> I know it is in git. I don't want to give out bogus information, that's why
>> the question. I don't h
On Sep 4, 2010, at 2:20 PM, James McKenzie wrote:
> I know it is in git. I don't want to give out bogus information, that's why
> the question. I don't have an Intel system here with MacOSX 10.4 installed
> anymore, all of mine are at 10.6.4
>
> Same thing with XCode. I know that the 2.x is
On Tuesday 07 September 2010 06:47:12 pm André Hentschel wrote:
> Am 07.09.2010 17:27, schrieb Marcus Meissner:
> > On Tue, Sep 07, 2010 at 04:37:49PM +0200, André Hentschel wrote:
> >> give the file a try when it only links to ordinals instead of just
> >> stopping execution here. ---
> >> dlls/n
On Tue, 2010-09-07 at 15:56 +0200, Henri Verbeet wrote:
> On 7 September 2010 14:43, misha680 wrote:
> > LPD3DVERTEXELEMENT9 is a D3DVERTEXELEMENT9 *,
> > http://msdn.microsoft.com/en-us/library/bb172630%28VS.85%29.aspx
> >
> > so LPD3DVERTEXELEMENT9 * is a D3DVERTEXELEMENT9 **, and to get at the
On 09/06/2010 10:00 PM, Eric Pouech wrote:
Actually, there's another issue with the same symptoms:
1- program A is launched from shell
2- program A starts another program B (for example winedbg when a fault
occurs)
3- at this point, both A & B can read/write to the console
4- program A exits. As
Am 07.09.2010 17:27, schrieb Marcus Meissner:
> On Tue, Sep 07, 2010 at 04:37:49PM +0200, André Hentschel wrote:
>> give the file a try when it only links to ordinals instead of just stopping
>> execution here.
>> ---
>> dlls/ntdll/virtual.c |4
>> 1 files changed, 0 insertions(+), 4 del
On Tue, Sep 07, 2010 at 04:37:49PM +0200, André Hentschel wrote:
> give the file a try when it only links to ordinals instead of just stopping
> execution here.
> ---
> dlls/ntdll/virtual.c |4
> 1 files changed, 0 insertions(+), 4 deletions(-)
>
> diff --git a/dlls/ntdll/virtual.c b/dl
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=5078
Your paranoid android.
On 7 September 2010 14:43, misha680 wrote:
> LPD3DVERTEXELEMENT9 is a D3DVERTEXELEMENT9 *,
> http://msdn.microsoft.com/en-us/library/bb172630%28VS.85%29.aspx
>
> so LPD3DVERTEXELEMENT9 * is a D3DVERTEXELEMENT9 **, and to get at the
Well yes, but why do you think that makes sense as an argument to
My apologies if my first patch was unclear.
Here is a slightly modified git diff
http://wine.1045685.n5.nabble.com/file/n2806011/patch patch
along with the relevant make test output
http://wine.1045685.n5.nabble.com/file/n2806011/maketestoutput
maketestoutput
The relevant part of the make tes
W dniu 07.09.2010 11:52, Mariusz Pluciński pisze:
W dniu 03.09.2010 13:01, Nikolay Sivov pisze:
On 9/3/2010 13:25, Mariusz Pluciński wrote:
+ WCHAR sInstanceId[40];
+ WCHAR sRegistryPath[8192];
Where does this come from? Sizes I mean.
I did a mistake. sInstanceId needs only 39 characters to s
Austin English writes:
> @@ -658,6 +658,7 @@
> @ stdcall GetTimeFormatA(long long ptr str ptr long)
> @ stdcall GetTimeFormatW(long long ptr wstr ptr long)
> @ stdcall GetTimeZoneInformation(ptr)
> +@ stdcall GetThreadUILanguage() GetUserDefaultUILanguage
You can't do that, the functions are
W dniu 03.09.2010 13:13, Nikolay Sivov pisze:
On 9/3/2010 13:25, Mariusz Pluciński wrote:
+ hr =
IXMLDOMDocument_get_documentElement(lpXMLDocument,&lpXMLRootElement);
+ if(hr == S_FALSE)
+ hr = E_FAIL;
hr != S_OK works.
I want this function to return E_FAIL in the case there's no root
element,
On 7 September 2010 13:21, Joris Huizer wrote:
> In the checkGLcall you changed the sign of the second parameter, but you
> didn't do this in the glTranslatef call.
> This seemed a bit strange (and I don't know which one would be right).
>
The checkGLcall is wrong, though it only affects the mess
While skimming through recently committed patches, I noticed this piece:
+/* Window Coord 0 is the middle of the first pixel, so translate by
1/2 pixels */
+glTranslatef(63.0f / 128.0f, 63.0f / 128.0f, 0.0f);
+checkGLcall("glTranslatef(63.0f / 128.0f, -63.0f / 128.0f, 0.0f
Hi,
I was just reading the emails about the winediag stuff and more
particularly AJ's remark about the 'hypothetical GUI'.
Would it make sense to really start fleshing out the eventlog API so we
can/could log errors (or whatever) in that way? The GUI (or commandline
app) could then 'easily'
W dniu 07.09.2010 12:09, Florian Köberle pisze:
Hello
when running a program using wine it's possible to log +message to get
informed about
all the messages which get sent. This debug channel displays the macro
names like WM_NOTIFY instead
of numbers. The most other debug channels and the regr
Henri Verbeet writes:
> On 7 September 2010 11:23, Alexandre Julliard wrote:
>> Nothing says that winediag messages have to be ERR. If it's not an
>> important failure that all users have to see, it can be a WARN or a
>> TRACE. The hypothetical diagnostic GUI tool can then display those
>> diffe
Eric Pouech writes:
> among the potential fixes:
> S1: no longer do the console attribute management in server, but only
> in kernel32, and only for the livespan of the process creating the
> bare console. this means that the console will not be accessible to
> the children of this process after
Hello
when running a program using wine it's possible to log +message to get
informed about
all the messages which get sent. This debug channel displays the macro
names like WM_NOTIFY instead
of numbers. The most other debug channels and the regression tests
however display numbers.
Functions li
On 7 September 2010 11:23, Alexandre Julliard wrote:
> Nothing says that winediag messages have to be ERR. If it's not an
> important failure that all users have to see, it can be a WARN or a
> TRACE. The hypothetical diagnostic GUI tool can then display those
> differently.
>
Things like not usin
W dniu 03.09.2010 13:01, Nikolay Sivov pisze:
On 9/3/2010 13:25, Mariusz Pluciński wrote:
---
dlls/gameux/Makefile.in | 2 +-
dlls/gameux/gameexplorer.c | 254 +-
dlls/gameux/gameux_private.h | 63 ++
dlls/gameux/tests/gameexplorer.c | 18 ++--
4 files cha
Jan Ohlsen wrote:
> + case TKIND_COCLASS: {
> + ITypeInfo *pSubTypeInfo = NULL;
> + TYPEATTR*tattr2 = NULL;
> + GUID*iid = &(tattr->guid);
Once you set tab size to 8 in your editor, or better will not use tabs
at all, you will notice that
Henri Verbeet writes:
> Note that personally I don't think it's appropriate for "winediag" to abuse
> the __WINE_DBCL_ERR debug class for diagnostic messages.
Nothing says that winediag messages have to be ERR. If it's not an
important failure that all users have to see, it can be a WARN or a
TR
Take a good look at the function's prototype.
On Mon, Sep 6, 2010 at 6:18 PM, Vincent Povirk wrote:
> + // Use IID of the coclass' default
> interface
>
> Don't use C++ comments.
>
> On Mon, Sep 6, 2010 at 10:31 AM, Jan Ohlsen
> wrote:
> >
> > ---
> > dlls/oleaut32/tmarshal.c | 69
> >
On Mon, 6 Sep 2010, Alexandre Julliard wrote:
>> 1. We only set, but never used cbres, so removing it loses nothing.
>> 2. With this patch we now set the return value to VCPN_FAIL in this
>> case. However, this is not the only case in vcpUICallbackProc16;
>> for example, in another case
2010/9/7 misha680
>
> Sorry for reposting - apparently my original nabble link did not work :(
>
> ---
>
> Dear All:
>
> Sorry to bother... I am working on a D3DXCreateMesh/ID3DXMesh patch, and I
> encountered a very strange error.
>
> Specifically, it seems that when passing a LPD3DVERTEXELEMENT
44 matches
Mail list logo
