Michael Stefaniuc mstef...@redhat.de writes:
---
dlls/dsound/duplex.c | 86 ++---
1 files changed, 53 insertions(+), 33 deletions(-)
diff --git a/dlls/dsound/duplex.c b/dlls/dsound/duplex.c
index 4a1fbd2..2fcf64c 100644
---
Mike Gibson mike.gib...@storagecraft.com writes:
@@ -144,8 +144,23 @@ LONGLONG WINAPI RtlLargeIntegerShiftRight( LONGLONG a,
INT count )
*/
LONGLONG WINAPI RtlLargeIntegerArithmeticShift( LONGLONG a, INT count )
{
-/* FIXME: gcc does arithmetic shift here, but it may not be true on
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=7515
Your paranoid
Hello,
I noticed in this patch, exactly the same lines are added in all the functions;
wouldn't it be better to add a(n) (inline) function
isComponentEnabled(rec,package) to reduce the repetition?
HTH,
Joris
Francois Gouget fgou...@free.fr writes:
I'm not happy with the situation when we skip a whole test executable.
One issue is that in such a case we don't even extract the executable
right now, thus making it impossible to print the subtest name. So we'd
need a different skip line format for
On Thu, 2010-12-09 at 07:52 -0800, Joris Huizer wrote:
I noticed in this patch, exactly the same lines are added in all the
functions; wouldn't it be better to add a(n) (inline) function
isComponentEnabled(rec,package) to reduce the repetition?
I'm not opposed to consolidating the check in
Am 07.12.2010 22:23, schrieb Joe Dluzen:
Hi all,
I've got the Visual Studio Remote Debugger working with breakpoints,
but not with forcing the process to pause. It immediately exits with
Trace/breakpoint trap. I've tried looking up the error, but it seems
that no one has this specific set
The remote debugger is on Mint 9 32 under WINE1.2 in a virtual
machine. VS2008 is on the host PC, Win7 64. The only command line
output is that Trace/breakpoint trap line, and then the program
exits.
I've filed a bug here: http://bugs.winehq.org/show_bug.cgi?id=25462
and a HowTo here:
Andre:
My computer is set up for 125 dpi (Large Fonts on WindowsXP). Should we be
testing for this as well? This should give different results than what is
stated here. Maybe there is a better way to test this than using a fixed value
of 39 in the ok comparision.
James McKenzie
I was looking into adding better bitmaps for the toolbar controls in
hhctrl.ocx (now that we have fancy alpha transparency support) and I wanted
to make sure that the bitmaps used matched everywhere else in Wine. Looking
into how this works currently, I noticed that keeping all the toolbar
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=7522
Your paranoid
Looking at test results today, seems my 64-bit machine only has 11
failures (compared to 6 for 32-bit):
http://test.winehq.org/data/4ad97d404d30f9ec62649a7b8180f51b7eb4a759/wine_ae-ub1004/version.html
On 12/10/2010 05:11, Austin English wrote:
msxml:domdoc -
http://test.winehq.org/data/4ad97d404d30f9ec62649a7b8180f51b7eb4a759/wine_ae-ub1004-x64/msxml3:domdoc.html
I see a crash in eglibc in another log. Is it a same failure for you?
On Thu, Dec 9, 2010 at 10:25 PM, Nikolay Sivov bungleh...@gmail.com wrote:
On 12/10/2010 05:11, Austin English wrote:
msxml:domdoc -
http://test.winehq.org/data/4ad97d404d30f9ec62649a7b8180f51b7eb4a759/wine_ae-ub1004-x64/msxml3:domdoc.html
I see a crash in eglibc in another log. Is it a same
14 matches
Mail list logo
