- wine-devel - winehq.org

Translation commits for wine-1.2.3
by Michael Stefaniuc 05 Apr '11

05 Apr '11

Hello Alexandre, attached is the list of translation commits that can be cherry-picked for wine-1.2.3. Notes: - The cherry-picks for cryptui and wineconsole will need a manual conflict resolution as they depend on my janitorial commits. - The Arab and Hebrew translations are filtered out (support for mirroring is only in wine-1.3.x). bye michael

1 0

Re: [PATCH] cmd: Added set /a (try 3, fixed tests and patch formatting) Some tests were written by Jack Kutilek
by Marvin 05 Apr '11

05 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=10353 Your paranoid android. === W7PROX64 (64 bit) === batch.c:70: Test failed: CreateFile failed

1 0

Re: ntdll: Remove more path trailing chars.
by Nikolay Sivov 05 Apr '11

05 Apr '11

On 4/2/2011 10:51, Vincent Pelletier wrote: > Add tests via FindFirstFileA. > Fixes bug 22635. > --- > dlls/kernel32/tests/file.c | 119 ++++++++++++++++++++++++++++++++++++++++++++ > dlls/ntdll/path.c | 8 +++- > 2 files changed, 126 insertions(+), 1 deletions(-) > > diff --git a/dlls/kernel32/tests/file.c b/dlls/kernel32/tests/file.c > index 4e8136a..dae8eee 100644 > --- a/dlls/kernel32/tests/file.c > +++ b/dlls/kernel32/tests/file.c > @@ -2164,6 +2164,125 @@ static void test_FindFirstFileA(void) > err = GetLastError(); > ok ( handle == INVALID_HANDLE_VALUE, "FindFirstFile on %s should Fail\n", buffer2 ); > ok ( err == ERROR_PATH_NOT_FOUND, "Bad Error number %d\n", err ); > + > + /* try FindFirstFileA on "test-dir" with forbidden chars */ > + CreateDirectoryA("test-dir", NULL); > + _lclose(_lcreat("test-file", 0)); > + > +#define FindFirstFileA_ok(value, caption, todo) { \ > + if(todo) { \ > + todo_wine ok(value, caption);\ > + } else { \ > + ok(value, caption);\ > + } \ > + } > + > +#define test_FindFirstFileA_with(x, y, todo) { \ > + handle = FindFirstFileA(x,&data);\ > + if (y) { \ > + FindFirstFileA_ok( \ > + handle != INVALID_HANDLE_VALUE, \ > + "FindFirstFile on "x" should succeed\n", \ > + todo);\ > + } else { \ > + FindFirstFileA_ok( \ > + handle == INVALID_HANDLE_VALUE, \ > + "FindFirstFile on "x" should fail\n", \ > + todo);\ > + } \ > + if (handle != INVALID_HANDLE_VALUE) \ > + ok( FindClose(handle) == TRUE, "Failed to close handle "x"\n"); \ > + } > + > + /* Disallowed chars being ignored: */ > + test_FindFirstFileA_with("test-dir/.", 1, 0); > + test_FindFirstFileA_with("test-dir\\.", 1, 0); > + test_FindFirstFileA_with("test-dir<.", 1, 0); > + test_FindFirstFileA_with("test-dir< ", 1, 0); > + test_FindFirstFileA_with("test-dir>.", 1, 0); > + test_FindFirstFileA_with("test-dir> ", 1, 0); > + test_FindFirstFileA_with("test-dir\".", 1, 0); > + test_FindFirstFileA_with("test-dir\" ", 1, 0); > + test_FindFirstFileA_with("test-dir/>", 1, 0); > + test_FindFirstFileA_with("test-dir/<", 1, 0); > + test_FindFirstFileA_with("test-dir/\"", 1, 0); > + test_FindFirstFileA_with("test-dir<>", 1, 0); > + test_FindFirstFileA_with("test-dir<<", 1, 0); > + test_FindFirstFileA_with("test-dir<\"", 1, 0); > + test_FindFirstFileA_with("test-dir>>", 1, 0); > + test_FindFirstFileA_with("test-dir><", 1, 0); > + test_FindFirstFileA_with("test-dir>\"", 1, 0); > + test_FindFirstFileA_with("test-dir\">", 1, 0); > + test_FindFirstFileA_with("test-dir\"<", 1, 0); > + test_FindFirstFileA_with("test-dir\"\"", 1, 0); > + test_FindFirstFileA_with("test-dir\\<", 1, 0); > + test_FindFirstFileA_with("test-dir\\>", 1, 0); > + test_FindFirstFileA_with("test-dir\\\"", 1, 0); > + /* But space prevents forward& back slashes from being stripped */ > + test_FindFirstFileA_with("test-dir<", 0, 1); > + test_FindFirstFileA_with("test-dir/ ", 0, 0); > + test_FindFirstFileA_with("test-dir/ .", 0, 0); > + test_FindFirstFileA_with("test-dir/. ", 0, 1); > + test_FindFirstFileA_with("test-dir\\ ", 0, 0); > + test_FindFirstFileA_with("test-dir\\ .", 0, 0); > + test_FindFirstFileA_with("test-dir\\. ", 0, 1); > + test_FindFirstFileA_with("test-dir/. ", 0, 1); > + test_FindFirstFileA_with("test-dir\\. ", 0, 1); > + /* But forward& back slashes are not tolerated on a file */ > + test_FindFirstFileA_with("test-file/>", 0, 1); > + test_FindFirstFileA_with("test-file/<", 0, 1); > + test_FindFirstFileA_with("test-file/\"", 0, 1); > + test_FindFirstFileA_with("test-file<>", 1, 0); > + test_FindFirstFileA_with("test-file<<", 1, 0); > + test_FindFirstFileA_with("test-file<\"", 1, 0); > + test_FindFirstFileA_with("test-file>>", 1, 0); > + test_FindFirstFileA_with("test-file><", 1, 0); > + test_FindFirstFileA_with("test-file>\"", 1, 0); > + test_FindFirstFileA_with("test-file\">", 1, 0); > + test_FindFirstFileA_with("test-file\"<", 1, 0); > + test_FindFirstFileA_with("test-file\"\"", 1, 0); > + test_FindFirstFileA_with("test-file\\<", 0, 1); > + test_FindFirstFileA_with("test-file\\>", 0, 1); > + test_FindFirstFileA_with("test-file\\\"", 0, 1); > + /* Even when many */ > + test_FindFirstFileA_with("test-dir\"\"\"\"\"", 1, 0); > + test_FindFirstFileA_with("test-dir<<<><><>\"\"\"\"<<<>", 1, 0); > + /* But only in the end of path */ > + test_FindFirstFileA_with("test-/>dir", 0, 0); > + test_FindFirstFileA_with("/>test-dir", 0, 0); > + test_FindFirstFileA_with(">test-dir", 0, 0); > + test_FindFirstFileA_with(">>test-dir", 0, 0); > + test_FindFirstFileA_with(">test->dir", 0, 0); > + test_FindFirstFileA_with("><test->dir", 0, 0); > + test_FindFirstFileA_with("<test->dir", 0, 0); > + test_FindFirstFileA_with("<\"test->dir", 0, 0); > + > + /* Slash after ignored chars is not ignored: */ > + test_FindFirstFileA_with("test-dir//", 0, 0); > + test_FindFirstFileA_with("test-dir</", 0, 0); > + test_FindFirstFileA_with("test-dir>/", 0, 0); > + test_FindFirstFileA_with("test-dir\"/", 0, 0); > + test_FindFirstFileA_with("test-dir\\", 0, 0); > + test_FindFirstFileA_with("test-dir\\\\", 0, 0); > + test_FindFirstFileA_with("test-dir\\/", 0, 0); > + test_FindFirstFileA_with("test-dir/\\", 0, 0); > + > + /* Disalowed chars being preserved: */ > + test_FindFirstFileA_with("test-dir/:", 0, 0); > + test_FindFirstFileA_with("test-dir/|", 0, 0); > + > + /* Slashes converted to backslashes */ > + test_FindFirstFileA_with("test-dir/", 0, 0); > + test_FindFirstFileA_with("./test-dir", 1, 0); > + test_FindFirstFileA_with("./test-dir/", 0, 0); > + test_FindFirstFileA_with("test-dir\\", 0, 0); > + test_FindFirstFileA_with(".\\test-dir", 1, 0); > + test_FindFirstFileA_with(".\\test-dir\\", 0, 0); > + > +#undef test_FindFirstFileA_with > +#undef FindFirstFileA_ok > + DeleteFileA("test-file"); > + RemoveDirectoryA("test-dir"); > } Please use table for test data and put your macro body in a loop.

3 3

Re: cmd: Added set /a (try 2)
by Marvin 05 Apr '11

05 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=10349 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Sorry about the duplicate patches.
by Joel Teichroeb 05 Apr '11

05 Apr '11

When trying to submit my first patch I did not do it correctly, and on http://source.winehq.org/patches/ it shows up 5 times. The correct patch is http://www.winehq.org/pipermail/wine-patches/2011-April/100677.html Thanks for your patience. Joel Teichroeb

1 0

Re: gdi32/tests: Start of a framework for writing dib driver tests.
by Huw Davies 05 Apr '11

05 Apr '11

On Tue, Apr 05, 2011 at 03:31:23PM +0100, Huw Davies wrote: > > Try2. Using the A_SHA functions to generate the hashes. Although somewhat neater than the first version it doesn't work on nt4/win2k as they don't export these functions. So we're better off using the original. Huw.

1 0

Re: gdi32/tests: Start of a framework for writing dib driver tests.
by Marvin 05 Apr '11

05 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=10338 Your paranoid android. === WNT4WSSP6 (32 bit dib) === Timeout === W2KPROSP4 (32 bit dib) === Timeout

1 0

Re: mshtml: Properly handle upload streams containing headers
by Alexandre Julliard 05 Apr '11

05 Apr '11

