"Charles Davis" wrote:
I've attached the patch so you can build a gdi32_test.exe that contains
my tests.
Why don't you use the same way of comparing EMFs as other tests do,
compare_emf_bits()/dump_emf_bits()/dump_emf_records()?
--
Dmitry.
Vincent Povirk wrote:
> You still have the loop comparing to 0xff, and the test won't pass on
> windows with the if(0).
Whoops, that must have been an old version of the patch. I fixed the
first one, and the second one should be fixed, too. Now the
BitBlt(...,WHITENESS) call executes on Windows, bu
On Tue, Nov 17, 2009 at 10:52 AM, James Mckenzie
wrote:
> Are there not installer packages for the different UNIXes for Gecko? If
> there are not, then the package should install everywhere, including MacOSX
> and OpenSolaris. If they are system/OS dependent, then my comment stands.
As Jacek
All right, this should be the last one. The tests pass on Wine, and
should pass on Windows if you un-if(0) the call to BitBlt(...,
WHITENESS). I still don't have any results for the many other Windows
versions (95, 98, ME, NT4, 2000, Vista, Win7), so I'm going to wait for
results from these other p
There was a second new error in that file that is probably low hanging fruit:
Conditional jump or move depends on uninitialised value(s)
at invoke_constructor (function.c:243)
by Function_value (function.c:521)
by invoke_prop_func (dispex.c:259)
by jsdisp_call (dispex.c:870)
Marcus Meissner wrote:
On Mon, Nov 16, 2009 at 10:52:04AM +0100, Julius Schwartzenberg wrote:
Dan Kegel wrote:
Julius wrote:
With one file however (GOODTIME.AVI from the win95 cd) I get this
error after about a second:
err:heap:HEAP_ValidateInUseArena Heap 0x11: in-use arena 0x184420
next
(Without a change like this, Valgrind can't properly
detect buffer overruns, but even without Valgrind,
this change will improve Wine's ability to detect
buffer overruns.)
With this change, users can enable buffer overrun
detection in Wine by setting WINE_GLOBAL_FLAGS=0x10.
This is like the overru
On Tue, Nov 17, 2009 at 3:50 PM, Charles Davis wrote:
>> If I comment out the for loop and initialize i to 1, the test succeeds
>> on Windows.
>>
> There's one test that succeeds if there are exactly two BitBlt() records
> in the metafile. The test_BitBlt_record() function just increments i
> (thr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have just tested this patch with the World of Warcraft launcher
(couldn't before due to a mismatch between 32-bit and 64-bit jpeg
versions, and Gentoo masking out jpeg).
After SetFileSecurityW (L"H:\\Games\\World of Warcraft", 0x4, 0x1697c8)
with th
Vincent Povirk wrote:
> Now on windows (with s/if(0)/if(1)/) I get lots of:
>
> metafile.c:740: Test failed: unexpected EMF bits: got 01, expected 0xff
>
> metafile.c:740: Test failed: unexpected EMF bits: got 00, expected 0xff
>
> metafile.c:740: Test failed: unexpected EMF bits: got 00, expect
Now on windows (with s/if(0)/if(1)/) I get lots of:
metafile.c:740: Test failed: unexpected EMF bits: got 01, expected 0xff
metafile.c:740: Test failed: unexpected EMF bits: got 00, expected 0xff
metafile.c:740: Test failed: unexpected EMF bits: got 00, expected 0xff
...
You, uh, do realize me
On 11/17/2009 09:38 PM, Greg Geldorp wrote:
Hi Jörg
The picture on test.winehq.org is a disaster: None of the w95, w98, nt4,
2k, 2k3, Vista, 2k8, w7 machines have performed winmm:wave tests!
They all have no sound configured. Mostly useless.
A lot of those VMware boxes are mine. They come in
OK, try this one. It has the BitBlt(..., WHITENESS) call if(0)'d out, so
the test doesn't crash. I also fixed the issue with the other BitBlt()
failing on Wine (I used a memory DC).
I also put some tests that depend on the WHITENESS call succeeding into
todo_wine blocks. Oddly enough, the check fo
Paul Vriens a écrit :
On 11/15/2009 10:07 PM, Eric Pouech wrote:
(fix for #20681)
Hi Eric,
This new test fails on all 32bit systems:
http://test.winehq.org/data/tests/msvcrt:cpp.html
The only box where there are no failures is a 64bit one, but no tests
are actually run there ;)
Could y
Vincent Povirk wrote:
> On windows, I get:
>
> metafile.c:705: Test failed: CreateDCA error 1801
Hmm... now that I think about it, I think the call to CreateDCA() should
look like this:
hdcDisplay = CreateDCA("DISPLAY", NULL, NULL, NULL);
>
> metafile.c:710: Test failed: BitBlt error 1801
BitBlt(
Hi Jörg
> > The picture on test.winehq.org is a disaster: None of the w95, w98, nt4,
> > 2k, 2k3, Vista, 2k8, w7 machines have performed winmm:wave tests!
> > They all have no sound configured. Mostly useless.
>
> A lot of those VMware boxes are mine. They come in two flavors. Some of
> them (sta
On windows, I get:
metafile.c:705: Test failed: CreateDCA error 1801
metafile.c:710: Test failed: BitBlt error 1801
metafile.c:730: Test failed: unexpected EMF bits: got 01, expected 0xff
metafile.c:730: Test failed: unexpected EMF bits: got 00, expected 0xff
metafile.c:730: Test failed: unexp
On closer inspection, you didn't add a call to your static function,
so that was meaningless.
On Tue, Nov 17, 2009 at 1:59 PM, Vincent Povirk
wrote:
> This passes on my Windows XP vm and on Wine here.
>
> On Tue, Nov 17, 2009 at 12:44 PM, Charles Davis
> wrote:
>> Hi,
>>
>> I have a test that I
This passes on my Windows XP vm and on Wine here.
On Tue, Nov 17, 2009 at 12:44 PM, Charles Davis wrote:
> Hi,
>
> I have a test that I wrote from scratch for bug 4543. It tests the
> operation of BitBlt to a metafile, first from the screen then pure
> whiteness. Unfortunately, I have no Windows
Am 17.11.2009 um 12:16 schrieb Austin Lund:
>>> <0001-ddraw-tests-Fix-test-failure-for-D3DFMT_A2R10G10B10-.txt>
>> Where did this test fail? On Wine or Windows? If it was on windows, which
>> windows version and GPU did you use?
>>
>
> WinXP SP2 running in Virtual box 3.0.8 with guest additions
Hi,
I have a test that I wrote from scratch for bug 4543. It tests the
operation of BitBlt to a metafile, first from the screen then pure
whiteness. Unfortunately, I have no Windows boxes to test on, so I need
people to run my test on Windows. After all, I need to verify that this
test is an accur
Dan Kegel wrote:
http://kegel.com/wine/valgrind/logs/2009-11-16-19.12/diff-urlmon_misc.txt
http://kegel.com/wine/valgrind/logs/2009-11-16-19.12/vg-urlmon_misc.txt
show the new crash
Unhandled exception: page fault on read access to 0xf0f0f0f0 in 32-bit
code (0x0c530e3b).
Register dump:
CS:0023
Vincent Povirk wrote:
On Tue, Nov 17, 2009 at 11:08 AM, Jacek Caban wrote:
I also don't see much point in winelib builds so I don't plan to work on it
myself. It will make things harder to support. The only real point I can see
is if we wanted to provide a package for architectures are not s
On Tue, Nov 17, 2009 at 11:08 AM, Jacek Caban wrote:
> I also don't see much point in winelib builds so I don't plan to work on it
> myself. It will make things harder to support. The only real point I can see
> is if we wanted to provide a package for architectures are not supported by
> PE. Anyw
Yesterday's valgrind results are at
http://kegel.com/wine/valgrind/logs/2009-11-16-19.12/
These were done with updated suppressions; see
http://code.google.com/p/winezeug/source/list?path=/trunk/valgrind/valgrind-suppressions
so don't get too excited about errors going away.
(I really should inclu
Vincent Povirk wrote:
On Tue, Nov 17, 2009 at 9:54 AM, Peter Urbanec wrote:
There's a lot of talk about the new Gecko requirement. At the end of the
day, adding the .cab file to a binary distribution was a trivial 10 minute
exercise. It took another 20 minutes to test everything and figure o
http://kegel.com/wine/valgrind/logs/2009-11-16-19.12/diff-urlmon_misc.txt
http://kegel.com/wine/valgrind/logs/2009-11-16-19.12/vg-urlmon_misc.txt
show the new crash
Unhandled exception: page fault on read access to 0xf0f0f0f0 in 32-bit
code (0x0c530e3b).
Register dump:
CS:0023 SS:002b DS:002b ES:
On 11/17/2009 04:48 PM, Paul Chitescu wrote:
--- ./file.c.orig 2009-08-19 14:25:58.0 +0300
+++ ./file.c2009-11-17 17:26:31.0 +0200
Patches should be relative to the root.
--
Cheers,
Paul.
Paul Vriens schrieb:
> On 11/17/2009 05:14 PM, André Hentschel wrote:
>> +for(i=0;i> +{
>> +lstrcpyA(lf.lfFaceName, TestName[i]);
>
> Hi André,
>
> Even though it would slightly change the size of the patch, I wouldn't
> mind some indentation here (and it would be more in line with th
On Tue, Nov 17, 2009 at 9:54 AM, Peter Urbanec wrote:
> There's a lot of talk about the new Gecko requirement. At the end of the
> day, adding the .cab file to a binary distribution was a trivial 10 minute
> exercise. It took another 20 minutes to test everything and figure out that
> the wiki pag
On 11/17/2009 05:14 PM, André Hentschel wrote:
+for(i=0;i
Hi André,
Even though it would slightly change the size of the patch, I wouldn't
mind some indentation here (and it would be more in line with the style
of the file).
You should also try to keep with the current style in that fil
Peter Urbanec wrote:
Vincent Povirk wrote:
Distro-specific packages just put the
.cab file in the right place. Gecko binaries target windows, not unix
(hence the need for mingw) so they really just depend on a functional
x86 Wine.
There's a lot of talk about the new Gecko requirement. At the e
--- On Tue, 11/17/09, Paul Vriens wrote:
> From: Paul Vriens
> Subject: Re: shell32/tests: Fix Program Manager DDE Conformance Test Failures
> To: "Mikey Alexander"
> Cc: "'wine-devel@winehq.org'"
> Date: Tuesday, November 17, 2009, 6:26 AM
> On 11/17/2009 10:10 AM, Paul Vriens
> wrote:
> > O
Hi, Owen. There's a mistake here.
+hNew = ImageList_Duplicate(iImageList == SHIL_LARGE ? hLarge : hSmall);
+
+/* Get the interface for the new image list */
+if (hNew)
+{
+ret = HIMAGELIST_QueryInterface(hNew, riid, ppv);
+
+if (!SUCCEEDED(ret))
+ImageLi
Vincent Povirk wrote:
Distro-specific packages just put the
.cab file in the right place. Gecko binaries target windows, not unix
(hence the need for mingw) so they really just depend on a functional
x86 Wine.
There's a lot of talk about the new Gecko requirement. At the end of the
day, adding
2009/11/17 Joerg Mayer :
> There is one point in this discussion that I've been asking myself:
> Why does Wine need a Windows Gecko instead of a native (Unix/Linux)
> one? And if the question before makes any sense, wouldn't a native
I'd guess to allow it to interact with Win32 windows etc. instea
> Gecko is not a core part of Wine. It is only needed for an MSHTML
> implementation. There are plenty of apps in existence that do not and
> will not have any use for Gecko. I argue that the size of Gecko is a
> good reason to not require it to be installed for those users who
> *know* they don't
On Tue, Nov 17, 2009 at 8:52 AM, James Mckenzie
wrote:
> Are there not installer packages for the different UNIXes for Gecko? If
> there are not, then the package should install everywhere, including MacOSX
> and OpenSolaris. If they are system/OS dependent, then my comment stands.
Nope, ther
There is one point in this discussion that I've been asking myself:
Why does Wine need a Windows Gecko instead of a native (Unix/Linux)
one? And if the question before makes any sense, wouldn't a native
version be part of a firefox package and thus not need extra packaging?
I'm sorry to ask such a
Jacek Caban skrev:
> Ove Kaaven wrote:
>> Vincent Povirk skrev:
>>
>>> On Mon, Nov 16, 2009 at 5:52 PM, Ove Kaaven wrote:
>>>
(It is actually for similar reasons that binaries must be buildable
on a
clean system (say, a build daemon), without any special (non-free)
tools
Jacek Caban wrote:
>Sent: Nov 17, 2009 7:40 AM
>To: Tom Wickline
>Cc: James Mckenzie , Vincent Povirk
>, wine-devel@winehq.org
>Subject: Re: today's git broke winetricks gecko :-(
>
>Tom Wickline wrote:
>>
>>
>> On Tue, Nov 17, 2009 at 10:27 PM, James Mckenzie
>> mailto:jjmckenzi...@earthlink.ne
Marcus Meissner wrote:
On Mon, Nov 16, 2009 at 11:29:51PM +0100, Ove Kaaven wrote:
Jacek Caban skrev:
Well, I hope that a side effect of installation during wineprefix
creation is that it will force packagers to package gecko
You can't *force* the creation of packages which wou
Ove Kaaven wrote:
Vincent Povirk skrev:
On Mon, Nov 16, 2009 at 5:52 PM, Ove Kaaven wrote:
(It is actually for similar reasons that binaries must be buildable on a
clean system (say, a build daemon), without any special (non-free) tools
or sourceless libraries. Magic libshell32.a in th
On 11/17/2009 03:26 PM, Paul Vriens wrote:
On 11/17/2009 10:10 AM, Paul Vriens wrote:
On 11/14/2009 05:31 PM, Mikey Alexander wrote:
/* Timeout on DdeClientTransaction Call */
#define MS_TIMEOUT_VAL 1000
/* # of times to poll for window creation */
-#define PDDE_POLL_NUM 50
+#define PDDE_POLL_N
Tom Wickline wrote:
On Tue, Nov 17, 2009 at 10:27 PM, James Mckenzie
mailto:jjmckenzi...@earthlink.net>> wrote:
>
+1 as well. Not all UNIXes have Gecko support packages built for them
+1 as well, I haven't tested the changes on OpenSolaris yet, but I
plan to. :)
Which makes -
On Tue, Nov 17, 2009 at 10:27 PM, James Mckenzie wrote:
>
> >
> +1 as well. Not all UNIXes have Gecko support packages built for them
>
+1 as well, I haven't tested the changes on OpenSolaris yet, but I plan to.
:)
Tom
> James McKenzie
>
>
>
--
http://www.wine-reviews.net/
On Tuesday 17 November 2009 04:15:29 pm Nate Gallaher wrote:
> I would just like to second Vincent's suggestion.
>
> Vincent Povirk wrote:
> > It also seems to me that a --disable-gecko-downloader configure switch
> > that would disable the dialog COMPLETELY (even "when needed") would
> > put geck
Nate Gallaher wrote:
>Vincent Povirk wrote:
>> It also seems to me that a --disable-gecko-downloader configure switch
>> that would disable the dialog COMPLETELY (even "when needed") would
>> put gecko on equal footing with optional library requirements. It
>> would mean:
>> * You can warn about th
On 11/17/2009 10:10 AM, Paul Vriens wrote:
On 11/14/2009 05:31 PM, Mikey Alexander wrote:
/* Timeout on DdeClientTransaction Call */
#define MS_TIMEOUT_VAL 1000
/* # of times to poll for window creation */
-#define PDDE_POLL_NUM 50
+#define PDDE_POLL_NUM 150
/* time to sleep between polls */
-#d
I would just like to second Vincent's suggestion.
Vincent Povirk wrote:
It also seems to me that a --disable-gecko-downloader configure switch
that would disable the dialog COMPLETELY (even "when needed") would
put gecko on equal footing with optional library requirements. It
would mean:
* You c
Roderick Colenbrander writes:
> This patch adds an initial implementation of WGL_ARB_create_context
> which is required for OpenGL 3.x support. I have tried some basic GL3
> samples which work and the initial Wine tests.
It doesn't work here:
../../../tools/runtest -q -P wine -M opengl32.dll -T
Andrew Eikum writes:
> ---
> dlls/mshtml/htmldoc3.c | 26 ++
> dlls/mshtml/tests/dom.c | 29 -
> 2 files changed, 50 insertions(+), 5 deletions(-)
It doesn't work here:
../../../tools/runtest -q -P wine -M mshtml.dll -T ../../.. -p
msht
Owen, also please use more reasonable names for particular tests -
dotest means nothing.
On 11/17/09, Paul Vriens wrote:
> On 11/13/2009 06:14 PM, Owen Rudge wrote:
>> ---
>> dlls/comctl32/tests/imagelist.c | 80
>> +++
>> 1 files changed, 80 insertions(+), 0 de
On 11/13/2009 06:14 PM, Owen Rudge wrote:
---
dlls/comctl32/tests/imagelist.c | 80
+++
1 files changed, 80 insertions(+), 0 deletions(-)
Hi Owen,
These tests introduce 3 failures on all 32bit XP boxes:
http://test.winehq.org/data/tests/comctl32:imagelist.h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul Chitescu wrote:
> Hi!
>
> How should server/file.c sd_to_mode() deal with filesystems that don't
> support full POSIX ownership and access permissions? It is quite
> popular to mount FAT filesystems - either from a removable media or a
> partition
Hi!
How should server/file.c sd_to_mode() deal with filesystems that don't support
full POSIX ownership and access permissions? It is quite popular to mount FAT
filesystems - either from a removable media or a partition shared with a
Windows installation.
Furthermore, there could be symlinks t
Ben Klein writes:
> 2009/11/17 Juan Lang :
>>> If a previously-optional component is now deemed to be mandatory, and
>>> that component *on its own* happens to double the download size
>>> required to install Wine, I consider that a problem. Not everyone has
>>> a cable or ADSL2+ connection.
>>
>
Vincent Povirk skrev:
> On Mon, Nov 16, 2009 at 5:52 PM, Ove Kaaven wrote:
>> (It is actually for similar reasons that binaries must be buildable on a
>> clean system (say, a build daemon), without any special (non-free) tools
>> or sourceless libraries. Magic libshell32.a in the source package fa
Am 17.11.2009 um 10:38 schrieb Austin Lund:
>
> <0001-ddraw-tests-Fix-test-failure-for-D3DFMT_A2R10G10B10-.txt>
Where did this test fail? On Wine or Windows? If it was on windows, which
windows version and GPU did you use?
On 11/15/2009 10:07 PM, Eric Pouech wrote:
(fix for #20681)
Hi Eric,
This new test fails on all 32bit systems:
http://test.winehq.org/data/tests/msvcrt:cpp.html
The only box where there are no failures is a 64bit one, but no tests
are actually run there ;)
Could you have a look?
--
Chee
On 11/14/2009 05:31 PM, Mikey Alexander wrote:
/* Timeout on DdeClientTransaction Call */
#define MS_TIMEOUT_VAL 1000
/* # of times to poll for window creation */
-#define PDDE_POLL_NUM 50
+#define PDDE_POLL_NUM 150
/* time to sleep between polls */
-#define PDDE_POLL_TIME 200
+#define PD
2009/11/17 Juan Lang :
>> If a previously-optional component is now deemed to be mandatory, and
>> that component *on its own* happens to double the download size
>> required to install Wine, I consider that a problem. Not everyone has
>> a cable or ADSL2+ connection.
>
> Yes, but it's not updated
62 matches
Mail list logo
