Re: [PATCH 1/6] kernel32: Fix PROFILE_Load (try 4)

[Christian Inci]

On 07/08/2011 02:06 AM, Ricardo Filipe wrote:
> 2011/7/8 Christian Inci  >
> 
> On 07/08/2011 01:22 AM, Juan Lang wrote:
> > Hi Christian,
> > this isn't quite what Alexandre meant.  *What* did you fix?  Saying
> > you did so isn't enough.
> > Thanks,
> > --Juan
> I'm sorry, I thought you can see it out of the sourcecode.
> 
> PATCH 1: Don't load any variables which aren't in a section.
> PATCH 2: Don't increase seclen or keylen by 1(one) if section name, key
> name is empty. (a empty name seems to be valid too.)
> PATCH 3: Don't return default value if keyname is empty. If keyname is
> NULL return error (ERROR_FILE_NOT_FOUND). Allow empty section name.
> PATCH 4: GetPrivateProfileStringA should set two null bytes.
> PATCH 5: If filename is NULL return error (ERROR_FILE_NOT_FOUND).
> PATCH 6: GetPrivateProfileSectionNamesA should set two null bytes. (try
> 5 of PATCH 6 coming soon.)
> 
> 
> that's what you should write in the patch subjects :)
> dll : fix description

Thank you all for the hints. :)
I'll remember it for the next patches.

Re: [PATCH 1/6] kernel32: Fix PROFILE_Load (try 4)

[Ricardo Filipe]

2011/7/8 Christian Inci 

> On 07/08/2011 01:22 AM, Juan Lang wrote:
> > Hi Christian,
> > this isn't quite what Alexandre meant.  *What* did you fix?  Saying
> > you did so isn't enough.
> > Thanks,
> > --Juan
> I'm sorry, I thought you can see it out of the sourcecode.
>
> PATCH 1: Don't load any variables which aren't in a section.
> PATCH 2: Don't increase seclen or keylen by 1(one) if section name, key
> name is empty. (a empty name seems to be valid too.)
> PATCH 3: Don't return default value if keyname is empty. If keyname is
> NULL return error (ERROR_FILE_NOT_FOUND). Allow empty section name.
> PATCH 4: GetPrivateProfileStringA should set two null bytes.
> PATCH 5: If filename is NULL return error (ERROR_FILE_NOT_FOUND).
> PATCH 6: GetPrivateProfileSectionNamesA should set two null bytes. (try
> 5 of PATCH 6 coming soon.)
>
>
> that's what you should write in the patch subjects :)
dll : fix description

Re: [PATCH 1/6] kernel32: Fix PROFILE_Load (try 4)

[Christian Inci]

On 07/08/2011 01:22 AM, Juan Lang wrote:
> Hi Christian,
> this isn't quite what Alexandre meant.  *What* did you fix?  Saying
> you did so isn't enough.
> Thanks,
> --Juan
I'm sorry, I thought you can see it out of the sourcecode.

PATCH 1: Don't load any variables which aren't in a section.
PATCH 2: Don't increase seclen or keylen by 1(one) if section name, key
name is empty. (a empty name seems to be valid too.)
PATCH 3: Don't return default value if keyname is empty. If keyname is
NULL return error (ERROR_FILE_NOT_FOUND). Allow empty section name.
PATCH 4: GetPrivateProfileStringA should set two null bytes.
PATCH 5: If filename is NULL return error (ERROR_FILE_NOT_FOUND).
PATCH 6: GetPrivateProfileSectionNamesA should set two null bytes. (try
5 of PATCH 6 coming soon.)

Re: [PATCH 1/6] kernel32: Fix PROFILE_Load (try 4)

[Juan Lang]

Hi Christian,
this isn't quite what Alexandre meant.  *What* did you fix?  Saying
you did so isn't enough.
Thanks,
--Juan

Re: Bug #2082

[Stefan Dösinger]

Hi,

Your test app is pretty helpful, I'll reply with more details in the bug 
report. Note however that this is not an easy buy, if it was it would have 
been fixed years ago. I am not convinced that a proper fix is possible at all. 
The apps in question, and your test app, are essentially broken, they just 
used to work by luck on Pre-compositing Windows versions, and we can hack them 
into a working state on X11 too as long as the user doesn't use a compositing 
window manager.

Stefan

