On 8/21/2013 10:33, Alistair Leslie-Hughes wrote:
+typedef struct DataSourceImpl
+{
+IDataSourceLocator IDataSourceLocator_iface;
+LONG ref;
+
+} DataSourceImpl;
All good, except this one.
Dmitry Timoshkov writes:
> @@ -748,6 +748,11 @@ err:
> }
> else
> {
> +if (type == FD_TYPE_FILE)
> +{
> +io_status->u.Status = status;
> +io_status->Information = total;
> +}
I don't see why this would have to be specific to files.
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=26789
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=26791
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=26790
Your paranoid android
Piotr Caban writes:
> ---
> dlls/msvcrt/file.c | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
It doesn't work:
../../../tools/runtest -q -P wine -M msvcrt.dll -T ../../.. -p
msvcrt_test.exe.so file.c && touch file.ok
file.c:2042: Test failed: read returned 2, expecte
Stefan Dösinger writes:
> This supersedes patch 98009. It renames the allocation and free
> functions as suggested by Henri.
It doesn't work:
../../../tools/runtest -q -P wine -M d3dx9_36.dll -T ../../.. -p
d3dx9_36_test.exe.so texture.c && touch texture.ok
texture.c:555: Tests skipped: No D3D
Alexandre Julliard wrote:
> > +if (type == FD_TYPE_FILE)
> > +{
> > +io_status->u.Status = status;
> > +io_status->Information = total;
> > +}
>
> I don't see why this would have to be specific to files.
There is a test for pipes which fails if th
Dmitry Timoshkov writes:
> Alexandre Julliard wrote:
>
>> > +if (type == FD_TYPE_FILE)
>> > +{
>> > +io_status->u.Status = status;
>> > +io_status->Information = total;
>> > +}
>>
>> I don't see why this would have to be specific to files.
>
> The
Please ignore this patch, I'll send a better version.
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=26794
Your paranoid android
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-08-21 12:43, schrieb Alexandre Julliard:> 8 0x68e5fba9
wined3d_texture_decref+0x48(texture=)
[/home/julliard/wine/wine/dlls/wined3d/texture.c:449] in wined3d
(0x0032fb28)
This is an existing bug, when running the tests often enough with the
e
+/* Assume the namespace is the Assembly name */
Uh, what?
We should only be passing an assembly name to
get_file_from_strongname, not the class name. You shouldn't even have
access to the class name.
I think what you're actually doing here is skipping the assembly name
and using the
On Aug 20, 2013, at 10:49 PM, Charles Davis wrote:
> In the Windows world, "Unicode" almost universally means "UTF-16". So,
> use the well-known UTF-16 type instead of making up our own.
>
> I have to wonder if there was a good reason Ken didn't use this
> initially.
Please hold this patch while
On Aug 21, 2013, at 10:12 AM, Ken Thomases wrote:
> On Aug 20, 2013, at 10:49 PM, Charles Davis wrote:
>
>> In the Windows world, "Unicode" almost universally means "UTF-16". So,
>> use the well-known UTF-16 type instead of making up our own.
>>
>> I have to wonder if there was a good reason Ken
On Aug 21, 2013, at 10:11 AM, Ken Thomases wrote:
> On Aug 21, 2013, at 10:12 AM, Ken Thomases wrote:
>
>> On Aug 20, 2013, at 10:49 PM, Charles Davis wrote:
>>
>>> In the Windows world, "Unicode" almost universally means "UTF-16". So,
>>> use the well-known UTF-16 type instead of making up our
Looks good for the most part. Some thoughts below...
On Sat, Aug 17, 2013 at 01:25:00PM +0200, Frédéric Delanoy wrote:
> + The implementation can be found in a number of directories:
> +
> +
> +
> +dlls/winmm/, +class="directory">dlls/mmsystem.
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=26809
Your paranoid android
On Aug 21, 2013, at 9:42 PM, Charles Davis wrote:
> @@ -90,6 +93,9 @@ static CFDataRef export_hdrop_to_filenames(HANDLE data);
> static CFDataRef export_oemtext_to_utf8(HANDLE data);
> static CFDataRef export_text_to_utf8(HANDLE data);
> static CFDataRef export_unicodetext_to_utf8(HANDLE data);
>
On Aug 21, 2013, at 10:34 PM, Ken Thomases wrote:
> On Aug 21, 2013, at 9:42 PM, Charles Davis wrote:
>> +static HANDLE import_utf16_to_unicodetext(CFDataRef data)
>> +{
>> +const WCHAR *src;
>> +unsigned long data_len;
>> +unsigned long new_lines = 0;
>> +LPWSTR dst;
>> +unsi
Ahlan Ya Mas3ab!
How can I test it with Hebrew?
Yaron Shahrabani
On Wed, Aug 21, 2013 at 11:19 PM, مصعب الزعبي wrote:
> Written By Aric Stewart , fix about 50 percent of Bug 33794
>
> ---
> dlls/gdi32/font.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>
>
>
21 matches
Mail list logo
