On 8/30/2013 16:28, Piotr Caban wrote:
---
dlls/oleaut32/tests/typelib.c | 13 +++--
dlls/oleaut32/typelib.c | 13 +++--
2 files changed, 22 insertions(+), 4 deletions(-)
ITypeInfoImpl *This = info_impl_from_ICreateTypeInfo2(iface);
-FIXME("%p %u %s - stub\n",
On 08/22/2013 04:08 PM, Alexandre Julliard wrote:
Nikolay Sivov writes:
Some tests for LoadRegTypeLib() with activated context
From 1ea3d8c82dd77ac14f2cdec748c0284032958b2f Mon Sep 17 00:00:00 2001
From: Nikolay Sivov
Date: Wed, 21 Aug 2013 12:34:47 +0400
Subject: [PATCH 5/6] Some tests for
Nikolay Sivov writes:
> Some tests for LoadRegTypeLib() with activated context
>
> From 1ea3d8c82dd77ac14f2cdec748c0284032958b2f Mon Sep 17 00:00:00 2001
> From: Nikolay Sivov
> Date: Wed, 21 Aug 2013 12:34:47 +0400
> Subject: [PATCH 5/6] Some tests for LoadRegTypeLib() with activated context
I
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=26136
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=26136
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=25960
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=25961
Your paranoid android
Sorry, I should have labelled this patch as "Try 2".
--
Andy.
Andrew Talbot writes:
> Changelog:
> oleaut32: Indentation Fix.
Please avoid reformatting hundreds of lines for no reason. Only fix the
parts where the indentation is actually incorrect.
--
Alexandre Julliard
julli...@winehq.org
Alistair Leslie-Hughes writes:
> diff --git a/dlls/oleaut32/typelib.c b/dlls/oleaut32/typelib.c
> index fa9b050..04914e0 100644
> --- a/dlls/oleaut32/typelib.c
> +++ b/dlls/oleaut32/typelib.c
> @@ -2544,9 +2544,11 @@ static HRESULT TLB_PEFile_Open(LPCWSTR path, INT
> index, LPVOID *ppBase, DWORD
Heh, sure I can do that. I did that initially with test_tlb.idl but after
that I got a bunch of failures cause of existing tests. I will update
existing tests then.
On Fri, Dec 14, 2012 at 7:09 PM, Alexandre Julliard wrote:
> Nikolay Sivov writes:
>
> > Don't know what it wants here. Probably i
Nikolay Sivov writes:
> Don't know what it wants here. Probably it doesn't like new idl file?
I don't like it either ;-) Any chance you could put that in one of the
existing files?
--
Alexandre Julliard
julli...@winehq.org
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=23397
Your paranoid android
Don't know what it wants here. Probably it doesn't like new idl file?
On Fri, Dec 14, 2012 at 3:15 PM, Marvin wrote:
> 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 co
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=21195
Your paranoid android
Alistair Leslie-Hughes wrote:
> Changelog:
> oleaut32: VaraintChangeType to support VT_BSTR to VT_UI2|VT_ARRAY
Please resend the test separately, your fix conflicts with the patch
sent by Roman Dadkov.
--
Dmitry.
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://winetestbot.dolphin/JobDetails.pl?Key=87
Your paranoid android.
Jacek Caban wrote:
> >> BTW, did you test the app on Windows with disabled BSTR cache? It's easy
> >> to do by setting OANOCACHE environment variable before running the app.
> >> If that breaks the app, then indeed the app is broken in a way that it
> >> depends on BSTR cache behaviour.
> > It's
On 06/05/12 13:31, Dmitry Timoshkov wrote:
> Jacek Caban wrote:
>
>> BTW, did you test the app on Windows with disabled BSTR cache? It's easy
>> to do by setting OANOCACHE environment variable before running the app.
>> If that breaks the app, then indeed the app is broken in a way that it
>> depe
Dmitry Timoshkov writes:
> Alexandre Julliard wrote:
>
>> That doesn't seem very useful. What use case would there be for an app
>> to rely on some random 75% of its strings to remain valid?
>
> Although the test is about statistics, my intention was to show that BSTR
> cache in Wine corrupts ca
Jacek Caban wrote:
> BTW, did you test the app on Windows with disabled BSTR cache? It's easy
> to do by setting OANOCACHE environment variable before running the app.
> If that breaks the app, then indeed the app is broken in a way that it
> depends on BSTR cache behaviour.
It's easy to test un
Hi Dmitry,
On 06/05/12 13:05, Dmitry Timoshkov wrote:
> Alexandre Julliard wrote:
>
>> That doesn't seem very useful. What use case would there be for an app
>> to rely on some random 75% of its strings to remain valid?
> Although the test is about statistics, my intention was to show that BSTR
>
Alexandre Julliard wrote:
> That doesn't seem very useful. What use case would there be for an app
> to rely on some random 75% of its strings to remain valid?
Although the test is about statistics, my intention was to show that BSTR
cache in Wine corrupts cached strings. I could try to figure o
Dmitry Timoshkov writes:
> +for (i = 0; i < sizeof(bstr)/sizeof(bstr[0]); i++)
> +{
> +INTERNAL_BSTR *data = Get(bstr[i]);
> +
> +for (j = 0; j < i; j++) str[j] = '0' + i % 10;
> +
> +if (data->dwLen == i * sizeof(WCHAR))
> +good_length_entries++;
> +
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=18731
Your paranoid android
Am 03.08.2011 22:14, schrieb Octavian Voicu:
> 2011/8/3 André Hentschel mailto:n...@dawncrow.de>>
>
> a80a90fcb7f917ef4ec999007f5a49eb63d1b0a6
>
>
> Doesn't look like a valid commit... which one is that?
>
> Octavian
sry, i mean 862cc73fb4cd8e6c8d454ab822a70a5072cb5dda
--
Best Regards,
2011/8/3 André Hentschel
> a80a90fcb7f917ef4ec999007f5a49eb63d1b0a6
>
Doesn't look like a valid commit... which one is that?
Octavian
André Hentschel writes:
> The hole test_ function depends on succeeding here (more than i thought first)
Actually you'd want to skip even more than that, the real failure is
earlier.
--
Alexandre Julliard
julli...@winehq.org
On Tue, Jul 12, 2011 at 1:19 PM, Alistair Leslie-Hughes
wrote:
> Hi,
>
>
> Changelog:
> oleaut32: Add DISPID_PICT_RENDER support to OLEPictureImpl_Invoke
>
+ case DISPID_PICT_RENDER:
+if (wFlags & DISPATCH_METHOD)
+{
+ TRACE("DISPID_PICT_RENDER %d %d %d %d %d %d %d %d %d %d\n",
+
Hi,
isn't there a white space issue? (trailing)
Regards,
W.
On Thu, Jul 7, 2011 at 2:09 PM, Alistair Leslie-Hughes
wrote:
> Hi,
>
>
> Changelog:
> oleaut32: Implement ICreateTypeInfo2 SetHelpStringContext
>
+ICreateTypeInfo2Impl *This = impl_from_ICreateTypeInfo2(iface);
+
+TRACE("(%p,%d), stub!\n", iface, dwHelpStringContext);
It's not a stub
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=12210
Your paranoid android
Hello Alistair,
Alistair Leslie-Hughes wrote:
> Changelog:
> oleaut32: Implement ICreateTypeInfo2 SetHelpStringContext
>
> dlls/oleaut32/typelib2.c |9 +++--
> 1 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/dlls/oleaut32/typelib2.c b/dlls/oleaut32/typelib2.c
> inde
On Thu, May 19, 2011 at 11:30 AM, Austin English
wrote:
> --
> -Austin
>
>
>
>
This test should use a table+loop I think.
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=9472
Your paranoid android.
On Tue, Feb 22, 2011 at 09:02:38PM +1100, Alistair Leslie-Hughes wrote:
> >From 6aa7bfa0c06b746ee64daf56f2b02e6f38542d54 Mon Sep 17 00:00:00 2001
> From: Alistair Leslie-Hughes
> Date: Fri, 18 Feb 2011 12:04:56 +1100
> Subject: [PATCH] Implement ITypeInfo_GetNames Stub/Proxy
> 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=8987
Your paranoid android.
On 1/24/2011 12:38, Michael Stefaniuc wrote:
Hello Nikolay,
On 01/24/2011 01:01 AM, Nikolay Sivov wrote:
Use implementation pointer to trace ICreateTypeInfo2
diff --git a/dlls/oleaut32/typelib2.c b/dlls/oleaut32/typelib2.c
index 8260ef2..5c843a1 100644
--- a/dlls/oleaut32/typelib2.c
+++ b/dl
Hello Nikolay,
On 01/24/2011 01:01 AM, Nikolay Sivov wrote:
Use implementation pointer to trace ICreateTypeInfo2
diff --git a/dlls/oleaut32/typelib2.c b/dlls/oleaut32/typelib2.c
index 8260ef2..5c843a1 100644
--- a/dlls/oleaut32/typelib2.c
+++ b/dlls/oleaut32/typelib2.c
@@ -2322,6 +2321,7 @
Nikolay Sivov writes:
> Remove S_OK value assumptions, fix potential stream leak
Returning an error value and 0 on success is a common pattern, using a
magic constant for 0 is not an improvement.
--
Alexandre Julliard
julli...@winehq.org
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=7587
Your paranoid android.
André Hentschel writes:
> @@ -10,7 +10,7 @@ C_SRCS = \
> typelib.c \
> usrmarshal.c \
> varformat.c \
> - vartest.c \
> + variant.c \
> vartype.c
Renaming tests should be avoided, it makes it hard to follow the history
on test.winehq.org.
--
Alexandre Julliard
j
Fredag 15 oktober 2010 07:48:17 skrev Trygve Vea :
>
What is being changed here?
Alexander N. Sørnes
On 10/2/10 7:00 PM, Jeremy Drake wrote:
On Sat, 2 Oct 2010, James McKenzie wrote:
Looks like you got 'bit' by the way that a finite storage method mangles
floating information. There was a lengthy discussion on how to 'overcome'
this on the Wine-Development list a short while ago.
No, those
On Sat, 2 Oct 2010, James McKenzie wrote:
> Looks like you got 'bit' by the way that a finite storage method mangles
> floating information. There was a lengthy discussion on how to 'overcome'
> this on the Wine-Development list a short while ago.
No, those tests aleady account for that.
/* Whe
On 10/2/10 10:13 AM, (Marvin) wrote:
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/JobDe
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=5729
Your paranoid android.
Oops, those empty parens () were intended to cite the URL for the article.
Unfortunately, I can't seem to find it now. However, I found an MSDN page
that describes the behavior I am testing here:
http://msdn.microsoft.com/en-us/library/system.datetime.fromoadate.aspx
This is actually documentatio
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
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
> >
+ // 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
> ++
> 1 files changed, 69 insertions(+), 0 deletions(-)
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=3687
Your paranoid android.
On 4/14/2010 23:56, André Hentschel wrote:
Nikolay Sivov schrieb:
On 4/14/2010 22:51, André Hentschel wrote:
case 0x3: /* TTT TTTDD TTTDDD */
- if (iDate&& dp.dwCount == 3)
+ if (dp.dwCount == 3&& !strncmp(ShortDate,"dd.MM.yy",8))
case 0x1B
Nikolay Sivov schrieb:
> On 4/14/2010 22:51, André Hentschel wrote:
>> case 0x3: /* TTT TTTDD TTTDDD */
>> - if (iDate&& dp.dwCount == 3)
>> + if (dp.dwCount == 3&& !strncmp(ShortDate,"dd.MM.yy",8))
>>
>>
>
>> case 0x1B: /* localized DDDTTT */
>> - if (!iDate)
>> +
On 4/14/2010 22:51, André Hentschel wrote:
case 0x3: /* TTT TTTDD TTTDDD */
- if (iDate&& dp.dwCount == 3)
+ if (dp.dwCount == 3&& !strncmp(ShortDate,"dd.MM.yy",8))
case 0x1B: /* localized DDDTTT */
- if (!iDate)
+ if (strncmp(ShortDate,"dd.MM.yy",8))
André Hentschel writes:
> @@ -7708,7 +7708,7 @@ HRESULT WINAPI VarDateFromStr(OLECHAR* strIn, LCID
> lcid, ULONG dwFlags, DATE* pd
>break;
>
> case 0x1B: /* localized DDDTTT */
> - if (!iDate)
> + if (PRIMARYLANGID(lcid) != LANG_GERMAN)
Obviously you cannot hardcode spe
A test case would be a good idea.
After spending a consider amount of time trying to writing a test case, It
always failed on an XP box.
This patch would just hide the issue instead of truly fixing it.
Best Regards
Alistair Leslie-Hughes
Can you write a test for that?
Alistair Leslie-Hughes writes:
> Both FADF_HAVEVARTYPE and FADF_RECORD both store information at
> negative 4 in the safearray, and ODBC(native MDAC) can attempt to copy
> an array with both of these flags set.
A test case would be a good idea.
--
Alexandre Julliard
julli...@winehq.org
We may search multiple modules/types, and we shouldn't necessarily
return the failure code of the last one we searched. If we ever get a
type mismatch error, we should return that error, but the last result
we get will most likely be "not found", or S_OK with a DESCKIND_NONE.
(I'm not sure whether
On 3/12/2010 23:56, Vincent Povirk wrote:
ITypeLibImpl *This = impl_from_ITypeComp(iface);
ITypeInfoImpl *pTypeInfo;
+int typemismatch=0;
Do you really need this one? Looks like it's enough to move hr at top
level and use it.
André Hentschel writes:
> diff --git a/dlls/oleaut32/variant.c b/dlls/oleaut32/variant.c
> index 450856f..4ed4f01 100644
> --- a/dlls/oleaut32/variant.c
> +++ b/dlls/oleaut32/variant.c
> @@ -85,6 +85,7 @@ static inline HRESULT VARIANT_Coerce(VARIANTARG* pd, LCID
> lcid, USHORT wFlags,
>HRESU
On 3/2/2010 19:31, Alexandre Julliard wrote:
Nikolay Sivov writes:
Unfortunately I don't have a 64bit to cross-build a test on it. Should
it just be 4? or there's something more complicated?
Most likely more complicated, test cases are probably in order.
Ok, just tried with test
Nikolay Sivov writes:
> Unfortunately I don't have a 64bit to cross-build a test on it. Should
> it just be 4? or there's something more complicated?
Most likely more complicated, test cases are probably in order.
--
Alexandre Julliard
julli...@winehq.org
On 03/02/2010 05:26 PM, Nikolay Sivov wrote:
On 3/2/2010 19:21, Paul Vriens wrote:
On 03/02/2010 05:16 PM, Nikolay Sivov wrote:
On 3/2/2010 19:01, Alexandre Julliard wrote:
Nikolay Sivov writes:
@@ -239,6 +239,8 @@ static unsigned int get_type_size(ULONG *pFlags,
VARTYPE vt)
case VT_DISPATCH
On 3/2/2010 19:21, Paul Vriens wrote:
On 03/02/2010 05:16 PM, Nikolay Sivov wrote:
On 3/2/2010 19:01, Alexandre Julliard wrote:
Nikolay Sivov writes:
@@ -239,6 +239,8 @@ static unsigned int get_type_size(ULONG *pFlags,
VARTYPE vt)
case VT_DISPATCH:
case VT_RECORD:
return 0;
+ case VT_INT_PTR:
On 03/02/2010 05:16 PM, Nikolay Sivov wrote:
On 3/2/2010 19:01, Alexandre Julliard wrote:
Nikolay Sivov writes:
@@ -239,6 +239,8 @@ static unsigned int get_type_size(ULONG *pFlags,
VARTYPE vt)
case VT_DISPATCH:
case VT_RECORD:
return 0;
+ case VT_INT_PTR:
+ return sizeof(INT_PTR);
This won't
On 3/2/2010 19:01, Alexandre Julliard wrote:
Nikolay Sivov writes:
@@ -239,6 +239,8 @@ static unsigned int get_type_size(ULONG *pFlags, VARTYPE vt)
case VT_DISPATCH:
case VT_RECORD:
return 0;
+case VT_INT_PTR:
+return sizeof(INT_PTR);
This won't do
Nikolay Sivov writes:
> @@ -239,6 +239,8 @@ static unsigned int get_type_size(ULONG *pFlags, VARTYPE
> vt)
> case VT_DISPATCH:
> case VT_RECORD:
> return 0;
> +case VT_INT_PTR:
> +return sizeof(INT_PTR);
This won't do the right thing on 64-bit.
--
Alexandre Jull
André Hentschel writes:
> ---
> dlls/oleaut32/tests/varformat.c | 10 --
> dlls/oleaut32/varformat.c |3 ++-
> dlls/oleaut32/variant.c |2 +-
> 3 files changed, 11 insertions(+), 4 deletions(-)
It doesn't work:
../../../tools/runtest -q -P wine -M oleaut32.dll -
André Hentschel writes:
> Old version of that function only used if-statements which is not the best
> solution for a math problem.
It doesn't work here:
../../../tools/runtest -q -P wine -M oleaut32.dll -T ../../.. -p
oleaut32_test.exe.so vartest.c && touch vartest.ok
vartest.c:1759: Test fa
Aric Stewart writes:
> Meaning the place where I am finding this is different bug?
>
> In deserialize_param in the VT_BSTR case if the byte_length of the
> BSTR that we are deserializing is -1 then BSTR_UserUnmarshal places
> NULL into *arg.
>
> I will admit I know very little about this code bu
Aric Stewart wrote:
Meaning the place where I am finding this is different bug?
In deserialize_param in the VT_BSTR case if the byte_length of the BSTR
that we are deserializing is -1 then BSTR_UserUnmarshal places NULL
into *arg.
I will admit I know very little about this code but having i
Meaning the place where I am finding this is different bug?
In deserialize_param in the VT_BSTR case if the byte_length of the BSTR
that we are deserializing is -1 then BSTR_UserUnmarshal places NULL
into *arg.
I will admit I know very little about this code but having it crash when
trying
Aric Stewart writes:
> @@ -68,10 +68,16 @@ typedef struct _marshal_state {
>
> /* used in the olerelay code to avoid having the L"" stuff added by
> debugstr_w */
> static char *relaystr(WCHAR *in) {
> -char *tmp = (char *)debugstr_w(in);
> -tmp += 2;
> -tmp[strlen(tmp)-1] = '\0'
Austin English wrote:
> On Sat, Oct 24, 2009 at 5:13 PM, Jeremy White wrote:
>> Has the side effect of preventing a test failure which occurs only when
>> running with +heap.
>
> Woohoo! Should fix:
> http://bugs.winehq.org/show_bug.cgi?id=14078
No; this patch doesn't address that particular Va
On Sat, Oct 24, 2009 at 5:13 PM, Jeremy White wrote:
> Has the side effect of preventing a test failure which occurs only when
> running with +heap.
Woohoo! Should fix:
http://bugs.winehq.org/show_bug.cgi?id=14078
http://bugs.winehq.org/show_bug.cgi?id=17412
--
-Austin
Hi Vincent,
Vincent Povirk wrote:
As far as I know, this failure only occurs when I do something stupid
like set use_midl_tlb to 1 and don't provide a working
midl_tmarshal.tlb, but I need the test to remind me that I'm an idiot
when I do that. Silently skipping tests is unacceptable.
W
Of course it would probably help if I remembered to attach the patch.
On Mon, Aug 31, 2009 at 5:08 PM, Vincent Povirk wrote:
> This needs an updated prefix to work.
>
>
>
>
--
Vincent Povirk
On Fri, Aug 21, 2009 at 1:42 PM, Juan Lang wrote:
> Ah, fair enough, and clearly oleaut32 belongs in that category. Thanks.
I should have said Windows as technically mingw is still __GNUC__ but
you got the idea.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, a
> There are a few instances of it, at least in code we care about
> sharing with a mingw build
Ah, fair enough, and clearly oleaut32 belongs in that category. Thanks.
--Juan
On Fri, Aug 21, 2009 at 12:31 PM, Juan Lang wrote:
> We don't protect by __GNUC__ for any of our other assembly either,
> even though it all uses GNU assembly syntax. So personally I think
> that part's okay.
There are a few instances of it, at least in code we care about
sharing with a mingw bui
Thanks for the review, Henri.
> I don't know if there's a reason the general approach couldn't work,
> but the code in the patch is gcc specific, so I think it should at
> least be protected by __GNUC__ in addition to __i386__.
We don't protect by __GNUC__ for any of our other assembly either,
ev
2009/8/21 Juan Lang :
> Personally, I don't think the cut-and-paste approach we've been taking
> to fix this works all that well for a 126-argument function, so it
> seems like an assembly approach is the only tenable method. I'm not
> certain whether Jon's approach is the correct one, but since i
Alexandre Julliard wrote:
> Michael Stefaniuc writes:
>
>> Well, Alexandre did the first patch for programs/clock
>> http://source.winehq.org/git/wine.git/?a=commit;h=aa41526c73a5fbcc2c08a9342107ee76173a2b97
>> so it must be right ;). It increases the resilience as errors in one
>> language rc fi
Paul Vriens wrote:
> Michael Stefaniuc wrote:
>> Hello Nikolay,
>>
>> Nikolay Sivov wrote:
>>> Michael Stefaniuc wrote:
instead of including them from an other rc file.
---
>>> What is the purpose of these changes? I'm not talking it's wring :),
>>> just interested.
>> Well, Alexa
Michael Stefaniuc writes:
> Well, Alexandre did the first patch for programs/clock
> http://source.winehq.org/git/wine.git/?a=commit;h=aa41526c73a5fbcc2c08a9342107ee76173a2b97
> so it must be right ;). It increases the resilience as errors in one
> language rc file do not propagate to the other l
Michael Stefaniuc wrote:
Hello Nikolay,
Nikolay Sivov wrote:
Michael Stefaniuc wrote:
instead of including them from an other rc file.
---
What is the purpose of these changes? I'm not talking it's wring :),
just interested.
Well, Alexandre did the first patch for programs/clock
http://so
Michael Stefaniuc wrote:
Hello Nikolay,
Nikolay Sivov wrote:
Michael Stefaniuc wrote:
instead of including them from an other rc file.
---
What is the purpose of these changes? I'm not talking it's wring :),
just interested.
Well, Alexandre did the first patch for prog
Hello Nikolay,
Nikolay Sivov wrote:
> Michael Stefaniuc wrote:
>> instead of including them from an other rc file.
>> ---
>>
> What is the purpose of these changes? I'm not talking it's wring :),
> just interested.
Well, Alexandre did the first patch for programs/clock
http://source.winehq.org/
Paul Vriens wrote:
Huw Davies wrote:
On Wed, Jun 17, 2009 at 03:58:33PM +0200, Paul Vriens wrote:
Huw Davies wrote:
---
dlls/oleaut32/tests/tmarshal.c | 53
+++-
dlls/oleaut32/tests/tmarshal.idl |6 +++
dlls/oleaut32/tests/tmarshal_dispids.h |
Huw Davies wrote:
On Wed, Jun 17, 2009 at 03:58:33PM +0200, Paul Vriens wrote:
Huw Davies wrote:
---
dlls/oleaut32/tests/tmarshal.c | 53 +++-
dlls/oleaut32/tests/tmarshal.idl |6 +++
dlls/oleaut32/tests/tmarshal_dispids.h |1 +
3 files chang
On Wed, Jun 17, 2009 at 03:58:33PM +0200, Paul Vriens wrote:
> Huw Davies wrote:
>> ---
>> dlls/oleaut32/tests/tmarshal.c | 53
>> +++-
>> dlls/oleaut32/tests/tmarshal.idl |6 +++
>> dlls/oleaut32/tests/tmarshal_dispids.h |1 +
>> 3 files change
Huw Davies wrote:
---
dlls/oleaut32/tests/tmarshal.c | 53 +++-
dlls/oleaut32/tests/tmarshal.idl |6 +++
dlls/oleaut32/tests/tmarshal_dispids.h |1 +
3 files changed, 59 insertions(+), 1 deletions(-)
--
Paul Vriens wrote:
Detlef Riekenberg wrote:
On Mi, 2009-04-15 at 13:37 +0200, Paul Vriens wrote:
The lstrcpyW and lstrcatW additions to init() in the tests don't work
on Win95. I guess that's where the new failures come from:
I removed a "broken(hres == VARCMP_GT)", and that's what VarCmp
Detlef Riekenberg wrote:
On Mi, 2009-04-15 at 13:37 +0200, Paul Vriens wrote:
The lstrcpyW and lstrcatW additions to init() in the tests don't work on
Win95. I guess that's where the new failures come from:
I removed a "broken(hres == VARCMP_GT)", and that's what
VarCmp on your w95 machine
On Mi, 2009-04-15 at 13:37 +0200, Paul Vriens wrote:
> The lstrcpyW and lstrcatW additions to init() in the tests don't work on
> Win95. I guess that's where the new failures come from:
I removed a "broken(hres == VARCMP_GT)", and that's what
VarCmp on your w95 machine returned.
My second Pat
Detlef Riekenberg wrote:
http://test.winehq.org/data/f212579ae9a1b770ebd34cec20f95e1977bb57f0/xp_dr-asus/oleaut32:vartest.html
While reading the code for a test failure on all of my Windows
installations,
the current code was already strange:
5436 ok(hres == VARCMP_EQ ||
5437broken(
"Juan Lang" wrote:
> + hr = VarR8FromDec((DECIMAL *)pDecIn, &dbl);
According to PSDK VarR8FromDec() takes a const pointer to the 1st parameter,
to it should be fixed instead of casting const out.
Same for VarDecInt() patch.
--
Dmitry.
Rob Shearman writes:
> 2009/2/9 Alexandre Julliard :
>> Rob Shearman writes:
>>
>>> @@ -874,8 +874,8 @@ unsigned char * WINAPI LPSAFEARRAY_UserMarshal(ULONG
>>> *pFlags, unsigned char *Buf
>>>
>>> *(ULONG *)Buffer = ulCellCount;
>>> Buffer += sizeof(ULONG);
>>> -*(ULON
1 - 100 of 268 matches
Mail list logo
