On Wednesday 04 August 2010 10:10:17 Stefan Dösinger wrote:
> Am 03.08.2010
um 21:26 schrieb Oldřich Jedlička:
> > DirectX 1 interface allowed creation
of explicit back buffers, so move
> > the restrictive checks to DirectX 2+
implementations. Don't permit
> > creating of primary surface back buffe
2010/8/4 André Hentschel
> Hi,
> what is the best/easiest/fastest way to hack Wine so it does not start
> winedbg and i can debug it with gdb?
> my problem is that my WineARM works so far that it tries to run winedbg and
> uses its own handlers. but i want that not to happen
> of course it crashe
On 08/04/2010 03:15 PM, Francois Gouget wrote:
On Mon, 2 Aug 2010, Max TenEyck Woodbury wrote:
[...]
This has been discussed elsewhere on this mailing list.
There is a lot of information specific to Wine, particularly its
internal structure, that is not shared with Microsoft's product.
Further,
On Mon, 2 Aug 2010, Max TenEyck Woodbury wrote:
[...]
> > You have chosen not very good name. There is no such a thing as Wine API,
> > Wine implements Win32 API, and doesn't specify/add anything custom to it.
> > The name "WineAPI" implies that Wine defines its own API which is not true,
> > and i
Just resend this one, it's easier that way.
J. Leclanche / Adys
2010/8/3 Mariusz Pluciński :
> W dniu 03.08.2010 13:28, Nikolay Sivov pisze:
>>
>> On 8/3/2010 13:58, Mariusz Pluciński wrote:
>>>
>>> ---
>>> dlls/gameux/Makefile.in | 1 +
>>> dlls/gameux/factory.c | 5 ++
>>> dlls/gameux/gamestat
Folks,
I'll be on vacation until the end of next week, so there won't be any
commits for a while. That shouldn't prevent anybody from making
progress, as we have seen during the recent code freeze ;-)
The next release will be on Friday 20th.
--
Alexandre Julliard
julli...@winehq.org
On 08/04/2010 12:29 PM, Alexandre Julliard wrote:
You can't use Wine exception macros in tests.
I guess my patch [1] was rejected for the same reason but then how to
handle it ?
The test only crashes on NT4 but is needed because some programs use a
NULL descriptor [2]
I'm not allowed
On 8/4/10 5:45 PM, Łukasz Wojniłowicz wrote:
From: Lukasz Wojnilowicz
---
dlls/shdocvw/Makefile.in |1 +
dlls/shdocvw/Pl.rc | 57 ++
2 files changed, 58 insertions(+), 0 deletions(-)
create mode 100644 dlls/shdocvw/Pl.rc
diff --git
Hi Łukasz,
On 08/04/2010 05:45 PM, Łukasz Wojniłowicz wrote:
+CAPTION "Otw�rz URL"
This file needs the UTF-8 pragma.
--
Cheers,
Paul.
> From: Stefan Doesinger
>
> Greg's testbot looks pretty useful by now, but for me it has one major
> problem: It cannot run D3D tests because it is stuck in a virtual machine.
>
> I understand that the core of Winetestbot will stay in VMs, but is there a
> way we can extend it with extra machines?
Hi,
what is the best/easiest/fastest way to hack Wine so it does not start winedbg
and i can debug it with gdb?
my problem is that my WineARM works so far that it tries to run winedbg and
uses its own handlers. but i want that not to happen
of course it crashes somewhere and then tries to start w
Hi,
Jeff Zaroyko wrote:
>> mcicda: 98 tests executed (0 marked as todo, 2 failures), 0 skipped.
>With a dual mode cd which has a data and audio tracks:
>mcicda: 90 tests executed (0 marked as todo, 14 failures), 0 skipped.
>Tried a different cd with audio tracks only:
>mcicda: 90 tests executed (
Detlef Riekenberg writes:
> @@ -37,8 +37,12 @@
> #include "winternl.h"
> #include "wine/debug.h"
> #include "wine/exception.h"
> +#include "wine/unicode.h"
> #include "ntdll_misc.h"
>
> +#include "winsock2.h"
You don't want to include winsock2.h here.
--
Alexandre Julliard
julli...@wineh
Hi,
Greg's testbot looks pretty useful by now, but for me it has one major problem:
It cannot run D3D tests because it is stuck in a virtual machine.
I understand that the core of Winetestbot will stay in VMs, but is there a way
we can extend it with extra machines? I have a few spare boxes wi
On 08/04/2010 08:50 AM, Alexandre Julliard wrote:
Andrew Eikum writes:
User calls SHChangeNotifyRegister with a PIDL like "[Desktop][C:]".
The shell (or whatever) calls SHChangeNotify with a PIDL in the UNIX
filesystem, like "[Desktop][/][home][user][.wine][drive_c]". These
should result
Andrew Eikum writes:
> User calls SHChangeNotifyRegister with a PIDL like "[Desktop][C:]".
> The shell (or whatever) calls SHChangeNotify with a PIDL in the UNIX
> filesystem, like "[Desktop][/][home][user][.wine][drive_c]". These
> should result in a match and the window being notified, but ins
On Wed, Aug 4, 2010 at 4:27 PM, Jeff Zaroyko wrote:
> I noticed the midi notes playing, didn't think much of it.
That's nothing, some tests record whatever comes via the microphone
then play it back. Might be scary if you forget about the tests :)
Octavian
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=4288
Your paranoid android.
On Wed, Aug 4, 2010 at 10:36 PM, wrote:
> Hi,
>
> Wine's testbt job #4280
> http://testbot.winehq.org/JobDetails.pl?Key=4280
> contains both a patch and a binary for new MCICDA=MCI CD-audio tests.
>
> It already contains most of what I want in the initial release but
> would benefit from testing
On 08/04/2010 05:24 AM, Alexandre Julliard wrote:
Andrew Eikum writes:
This fixes bug 18606.
It's possible to refer to the same file in two different ways with PIDLs
in Wine. This can cause notifications via SHChangeNotify to fail to
trigger. To ensure an apples-to-apples comparison, we
Hi,
Wine's testbt job #4280
http://testbot.winehq.org/JobDetails.pl?Key=4280
contains both a patch and a binary for new MCICDA=MCI CD-audio tests.
It already contains most of what I want in the initial release but
would benefit from testing on a broad range of native MS systems.
Please invoke it
Dmitry Timoshkov writes:
> (Marvin) wrote:
>
>> === W98SE (32 bit win) ===
>> win.c:110: Test failed: Wrong result for GWL_HWNDPARENT 076C expected
>>
>> win.c:114: Test failed: Wrong result for GW_OWNER 076C expected
>> win.c:388: Test failed: GWL_HWNDPARENT return va
Hi Stefan,
4.8.2010 13:04:43, Stefan Dösinger :
>
> Am 04.08.2010 um 12:29 schrieb Alexandre Julliard:
>
> > Oldřich Jedlička writes:
> >
> >> +__TRY
> >> +{
> >> +hr = IDirectDraw_CreateSurface(lpDD, NULL, &surf, NULL);
> >> +todo_wine ok(hr == DDERR_INVALIDPARAMS, "ID
(Marvin) wrote:
> === W98SE (32 bit win) ===
> win.c:110: Test failed: Wrong result for GWL_HWNDPARENT 076C expected
>
> win.c:114: Test failed: Wrong result for GW_OWNER 076C expected
> win.c:388: Test failed: GWL_HWNDPARENT return value 076C expected 0
This test
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=4287
Your paranoid android.
Am 04.08.2010 um 12:29 schrieb Alexandre Julliard:
> Oldřich Jedlička writes:
>
>> +__TRY
>> +{
>> +hr = IDirectDraw_CreateSurface(lpDD, NULL, &surf, NULL);
>> +todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw_CreateSurface
>> didn't return 0x%08x, but 0x%08x\n",
>>
Please ignore this patch.
It seems that it does crash all the time, just that sometimes the
debugger won't kick in on win64. There is a bug but it's somewhere
else.
Octavian
Oldřich Jedlička writes:
> +__TRY
> +{
> +hr = IDirectDraw_CreateSurface(lpDD, NULL, &surf, NULL);
> +todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw_CreateSurface
> didn't return 0x%08x, but 0x%08x\n",
> + DDERR_INVALIDPARAMS, hr);
> +}
> +__EXCEPT
Andrew Eikum writes:
> This fixes bug 18606.
>
> It's possible to refer to the same file in two different ways with PIDLs
> in Wine. This can cause notifications via SHChangeNotify to fail to
> trigger. To ensure an apples-to-apples comparison, we convert the
> incoming PIDLs and the filters to
On Wed, Aug 4, 2010 at 3:17 PM, Luca Bennati wrote:
Please send patches to wine-patc...@winehq.org, they are not picked up here.
Thanks!
--
-Austin
From 97a5bd2d2388cf96142414593bb449e5e66a02b1 Mon Sep 17 00:00:00 2001
From: Luca Bennati
Date: Wed, 4 Aug 2010 09:14:40 +0200
Subject: shdocvw: Update Italian translation
---
dlls/shdocvw/It.rc | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/dlls/shdocvw
On 3 August 2010 21:07, Travis Athougies wrote:
> dlls/d3dx9_36/tests/Makefile.in | 1 +
> dlls/d3dx9_36/tests/hlsl.c | 666
> +++
> include/d3dx9shader.h | 11 +
> 3 files changed, 678 insertions(+), 0 deletions(-)
> create mode 100644 d
Am 03.08.2010 um 21:26 schrieb Oldřich Jedlička:
> DirectX 1 interface allowed creation of explicit back buffers, so move the
> restrictive checks to DirectX 2+ implementations. Don't permit creating of
> primary surface back buffer.
The patch(as well as 9 and 10) look OK to me. Patch 6 is OK too
Am 03.08.2010 um 21:26 schrieb Oldřich Jedlička:
> +whiteBrush = CreateSolidBrush(white);
> +ok(whiteBrush != NULL, "CreateBrush returned: %p\n", whiteBrush);
> +redBrush = CreateSolidBrush(red);
> +ok(redBrush != NULL, "CreateBrush returned: %p\n", redBrush);
> +
> +hr = I
34 matches
Mail list logo
