On 5/3/2011 08:07, Adam Martinson wrote:
Fixes bug 14864.
---
dlls/msxml3/domdoc.c | 255
++
1 files changed, 134 insertions(+), 121 deletions(-)
+case VT_ARRAY|VT_UI1:
+{
+SAFEARRAY* psa;
+BSTR bstr;
+
On 2 May 2011 13:24, Marvin wrote:
> === WXPPROSP3 (32 bit device) ===
> device: unhandled exception c005 at 0040320F
>
For what it's worth, not sure if you figured this out by yourself yet
or not, but you need to handle create_device() failing to create a
device on machines like the testbot t
On 2 May 2011 23:28, John Edmonds wrote:
> Are you suggesting that we turn off message filtering altogether or just for
> the Reset function?
>
Just Reset().
Are you suggesting that we turn off message filtering altogether or just for
the Reset function?
I would like to add that I did disable all message filtering (by commenting
out the code in Wine's wndproc) and the games I was testing worked fine.
However, I did not investigate the effects of that c
Hi Guys!
I'm doing Google Summer of Code 2011 and found out that some of the
functions I was to implement have been implemented while my
application was being processed. This means I have to find some other
functions in D3DX9 to implement. I see that UpdateSemantics and
D3DXWeldVertices are unimpl
On Mon, May 2, 2011 at 10:58, Marcus Meissner wrote:
> On Mon, May 02, 2011 at 10:52:50AM -0500, Austin English wrote:
>> Avoids a Clang bug:
>> http://bugs.winehq.org/show_bug.cgi?id=26754
>
> clang cannot even survive a simple memset() to 0?
http://llvm.org/bugs/show_bug.cgi?id=9830
--
-Austi
On Mon, May 02, 2011 at 10:52:50AM -0500, Austin English wrote:
> Avoids a Clang bug:
> http://bugs.winehq.org/show_bug.cgi?id=26754
clang cannot even survive a simple memset() to 0?
Ciao, Marcus
On 5/2/2011 14:45, Alexandre Julliard wrote:
Nikolay Sivov writes:
@@ -210,11 +210,11 @@ typedef INT (CALLBACK *MRUStringCmpFnA)(LPCSTR lhs,
LPCSTR rhs);
typedef INT (CALLBACK *MRUStringCmpFnW)(LPCWSTR lhs, LPCWSTR rhs);
typedef INT (CALLBACK *MRUBinaryCmpFn)(LPCVOID lhs, LPCVOID rhs, DWO
On 2 May 2011 13:20, Emanuele Oriani wrote:
> Hi, let me agree with you... probably there might be one or two fixes
> somewhere which will make performance go better, but apparently the idea is
> that now, if "early optimization is the root of all evils" was true a while
> a go, I guess we're at a
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=10678
Your paranoid android
On 2 May 2011 13:18, John Edmonds wrote:
> Toki Tori and RUSH both depend on receing WM_ACTIVATEAPP before they will
> start. These messages are currently getting filtered out.
> This resolves bug #25640.
It doesn't look right to me to filter messages during
IWineD3DDevice_ReleaseFocusWindow() b
On 2 May 2011 13:18, John Edmonds wrote:
> + /*Pull all currently available messages. We don't care about messages
> generated after this loop exits.*/
> + while(PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
> + {
> + TranslateMessage(&msg);
> + DispatchMessage(&msg);
> + }
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=10677
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=10676
Your paranoid android
Hi, let me agree with you... probably there might be one or two fixes
somewhere which will make performance go better, but apparently the idea
is that now, if "early optimization is the root of all evils" was true a
while a go, I guess we're at a place where all the small optimizations
should t
Paul Chitescu writes:
> Wine is already plagued by deadlocks in the MM drivers initialization that
> interfere with the loader's lock. Explicit initialization after LoadLibrary
> returns should help getting rid of these.
Considering that the MM drivers don't implement DLL_PROCESS_ATTACH at
all
On Monday 02 May 2011 01:32:59 pm Alexandre Julliard wrote:
> Andrew Eikum writes:
> > @@ -72,11 +73,19 @@ static BOOL load_driver(const WCHAR *name)
> > }
> >
> > #define LDFC(n) do { drvs.p##n = (void*)GetProcAddress(drvs.module,
> > #n);\ -if(!drvs.p##n) return FALSE; } while(0);
Nikolay Sivov writes:
> @@ -210,11 +210,11 @@ typedef INT (CALLBACK *MRUStringCmpFnA)(LPCSTR lhs,
> LPCSTR rhs);
> typedef INT (CALLBACK *MRUStringCmpFnW)(LPCWSTR lhs, LPCWSTR rhs);
> typedef INT (CALLBACK *MRUBinaryCmpFn)(LPCVOID lhs, LPCVOID rhs, DWORD
> length);
>
> -typedef struct tagCR
On 2 May 2011 02:23, Dan Kegel wrote:
> -if (attribute && !negate) {
> -stillOK = stillOK;
> -} else if (!attribute && negate) {
> -stillOK = stillOK;
> -} else {
> +if (
Andrew Eikum writes:
> @@ -72,11 +73,19 @@ static BOOL load_driver(const WCHAR *name)
> }
>
> #define LDFC(n) do { drvs.p##n = (void*)GetProcAddress(drvs.module, #n);\
> -if(!drvs.p##n) return FALSE; } while(0);
> +if(!drvs.p##n) { FreeLibrary(drvs.module); return FALSE; }
20 matches
Mail list logo