Jacek Caban <jacek(a)codeweavers.com> writes: > + if(nschannel->post_data_contains_headers) { > + if(data[0] == '\r' && data[1] == '\n') { > + post_data = data+2; > + data_len -= 2; > + }else { > + WCHAR *headers; > + DWORD size; > + > + post_data = memmem(data, data_len, "\r\n\r\n", 4); memmem is not portable. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] cmd: Added set /a
by Marvin 05 Apr '11

05 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=10334 Your paranoid android. === WNT4WSSP6 (32 bit) === batch.c:223: Test failed: unexpected char 0x34 position 0 in line 118 (got '4', wanted '3') batch.c:223: Test failed: unexpected char 0x34 position 0 in line 120 (got '4', wanted '11') batch.c:223: Test failed: unexpected char 0x30 position 0 in line 24 (got '0', wanted '2') batch.c:223: Test failed: unexpected char 0x31 position 0 in line 30 (got '12', wanted '2') batch.c:223: Test failed: unexpected char 0x2d position 0 in line 42 (got '-2147483648', wanted '0') batch.c:223: Test failed: unexpected char 0x33 position 0 in line 46 (got '3', wanted '1') batch.c:223: Test failed: unexpected char 0x35 position 0 in line 124 (got '5', wanted '6') batch.c:223: Test failed: unexpected char 0x35 position 0 in line 130 (got '5', wanted '2') batch.c:223: Test failed: unexpected char 0x35 position 0 in line 140 (got '5', wanted '1') batch.c:223: Test failed: unexpected char 0x35 position 0 in line 146 (got '5', wanted '10')

1 0

Re: msi: Fix parsing of an empty property followed by a non-empty property.
by Marvin 05 Apr '11

05 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=10333 Your paranoid android. === WNT4WSSP6 (32 bit install) === install.c:5979: Test failed: Per-user icon file isn't where it's expected (C:\WINNT\Profiles\Default User\Application Data\Microsoft\Installer\{7DF88A49-996F-4EC8-A022-BF956F9B2CBB}\testicon)

1 0

Re: Fixes a crypt32 str test. (try 2)
by Juan Lang 04 Apr '11

04 Apr '11

Hi Christian, I'd like to see the actual test, preferably incorporated into the test suite. Thanks, --Juan

1 0

Re: [GSoC] Merge winecfg and Control Panel
by Dan Kegel 04 Apr '11

04 Apr '11

Winetricks is a simple script that adds a few mssing things to wine, e.g. it's how most people install ms dlls or .net on wine. It also provides a simple commandline way to change a few settings. For instance, winetricks vd=1024x768 sets a 1024x768 virtual desktop... it'd be nice if one could instead do winecfg vd=1024x768 or something like that. See also http://winetricks.org. On Mar 23, 2011 10:36 AM, "Tony Zhang" <niu.tony.c.zhang(a)gmail.com> wrote: Dear Dan, I agree that it would be nice to have a command-line interface for wine settings cause I have run into situations that I have to configure wine before going into X. So is it possible to first group/rearrange winecfg functions into certain libraries and then let the GUI (control panel) and the CLI all interact with the corresponding libraries? About winetricks, I do not know much about it. What exactly do you mean by "winetricks settings"? -- Tony (Chi Zhang) On Wed, Mar 23, 2011 at 9:15 AM, Dan Kegel <dank(a)kegel.com> wrote: > > Also... it would be nice i...

4 4

Re: po: Update US English resource
by Alexandre Julliard 04 Apr '11

04 Apr '11

Ken Sharp <kennybobs(a)o2.co.uk> writes: > Just ise/ize changes > From 60f207abd03edf7ffac6f129a8bffd537596d54e Mon Sep 17 00:00:00 2001 > From: Ken Sharp <kennybobs(a)o2.co.uk> > Date: Fri, 1 Apr 2011 23:07:03 +0100 > Subject: po: Update US English resource These need to be changed in the original rc files. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [2/2] user32: DefDlgProc on WM_QUIT should repost it and terminate the dialog message loop.
by Marvin 04 Apr '11

04 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=10328 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

1 0

Re: [1/2] user32: Add a test for WM_QUIT handling by DefDlgProc.
by Marvin 04 Apr '11

04 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=10327 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

1 0

Re: [PATCH 2/2] comdlg32: Add support for customizing control labels in the item dialog.
by Nikolay Sivov 04 Apr '11

04 Apr '11

On 4/4/2011 13:01, David Hedberg wrote: > static HRESULT WINAPI IFileDialog2_fnSetOkButtonLabel(IFileDialog2 *iface, LPCWSTR pszText) > { > FileDialogImpl *This = impl_from_IFileDialog2(iface); > - FIXME("stub - %p (%p)\n", This, pszText); > - return E_NOTIMPL; > + TRACE("%p (%p)\n", This, pszText); > + If you trace text parameter pointer value itself is not very interesting. Why not dumping a string?

1 0

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

Re: kernel32: add test for FindFirstFileA with a path ending with "/>"
by Marvin 01 Apr '11

01 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=10286 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: msvcp90: Implement basic_string and cstring versions of basic_string::find.
by Marvin 01 Apr '11

01 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=10285 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

RFC: Standardising the Help menus
by Francois Gouget 01 Apr '11

01 Apr '11

I am in the process of reviewing Wine's resource files and more specifically the menus of its applications, and even more specifically the Help menu for now. Currently they are a bit inconsistent and I propose to standardise them by following the GNOME interface guidelines. That is use the following structure: Help Contents F1 About So here is the data I gathered on this eminently critical issue ;-) Windows User Experience Interaction Guidelines ---------------------------------------------- * The section about standard menus say we should use: http://msdn.microsoft.com/en-us/library/aa511502.aspx Help <program name> help F1 <separator> About <program name> * All applications seem to conform to the specification for the 'About' menu (except Sound Recorder which uses 'About' and Disk Management which incorrectly adds an ellipsis). * But for the 'Help' menu there is a lot of inconsistency. In Windows 7 I got: 'View Help': Notepad, Solitaire, Mine Sweeper, Calculator, FreeCell, Internet Backgammon, Spider Solitaire '<program name> Help': Internet Explorer 8 '<program name> Help Topics': Task Manager 'Help Topics': Regedit, Task Scheduler, Disk Management 'Help': Sound Recorder 'Contents': msinfo32 'None' (replaced by a toolbar icon): Explorer, Paint, XPS Viewer, Windows Media Player, Backup and Restore, Sync Center * From the point above I conclude that following the Microsoft Guidelines will not particularly help consistency with other Windows applications, nor help meet the users expectations. * Putting the program name in the menu name means we will have as many strings to translate as there are programs. This is more work for translators and can yield inconsistencies from one program to the next. * Putting the program name in the menu name also feels redundant to me. Does one really expect Regedit to give you the help for Notepad? Similarly one would expect an 'About' menu to be about the current program, although in Wine's case it's more a generic About dialog. Unix Interface Guidelines ------------------------- * The GNOME Human Interface Guidelines specify: http://library.gnome.org/devel/hig-book/2.32/hig-book.html#menu-standard-he… Help Contents F1 About * This allows sharing of the translations across programs. * It would make Wine's applications consistent with the system ones... as long as one uses Gnome. * Because unfortunately this is a case where the KDE User Interface Guidelines differ: http://developer.kde.org/documentation/standards/kde/style/menus/help.html Help <program name> Handbook... F1 What's This? Shift+F1 <separator> About <program name>... About KDE... * Using ellipses as specified for these menus makes absolutely no sense and is inconsistent with their own guidelines regarding them. Fortunately this seems to be a bug in the specification and the applications don't uses ellipses (feel free to report this bug). * Both GNOME and KDE applications follow their guidelines pretty well. (except Gnome's Network Tools app which uses 'Help Ctrl+H' instead of 'Contents F1', maybe another bug to report) * However other applications, specifically FireFox and OpenOffice seem to follow the Windows guidelines. VMware Workstation follows them for the About menu, but follows GNOME's guidelines for the 'Contents' help menu. * So given that we cannot be consistent with all Unix applications I propose to pick the scheme that requires the less work for us, which is GNOME's scheme. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Stolen from an Internet user: "f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng !"

3 2

Re: [3/3] wined3d: Get rid of context_validate.
by Alexandre Julliard 01 Apr '11

01 Apr '11

Matteo Bruni <matteo.mystral(a)gmail.com> writes: > It should not be needed anymore, now the wined3d context is implicitly > validated on GL context activation. The check itself wasn't reliable > because of some threading issues and it also brought a small performance hit. It crashes here (nvidia driver 256.53): ../../../tools/runtest -q -P wine -M d3d8.dll -T ../../.. -p d3d8_test.exe.so visual.c && touch visual.ok visual.c:949: Tests skipped: D3DFMT_P8 textures not supported wine: Unhandled page fault on read access to 0x00000004 at address 0x564def4d (thread 0044), starting debugger... Unhandled exception: page fault on read access to 0x00000004 in 32-bit code (0x564def4d). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:564def4d ESP:0032f110 EBP:7e27f248 EFLAGS:00010246( R- -- I Z- -P- ) EAX:00000000 EBX:682e96c0 ECX:00000000 EDX:00000000 ESI:56d8f000 EDI:00000000 Stack dump: 0x0032f110: 56d8f000 00000000 00000004 02000007 0x0032f120: 556be000 02000007 7df05fa0 5572fc1e 0x0032f130: 7e27f270 556be000 56d8f000 02000007 0x0032f140: 00000000 00000014 00000000 7e0db298 0x0032f150: 02000007 02000007 7df05fa0 56d8f000 0x0032f160: 7e27f270 7e0db1a0 7e27f248 5572fdbf Backtrace: =>0 0x564def4d in libnvidia-glcore.so.256.53 (+0xd38f4d) (0x7e27f248) 1 0x00000000 (0x7e106410) 0x564def4d: testl $0xe000000,0x4(%edi) -- Alexandre Julliard julliard(a)winehq.org

1 0

About Wine/Gecko/MSHTML
by Artem S. Tashkinov 01 Apr '11

01 Apr '11

Hi, I have no idea to what extent and how Mozilla's Gecko library is being used in Wine (all I know is that it's used in Wine's MSHTML component), but recently a Mozilla developer made a very unsettling announcement: groups dot google dot com/d/topic/mozilla.dev.embedding/c_NMcO-N8wo/discussion I wonder if this announcement has any adverse effects on Wine's future. Best wishes, Artem

2 1

Re: [PATCH] user32/tests: Fixed SetParent test on 64bit Vista
by Marvin 01 Apr '11

01 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=10257 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

1 0

Re: [PATCH] kernel32: Populate HKLM\HARDWARE\DEVICEMAP\Scsi on Mac OS.
by Alexandre Julliard 31 Mar '11

31 Mar '11

Charles Davis <cdavis(a)mymail.mines.edu> writes: > From: Charles Davis <cdavis(a)mines.edu> > > --- > dlls/kernel32/Makefile.in | 2 +- > dlls/kernel32/oldconfig.c | 157 +++++++++++++++++++++++++++++++++++++++++++- > 2 files changed, 154 insertions(+), 5 deletions(-) This code needs to be moved to the mountmgr first. -- Alexandre Julliard julliard(a)winehq.org

2 4

Re: [3/3] Changing the day of month BEFORE calculating the day of week this time. (try 3)
by Vincent Povirk 31 Mar '11

31 Mar '11

And now I screwed up the title. But I'm sure git-am will fix that. On Thu, Mar 31, 2011 at 3:58 PM, Vincent Povirk <madewokherd(a)gmail.com> wrote: > EVERY TIME I have to do anything different I forget to attach the patch. >

1 0

Re: d3dx9_36 [patch 2/2]: Add tests for D3DXCreateBox
by Matteo Bruni 31 Mar '11

31 Mar '11

2011/3/31 David Adam <david.adam.cnrs(a)gmail.com>: > > + /* Check the width */ > + v1 = *((D3DXVECTOR3*)(data+19*num_bytes_per_vertex)); > + v2 = *((D3DXVECTOR3*)(data+18*num_bytes_per_vertex)); > + length = D3DXVec3Length(D3DXVec3Subtract(&v2,&v1,&v2)); > + ok(fabs(length-10.0f)<admitted_error, "Width expected= 10.0, received %f\n", length); This is not really different from the previous version: you are still making assumptions about the vertex ordering (in this specific case, you're assuming that vertices 18 and 19 have different X coordinate but the same Y and Z coordinate values). What I was proposing was something like this: for (i = 0; i < num_vertices; i++) { float *vertex_data = data + i * num_bytes_per_vertex; if (vertex_data[0] < xmin) xmin = vertex_data[0]; if (vertex_data[0] > xmax) xmax = vertex_data[0]; if (vertex_data[1] < ymin) ymin = vertex_data[1]; if (vertex_data[1] > ymax) ymax = vertex_data[1]; if (vertex_data[2] < zmin) zmin = vertex_data[2]; if (vertex_data[2] > zmax) zmax = vertex_data[2]; } and then proceed to check whether the minimum and maximum values you got match the expected ones. This code snippet can certainly be improved, it is only to show you what I meant. Also, again, please try to fix the whitespaces...

2 3

Re: msvcrt: Fix locale creation for multibyte encoding
by Alexandre Julliard 31 Mar '11

31 Mar '11

Piotr Caban <piotr(a)codeweavers.com> writes: > @@ -787,13 +787,15 @@ MSVCRT__locale_t MSVCRT__create_locale(int category, const char *locale) > loc->locinfo->lc_category[MSVCRT_LC_CTYPE].locale = _strdup("C"); > } > > - for(i=0; i<256; i++) > - buf[i] = i; > - > - LCMapStringA(lcid[MSVCRT_LC_CTYPE], LCMAP_LOWERCASE, buf, 256, > - (char*)loc->locinfo->pclmap, 256); > - LCMapStringA(lcid[MSVCRT_LC_CTYPE], LCMAP_UPPERCASE, buf, 256, > - (char*)loc->locinfo->pcumap, 256); > + for(i=0; i<256; i++) { > + buf[0] = i; > + if(!LCMapStringA(lcid[MSVCRT_LC_CTYPE], LCMAP_LOWERCASE, buf, 1, > + (char*)loc->locinfo->pclmap+i, 1)) > + loc->locinfo->pclmap[i] = ' '; > + if(!LCMapStringA(lcid[MSVCRT_LC_CTYPE], LCMAP_UPPERCASE, buf, 1, > + (char*)loc->locinfo->pcumap+i, 1)) > + loc->locinfo->pcumap[i] = ' '; > + } It would probably be better to replace the DBCS lead chars in the input buffer first and then still do the whole mapping in one step. -- Alexandre Julliard julliard(a)winehq.org

1 0

State of AMD 3d drivers?
by Dan Kegel 31 Mar '11

31 Mar '11

How good are AMD's 3d drivers these days? A few years ago, the word was, if you wanted to run the wine test suite, you'd better have an nvidia graphics chip. Is that still true?

2 1

Re: [1/2] winefile: Remove unimplemented menu entries.
by James McKenzie 30 Mar '11

30 Mar '11

On Wed, Mar 30, 2011 at 7:46 AM, Francois Gouget <fgouget(a)free.fr> wrote: > They unnecessarily clutter the GUI and are unlikely to ever be implemented. > --- > > As discussed on wine-devel. > I still left Rename and Create Directory because they are basic > functions that should really be there (but I won't implement them). Thank you Francois. These should only be brought back with a full implementation of the underlying code, if it is really needed. James McKenzie

1 0

Re: semi-obsolete audio drivers
by Andrew Eikum 30 Mar '11

30 Mar '11

On 03/30/2011 09:23 AM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Andrew, > > [good news, esp. the time-line] Let's hope I can stick to it :-P. It's looking good, though. >>OSSv4 (complete) > Do you specifically use OSS *v4* functions not available earlier? > (I'm not familiar with OSS4, even though I consult their docu online > and hope that what they write also applies to my machine with OSS v3 (Ubuntu)). I wrote it following the OSSv4 spec and using an OSSv4 implementation, so I suspect it won't work on OSSv3. I thought about supporting OSSv3, but I think it's not worth the effort -- that's a really old version that, when written, didn't support multiple clients simultaneously, had no mixer, etc. OSSv4 has a lot of features that make the driver much simpler. Further, I think only Linux is still stuck on OSSv3. I looked at a number of other operating systems, mostly BSDs and Solaris, and they all use OSSv4 by default. So I think Linux users should be covered by ALSA or PulseAudio (or perhaps JACK), and the much-more-pleasant OSSv4 is available for BSDs and Solaris. If a Linux user really wants OSS, I think they should probably upgrade to OSSv4 anyway. I could look at making it OSSv3 compatible, but I just think it's not worth the effort of supporting such an old and cantankerous API. Andrew

1 0

semi-obsolete audio drivers
by Joerg-Cyril.Hoehle＠t-systems.com 30 Mar '11

30 Mar '11

Hi, you may have noticed that I've always sent patches for the 3 audio drivers that I consider current and mostly up to date: + winealsa + wineoss + winecoreaudio and never for one of the other ones which I consider obsolete. - winejack - wineesd - winenas Sometimes I've been wondering whether I should include and take care of winejack too, although I've neither the jack development package nor do I know or use any software that uses Jack. As for the others, I really consider them obsolete and never look at them. This is not entirely satisfactory, as I've been blaming (in thoughts) the one or other developer who in the past fixed a bug in one of the drivers without fixing the same bug in the other ones... Code continues to diverge... What do you think? - Why did people submit patches to one driver only when a short glance shows that the same bug is in the other cloned drivers too? - Is WineJack "current" and worth some effort? - Let the others continue to decay? - Remove them from git? Please don't shout for maintenance by others too early: how much time do *you* invest in making Wine better? Regards, Jörg Höhle

2 1

Re: [PATCH 1/6] winmm: Check callback flags prior to opening a driver.
by Marvin 30 Mar '11

30 Mar '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=10217 Your paranoid android. === WXPPROSP3 (32 bit mixer) === mixer.c:1050: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR mixer.c:1061: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR === W2K3R2SESP2 (32 bit mixer) === mixer.c:1050: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR mixer.c:1061: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR === WVISTAADM (32 bit mixer) === mixer.c:1050: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR mixer.c:1061: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR === W2K8SE (32 bit mixer) === mixer.c:1050: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR mixer.c:1061: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR === W7PRO (32 bit mixer) === mixer.c:1050: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR mixer.c:1061: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR === W7PROX64 (32 bit mixer) === mixer.c:1050: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR mixer.c:1061: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR === W7PROX64 (64 bit mixer) === mixer.c:1050: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR mixer.c:1061: Test failed: mixerOpen: MMSYSERR_INVALFLAG expected, got MMSYSERR_NOERROR

1 0

Re: [06/10] msi: Accept whitespace-only property values on the command line.
by Marvin 30 Mar '11

30 Mar '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=10214 Your paranoid android. === WNT4WSSP6 (32 bit install) === install.c:5979: Test failed: Per-user icon file isn't where it's expected (C:\WINNT\Profiles\Default User\Application Data\Microsoft\Installer\{7DF88A49-996F-4EC8-A022-BF956F9B2CBB}\testicon)

1 0

Re: [02/10] msi/tests: Get rid of workarounds for win9x test failures.
by Marvin 30 Mar '11

30 Mar '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=10212 Your paranoid android. === WNT4WSSP6 (32 bit install) === install.c:5979: Test failed: Per-user icon file isn't where it's expected (C:\WINNT\Profiles\Default User\Application Data\Microsoft\Installer\{7DF88A49-996F-4EC8-A022-BF956F9B2CBB}\testicon)

1 0

Fwd: Re: [PATCH 2/5] d3dx9_36: Implemented ID3DXConstantTable_SetIntArray and ID3DXConstantTable_SetInt (Try 5)
by Rico Schüller 30 Mar '11

30 Mar '11

Forwarding to the list. Am 28.03.2011 20:47, schrieb David Laight: >> Ints and floats are represented differently and so, if we want to put >> an integer array into floating point registers, we need to have casts. >> If you were to simply call SetFloatArray, you would get nonsense >> values in the floating point registers. > Even using casts will fall foul of the C aliasing rules - which > mean that the compiler can assume that a read of type will not be > modified by a write to a different type so can be reorderd (unless > one of the types is 'char'). > > Not only that, but there are systems that will fault is an invalid > FP bit pattern is loaded into an FP register. > > David > My example wasn't very well chosen. So conversation (casts) between the different types is necessary. It was meant the way to reuse some of the code. Because I think ID3DXConstantTable_SetIntArray and ID3DXConstantTable_SetFloatArray could share a lot of code. This will probably be the same for ID3DXConstantTable_SetBoolArray. Cheers Rico

1 0

Re: [01/10] msi: Ignore invalid upgrade codes in the PublishProduct action.
by Marvin 30 Mar '11

30 Mar '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=10211 Your paranoid android. === WNT4WSSP6 (32 bit install) === install.c:6052: Test failed: Per-user icon file isn't where it's expected (C:\WINNT\Profiles\Default User\Application Data\Microsoft\Installer\{7DF88A49-996F-4EC8-A022-BF956F9B2CBB}\testicon)

1 0

Fwd: [PATCH 2/5] d3dx9_36: Implemented ID3DXConstantTable_SetIntArray and ID3DXConstantTable_SetInt (Try 5)
by Travis Athougies 30 Mar '11

30 Mar '11

>> Ints and floats are represented differently and so, if we want to put >> an integer array into floating point registers, we need to have casts. >> If you were to simply call SetFloatArray, you would get nonsense >> values in the floating point registers. > > Even using casts will fall foul of the C aliasing rules - which > mean that the compiler can assume that a read of type will not be > modified by a write to a different type so can be reorderd (unless > one of the types is 'char'). > Exactly. Which is why I am not ever casting int pointers to float pointers as Rico suggested. Instead I'm looping through the array and casting each int to a float, which should invoke the machinery necessary to convert from the bit representation of an int to that of a float. > Not only that, but there are systems that will fault is an invalid > FP bit pattern is loaded into an FP register. > If I'm casting ints to floats (and not int pointers to float pointers) I don't see how this could be an issue. Travis -- Travis Athougies

1 0

[RFC] dinput: Length can actually be 0.
by Vincent Pelletier 30 Mar '11

30 Mar '11

(Sorry for sending to wine-patches initially, it was intended for wnie-devel.) This fixes force feedback devices slamming for 10ms at full strength, as attack is an absolute value, not a factor of effect level. Daniel Remenak told me that 0-length envelopes (attack and/or fade, not sure which combination) cause the effect to be not played (possibly played with 0- level) on devices using the Linux iforce driver. This is the reason of the comment in the code. But to other drivers, such as hid-ff, this code causes the device to jump as full strength, which was reported (to me directly) for example when playing "Live for Speed"[1] with a steering wheel having strong force feedback (Logitech G27). My question: Is it acceptable to risk some regression for iforce driver (until bug is identified) to fix other devices ? I guess iforce devices also suffer from the too-strong attack/fade effect. [1] http://www.lfs.net (demo available, I didn't try it) --- dlls/dinput/effect_linuxinput.c | 11 +++++------ 1 files changed, 5 insertions(+), 6 deletions(-) diff --git a/dlls/dinput/effect_linuxinput.c b/dlls/dinput/effect_linuxinput.c index fbc5994..0154f49 100644 --- a/dlls/dinput/effect_linuxinput.c +++ b/dlls/dinput/effect_linuxinput.c @@ -606,13 +606,12 @@ static HRESULT WINAPI LinuxInputEffectImpl_SetParameters( else env = NULL; if (peff->lpEnvelope == NULL) { - /* if this type had an envelope, reset it - * note that length can never be zero, so we set it to something minuscule */ + /* if this type had an envelope, reset it */ if (env) { - env->attack_length = 0x10; - env->attack_level = 0x7FFF; - env->fade_length = 0x10; - env->fade_level = 0x7FFF; + env->attack_length = 0; + env->attack_level = 0; + env->fade_length = 0; + env->fade_level = 0; } } else { /* did we get passed an envelope for a type that doesn't even have one? */ -- 1.7.4.1

2 1

today's git failed to build for me
by Susan Cragin 30 Mar '11

30 Mar '11

I just downloaded today's git and tried to build it. The following are the make errors in the terminal output. Below that, separated by a line, are the installation errors. make[1]: Entering directory `/home/susan/wine/dlls/winejack.drv' gcc -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o audio.o audio.c audio.c: In function ‘JACK_DriverProc’: audio.c:2419:50: error: ‘RTLD_NOW’ undeclared (first use in this function) audio.c:2419:50: note: each undeclared identifier is reported only once for each function it appears in audio.c:2443:5: warning: implicit declaration of function ‘MessageBoxA’ audio.c:2443:78: error: ‘MB_OK’ undeclared (first use in this function) make[1]: *** [audio.o] Error 1 make[1]: Leaving directory `/home/susan/wine/dlls/winejack.drv' make: *** [dlls/winejack.drv] Error 2 ------------------------------------------ make[1]: Entering directory `/home/susan/wine/dlls/winejack.drv' gcc -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o audio.o audio.c audio.c: In function ‘JACK_DriverProc’: audio.c:2419:50: error: ‘RTLD_NOW’ undeclared (first use in this function) audio.c:2419:50: note: each undeclared identifier is reported only once for each function it appears in audio.c:2443:5: warning: implicit declaration of function ‘MessageBoxA’ audio.c:2443:78: error: ‘MB_OK’ undeclared (first use in this function) make[1]: *** [audio.o] Error 1 make[1]: Leaving directory `/home/susan/wine/dlls/winejack.drv' make: *** [install] Error 2

3 2

Re: [PATCH 6/6] d3dx9: Use init function for ID3DXBuffer.
by David Adam 29 Mar '11

29 Mar '11

You mix S_OK with D3D_OK. Though they are equivalent, I think it would be better to keep the only D3D_OK notation. A+ David 2011/3/29 Rico Schüller <kgbricola(a)web.de> > --- > dlls/d3dx9_36/core.c | 36 +++++++++++++++++++++++++++--------- > 1 files changed, 27 insertions(+), 9 deletions(-) > > > > > >

1 0

Re: [2/3] winex11.drv: Don't modify current state if glXMakeCurrent fails.
by Roderick Colenbrander 29 Mar '11

29 Mar '11

I'm not sure if the only value error wglMakeCurrent should return is INVALID_HANDLE. What if glXMakeCurrent fails because of an invalid context? The return value may be similar, but don't remember for sure. Roderick On Tue, Mar 29, 2011 at 7:42 AM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > > > > >

2 2

Re: [3/3] winex11.drv: Make wglMakeCurrent return the correct error when the drawable is invalid.
by Roderick Colenbrander 29 Mar '11

29 Mar '11

The fact that a pixel format is not set on the physDev doesn't necessarily mean it is invalid, it just means SetPixelFormat wasn't called on it. Though slightly earlier in wglMakeCurrent we already catch that situation when compare the pixel format of the context and the hdc. Is there not something better for which we could check? Is the drawable of the physDev perhaps something to check for? (I have no idea in what state the physDev is after a destroy window; should we be able to enter x11drv at all? perhaps this should be handled inside the gdi32 code, just a thought) Roderick On Tue, Mar 29, 2011 at 7:42 AM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > > > > >

2 2

Re: wldap32: Accept a NULL value in ldap_set_option.
by Marvin 29 Mar '11

29 Mar '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=10187 Your paranoid android. === WNT4WSSP6 (32 bit parse) === parse.c:120: Test failed: ldap_set_optionW failed 0x00000059 === W2KPROSP4 (32 bit parse) === parse.c:120: Test failed: ldap_set_optionW failed 0x00000059

1 0

Re: mshtml: Fixed node leak in HTMLEventObj
by Alexandre Julliard 29 Mar '11

29 Mar '11

Jacek Caban <jacek(a)codeweavers.com> writes: > --- > dlls/mshtml/htmlevent.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) This causes the mshtml:events test to hang for me. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 3/4] comdlg32: Add implementation of DllRegisterServer/DllUnregisterServer. (resend)
by Alexandre Julliard 29 Mar '11

29 Mar '11

David Hedberg <david.hedberg(a)gmail.com> writes: > @@ -274,3 +277,82 @@ HRESULT WINAPI DllGetClassObject(REFCLSID rclsid, REFIID riid, void **ppv) > > return CLASS_E_CLASSNOTAVAILABLE; > } > + > +/*********************************************************************** > + * Register/Unregister DLL, based on shdocvw/factory.c > + */ You should use the new IRegistrar mechanism instead. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: RFC: Remove unimplemented application menus?
by James McKenzie 29 Mar '11

29 Mar '11

On 3/28/11 9:28 AM, André Hentschel wrote: > Am 28.03.2011 17:27, schrieb James McKenzie: >> 2011/3/27 André Hentschel<nerv(a)dawncrow.de>: >>> Am 27.03.2011 13:50, schrieb Francois Gouget: >>>> Some Wine programs, winefile in particular, have a lot of unimplemented >>>> menus. That is you can see the menu entry but clicking on it only gives >>>> you a 'Not yet implemented' error dialog (or does nothing in the case >>>> of iexplore). For instance just for the first two winefile menus none >>>> of the following are implemented: >>>> >>>> File -> Print... >>>> File -> Associate... >>>> File -> Search... >>>> File -> Select Files... >>>> Disk -> Share as... >>>> Disk -> Remove Share... >>>> Disk -> Select Drive... >>>> >>>> >>>> I think such a situation is bad: >>>> * Having tons of unimplemented menus looks amateurish. >>>> * It's very confusing. You see tons of menus except over 50% of them >>>> don't work. So it makes the GUI more complex with no benefit. >>>> * I suspect most of these menus have been unimplemented for years >>>> so there is little hope of seeing them improve any time soon. >>>> * For a number of them it's questionable whether it makes sense to >>>> implement them in Wine at all as they correspond to tasks that >>>> better belong to the native system facilities (Share as for >>>> instance). >>>> * I doubt they serve any significant compatibility purpose. >>>> * In the mean time they generate more work for translators and >>>> translation reviewers. >>>> * It generates more work for anyone checking whether the GUI is >>>> consistent / follows human interface guidelines (wrt. ellipses for >>>> instance). >>>> >>>> So I propose to simply remove unimplemented menus. When / if someone >>>> ever decides to implement some of the corresponding functionality, >>>> adding the corresponding code and GUI bits back should not be too hard. >>>> >>>> Objections? >>>> >>> Good Idea, at least for the year old stub menus (like winefile). >>> For recently added, with hope to see them implemented in the next time (maybe gsoc), we should wait some month (e.g. iexplore) IMO. >>> >> I agree. This was proposed as a GOSC project by one of the people. >> There is a thread on Wine Users about these menus being >> 'unimplemented' and how they should be. Would this be a good item for >> a bug report for an Request for Enhancement? > IMHO no, there is no point i think. > PS: is this meant to be also sent to wine-devel? > > Are these features the program should possess or not? These tend to be 'standard' menu items for most Windows programs and the underlying code does lie in Windows, not the individual programs and has since the Windows 3.x days. Sorry, but I hit the reply button and not reply to all when I responded to you. My apologies. James McKenzie

2 6

[GSoC] Message mode pipes proposal
by Bryan Donlan 28 Mar '11

28 Mar '11

Hi, all, >From the GSoC project ideas page, I became interested in the proposal for implementing message-based pipes (see bug: http://bugs.winehq.org/show_bug.cgi?id=17195). The most recent patches to the bug cited above appear to use a separate socketpair for each message sent down the pipe, and must make potentially multiple wineserver calls for each interaction with the pipe. This will clearly begin to have problems once a large number of file descriptors are in the air. While a discussion on #winehackers suggested that implementing message-based pipes efficiently and safely entirely in userspace would be quite difficult, I feel that implementing a _correct_ implementation (regardless of efficiency) would be a practical goal. After creating a correct implementation, work could then be done to improve performance. First, a bit about me: I am a computer science student at the University of Massachusetts, heading into my senior year. I have had a lot of experience with Linux development, somewhat less on the Windows side. I am fluent in English and Japanese, although I doubt Japanese language experience would be helpful for this project :) In previous summer internships I have developed code for interprocess communication; in one instance, I wrote a ring buffer synchronization protocol to transfer data from a Windows user-space program to a real-time process running in kernel-mode (hosted via a third-party Windows real-time HAL). I propose the following overall plan: * First, I will prepare a comprehensive test suite for message-based pipes. Benchmarks would also be prepared to help determine whether optimization is necessary. This will likely borrow from the tests already posted to the bug I linked above. * I will write a wineserver-internal implementation of message-based pipes. That is, all NtReadFile/NtWriteFile() requests would be completely redirected to wineserver; there would be no attempt to expose a file descriptor for the client process to access directly. Wineserver in turn would simply manage a simple, in-memory queue of messages. Although this is unscalable and has a lot of context switch and copying overhead, it is simple, and would allow programs making light usage of message-based pipes to work. It also provides a clear place to hook on a new, faster protocol that requires a custom NtReadFile/NtWriteFile. After this point, I will begin work on optimizing the implementation. Some ideas on how to do this might include: * Implement the pipe using a ring buffer in shared memory. Client processes can then directly access the pipe buffer to pass data without wineserver's involvement. This has the downside that a user-mode process can inadvertently corrupt the pipe's state; this may be acceptable if the effects can be limited to a trashed pipe buffer, instead of crashing unrelated processes. * Implement the pipe using a ring buffer in shared memory, but expose only a read-only file descriptor to client processes. This avoids the corruption issues, but writes must be managed by the server and will incur overhead. * Implement the pipe as a single server-managed socketpair over which shared memory backing files are passed with SCM_RIGHTS, plus a lock (possibly implemented in shared memory using futexes, or by flock on a /dev/shm file). Clients acquire the lock, then MSG_PEEK the socketpair to retrieve an anonymous (unlinked immediately after creation) shared memory file descriptor. The shared memory buffer holds a count of remaining bytes, plus the actual message data. Clients then perform a normal recvmsg() to dequeue the message if they successfully retrieved the entire message. This approach is complex, and it is unclear what the performance impacts of having so many files being thrown around would be. However, it does avoid the context-switch costs and wineserver load that are a problem in the implementations currently on the bug tracker. * Implement a Linux kernel module to implement message-based pipe semantics natively. Although quite efficient, this will only apply to Linux, and may introduce difficulty keeping up with Linux kernel changes in the future. It is also unclear whether distributions and/or upstream Linux maintainers will welcome this approach. I will likely end up trying out several of these approaches and comparing actual performance results. Finally, if time allows, I will also investigate integration with samba, in order to support connecting to named pipes on remote servers. I would appreciate any comments on this proposal prior to actual submission. Thanks, Bryan Donlan

1 0

Re: [PATCH 4/6] mshtml/tests: Added IDocObjectService interface
by Marvin 28 Mar '11

28 Mar '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=10180 Your paranoid android. === WXPPROSP3 (32 bit htmldoc) === TestLauncher.c:89: Test failed: Can't open test executable C:\winetest\mshtml_test.exe, error 32

1 0

Re: wininet: Port numbers are unsigned (more)
by Dan McDonald 28 Mar '11

28 Mar '11

On 03/28/2011 01:40 PM, André Hentschel wrote: > - static const WCHAR percentD[] = {'%','d',0}; > + static const WCHAR percentD[] = {'%','u',0}; Variable name change may be in order here. Dan

2 1

Re: [PATCH 2/5] d3dx9_36: Implemented ID3DXConstantTable_SetIntArray and ID3DXConstantTable_SetInt (Try 5)
by Rico Schüller 28 Mar '11

28 Mar '11

Hi, this and the previous patch (1/5) are doing the same thing? Is there a reason why they could not use the same code base? e.g. ID3DXConstantTable_SetIntArray(iface, device, constant, n, count) { return ID3DXConstantTable_SetFloatArray(iface, device, constant, n, count); } Also I'd prefer if there would be TRACEs in each function. It might be useful to add the RegisterSet in the FIXME for the default case, to see which one is missing in the special case. Cheers Rico Am 27.03.2011 22:22, schrieb Travis Athougies: > --- > dlls/d3dx9_36/shader.c | 37 ++++++++++++++++++++++++++++++------- > 1 files changed, 30 insertions(+), 7 deletions(-) > > diff --git a/dlls/d3dx9_36/shader.c b/dlls/d3dx9_36/shader.c > index 4a3caab..874d916 100644 > --- a/dlls/d3dx9_36/shader.c > +++ b/dlls/d3dx9_36/shader.c > @@ -847,11 +847,7 @@ static HRESULT WINAPI ID3DXConstantTableImpl_SetBoolArray(ID3DXConstantTable* if > > static HRESULT WINAPI ID3DXConstantTableImpl_SetInt(ID3DXConstantTable* iface, LPDIRECT3DDEVICE9 device, D3DXHANDLE constant, INT n) > { > - ID3DXConstantTableImpl *This = impl_from_ID3DXConstantTable(iface); > - > - FIXME("(%p)->(%p, %p, %d): stub\n", This, device, constant, n); > - > - return E_NOTIMPL; > + return ID3DXConstantTable_SetIntArray(iface, device, constant,&n, 1); > } > > static HRESULT WINAPI ID3DXConstantTableImpl_SetIntArray(ID3DXConstantTable* iface, LPDIRECT3DDEVICE9 device, > @@ -859,9 +855,36 @@ static HRESULT WINAPI ID3DXConstantTableImpl_SetIntArray(ID3DXConstantTable* ifa > { > ID3DXConstantTableImpl *This = impl_from_ID3DXConstantTable(iface); > > - FIXME("(%p)->(%p, %p, %p, %d): stub\n", This, device, constant, n, count); > + D3DXCONSTANT_DESC desc; > + HRESULT hr; > + UINT i, desc_count = 1; > + float row[4] = {0.0f, 0.0f, 0.0f, 0.0f}; > + > + hr = ID3DXConstantTable_GetConstantDesc(iface, constant,&desc,&desc_count); > + if (FAILED(hr)) > + { > + TRACE("ID3DXConstantTable_GetConstantDesc failed: %08x", hr); > + return D3DERR_INVALIDCALL; > + } > > - return E_NOTIMPL; > + switch (desc.RegisterSet) > + { > + case D3DXRS_FLOAT4: > + for (i = 0; i< count&& i< desc.RegisterCount; i++) > + { > + row[0] = n[i]; > + if (is_vertex_shader(This->desc.Version)) > + IDirect3DDevice9_SetVertexShaderConstantF(device, desc.RegisterIndex + i, row, 1); > + else > + IDirect3DDevice9_SetPixelShaderConstantF(device, desc.RegisterIndex + i, row, 1); > + } > + break; > + default: > + FIXME("Can't handle RegisterSets other than D3DXRS_FlOAT4\n"); > + return E_NOTIMPL; > + } > + > + return D3D_OK; > } > > static HRESULT WINAPI ID3DXConstantTableImpl_SetFloat(ID3DXConstantTable* iface, LPDIRECT3DDEVICE9 device,

3 2

Re: [4/4] d3d9: Test depth stencil size mismatches
by Henri Verbeet 28 Mar '11

28 Mar '11

This fails for me on native (Windows 7, Radeon HD 6950): visual.c:11813: Test failed: DS size test: Pixel (2, 2) after clear is 0xff0000, expected 0x000000FF visual.c:11815: Test failed: DS size test: Pixel (31, 31) after clear is 0xff0000, expected 0x000000FF visual.c:11817: Test failed: DS size test: Pixel (32, 32) after clear is 0xff0000, expected 0x000000FF visual.c:11819: Test failed: DS size test: Pixel (63, 63) after clear is 0xff0000, expected 0x000000FF visual.c:11825: Test failed: IDirect3DDevice9_ValidateDevice returned 0, expected D3DERR_CONFLICTINGRENDERSTATE. visual.c:11832: Test failed: IDirect3DDevice9_ValidateDevice returned 0, expected D3DERR_CONFLICTINGRENDERSTATE.

2 1

Re: [1/7] urlmon: Removed str_last_of in favor of strnrchrW
by Alexandre Julliard 28 Mar '11

28 Mar '11

Thomas Mullaly <thomas.mullaly(a)gmail.com> writes: > --- > dlls/urlmon/uri.c | 27 ++++++--------------------- > dlls/urlmon/urlmon_main.h | 14 ++++++++++++++ > 2 files changed, 20 insertions(+), 21 deletions(-) > From 7528b6b58256cba3ef53937e0ff7dbc3593f684a Mon Sep 17 00:00:00 2001 > From: Thomas Mullaly <tmullaly(a)codeweavers.com> > Date: Sun, 20 Mar 2011 16:28:59 -0400 > Subject: urlmon: Removed str_last_of in favor of strnrchrW It's called memrchrW. -- Alexandre Julliard julliard(a)winehq.org

1 0

winmm & concurrency
by Joerg-Cyril.Hoehle＠t-systems.com 28 Mar '11

28 Mar '11

Hi, I've had a hard time finding information about what kind of guarantees MS makes for concurrency in the winmm function set. The best I've found so far is a 2005 blog entry written by Larry Osterman. Concurrency, part way too many2 - Concurrency and the Win32 API set http://blogs.msdn.com/b/larryosterman/archive/2005/03.aspx "I implicated the concurrency issues when I mentioned that all DLLs need to be multi-thread safe [...]" "The Windows MME APIs (waveOutXxx, waveInXxx, mixerXxx, etc) also protect their internal data structures. But they also support callback functions [...]" That's short. If you find anything else, please tell me. The irritating thing about Wine bug #9026 (waveOutReset during waveOutClose) and bug #22978 (MCI_CLOSE) is that they involve no concurrency from the app's POV. In both cases, the app issues a sequence of PlaySound resp. mciSendCommand from a single thread. Concurrency appears as Wine internally makes use of player threads. Regards, Jörg Höhle

1 0

Re: [PATCH2/2] winmm: PlaySound concurrency cleanup.
by Eric Pouech 28 Mar '11

28 Mar '11

sharing a global variable between threads without proper sync protection or atomic operation is the wrong thing to do moreover you're doing several unrelated changes in the same patch, please split up A+ 2011/3/28 <Joerg-Cyril.Hoehle(a)t-systems.com> > Hi, > > - PlaySound_Alloc does not call _Free anymore, so it does not use WINMM_cs > anymore, which makes it easier to reason about use of critical sections. > - psStopEvent was never used like an event rather than a boolean. > - No need to muck with WHDR_DONE. > - No need to keep the unused thread handle object around. > - Abort the playloop in case of error, like I did for mciwave. The error > may not be transient. > > - Free waveHdr and hEvent after closing hWave. Either you believe that > WAVERR_STILLPLAYING can happen, then obviously waveHdr is in use and must > not yet be freed, or you believe checking for STILLPLAYING is a waste of > code because waveOutReset must have done its job. > > I should have added an ERR() message. > > One should think again about what to do in such a case. Why/when would > sleep help? User-friendlier might be not to wait, not to free WaveHdr > and accept to leak resources in such a case. > > Actually, waveOutClose can fail with STILLPLAYING because waveOutReset > can fail. If you look at winealsa, you'll see it uses CreateEvent to > synchronously wait for acknowledge of the message. Now guess what > happens if CreateEvent fails because memory is tight? > What happens in the app when waveOutClose's CreateEvent fails? > It's always tough to reason about the many error paths. > > Regards, > Jörg Höhle > > > > -- -- Eric Pouech

2 1

w9x/ME users, please test (mciGet/SetYieldProc)
by Joerg-Cyril.Hoehle＠t-systems.com 28 Mar '11

28 Mar '11

Hi, Testbot job #10124 contains a test that works perfectly on machines since w2k, but much to my surprise, mciGetYieldProc returns NULL,0 on testbot's win9x machines. If you have a w9x or a WinME machine, I'd appreciate if you could run the test too. Download & invoke winmm_test.exe midi http://testbot.winehq.org/GetFile.pl?JobKey=10124&StepKey=2 test & patch code: http://testbot.winehq.org/GetFile.pl?JobKey=10124&StepKey=1 If you happen to know why mciGet/SetYieldProc yield NULL/FALSE, please let me hear. NULL looks like an error status than a valid "old value is truly NULL" result. mciSetYieldProc returns FALSE as an error indicator, whereas I'd expect mciSetYieldProc(id,NULL,<any>) to be a valid call. Testbot's w9x machines return: mci.c:639: Test failed: original yieldproc 00000000 mci.c:640: Test failed: Break key is vkey 0 mci.c:643: Test failed: mciSetYieldProc NULL mci.c:648: Test failed: Break key changed to vkey 0 mci.c:664: Test failed: Break key changed to vkey 0 mci.c:674: Test failed: mciSetYieldProc restore Thank you, Jörg Höhle

1 0

Wine compatibility
by Adam Kłobukowski 28 Mar '11

28 Mar '11

Hello I have a question for Wine developers, not 100% related to development, so: please excuse me for wasting your time. Officially sated, Wine wants to be 'bug-by-bug' implementation of Windows APIs. On the other hand, it is known that all (?) version of Windows contain 'hacks' to make important and not well behaving applications work (mostly workarounds for application bugs). This 'hacks' work by detecting that a faulty app is running, and turning special 'hack' mode for such app. Because of this, black box testing often used by Wine developers will not detect such workarounds, and applications that (seem to) work perfectly well under Windows, will not work under Wine. Is there a solution for this? What is Wine devs position on this matter? Side question: Windows could make a 'clean start' with 64 bit environment, did they? Thank you for your time. Adam Klobukowski

5 6

Re: d3dx9_36: Implement D3DXCreateBox
by Joris Huizer 28 Mar '11

28 Mar '11

Hello, In this patch, one part seemed strange to me: You are declaring vertices as static memory: + static FLOAT vertices[144] But you are changing the values during the function: + + for(i = 0; i< 24; i++) + { + vertices[6 * i ] *= width; + vertices[6 * i + 1] *= height; + vertices[6 * i + 2] *= depth; + } + Given that original values are never restored, I think you can not mark the array as static, otherwise incorrect values are used after the first call. The other arrays are not adapted, so they are fine as static memory (And you may in fact mark those static const) HTH, Joris

4 5

RFC: Remove unimplemented application menus?
by Francois Gouget 27 Mar '11

27 Mar '11

Some Wine programs, winefile in particular, have a lot of unimplemented menus. That is you can see the menu entry but clicking on it only gives you a 'Not yet implemented' error dialog (or does nothing in the case of iexplore). For instance just for the first two winefile menus none of the following are implemented: File -> Print... File -> Associate... File -> Search... File -> Select Files... Disk -> Share as... Disk -> Remove Share... Disk -> Select Drive... I think such a situation is bad: * Having tons of unimplemented menus looks amateurish. * It's very confusing. You see tons of menus except over 50% of them don't work. So it makes the GUI more complex with no benefit. * I suspect most of these menus have been unimplemented for years so there is little hope of seeing them improve any time soon. * For a number of them it's questionable whether it makes sense to implement them in Wine at all as they correspond to tasks that better belong to the native system facilities (Share as for instance). * I doubt they serve any significant compatibility purpose. * In the mean time they generate more work for translators and translation reviewers. * It generates more work for anyone checking whether the GUI is consistent / follows human interface guidelines (wrt. ellipses for instance). So I propose to simply remove unimplemented menus. When / if someone ever decides to implement some of the corresponding functionality, adding the corresponding code and GUI bits back should not be too hard. Objections? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ In a world without fences who needs Gates?

2 1

RFC: wined3d: Check for and use FBO blits early in BltOverride
by Chris Robinson 27 Mar '11

27 Mar '11

IDirect3DDevice9::StretchRect is used to stretch-blit between video memory surfaces. It's implemented by calling IWineD3DSurfaceImpl_Blt, which itself will attempt IWineD3DSurfaceImpl_BltOverride to accelerate it. However, BltOverride will not accelerate the blit if neither surface is a swapchain or active render target 0, and will fall back to a sysmem->sysmem blit with possible conversions. This seems to happen in between every post-processing (screen-space shader) pass with Oblivion Graphics Extender and Morrowind Graphics Extender, which causes a severe loss in performance. After some testing and talking with Henri, it seems a number of checks aren't needed if FBO blits are available, particularly the swapchain/active render target checks. The attached patch makes BltOverride check for FBO blits earlier, which helps it catch more cases where blits can be accelerated. It provides a significant improvement with the aforementioned programs. I'm not sure of the full consequences of this move, however, particularly with earlier DX versions. Hence a request for comments.

3 3

Re: [1/4] wined3d/context: Track the number of render targets in FBO entries.
by Henri Verbeet 27 Mar '11

27 Mar '11

On 21 March 2011 21:56, Adam Martinson <amartinson(a)codeweavers.com> wrote: > > Cuts CPU time in context_apply_fbo_state() in half. This is meaningless. Which applications, and how much time of the total is spent in context_apply_fbo_state()? How does this translate into concrete thing like frame time? More importantly, why does this change come before the one for tracking FBO dirty state? Avoiding redundant FBO entry comparisons completely is likely to have a much more significant effect than making the comparisons themselves slightly cheaper in very specific applications.

2 4

Re: d3dx10: Float16To32Array and Float32To16Array (GSoC)
by Stefan Dösinger 27 Mar '11

27 Mar '11

On Sunday 20 March 2011 22:29:34 Joshua Beck wrote: > I erred on the side of caution because I didn't want to spend all summer > working on a project that I couldn't finish. Finding the right amount of work is certainly tricky. Luckily d3dx9 has many functions, so if you find out that you have plenty of time left you can include extra work in your project later on. You don't have to get the set of work perfect at the start - reevaluating the amount of work needed and adjusting the goals during the project is part of gsoc. However, finding a most likely doable, but not overly simple set of work does improve the application. We'll provide feedback on this(as I just did, I hope others who know the library better will jump in if I am telling you incorrect things) > However I do have other > ideas that I would also like to implement. For instance, I would be > willing to implement the D3DXSave[Surface/Texture]ToFile* functions for > all file formats currently supported by WINE. Wrt this specific function we already have some related infrastructure for D3DXLoadSurfaceFrom* . Also other parts of Wine(gdi32.dll, windowscodecs.dll) have functions for handling various on-disk file formats which can(and should) be used. (That's just some generic implementation hint, it doesn't mean that it makes the idea good or bad)

2 2

Re: [GSoC] Merge winecfg and Control Panel
by wine.dev＠web.de 27 Mar '11

27 Mar '11

Dear Tony Welcome to Wine. > > After all the searches, I still do not have an overall idea of how to > create an control panel applet. From my current understanding, if I put the > cpl (dll) file in "~/.wine/drive_c/windows/system32/", wine control will > recognize it automatically, right? When you add a new cpl, the wine build system does this for you. > If so, is there any instructions on how to build a simple applet under wine > (even one that does nothing could work for me). I'd really like to try > create and build some test applet in order to understand it better. As always: Read the source. What you try to do (test applet) is how i started with inetcpl.cpl a while ago. git has a web interface with a history and the first commit for inetcpl.cpl is a minimalistic control applet. ( http://source.winehq.org/git/wine.git/history/HEAD:/dlls/inetcpl.cpl ) -- by by ... Detlef

3 2

Re: wined3d: check for ARB_fragment_program in arbfp_blit_supported
by Stefan Dösinger 26 Mar '11

26 Mar '11

> <0001-wined3d-check-for-ARB_fragment_program-in-arbfp_blit.patch> Considering this statement in select_blit_implementation, directx.c: if ((ps_selected_mode == SHADER_ARB || ps_selected_mode == SHADER_GLSL) && gl_info->supported[ARB_FRAGMENT_PROGRAM]) return &arbfp_blit; else return &ffp_blit; How does wined3d end up using arbfp_blit?

2 2

Re: [2/2] comctl32/listview: Fix edit box text limit
by Marvin 26 Mar '11

26 Mar '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=10152 Your paranoid android. === WNT4WSSP6 (32 bit listview) === listview.c:397: Test failed: buffer size 264 listview.c:397: Test failed: buffer size 264 listview.c:397: Test failed: buffer size 264 listview.c:397: Test failed: buffer size 264 listview.c:397: Test failed: buffer size 264 listview.c:397: Test failed: buffer size 264 listview.c:397: Test failed: buffer size 264 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259

1 0

Re: [1/2] comctl32/listview: Adjust dispinfo text buffer length
by Marvin 26 Mar '11

26 Mar '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=10151 Your paranoid android. === WNT4WSSP6 (32 bit listview) === listview.c:397: Test failed: buffer size 264 listview.c:397: Test failed: buffer size 264 listview.c:397: Test failed: buffer size 264 listview.c:397: Test failed: buffer size 264 listview.c:397: Test failed: buffer size 264 listview.c:397: Test failed: buffer size 264 listview.c:397: Test failed: buffer size 264 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259 listview.c:353: Test failed: text limit 260, expected 259

1 0

GSoC: Implement the Explorer
by Jay Yang 26 Mar '11

26 Mar '11

Hello, Since my first proposal got no response at all, I thought I'd offer another possible project I'm interested in. I looked a little into the "Implement the Explorer" project idea listed on the Summer of Code page on the wine wiki. I have a few questions as to what parts need to be implemented. Clearly, as stated by the description on the Summer of Code page, we have winefile, which does some of the things expected of explorer, but how far is winefile from a correct explorer implementation? Also would implementing Shell Extensions be a good Summer of Code project? In particular, I think it would be nice to have things like TortiseSVN working in wine. Thanks -- Jay Yang

3 4

Re: ole32/tests: Test for correct storage creation.
by Dmitry Timoshkov 26 Mar '11

26 Mar '11

Roman Dadkov <romand(a)etersoft.ru> wrote: > + IStorage_Commit(stg, STGC_DEFAULT); > + IStorage_Release(stg); > + GetHGlobalFromILockBytes(ilb, &hMem); It would be helpful to test the results of the above calls too. > + todo_wine > + ok(!memcmp((BYTE*)hMem, StandardMagic, 8), "Incorrect storage creation\n"); > + todo_wine > + ok(!memcmp(((BYTE*)hMem+8), NullableField, 16), "Incorrect storage creation. Field is not reset\n"); > + todo_wine > + ok(!memcmp(((BYTE*)hMem+34), NullableField, 10), "Incorrect storage creation. Field is not reset\n"); What is this supposed to show? -- Dmitry.

2 1

Re: Ubuntu's next release and raising hard ulimit on ubuntu
by Dan Kegel 26 Mar '11

26 Mar '11

Nope, this isn't about the select() limit. The soft limit on file handles should stay at 1024 so apps that use select() don't break. Apps like wine that have already switched away from select should be able to raise their soft limit if they want more file desciptors. Wine already does this. But ubuntu is misconfigured by default with a hard limit identical to the soft limit. It's time for ubuntu to fix this by raising the default hard limit on file desciptors in /etc/security/limits.conf. Users who need this can edit that file to make their games work, but they shouldn't have to. (Topposted from my cellphone) On Mar 25, 2011 8:03 AM, "Paul Chitescu" <paulc(a)voip.null.ro> wrote: On Friday 25 March 2011 03:26:25 pm Dan Kegel wrote: > Scott, correct me if I'm wrong, but does Natt... This is not an Ubuntu limitation but rather of the (g)libc API implementation. At least on glibc it is possible to increase the FD_SETSIZE at build time. Been there, done that, got the T-shirt. No need for header patching. http://yate.null.ro/websvn/filedetails.php?repname=yate&path=%2Ftrunk%2Feng… Caveat: FD_... operations take longer if FD_SETSIZE is increased. On all relevant platforms it is possible to check if a fd is above the limit. The application code must do so. Best is to internally replace select() with poll() on platforms that support it.

1 1

Ubuntu's next release and raising hard ulimit on ubuntu
by Dan Kegel 26 Mar '11

26 Mar '11

Scott, correct me if I'm wrong, but does Natty still have the hard limit of 1024 files open per process? If so, should be ask people to go vote for https://bugs.launchpad.net/ubuntu/+source/linux/+bug/663090 ? Getting that limit raised might avoid increasing numbers of support requests from users who can't figure out why Wine can't run their p2p downloader ( http://bugs.winehq.org/show_bug.cgi?id=25015 ).

3 2

Re: urlmon: Use unescaped Urls for FTP actions (try 3)
by Nikolay Sivov 25 Mar '11

25 Mar '11

On 3/26/2011 01:22, André Hentschel wrote: > Jacek gave me some advice and we made sure we have no other option to unescape the url. > --- > dlls/urlmon/ftp.c | 6 ++++++ > 1 files changed, 6 insertions(+), 0 deletions(-) > > diff --git a/dlls/urlmon/ftp.c b/dlls/urlmon/ftp.c > index c9d43b8..5857818 100644 > --- a/dlls/urlmon/ftp.c > +++ b/dlls/urlmon/ftp.c > @@ -60,12 +60,18 @@ static HRESULT FtpProtocol_open_request(Protocol *prot, IUri *uri, DWORD request > { > FtpProtocol *This = impl_from_Protocol(prot); > BSTR url; > + DWORD len; > HRESULT hres; > > hres = IUri_GetAbsoluteUri(uri,&url); > if(FAILED(hres)) > return hres; > > + len = strlenW(url); No need to slow down with strlenW, it's a BSTR. > + hres = UrlUnescapeW((LPWSTR)url, NULL,&len, URL_UNESCAPE_INPLACE); > + if(FAILED(hres)) > + return hres; > + Leak! And why a cast by the way?

1 0

[GSoC] Continue work on Games Explorer
by Mariusz Pluciński 25 Mar '11

25 Mar '11

Hello, wine-devel In the last year's GSoC, I was working on implementation of Games Explorer features under Wine. I have successfully created it's own interfaces and made them working. However, the task proved harder than I thought before, so I did not create a user-interface part of the library. My idea for this summer is to finish the implementation of gameux.dll - writing the Shell Extension for GE. It would behave almost exact as the Windows equivalent - it should be able to display registered games as shell items, with possibility to run them, see the statistics etc. Having this should give user-experience a great deal. However, in my opinion it would be also a good way to check and extend the existing implementation of shell32. As far as I know, there is currently no real shell extension being part of Wine, so the working one would increase compatibility a much. There will be probably a problem with making my extension usable for user, as there's no working explorer currently in Wine. However, as I see, the implementation of explorer is one of popular proposal this year. In my opinion, it would be good idea to cooperate my work on GE Shell Extension with the person who will implement explorer.exe (if both ideas will be selected for realization). This would probably improve the quality of both projects. Summarizing, my project assumes following things to do: - write testing set to run under Windows. Tests will read the data from GE using it's shell interfaces. - creating stubs for shell interfaces. This will include following interfaces IShellFolder(2/3?), IShellView, IPersistFolder, IEnumIDList, IContextMenu, and probably a few other. I have created some stubs at the end of last GSoC, but never committed them, as they were requiring a few improvements. - implementing interfaces using the existing infrastructure inside of gameux.dll. Routines giving access to list of installed games were written by me last year, but there are still some missing parts which must be filled to let shell interfaces return proper data. - extending and fixing parts of shell32 (or other libraries) if required. This is mostly undefined part of task, but I've listed it here, cause I suppose this could take significant part of project's time. If there will be still time after finishing the points above, I would like to add one feature from my last-year proposal: a legacy games support. When Microsoft introduced the Games Explorer in Vista, they provided a big set of definitions of currently existing games to make them visible in GE, without requirement of modifications in games. My idea is to extend Wine's Application Database to allow it serve as legacy games database for our GE. This would increment an user experience from using the tool. My name is Mariusz Pluciński. I'm 20 years old student of Information Technology in Gdańsk University of Technology in Poland. Last year I was successfully participating in GSoC in Wine project (project name was "Implementation of Windows Game Explorer equivalent "), so my knowledge seems to be enough to continue work with even better results. Comments are welcome -- Best regards Mariusz Pluciński

1 0

[GSoC] Implementing missing DirectInput8 features
by Lucas Zawacki 25 Mar '11

25 Mar '11

Hello, I'm Lucas Fialho Zawacki a Computer Science undergrad at UFRGS university in Brazil. I'm very interested in working with Wine for the Google Summer of Code and have decided to approach the implementation of DirectInput8 missing features. I'm a long time Wine user, but I'd never looked at it from a developer point of view, so for the past few days I have been reading Wine's developer documentation and familiarizing myself with it's architecture and with the parts I intend to work on. At the moment, I don't have a clear understanding of how the implementation should be done so I'm reading a lot of material about dinput and dinput8 and building some documentation to help me. After some polishing I hope to be able to contribute it to Wine too. A little word about me. I've been using the C programming language for almost three years, so I'm very familiar with it. For the last two years I've worked on a research project as a C/C++ programmer, implementing a decision system for a F180 Small Size League Robot Soccer Team (see http://small-size.informatik.uni-bremen.de/) and http://code.google.com/p/robopet/ . I'm a heavy Linux user and I'm very comfortable with it's tools used for programming. That's it. I'm eager to get your feedback about this. My proposal will be ready in a few days. -- http://www.twitter.com/lfzawacki http://www.linesocode.wordpress.com

2 2

Re: [PATCH 07/15] d3dx9: Add ID3DXBaseEffect interface.
by Henri Verbeet 25 Mar '11

25 Mar '11

2011/3/23 Rico Schüller <kgbricola(a)web.de>: > + FIXME("íface %p, desc %p stub\n", This, desc); Typo?

2 1

Re: [PATCH 03/15] d3dx9: Use size of variable instead of type.
by Nikolay Sivov 25 Mar '11

25 Mar '11

On 3/23/2011 13:49, Rico Schüller wrote: > --- > dlls/d3dx9_36/effect.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > len = MultiByteToWideChar(CP_ACP, 0, srcfile, -1, NULL, 0); > - srcfileW = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, len * sizeof(WCHAR)); > + srcfileW = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, len * sizeof(*srcfileW)); > MultiByteToWideChar(CP_ACP, 0, srcfile, -1, srcfileW, len); No need to zero, if it will be filled with next call. This could a subject of next patch of course.

2 1

[GSoC] Merge winecfg and Control Panel
by Tony Zhang 25 Mar '11

25 Mar '11

Hi everyone, I am a senior student double majoring in Computer Science and Math at Northern Illinois University (currently applying the CS Master Program at NIU) and I would like to participate in merging winecfg and control panel through the Google Summer of Code program. I have used wine since wine 0.9 and 'm now using wine 1.3. I like the idea that all config tools should be grouped and managed at one place, and it would be nice to have them similar to the classical windows control panel (like the control panel in wine 1.3). About my programming background, I believe I know (and love) C the best. I have not had any internships before, but I'm currently working as an undergraduate Research Assistant at NIU. It is a Proton Computed Tomography (Proton CT) project and the main language in use is C, so I do have some experience of using C in a large-scale project. I have briefly walked through Owen Rudge's code of splitting out the Desktop Integration tab into its own control panel, but have no luck in getting a decent understanding of it. So I'm hoping some of you can point me to some documents that related to this task so I can have an overall understanding of the challenges of this task. Sincerely, -- Tony (Chi Zhang)

3 5

wine 1.3.16: wrc compiler and LANGUAGE
by Gilles Depeyrot 24 Mar '11

24 Mar '11

Hi, I am testing compiling an application that uses winelib with 1.3.16 (currently compiled with 1.2.2). I have an issue with the resource compiler (wrc) which doesn't understand the LANGUAGE line. When I compile resource files, I get errors resembling: file.rc:22:21: Error: syntax error The corresponding line in the file is: LANGUAGE LANG_FRENCH, SUBLANG_FRENCH If I comment the line, the compilation succeeds. Best regards, Gilles

4 7

Re: browseui/tests: COM cleanup in autocomplete.c.
by Marvin 24 Mar '11

24 Mar '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=10131 Your paranoid android. === WNT4WSSP6 (32 bit autocomplete) === autocomplete.c:250: Test failed: CoCreateInstance(&CLSID_ACLMulti, NULL, CLSCTX_INPROC, &IID_IEnumString, (LPVOID *)&obj) failed: 80040154

1 0

Re: winex11.drv/opengl.c: add improved error handling to pglXMakeCurrent() call
by Chris Robinson 24 Mar '11

24 Mar '11

On Wednesday, March 23, 2011 9:00:25 PM Joshua Beck wrote: > This patch was made against the origin, so if you've applied my previous > patch, remove that one before applying this one. > This patch makes the error message use ERR_(winediag) instead of just > ERR and is closer in style to the other error messages in opengl.c. There's some trailing whitespace in the patch.

1 0

Re: winex11.drv/opengl.c: add error handling to pglXMakeCurrent() call
by Roderick Colenbrander 24 Mar '11

24 Mar '11

Hi Joshua, Was about to submit a similar patch (had a few tiny fixes in my tree left), but this patch is mostly fine with me. Except I would print to 'winediag' like some of the other errors for software / indirect rendering are doing. So do something like 'Unable to active OpenGL context, like something your drivers have not been configured properly' (look what the other messages are like). Roderick On Thu, Mar 24, 2011 at 2:34 AM, Joshua Beck <jxb091000(a)utdallas.edu> wrote: > This patch should make it easier for those with driver problems to find the > problem when running Wine. > --Josh > > > >

1 0

Duplicate AppDB Entry
by Jeremy Nowka 24 Mar '11

24 Mar '11

"Barnes And Noble EReader" v2.5 and "Nook for PC" are the same program. I feel that the two AppDB entries should be combined for easier access by the general public. I feel that the information should be merged to "Nook for PC" because this is the common name for version 2.5. The version number for "Nook for PC" should be changed to reflect the actual version, 2.5.

2 1

re: [GSoC] Merge winecfg and Control Panel
by Dan Kegel 23 Mar '11

23 Mar '11

Also... it would be nice if there were a central commandline way of changing wine settings, kind of like 'net' is a central way of manipulating networking. I've been thinking that winecfg should have a commandline interface, too, and making it accept winetricks settings directly. Something like that would also make a good soc project.

4 3

Re: [1/2] uxtheme: Add OpenThemeDataEx (try 2)
by Dmitry Timoshkov 23 Mar '11

23 Mar '11

André Hentschel <nerv(a)dawncrow.de> wrote: > Applied Dmitry's suggestions > -HTHEME WINAPI OpenThemeData(HWND hwnd, LPCWSTR pszClassList) > +HTHEME WINAPI OpenThemeDataEx(HWND hwnd, LPCWSTR classlist, DWORD flags) > { > - WCHAR szAppBuff[256]; > - WCHAR szClassBuff[256]; > - LPCWSTR pszAppName; > - LPCWSTR pszUseClassList; > + WCHAR appbuff[256]; > + WCHAR classbuff[256]; > + LPCWSTR appname; > + LPCWSTR useclasslist; > HTHEME hTheme = NULL; You are changing too much. Just use lowercase named variables for new code, not touching existing ones. > - TRACE("(%p,%s)\n", hwnd, debugstr_w(pszClassList)); > + TRACE("(%p,%s, %u)\n", hwnd, debugstr_w(classlist), flags); flags above is still printed in decimal. > + > + if(flags) > + FIXME("unhandled Flags: %x\n", flags); -- Dmitry.

1 0

Re: [PATCH 2/4] comdlg32: Add stub implementation of the Common Item dialogs.
by Nikolay Sivov 23 Mar '11

23 Mar '11

On 3/21/2011 16:37, David Hedberg wrote > + */ > + > +#include<stdarg.h> > + > +#define COBJMACROS > +#define NONAMELESSUNION > +#define NONAMELESSSTRUCT > + > +#include "windef.h" > +#include "winbase.h" > +#include "winuser.h" > +#include "wingdi.h" > + > +#include "commdlg.h" > +#include "cdlg.h" > + > +#include "wine/debug.h" > + > +WINE_DEFAULT_DEBUG_CHANNEL(commdlg); > + > +typedef struct FileDialogImpl { > + IFileDialog2 IFileDialog2_iface; > + IFileOpenDialog IFileOpenDialog_iface; > + IFileSaveDialog IFileSaveDialog_iface; > + LONG ref; > +} FileDialogImpl; Maybe it's better to use a union and enum type field here, if it can't be open and save at the same time. > + > +/************************************************************************** > + * IFileDialog implementation > + */ > +static inline FileDialogImpl *impl_from_IFileDialog2(IFileDialog2 *iface) > +{ > + return (FileDialogImpl *)((char*)iface - FIELD_OFFSET(FileDialogImpl, IFileDialog2_iface)); > +} > + Use CONTAINING_RECORD macro please. > +static HRESULT WINAPI IFileDialog2_fnQueryInterface(IFileDialog2 *iface, > + REFIID riid, > + void **ppvObject) > +{ > > + } > + else > + FIXME("Unknown interface requested.\n"); It's better to dump guid here. > +} > + > +static ULONG WINAPI IFileDialog2_fnRelease(IFileDialog2 *iface) > +{ > + FileDialogImpl *This = impl_from_IFileDialog2(iface); > + LONG ref = InterlockedDecrement(&This->ref); > + TRACE("%p - ref %d\n", This, ref); > + > + if(!ref) > + { > + TRACE("Freeing object.\n"); > + HeapFree(GetProcessHeap(), 0, This); > + } > + > + return ref; > +} No need for additional trace I think, ref == 0 is enough to indicated that. > +static HRESULT FileDialog_constructor(IUnknown *pUnkOuter, REFIID riid, void **ppv, REFCLSID type) > +{ > + FileDialogImpl *fdimpl; > + HRESULT hr; > + TRACE("%p, %s, %p\n", pUnkOuter, debugstr_guid(riid), ppv); > + > + if(!ppv) > + return E_POINTER; > + if(pUnkOuter) > + return CLASS_E_NOAGGREGATION; > + > + fdimpl = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(FileDialogImpl)); > + if(!fdimpl) > + return E_OUTOFMEMORY; Zero initialization is useless here. > + > + fdimpl->IFileDialog2_iface.lpVtbl =&vt_IFileDialog2; > + > + if(IsEqualCLSID(type,&CLSID_FileOpenDialog)) > + fdimpl->IFileOpenDialog_iface.lpVtbl =&vt_IFileOpenDialog; > + else > + fdimpl->IFileSaveDialog_iface.lpVtbl =&vt_IFileSaveDialog; > + > + IUnknown_AddRef((IUnknown*)fdimpl); > + hr = IUnknown_QueryInterface((IUnknown*)fdimpl, riid, ppv); > + IUnknown_Release((IUnknown*)fdimpl); > + That looks strange, you only need one QueryInterface here.

2 4

Re: Question
by Andrew Green 22 Mar '11

22 Mar '11

There are no teams in gsoc. Each person has to work individually on the project they choose. How it works is that the organisation pick projects it approves of. Then these projects are sent to google. Google takes into account various factors to decide how many projects get selected. On Mar 23, 2011 12:24 AM, "Sanket Patel" <sanketpatel.com(a)gmail.com> wrote: > > How Teams Are Formed in Google Summer Of Code For Any Project. > Is It Formed By Organization Or Google ? > > -- > " Live 2 Love and Love 2 Live " > > >

1 0

winex11.drv/opengl.c: Unhandled null pointer
by Joshua Beck 22 Mar '11

22 Mar '11

I've been trying to run wine with a few games, and I've been getting a similar error and backtrace with all of them. Here's the relevant info: wine: Unhandled page fault on read access to 0x00000000 at address 0xf748c110 (thread 0043), starting debugger... Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0xf748c110). ... Backtrace: =>0 0xf748c110 in libc.so.6 (+0x74110) (0x0032e670) 1 0x7e59fae9 X11DRV_WineGL_InitOpenglInfo+0x353() [/home/jb/programs/wine-git/dlls/winex11.drv/opengl.c:351] in winex11 (0x0032e670) ... (goes on for a dozen or so more, not relevant to this bug) So my first thought was "What's wrong with libc?" Then I looked at the source of the file at level 1 of the stack and found this: 350: str = (const char *) pglGetString(GL_EXTENSIONS); 351: WineGLInfo.glExtensions = HeapAlloc(GetProcessHeap(), 0, strlen(str)+1); From this it's obvious that pglGetString is returning a null pointer. It would be better to do something like this instead: str = (const char *) pglGetString(GL_EXTENSIONS); if(str == 0) { ERR( "Couldn't find GL_EXTENSIONS string, disabling OpenGL.\n" ); goto done; } WineGLInfo.glExtensions = HeapAlloc(GetProcessHeap(), 0, strlen(str)+1); What do you think?

3 3

Question
by Sanket Patel 22 Mar '11

22 Mar '11

How Teams Are Formed in Google Summer Of Code For Any Project. Is It Formed By Organization Or Google ? -- " Live 2 Love and Love 2 Live "

2 1

Re: kernel32: avoid shadowing a parameter (try 2)
by Henri Verbeet 22 Mar '11

22 Mar '11

On 22 March 2011 02:27, Austin English <austinenglish(a)gmail.com> wrote: > defval_tmp = HeapAlloc(GetProcessHeap(), 0, (len + 1) * sizeof(WCHAR)); > - memcpy(defval_tmp, def_val, len * sizeof(WCHAR)); > - defval_tmp[len] = '\0'; > + memcpy(defval_tmp, def_val, defval_len * sizeof(WCHAR)); > + defval_tmp[defval_len] = '\0'; I think you're allocating the wrong amount of memory now.

1 0

Re: [1/4] wined3d/context: Track the number of render targets in FBO entries.
by Stefan Dösinger 22 Mar '11

22 Mar '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 21.03.2011 um 21:56 schrieb Adam Martinson: > > Cuts CPU time in context_apply_fbo_state() in half. What is the performance impact on real apps? -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJNiHM5AAoJEN0/YqbEcdMwi28P/1iN598GQgE9ttILayjW6f1h E8DKkF30dJyXa506XoPKWeE+319mpLOevUca2hjBaaKoL+H69TzCproGGgdw7/W3 roWyg2Q42hibFnTb5ORwgjbsQbqYlRaMj7nlCJguyDjnK81oNIpLWjdiVWpe4H+b naQf+p9NWRR6x2tOx4i71MgvWnbPRiawJO14DxwwyTxelYWu05XgWvFaRYuyKevt 67q8yGGVx+4SXmSC1D5rzRAjY2OHIvGbznlrC3VV3TmpQg5YsrWS7b8XWr/Ii3DJ DQsOLbv/KMFTOTcQ6wjI+dJPX/lM/3z7QcOVVsAGZyOvH+8fIMAwtDcgU+EAwyWY CaM7NH6JM8Jlal4r8Hfhw/9IfLr+K6WVzYKPdjxO+PUxhV1GV4GC74vQn8wMHK4U LANQ5Kw9s+dThqM6gyBTcdyD8r37ktULlOyAFfx4a63Wg8JRBiqPyEyRufoCK7Kf lfsOGcadkAy9eKh4tIlaEfOMwewOap7Mq4veyQLO6JrnWVKIPg/vCufT4SD5VgPG AMtvbG0lqX5+egdH0IM6j4e9CiescSwqHqywphvxGwzQlPpbejvnIysFLH351lBQ cqIjVmcXLDTRigO8cpg+r7yyntVSCGZ8HduZlgwCLroOHJvK1vR0LkUHPIC1M5yE CYKj0gOxXQ7k8pT0uHJb =UrlD -----END PGP SIGNATURE-----

1 0

Re: Idea
by Hin-Tak Leung 22 Mar '11

22 Mar '11

(Please keep the wine-devel CC:) Sanket Patel wrote: > User File Location > > On Tue, Mar 22, 2011 at 8:25 AM, Hin-Tak Leung <hintak_leung(a)yahoo.co.uk > <mailto:hintak_leung@yahoo.co.uk>> wrote: > > Sanket Patel wrote: > > > hi there, > I talk about to make wine portable. > How I am Gonna Do That is , > There is a files that are related to system and integrated in to > system while install. > We gonna change that system files places . > How ? that is still question but we can do By community Support. > > If you talk about takiinng 1/2 of system files into package , i > think there is not really a case to happen > > > Hmm, I think you are confusing 'relocatable' vs 'portable' - in any > case, wine is already both portable (runs on many x86/x86_64-based > unix systems, include linux, *bsd, solaris, Mac OS X), and wine is > also relocatable to a good extent - > you can either run wine without installing, from within the > source(build) directory with the script provided, or you can choose > an install location with "./configure --prefix=..." > > Or may be you mean the user file location (${HOME}/.wine > (WINEPREFIX)) vs the wine binary locations (the ./configure > --prefix=<where>)? You need to clarify what you propose. Perhaps you did not notice, I already wrote that user file location, while defaults to ${HOME}/.wine, is controllable by setting the WINEPREFIX environment variable before launching wine. This machanism of allowing for parallel and separate user files are quite actively used and maintained. WineInBottle (or something of a similar name?) and possibly a few other "wine add-ons" does that, actually.

1 0

Re: winex11.drv/opengl.c: Unhandled null pointer
by Dmitry Timoshkov 22 Mar '11

22 Mar '11

[Please do not omit wine-devel(a)winehq.org when replying] Joshua Beck <jxb091000(a)utdallas.edu> wrote: > > What OpenGL driver are you using? glGetString(GL_EXTENSIONS) returning NULL > > might be a driver bug. > > > I'm using an nvidia binary driver (260.36.19 I think). Thing is I'm > running Debian amd64 and I compiled wine with -m32. I checked and there > are nvidia libraries in /usr/lib32. However I don't know if all of them > are in there or if they work correctly. See http://wiki.winehq.org/3DDriverIssues how to diagnose GL driver problems. > >> It would be better to do something like this instead: > >> > >> str = (const char *) pglGetString(GL_EXTENSIONS); > >> if(str == 0) > >> { > >> ERR( "Couldn't find GL_EXTENSIONS string, disabling OpenGL.\n" ); > >> goto done; > >> } > >> WineGLInfo.glExtensions = HeapAlloc(GetProcessHeap(), 0, strlen(str)+1); > >> > >> > >> What do you think? > >> > > WineGLInfo.glExtensions is used in other places in the code, it must be > > initialized. > > > > > If str == 0 then the program is going to crash before anything else can > get to WineGLInfo.glExtensions. Better to say what the error is than to > crash with an "Unhandled page fault" error. If it's that important to > have WineGLInfo.glExtensions initialized to something then initialize > it to an error code. If pglGetString(GL_EXTENSIONS) returns NULL for whatever reason allocating an 1 byte WineGLInfo.glExtensions buffer and setting it to 0 should work just fine. -- Dmitry.

1 0

Re: [1/4] wined3d/context: Track the number of render targets in FBO entries.
by Dmitry Timoshkov 22 Mar '11

22 Mar '11

Adam Martinson <amartinson(a)codeweavers.com> wrote: > Cuts CPU time in context_apply_fbo_state() in half. > --- > dlls/wined3d/context.c | 65 > +++++++++++++++++++++------------------ > dlls/wined3d/wined3d_private.h | 1 + > 2 files changed, 36 insertions(+), 30 deletions(-) It looks like you are not subscribed to wine-patches mailing list and your patches are delayed awaiting the moderator action. -- Dmitry.

1 0

Re: [1/2] uxtheme: Add OpenThemeDataEx
by Dmitry Timoshkov 22 Mar '11

22 Mar '11

André Hentschel <nerv(a)dawncrow.de> wrote: > - TRACE("(%p,%s)\n", hwnd, debugstr_w(pszClassList)); > + TRACE("(%p,%s, %u)\n", hwnd, debugstr_w(pszClassList), Flags); > + > + if(Flags) > + FIXME("unhandled Flags: %u\n", Flags); ... > +#define OTD_FORCE_RECT_SIZING 0x0001 > +#define OTD_NONCLIENT 0x0002 > +#define OTD_VALIDBITS (OTD_FORCE_RECT_SIZING | OTD_NONCLIENT) Flags should be printed as hex in the traces. Also using names without capitalizaion and hungarian notation is always preferred for new code in Wine. -- Dmitry.

1 0

Idea
by Sanket Patel 22 Mar '11

22 Mar '11

hi there, I talk about to make wine portable. How I am Gonna Do That is , There is a files that are related to system and integrated in to system while install. We gonna change that system files places . How ? that is still question but we can do By community Support. If you talk about takiinng 1/2 of system files into package , i think there is not really a case to happen -- " Live 2 Love and Love 2 Live "

2 1

Xbox 360 controller compatibility
by Alesh Slovak 22 Mar '11

22 Mar '11

Hi, I apologize if this question has come up before, I could not find a search feature in the mailing list archives and google didn't give me much on the subject. I am interested in getting the Xbox 360 controller working in wine. Currently, I can use the controller, but it is recognized only as a generic controller. This is acceptable (although annoying) for games that allow me to freely configure the controller, but others seem to specifically look for an Xbox 360 controller, and when they can't find it, drop to keyboard controls. Firstly, I am not even sure this is something that should or can be handled in wine. Maybe this needs to be handled in the xpad kernel module, or maybe both. But my guess is that wine would need to detect an Xbox 360 controller and then explicitly present it as such to any games. I guess the first step would be to find out how exactly games detect the Xbox 360 controller under Windows and try to emulate that. Any other previous attempts that anyone knows of? I would appreciate it if anybody out there who has any knowledge in this area, can point me in the right direction. Thanks.

5 11

Re: mshtml: avoid shadowing a parameter (2/2)
by Jacek Caban 22 Mar '11

22 Mar '11

Hi Austin, On 3/9/11 10:07 AM, Austin English wrote: > diff --git a/dlls/mshtml/htmlwindow.c b/dlls/mshtml/htmlwindow.c > index d0d378f..9948a02 100644 > --- a/dlls/mshtml/htmlwindow.c > +++ b/dlls/mshtml/htmlwindow.c > @@ -2141,22 +2141,22 @@ static HRESULT HTMLWindow_invoke(DispatchEx *dispex, DISPID id, LCID lcid, WORD > > switch(prop->type) { > case GLOBAL_SCRIPTVAR: { > - IDispatchEx *dispex; > + IDispatchEx *dpex; How about renaming argument name to 'iface'? It's not really an interface, but its purpose in this context is like iface arguments in regular COM objects. Jacek

2 1

Re: wined3d: Prevent crash when blit_priv is NULL.
by Roderick Colenbrander 21 Mar '11

21 Mar '11

Hi Konrad, You should try to figure out why blit_priv is NULL. That's the real issue. What drivers are you using? Do they support arb fragment program? Right now we may still call arbfp_blit_surface when the extension isn't around (was working on this a year ago, haven't had time since then :( ), this could explain why there is no priv_data since in ffp_blit_alloc we don't do any allocation. Roderick On Sun, Mar 20, 2011 at 3:58 AM, Konrad Rzepecki <hannibal(a)astral.lodz.pl> wrote: > Might&Magic VII from gog.com crash in bink movie plaing: > > Backtrace: > =>0 0x7e70c4b9 arbfp_blit_set+0x28b(blit_priv=0x0(nil), gl_info=0x135b08, surface=0x1dc788) [/mnt/skopia/devel/winegit/wine/dlls/wined3d/arb_program_shader.c:7058] in wined3d (0x0033f98c) > 1 0x7e70d3db arbfp_blit_surface+0xa2(device=0x16cdc0, src_surface=0x1dc788, src_rect=0x33fa74, dst_surface=0x168140, dst_rect_in=0x33fa84, blit_op=BLIT_OP_BLIT, Filter=0x2) [/mnt/skopia/devel/winegit/wine/dlls/wined3d/arb_program_shader.c:7192] in wined3d (0x0033f9dc) > 2 0x7e7d28f7 IWineD3DSurfaceImpl_BltOverride+0xf1b(dst_surface=0x168140, DestRect=0x33fcf8, src_surface=0x1dc788, SrcRect=0x33fce8, flags=0x1000000, DDBltFx=(nil), Filter=WINED3DTEXF_LINEAR) [/mnt/skopia/devel/winegit/wine/dlls/wined3d/surface.c:3787] in wined3d (0x0033fbac) > 3 0x7e7d3013 IWineD3DSurfaceImpl_Blt+0x29e(iface=0x168140, DestRect=0x33fcf8, src_surface=0x1dc788, SrcRect=0x33fce8, flags=0x1000000, DDBltFx=(nil), Filter=WINED3DTEXF_LINEAR) [/mnt/skopia/devel/winegit/wine/dlls/wined3d/surface.c:3930] in wined3d (0x0033fc2c) > 4 0x7e8687f2 ddraw_surface7_Blt+0x380(iface=0x135308, DestRect=0x33fcf8, SrcSurface=0x1dc560, SrcRect=0x33fce8, Flags=0x1000000, DDBltFx=(nil)) [/mnt/skopia/devel/winegit/wine/dlls/ddraw/surface.c:908] in ddraw (0x0033fc9c) > 5 0x004a18cd in mm7-rel (+0xa18cc) (0x0033fcc8) > 6 0x004beda4 in mm7-rel (+0xbeda3) (0x0033fd08) > 7 0x004be721 in mm7-rel (+0xbe720) (0x00000000) > --- > dlls/wined3d/surface.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c > index 745bd77..baa032b 100644 > --- a/dlls/wined3d/surface.c > +++ b/dlls/wined3d/surface.c > @@ -3924,8 +3924,8 @@ static HRESULT WINAPI IWineD3DSurfaceImpl_Blt(IWineD3DSurface *iface, const RECT > } > > /* Special cases for RenderTargets */ > - if ((This->resource.usage & WINED3DUSAGE_RENDERTARGET) > - || (src && (src->resource.usage & WINED3DUSAGE_RENDERTARGET))) > + if (This->resource.device->blit_priv && ((This->resource.usage & WINED3DUSAGE_RENDERTARGET) > + || (src && (src->resource.usage & WINED3DUSAGE_RENDERTARGET)))) > { > if (SUCCEEDED(IWineD3DSurfaceImpl_BltOverride(This, DestRect, src, SrcRect, flags, DDBltFx, Filter))) > return WINED3D_OK; > -- > 1.7.4.1 > > >

3 5

Failing kernel32:change and ntdll:change tests on Mac OS
by Charles Davis 21 Mar '11

21 Mar '11

Hi, I just got done looking over the latest batch of test results I sent, and one thing really sticks out and bothers me. The Change Notification tests all fail miserably on my machine (a 2009 Mac Pro with Mac OS X 10.6), because that feature hasn't been implemented on Mac yet. I could implement it for 10.5 up, but the problem is that the "public" API for Change Notifications on Mac (the "FSEvents" API, in CoreServices.framework) expects clients to either use a CFRunLoop or (on 10.6 and up) a GCD dispatch queue. I'm sure this won't sit well with AJ. I did some digging, and it turns out that FSEvents just uses a Mach port (whose name is published in root's Mach bootstrap context as "com.apple.FSEvents") to talk to a daemon, fseventsd, which in turn opens a device file, /dev/fsevents, which is the actual gateway to the kernel. Though it's largely undocumented, we could use this device file to implement Change Notification. The FDs that get returned by this file even support kqueues. But, there are two tiny problems with that: 1) You have to be root to open /dev/fsevents. If we do it this way, we will have to wait until the server is converted to run as root. 2) Because this API isn't officially documented, it's unstable and subject to change. (In fact, judging from the kernel source, it's already changed once. There are several 'old' and 'new' variants of the FSEvents ioctls that the kernel handler supports.) I guess the real question is, which way should we do this? If we do it the first way (using the public and documented but kqueue-unfriendly Carbon API), wineserver has to use a CFRunLoop (or, if we're no longer concerned about Leopard, a GCD dispatch queue) in its main loop, and if we do it the second way (using the undocumented and unstable but kqueue-friendly Unix API), wineserver needs to run as root, and may need to cope with API changes. Based on what I've heard, I'm leaning toward the second way, but I want your guys' input before I go ahead. Thanks. Chip

2 4

Re: msi: Add an offset to sequence numbers belonging to files added by a patch. (try 2)
by Hans Leidekker 21 Mar '11

21 Mar '11

On Mon, 2011-03-21 at 14:14 +0100, David Hedberg wrote: > +static void msi_patch_offset_list_init(struct msi_patch_offset_list **pos) > +{ > + *pos = msi_alloc(sizeof(struct msi_patch_offset_list)); > + list_init( &(*pos)->files ); > + (*pos)->count = (*pos)->max = 0; > + (*pos)->min = 999999; > +} It would be nicer to have a _create function that returns an initialized structure.

1 0

Re: user32: Fix return value when passing a non-sibling preceding window to SetWindowPos.
by Dmitry Timoshkov 21 Mar '11

21 Mar '11

David Hedberg <dhedberg(a)codeweavers.com> wrote: > +#define ERROR_ABORT_WITH_TRUE 30000 ... > /* Fix redundant flags */ > - if (!fixup_flags( winpos )) return FALSE; > + ret = fixup_flags( winpos ); > + if(ret == ERROR_FUNCTION_FAILED) > + return FALSE; > + else if(ret == ERROR_ABORT_WITH_TRUE) > + return TRUE; Please try to avoid made up names and internal conditions. I'd suggest to add a test case which shows the problem first with todo_wine around the failing test, and only then send a fix, so it's clear what actually your patch is doing. Tiny nitpick, in the code below: if (condition1) return something1; else if (contition2) return something2; 'else' statement is redundant. -- Dmitry.

1 0

Re: [1/4] wined3d: don't create VBOs in buffer::preload
by Henri Verbeet 21 Mar '11

21 Mar '11

On 20 March 2011 20:07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > I'm not so sure about this patch. I think preload() should conceptually be "wined3d_resource_load_location(resource, WINED3D_RESOURCE_LOCATION_GPU, NULL);", and this patch seems to move away from that rather than towards it. I'm also not sure about how the bug you're describing would actually happen. Although device_stream_info_from_declaration() seems to assume preload() can only drop buffer objects, it does correctly call buffer_get_sysmem(), so the resulting stream info should be consistent, even though perhaps somewhat sub-optimal. Shouldn't this just be a matter of fixing device_stream_info_from_declaration() to not assume preload() can only drop buffer objects?

1 0

Re: [PATCH] winegcc - do not create .exe.so
by Vitaliy Margolen 21 Mar '11

21 Mar '11

On 03/20/2011 05:14 AM, Pali Rohár wrote: > Can anybody review my patch? Not sure what you trying to do exactly. Wine already has wrapper that makes all wine binaries executable after they are being installed into system. As for the patch: - Do not use tab characters - Please no unneeded white space changes - Use git to create your patch. At the very minimum it have to have full path to the source file in the header - patch should be generated from the top of the source tree. Vitaliy.

4 8

Re: [PATCH] winegcc - do not create .exe.so
by James McKenzie 21 Mar '11

21 Mar '11

On 3/20/11 4:14 AM, Pali Rohár wrote: > 2011/2/19 Pali Rohár<pali.rohar(a)gmail.com>: >> 2011/2/4 Pali Rohár<pali.rohar(a)gmail.com>: >>> Hello, >>> >>> I created patch which implement correct _start section in ELF shared >>> libraries/binaries which generate winegcc. >>> Into _start section this patch add calling execve syscall which start >>> wine with all arguments. So it is not needed to generate shell wrapper >>> and .exe.so binary. >>> >>> This replace code on: >>> http://wiki.winehq.org/Winelib_binaries_as_ELF_executables_not_.exe.so >>> >>> $ winegcc app.c --> generate only a.exe (shared object ELF binary), no >>> aditional a.exe.so >>> $ ./a.exe --> start binary correctly without shell wrapper >>> >>> -- >>> Pali Rohár >>> pali.rohar(a)gmail.com >>> >> I rewrited my patch. Now set up correctly enviromental variables too. >> Assembler code is only for x86. >> >> -- >> Pali Rohár >> pali.rohar(a)gmail.com >> > Can anybody review my patch? > Reviews are sent to wine-development list. If you want to submit a patch for comment only, please submit it to wine-development. Thank you. James McKenzie

1 0

Idea
by Sanket Patel 20 Mar '11

20 Mar '11

I Have One Idea ......... Why Should not we make wine portable ? -- " Live 2 Love and Love 2 Live "

2 1

d3dx10: Float16To32Array and Float32To16Array (GSoC)
by Joshua Beck 20 Mar '11

20 Mar '11

I'm looking for feedback on an idea for a Google Summer of Code project. I looked at bugzilla and found that the D3DX9 versions of Float16To32Array and Float32To16Array were needed for some games to run. I thought that implementing those functions would make a good Google Summer of Code project, but later discovered that Misha Koshelev had already implemented them in a patch that wasn’t committed yet. In looking up documentation on half floats and these functions gave me ideas for other improvements. For instance, the functions may be implemented differently in D3DX10. A post in this thread: http://www.devmaster.net/forums/showthread.php?t=10924 says that D3DX10 uses different rounding rules and can store NaNs and infinities. I have access to computers running Vista and 7 so I would be able to test how the D3DX10 versions of the functions convert floating point numbers. After doing so, I could make the D3DX10 versions of the functions by modifying the D3DX9 patch’s code. I could also write a conformance test to make sure that the functions are implemented correctly in D3DX10. Joshua Beck

2 2

GSoC: Cygwin and the file system
by Jay Yang 20 Mar '11

20 Mar '11

Hello, First an introduction, My name is Jay Yang, I'm currently an undergraduate at the University of Michigan, and as this email indicates, I'm interested in participating in Google Summer of Code. I've been looking at the Cygwin project idea listed on the Summer of Code page, and after looking at some bug reports, I found at least three bugs related to Cygwin that seem to have something to do with the file system. I also saw that the Cygwin page on the wine wiki seems to note that symlinks are one thing that do not work correctly. Is there some underlying bug or unimplemented feature that is causing these failures or are they each their own problem? Also would fixing some of these file system related issues be a good project? Thanks -- Jay Yang

1 0

testing sending to mailing list
by Joshua Beck 20 Mar '11

20 Mar '11

My last two emails to this list haven't been accepted. I think I figured out the reason why. Instead of resending the last email I sent, which might make it look like I'm spamming, I'm sending this test email instead.

2 1

Re: [PATCH] Label verbosity levels.
by max＠mtew.isa-geek.net 20 Mar '11

20 Mar '11

From: max <max(a)mtew.isa-geek.net> On 03/19/2011 08:42 PM, Joris Huizer wrote: > On 03/19/2011 11:32 PM, Vitaliy Margolen wrote: >> On 03/18/2011 09:24 PM, max(a)mtew.isa-geek.net wrote: >>> - if ($opt_verbose> 0) >>> - { >>> - print "Processing ".$spec_name."\n"; >>> - } >>> + print "Processing ".$spec_name."\n" >>> + if $opt_verbose q>= $VERBOSE_INPUT; >> >> Please don't do this reverse notation. It's much more confusing to most people who are not too familiar with Perl. >> >> Also you changing logic, by replacing ">" (greater then) with ">=" (greater of equal. This is a big no-no to combine any logical changes with cleanup changes. > > This doesn't seem to change logic as $VERBOSE_INPUT equals 1 ( $VERBOSE_QUIET equals 0 ) > Correct. The clean-up involves two counter-acting logic changes. The change from > to >= is countered by increasing the target number by one. The result is that the number itself has the designated meaning. Before the number was one less than level needed to change the affect. There is no _functional_ change. The suffix logical form is not that difficult to understand. It shifts the emphasis from the conditional as the thing of primary import to the message being conveyed, where it belongs. On the other hand if anybody can come up with better names for the levels, PLEASE comment! Max

2 1

d3dx10: Float16To32Array and Float32To16Array (GSoC)
by Joshua Beck 20 Mar '11

20 Mar '11

I'm looking for feedback on an idea for a Google Summer of Code project. I looked at bugzilla and found that the D3DX9 versions of Float16To32Array and Float32To16Array were needed for some games to run. I thought that implementing those functions would make a good Google Summer of Code project, but later discovered that Misha Koshelev had already implemented them in a patch that wasn’t committed yet. In looking up documentation on half floats and these functions gave me ideas for other improvements. For instance, the functions may be implemented differently in D3DX10. A post in this thread: http://www.devmaster.net/forums/showthread.php?t=10924 says that D3DX10 uses different rounding rules and can store NaNs and infinities. I have access to computers running Vista and 7 so I would be able to test how the D3DX10 versions of the functions convert floating point numbers. After doing so, I could make the D3DX10 versions of the functions by modifying the D3DX9 patch’s code. I could also write a conformance test to make sure that the functions are implemented correctly in D3DX10. Joshua Beck

1 0

[GSOC] d3dx10: Float16To32Array and Float32To16Array
by Joshua Beck 20 Mar '11

20 Mar '11

I'm looking for feedback on an idea for a Google Summer of Code project. I looked at bugzilla and found that the D3DX9 versions of Float16To32Array and Float32To16Array were needed for some games to run. I thought that implementing those functions would make a good Google Summer of Code project, but later discovered that Misha Koshelev had already implemented them in a patch that wasn't committed yet. In looking up documentation on half floats and these functions gave me ideas for other improvements. For instance, the functions may be implemented differently in D3DX10. A post in this thread: http://www.devmaster.net/forums/showthread.php?t=10924 says that D3DX10 uses different rounding rules and can store NaNs and infinities. I have access to computers running Vista and 7 so I would be able to test how the D3DX10 versions of the functions convert floating point numbers. After doing so, I could make the D3DX10 versions of the functions by modifying the D3DX9 patch's code. I could also write a conformance test to make sure that the functions are implemented correctly in D3DX10. Joshua Beck

1 0

re: [1/2] msvcrt: Implement _mbsupr_s (try2).
by Dan Kegel 20 Mar '11

20 Mar '11

Konrad wrote: > + c = _mbctoupper(_mbsnextc(s)); > + /* Note that I assume that the size of the character is unchanged */ > + if (c > 255) > + { > + *s++=(c>>8); > + c=c & 0xff; > + } > + *s++=c; Tests might be in order... (Here's one possible interesting test case: http://blogs.msdn.com/b/michkap/archive/2009/08/11/9864576.aspx ) - Dan

2 3

Re: [PATCH] Label verbosity levels.
by Vitaliy Margolen 20 Mar '11

20 Mar '11

On 03/18/2011 09:24 PM, max(a)mtew.isa-geek.net wrote: > - if ($opt_verbose> 0) > - { > - print "Processing ".$spec_name."\n"; > - } > + print "Processing ".$spec_name."\n" > + if $opt_verbose>= $VERBOSE_INPUT; Please don't do this reverse notation. It's much more confusing to most people who are not too familiar with Perl. Also you changing logic, by replacing ">" (greater then) with ">=" (greater of equal. This is a big no-no to combine any logical changes with cleanup changes.

2 1

GSOC-Introduction
by Sanket Patel 19 Mar '11

19 Mar '11

Hi there I am Sanket Patel I can code well in C If Anything is say to Implement I have good skill in coding in C At all And can Use Efficient C help topics.

1 0

Summer of Code 2011 is on!
by Maarten Lankhorst 19 Mar '11

19 Mar '11

Hi all, As you may have known wine has been accepted for summer of code 2011 as a mentoring organization. As such the wine project is now looking for students to participate this year with wine. On our wiki page[1] you can find some ideas, but if you come up with your own idea you will have a lot better chance of getting accepted, as long as you listen to feedback. Summer of code is not just learning to code, but also getting your code accepted into the wine git tree. We'll try to help with that, but the interaction with the wine community is definitely required. For some advice you can read [2] for example. [1] http://wiki.winehq.org/SummerOfCode [2] http://bit.ly/efXVqz Cheers, Maarten PS1: Is anyone willing to add a 'news' blurb about summer of code to the main site? PS2: Also looking for mentor applies.

1 0

Re: clusapi: add stub for GetClusterInformation
by Dmitry Timoshkov 18 Mar '11

18 Mar '11

Konrad Rzepecki <hannibal(a)astral.lodz.pl> wrote: > +/*********************************************************************** > + * GetClusterInformation (CLUSAPI.@) > + * > + */ > +DWORD WINAPI GetClusterInformation(HCLUSTER hCluster, LPWSTR > lpszClusterName, LPDWORD lpcchClusterName, LPCLUSTERVERSIONINFO > lpClusterInfo) It looks like your mailer has wrapped all your patches. -- Dmitry.

5 4

Vacation
by Alexandre Julliard 18 Mar '11

18 Mar '11

Folks, There won't be any commits next week, since I'll be busy skiing. Next release should be on schedule two weeks from now. See you all in a week! -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: urlmon: Use unescaped Urls for FTP actions (try 2)
by Jacek Caban 18 Mar '11

18 Mar '11

Hi André, On 3/17/11 8:58 PM, André Hentschel wrote: > ...don't leak path... > --- > dlls/urlmon/ftp.c | 16 ++++++++++++---- > 1 files changed, 12 insertions(+), 4 deletions(-) > > diff --git a/dlls/urlmon/ftp.c b/dlls/urlmon/ftp.c > index c9d43b8..a27d84c 100644 > --- a/dlls/urlmon/ftp.c > +++ b/dlls/urlmon/ftp.c > @@ -59,22 +59,30 @@ static HRESULT FtpProtocol_open_request(Protocol *prot, IUri *uri, DWORD request > HINTERNET internet_session, IInternetBindInfo *bind_info) > { > FtpProtocol *This = impl_from_Protocol(prot); > - BSTR url; > + DWORD path_size = INTERNET_MAX_URL_LENGTH; > + BSTR url, path; > HRESULT hres; > > hres = IUri_GetAbsoluteUri(uri,&url); > if(FAILED(hres)) > return hres; > + path = heap_alloc(path_size); > + hres = UrlUnescapeW((LPWSTR)url, path,&path_size, 0); It looks like using GetDisplayUri is what you need. Jacek

1 0

Re: msxml3: Prevent a crash at second call to vsnprintf
by Nikolay Sivov 17 Mar '11

17 Mar '11

On 3/18/2011 02:00, André Hentschel wrote: > i did test that now for a while and if the first time the buffer isn't enough and len gets incremented (no matter how much) then the next call to vnsprintf crashes. > that seems to happen only with 64 bits and i would blame Ubuntu for it :) > see http://test.winehq.org/data/12b24af8d7bbb515c4cc678eef45c396487816a4/wine_a… > > so bumping the buffer length to 64 is enough to not trigger that case with our testsuite > --- > dlls/msxml3/main.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/msxml3/main.c b/dlls/msxml3/main.c > index 01eabab..d3fda99 100644 > --- a/dlls/msxml3/main.c > +++ b/dlls/msxml3/main.c > @@ -63,7 +63,7 @@ HINSTANCE MSXML_hInstance = NULL; > void wineXmlCallbackLog(char const* caller, xmlErrorLevel lvl, char const* msg, va_list ap) > { > char* buf = NULL; > - int len = 32, needed; > + int len = 64, needed; > enum __wine_debug_class dbcl = __WINE_DBCL_ERR; > switch (lvl) > { I feel like you need to figure out why it crashes.

1 0

Spammer on AppDB
by Erich Hoover 17 Mar '11

17 Mar '11

Account named "AnnaT": http://appdb.winehq.org/objectManager.php?sClass=version&iId=7440#Comment-6…

2 1

Re: wineport: Add support for ctz().
by Adam Martinson 17 Mar '11

17 Mar '11

On 03/17/2011 02:04 PM, Alexander Kochetkov wrote: >> For my purposes the 'return -1' path will never be taken, so it's not >> needed. I want to be able to do: >> >> while (bitmap) >> { >> i = ctz(bitmap); /* get the LSB index */ >> bitmap ^= 1<< i; /* zero LSB */ >> >> /* for each set bit i... */ >> } >> >> If there's a faster way to do this I'm all ears. >> > while (bitmap) > { > bitmap = (bitmap& (bitmap - 1)); /* zero LSB */ > > /* for each set bit i... */ > } > > You could try this solution to zero lsb. > Yes, that's another way to zero the LSB, but I need the index (i).

1 0

Re: msvcrt: add implementation of _mbsupr_s and _mbslwr_s
by Austin English 17 Mar '11

17 Mar '11

On Thu, Mar 17, 2011 at 09:39, Konrad Rzepecki <hannibal(a)astral.lodz.pl> wrote: > --- > dlls/msvcr100/msvcr100.spec | 4 +- > dlls/msvcr80/msvcr80.spec | 4 +- > dlls/msvcr90/msvcr90.spec | 4 +- > dlls/msvcrt/mbcs.c | 72 > +++++++++++++++++++++++++++++++++++++++++++ > dlls/msvcrt/msvcrt.spec | 4 +- > 5 files changed, 80 insertions(+), 8 deletions(-) These should be two separate patches, one for each function. Thanks for working on Wine! -- -Austin

1 0

Re: wineport: Add support for ctz().
by Alexandre Julliard 17 Mar '11

17 Mar '11

Adam Martinson <amartinson(a)codeweavers.com> writes: > @@ -239,6 +243,19 @@ extern int getopt_long_only (int ___argc, char *const *___argv, > int ffs( int x ); > #endif > > +#if defined(__GNUC__) && (GCC_VERSION >= 30406) > + #define ctz(x) __builtin_ctz(x) > +#elif defined(__GNUC__) && (defined(__i386__) || defined(__x86_64__)) > + static inline int ctz( unsigned int x ) > + { > + int ret; > + __asm__("bsfl %1, %0" : "=r" (ret) : "r" (x)); > + return ret; > + } > +#else > + #define ctz(x) (ffs(x)-1) > +#endif There's no reason to add this. Just use ffs(). -- Alexandre Julliard julliard(a)winehq.org

4 5

Re: usp10: corrections to ScriptXtoCP
by Nikolay Sivov 17 Mar '11

17 Mar '11

On 3/17/2011 18:20, Aric Stewart wrote: > > It is correct for both LRT and RTL runs > --- > dlls/usp10/tests/usp10.c | 211 > +++++++++++++++++++++++++++++++++------------- > dlls/usp10/usp10.c | 128 +++++++++++++++++++++++----- > 2 files changed, 259 insertions(+), 80 deletions(-) > Maybe it's better to store test data in a table, cause looks like you do similar calls over and over again.

1 0

re: Please ban this spammer from the forum
by Dan Kegel 17 Mar '11

17 Mar '11

Done.

1 0

Please ban this spammer from the forum
by Rosanne DiMesio 17 Mar '11

17 Mar '11

We've had repeated spam posts from user darlingntq9 over the past couple of days. Please ban him/her from the forum. -- Rosanne DiMesio <dimesio(a)earthlink.net>

1 0

Re: [2/2] server: Make sure that CreateFile(CREATE_ALWAYS) overwrites existing file attributes.
by Alexandre Julliard 17 Mar '11

17 Mar '11

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > @@ -1829,6 +1828,11 @@ struct fd *open_fd( struct fd *root, const char *name, int flags, mode_t *mode, > return NULL; > } > ftruncate( fd->unix_fd, 0 ); > + if (flags & O_CREAT) > + { > + fchmod( fd->unix_fd, *mode ); > + fstat( fd->unix_fd, &st ); > + } You'd have to take umask into account. And I'd like to see some tests for this at the ntdll level. > @@ -178,7 +178,7 @@ static struct object *create_file( struct fd *root, const char *nameptr, data_si > switch(create) > { > case FILE_CREATE: flags = O_CREAT | O_EXCL; break; > - case FILE_OVERWRITE_IF: /* FIXME: the difference is whether we trash existing attr or not */ > + case FILE_OVERWRITE_IF: /* the difference is whether we trash existing attr or not */ It's still a FIXME. -- Alexandre Julliard julliard(a)winehq.org

1 0

Solution for "Could not find dependent assembly" error
by Alexandru Bolboaca-Diaconu 17 Mar '11

17 Mar '11

1 0

Re: mshtml,shdocvw: Initialize OLEINPLACEFRAMEINFO.cb for IOleInPlaceSite::GetWindowContext (try 2)
by Dmitry Timoshkov 17 Mar '11

17 Mar '11

Thomas Faber <thfabba(a)gmx.de> wrote: > ip_frame = NULL; > ip_uiwindow = NULL; > + frame_info.cb = sizeof(OLEINPLACEFRAMEINFO); Using sizeof(frame_info) here and in other places instead of sizeof(OLEINPLACEFRAMEINFO) would be better IMHO. -- Dmitry.

1 0

Re: wined3d/device: Avoid repeated calculations of idx and shift in IWineD3DDeviceImpl_MarkStateDirty(). (resend)
by Adam Martinson 16 Mar '11

16 Mar '11

On 03/16/2011 02:24 PM, Alexandre Julliard wrote: > Adam Martinson<amartinson(a)codeweavers.com> writes: > >> Look at any d3d app with oprofile. That function is called >> EVERYWHERE. In my testing this reduces >> IWineD3DDeviceImpl_MarkStateDirty() from 4.8% of wined3d CPU time to >> 3.3%. > What compiler are you using? I don't see any difference here. > GCC 4.4.5, running the 3DMark06 batch size tests.

2 2

re: kernel32: CreateProcessA should not call CreateProcessW directly
by Dan Kegel 16 Mar '11

16 Mar '11

Does that work when compiling with -O3 ? Maybe you need a noinline attribute, http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function-Attribu…

2 1

winmm DriverCallback with 0 CALLBACK_WINDOW
by Joerg-Cyril.Hoehle＠t-systems.com 16 Mar '11

16 Mar '11

Hi, Testbot job #9994 proves that Wine and native differ in their handling of a 0 CALLBACK_WINDOW handle. Wine's PostMessage redirects a 0 handle to PostThreadMessage(currentThreadID()), while native finds no notification on the thread's queue in such a case. (As a consequence, Wine's player thread will send notification messages to itself ...) Alas, the test case does not allow to tell whether the difference in with - winmm:DriverCallback or - whether winmm:midiOutOpen sees the 0 handle and remap to CALLBACK_NULL internally, before ever calling DriverCallback. Likewise, a NULL CALLBACK_FUNCTION does not cause a crash since w2k, but we don't know whether winmm:DriverCallback catches that case (as Wine does nowadays) or whether winmm:wave/midi/mixer/Open remap that to maybe CALLBACK_NULL and proceed. Is there any means to tell the difference, short of writing a real driver with debug output and installing it on a native system, having native DriverCallback called directly? Any ideas? Jörg Höhle BTW, why does winealsa.drv:mixer use a custom callback mechanism instead of the generic DriverCallback that the other winmm drivers use? Historical reasons only?

2 1

lifetime of the MIDI/MIXER/WAVEOPENDESC structure?
by Joerg-Cyril.Hoehle＠t-systems.com 16 Mar '11

16 Mar '11

Hi, MSDN is silent about the lifetime of the MIDI/MIXER/WAVEOPENDESC structure that is deliverred via the W/MODM_OPEN/MXM_OPEN message to the winmm drivers (WAVEOOPENDESC is not even documented for MS-Windows (not CE) anymore). http://msdn.microsoft.com/en-us/library/ff537518%28v=vs.85%29.aspx MIDIOPENDESC IMHO, it would make a lot of sense if the structure remained allocated for the whole lifetime of the open/close cycle, so the driver need not make a copy of it. Is there anybody who knows more about this topic? Thank you, Jörg Höhle

2 1

Re: wined3d/device: Avoid repeated calculations of idx and shift in IWineD3DDeviceImpl_MarkStateDirty(). (resend)
by Alexandre Julliard 16 Mar '11

16 Mar '11

Adam Martinson <amartinson(a)codeweavers.com> writes: > --- > dlls/wined3d/device.c | 17 ++++++++--------- > 1 files changed, 8 insertions(+), 9 deletions(-) You still need to demonstrate that this is an improvement. Compilers are pretty good nowadays, and doing such micro-optimizations at the source level is usually futile. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: d3dx9_36/tests: Replace a malloc() with HeapAlloc()+HeapFree().
by Dylan Smith 16 Mar '11

16 Mar '11

On Wed, Mar 16, 2011 at 3:57 AM, Francois Gouget <fgouget(a)free.fr> wrote: > Any reason why we were not freeing glyphmetrics_float? > No reason, just a mistake on my part.

1 0

Re: windowscodecs: DibDecoder_CreateInstance() is unused so remove it.
by Vincent Povirk 16 Mar '11

16 Mar '11

I think this will be needed by d3dx9, though it hasn't been fully wired up yet.

1 0

Re: kernel32: Implement and test GetVolumePathNamesForVolumeName. (try 2)
by Alexandre Julliard 16 Mar '11

16 Mar '11

Hans Leidekker <hans(a)codeweavers.com> writes: > + for (i = 0; i < output->NumberOfMountPoints; i++) > + { > + if (output->MountPoints[i].DeviceNameOffset) > + { > + const WCHAR *device = (const WCHAR *)((const char *)output + output->MountPoints[i].DeviceNameOffset); > + UINT device_len = output->MountPoints[i].DeviceNameLength / sizeof(WCHAR); > + int drive = map_dos_device( device, device_len ); > + > + if (drive != -1) > + { > + len += 4; > + if (volumepathname && len < buflen) > + { > + path[0] = 'A' + drive; > + path[1] = ':'; > + path[2] = '\\'; > + path[3] = 0; > + path += 4; > + } > + } > + } This won't allow you to support GUID volume names. I think you should query all mount points that match the device, not just the DOS drives. Either way you should use MOUNTMGR_QUERY_POINTS instead of trying every drive one by one. -- Alexandre Julliard julliard(a)winehq.org

1 0

Wine Gecko 1.2.0 released
by Jacek Caban 16 Mar '11

16 Mar '11

Hi all, The new Wine Gecko release is out and already used by Wine git version. Let me conclude shortly what has changed (more detailed updates can be found in my previous mails). It mostly means that you have to download it from Wine Sourceforge [1] and put it into the right directory [2] as always after each Gecko update. One important change is that there is msi file instead of cab file. Also starting with Wine 1.3.15, packages should be updated to depend on the new Gecko. Packagers may consider compiling Gecko themselves as building process no longer has ugly dependencies. Thanks to everyone who helped with the release! BTW, the nice thing is that accidentally we've released just after IE9. That's what I call a quick response :) Cheers, Jacek [1] https://sourceforge.net/projects/wine/files/Wine%20Gecko/1.2.0/ [2] http://wiki.winehq.org/Gecko

2 2

Re: mshtml, shdocvw: Initialize OLEINPLACEFRAMEINFO.cb for IOleInPlaceSite::GetWindowContext
by Jacek Caban 16 Mar '11

16 Mar '11

Hi Thomas, On 3/16/11 11:21 AM, Thomas Faber wrote: > Hi, > > the documentation for the OLEINPLACEFRAMEINFO structure [1] says > that the 'cb' member must be initialized before passing the structure > to IOleInPlaceSite::GetWindowContext (where the rest of it will be > filled). > In addition to the fix, I have updated the corresponding > tests to check this member instead of setting it, and they pass > on Windows as expected [2]. I've used a>= compare for future > version compatibility. Comparing to the exact value is better in this case. If the value will ever change, we want to know that and tests failures will help us notice it. Jacek

1 0

Re: d3dx9_36 [try 3]: Add a few tests for D3DXCreateBox
by Matteo Bruni 16 Mar '11

16 Mar '11

Most of the objections from the previous try still stand: check your whitespaces (whitespace after every comma, whitespaces around operators, whitespace after "if" or "for" keywords), you have to be consistent. Comparing indices doesn't make much sense now that you don't check vertices, I think you should drop that too. You could probably instead check for min and max x, y and z vertices coordinates, verifying that the box has the expected dimensions.

1 0

correct comctl32 implementation
by Andrew Green 16 Mar '11

16 Mar '11

I have been researching how i could implement the gsoc Theming - Implement Wine theming support. Though I'm a bit confused what is wanted. So is the case that completely separate dll's should be written for different versions and be loaded by side-by-side assembly. So you would end up with "comctl32v5.dll","comctl32v6.dll","comctl32v7.dll"? Would these be 3 different code basses or should they be made to share most of there code? >From what I understand uxtheme already loads XP theme files. So would all the work be isolated to creating different versions of comdlg32 and comctl32? Also does wine support side by side assembly? I did a very quick google search and i didn't see anything. I hope I'm not asking too much at once and/or too silly questions.

4 7

Re: [2/4] kernel32: Create a temp file with full access rights.
by Nikolay Sivov 15 Mar '11

15 Mar '11

On 3/15/2011 14:07, Dmitry Timoshkov wrote: > Installer in the bug 26288 requests FILE_ALL_ACCESS permission on a temp file > it just created. > --- > dlls/kernel32/path.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/kernel32/path.c b/dlls/kernel32/path.c > index e72848c..beeb14c 100644 > --- a/dlls/kernel32/path.c > +++ b/dlls/kernel32/path.c > @@ -703,7 +703,7 @@ UINT WINAPI GetTempFileNameW( LPCWSTR path, LPCWSTR prefix, UINT unique, LPWSTR > do > { > sprintfW( p, formatW, unique ); > - handle = CreateFileW( buffer, GENERIC_WRITE, 0, NULL, > + handle = CreateFileW( buffer, GENERIC_READ|GENERIC_WRITE|GENERIC_EXECUTE, 0, NULL, > CREATE_NEW, FILE_ATTRIBUTE_NORMAL, 0 ); > if (handle != INVALID_HANDLE_VALUE) > { /* We created it */ Is it possible to add a test for that?

2 1

Re: mshtml: Report an error when navigation fails
by Piotr Caban 15 Mar '11

15 Mar '11

On 03/14/11 16:59, Piotr Caban wrote: > --- > dlls/mshtml/navigate.c | 110 > ++++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 110 insertions(+), 0 deletions(-) Please ignore this patch. It doesn't work as native do. Cheers, Piotr

1 0

Re: [PATCH 3/3] mshtml: Notify parser about script evaluation
by Marvin 15 Mar '11

15 Mar '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=9959 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

2 1

Re: [4/4] server: Do not limit execute file access to .exe and .com files.
by Dmitry Timoshkov 15 Mar '11

15 Mar '11

Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > - if (len >= 4 && > - (!strcasecmp( name + len - 4, ".exe" ) || !strcasecmp( name + len - 4, ".com" ))) > - { > - if (mode & S_IRUSR) > - mode |= S_IXUSR; > - if (mode & S_IRGRP) > - mode |= S_IXGRP; > - if (mode & S_IROTH) > - mode |= S_IXOTH; > - } > + if (mode & S_IRUSR) > + mode |= S_IXUSR; > + if (mode & S_IRGRP) > + mode |= S_IXGRP; > + if (mode & S_IROTH) > + mode |= S_IXOTH; Please ignore this patch, I need to figure out at which point the exec permissions are dropped. Other patches in the sequence do not depend on this one (and actually are all independent changes). -- Dmitry.

1 0

Two more summer of code ideas
by Dan Kegel 15 Mar '11

15 Mar '11

I added sandboxing and message-mode pipes to http://wiki.winehq.org/SummerOfCode (Yes, it's literally a pipe dream :-) - Dan

2 1

Re: comctl32: Update progress bar only if it moves
by Nikolay Sivov 14 Mar '11

14 Mar '11

On 3/15/2011 00:16, Maarten Lankhorst wrote: > --- > Hopefully helps a little with lord of the rings online installer. It > seems to be fanatical about updating the position, which may result in > too many unnecessary redraws. Patch is wrong. This is inefficient but it's how native control works, it invalidates progress bar no matter what if position is changed. I tested so far PBM_DELTAPOS, PBM_SETPOS, PBM_STEPIT. So this change can break subclass processing for example, when application expects WM_PAINT.

1 0

Re: d3dx9_36: Start effect parsing.
by Henri Verbeet 14 Mar '11

14 Mar '11

2011/3/13 Rico Schüller <kgbricola(a)web.de>: > + if (tag != 0xfeff0901) Looks like the kind of thing you'd want a constant or inline function for. If I were to guess, the feff part means it's an effect (similar to the ffff for d3d9 pixel shaders and the fffe for d3d9 vertex shaders), and 0901 for version 9.1 (also similar to the d3d9 shader version token).

2 2

Re: [PATCH 5/5] shdocvw/tests: Added IShellBrowser, IBrowserService and IDocObjectService existance tests
by Marvin 14 Mar '11

14 Mar '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=9936 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

Re: [PATCH 2/5] shdocvw: Added IShellBrowser interface stub
by Huw Davies 14 Mar '11

14 Mar '11

On Mon, Mar 14, 2011 at 05:03:37PM +0100, Piotr Caban wrote: > +static HRESULT WINAPI ShellBrowser_QueryInterface( > + IShellBrowser* iface, > + REFIID riid, > + void **ppvObject) > +{ > + ShellBrowser *This = impl_from_IShellBrowser(iface); > + *ppvObject = NULL; > + > + if(IsEqualGUID(&IID_IShellBrowser, riid)) > + *ppvObject = &This->IShellBrowser_iface; > + > + if(*ppvObject) { > + TRACE("%p %s %p\n", This, debugstr_guid(riid), ppvObject); > + IUnknown_AddRef((IUnknown*)*ppvObject); > + return S_OK; > + } > + You probably want to add support for IID_IUnknown here too. Huw.

1 0

Re: [PATCH 2/2] winmm: Parse MCI colon notation as in T:MM:SS:F
by Alexandre Julliard 14 Mar '11

14 Mar '11

<Joerg-Cyril.Hoehle(a)t-systems.com> writes: > @@ -975,18 +975,31 @@ static WORD MCI_GetMessage(LPCWSTR lpCmd) > */ > static BOOL MCI_GetDWord(DWORD* data, LPWSTR* ptr) > { > - DWORD val; > - LPWSTR ret; > + DWORD val, total = 0; > + LPWSTR ret, src = *ptr; > + int shift = 0; > > - val = strtoulW(*ptr, &ret, 10); > + colonized: > + val = strtoulW(src, &ret, 10); > + if (ret == src) return FALSE; > > switch (*ret) { > case '\0': break; > + case '\t': > case ' ': ret++; break; > + case ':': { > + if ((val >= 256) || (shift >= 24)) return FALSE; > + total |= val << shift; > + shift += 8; > + src = ret + 1; > + goto colonized; > + } Please use a proper loop, not a goto. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 3/3] winecoreaudio: Fix 64-bits incompatibilities
by Alexandre Julliard 14 Mar '11

14 Mar '11

<Joerg-Cyril.Hoehle(a)t-systems.com> writes: > Dear 64bit users, > > here I turned a couple of DWORD into DWORD_PTR by analogy with other such patches. > I'm using a 32bit bit system where it makes no difference, so please check. > I'm wondering why, if such types make a difference on 64 bit, there > aren't crashes seen on testhq or otherwise reported. Why was this > not spotted earlier? 64-bit is not supported on Mac OS. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Patch hw cursor Wine 1.3.15
by Vitaliy Margolen 14 Mar '11

14 Mar '11

On 03/13/2011 02:31 PM, Valentino Dell'Aica wrote: > Hi I've modified a patch for hw cursor in wine so it can work on wine 1.3.15 You have number of problems with your patch formatting with are outlined here: http://wiki.winehq.org/SubmittingPatches > + hwgl = getenv("WINE_CURSOR"); Wine uses registry for things like this. It should be a static variable set once. > + WINE_FIXME("Out of memory.\n"); For wine libraries this should be "FIXME". Also just printing fixme isn't a good error handling. And can you explain why for every button press/release you creating/removing cursor? This is highly inefficient. And what are you trying to archive with it anyway? Vitaliy.

3 2

GSOC CMD parser.
by Joel Teichroeb 14 Mar '11

14 Mar '11

I'm quite interested in the idea on the wiki of improving the CMD parser and fixing the bugs. I brought this up in the IRC and it was mentioned that there was some discussion of using bison/flex for parsing. I don't think that would be feasible for me to do in just three months but I'm wondering if that is the direction that is wanted for the CMD parser. It does not seem like there are enough issues with the current implementation to justify scrapping the current parser. The way I would go about this task would be to fix all the outstanding bugs, and add test cases for them, then find as many other bugs using and batch scripts from other open source projects. Thoughts and comments would be wonderful. Joel Teichroeb.

2 1

Re: riched20/tests: Beginnings of EM_SETMARGINS test
by Marvin 14 Mar '11

14 Mar '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=9910 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

riched20/tests: Beginnings of EM_SETMARGINS test. This patch is released into the Public Domain under the requirements of the LGPL version 2.1 or later. Released by James McKenzie jjmckenzie51@gmail.com
by James McKenzie 13 Mar '11

13 Mar '11

Just checking if gmail has a 'wrapping' problem or if this will actually go through. riched20/tests: Beginnings of EM_SETMARGINS test. This patch is released into the Public Domain under the requirements of the LGPL version 2.1 or later. Released by James McKenzie jjmckenzie51(a)gmail.com --- dlls/riched20/tests/editor.c | 215 ++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 215 insertions(+), 0 deletions(-) diff --git a/dlls/riched20/tests/editor.c b/dlls/riched20/tests/editor.c index 7a4e032..31f3bdc 100644 --- a/dlls/riched20/tests/editor.c +++ b/dlls/riched20/tests/editor.c @@ -7034,6 +7034,220 @@ static void test_dialogmode(void) DestroyWindow(hwParent); } +static INT CALLBACK is_truetype_font_installed_proc(const LOGFONT *elf, const TEXTMETRIC *ntm, DWORD type, LPARAM lParam) +{ + if (type != TRUETYPE_FONTTYPE) return 1; + + return 0; +} + +static BOOL is_truetype_font_installed(const char *name) +{ + HDC hdc = GetDC(0); + BOOL ret = FALSE; + + if (!EnumFontFamiliesA(hdc, name, is_truetype_font_installed_proc, 0)) + ret = TRUE; + + ReleaseDC(0, hdc); + return ret; +} + +static INT CALLBACK is_font_installed_proc(const LOGFONT *elf, const TEXTMETRIC *ntm, DWORD type, LPARAM lParam) +{ + return 0; +} + +static BOOL is_font_installed(const char *name) +{ + HDC hdc = GetDC(0); + BOOL ret = FALSE; + + if(!EnumFontFamiliesA(hdc, name, is_font_installed_proc, 0)) + ret = TRUE; + + ReleaseDC(0, hdc); + return ret; +} + +static void test_em_setmargins(void) +{ + HWND hwndRichEdit; + RECT old_rect, new_rect; + + HDC hDC; + LOGFONTA lfA; + UINT ret; + int ry, i, j, k; + + HFONT testFont1A, hDC_font; + + /* Add various window sizes for USEFONTINFO tests */ + static const struct rect_parameters + { + int start_left, start_top, end_right, end_bottom; + } rect_param[] = + { + { 0, 0, 400, 80 }, + }; + + /* data for ANSI font tests */ + static const struct font_margins_data + { + const char face_name[LF_FACESIZE]; + int weight, height, ascent, descent, int_leading, ext_leading; + int ave_char_width, max_char_width, dpi; + } fmd[] = + { + { "Courier", FW_NORMAL, 13, 11, 2, 0, 0, 8, 8, 96 }, + { "System", FW_BOLD, 16, 13, 3, 3, 0, 7, 14, 96 }, + { "Arial", FW_NORMAL, 16, 13, 3, 3, 0, 6, 35, 96, }, + }; + + /* Test data for margins testing */ + static const struct margin_test_data + { + int left_margin, right_margin; + DWORD margin_type; + } mmt [] = + { + { 0, 0, EC_LEFTMARGIN }, /*Clear all margin settings */ + /*Left Margin tests*/ + { 10, 0, EC_LEFTMARGIN }, /*Set Left Margin to 10 */ + { EC_USEFONTINFO, 0, EC_LEFTMARGIN }, /*Test EC_USEFONTINFO as lparam with EC_LEFTMARGIN */ + { 0, 0, EC_LEFTMARGIN }, /*Clear margins for Right Margin tests */ + /*EC_USEFONTINFO as lpararm tests */ + { 10, 10, EC_USEFONTINFO }, /*Set margins to 10 with EC_USEFONTINFO, should return zero */ + { 0, EC_USEFONTINFO, EC_USEFONTINFO }, /*Set Right Margin to EC_USEFONTINFO under EC_USEFONTINFO, should + return zero except with TrueType Fonts, this should be the lagging spacing value for large fonts and large + edit windows*/ + { EC_USEFONTINFO, 0, EC_USEFONTINFO }, /*Set Left Margin to EC_USEFONTINFO under EC_USEFONTINFO, should return + zero except with TrueType Fonts, this should be the leading spacing value for large fonts and large edit + windows*/ + { EC_USEFONTINFO, EC_USEFONTINFO, EC_USEFONTINFO }, /*Set both margins to EC_USEFONTINFO under EC_USEFONTINFO, + should have same results for both left and right tests above */ + { 0, 0, EC_USEFONTINFO }, /*Clear Margins, if set */ + }; + + /* Run tests for number of rectangles */ + for ( k=0; k< (sizeof(rect_param)/sizeof(rect_param[0])); k++) + { + hwndRichEdit = CreateWindow(RICHEDIT_CLASS, NULL, ES_MULTILINE|WS_POPUP|WS_HSCROLL|WS_VSCROLL|WS_VISIBLE, + rect_param[k].start_left, rect_param[k].start_top, rect_param[k].end_right, + rect_param[k].end_bottom, NULL, NULL, hmoduleRichEdit, NULL); + ok(hwndRichEdit != NULL, "Error creating Richedit Window in EM_SETMARGINS test. error received: %d\n", + (int) GetLastError()); + if (!hwndRichEdit) + { + return; + } + + hDC = GetDC(hwndRichEdit); + ok (hDC != NULL, "Creation of hdc failed.\n"); + if (!hDC) + { + DestroyWindow(hwndRichEdit); + return; + } + + ry = GetDeviceCaps(hDC, LOGPIXELSY); + + ZeroMemory(&lfA, sizeof(lfA)); + ZeroMemory(&testFont1A, sizeof(HFONT)); + /*Initialize rect variable to be the size of the entire richedit window */ + old_rect.left = rect_param[k].start_left; + old_rect.right = rect_param[k].end_right; + old_rect.top = rect_param[k].start_top; + old_rect.bottom = rect_param[k].end_bottom; + SendMessageA(hwndRichEdit, EM_SETRECT, 0, (LPARAM)&old_rect); + SendMessageA(hwndRichEdit, EM_GETRECT, 0, (LPARAM)&old_rect); + ok (rect_param[k].start_left == old_rect.left , "Richedit control window not created correctly. Canceling " + "test for window size of %d by %d\n", rect_param[k].end_right, rect_param[k].end_bottom); + if (rect_param[k].start_left != old_rect.left) continue; + + /* Run tests for number of ANSI fonts */ + for (i = 0; i < sizeof(fmd)/sizeof(fmd[0]); i++) + { + strcpy(lfA.lfFaceName, fmd[i].face_name); + lfA.lfHeight = fmd[i].height; + lfA.lfCharSet = DEFAULT_CHARSET; + lfA.lfWeight = fmd[i].weight; + ret = is_font_installed(lfA.lfFaceName); + /* If font cannot cannot be found, skip rest of tests */ + ok (ret != 0, "Font not found, test results are not predictable. Aborting test for font %s\n", + fmd[i].face_name); + if (ret) continue; + ret = is_truetype_font_installed(lfA.lfFaceName); + if (lfA.lfFaceName == "Arial") + { + ok (ret == 0, "Truetype font emulated, test results will not be consistent with Windows!\n"); + if (!ret) continue; + } + + testFont1A = CreateFontIndirectA (&lfA); + hDC_font = SelectObject(hDC, testFont1A); + /* looping through the all of the tests */ + for (j=0; j < sizeof (mmt)/sizeof (mmt[1]); j++) + { + SendMessageA(hwndRichEdit, EM_SETMARGINS, mmt[j].margin_type, MAKELONG (mmt[j].left_margin, + mmt[j].right_margin)); + ret=SendMessageA(hwndRichEdit, EM_GETRECT, 0, (LPARAM)&new_rect); + ok (ret == 0, "An error occurred getting new margins\n"); + switch (mmt[j].margin_type) + { + case EC_USEFONTINFO : + /* Per several web sources, using the EC_USEFONTINFO with a TrueType font should result in the + following: The Left Margin should be set to the 'C' value, that is the value used to set white + space after a character and the next printed character. This is also called leading spacing. + The Right Margin should be set to the 'A' value, that is the value use to set white space to the + current position before drawing the next character. This is also called lagging spacing. + During testing could not find a case where this was true for any version of riched20.dll */ + { + ok(new_rect.right == old_rect.right, "The right border moved in EC_USEFONTINFO Left/Right " + "margin change test to %d for font %s(%d)\n", old_rect.right - new_rect.right, + fmd[i].face_name, fmd[i].height); + ok(new_rect.left == old_rect.left, "The left border was moved in EC_USEFONTINFO Left/Right Margin " + "change test to %d for font %s(%d).\n", old_rect.left - new_rect.left, fmd[i].face_name, + fmd[i].height); + } + break; + case EC_LEFTMARGIN : + if (mmt[j].left_margin == 0 ) + { + ok(new_rect.left == old_rect.left, "The left border moved %d in the Left Margin " + "Zero test for font %s(%d).\n", new_rect.left - old_rect.left, fmd[i].face_name, fmd[i].height); + } + else + { + todo_wine { + ok(new_rect.left == old_rect.left + mmt[j].left_margin, "The left border moved %d and should be " + "%d in the Left margin change test for font %s(%d).\n", new_rect.left - old_rect.left, + mmt[j].left_margin, fmd[i].face_name, fmd[i].height); + } + } + ok(new_rect.right == old_rect.right, "The right border was moved %d in Left Margin change test for " + "font %s(%d).\n", new_rect.right - old_rect.right, fmd[i].face_name, fmd[i].height); + break; + case EC_LEFTMARGIN | EC_RIGHTMARGIN : + case EC_RIGHTMARGIN : + default: /* fall through if there is a data error or new margin type test */ + ok (0 == 1, "Check %s %d %d 0x%x\n", fmd[i].face_name, fmd[i].height, fmd[i].dpi, mmt[j].margin_type); + } + /* test if top or bottom margin moved. Test should not disturb them */ + ok(new_rect.top == old_rect.top, "The top border moved %d in the test.\n", + new_rect.top - old_rect.top); + ok(new_rect.bottom == old_rect.bottom, "The bottom border moved %d in the test\n", + new_rect.bottom - old_rect.bottom); + } + SelectObject(hDC, hDC_font); + DeleteObject(testFont1A); + } + DeleteObject(testFont1A); + ReleaseDC (hwndRichEdit, hDC); + DestroyWindow (hwndRichEdit); + } +} + START_TEST( editor ) { BOOL ret; @@ -7090,6 +7304,7 @@ START_TEST( editor ) test_WM_GETDLGCODE(); test_zoom(); test_dialogmode(); + test_em_setmargins(); /* Set the environment variable WINETEST_RICHED20 to keep windows * responsive and open for 30 seconds. This is useful for debugging. -- 1.7.4

1 0

Wine announce on the website shows weird content
by Divaret Mathieu 13 Mar '11

13 Mar '11

Hello, I just wanted to tell you that the page on http://www.winehq.org/announce/ is bugged. It now shows git historic and curious non-sense links. Sorry to disturb if you already know. Continue the good job. Bye.

2 1

Re: programs/dxdiag: beginnings of support for /t option (try 2)
by Vitaliy Margolen 13 Mar '11

13 Mar '11

On 03/12/2011 09:55 PM, Drew Goodwin wrote: > Fixed issues pointed out by Andrew Nguyen and Henri Verbeet. > There are still number of things that needs fixing: > +static BOOL PrepareFilename(WCHAR* filename, const enum OUTFORMAT format); > +static void OutputPlainFile(FILE * hFile, DxDiag_Root g_dxdiagcom_root); > +static void OutputSectionHeading(int section, FILE * hFile); > +static void OutputNewline(FILE * hFile); > +static void OutputWString(FILE * hFile, WCHAR * buffer); > +static void OutputPlainPropertyTitle(int property, FILE * hFile); > +static void OutputPlainProperty(int property, WCHAR * value, FILE * hFile); Please rearrange your functions so you don't need forward declarations. > + WideCharToMultiByte(CP_UTF8, 0, filename, -1, utf8Filename, > + MAX_STRING_LEN, NULL, NULL); Why utf8? Native creates plain text file which isn't a utf8. Haven't checked on different languages, but I think it would use some windows codepage instead of utf8. > + LoadStringW(NULL, STRING_ERROR_OPENING_FILE, messageText, > + MAX_STRING_LEN); Please don't split file on 80-character boundary, all modern widescreen displays can comfortably display 100+ characters in huge font. > + else if (format == XML) > + WINE_FIXME("/x unimplemented\n"); If it's not implemented, please remove all related code and add it back with xml implementation. > + /* trailing periods are not allowed in windows filenames */ > + /* some characters not allowed in windows filenames */ You shouldn't need to perform these checks here. Kernel/ntdll already do all of that. > +static void OutputWString(FILE * hFile, WCHAR * buffer) > +{ > + utf8BufferSize = WideCharToMultiByte(CP_UTF8, 0, buffer, -1, NULL, 0, NULL, NULL); > + utf8Buffer = HeapAlloc(GetProcessHeap(), 0, utf8BufferSize); This has really big overhead. Please use stack buffer instead and only do allocation when the buffer it too small. > +++ b/programs/dxdiag/cmdline.h > +BOOL OutputToFile(WCHAR * filename, const enum OUTFORMAT format, DxDiag_Root g_dxdiagcom_root); You don't need 2 header files for 3 external functions. Just forward declare them in the file that uses them. Or better yet put it all into the same file. And last but not the least, you might want to fix dxdiagn.dll to return a bit more for system info then this: ------------------- System Information ------------------- Time of this report: Machine name: Operating System: Language: System Manufacturer: System Model: BIOS: Processor: Memory: Page File: Windows Dir: C:\windows DirectX Version: = "DirectX 9.0c (4.09.0000.0904) DX Setup Parameters: Vitaliy

1 0

Re: advapi32/tests: Add some skips
by Nikolay Sivov 13 Mar '11

13 Mar '11

> to quicker see on which platforms it doesn't work > --- > dlls/advapi32/security.c | 2 +- > dlls/advapi32/tests/registry.c | 11 ++++++++--- > 2 files changed, 9 insertions(+), 4 deletions(-) > > diff --git a/dlls/advapi32/security.c b/dlls/advapi32/security.c > index 1aa7990..4ee5c7b 100644 > --- a/dlls/advapi32/security.c > +++ b/dlls/advapi32/security.c > @@ -2445,7 +2445,7 @@ AccessCheck( > BOOL ret = set_ntstatus( NtAccessCheck(SecurityDescriptor, ClientToken, DesiredAccess, > GenericMapping, PrivilegeSet, PrivilegeSetLength, > GrantedAccess,&access_status) ); > - if (ret) *AccessStatus = set_ntstatus( access_status ); > + if (ret) *AccessStatus = 1;//set_ntstatus( access_status ); > return ret; > } ?

2 1

re: GSOC CMD parser.
by Dan Kegel 13 Mar '11

13 Mar '11

Joel wrote: > ... > It does not seem like there are enough issues with the current > implementation to justify scrapping the current parser. The existing parser is pretty hard to understand and extend. We're probably a few man-months away from the point of diminishing returns, and I'm sure there are some bugs that can't be fixed without a rewrite. Have you read it enough to understand it yet? ( see also http://kegel.com/wine/sweng/2010/#parser ) > The way I would go about this task would be to fix all > the outstanding bugs, and add test cases for them ... Incremental improvements to the current parser would still be welcome and useful. For instance, supporting cmd /a ( see http://bugs.winehq.org/show_bug.cgi?id=21174 for someone's draft patch ). - Dan

1 0

Re: winex11: Quite a noisy FIXME
by Vitaliy Margolen 13 Mar '11

13 Mar '11

On 03/12/2011 12:10 PM, André Hentschel wrote: > Yeah i know the fixme has good reasons, but still it shouldn't mess on console. You shouldn't use broken Wine. Anything that indicates a broken Wine, especially due to missing dependencies during compile, should not be hidden. Vitaliy.

2 1

Help: afxctl.h missing
by Jaytirth S. Khairatkar 13 Mar '11

13 Mar '11

Hello, I am getting the following error when I am trying to compile in Winelib error: afxctl.h: No such file or directory How should I resolve this? thanks and regards Jaytirth Khairatkar -- Jaytirth S. Khairatkar System Architecture and Algorithms Mobile: 9223529523

2 1

Re: winex11: Quite a noisy FIXME
by Andrew Nguyen 12 Mar '11

12 Mar '11

On 03/12/2011 01:10 PM, André Hentschel wrote: > Yeah i know the fixme has good reasons, but still it shouldn't mess on console. > --- > dlls/winex11.drv/xrender.c | 4 +++- > 1 files changed, 3 insertions(+), 1 deletions(-) > > diff --git a/dlls/winex11.drv/xrender.c b/dlls/winex11.drv/xrender.c > index fde0b91..70fd5e2 100644 > --- a/dlls/winex11.drv/xrender.c > +++ b/dlls/winex11.drv/xrender.c > @@ -2435,7 +2435,9 @@ void X11DRV_XRender_UpdateDrawable(X11DRV_PDEVICE *physDev) > BOOL XRender_AlphaBlend( X11DRV_PDEVICE *devDst, X11DRV_PDEVICE *devSrc, > struct bitblt_coords *dst, struct bitblt_coords *src, BLENDFUNCTION blendfn ) > { > - FIXME("not supported - XRENDER headers were missing at compile time\n"); > + static int once; > + if(!once) > + FIXME("not supported - XRENDER headers were missing at compile time\n"); > return FALSE; > } > Since the static variable once is never incremented, the if condition is practically a no-op.

1 0

Re: Make sure This->bsc.doc will be initialized while opening a zero byte html file, fix bug 25999 . modified: dlls/mshtml/navigate.c
by Jacek Caban 12 Mar '11

12 Mar '11

Hi Zuno, I don't think that's the right place for the fix. What's the exact problem you're trying to fix? AFAICS the only important difference your patch makes is that on_start_nsrequest will be always called in read_stream_data (possibly many times), but it's also called in on_stop_nsrequest if no data was read. Jacek

3 2

Re: inetcpl.cpl: Update French translation
by Nicolas Le Cam 12 Mar '11

12 Mar '11

Hi Frédéric, Le 12 mars 2011 09:09, Frédéric Delanoy <frederic.delanoy(a)gmail.com> a écrit : > --- > dlls/inetcpl.cpl/cpl_Fr.rc | 12 ++++++------ > 1 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/dlls/inetcpl.cpl/cpl_Fr.rc b/dlls/inetcpl.cpl/cpl_Fr.rc > index 54d19e9..1244ff6 100644 > --- a/dlls/inetcpl.cpl/cpl_Fr.rc > +++ b/dlls/inetcpl.cpl/cpl_Fr.rc > @@ -35,17 +35,17 @@ CAPTION "Général" > BEGIN > > GROUPBOX " Page d'accueil ", IDC_STATIC, 4, 4, 312, 52 > - LTEXT "Vous pouvez spécifier une adresse à utiliser comme page > d'accueil :", > + LTEXT "Vous pouvez spécifier l'adresse à utiliser comme page > d'accueil :", > IDC_STATIC, 68, 10, 242, 10 > EDITTEXT IDC_HOME_EDIT, 68, 22, 242, 12, WS_VISIBLE | ES_AUTOHSCROLL > PUSHBUTTON "Page &courante", IDC_HOME_CURRENT, 68, 36, 77, 14 > PUSHBUTTON "Page par &défaut", IDC_HOME_DEFAULT, 151, 36, 77, 14 > PUSHBUTTON "Page &blanche", IDC_HOME_BLANK, 233, 36, 77, 14 > - GROUPBOX " Browsing history ", IDC_STATIC, 4, 60, 312, 46 > - LTEXT "You can delete cached pages, cookies and other data.", > - IDC_STATIC, 58, 72, 252, 10 > - PUSHBUTTON "Delete &files...", IDC_HISTORY_DELETE, 144, 86, 80, 14 > - PUSHBUTTON "&Settings...", IDC_HISTORY_SETTINGS, 230, 86, 80, 14 > + GROUPBOX " Historique de navigation ", IDC_STATIC, 4, 60, 312, 46 > + LTEXT "Vous pouvez effacer les pages en cache, les cookies et > d'autres données.", > + IDC_STATIC, 68, 72, 242, 10 > "Vous pouvez effacer les pages en cache, les cookies et autres données." should be better. > + PUSHBUTTON "&Effacer les fichiers...", IDC_HISTORY_DELETE, 151, 86, > 77, 14 > + PUSHBUTTON "&Paramètres...", IDC_HISTORY_SETTINGS, 233, 86, 77, 14 > > END > > -- > 1.7.4.1 > > -- Nicolas Le Cam

1 0

Re: wineport: Add fast builtin & asm versions of ffs() + ctz() where supported.
by Alexandre Julliard 11 Mar '11

11 Mar '11

Adam Martinson <amartinson(a)codeweavers.com> writes: > @@ -236,7 +241,40 @@ extern int getopt_long_only (int ___argc, char *const *___argv, > #endif /* HAVE_GETOPT_LONG */ > > #ifndef HAVE_FFS > -int ffs( int x ); > + #if defined(__i386__) || defined(__x86_64__) > + #define HAVE_FFS > + static inline int ffs( int x ) > + { > + if (!x) > + { > + return 0; > + } > + else > + { > + int ret; > + __asm__("bsfl %1, %0; incl %0" : "=r" (ret) : "r" (x)); > + return ret; > + } > + } > + #elif defined(__GNUC__) && GCC_VERSION >= 29503 > + #define HAVE_FFS > + #define ffs(x) __builtin_ffs(x) > + #else > + int ffs( int x ); > + #endif > +#endif You'd have to show benchmarks to prove that this complexity is necessary. Given that ffs() should already be inlined on all decent platforms, I doubt you'd be able to demonstrate a difference (if anything, your version would be slower because of the extra increment). -- Alexandre Julliard julliard(a)winehq.org

3 2

Re: wineport: Use a lookup table to make our slow ffs() a bit faster.
by Henri Verbeet 11 Mar '11

11 Mar '11

Something like the following may be faster: static const int bit_pos[] = { 0x00, 0x01, 0x0e, 0x02, 0x0f, 0x1b, 0x12, 0x03, 0x1e, 0x10, 0x1c, 0x16, 0x18, 0x13, 0x0a, 0x04, 0x1f, 0x0d, 0x1a, 0x11, 0x1d, 0x15, 0x17, 0x09, 0x0c, 0x19, 0x14, 0x08, 0x0b, 0x07, 0x06, 0x05, }; const unsigned int c = 0x7dc4d65; return bit_pos[((x & -x) * c) >> 27]; I'd expect that mostly due to eliminating the branches and the implicit shift & mask operations in something like "y.c[1]".

3 2

Re: wined3d/context: Remove a trivial call to context_validate_onscreen_formats() in context_apply_blit_state().
by Henri Verbeet 11 Mar '11

11 Mar '11

On 10 March 2011 20:22, Adam Martinson <amartinson(a)codeweavers.com> wrote: > - context_validate_onscreen_formats(device, context, NULL); > + /* It's silly to call context_validate_onscreen_formats() with a NULL depth_stencil. */ Sigh. I've asked you a very simple question about the performance impact of these changes *twice* now, and you ignored the question both times. Unless you have evidence that the compiler fails to eliminate the call by itself, and this actually makes any kind of difference, consistency is more important. The same goes for the IWineD3DDeviceImpl_MarkStateDirty() change, though at least in that case there's somewhat of a remote chance of it making a difference.

2 1

Re: include: Add rmxftmpl.h header.
by Alexandre Julliard 11 Mar '11

11 Mar '11

Dylan Smith <dylan.ah.smith(a)gmail.com> writes: > Manually parsed a hexdump of D3DRM_XTEMPLATES from the native header; > comments to show the corresponding text encoding. I used a test > application to dump D3DRM_XTEMPLATES with this header and the native > header to confirm that this header binary compatible with the native one. That stuff needs to be generated from source, you can't just copy the native header contents. -- Alexandre Julliard julliard(a)winehq.org

2 1

re: wineport: Use a lookup table to make our slow ffs() a bit faster.
by Dan Kegel 11 Mar '11

11 Mar '11

Do you actually have a system that doesn't have HAVE_FFS set? On my machine, int main(int argc, char **argv) { return ffs(argc); } compiles to pushl %ebp movl %esp, %ebp movl $-1, %edx bsfl 8(%ebp), %eax cmove %edx, %eax addl $1, %eax popl %ebp ret which is probably pretty fast. Large lookup tables can dirty the L1 cache and slow other things down. See also http://stackoverflow.com/questions/757059/position-of-least-significant-bit…

2 1

Re: [PATCH 1/6] user32: Add get/release routines for accessing cursor frames.
by Alexandre Julliard 11 Mar '11

11 Mar '11

Erich Hoover <ehoover(a)mines.edu> writes: > @@ -135,6 +139,16 @@ static void release_icon_ptr( HICON handle, struct cursoricon_object *ptr ) > release_user_handle_ptr( ptr ); > } > > +struct static_cursoricon_object *get_icon_data( struct cursoricon_object *obj, int istep ) > +{ > + return &obj->frames[istep]; > +} > + > +void release_icon_data( struct cursoricon_object *obj, int istep, struct static_cursoricon_object *icon_data ) > +{ > + /* placeholder */ > +} I find your data structures confusing. You add a concept of icon_data separate from icon_ptr, but it doesn't correspond to the data structures, there's no such thing as an icon_data. There should be a way of making this clearer. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: programs/dxdiag: beginnings of support for /t option
by Henri Verbeet 11 Mar '11

11 Mar '11

On 10 March 2011 20:35, Drew Goodwin <drew(a)drewgoodwin.com> wrote: > + length = MultiByteToWideChar(0, 0, name, -1, NULL, 0)+1; > + { > + /* Allocate on the stack */ > + WCHAR nameW[length]; Oh, and variable length arrays are a C99 feature, Wine tries to mostly stick to C89.

2 1

New winetricks 20110311b: winetricks is dead, long live winetricks
by Dan Kegel 11 Mar '11

11 Mar '11

winetricks-20110311b is now released. Changes since winetricks-20110123 (for anyone who has not been using the alpha versions): - manages multiple wineprefixes - apps are now installed into separate wineprefixes by default - gui now split into separate pages for games, benchmarks, apps, dlls, fonts - gui now shows approximate disk requirement and install times - gui now lets you pick silent installation mode - apps that are broken (e.g. have drm that wine can't handle) are now hidden by default, gui has a button to reveal them - 70 games added, including Dragon Age II demo, Starcraft II demo, Mass Effect 2, and Mass Effect 2 demo - many updates and bugfixes Changes since winetricks-alpha-20110310: - mdac25, mdac27 removed, as downloads no longer available - mdac28: updated to sp1 - sizes/times in gui updated. (Most show download + install time; a future release will show just install time.) For bug tracker, mailing lists, and wiki, see http://winetricks.org Download url: http://winetricks.org/winetricks

1 0

re: links down
by Dan Kegel 11 Mar '11

11 Mar '11

Looks like 2.8 sp1 is still up, though: http://www.microsoft.com/downloads/en/details.aspx?familyid=78cac895-efc2-4… I'll update winetricks, thanks. (And I'll put together a fast link checker for winetricks; doing a full run with an empty cache takes too long to be a good way of noticing broken links.) Wish I'd noticed this sooner!

1 0

Re: programs/dxdiag: beginnings of support for /t option
by Henri Verbeet 11 Mar '11

11 Mar '11

On 10 March 2011 20:35, Drew Goodwin <drew(a)drewgoodwin.com> wrote: > I'm a CS student at UCLA. I and some classmates are adding features to > wine's dxdiag. Here's the first patch, with code by Steve Feng, Andrew > Freer, and myself, properly copyrighted and licensed under the LGPL. Once > this is accepted, we will send a series of patches to support the remaining > sections in the /t option and the /x option, and add a working gui. > Just some random comments, this is by no means a proper review: > -EXTRADEFS = -DWINE_NO_UNICODE_MACROS > +EXTRADEFS = -DWINE_NO_UNICODE_MACROS -D__WINE__ What do you need __WINE__ for? > +IMPORTS = advapi32 comdlg32 comctl32 d3d9 d3dx9 ddraw dsound dxguid gdi32 kernel32 ole32 oleaut32 shell32 user32 winmm > + That's a lot of imports, do you really need all of those in this patch? > +HINSTANCE g_hinstance; The way you're using this, that's just a slightly odd way to write "NULL". > + sysinfo = malloc(sizeof(DxDiag_SystemInfo)); You should typically use HeapAlloc() for memory allocation in Wine, except for rare cases where you pass the result to a library function that free()'s it. You also leak the sysinfo, but perhaps that's ok as long as you exit right after being done with it. The "g_dxdiagcom_root" global isn't very useful, just pass it to OutputPlainFile() directly.

1 0

Re: cryptnet/tests: Partially revert commit de6e33f306a3b1b424ad1a9c41e85d3692ef9e4d
by Joris Huizer 11 Mar '11

11 Mar '11

Hello, I found a small (copy/paste) mistake in this patch: - /* w2k3,XP, newer w2k: CRYPT_E_NO_MATCH */ - ok(!ret && (GetLastError() == CRYPT_E_NO_MATCH), + /* w2k3,XP, newer w2k: CRYPT_E_NO_MATCH, older w2k: CRYPT_E_ASN1_BADTAG */ + ok(!ret && (GetLastError() == CRYPT_E_NO_MATCH || + broken(GetLastError() == CRYPT_E_NO_MATCH)), The comment indicates the alternative error, but the actual code doesn't check that one HTH, Joris

1 0

Re: wininet(4/7): Implement commiting a url cache entry that already existed (try 2)
by Alexandre Julliard 11 Mar '11

11 Mar '11

Juan Lang <juan.lang(a)gmail.com> writes: > With the previous patches applied, this no longer fails for me on > Alexandre's apparently corrupt index.dat. Note that the index.dat I sent you was created from scratch, by running the wininet tests in an empty wineprefix. So if it's really corrupt it means wininet has corrupted it. It would probably be a good idea to fix this first. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: msxml3: Ignore XML Property ResolveExternals
by Nikolay Sivov 11 Mar '11

11 Mar '11

On 3/11/2011 13:46, Alistair Leslie-Hughes wrote: > Hi, > > > Changelog: > msxml3: Ignore XML Property ResolveExternals Please correct naming: static const WCHAR PropertyNewParserW[] = {'N','e','w','P','a','r','s','e','r',0}; static const WCHAR PropValueXPathW[] = {'X','P','a','t','h',0}; static const WCHAR PropValueXSLPatternW[] = {'X','S','L','P','a','t','t','e','r','n',0}; +static const WCHAR PropValueResolveExternalsW[] = {'R','e','s','o','l','v','e','E','x','t','e','r','n','a','l','s',0}; It's not a value, it's a property with boolean value, so it's PropertyResolveExternalsW. > > > Best Regards > Alistair Leslie-Hughes

1 0

Re: wininet(7/7): Delete the cache file when it's no longer referenced (resend)
by Marvin 11 Mar '11

11 Mar '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=9868 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: wininet(6/7): Delete cache entries when their use count reaches 0
by Marvin 11 Mar '11

11 Mar '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=9867 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: [PATCH 6/6] user32: Add support for sequence-based animated cursors.
by Henri Verbeet 11 Mar '11

11 Mar '11

On 10 March 2011 07:42, Erich Hoover <ehoover(a)mines.edu> wrote: > @@ -940,6 +954,7 @@ done: > #define ANI_seq__ID RIFF_FOURCC('s', 'e', 'q', ' ') > #define ANI_fram_ID RIFF_FOURCC('f', 'r', 'a', 'm') > #define ANI_rate_ID RIFF_FOURCC('r', 'a', 't', 'e') > +#define ANI_seq_ID RIFF_FOURCC('s', 'e', 'q', ' ') Just happened to notice this, but I doubt there's much point in having two different defines for sequence chunks.

2 1

Re: [4/4] d3d8: Test depth stencil size mismatches
by Henri Verbeet 10 Mar '11

10 Mar '11

On 10 March 2011 22:58, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -264,6 +264,8 @@ struct IDirect3DSurface8Impl > > /* If set forward refcounting to this object */ > IUnknown *forwardReference; > + > + UINT width, height; > }; You could just ask wined3d for the surface size.

2 1

Re: [PATCH 3/4] mshtml: Added IHTMLPrivateWindow_GetAddressBarUrl implementation
by Marvin 10 Mar '11

10 Mar '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=9859 Your paranoid android. === WXPPROSP3 (32 bit htmldoc) === htmldoc.c:3564: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3526: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3557: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3564: Test failed: unexpected address bar url: L"about:replace" === WVISTAADM (32 bit htmldoc) === htmldoc.c:3564: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3526: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3557: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3564: Test failed: unexpected address bar url: L"about:replace" === W7PRO (32 bit htmldoc) === htmldoc.c:3564: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3526: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3557: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3564: Test failed: unexpected address bar url: L"about:replace" === W7PROX64 (32 bit htmldoc) === htmldoc.c:3564: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3526: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3557: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3564: Test failed: unexpected address bar url: L"about:replace" === W7PROX64 (64 bit htmldoc) === htmldoc.c:3564: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3526: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3557: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3564: Test failed: unexpected address bar url: L"about:replace"

1 0

Wine Gecko 1.2.0 RC1
by Jacek Caban 10 Mar '11

10 Mar '11

Hi all, I'm happy to announce that the new update of Wine Gecko packages is almost there. It took long time since last beta to get to RC point from beta, not only because of many changes on our side, but mostly because of delays in Mozilla release process. We've done everything I've hoped to be done (and even more than I expected). I'm also happy that it was much better tested than previous times (mostly because they were available for so long). So far I'm aware of only one regression in Outlook that probably won't block the release because it seems to be a problem on Wine side (I can't be sure as I wasn't able to reproduce it so far). If I've missed something, please let me know. I'd appreciate help with testing. Builds are on Sourceforge [1]. To use it, just grab MSI files and put it into the directory where usually CAB files would go and apply the attached patch. Please let me know about any regression you notice. * CHANGES * - The CAB file is created without external dependencies Thanks to Alexandre for cabinet work. - We use MSI installers Thanks to Hans for winemsibuilder and preparing scripts that made it possible. - winedbg works with Gecko debug builds Thanks to Eric for many fixes to dbghelp/winedbg. Once he will merge his work to Wine, we will be able to use winedbg for comfortable Gecko debugging - win64 build now works - a few bug fixes - I've got rid of some Gecko ugly things like using API hooks * FURTHER PLANS * Firefox 4 RC1 came out yesterday and is expected to be the final build (so far nothing that would require another RC was found). Mozilla estimates release to be out in a week or two. I'm tempted to not wait and release early next week (so that it will live in Git for at least a few days before Wine release), but we will see how it will work. If we'd find any new blocker, it would most likely mean that we will release a week later. * FOR PACKAGERS * If you are interested in building the packager yourself from sources (so far I've heard about Debian and Fedora attempts to do so), everything is ready to support it now. Building instructions changed a bit after switching to use MSI files, but I've made things as easy as possible. Building the package itself is a matter of invoking one script with proper arguments. The tricky part is that Wine is needed for building, so we get circural build-time dependency. The script, however, makes sure that Wine doesn't need Gecko during compiling Gecko, so it shouldn't be a big problem to handle. Also, unless you manually set WINEPREFIX, the script created a temporary wineprefix directory, so there is nothing to worry if your ~/.wine is in broken state. It can also use Wine from its build dir if you set WINE_BUILD_DIR environment variable. Please let me know if there are more problems than need to be addressed and feel free to contact me if you have any questions. Thanks, Jacek [1] http://sourceforge.net/projects/wine/files/Wine%20Gecko/1.2.0-rc1/

3 4

Re: wininet(6/10): Implement commiting a url cache entry that already existed
by Alexandre Julliard 10 Mar '11

10 Mar '11

Juan Lang <juan.lang(a)gmail.com> writes: > As a nice side effect, the aggravating fixme about not knowing what to > do disappears. The tests just hang for me: ../../../tools/runtest -q -P wine -M wininet.dll -T ../../.. -p wininet_test.exe.so http.c && touch http.ok fixme:wininet:set_cookie persistent cookies not handled (L"expires=Sat, 09 Apr 2011 14:14:39 GMT; path=/") fixme:wininet:InternetSetOptionW Option 43 STUB fixme:wininet:InternetSetOptionW Option 44 STUB fixme:wininet:CommitUrlCacheEntryInternal Trying to delete entry of unknown format "\x00\x00\x00\x00" -- Alexandre Julliard julliard(a)winehq.org

2 1

Links down
by Diego Diaz 10 Mar '11

10 Mar '11

sh winetricks mdac25 Executing wget -O mdac_typ.exe -nd -c --read-timeout=300 --retry-connrefused --header Accept-Encoding: gzip,deflate http://download.microsoft.com/download/e/e/4/ee4fe9ee-6fa1-4ab6-ab8c-fe1769… --2011-03-10 16:16:31-- http://download.microsoft.com/download/e/e/4/ee4fe9ee-6fa1-4ab6-ab8c-fe1769… Resolving download.microsoft.com... 77.67.20.40, 77.67.20.51, 77.67.20.64 Connecting to download.microsoft.com|77.67.20.40|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2011-03-10 16:16:32 ERROR 404: Not Found. ------------------------------------------------------ Note: command 'wget -O mdac_typ.exe -nd -c --read-timeout=300 --retry-connrefused --header Accept-Encoding: gzip,deflate http://download.microsoft.com/download/e/e/4/ee4fe9ee-6fa1-4ab6-ab8c-fe1769…' returned status 8. Aborting. ------------------------------------------------------ ------------------------------------------------------ mdac25 failed ************************************************************************************************************************************************* sh winetricks mdac28 Executing wget -O MDAC_TYP.EXE -nd -c --read-timeout=300 --retry-connrefused --header Accept-Encoding: gzip,deflate http://download.microsoft.com/download/c/d/f/cdfd58f1-3973-4c51-8851-49ae37… --2011-03-10 16:16:09-- http://download.microsoft.com/download/c/d/f/cdfd58f1-3973-4c51-8851-49ae37… Resolving download.microsoft.com... 77.67.20.40, 77.67.20.24 Connecting to download.microsoft.com|77.67.20.40|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2011-03-10 16:16:10 ERROR 404: Not Found. ------------------------------------------------------ Note: command 'wget -O MDAC_TYP.EXE -nd -c --read-timeout=300 --retry-connrefused --header Accept-Encoding: gzip,deflate http://download.microsoft.com/download/c/d/f/cdfd58f1-3973-4c51-8851-49ae37…' returned status 8. Aborting. ------------------------------------------------------ ------------------------------------------------------ mdac28 failed

1 0

New winetricks 20110310-alpha: new verbs csi6_demo, farmsim2011_demo, mono210
by Dan Kegel 10 Mar '11

10 Mar '11

Version 20110310-alpha adds two games csi6_demo - CSI: Fatal Conspiracy Demo farmsim2011_demo - Farming Simulator 2011 Demo plus a new version of mono (2.10). There are a couple gui changes: it adds a help button and a button to unhide broken titles,and adds a scary warning to the dinput and directx9 verb menu items. It also fixes a number of bugs. For bug tracker, mailing lists, and wiki, see http://winetricks.org Download url: http://winetricks.org/winetricks-alpha There's also an announcements mailing list for package maintainers now: http://groups.google.com/group/winetricks-announce Changes since 20110306-alpha: vbrun5, vbrun6: fix install check. vc2005trial: fix regression caused by 7zip installing into its own wineprefix. richtx32: fix install check Print unix file rather than windows file when install check fails, it's much less mysterious. farmsim2011_demo: fix media type Avoid syntax error if which returns empty string list-installed: no longer need kludge. Also sort the inputs rather than the outputs so output shows up faster. firefox4: update to rc1 mono210: new verb w_download: fix penpenxmas and autohotkey right this time w_download: don't set user-agent, it breaks sourceforge download csi6_demo: new verb farmsim2011_demo: new verb. sammax301_demo: fix typo (it's not 304) Add gui option for showing broken apps. Not great, but it'll do for now. Main menu is called 'main', so call prefix menu 'prefix'... masseffect2_demo: use wine-hotfix-6971 if present. Also fix -q support. tahoma: fix install check grr. really fix navigation, I hope. help: new verb, just opens winetricks.org/help in a browser. This is the very first entry on the first menu of the gui. fix breakage in zenity menus remove dead code dxdiag: list under 'dlls' rather than 'apps', since it's usually used in the context of some other app. Make directx9 warning more obvious. OS reporting didn't work well, so put wine version in that slot Fix navigation when returning back from apps Fix KDE support in top menu. Fix time/space columns in German and (kind of) Danish. d3dcompiler_43: new verb by Rico; marked as broken to hide it from casual users until wine can handle more d3d10 dinput: add scary warning

1 0

Re: [1/2] wininet: Partially implement FreeUrlCacheSpaceW. (try 2)
by Alexandre Julliard 10 Mar '11

10 Mar '11

Alexander Scott-Johns <alexander.scott.johns(a)googlemail.com> writes: > @@ -1660,6 +1660,16 @@ BOOLAPI DeleteUrlCacheEntryA(LPCSTR); > BOOLAPI DeleteUrlCacheEntryW(LPCWSTR); > #define DeleteUrlCacheEntry WINELIB_NAME_AW(DeleteUrlCacheEntry) > > +/* FCS_ flags and FreeUrlCacheSpace are no longer documented */ > +#define FCS_PERCENT_CACHE_SPACE 0 /* guessed value */ > +#define FCS_PERCENT_DISK_SPACE 1 /* guessed value */ > +#define FCS_ABSOLUTE_SIZE 2 /* guessed value */ Where do these come from then? If you made them up they shouldn't go in a public header. -- Alexandre Julliard julliard(a)winehq.org

2 2

d3dxcreatebox patch
by David Adam 10 Mar '11

10 Mar '11

Hello, is there any problem with my d3dxcreatebox patch? Thanks in advance for any feedback. A+ David

3 5

Re: winecfg: Protect from closing the root key.
by Alexandre Julliard 10 Mar '11

10 Mar '11

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > This patch should fix the crash reported in the bug #26367. A better way would be to use RegOpenKeyExW. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 5/6] user32: Add support for retrieving individual animated frames.
by Alexandre Julliard 10 Mar '11

10 Mar '11

Erich Hoover <ehoover(a)mines.edu> writes: > @@ -101,19 +93,40 @@ struct cursoricon_object > UINT width; > UINT height; > POINT hotspot; > + UINT delay; /* delay between this frame and the next (in jiffies) */ > + BOOL is_ani; /* whether this object is a static cursor or an animated cursor */ > UINT num_frames; /* number of frames in the icon/cursor */ > UINT num_steps; /* number of sequence steps in the icon/cursor */ > - UINT delay; /* global delay between frames (in jiffies) */ > - struct cursoricon_frame frames[1]; /* icon frame information */ > }; Some of these fields don't make sense for a static cursor. Also please try to do this change in smaller steps. -- Alexandre Julliard julliard(a)winehq.org

1 0

hooking into wine (GL video capturing app)
by Christian Parpart 10 Mar '11

10 Mar '11

Hey all, a few years ago I once developed an application for recording the video of the 3D games I played via wine (and cedega). This all worked quite fine these days and I remember that cedega's wine engine used other libX11 functions to process events than wine itself did or still does. In my software, I am overriding the specific library functions I want to hook in, such as glXSwapBuffers, XNextEvent, XCheckIfEvent, ... and then do LD_PRELOAD_LIBRARY this when starting wine. Note, only wine used to use XCheckIfEvent but cedega used some other function to process events, IIRC. This all worked fine back in the days I developed it, now I want to resurrect this project and found myself in troubles. That is, I can successfully hook into OpenGL library functions, but I just cannot find a trace on why my XCheckIfEvent is not being used by wine. A few days back one guy at IRC told me that I have to look at the wine's x11drv source code, which I did, but all I can see, is, that wine indeed still seems to use XCheckIfEvent(). Checking my running wine app (with my library preloaded) using lsof I can see that my library is indeed successfully hooked up into the process image at least, and so do my hooks to the OpenGL functions work. As a test, I also hooked up into XOpenDisplay from libX11, it worked, but still, XCheckIfEvent() does not, and my only clue is, that this piece of code of wine isn't actually the one processing the events. As a side note, I need to hook up into libX11 to capture keyboard input to actually start/stop video recording / screenshotting on keyboard events. Can anyone please help me out here why I cannot grap wine's keyboard events? In case of interest, the following is the link to the source code in question: http://redmine.xzero.ws/projects/captury/repository/revisions/master/entry/… Best regards, Christian Parpart.

2 1

Re: USB Osciloscope
by Archie Robertson 10 Mar '11

10 Mar '11

> Hello, > > What WINE version do you try to use? > What do you put to the WINE registry? > Could you send me ezusb.sys and a starting WINE log with > WINEDEBUG=+winedevice,+ntoskrnl,+usbhub ? > > Thanks, > Alexander Here is the information you have requested. I had trouble emailing the driver, so I put them on my web server at www.robertsonrobots.com/ezusb.sys Thanks for the help, Archie wine-1.0.1 REGEDIT4 [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\USB] [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\USB\Vid_3195&Pid_0004] [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\USB\Vid_3195&Pid_0004\5&c1e6cce&0&1] "Capabilities"=dword:00000084 "Class"="DSO" "ClassGUID"="{4C696E6B-2049-6E73-7472-756D656E7473}" "CompatibleIDs"=hex(7):55,53,42,5c,43,6c,61,73,73,5f,66,65,26,53,75,62,43,6c,61,\ 73,73,5f,30,33,26,50,72,6f,74,5f,30,30,00,55,53,42,5c,43,6c,61,73,73,5f,66,\ 65,26,53,75,62,43,6c,61,73,73,5f,30,33,00,55,53,42,5c,43,6c,61,73,73,5f,66,\ 65,00,00 "ConfigFlags"=dword:00000000 "DeviceDesc"="Link Instruments DSO-8502" "Driver"="{4C696E6B-2049-6E73-7472-756D656E7473}\\0001" "HardwareID"=hex(7):55,53,42,5c,56,69,64,5f,33,31,39,35,26,50,69,64,5f,30,30,30,\ 34,26,52,65,76,5f,30,30,30,35,00,55,53,42,5c,56,69,64,5f,33,31,39,35,26,50,\ 69,64,5f,30,30,30,34,00,00 "LocationInformation"="DSO-8502" "Mfg"="Link Instruments" "Service"="ezusb" "UINumber"=dword:00000000 [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\USB\Vid_3195&Pid_0004\5&c1e6cce&0&1\Device Parameters] "SymbolicName"="\\??\\USB#Vid_3195&Pid_0004#5&c1e6cce&0&1#{a5dcbf10-6530-11d2-901f-00c04fb951ed}" [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\USB\Vid_3195&Pid_0004\5&c1e6cce&0&1\LogConf] [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\USB\Vid_3195&Pid_0004\5&c1e6cce&0&2] "Capabilities"=dword:00000084 "Class"="DSO" "ClassGUID"="{4C696E6B-2049-6E73-7472-756D656E7473}" "CompatibleIDs"=hex(7):55,53,42,5c,43,6c,61,73,73,5f,66,65,26,53,75,62,43,6c,61,\ 73,73,5f,30,33,26,50,72,6f,74,5f,30,30,00,55,53,42,5c,43,6c,61,73,73,5f,66,\ 65,26,53,75,62,43,6c,61,73,73,5f,30,33,00,55,53,42,5c,43,6c,61,73,73,5f,66,\ 65,00,00 "ConfigFlags"=dword:00000000 "DeviceDesc"="Link Instruments DSO-8502" "Driver"="{4C696E6B-2049-6E73-7472-756D656E7473}\\0000" "HardwareID"=hex(7):55,53,42,5c,56,69,64,5f,33,31,39,35,26,50,69,64,5f,30,30,30,\ 34,26,52,65,76,5f,30,30,30,35,00,55,53,42,5c,56,69,64,5f,33,31,39,35,26,50,\ 69,64,5f,30,30,30,34,00,00 "LocationInformation"="DSO-8502" "Mfg"="Link Instruments" "Service"="ezusb" "UINumber"=dword:00000000 [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\USB\Vid_3195&Pid_0004\5&c1e6cce&0&2\Device Parameters] "SymbolicName"="\\??\\USB#Vid_3195&Pid_0004#5&c1e6cce&0&2#{a5dcbf10-6530-11d2-901f-00c04fb951ed}" [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\USB\Vid_3195&Pid_0004\5&c1e6cce&0&2\LogConf] REGEDIT4 [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ezusb] "ErrorControl"=dword:00000001 "ImagePath"="\"system32\\\\driver\\\\ezusb.sys\"" "Start"=dword:00000003 "Type"=dword:00000001 [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ezusb\Security] "Security"=hex:01,00,14,80,a0,00,00,00,ac,00,00,00,14,00,00,00,30,00,00,00,02,\ 00,1c,00,01,00,00,00,02,80,14,00,ff,01,0f,00,01,01,00,00,00,00,00,01,00,00,\ 00,00,02,00,70,00,04,00,00,00,00,00,18,00,fd,01,02,00,01,01,00,00,00,00,00,\ 05,12,00,00,00,00,00,00,00,00,00,1c,00,ff,01,0f,00,01,02,00,00,00,00,00,05,\ 20,00,00,00,20,02,00,00,00,00,00,00,00,00,18,00,8d,01,02,00,01,01,00,00,00,\ 00,00,05,0b,00,00,00,20,02,00,00,00,00,1c,00,fd,01,02,00,01,02,00,00,00,00,\ 00,05,20,00,00,00,23,02,00,00,00,00,00,00,01,01,00,00,00,00,00,05,12,00,00,\ 00,01,01,00,00,00,00,00,05,12,00,00,00 phoenox@firebird:~/.wine/drive_c/DSO8000$ WINEDEBUG=+winedevice, +ntoskrnl,+usbhub wine ezusb.sys trace:winedevice:ServiceMain starting service L"MountMgr" trace:winedevice:load_driver loading driver L"C:\\windows\\system32\ \drivers\\mountmgr.sys" trace:ntoskrnl:IoCreateDevice (0x7ee8c480, 0, L"\\Device\ \MountPointManager", 0, 0, 0, 0x7ec048ac) trace:ntoskrnl:IoCreateSymbolicLink L"\\??\\MountPointManager" -> L"\ \Device\\MountPointManager" trace:ntoskrnl:IoCreateDevice (0x1117b0, 20, L"\\Device\\Harddisk0", 0, 0, 0, 0x7ec047f8) trace:ntoskrnl:IoCreateSymbolicLink L"\\??\\PhysicalDrive0" -> L"\ \Device\\Harddisk0" trace:ntoskrnl:IoCreateDevice (0x1117b0, 20, L"\\Device\ \HarddiskVolume1", 0, 0, 0, 0x7ec3a540) trace:ntoskrnl:IoCreateSymbolicLink L"\\DosDevices\\C:" -> L"\\Device\ \HarddiskVolume1" trace:ntoskrnl:IoCreateSymbolicLink L"\\??\ \Volume{00000000-0000-0000-0000-000000000043}" -> L"\\Device\ \HarddiskVolume1" trace:ntoskrnl:IoCreateDevice (0x1117b0, 20, L"\\Device\ \HarddiskVolume1", 0, 0, 0, 0x7ec3a568) trace:ntoskrnl:IoCreateDevice (0x1117b0, 20, L"\\Device\ \HarddiskVolume2", 0, 0, 0, 0x7ec3a568) trace:ntoskrnl:IoCreateSymbolicLink L"\\DosDevices\\D:" -> L"\\Device\ \HarddiskVolume2" trace:ntoskrnl:IoCreateSymbolicLink L"\\??\ \Volume{00000000-0000-0000-0000-000000000044}" -> L"\\Device\ \HarddiskVolume2" trace:ntoskrnl:IoCreateDevice (0x1117b0, 20, L"\\Device\ \HarddiskVolume1", 0, 0, 0, 0x7ec3a590) trace:ntoskrnl:IoCreateDevice (0x1117b0, 20, L"\\Device\ \HarddiskVolume2", 0, 0, 0, 0x7ec3a590) trace:ntoskrnl:IoCreateDevice (0x1117b0, 20, L"\\Device\ \HarddiskVolume3", 0, 0, 0, 0x7ec3a590) trace:ntoskrnl:IoCreateSymbolicLink L"\\DosDevices\\H:" -> L"\\Device\ \HarddiskVolume3" trace:ntoskrnl:IoCreateSymbolicLink L"\\??\ \Volume{00000000-0000-0000-0000-000000000048}" -> L"\\Device\ \HarddiskVolume3" trace:ntoskrnl:IoCreateDevice (0x1117b0, 20, L"\\Device\ \HarddiskVolume1", 0, 0, 0, 0x7ec3a5b8) trace:ntoskrnl:IoCreateDevice (0x1117b0, 20, L"\\Device\ \HarddiskVolume2", 0, 0, 0, 0x7ec3a5b8) trace:ntoskrnl:IoCreateDevice (0x1117b0, 20, L"\\Device\ \HarddiskVolume3", 0, 0, 0, 0x7ec3a5b8) trace:ntoskrnl:IoCreateDevice (0x1117b0, 20, L"\\Device\ \HarddiskVolume4", 0, 0, 0, 0x7ec3a5b8) trace:ntoskrnl:IoCreateSymbolicLink L"\\DosDevices\\Z:" -> L"\\Device\ \HarddiskVolume4" trace:ntoskrnl:IoCreateSymbolicLink L"\\??\ \Volume{00000000-0000-0000-0000-00000000005a}" -> L"\\Device\ \HarddiskVolume4" trace:winedevice:init_driver init done for L"MountMgr" obj 0x7ee8c480 trace:winedevice:init_driver - DriverInit = 0x7ec383c0 trace:winedevice:init_driver - DriverStartIo = (nil) trace:winedevice:init_driver - DriverUnload = (nil) trace:winedevice:init_driver - MajorFunction[0] = (nil) trace:winedevice:init_driver - MajorFunction[1] = (nil) trace:winedevice:init_driver - MajorFunction[2] = (nil) trace:winedevice:init_driver - MajorFunction[3] = (nil) trace:winedevice:init_driver - MajorFunction[4] = (nil) trace:winedevice:init_driver - MajorFunction[5] = (nil) trace:winedevice:init_driver - MajorFunction[6] = (nil) trace:winedevice:init_driver - MajorFunction[7] = (nil) trace:winedevice:init_driver - MajorFunction[8] = (nil) trace:winedevice:init_driver - MajorFunction[9] = (nil) trace:winedevice:init_driver - MajorFunction[10] = (nil) trace:winedevice:init_driver - MajorFunction[11] = (nil) trace:winedevice:init_driver - MajorFunction[12] = (nil) trace:winedevice:init_driver - MajorFunction[13] = (nil) trace:winedevice:init_driver - MajorFunction[14] = 0x7ec37630 trace:winedevice:init_driver - MajorFunction[15] = (nil) trace:winedevice:init_driver - MajorFunction[16] = (nil) trace:winedevice:init_driver - MajorFunction[17] = (nil) trace:winedevice:init_driver - MajorFunction[18] = (nil) trace:winedevice:init_driver - MajorFunction[19] = (nil) trace:winedevice:init_driver - MajorFunction[20] = (nil) trace:winedevice:init_driver - MajorFunction[21] = (nil) trace:winedevice:init_driver - MajorFunction[22] = (nil) trace:winedevice:init_driver - MajorFunction[23] = (nil) trace:winedevice:init_driver - MajorFunction[24] = (nil) trace:winedevice:init_driver - MajorFunction[25] = (nil) trace:winedevice:init_driver - MajorFunction[26] = (nil) trace:winedevice:init_driver - MajorFunction[27] = (nil) err:module:attach_process_dlls "USBD.SYS" failed to initialize, aborting err:module:LdrInitializeThunk Main exe initialization for L"C:\\DSO8000\ \ezusb.sys" failed, status c0000142

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel