On 09/09/2010 02:46 AM, Thomas Mullaly wrote:
These todo's should have been removed as I implemented each of the
IUriBuilder_{Get/Set}* functions, but, I forgot about them.
Hi Thomas,
todo_wine's that succeed are marked as failures so that means these are
not fixed on (at least) AJ's box as o
On 09/09/2010 07:41 AM, Austin English wrote:
+@ stdcall RmGetList(long ptr ptr ptr)
Hi Austin,
This function has 5 parameters.
--
Cheers,
Paul.
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=5150
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=5149
Your paranoid android.
On 08/09/2010 15:41, Chris Robinson wrote:
Is it safe to call le32 on a float? Especially one that's going to be used
more? If the system is big-endian, the float/integer will need to be in big-
endian to be processed.
The raw data should be in a little-endian format. But you're right that
it
On Wednesday, September 08, 2010 11:02:27 am Owen Rudge wrote:
> +*(BYTE *) dst = (clamp(le32(*(const float *)src), -1, 1)) * 127 +
> 0.5;
Is it safe to call le32 on a float? Especially one that's going to be used
more? If the system is big-endian, the float/integer will need to be in big
On 8 September 2010 20:37, Joris Huizer wrote:
> Hello,
>
> I noticed some copy/paste mistake in this patch;
> A number of functions for *get_lastChild now call node_get_first_child.
>
> HTH,
> Joris
Care to supply a patch?
If you are feeling brave, you may also want to add test cases that
cause
On 8 September 2010 21:04, Eric Pouech wrote:
> does the attached patch help with some of the concerns ?
> I/ it should allow typing in the console (for all GUI programs) and still
> see output get buffer when the programs exits
> II/ reduce the number of cases where the console is in raw mode aft
does the attached patch help with some of the concerns ?
I/ it should allow typing in the console (for all GUI programs) and
still see output get buffer when the programs exits
II/ reduce the number of cases where the console is in raw mode after
wine exits
Not all the cases are supposed to be
Hello,
I noticed some copy/paste mistake in this patch;
A number of functions for *get_lastChild now call node_get_first_child.
HTH,
Joris
Howdy all,
I've added a daily test of wine/winetest compiled using clang (tag
wine_ae-ub1004-clang). I fixed the first bug it found
(http://source.winehq.org/git/wine.git/?a=commitdiff;h=7f30ae6349e01095823e6f84714cc209a20cafae),
but there are a few more failures that look interesting (interesting
Hans Leidekker writes:
> ---
> dlls/msi/package.c | 43 ---
> 1 files changed, 32 insertions(+), 11 deletions(-)
This breaks the tests on 64-bit:
../../../../wine/tools/runtest -q -P wine -M msi.dll -T ../../.. -p
msi_test.exe.so ../../../../wine/dlls
Wolfgang Schwotzer writes:
> Much thanks to Konstantin Kondratyuk. He is the brain behind this bugfix.
>
> --- a/dlls/user32/text.c 2010-06-01 18:14:04.0 +0200
> +++ b/dlls/user32/text.c 2010-06-01 18:15:37.0 +0200
> @@ -954,8 +954,12 @@
>
> if (flags & DT_SINGLE
Aric Stewart writes:
> So return a proper error instead of generating unexpected garbage
> ---
> dlls/usp10/usp10.c |5 -
> 1 files changed, 4 insertions(+), 1 deletions(-)
It fails the tests:
../../../tools/runtest -q -P wine -M usp10.dll -T ../../.. -p usp10_test.exe.so
usp10.c && t
Hans Leidekker writes:
> glibc's resolver supports threads since 2.3.2, released in 2003.
> Fixes http://bugs.winehq.org/show_bug.cgi?id=24180
It seems to me this would affect all platforms. Why fix it only for
Linux?
--
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=5136
Your paranoid android.
The reason for these changes is because of Visual Studio. I tried to
compile wined3d and a bunch of other dlls on Visual Studio (for a part
using Wine headers) and it failed because INTERFACE was not undefined
in some Microsoft headers (I don't remember which one, so it was a bug
there). The Micros
Sorry, Octavian, for sending this only to you.
On 8 September 2010 06:00, Octavian Voicu wrote:
> On Tue, Sep 7, 2010 at 9:42 PM, Lei Zhang wrote:
>>
>> It would be helpful if you provide the content of your debian/
>> directory.
Mainly you want my control and rules files. I'll get these to you
Roderick Colenbrander writes:
> @@ -129,6 +129,7 @@ typedef struct IDirect3DVolumeTexture8
> *LPDIRECT3DVOLUMETEXTURE8, *PDIRECT3DVOLU
>
> /*
> * IDirect3D8 interface
> */
> +#undef INTERFACE
> #define INTERFACE I
Jason Edmeades writes:
> Note1: Tested manually on windows with procmon, windows does indeed do
> the same as this patch, ie a double path/pathext search.
You can't look at the internal behavior of the tool you are
implementing, it needs to be treated as a black box. I'm afraid I can't
accept th
Wolfram Sang writes:
> taking another approach at Bug 19070, I noticed that
> dlls/hhctrl.ocx/hhctrl.c has even more problems with commandline-handling.
> All three invocations of strchr() should better be strchrnul(). (Compare
> calling hh.exe with '-mapid' and '-mapid ' to see one difference).
Hi,
taking another approach at Bug 19070, I noticed that
dlls/hhctrl.ocx/hhctrl.c has even more problems with commandline-handling.
All three invocations of strchr() should better be strchrnul(). (Compare
calling hh.exe with '-mapid' and '-mapid ' to see one difference).
strchrnul ist protected by
You have leaks in your error paths.
On 8 September 2010 02:33, Misha Koshelev wrote:
> +/* Create vertex buffer */
> +hr = IDirect3DDevice9_CreateVertexBuffer(device,
> + numvertices *
> sizeof(D3DXVECTOR3) * 2,
> +
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=5126
Your paranoid android.
On 8 September 2010 11:34, 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.wi
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=5122
Your paranoid android.
On 6 September 2010 21:00, Eric Pouech wrote:
> B/ actually, it's likely a race (in the simple way of running one single
> program) about resetting the console in decent shape. Could the folks having
> the issue try the attached patch (file conclean) to see if it helps ? (I
> never could reproduce
27 matches
Mail list logo
