April 2011 - Wine-devel - list.winehq.org

Re: (без темы)
by Dmitry Timoshkov 04 Apr '11

04 Apr '11

Roman Dadkov <romand(a)etersoft.ru> wrote: > 1) Magic field does not contain the correct information when creating a > storage file in Wine. > 2) Some fields are not filled with zeros when creating a storage file > in Wine. But these fields are filled with zeros when creating a storage > file in Windows. How is this different from the previous attempt? Did you address the comments? -- Dmitry.

1 0

Re: [PATCH] user32/tests: Fixed SetParent test on 64bit Vista
by Dmitry Timoshkov 04 Apr '11

04 Apr '11

Austin Lund <austin.lund(a)gmail.com> wrote: > --- a/dlls/user32/tests/msg.c > +++ b/dlls/user32/tests/msg.c > @@ -12681,6 +12681,7 @@ static const struct message WmSetParentSeq_2[] = { > { WM_WINDOWPOSCHANGING, sent|wparam, SWP_HIDEWINDOW|SWP_NOSIZE|SWP_NOMOVE }, > { EVENT_OBJECT_HIDE, winevent_hook|wparam|lparam, 0, 0 }, > { WM_WINDOWPOSCHANGED, sent|wparam, SWP_HIDEWINDOW|SWP_NOSIZE|SWP_NOMOVE|SWP_NOCLIENTSIZE|SWP_NOCLIENTMOVE }, > + { HCBT_SETFOCUS, hook|optional }, > { WM_NCACTIVATE, sent|wparam, 0 }, > { WM_ACTIVATE, sent|wparam, 0 }, > { WM_ACTIVATEAPP, sent|wparam, 0 }, This does look correct. It's pretty strange that other Windows versions don't send HCBT_SETFOCUS notification before WM_KILLFOCUS (which is right after WM_ACTIVATEAPP in the message sequence). -- Dmitry.

2 2

Summer of Code 2011 ideas
by Charles Davis 04 Apr '11

04 Apr '11

Hi, I intend to participate in the Google Summer of Code (again), so I'd like to bounce some ideas off of you guys again. (I don't know why; I'll probably end up doing an extension of last year's project that I did for LLVM. But just in case...) I know that students are supposed to start submitting their proposals tomorrow, but better late than never, I guess. Anyway, here are my ideas (in no particular order): 1. Quartz Driver. I know you guys rejected this last year, but it looks like AJ's been doing some work refactoring the driver interface (at least, the GDI driver interface) lately. I also have some patches to isolate the rest of Wine from winex11. Since the driver itself is so huge, I'll probably end up only doing a piece of it (just enough to run some simple programs like Notepad or Minesweeper). This still depends on my (as yet, unfinished) Deobjectivizer tool so I don't have to code the driver in Objective-C (or resort to Carbon, which Apple seems intent on exorcising from Mac OS X). 2. D3D10 support. Here's an idea that isn't tied to Mac OS X. In Wine, D3D10 support is still in the embryonic stage (i.e. lots of stubs, anything interesting doesn't work quite right). It looks like Henri wants to wait until he finishes exorcising COM from WineD3D to finish implementing D3D10 (probably because COM was too much of a burden for what D3D10 needed from WineD3D, judging from which methods are stubs), so if you want to wait, that's fine. If I do take this on, my goal will probably be to get the game "Civilization V" working (at least, partially) in D3D10 mode, because that's the only D3D10 game I happen to own! (If it already works, and I don't know if it does because I haven't gotten around to installing and testing it, then I'll try to make it work better.) 3. Message-mode pipes. I think we can use the sendmsg(2) and recvmsg(2) syscalls to implement this on top of Unix-domain sockets. Then again, I suspect that this was one of the first things AJ thought of--and he hasn't been able to figure out how to do it yet! I have some experience writing Mac OS X kernel extensions (I wrote the SCSI kexts that Wine on Mac uses), and even a little experience writing Linux modules, so that might help with that. I would like to avoid a kernel module, if possible, though. (It's just one more thing that users have to install to make the system work...) What do you think? Chip

3 4

Re: gdiplus: Simplify logic/control flow in SOFTWARE_GdipFillRegion.
by Vincent Povirk 03 Apr '11

03 Apr '11

I don't think this is an improvement. I think it's easier to use a single variable to indicate failure in the code, and to only use that variable when deciding whether to proceed further. This case only works because the GdipAlloc happens to be the only operation that can fail in that block before GdipGetRegionScansI. I worry that someone (probably me) could modify the code so that is no longer the case and fail to notice that the logic needs to be changed ( to check for stat == Ok && scans, rather than just scans). On Sat, Apr 2, 2011 at 3:36 PM, Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > This doesn't make things tremendously simpler, but does avoid one > unnecessary if / condition. > > If you prefer, I can switch the two arms of the if to retain the > original !scans. > > Gerald > > --- > dlls/gdiplus/graphics.c | 7 +++---- > 1 files changed, 3 insertions(+), 4 deletions(-) > > diff --git a/dlls/gdiplus/graphics.c b/dlls/gdiplus/graphics.c > index 4fdfa9c..49f3495 100644 > --- a/dlls/gdiplus/graphics.c > +++ b/dlls/gdiplus/graphics.c > @@ -3709,16 +3709,15 @@ static GpStatus SOFTWARE_GdipFillRegion(GpGraphics *graphics, GpBrush *brush, > if (stat == Ok && scans_count != 0) > { > scans = GdipAlloc(sizeof(*scans) * scans_count); > - if (!scans) > - stat = OutOfMemory; > - > - if (stat == Ok) > + if (scans) > { > stat = GdipGetRegionScansI(temp_region, scans, &dummy, identity); > > if (stat != Ok) > GdipFree(scans); > } > + else > + stat = OutOfMemory; > } > > GdipDeleteMatrix(identity); > -- > 1.7.4.1 > > >

1 0

Re: scarddlg: New dll stub
by Nikolay Sivov 03 Apr '11

03 Apr '11

On 4/3/2011 17:51, Stefan Leichter wrote: > let the installer from bug #26026 finish > > --- > configure.ac | 1 + > dlls/scarddlg/Makefile.in | 6 ++++ > dlls/scarddlg/main.c | 61 > +++++++++++++++++++++++++++++++++++++++++++ > dlls/scarddlg/scarddlg.spec | 5 +++ > 4 files changed, 73 insertions(+), 0 deletions(-) > create mode 100644 dlls/scarddlg/Makefile.in > create mode 100644 dlls/scarddlg/main.c > create mode 100644 dlls/scarddlg/scarddlg.spec > +/*********************************************************************** > + * FMExtensionProcW (acledit.@) > + * > + */ > + > +LONG WINAPI FMExtensionProcW(HWND hWnd, WORD wEvent, LONG lParam) > +{ > + FIXME("%p, %d, 0x%x) stub\n", hWnd, wEvent, lParam); > + return 0; > + > +} What's that for? It's not used.

1 0

Possible issue in dlls/d3dx9_36/surface.c?
by Gerald Pfeifer 03 Apr '11

03 Apr '11

Matteo et al, there is some code in dlls/d3dx9_36/surface.c which GCC struggles with (in the sense of warning about it), and so do I, so I am wondering whether you can have a look? Specifically, in point_filter_simple_data we have: DWORD val = 0, pixel; /* extract source color components */ if(srcformat->type == FORMAT_ARGB) { pixel = dword_from_bytes(srcptr, srcformat->bytes_per_pixel); get_relevant_argb_components(&conv_info, pixel, channels); } So, pixel is uninitialized, except when we have FORMAT_ARGB. However, directly below we then have /* recombine the components */ if(destformat->type == FORMAT_ARGB) val = make_argb_color(&conv_info, channels); if(colorkey) { get_relevant_argb_components(&ck_conv_info, pixel, channels); where pixel is passed to get_relevant_argb_components. This is guarded by colorkey, a parameter to this function, so indeed I can see pixel being unused here. (I'd naively propose a patch like the one below; this may not be sufficient though.) Gerald diff --git a/dlls/d3dx9_36/surface.c b/dlls/d3dx9_36/surface.c index a3e6e68..cc36818 100644 --- a/dlls/d3dx9_36/surface.c +++ b/dlls/d3dx9_36/surface.c @@ -701,7 +701,7 @@ static void copy_simple_data(CONST BYTE *src, UINT srcpitch, POINT srcsize, DWORD val = 0; for(x = 0;x < minwidth;x++) { - DWORD pixel; + DWORD pixel = 0xFFFFFFFF; /* extract source color components */ if(srcformat->type == FORMAT_ARGB) { @@ -768,7 +768,7 @@ static void point_filter_simple_data(CONST BYTE *src, UINT srcpitch, POINT srcsi for(x = 0;x < destsize.x;x++) { const BYTE *srcptr = bufptr + (x * srcsize.x / destsize.x) * srcformat->bytes_per_pixel; - DWORD val = 0, pixel; + DWORD val = 0, pixel = 0xFFFFFFFF; /* extract source color components */ if(srcformat->type == FORMAT_ARGB) {

2 1

Re: msvcp90: Implement basic_string and cstring versions of basic_string::find.
by Piotr Caban 02 Apr '11

02 Apr '11

Hi, On 04/02/11 08:49, Vincent Pelletier wrote: > +size_t __thiscall MSVCP_basic_string_char_find_cstr( > + basic_string_char *this, const char *str, size_t offset) > +{ > + const char *this_str = basic_string_char_const_ptr(this); > + const char *found = strstr(this_str+offset, str); > + if (found) > + return found - this_str; > + return MSVCP_basic_string_char_npos; > +} It's better to implement basic_string<char>::find(const char *str, size_t offset, size_t count) first and then call it in MSVCP_basic_string_char_find_cstr implementation. basic_string may contain nullbytes, your implementation will not work in this case. cstr may contain nullbytes as well when length is specified. Adding some tests similar to following code may be useful: basic_string<char> test = basic_string<char>("aaa"); test += '\0'; test += "bbb"; basic_string<char> test2 = basic_string<char>(test); test2 += '\0'; printf("%d %s\n", test.length(), test.c_str()); printf("%d\n", test.find("bbb", 0)); printf("%d\n", test.find(test, 0)); printf("%d\n", test.find(test.c_str(), 0, test.length())); printf("%d\n", test.find(test2, 0)); printf("%d\n", test.find(test2.c_str(), 0, test2.length())); Cheers, Piotr

1 0

Why do the wintab32 tests load the dll at runtime?
by Francois Gouget 02 Apr '11

02 Apr '11

The subject says it all. Why do the wintab32 tests load the dll at runtime instead of simply linking with wintab32.dll? Is it to make it easier to compile it with Visual C++ in case the system does not have wintab32.dll? (already the SDKs don't seem to have wintab.h) -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U

2 2

Re: ntdll: Remove more path trailing chars.
by Marvin 02 Apr '11

02 Apr '11

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=10288 Your paranoid android. === WNT4WSSP6 (32 bit file) === file.c:2261: Test failed: FindFirstFile on test-dir// should fail file.c:2262: Test failed: FindFirstFile on test-dir</ should fail file.c:2263: Test failed: FindFirstFile on test-dir>/ should fail file.c:2264: Test failed: FindFirstFile on test-dir"/ should fail file.c:2267: Test failed: FindFirstFile on test-dir\/ should fail file.c:2275: Test failed: FindFirstFile on test-dir/ should fail file.c:2277: Test failed: FindFirstFile on ./test-dir/ should fail

1 0

Re: kernel32: add test for FindFirstFileA with a path ending with "/>"
by Austin English 02 Apr '11

02 Apr '11

On Fri, Apr 1, 2011 at 23:14, Vincent Pelletier <plr.vincent(a)gmail.com> wrote: > Fixes bug 22635. > --- > dlls/kernel32/tests/file.c | 119 > ++++++++++++++++++++++++++++++++++++++++++++ > dlls/ntdll/path.c | 8 +++- > 2 files changed, 126 insertions(+), 1 deletions(-) Your patch changelog is misleading. You're not just adding tests, but fixing the bug. Either send the tests as a single patch and the fix separately(and removing any todo_wine()'s that it fixes) or change the summary to describe the fix. -- -Austin

2 1