May 2007 - Wine-Devel - list.winehq.org

Re:wine.inf: Create fake dll for iexplore.exe.

by Louis. Lenders

>wine.inf: Create fake dll for >iexplore.exe. >Vitaliy Margolen wine-patches at kievinfo.com >Thu May 24 08:50:10 CDT 2007 >Some older programs check if IE is installed looking for c:\Program >Files\Internet Explorer\iexplore.exe --- tools/wine.inf | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)

May 31, 2007

Re: Bug triage, or spam?

by Ben Hodgetts

Can someone explain to me the point of closing bugs please? If it's resolved one way or another then surely that's enough? Just seems like a waste of effort to be honest. Ben H. Tom Spear wrote: > Hi all, I just have a quick question.. > > I got a message from someone last night asking me to stop closing bugs > because I'm spamming the list, however I also received a message from > someone a couple of nights ago thanking me for doing bug triage.. > Which is it, and if it is both, then what draws the line between > triage and spam, and how do I close stale bugs without it being > considered spam? >

May 31, 2007

Whitespace changes in an indentation patch, is it acceptable?

by Tom Spear

Hi all, just curious, in my work on uninstaller, I am writing my patches to where when indentation is changed, due to adding a for loop, it is done in a separate patch file. I was wondering if it is acceptable to make whitespace changes to other parts of the file in that same patch.. For example, there is: int somevariable; do something; (there are 2 spaces in the blank line). Would it be acceptable to remove those spaces in a patch that changes the following code (which is introduced by the first patch in the series): for blah { do something; for something else { do another thing; } } to: for blah { do something; for something else { do another thing; } } or should I just leave those extra whitespaces in the blank line alone? -- Thanks Tom

May 31, 2007

Re: GDI+: headers and one test

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > Hmm, this is not the same as the PSDK. The PSDK only defines 'enum > Status { ... }' which, in theory, should only allow one to use 'enum > Status' and not 'Status'. Yet the PSDK headers seem to make use of > 'Status'. This might be different in C++ though... > So on the whole it's probably ok to use a typedef. I just prefer to > bring this up so others can chime in. I think it's better without the typedef, in C we can simply use 'enum Status'. -- Alexandre Julliard julliard(a)winehq.org

May 31, 2007

Re: GDI+: headers and one test

by Francois Gouget

On Tue, 29 May 2007, Evan Stade wrote: [...] > include/Gdiplus.h | 10 +++++ > include/GdiplusEnums.h | 39 ++++++++++++++++++ > include/GdiplusFlat.h | 23 ++++++++++ > include/GdiplusGpStubs.h | 10 +++++ > include/GdiplusInit.h | 26 ++++++++++++ > include/GdiplusTypes.h | 7 +++ All filenames in Wine should be lowercase. --- /dev/null +++ b/include/Gdiplus.h [...] + +#ifndef __cplusplus Why check for __cplusplus here? The PSDK contains no such check, at least in this file. --- /dev/null +++ b/include/GdiplusEnums.h [...] +#ifndef _GP_ENUMERATIONS_H_ +#define _GP_ENUMERATIONS_H_ The standard format for Wine headers is __WINE_HEADERNAME_H, unless we need to keep the original macro name for compatibility with the PSDK. But here you're following neither conventions (the other headers would need to be rechecked but they seem to keep the PSDK names). --- /dev/null +++ b/include/GdiplusFlat.h [...] +GpStatus WINGDIPAPI GdipCreateFromHDC(HDC hdc, GpGraphics **graphics); +GpStatus WINGDIPAPI GdipDeleteGraphics(GpGraphics *graphics); Wine headers generally don't keep the parameter names in the headers as they are not needed. --- /dev/null +++ b/include/GdiplusTypes.h [...] +typedef enum { [...] +} Status; Hmm, this is not the same as the PSDK. The PSDK only defines 'enum Status { ... }' which, in theory, should only allow one to use 'enum Status' and not 'Status'. Yet the PSDK headers seem to make use of 'Status'. This might be different in C++ though... So on the whole it's probably ok to use a typedef. I just prefer to bring this up so others can chime in. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ La terre est une bêta...