On Thursday 07 July 2011 21:43:49 Charles Welton wrote:
> This is one of the longest standing bugs which don't get much love from
> developers. Today I took some time with traces and wrote a test case
> which fails against git: http://bugs.winehq.org/attachment.cgi?id=35469
> 
> What is happening? When there's a child window to the ddraw window over
> it(the ddraw window), wined3d doesn't draw over the child. Windows,
> however, doesn't care about children and draws over them. Note that the
> DC is the same for both(according to traces).
> 
> Not only that, the child window have different positions when in
> fullscreen or virtual desktop.
> 
> As for the fix, I have yet to find the culprit dll(s) for this.
> Unfortunately I don't have the experience with wine's code and would
> like suggestions as to where to begin.


signature.asc
Description: This is a digitally signed message part.

Visual Studio project to compile the d3d code

[Stefan Dösinger]

Hi,

After two people told me they might have use for my Visual Studio setup to 
compile wined3d I finally got around to put it on my git server. You can 
download it with

GIT_SSL_NO_VERIFY=1 git clone https://84.112.174.163/~git/wined3d_vs

What is this good for? My aims were to have Microsoft-Style debug symbols to 
use various Windows development tools. The also aim was to to work without 
Mingw, Msys or any other Unix tool besides git, mostly because mingw+msys is a 
pain.