May 31, 2007

Bug triage, or spam?

by Tom Spear

Hi all, I just have a quick question.. I got a message from someone last night asking me to stop closing bugs because I'm spamming the list, however I also received a message from someone a couple of nights ago thanking me for doing bug triage.. Which is it, and if it is both, then what draws the line between triage and spam, and how do I close stale bugs without it being considered spam? -- Thanks Tom

May 31, 2007

Re: mshtml #2: Added warning if a wrong Wine Gecko package version was found.

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > Yes, that's my plan, but I'm not sure why it's important for this patch. > Currently Wine downloads always the same Gecko version that was never > updated, so this check should work with current Wine. It will change > once we will switch to the new version. I have patches that will use > query encoded in URL to specify the package version and it will use the > same defined version string as version check in this patch, so switching > to the new Gecko won't be much more than one line patch.. It requires > changes both in Wine and redirecting php script. I have patches for both > and this was the first patch in this direction. I only have to test the > rest of patches and send them (hopefully I will find the time to do it > tonight). My concern is that this sort of thing needs to be planned correctly to work in the long run, and it's not clear what the purpose of that version check is. Is there a dependency that would make Wine require a specific version? What happens if you use a new Gecko with an old Wine? Can you make different versions coexist? > We are very far from being able to support other archs, so I thought > it's not worth to care about it ATM. But then there's no sense in adding #ifdefs for it. Putting the architecture in the request wouldn't be much harder, and would avoid hardcoding in the client knowledge about what files are available on the server. -- Alexandre Julliard julliard(a)winehq.org

May 31, 2007

Re: winefile/explorer hardcoded? HKEY_CLASSES_ROOT\Folder\shell\open\command ignored

by Jan Zerebecki

On Mon, Apr 09, 2007 at 05:26:22AM +0200, RusH wrote: > Winefile seems to be hardcoded when it comes to opening folders. No > matter what I do it always pops up. I tried deleting > HKEY_CLASSES_ROOT\Folder and nothing changed. How do you test this? For me using start on directories gives access denied ( e.g. in cwd: start c:\windows ). So I guess what you see is something calling explorer on a directory. It then calls winefile, which is hard-coded. > Should I made a bug report? Yes. Jan

May 31, 2007

Re: (try 2) ws2_32: getsockname should fail for unbound sockets

by Dmitry Timoshkov

"Damjan Jovanovic" <damjan.jov(a)gmail.com> wrote: > + case AF_INET6: > + { > + static const struct sockaddr_in6 emptyAddr; > + const struct sockaddr_in6 *in6 = (struct sockaddr_in6*) uaddr; > + return in6->sin6_port || memcmp(&in6->sin6_addr, &emptyAddr.sin6_addr, sizeof(struct in6_addr)); > + } > + case AF_INET: > + { > + static const struct sockaddr_in emptyAddr; > + const struct sockaddr_in *in = (struct sockaddr_in*) uaddr; > + return in->sin_port || memcmp(&in->sin_addr, &emptyAddr.sin_addr, sizeof(struct in_addr)); > + } You should add 'const' to the casting if the target you create is 'const'. -- Dmitry.

May 31, 2007

Re: headers, two tests

by Dmitry Timoshkov

This time it's just the nit picks, I see no serious problems. "Evan Stade" <estade(a)gmail.com> wrote: > +void WINGDIPAPI GdipFree(void* ptr) > +{ > + if(ptr) > + HeapFree(GetProcessHeap(), 0, ptr); > +} There is no need to check a pointer for NULL before HeapFree call, there is even a janitorial project in Wine to remove such checks. > +static void test_constructor_destructor(void) > +{ > + GpStatus status; > + GpGraphics *pen; > + > + status = GdipCreatePen1((ARGB)0xffff00ff, 10.0f, UnitPixel, &pen); GdipCreatePen1 takes a pointer to GpPen in the last parameter, not GpGraphics. > + expect(Ok, status); > + ok(pen, "Expected pen to be initialized"); If you are testing returned pen pointer for NULL, you need to initialize it to NULL before the call. -- Dmitry.

May 31, 2007