It performs an out-of-tree build of ddraw, d3d8, d3d9, the tests, wined3d and 
a few dependencies. Just put the files next to the wine sources, the project 
essentially loads the source files from ../wine/*. I also have d3dx9_36.dll in 
the project, but it doesn't link at the moment because d3dcompiler.dll is 
missing and some math functions. The testlist.c files for the tests cannot be 
autogenerated yet.

The main issue is that this project is a stripped-down reimplementation of the 
wine build system. The source files and library exports are hardcoded, so if 
they change the msvc project needs manual adjustments. It would be much nicer 
to use the msvcmaker script for that, but I wasn't aware of this script when I 
started this.

No additional software besides Visual Studio 2010 is needed, except for 
d3dx9_36 which needs the DirectX SDK. I just noticed that the d3d8 tests 
hardcode a path to the SDK sdk too, that is a bug that I can fix. I tried to 
compile the tests and d3d client libs with the MS headers to test our header 
compatibility but ran into some difficulties. The generated binaries also have 
no dependencies except the msvc2010 C runtime(msvcr100.dll)

One word about licensing: I didn't find any obstacles that prevent personal 
use of MSVC Express, but please double-check the EULAs. Redistribution of 
Microsoft code is a problem however. The project setup doesn't deliberately 
include any MS code in the binaries, but it is possible that some functions 
from the C runtime is inlined, so to stay on the safe side I don't 
redistribute any binaries built from Visual Studio.

There are a bunch of warnings left in the code. I fixed the warnings in 
wined3d.dll, d3d8.dll, d3d9.dll and the d3d8 tests, or silenced some warnings 
that I considered too pedantic or hard to fix. ddraw.dll, the ddraw tests and 
d3dx9 and the d3d9 tests have a number of legitimate warnings left.

Stefan


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 1/6] shell32/tests: Add tests for SHQueryRecycleBin

[Marvin]

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=12300

Your paranoid android.


=== WNT4WSSP6 (32 bit recyclebin) ===
No test summary line found

=== W2KPROSP4 (32 bit recyclebin) ===
No test summary line found

=== WXPPROSP3 (32 bit recyclebin) ===
No test summary line found

=== W2K3R2SESP2 (32 bit recyclebin) ===
No test summary line found

=== WVISTAADM (32 bit recyclebin) ===
No test summary line found

=== W2K8SE (32 bit recyclebin) ===
No test summary line found

=== W7PRO (32 bit recyclebin) ===
No test summary line found

Re: [PATCH 2/6] shell32: Implement SHQueryRecycleBin (try 3)

[Marvin]

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=12302

Your paranoid android.


=== WNT4WSSP6 (32 bit recyclebin) ===
No test summary line found

=== W2KPROSP4 (32 bit recyclebin) ===
No test summary line found

=== WXPPROSP3 (32 bit recyclebin) ===
No test summary line found

=== W2K3R2SESP2 (32 bit recyclebin) ===
No test summary line found

=== WVISTAADM (32 bit recyclebin) ===
No test summary line found

=== W2K8SE (32 bit recyclebin) ===
No test summary line found

=== W7PRO (32 bit recyclebin) ===
No test summary line found

Re: [PATCH 2/6] shell32: Implement SHQueryRecycleBin (try 3)

[Marvin]

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=12302

Your paranoid android.


=== WNT4WSSP6 (32 bit recyclebin) ===
No test summary line found

=== W2KPROSP4 (32 bit recyclebin) ===
No test summary line found

=== WXPPROSP3 (32 bit recyclebin) ===
No test summary line found

=== W2K3R2SESP2 (32 bit recyclebin) ===
No test summary line found

=== WVISTAADM (32 bit recyclebin) ===
No test summary line found

=== W2K8SE (32 bit recyclebin) ===
No test summary line found

=== W7PRO (32 bit recyclebin) ===
No test summary line found

Bug #2082

[Charles Welton]

This is one of the longest standing bugs which don't get much love from
developers. Today I took some time with traces and wrote a test case
which fails against git: http://bugs.winehq.org/attachment.cgi?id=35469

What is happening? When there's a child window to the ddraw window over
it(the ddraw window), wined3d doesn't draw over the child. Windows,
however, doesn't care about children and draws over them. Note that the
DC is the same for both(according to traces).

Not only that, the child window have different positions when in
fullscreen or virtual desktop.

As for the fix, I have yet to find the culprit dll(s) for this.
Unfortunately I don't have the experience with wine's code and would
like suggestions as to where to begin.

-- 
Charles Welton

Re: msvcrt/tests: Remove dead assignment (Clang)

[Frédéric Delanoy]

On Thu, Jul 7, 2011 at 18:56, Octavian Voicu  wrote:
> 2011/7/7 Frédéric Delanoy :
>> --- a/dlls/msvcrt/tests/file.c
>> +++ b/dlls/msvcrt/tests/file.c
>> @@ -132,21 +132,21 @@ static void test_fileops( void )
>>         rewind(file);
>>         for (i = 0, c = EOF; i < sizeof(outbuffer); i++)
>
> Isn't c = EOF in for initialization also a dead assignment?

Yes missed that one.
Resent a new version of the patch.

Thanks for your review

Frédéric

Re: msvcrt/tests: Remove dead assignment (Clang)

[Frédéric Delanoy]

On Thu, Jul 7, 2011 at 19:07, Octavian Voicu  wrote:
> 2011/7/7 Frédéric Delanoy :
>>         c = outbuffer[sizeof(outbuffer) - 1];
>>         ok(ungetc(c, file) == c, "ungetc did not return its input for 
>> bufmode=%x\n", bufmodes[bufmode]);
>>         ok(!feof(file), "feof after ungetc returned EOF for bufmode=%x\n", 
>> bufmodes[bufmode]);
>> -        ok((c = fgetc(file)) != EOF, "getc after ungetc returned EOF for 
>> bufmode=%x\n", bufmodes[bufmode]);
>> +        ok(fgetc(file) != EOF, "getc after ungetc returned EOF for 
>> bufmode=%x\n", bufmodes[bufmode]);
>>         ok(c == outbuffer[sizeof(outbuffer) - 1],
>>            "getc did not return ungetc'd data for bufmode=%x\n", 
>> bufmodes[bufmode]);
>
> Also, this change doesn't look like it's removing a dead assignment,
> but it does make the test ok(c == outbuffer[sizeof(outbuffer) - 1],
> ...) always succeed.

Oops right. Thanks for spotting. I'll fix that.

Re: msvcrt/tests: Remove dead assignment (Clang)

[Octavian Voicu]

2011/7/7 Frédéric Delanoy :
>         c = outbuffer[sizeof(outbuffer) - 1];
>         ok(ungetc(c, file) == c, "ungetc did not return its input for 
> bufmode=%x\n", bufmodes[bufmode]);
>         ok(!feof(file), "feof after ungetc returned EOF for bufmode=%x\n", 
> bufmodes[bufmode]);
> -        ok((c = fgetc(file)) != EOF, "getc after ungetc returned EOF for 
> bufmode=%x\n", bufmodes[bufmode]);
> +        ok(fgetc(file) != EOF, "getc after ungetc returned EOF for 
> bufmode=%x\n", bufmodes[bufmode]);
>         ok(c == outbuffer[sizeof(outbuffer) - 1],
>            "getc did not return ungetc'd data for bufmode=%x\n", 
> bufmodes[bufmode]);

Also, this change doesn't look like it's removing a dead assignment,
but it does make the test ok(c == outbuffer[sizeof(outbuffer) - 1],
...) always succeed.

Octavian

Re: msvcrt/tests: Remove dead assignment (Clang)

[Octavian Voicu]

2011/7/7 Frédéric Delanoy :
> --- a/dlls/msvcrt/tests/file.c
> +++ b/dlls/msvcrt/tests/file.c
> @@ -132,21 +132,21 @@ static void test_fileops( void )
>         rewind(file);
>         for (i = 0, c = EOF; i < sizeof(outbuffer); i++)

Isn't c = EOF in for initialization also a dead assignment?

Octavian

Re: [PATCH 2/2] mshtml: Mark some functions as cdecl.

[Jacek Caban]

On 7/7/11 6:19 PM, Juan Lang wrote:

BTW, the current plan is to do the new Gecko release together with Firefox 6
release, which is about 6 weeks from now. The first beta version should be
out in a week or two, depending on how Firefox beta will behave.

Then shouldn't the beta have the calling convention change anyway?  In
this case, it doesn't make sense to me to change Wine for just a few
days.


No, beta will require manual patching of Wine, it's not going to be in 
the main tree.


Jacek

Re: [PATCH 2/2] mshtml: Mark some functions as cdecl.

[Juan Lang]

> BTW, the current plan is to do the new Gecko release together with Firefox 6
> release, which is about 6 weeks from now. The first beta version should be
> out in a week or two, depending on how Firefox beta will behave.

Then shouldn't the beta have the calling convention change anyway?  In
this case, it doesn't make sense to me to change Wine for just a few
days.
--Juan

Re: [PATCH 2/2] mshtml: Mark some functions as cdecl.

[Jacek Caban]

On 7/7/11 6:02 PM, Juan Lang wrote:

Hi Jacek,


These are functions that I missed when revieweing Gecko headers. I will
probably change their calling convention in the next Gecko release.

In that case, why not change the calling convention now?  The matrix
of possible configurations is much simpler that way.

Right now, we have:
current Wine + current gecko = crash

By changing the calling convention in Wine, we have:
Wine<= 1.3.23 + current gecko = crash
Wine 1.3.24-?? + current gecko = no crash
Wine ?? + current gecko = crash
Wine ?? + new gecko = no crash
Wine<= 1.3.23 + new gecko = crash

By doing a new gecko release, we have:
any Wine + current gecko = crash
any Wine + new gecko = no crash



There is 1:1 mapping between Gecko and Wine version. You won't be able 
to use current Wine with the new Gecko nor future Wine with current 
Gecko. And doing Gecko release is quite not that simple to do it for 
such a minor change.


BTW, the current plan is to do the new Gecko release together with 
Firefox 6 release, which is about 6 weeks from now. The first beta 
version should be out in a week or two, depending on how Firefox beta 
will behave.


Jacek

Re: [PATCH 2/2] mshtml: Mark some functions as cdecl.

[Juan Lang]

Hi Jacek,

> These are functions that I missed when revieweing Gecko headers. I will
> probably change their calling convention in the next Gecko release.

In that case, why not change the calling convention now?  The matrix
of possible configurations is much simpler that way.

Right now, we have:
current Wine + current gecko = crash

By changing the calling convention in Wine, we have:
Wine <= 1.3.23 + current gecko = crash
Wine 1.3.24-?? + current gecko = no crash
Wine ?? + current gecko = crash
Wine ?? + new gecko = no crash
Wine <= 1.3.23 + new gecko = crash

By doing a new gecko release, we have:
any Wine + current gecko = crash
any Wine + new gecko = no crash

--Juan

Re: [PATCH 1/2] kernel32: Fixes various 'profile' functions (profile.c). (try 3)

[Alexandre Julliard]

Christian Inci  writes:

> kernel32: Fixes various 'profile' functions.
> Try 2: Formatting change.
> Try 3: Splitted tests/profile.c patch

You can't split it that way. What you need is to split each separate fix
together with its own test fix. Also please use a subject message that
describes what you are fixing, not just "fixes various functions".

-- 
Alexandre Julliard
julli...@winehq.org

Re: oleaut32: Implement ICreateTypeInfo2 SetHelpStringContext

[Nikolay Sivov]

On Thu, Jul 7, 2011 at 2:09 PM, Alistair Leslie-Hughes
 wrote:
> Hi,
>
>
> Changelog:
>    oleaut32: Implement ICreateTypeInfo2 SetHelpStringContext
>

+ICreateTypeInfo2Impl *This = impl_from_ICreateTypeInfo2(iface);
+
+TRACE("(%p,%d), stub!\n", iface, dwHelpStringContext);
It's not a stub anymore.

+
+This->typelib->typelib_header.helpcontext = dwHelpStringContext;

Could you please get rid of this ugly naming here and use something
like 'context' for variable.

+
+return S_OK;
 }

>
> Best Regards
>  Alistair Leslie-Hughes
>
>
>
>