- wine-devel - winehq.org

Re: mmdevapi: Prevent 64 bit overflow within a few days of audio device use. (try 2)
by Michael Stefaniuc 05 Mar '13

05 Mar '13

Hello Joerg, On 03/01/2013 10:22 AM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > The idea to replace X * numerator / denominator > by X / den * mul + remainder from euclidian division > came from > http://blog.airsource.co.uk/index.php/2010/03/15/quelle-heure-est-il/ > > M. Stefaniuc suggested an inline function. The MulDiv64 inline has the benefit > of ensuring unsigned arithmetic, matching GetPosition UINT64 output. My idea was to have the whole if else in an inline function. But I see that even the whole functionality can move to a helper. Something like this: static inline ULONGLONG get_qpctime(void) { LARGE_INTEGER stamp, freq; QueryPerformanceCounter(&stamp); QueryPerformanceFrequency(&freq); if(freq.QuadPart == 10000000) return stamp.QuadPart; else return stamp.QuadPart / freq.QuadPart * 10000000 + stamp.QuadPart % freq.QuadPart * 10000000 / freq.QuadPart; } bye michael

2 2

Re: [PATCH 2/2] winmm: MCI_BREAK_HWND handling now matches Wine's 1999 MCI_DefYieldProc.
by Alexandre Julliard 05 Mar '13

05 Mar '13

<Joerg-Cyril.Hoehle(a)t-systems.com> writes: > @@ -2063,9 +2063,10 @@ static DWORD MCI_Break(UINT wDevID, DWORD dwFlags, LPMCI_BREAK_PARMS lpParms) > switch (dwFlags & (MCI_BREAK_KEY | MCI_BREAK_OFF)) { > case MCI_BREAK_KEY: > wmd->lpfnYieldProc = MCI_DefYieldProc; > - wmd->dwYieldData = lpParms->nVirtKey; > - if (dwFlags & MCI_BREAK_HWND) > - FIXME("(%x) vkey %02X on window %p\n", dwFlags, lpParms->nVirtKey, lpParms->hwndBreak); > + /* Our MCI_DefYieldProc from 1999-04-11 expects this DWORD splitting, > + * yet tests on w2k-w7 prove wmd->dwYieldData = lpParms->nVirtKey; */ It doesn't make sense to add workarounds for Wine code, it should be fixed instead. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: server/advapi32: Report administrator ownership by default for registry objects (try 5).
by Alexandre Julliard 05 Mar '13

05 Mar '13

"Erich E. Hoover" <ehoover(a)mymail.mines.edu> writes: > +static struct security_descriptor *key_get_sd( struct object *obj ) > +{ > + struct security_descriptor *sd = default_get_sd( obj ); > + const SID *admins_sid = security_builtin_admins_sid; > + int admin_len; > + char *ptr; > + > + if (sd) return sd; > + admin_len = FIELD_OFFSET(SID, SubAuthority[admins_sid->SubAuthorityCount]); > + sd = mem_alloc( sizeof(struct security_descriptor) + 2*admin_len ); > + if (!sd) return sd; > + > + sd->control = 0; > + sd->owner_len = admin_len; > + sd->group_len = admin_len; > + sd->sacl_len = 0; > + sd->dacl_len = 0; > + > + ptr = (char *)(sd + 1); > + memcpy( ptr, security_builtin_admins_sid, sd->owner_len ); > + ptr += sd->owner_len; > + memcpy( ptr, security_builtin_admins_sid, sd->group_len ); > + ptr += sd->group_len; > + > + free( obj->sd ); > + obj->sd = sd; > + return sd; > +} It shouldn't be necessary to allocate one for every key. -- Alexandre Julliard julliard(a)winehq.org

1 0

Making wine default to the Mac Driver on OS X
by Josh DuBois 05 Mar '13

05 Mar '13

With Friday's release, I am interested in making the Mac Driver wine's default on OS X. My own immediate motivation is largely so we at CodeWeavers can start testing it as a default internally (which obviously we can do on our own, regardless, if needed), but I figured I'd ask the wider community to see whether it's time in winehq also. My question is how it should be configured from a user perspective. Right now one can set a registry key in HKCU/Software/Wine/Drivers/Graphics with a comma-separated list specifying the driver load order, and the first one successfully loaded will be used. Absent the key, there is a hardcoded load order in user32/driver.c. Right now that is just "x11." Discussing with Alexandre the other day I believe his thought is to make the hardcoded default "x11,mac" in all cases (including Linux). I believe (and I don't mean to put words in his mouth) that his thought is that a user should never have to edit the registry to switch between drivers. The thought would be that in order to switch between drivers, a user must instead create an environment in which all drivers which are ahead of the desired driver in the hardcoded load order will fail to load. I think that in the specific case of "x11,mac" on an OS X box, the thought was to unset DISPLAY if you want to run with the Mac Driver on, forcing X11 to fail and therefore getting the fallback. I just now realized, though, that OS X 10.8 ships with stub X11 libraries which behave badly. If you try to load X11 on a brand-new OS X 10.8 machine, the user sees a dialog box with directions on downloading XQuartz, and the process which tried to load X11 is killed. I hadn't thought of that earlier, but it seems to weigh against using a fallback mechanism where x11 is attempted first in all cases. It means that to get good behavior from the fall-through, a Mac user would be required to download and install real X libraries, then unset DISPLAY. It seems broadly incorrect to me to attempt to load X11 first everywhere and force the user to make sure loading that fails if they want a different driver. I think that if the Mac Driver is to be the default on a Mac, rather than assume the environment will be such that other drivers will fail, it should really just be the first thing wine tries to load. The case of OS X's bad X11 stub libraries is one where it seems fairly onerous for a user to ensure X11 won't load. Wayland isn't here now, but it seems like when it comes it may bring similar issues. I propose an environment variable, WINEDRIVERLOADORDER. I would think we would first use the registry value, then the value of WINEDRIVERLOADORDER, then the hardcoded fallback. I would also propose making the hardcoded fallback differ on OS X and linux, so that a user who does nothing on OS X can have the Mac Driver, but someone who wants X11 can set WINEDRIVERLOADORDER and switch to that without editing the registry. Is that an acceptable approach? Of course, Ken may abhor the idea of having the Mac Driver the default in winehq at this point, anyway. ;)

5 7

wanted: testbot w9x machines
by Joerg-Cyril.Hoehle＠t-systems.com 04 Mar '13

04 Mar '13

Hi, Francois Gouget wrote in another thread: >Not so long ago that machine was also running the tests on 5 additional >NT4 configurations, Windows 95, Windows 98 and Windows Millenium. It no >longer does, not because of lack of 'resources' or 'intention', but >because the Wine community is not interested in these. Huh? What? Please, PLEASE give me a (new)testbot with some w9x machines such that I can investigate the winmm&mci behavior that the apps written in that era encountered. It really slows down development on my side *not* to have an easily checked w9x system (nor a system for 16 bit tests, BTW). All that I can remember when that issue was raised last time was: 1. It's good not to test incoming patches against w9x behavior, because the time spent adding broken() for those is better invested adding code and more tests for w2k-w7 machines. Agreed. 1' test.winehq.org need no more display w9x test results. I don't care much. 2. Some technical aspects, such as not being able to find Greg's old w95 VM image, or producing a VM image with some soundcard not hanging randomly. But I can't remember an argument saying like "nobody was interested in those w95/w98/w98SE/wME machines, so we dumped them". Currently, (new)testbot doesn't even offer an option to run tests on w9x machines. I'm not asking for that option to be on by default, I'm just begging for it to be present! Thank you, Jörg Höhle

2 1

Re: gdiplus/tests: Skip the tests if unable to load the TIFF image.
by Dmitry Timoshkov 04 Mar '13

04 Mar '13

Francois Gouget <fgouget(a)codeweavers.com> wrote: > On Windows XP most versions of gdiplus (i.e. older than 5.2) do not support TIFF. I'd suggest to upgrade the VM instead. Ideally each VM should represent a Windows version with newest service pack installed it's supposed to run the tests on, otherwise that VM is useless. IMHO there is no point in changing the tests to workaround a broken VM state. -- Dmitry.

3 7

Re: [1/3] Revert "gdiplus: Add support for StringFormatFlagsNoClip."
by Vincent Povirk 04 Mar '13

04 Mar '13

Yay, thanks for fixing this. +1 :D

1 0

Use accented letters in their names.
by Tae Wong 04 Mar '13

04 Mar '13

You will want to use accented letters in their authors names. Caolan McNamara Ferenc Wagner Marko Nikolic Every once and a while the GNOME Live website is down with an error on Netscape called “The operation timed out when attempting to contact .” - This paragraph should have a website name. You want to be unbanned in Amaterasu Translations and the DOS ain’t dead forums.

2 2

Re: comctl32/imagelist: use DDB instead of 16-color bitmaps
by Alexandre Julliard 04 Mar '13

04 Mar '13

Daniel Jelinski <djelinski1(a)gmail.com> writes: > Subject: [PATCH 1/2] comctl32/imagelist: use DDB instead of 16-color bitmaps > > I don't know if DDB is a good option here, but 32bit color resulted in > invisible images, and anything is better than the current 16 colors Some test cases would be a good idea. -- Alexandre Julliard julliard(a)winehq.org

1 0

IOCTL_DVD_READ_STRUCTURE (DvdPhysicalDescriptor) test failure
by Detlef Riekenberg 04 Mar '13

04 Mar '13

2 1

IOCTL_DVD_READ_STRUCTURE (DvdPhysicalDescriptor) test failure [text only]
by Detlef Riekenberg 03 Mar '13

03 Mar '13

Hi Alexandre. I have a test failure on my win7 Machine, while a valid cd was in the dvd drive. volume.c:785: Test failed: IOCTL_DVD_READ_STRUCTURE (DvdPhysicalDescriptor) failed, last error = 1785 Example result: http://test.winehq.org/data/209b58c64e6181c9bf448cb4f3130d3ba705c5d2/win7_d… (The same failure is present, when running the 64bit test) Other machines are also affected. Example: http://test.winehq.org/data/4a685ebea343efdcb433f8d710b0c9f902e471fa/win7_m… You wrote the tests, which was comitted on 12. July 2012: http://source.winehq.org/git/wine.git/commitdiff/a3b5dd2dff0d04fe317f00282c… What media did you use, to test your code? Data-DVD, Video-DVD, Empty DVD, Data-CD, Video-CD, Audio-CD, Empty CD, No Disc in Drive What results did you get on Windows and Unix? On Linux, mounting the example CD works perfect, but your test fails: volume.c:785: Test failed: IOCTL_DVD_READ_STRUCTURE (DvdPhysicalDescriptor) failed, last error = 87 Your test only read the DVD descriptor. To fix your test, I suggest, that you add a trace to dump the *_READ_STRUCTURE IoControl result and add similar tests for the other media formats. I also tested with a different Data-CD and got the same failure on linux (last error = 87). You can check the image yourself: http://www.memtest86.com/downloads/memtest86-4.1.0-iso.zip (Burned on a CD) Your broken test was not detected by winetest, but that is a different issue http://bugs.winehq.org/show_bug.cgi?id=31780 sorry for the prev. html mail -- By by ... Detlef

1 0

Re: [PATCH] Add support for -Ttext-segment linker flag to set image base of a dll.
by Alexandre Julliard 02 Mar '13

02 Mar '13

Tijl Coosemans <tijl(a)coosemans.org> writes: > --- > configure.ac | 2 ++ > tools/winegcc/winegcc.c | 8 ++++++++ > 2 files changed, 10 insertions(+) This would have to be done based on the target platform, not on a configure check. -- Alexandre Julliard julliard(a)winehq.org

2 1

FYI ubuntu PPA 64-bit did not update wine1.5-386
by Susan Cragin 02 Mar '13

02 Mar '13

just letting you know. assume it will be available later.

1 0

Re: gdiplus: GdipDrawString should handle alignment in both directions in a similar way. Take 2.
by Vincent Povirk 01 Mar '13

01 Mar '13

Sorry, I'm still not sure this is going to work. It seems to me that different lines will have to be offset by different amounts, and it's not clear to me how that's going to happen without the alignment logic in gdip_format_string. I'm also wondering if a change to the alignment logic in gdip_format_string is going to break MeasureCharacterRanges.

1 0

Re: [PATCH 3/3] msvcrt: Added stdin close/open tests
by Marvin 01 Mar '13

01 Mar '13

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=24564 Your paranoid android. === WVISTAADM (32 bit file) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation

1 0

Re: d3dx9 [patch 1/2]: Implement D3DXSHEvalConeLight
by Marvin 01 Mar '13

01 Mar '13

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

3 2

Re: ieframe: Fixed tests on IE10.
by Marvin 01 Mar '13

01 Mar '13

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=24562 Your paranoid android. === WNT4WSSP6 (32 bit webbrowser) === Timeout === W2KPROSP4 (32 bit webbrowser) === webbrowser.c:2613: Test failed: expected GetOverridesKeyPath webbrowser.c:2618: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2619: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:3052: Test failed: doc_disp == NULL webbrowser: unhandled exception c0000005 at 00402F21

1 0

Re: gdiplus: GdipDrawString should handle alignment in both directions same way.
by Vincent Povirk 28 Feb '13

28 Feb '13

> - if (format) halign = format->align; > - else halign = StringAlignmentNear; > - How are you handling the case where format is NULL?

1 1

GSoC 2013 guidelines.
by Tejas Nikumbh 28 Feb '13

28 Feb '13

Hi, I am Tejas Nikumbh, an undergrad at Indian Institute of Technology Bombay. I will be participating in GSoC this year. [GSoC 2013]. In order to imporve my chances for getting selected this year, I would like to start contributing early on to Open Source development via Wine. Here's a little background info : *Languages proficient in : *Java, Python, Javascript [+jQuery] , HTML[+HTML5 Canvas], CSS [+CSS3]. C++ should be on the list soon. *CS Theory :* Discrete Math, Probablity and Random Processes, Data Structures and Algorithms. *SVN : *Github, Mercurial . *Basic Machine learning [Regression algos and some classification algos]* Based on the above info, are there any projects which might suit me? Also, Picking up something reasonable quickly shouldn't be a problem. Thanks, -- Tejas Nikumbh, Third Year Undergraduate, Electrical Engineering Department, IIT Bombay.

1 0

Re: ieframe: Fixed QI tests on IE10, where IStdMarshalInfo is supported by WebBrowser object.
by Marvin 28 Feb '13

28 Feb '13

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=24550 Your paranoid android. === WNT4WSSP6 (32 bit webbrowser) === Timeout === W2KPROSP4 (32 bit webbrowser) === webbrowser.c:2607: Test failed: expected GetOverridesKeyPath webbrowser.c:2612: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2613: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:3041: Test failed: doc_disp == NULL webbrowser: unhandled exception c0000005 at 00402F21

1 0

Re: msvcrt/tests: Mark win8 behaviour as broken (try 2)
by Marvin 27 Feb '13

27 Feb '13

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

1 0

Fix name order in the authors file.
by Tae Wong 27 Feb '13

27 Feb '13

You’ve found Kazuyuki Sato in inverted name order. Apostrophes on the O-section are not ignored. O'Callahan, Robert O'Neill, Damien O'Regan, Mike Oberhumer, Stefan Oberndorfer, Peter Ogburn, Walt Ognyanoff, Damyan Olsen, Henrik Olsen, Magnus Olson, Roger Olver, Neil Ortiz, Jose Manuel Ferrer Osmundsen, Knut St. It should be ignored so the section should be sorted as: Oberhumer, Stefan Oberndorfer, Peter O'Callahan, Robert Ogburn, Walt Ognyanoff, Damyan Olsen, Henrik Olsen, Magnus Olson, Roger Olver, Neil O'Neill, Damien O'Regan, Mike Ortiz, Jose Manuel Ferrer Osmundsen, Knut St.

1 0

Re: d3dx9: Avoid expensive computations
by Rico Schüller 27 Feb '13

27 Feb '13

On 25.02.2013 06:03, Nozomi Kodama wrote: > + out.u.m[2][i] = v.z / signed_det; > + out.u.m[3][i] = v.w / signed_det; > } > > *pout = out; While you are at it, you may fix the indentation of out*, "}", "*pout = out;" and "return pout;". > signed_det = (i % 2)? -det: det; Couldn't you just use something like "det = -det;" instead of the modulo? This should be a little bit faster. I did some small tests for speed with the following results. You may also avoid such a lot of variable assignments like *pout = out and you may use 4 vecs instead. This should save ~48 assignments and it should also improve the speed a bit more (~10%). Though, native is still 40% faster than that. With the change above it should look like: int i; D3DXVECTOR4 v, vec[4]; FLOAT det; ... for (i = 0; i < 4; i++) { vec[i].x = pm->u.m[i][0]; vec[i].y = pm->u.m[i][1]; vec[i].z = pm->u.m[i][2]; vec[i].w = pm->u.m[i][3]; } for (i = 0; i < 4; i++) { switch (i) { case 0: D3DXVec4Cross(&v, &vec[1], &vec[2], &vec[3]); break; case 1: D3DXVec4Cross(&v, &vec[0], &vec[2], &vec[3]); break; case 2: D3DXVec4Cross(&v, &vec[0], &vec[1], &vec[3]); break; case 3: D3DXVec4Cross(&v, &vec[0], &vec[1], &vec[2]); break; } pout->u.m[0][i] = v.x / det; pout->u.m[1][i] = v.y / det; pout->u.m[2][i] = v.z / det; pout->u.m[3][i] = v.w / det; det = -det; } return pout; Maybe we could reuse some calculations from the D3DXVec4Cross function ... Cheers Rico

5 7

Re: secur32: Report SecPkgContext_ConnectionInfo in bits, not bytes.
by Marvin 27 Feb '13

27 Feb '13

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=24544 Your paranoid android. === W2KPROSP4 (32 bit schannel) === schannel.c:762: Test failed: conn_info.dwHashStrength = 128 === WXPPROSP3 (32 bit schannel) === schannel.c:762: Test failed: conn_info.dwHashStrength = 128 === W2K3R2SESP2 (32 bit schannel) === schannel.c:762: Test failed: conn_info.dwHashStrength = 128

1 0

Re: mmdevapi: Prevent 64 bit overflow within a few days of audio device use.
by Michael Stefaniuc 27 Feb '13

27 Feb '13

Hello Joerg, On 02/27/2013 02:46 PM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > The idea to replace X * numerator / denominator > by X / den * mul + remainder from euclidian division > came from can you please use an inline function for that? > http://blog.airsource.co.uk/index.php/2010/03/15/quelle-heure-est-il/ thanks bye michael

1 0

Re: [PATCH 2/4] vbscript: Added color constants.
by Marvin 27 Feb '13

27 Feb '13

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

1 0

Re: [1/3] wininet: Remember that headers were not received.
by Jacek Caban 27 Feb '13

27 Feb '13

Hi Ričardas, On 02/27/13 00:07, Ričardas Barkauskas wrote: > @@ -5708,6 +5708,7 @@ static INT HTTP_GetResponseHeaders(http_request_t *request, BOOL clear) > > heap_free(request->rawHeaders); > request->rawHeaders = heap_strdupW(szDefaultHeader); > + request->flags |= INTERNET_REQFLAG_NO_HEADERS; I don't think we want to maintain valid request->flags for that particular flag. Checking for request->rawHeaders should be enough. If we avoided setting rawHeaders here, we'd achieve the same behaviour. Jacek

1 0

Re: msvcrt/tests: Mark win8 behaviour as broken
by Piotr Caban 27 Feb '13

27 Feb '13

On 02/26/13 23:57, André Hentschel wrote: > diff --git a/dlls/msvcrt/tests/time.c b/dlls/msvcrt/tests/time.c > index 30d9fa7..3d00769 100644 > --- a/dlls/msvcrt/tests/time.c > +++ b/dlls/msvcrt/tests/time.c > @@ -181,8 +181,8 @@ static void test_gmtime(void) > err = p_gmtime32_s(&gmt_tm_s, &gmt); > - ok(gmt_tm_s.tm_year==-1 || broken(gmt_tm_s.tm_year==70 && gmt_tm->tm_sec<0), > - "tm_year = %d\n", gmt_tm_s.tm_year); > + ok(gmt_tm_s.tm_year==-1 || broken(gmt_tm_s.tm_year==70), > + "tm_year = %d, tm_sec = %d\n", gmt_tm_s.tm_year, gmt_tm->tm_sec); This test was checking wrong structure. It should use gmt_tm_s struct for testing seconds instead of gmt_tm.

1 0

Re: [1/3] wininet: Remember that headers were not received.
by Marvin 26 Feb '13

26 Feb '13

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=24535 Your paranoid android. === W7PROX64 (32 bit http) === http.c:3337: Test failed: HttpSendRequest failed: 12002

1 0

Re: gdi32: Fix the GdiGetCodePage() support ANSI_CHARSET font associated charset
by Akihiro Sagawa 26 Feb '13

26 Feb '13

On Sun, 24 Feb 2013 09:55:59 +0900, Byeongsik Jeon wrote: Could you consider adding "(try N)" at the end of subject line? The rule is documented here: http://wiki.winehq.org/SubmittingPatches#head-fea51bfdf6a29105a9a6fc6f5886a… > diff --git a/dlls/gdi32/font.c b/dlls/gdi32/font.c > index b274b83..3a99d35 100644 > --- a/dlls/gdi32/font.c > +++ b/dlls/gdi32/font.c > @@ -590,11 +590,75 @@ HFONT WINAPI CreateFontW( INT height, INT width, INT esc, This part looks good. > diff --git a/dlls/gdi32/freetype.c b/dlls/gdi32/freetype.c (snip) > +static void update_font_association_info(UINT current_ansi_codepage) > +{ > + static const WCHAR font_assoc_reg_keyW[] = {'S','y','s','t','e','m','\\', > + 'C','u','r','r','e','n','t','C','o','n','t','r','o','l','S','e','t','\\', > + 'C','o','n','t','r','o','l','\\','F','o','n','t','A','s','s','o','c','\0'}; It is nice introducing separate function for this work. However using WCHAR is a bit overwork, because ANSI APIs are still used in update_font_info() especially set_value_key(). Please follow the style of surrounding code. > @@ -3615,6 +3675,10 @@ static void update_font_info(void) > } > if (!done) > FIXME("there is no font defaults for codepages %u,%u\n", ansi_cp, oem_cp); > + > + /* update locale dependent font association info in registry */ > + if (strcmp(buf, cpbuf)) > + update_font_association_info(ansi_cp); > } > > static BOOL init_freetype(void) This condition should be rewritten. buf is not initialized when RegQueryValueExA is failed in line 3542. And strcmp(buf, cpbuf) has already done in line 3544. > diff --git a/dlls/gdi32/tests/font.c b/dlls/gdi32/tests/font.c > index 943f584..9d57806 100644 > --- a/dlls/gdi32/tests/font.c > +++ b/dlls/gdi32/tests/font.c Why are there no tests against OEM_CHARSET and SYMBOL_CHARSET? Regards, Akihiro Sagawa

2 2

Re: riched20: Remove redundant 'return;' statements.
by Dmitry Timoshkov 26 Feb '13

26 Feb '13

This patch is marked as 'Rejected', and I can't find an e-mail to wine-devel with an explanation why. -- Dmitry.

2 1

Re: comctl32/listview: fix mouse message sequences
by Nikolay Sivov 26 Feb '13

26 Feb '13

On 2/24/2013 01:33, Daniel Jelinski wrote: > @@ -10178,6 +10139,19 @@ static LRESULT LISTVIEW_LButtonDown(LISTVIEW_INFO *infoPtr, WORD wKey, INT x, IN > > if (infoPtr->dwLvExStyle & LVS_EX_ONECLICKACTIVATE) > if(lvHitTestInfo.iItem != -1) notify_itemactivate(infoPtr,&lvHitTestInfo); > + if (LISTVIEW_TrackMouse(infoPtr, pt)) > + { > + NMLISTVIEW nmlv; > + > + ZeroMemory(&nmlv, sizeof(nmlv)); > + nmlv.iItem = lvHitTestInfo.iItem; > + nmlv.ptAction = infoPtr->ptClickPos; > + > + notify_listview(infoPtr, LVN_BEGINDRAG, &nmlv); > + infoPtr->bDragging = TRUE; > + } > + else > + LISTVIEW_LButtonUp(infoPtr,0,x,y); This doesn't look very clean. I mean invoking *up handler from a *down one. Is this something that could be resolved with message loop like rbutton dragging was fixed?

2 3

Re: winetest: Add a link to the test summary page that specifies the test configuration details, the dll versions, etc.
by Alexandre Julliard 25 Feb '13

25 Feb '13

Francois Gouget <fgouget(a)codeweavers.com> writes: > Clarify two other link names to avoid confusion. > --- > > I did not test this patch so it should be verified carefully before > committing. I recently found myself annoyed that I could not go from a > page such as this one: > > http://test.winehq.org/data/209b58c64e6181c9bf448cb4f3130d3ba705c5d2/win7_n… > > to what I call that test's summary page: > > http://test.winehq.org/data/209b58c64e6181c9bf448cb4f3130d3ba705c5d2/win7_n… > > Of course 'summary' referred instead to the page with all the 'build > results' which I found very confusing. So I renamed it to just that > ('build results', not 'confusing' <g>). Then I renamed the 'index' link > to 'home' since it points to the winetest site's landing page (aka its > 'home' page). I'm not sure that's better. Particularly since that summary page is helpfully called "Main summary", it's not that confusing. The version info is obtained on other pages by clicking on the test tag, so we could potentially display the test tag on the individual test page too. -- Alexandre Julliard julliard(a)winehq.org

1 0

A new demangler test?
by Max TenEyck Woodbury 25 Feb '13

25 Feb '13

Would it be appropriate to add a test to the name demangler that: 1) Scans all '.dll' and '.spac' files for mangled names, and 2) Tries to decode those names. 3) Prints the mangled and decoded names and where they occur. Success would be that all names decode without the decoder blowing up or failing.

4 6

Re: [2/3] gdiplus: Round up when converting from 32-bit ARGB to PARGB.
by Vincent Povirk 25 Feb '13

25 Feb '13

Are you sure about this? Other tests have suggested that native is not this exact when dealing with color values, and different OS versions have produced slightly different results. Is there an application that relies on this, or is there a reason this is generally more correct behavior when premultiplying alpha?

1 1

Re: user32/tests: Test invalidating during SetWindowPos() (resend).
by Sergey Guralnik 25 Feb '13

25 Feb '13

On 2013-02-21 15:44, Sergey Guralnik wrote: > This patch marked as "Pending" without any comment at wine-devel. Is something wrong with it? (Maybe there should be more test cases?) -- Sergey

2 1

Re: [1/3] gdiplus: Add some tests for ARGB conversions.
by Nikolay Sivov 25 Feb '13

25 Feb '13

On 2/25/2013 09:29, Dmitry Timoshkov wrote: It seems your system time is an hour ahead. Probably old timezone info?

1 0

Why complain about X1R5G5B5?
by Francois Gouget 24 Feb '13

24 Feb '13

If I run Wine's conformance tests in a QEmu VM using Spice's QXL driver I get the following errors: d3d8:device device.c:1004: Test failed: Unexpected display mode returned for mode 0: 0x18 d3d9:device device.c:1366: Test failed: EnumAdapterModes(D3DFMT_X1R5G5B5) did not return D3DERR_INVALIDCALL (got 00000000)! In essence our tests say that the driver must not support X1R5G5B5. Why? Further notes: * If I then call Direct3D9::CheckDeviceType() for this format I get NOTAVAILABLE which is inconsistent. But then that's exactly what Microsoft's Standard VGA driver does for the R5G6B5 and X8R8G8B8 formats. http://www.winehq.org/pipermail/wine-patches/2013-February/122388.html * See the exact list of formats returned by IDirect3D8::EnumAdapterModes() http://newtestbot.winehq.org/JobDetails.pl?Key=243&log_103=1#k103 Test executable and source: https://bugs.freedesktop.org/attachment.cgi?id=75248 * See the list of formats that IDirect3D8::EnumAdapterModes() claims are supported, and how CheckDeviceType() refuses them. http://newtestbot.winehq.org/JobDetails.pl?Key=249&log_103=1#k103 Test executable and source: https://bugs.freedesktop.org/attachment.cgi?id=75260 * I think it's important to get Spice's QXL driver and Wine's conformance tests to play nice together. First they are both open-source so if one is wrong we should work to resolve that. But also the new WineTestBot is uses QEmu and the QXL driver looks like it will be _the_ paravirtualized(*) graphics driver there. (*) I.e. high performance and most used driver. * See also QXL bug 61227: https://bugs.freedesktop.org/show_bug.cgi?id=61227 -- Francois Gouget <fgouget(a)codeweavers.com>

3 4

Re: A new demangler test?
by Nikolay Sivov 24 Feb '13

24 Feb '13

On 2/24/2013 15:13, Eric Pouech wrote: > Le 24/02/2013 10:18, Nikolay Sivov a écrit : >> On 2/24/2013 10:07, Max TenEyck Woodbury wrote: >>> On 02/23/2013 02:54 AM, Eric Pouech wrote: >>>> Le 21/02/2013 14:33, Max TenEyck Woodbury a écrit : >>>>> Would it be appropriate to add a test to the name demangler that: >>>>> >>>>> 1) Scans all '.dll' and '.spec' files for mangled names, and >>>>> >>>>> 2) Tries to decode those names. >>>>> >>>>> 3) Prints the mangled and decoded names and where they occur. >>>>> >>>>> Success would be that all names decode without the decoder blowing up >>>>> or failing. >>>>> >>>>> >>>>> >>>> adding tests for demangler is good >>>> but you just need to have a set of mangled/unmangled strings for >>>> the test >>>> as core demangler in msvcrt, test should be added here... >>>> (but grabbing the mangled strings shall be left out of the test >>>> itself) >>>> A+ >>>> >>> One of the important aspects of name demangling is that it should work >>> on _all_ the names in the current system. The current test does >>> demangle a list of known strings, but that list was incomplete with >>> respect to all the features used in real names the last time I dug into >>> the details (which was none too recently). >>> >>> Scanning for all the real mangled names not only makes sure that the >>> demangler is working properly, it also assures that all the names used >>> are properly formed and decode to their intended values. >> I don't see a point to extend test data that much, it's enough to add >> some most common cases, >> and add more when something breaks because of it. Otherwise it >> doesn't deserve that much of attention imho. >> >> By the way, do you see something broken or it's just something you >> want to work on? >>> >>> > there are lots of broken stuff (in msvcrt), and demangler in winedump > is ante-deluvian (and doesn't share its code with msvcrt) > A+ Okay, don't know if winedump part is of any use, I mean it tries to provide a sane C name for decorated names, and usually such names are hand-crafted anyway later. Msvcrt being broken is important of course (at least for dbghelp).

1 0

Re: [0/13] Patch series description
by Saulius Krasuckas 23 Feb '13

23 Feb '13

* On Wed, 20 Feb 2013, André Hentschel wrote: > this patch series removes the broken SPARC support. > Reasons: > * It's broken, i wasted enough time already trying to fix that It's sad to hear. Can you be more verbose on brokenness, please? Eg. namely what Sparc platform were you using for development? > * Nobody cares - I sent an e-mail to everyone ever related to > Wine/SPARC based on addresses from our mailing lists - no answer in a > week (and cw also has no customers for it) You didn't catch this then: http://www.winehq.org/pipermail/wine-devel/2004-October/030355.html I care :) > * If someone _would_ care the right thing to do would be a clean SPARC > 64-bit port So, the old port was 32-bit or mixed or what? > * It really can confuse people (more than a ARM/ARM64 port xD) You mean random readers about host platforms Wine runs on;)? > * SPARC is dead on the Desktop :( > And last but not least: I had a bad experience with the Solaris > community regarding Wine/SPARC Oh. Is there any related public messages on the net? It would interesting to read and know those stories. S.

2 6

Re: gdiplus: Remove debug traces from GdipBitmapGetPixel and GdipBitmapSetPixel.
by Vincent Povirk 22 Feb '13

22 Feb '13

> alpha_blend_bmp_pixels() calls them while copying bitmap bits with an > alpha channel. This makes debug logs huge, hard to analyze, and completely > unmanagable in size. GDI+ should be fixed so it doesn't call these functions internally. It's just not an efficient way to render to bitmaps.

1 0

Re: gdi32: Fix the GdiGetCodePage() support ANSI_CHARSET font associated charset.
by Akihiro Sagawa 22 Feb '13

22 Feb '13

On Fri, 22 Feb 2013 11:21:20 +0900, Byeongsik Jeon wrote: > This patch fix a original topic of the wine-bugs #16325. Thanks for your work on this. > +static DWORD get_associated_charset_info(void) > +{ > + static DWORD associated_charset = -1; > + > + if (associated_charset == -1) > + { > + const char *assoc_charset_reg_key = > + "System\\CurrentControlSet\\Control\\FontAssoc\\Associated Charset"; Please use WCHARs and W version of APIs in gdi32/font.c, like: const WCHAR yesW[] = { 'Y', 'E', 'S', 0 }; and so on. > @@ -3615,6 +3615,33 @@ static void update_font_info(void) > } > if (!done) > FIXME("there is no font defaults for codepages %u,%u\n", ansi_cp, oem_cp); > + > + if (RegCreateKeyA( HKEY_LOCAL_MACHINE, > + "System\\CurrentControlSet\\Control\\FontAssoc\\Associated Charset", As far as I know, in SBCS locale, this key doesn't exist. Therefore it should delete in SBCS locale initialization and create the key in DBCS locale initialization. Regards, Akihiro Sagawa

1 0

newtestbot timings
by Joerg-Cyril.Hoehle＠t-systems.com 22 Feb '13

22 Feb '13

Hi, I've looked at some of newtestbot timing results. http://newtestbot.winehq.org/JobDetails.pl?Key=256 It's not too bad, but it's not superb either. >render.c:633: event after Stop.4 average 40.000ms deviation 0.06 from 100 samples That's exactly the expected 40ms, great! >render.c:618: Test failed: Wait iteration 40 gave 102 >render.c:633: event after Stop.1 average 10.925ms deviation 0.36 from 40 samples That's funny. I recently discovered that the Vista-w7 machines downgrade their event rate from 10 to 40.0ms exactly 2 seconds following IAC_Stop. Newtestbot's w8 results indicate that w8 continues sending 10ms events for 400ms after IAC_Stop, then ceases. Current wine*.drv immediately stop sending events after IAC_Stop, so Wine almost implemented w8 behaviour before it existed :-) >render.c:189: Returned periods: 10.1587 ms 3.0000 ms >render.c:633: event after Start.2 average 10.955ms deviation 0.16 from 100 samples >render.c:2200: Released 44800=100x448 -448 frames at 44100 worth 1006ms in 1087ms >render.c:2206: event average 10.878ms deviation 0.16 from 100 samples So the machines do not manage to deliver the expected 10.1587ms period. Well, 10.9 is not that far away. By comparison, a native box meets the average: < event after Start.4 average 10.159ms deviation 0.01 from 100 samples < Released 44800=100x448 -896 frames at 44100 worth 996ms in 1018ms < event average 10.161ms deviation 0.03 from 100 samples The exclusive mode test shows some degradation: >render.c:928: Testing exclusive mode at 44100 >render.c:948: Latency: 15.0113 ms >render.c:967: BufferSize 22528 estimated fragment 662 x 33 = 21846 >render.c:991: Clock Frequency 44100 >render.c:1060: Test failed: Position 5696 too far after stop 100ms -- 129ms 30% off, quite a lot. >render.c:1070: padding 0 past sleep #2 >render.c:1089: padding 0 position 22528 past stop #2 This is worrying. Padding 0 means that within 200ms, the driver emptied its whole half second buffer. That's not physical. Do you have PulseAudio running on the UNIX VM host? It's known from winealsa to eat lots of samples when starting up. By contrast, a native box yields: < padding 13308 past sleep #2 < padding 13251 position 9277 past stop #2 -- 210ms >render.c:1148: position 6208 past 100ms sleep #3 -- 141ms >render.c:1152: Test failed: Position 6208 too far after playing 100ms >render.c:1168: padding 16256 position 6272 past stop #3 -- 142ms >render.c:1173: Test failed: Position 6272 too far after stop 100ms Again, a native box yields values fully in range: < position 4757 past 100ms sleep #3 -- 108ms < padding 17706 position 4822 past stop #3 -- 109ms Interestingly, only exclusive mode is affected by huge deviations, upto 50%. Regarding shared mode, oddly w8 machines exhibit some failures. They are quite small (I think we should raise the margins to fit): render.c:1060: Test failed: Position 39424 too far after stop 100ms -- 111ms render.c:1060: Test failed: Position 43008 too far after stop 100ms -- 121ms render.c:1094: Test failed: Position 78848 too far after playing 200ms --223ms One machine stalled for 44 seconds: >render.c:633: event after Stop.2 average 444.809ms deviation 4294.73 from 100 samples That would have caused a test failure if it had happened at another location within the tests. Regards, Jörg Höhle

1 0

winealsa: Have the MIDI recorder wait in poll(), not snd_seq_event_input().
by Joerg-Cyril.Hoehle＠t-systems.com 22 Feb '13

22 Feb '13

Hi, Johannes Krol wrote: >Joerg, if you want the complete log I can send it to you by PM, it's >about 1.7M. I don't need that for now. What I need are the 119 missing bytes between 17.015:003b:trace:midi:modLongData dwBufferLength=125 ! 17.015:003b:trace:midi:modLongData F0 42 40 ... 00 00 00 Please copy&paste & adapt this code to produce a full hex dump: http://source.winehq.org/source/dlls/winmm/winmm.c#L1066 In particular, I want to know if there's some F7 amid that data (remember that your original patch precisely stopped at a F7...) and what the bytes following that F7 look like. >This could be interpreted to mean that Windows will add the 0xF7 >marker, if it was missing, when any other MIDI message is sent. That's a possible interpretation, however your log snippet shows no sign of sending another message. Do you have MIDI/ALSA debugging tools that can show you whether ALSA truly sends out the 125 bytes? That too would help identify the problem. Thank you, Jörg Höhle

2 6

Re: vbscript: Added support for a few more constants.
by Marvin 22 Feb '13

22 Feb '13

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

1 0

Re: comctl32/treeview: Protect TVM_GETITEM from invalid item pointers
by Alexandre Julliard 22 Feb '13

22 Feb '13

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > @@ -2101,9 +2102,17 @@ TREEVIEW_GetItemT(const TREEVIEW_INFO *infoPtr, LPTVITEMEXW tvItem, BOOL isW) > { > if (!item) return FALSE; > > - TRACE("got item from different tree %p, called from %p\n", item->infoPtr, infoPtr); > - infoPtr = item->infoPtr; > - if (!TREEVIEW_ValidItem(infoPtr, item)) return FALSE; > + __TRY > + { > + infoPtr = item->infoPtr; > + TRACE("got item from different tree %p, called from %p\n", item->infoPtr, infoPtr); > + if (!TREEVIEW_ValidItem(infoPtr, item)) return FALSE; You can't return from a try block. Also have you verified that this is not just masking some other Wine bug? -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: server/advapi32: Report administrator ownership by default for registry objects (try 4).
by Alexandre Julliard 22 Feb '13

22 Feb '13

"Erich E. Hoover" <ehoover(a)mymail.mines.edu> writes: > + else > + { > + struct object_type *type = obj->ops->get_type( obj ); > + static const WCHAR key_type[] = {'K','e','y'}; > + const WCHAR *type_name = NULL; > + data_size_t type_len = 0; > + > + if (!type) goto done; > + type_name = get_object_name( &type->obj, &type_len ); > + release_object( type ); > + if (memcmp(type_name, key_type, type_len) != 0) goto done; > + } You clearly need to spend more time studying how the server works. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: gdi32: Fix the GdiGetCodePage() support ANSI_CHARSET font associated charset.
by Qian Hong 22 Feb '13

22 Feb '13

On Fri, Feb 22, 2013 at 10:21 AM, Byeongsik Jeon <bsjeon(a)hanmail.net> wrote: > This patch fix a original topic of the wine-bugs #16325. Thanks for the great work! I've been waiting for this fix for a really long time :) Out basic Wine test VM does not include Chinese/Japanese Windows, so I submit Byeongsik's patch to the testbot again with Chinese/Japanese Windows included: https://testbot.winehq.org/JobDetails.pl?Key=24496 All tests related to this patch passed (Those failed tests are not related to this patch) I also manually test the patch on Windows with Korean locale and the test case passed as well. Hopes that helps :) -- Regards, Qian Hong - http://www.winehq.org

1 0

Re: [12/13] winedump: Remove SPARC support
by André Hentschel 21 Feb '13

21 Feb '13

Am 21.02.2013 20:55, schrieb Eric Pouech: > Le 20/02/2013 21:11, André Hentschel a écrit : >> - case IMAGE_FILE_MACHINE_SPARC: return "SPARC"; >> >> > Actually this one should be kept, so that dumping such would print the relevant information. > A+ Thought about that for a second, too. But winedump only parses PE dlls, not the winelib ones and there are no SPARC PE dlls out there (Windows was never ported to it). -- Best Regards, André Hentschel

1 0

prelink --reloc-only versus ld -Ttext-segment
by Tijl Coosemans 21 Feb '13

21 Feb '13

Hi, I'm looking into supporting winegcc -Wl,--image-base on FreeBSD. On Linux prelink --reloc-only is used for that but rather than porting prelink it seems easier to pass -Wl,-Ttext-segment to the compiler instead. Is there anything obviously wrong with that? Winedbg shows kernel32 and ntdll are loaded at their respective addresses: ELF 7b800000-7ba41000 Dwarf kernel32<elf> \-PE 7b820000-7ba41000 \ kernel32 ELF 7bc00000-7bccd000 Dwarf ntdll<elf> \-PE 7bc10000-7bccd000 \ ntdll The output of readelf -l ntdll.dll.so looks good too: Elf file type is DYN (Shared object file) Entry point 0x7bc20200 There are 5 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000000 0x7bc00000 0x7bc00000 0xafce4 0xafce4 R E 0x1000 LOAD 0x0afce4 0x7bcb0ce4 0x7bcb0ce4 0x0941c 0x1c2b4 RW 0x1000 DYNAMIC 0x0b0000 0x7bcb1000 0x7bcb1000 0x000e8 0x000e8 RW 0x4 GNU_EH_FRAME 0x0960bc 0x7bc960bc 0x7bc960bc 0x04144 0x04144 R 0x4 GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x4

1 0

prelink --reloc-only versus ld -Ttext-segment
by Tijl Coosemans 21 Feb '13

21 Feb '13

Hi, I'm looking into supporting winegcc -Wl,--image-base on FreeBSD. On Linux prelink --reloc-only is used for that but rather than porting prelink it seems easier to pass -Wl,-Ttext-segment to the compiler instead. Is there anything obviously wrong with that? Winedbg shows kernel32 and ntdll are loaded at their respective addresses: ELF 7b800000-7ba41000 Dwarf kernel32<elf> \-PE 7b820000-7ba41000 \ kernel32 ELF 7bc00000-7bccd000 Dwarf ntdll<elf> \-PE 7bc10000-7bccd000 \ ntdll The output of readelf -l ntdll.dll.so looks good too: Elf file type is DYN (Shared object file) Entry point 0x7bc20200 There are 5 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000000 0x7bc00000 0x7bc00000 0xafce4 0xafce4 R E 0x1000 LOAD 0x0afce4 0x7bcb0ce4 0x7bcb0ce4 0x0941c 0x1c2b4 RW 0x1000 DYNAMIC 0x0b0000 0x7bcb1000 0x7bcb1000 0x000e8 0x000e8 RW 0x4 GNU_EH_FRAME 0x0960bc 0x7bc960bc 0x7bc960bc 0x04144 0x04144 R 0x4 GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x4

1 0

Re: webservices: Add new dll
by Hans Leidekker 21 Feb '13

21 Feb '13

On Thu, 2013-02-21 at 18:47 +1100, Alistair Leslie-Hughes wrote: > +#include "wine/debug.h" > + > +WINE_DEFAULT_DEBUG_CHANNEL(wincodecs); That channel is already taken :)

1 0

Re: comctl32/listview: fix selection in ownerdata listview
by Nikolay Sivov 21 Feb '13

21 Feb '13

On 2/21/2013 02:19, Daniel Jelinski wrote: > /* disable per item notifications on LVS_OWNERDATA style > FIXME: single LVN_ODSTATECHANGED should be used */ > bOldChange = infoPtr->bDoChangeNotify; > - if (infoPtr->dwStyle & LVS_OWNERDATA) infoPtr->bDoChangeNotify = FALSE; > + /*if (infoPtr->dwStyle & LVS_OWNERDATA) infoPtr->bDoChangeNotify = FALSE;*/ What's a problem in fixing this properly? This change could break something potentially, it was disabled for a purpose of fixing some real application as I remember.

2 2

Re: Implement pinned memory for ATI where buffer regions are slow
by Henri Verbeet 20 Feb '13

20 Feb '13

On 17 February 2013 07:17, Stanislaw Halik <sthalik(a)misaki.pl> wrote: > This one should be better. Sorry about indentation. Much, much FPS, and > supposedly no loss of functionality. > I didn't really review this, but I think any extension that allows "... including program or even system termination." from regular user space is terrible. (And yes, your formatting is also messed up.) I think Stefan has said this before, but what really needs to happen is that you (or someone else) figure out where the actual issue with ARB_map_buffer_range is, and either get that fixed in Wine, or file a bug for fglrx.

3 5

Failing tests in the Japanese and Hebrew languages
by Francois Gouget 20 Feb '13

20 Feb '13

I have noticed some test failures that only happen when I set the locale and display language to Japanese and/or Hebrew in Windows 7. Let me know if I should create bugs for these. * comctl32:listview (Hebrew and Japanese) listview.c:3822: Test failed: Expected 96, got 112 listview.c:4751: Test failed: Expected 96, got 112 Both correspond to the use of GetDeviceCaps(LOGPIXELSX) so something must be wrong there: todo_wine expect(((GetDeviceCaps(hdc, LOGPIXELSX) + 15) / 16) * 16, rect.right); todo_wine expect(((GetDeviceCaps(hdc, LOGPIXELSX) + 15) / 16) * 16, ret); * riched20:editor (Hebrew only) editor.c:586: Test failed: EM_POSFROMCHAR reports x=5, expected 8 editor.c:609: Test failed: EM_POSFROMCHAR reports x=5, expected 8 editor.c:640: Test failed: pt.x = 117 All three are related to testing positions past the end of text. Here the fact that Hebrew is RTL probably breaks the test. * rpcrt4:rpc (Japanese only) rpc.c:171: Test failed: DceErrorInqTextA(deviation...) Based on the comment it does not seem surprising that this would be language-specific: /* One for which FormatMessage should succeed but * DceErrorInqText should "fail" * 3814 is generally quite a long message */ * shell32:progman_dde (Hebrew and Japanese) progman_dde.c:377: Test failed: Window "?????" was not created in 45 seconds - assumed failure. [S_G:11] Based on the 'S_G:11' this would correspond to this line: ShowGroupTest(instance, hConv, "[ShowGroup(Startup,0)]", DMLERR_NO_ERROR, "Startup", StartupTitle, TRUE, DDE_TEST_SHOWGROUP|testnum++); * shlwapi:ordinal (Hebrew only) ordinal.c:1721: Test failed: expected (ùáú 16 ôáøåàø 2013), got (??? 16 ?????? 2013) ordinal.c:1729: Test failed: expected (ùáú 16 ôáøåàø 2013), got (??? 16 ?????? 2013) ordinal.c:1743: Test failed: expected (ùáú 16 ôáøåàø 2013) got (??? 16 ?????? 2013) for date part ordinal.c:1757: Test failed: expected (ùáú 16 ôáøåàø 2013) got (??? 16 ?????? 2013) for date part ordinal.c:1929: Test failed: expected (L"\05e9\05d1\05ea 16 \05e4\05d1\05e8\05d5\05d0\05e8 2013") got (L"\200f\05e9\05d1\05ea \200f16 \200f\05e4\05d1\05e8\05d5\05d0\05e8 \200f") for date part ordinal.c:1955: Test failed: expected (L"\05e9\05d1\05ea 16 \05e4\05d1\05e8\05d5\05d0\05e8 2013") got (L"\200f\05e9\05d1\05ea \200f16 \200f\05e4\05d1\05e8\05d5\05d0\05e8 \200f") for date part Note that while the above test was run with a Hebrew locale and display language, I get similar errors when running the test in the Japanese locale with the French display language: ordinal.c:1721: Test failed: expected (2013N216ú), got (2013?2?16?) ordinal.c:1729: Test failed: expected (2013N216ú), got (2013?2?16?) ordinal.c:1743: Test failed: expected (2013N216ú) got (2013?2?16?, 8) for date part ordinal.c:1757: Test failed: expected (2013N216ú) got (2013?2?16?, 8) for date part -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ E-Voting: It's not the people who vote that count. It's the people who count the votes.

3 6

Re: advapi32: Report administrator ownership by default for registry objects (try 3).
by Alexandre Julliard 19 Feb '13

19 Feb '13

"Erich E. Hoover" <ehoover(a)mymail.mines.edu> writes: > The attached patch fixes an issue where the Opera installer expects > registry keys to return ownership information (Bug #32904), concluding > the cleanup of [Get|Set]NamedSecurityInfo. This patch addresses the > issue by ensuring that NULL owner and group information is never > returned for registry keys and instead returns the Administrators SID > (S-1-5-32-544) when this information is unavailable, which is > sufficient to keep the Opera installer from encountering an error. > The included test shows that this behavior is the case for system keys > on Windows, which returns the Administrators SID for system registry > keys (such as HKLM\Software). Surely this is not specific to GetNamedSecurityInfo. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [14/14] gdiplus: Reimplement GdipDrawPath.
by Vincent Povirk 19 Feb '13

19 Feb '13

> Please don't apply this [14/14] patch, it causes a test failure. I'm sending > it to show how this is going to look like eventually. Yeah, GdipWidenPath isn't good enough for this yet. But I agree this is the way to go, and the rest of the series looks good.

2 2

Re: [PATCH 5/8] vbscript: Added RegExp.Execute tests
by Marvin 19 Feb '13

19 Feb '13

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

2 1

Re: [PATCH 7/8] vbscript: Added tests for invalid parameters in regular expression functions
by Marvin 19 Feb '13

19 Feb '13

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

2 1

Re: [PATCH 5/8] vbscript: Added RegExp.Execute tests
by Marvin 19 Feb '13

19 Feb '13

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

1 0

IE 6 related urlmon:protocol failures
by Francois Gouget 18 Feb '13

18 Feb '13

I have investigated the following test failure on the new WineTestBot: urlmon: protocol.c:1051: Test failed: hrResult = 800401e4, expected: 00000000 protocol.c:1056: Test failed: dwError == ERROR_SUCCESS protocol.c:613: Test failed: expected ReportData The results from test.winehq.org show that they only happen on systems that have urlmon.dll version 6.0, which I guess corresponds to Internet Explorer 6.0. More specifically: * The test detects systems that have Internet Explorer 5.5 or older, based on missing functions, declares too old and skips the tests: 5.0.3700.6705 wtb-w2kassp4 5.0.3888.1400 wtb-w2kprosp4 5.50.4807.2300 fg-win2000-ie55 * The test runs and fails on these systems: 6.0.2800.1649 fg-win2000-up1 6.0.2800.1649 fg-win2000-uplast 6.0.2900.3562 fg-winxp-2sp 6.0.2900.3698 wtb-wxpmce 6.0.2900.6049 wtb-wxphmnlsp3 * The test runs and succeeds on systems that have urlmon 7.0 or greater: 7.0.6000.16850 fg-winxp-2spie7 7.0.6000.16850 fg-winxp-3sp 8.0.6001.18806 fg-winxp-3spie8 8.0.6001.19100 fg-winxp-last So I will be applying the latest updates to the new TestBot's Windows XP VM and that should solve the issue in that case. However I think the test should still not fail. So I'm looking for a volunteer to either get the test to succeed with urlmon 6.0, or find a way to detect it and skip these three tests. -- Francois Gouget <fgouget(a)codeweavers.com>

2 4

Re: [PATCH 1/2] wininet: Address string should never be converted to UNICODE in status notifications
by Marvin 18 Feb '13

18 Feb '13

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

2 1

Re: msi: Don't ignore failure to remove an existing product.
by Alexandre Julliard 18 Feb '13

18 Feb '13

Hans Leidekker <hans(a)codeweavers.com> writes: > --- > dlls/msi/action.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) It fails here: ../../../tools/runtest -q -P wine -M msi.dll -T ../../.. -p msi_test.exe.so action.c && touch action.ok action.c:6397: Test failed: Expected ERROR_SUCCESS, got 2 action.c:6400: Test failed: Expected ERROR_SUCCESS, got 2 make[1]: *** [action.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

1 0

winmm: More compatible waveIn/Out[Un]Prepare WHDR_* flag handling.
by Joerg-Cyril.Hoehle＠t-systems.com 18 Feb '13

18 Feb '13

Hi, One thing to note is a slight change when Prepare is called twice in a row. When the ACM is used, the former Wine code would prepare the ACM again, leaking the memory of the previous preparation. Now that code is by-passed as the header is prepared exactly once, the first time. What if the app changes dwBufferLength in between? We don't know what exactly native does. My tests only show that *some* code is by-passed, because when WHDR_PREPARE is found already set, the other flags are not repeatedly cleared. All calls return NOERROR. The 16 bit code has a comment http://source.winehq.org/source/dlls/mmsystem.dll16/message16.c#L430 > /* dwBufferLength can be reduced between prepare & write */ > if (... && wh32->dwBufferLength < wh16->dwBufferLength) { I've checked neither - what native does in that case when the ACM is involved, nor - how Wine drives the ACM in that case. It's reasonable to assume that only dwBufferLength at the time of waveOutWrite should be relevant. Let's hope that dwBufferLength from the time of Prepare doesn't matter in Wine's 32 bit ACM. Regards, Jörg Höhle

1 0

Re: [PATCH 1/2] wined3d: Make (wined3d_)surface_depth_blt_fbo handle locations other than SFLAG_INTEXTURE.
by Henri Verbeet 18 Feb '13

18 Feb '13

On 17 February 2013 18:10, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > @@ -6168,18 +6172,10 @@ HRESULT surface_load_location(struct wined3d_surface *surface, DWORD location, c > > if (surface->resource.usage & WINED3DUSAGE_DEPTHSTENCIL) > { > - if (location == SFLAG_INTEXTURE) > - { > - struct wined3d_context *context = context_acquire(device, NULL); > - surface_load_ds_location(surface, context, location); > - context_release(context); > - return WINED3D_OK; > - } > - else > - { > - FIXME("Unimplemented location %s for depth/stencil buffers.\n", debug_surflocation(location)); > - return WINED3DERR_INVALIDCALL; > - } > + struct wined3d_context *context = context_acquire(device, NULL); > + surface_load_ds_location(surface, context, location); > + context_release(context); > + return WINED3D_OK; > } This is probably wrong (and the original code is probably questionable too), surface_load_ds_location() is only really meant for onscreen <-> offscreen blits. The original code is meant for the case where AlwaysOffscreen is disabled and a depth stencil is used as texture. The implication there is that the only possible locations are SFLAG_INTEXTURE and SFLAG_INDRAWABLE, it doesn't really work with multisampling. Fortunately you can't directly texture from multisampled depth stencil surfaces either. In principle we could make surface_load_ds_location() the generic function for depth / stencil location transfers, but currently it isn't. If you're hitting it with the RESZ code it probably only works by accident.

2 2

Re: Wine release 1.5.24
by Gennady Telegin 17 Feb '13

17 Feb '13

Hi, I want to unsubscribe from this list, how to do it? Best, Gennady Telegin On Sat, Feb 16, 2013 at 12:30 AM, Alexandre Julliard <julliard(a)winehq.org>wrote: > The Wine development release 1.5.24 is now available. > > What's new in this release (see below for details): > - Keyboard and mouse wheel support in the Mac driver. > - Regular expression support in VB Script. > - Many RichEdit code cleanups. > - Various bug fixes. > > The source is available from the following locations: > > http://prdownloads.sourceforge.net/wine/wine-1.5.24.tar.bz2 > http://mirrors.ibiblio.org/wine/source/1.5/wine-1.5.24.tar.bz2 > > Binary packages for various distributions will be available from: > > http://www.winehq.org/download > > You will find documentation on http://www.winehq.org/documentation > > You can also get the current source directly from the git > repository. Check http://www.winehq.org/git for details. > > Wine is available thanks to the work of many people. See the file > AUTHORS in the distribution for the complete list. > > ---------------------------------------------------------------- > > Bugs fixed in 1.5.24 (total 38): > > 6512 power-tab-editor freezes at end of a song > 8598 msvcrt file IO functions do not handle unicode properly in text > mode > 12908 Battle Zone I does not start. > 16685 redraw problem in AIM_675 > 17380 CListCtrl: wrong icon spacing > 17762 Citavi: Application is very slow > 17763 Citavi: mouse doesn't catch links > 18079 AutoCorect: does not properly display custom checkboxes made by > Alcinoe > 20294 sigma photo pro crashes in X11DRV_DIB_DeleteDIBSection > 24089 EverQuest: Escape to Norrath: login screen is blank without > native ie6 > 24315 Verizon Media Manager crashes on exit (VZMediaagent.exe > 24361 Crashday: game is unusably slow during gameplay > 24474 Simpsons Hit & Run sound bug > 24554 Black screen in Everquest 2 (lighting issue?) > 25576 Microsoft Flight Simulator X: Demo/Deluxe Edition, menu blank > without native ie7 > 25584 Racedriver:GRID sound hardware acceleration not working > 25958 DreamStation 1 free music tracker visually freezes under some > conditions > 27011 Lucent Heart: patcher window is blank > 27905 HUNTED The Demon Forge: Sound does not work in the game (in > movies this works) > 29718 IE4 setup wants wininet.dll.LoadUrlCacheContent > 29873 Guild Wars: Water graphic is missing > 30008 Resource Hacker logo on about window has black background > 30183 Fchart installation crashes > 30246 EA Origin:Crashes when using openssl 1.0.1 > 30839 BSTR cache corrupts most of cached BSTR entries > 31308 Remote Tools for Visual Studio 2012 RC installer for Windows on > ARM (WoA) crashes because TPIDRURW (user TLS register) needs to be set to > TEB address > 31706 Sacred Underworld: Some models glow like a Christmas tree > 31977 YoudaoDict crash at start > 32520 EVE Online and other games want d3d11.dll.D3D11CreateDevice > 32669 Ghost Master: invisible mouse pointer unless 'Enhanced Cursor' > option selected > 32808 installer of PPTV: needs unimplemented > atl100.dll.AtlComModuleRegisterClassObjects > 32818 Adrenalin Extreme Show: launcher.exe has repainting issues > 32842 TurboTax 2012 needs shlwapi.dll IsInternetESCEnabled stub > 32858 Crash dialog Details button Russian text doesn't fit > 32862 Microsoft Expression Design 4 (Free Version) needs > WindowsCodecsExt.dll (Microsoft Windows Codecs Extended Library) > 32882 Grand Theft Auto IV doesn't start, aborts with a GLX error. > 32909 QQDownload 3.9 needs unimplemented msvcr80.dll._wstat32i64 > 32929 Microsoft Expression Design 4 (Free Version) needs > windowscodecsext.dll.WICCreateColorTransform_Proxy > > ---------------------------------------------------------------- > > Changes since 1.5.23: > > Akihiro Sagawa (1): > gdi32: Ensure a fixed-pitch full-width character has double advance > of a half-width character. > > Alexander Morozov (1): > ole32: Avoid a deadlock when a being loaded DLL calls > CoRegisterClassObject from its DLL_PROCESS_ATTACH handler. > > Alexandre Julliard (28): > winemac: Don't move off-screen windows to a random position. > gdi32: Return the correct module handle for the initial display > driver load. > explorer: Retrieve the graphics driver module from gdi32. > explorer: Return a simple boolean instead of a window in the > wine_create_desktop entry point. > wintab32: Retrieve the graphics driver module from gdi32. > imm32: Retrieve the graphics driver module from gdi32. > winex11: Ignore color key and exposures when using the null surface. > user32: Avoid releasing a potentially null pointer. > server: Also exclude the top-level client rectangle for windows that > have a pixel format. > server: Return the window paint flags in the get_visible_region > request. > user32: Don't paint to the surface if the window has a pixel format, > regardless of the state of the top parent. > wininet: Don't reset the available size after the async has been > queued. > user32: Prefer loading color cursors in LoadImage. > ntdll: Add a helper function to check that a fault address lies in a > known virtual memory view. > ntdll: Check for invalid %gs value in 32-bit code. > winex11: Preserve the client window when changing the window visual. > server: Don't support debug registers in ptrace if sys/user.h is > missing. > loader: Define our own auxv structure. > loader: Rename the elf_hash function to avoid conflicts. > odbccu32: Remove an unnecessary source file. > twain_32: Remove an unnecessary DllMain entry point. > cryptnet: Remove an unnecessary DllMain entry point. > dpnhpast: Remove an unnecessary DllMain entry point. > iphlpapi: Remove an unnecessary DllMain entry point. > ktmw32: Remove an unnecessary DllMain entry point. > sensapi: Remove an unnecessary DllMain entry point. > usp10: Remove an unnecessary DllMain entry point. > wtsapi32: Remove an unnecessary DllMain entry point. > > Alistair Leslie-Hughes (1): > fusion: Return correct error for null public token. > > Andrew Talbot (8): > jscript: Avoid signed-unsigned integer comparisons. > mapi32: Avoid signed-unsigned integer comparisons. > kernel32: Avoid signed-unsigned integer comparisons. > mscoree: Avoid signed-unsigned integer comparisons. > mmdevapi: Avoid signed-unsigned integer comparisons. > mlang: Avoid signed-unsigned integer comparisons. > msdaps: Avoid signed-unsigned integer comparisons. > msctf: Avoid signed-unsigned integer comparisons. > > André Hentschel (4): > ntdll: Set TPIDRURW to TEB on thread init for ARM. > make_xftmpl: Avoid comparing a char with EOF. > winedbg: Add PState to cpu_register_map for ARM64. > ntdll: Implement RtlUnwind for ARM. > > Aric Stewart (6): > usp10: Fix typo with Script_Khmer_Numeric. > usp10: Split the core Itemize function out to be able to support > differences between the normal and OpenType versions. > usp10: Update diacritical script handling for non OpenType > Itemization. > usp10: Free default_language items when freeing script cache. > usp10: Fix memory leak when a font has 0 languages, scripts or > features. > usp10: Correct error with ScriptLayout log2vis. > > Austin English (4): > windowscodecsext: Add a stub dll. > shlwapi: Add a stub for IsInternetESCEnabled. > d3d11: Add a stub for D3D11CreateDevice. > wininet: Add a stub for LoadUrlCacheContent. > > Daniel Jelinski (6): > comctl32/listview: Correct icon spacing calculation when set to 0 or > -1. > comctl32/listview: Always use large icon size when calculating icon > spacing. > comctl32/listview: Do not touch icon spacing if set explicitly. > user32: Fix CopyImage implementation when changing cursor to icon. > comctl32/listview: Better handling of custom colors in report view. > comctl32/listview: Fix LVM_SETICONSPACING on 64bit machines. > > Detlef Riekenberg (2): > advapi32/tests: Skip tests on non-English systems. > kernel32/tests: Skip tests on non-English systems. > > Dmitry Timoshkov (14): > wbemprox: Free name in create_signature (Coverity). > comctl32: Test appropriate tool window for active state. > gdi32: Add support for 16-bit QUERYESCSUPPORT queries. > gdi32: Add a bunch of tests for CreateDC/ResetDC with a custom > DEVMODE. > winspool.drv: Turn macros into helper functions. > wineps.drv: Add DEVMODE dumping to make debugging device state > easier. > winspool.drv: There is no need to speculate about wineps.drv default > DEVMODE. > gdi32: Make sure that actual clipping region is updated for a EMF DC. > gdi32: Add more EMF clipping tests. > gdi32: OffsetClipRgn should update actual clipping region for a EMF > DC. > gdi32: IntersectClipRect should update actual clipping region for a > EMF DC. > gdi32: ExcludeClipRect should update actual clipping region for a > EMF DC. > gdi32: SelectClipPath should update actual clipping region for a EMF > DC. > kernel32: There is no need for lock/unlock heap in GlobalAlloc. > > Erich Hoover (2): > advapi32: Support registry objects in GetNamedSecurityInfo. > advapi32: Support registry objects in SetNamedSecurityInfo. > > Francois Gouget (5): > kernel32/tests: Reduce the size of the console buffer to speed up > the tests. > rpcrt4/tests: Trace the GUID when it is wrong. > d3d11: Make debug_d3d_driver_type() static. > ws2_32/tests: Fix the GetAcceptExSockaddrs() test. > winetest: Trace the time it takes to run each test. > > Frédéric Delanoy (1): > msi: Fix memory leak (coverity). > > Hans Leidekker (12): > windowscodecs: Implement IWICColorContext::InitializeFromFilename. > windowscodecs: Add a stub IWICColorTransform implementation. > windowscodecs: Convert the source bitmap to the requested pixel > format in IWICColorTransform::Initialize. > windowscodecs: Implement > IWICComponentFactory::CreateDecoderFromFileHandle. > wbemprox: Trace the qualifier value in IWbemClassObject::GetNames. > windowscodecsext: Implement WICCreateColorTransform_Proxy and > IWICColorTransform_Initialize_Proxy. > windowscodecs: Implement IWICBitmapFrameDecode::GetColorContexts for > TIFF images. > msiexec: Add /unregserver support. > msiexec: Convert DoRegServer to Unicode. > wininet/tests: Fix a test failure. > msi/tests: Move a couple of tests from install.c to msi.c. > msi: Don't remove products if msidbUpgradeAttributesOnlyDetect is > set. > > Henri Verbeet (2): > wined3d: Add WINED3DFMT_INST to the format table. > configure: Include Xlib.h before Xrandr.h. > > Huw Davies (23): > riched20: Actually pass the ANSI string to the break proc. > riched20: Pass the character ptr and string length directly to the > break proc helper. > riched20: Pass a character ptr and length to SplitParagraph. > riched20: Pass character ptrs to the whitespace finding functions. > riched20: Move the text to the paragraph level. > riched20: Move SplitRun to wrap.c and make it static. > riched20: Move the split point calculation to wrap.c. > riched20: Move run extent calculation to wrap.c. > riched20: The run width is always passed so we don't need to > calculate it again. > riched20: Pass the run to the text drawing routine. > riched20: Move underline pen creation to a helper function. > riched20: Move y offset calculation to a helper function. > riched20: Move text color determination to a helper function. > riched20: Move the white space painting operations to a common > function. > riched20: Remove the special case tab handling now that we handle > that in draw_space. > riched20: Make it possible to perform point -> char conversion while > holding a context. > riched20: The string len parameter is no longer necessary. > riched20: Use the point from char helpers to calculate the selection > rectangle. > riched20: Simplify selection painting by drawing a selected run > twice with appropriate clipping. > riched20: Move underline drawing to a common function. > riched20: Move the range clamping to the helper now that the range > isn't used later on. > riched20: Move the password string hack to just before it's used. > riched20: Use ME_PointFromChar to calculate the caret position. > > Jacek Caban (13): > atl100: Added AtlComModuleRegisterClassObjects implementation (based > on AtlModuleRegisterClassObjects). > oleaut32: COM clean up of ITypeLib2 interface implementation. > mshtml: Use VT_ERROR as return type in DispCallFunc call. > oleaut32: Return error if VT_HRESULT is used as return type in > DispCallFunc. > urlmon: Clean up handling tested URLs. > urlmon: Fixed QueryInfo tests during BINDSTATUS_PROXYDETECTING > notification. > urlmon: Skip reported_url tests when binding to object. > urlmon: Fixed tests on IEs that report BINDSTATUS_DECODING. > oleaut32: Don't free a string in SysFreeString if it's already in > cache. > oleaut32: Added some SysFreeString tests. > urlmon: Allow available_bytes to be set before protocol_continue > call. > wininet: Set available bytes in InternetQueryDataAvailable even if > it ends up in async call. > vbscript: Added support for a few more constants. > > Jactry Zeng (4): > msvcr100: Added _wstat32i64 implementation. > msvcr100: Added _stat32i64 implementation. > msvcr80: Sync _wstat32i64 and _stat32i64 implementation. > msvcr90: Sync _wstat32i64 and _stat32i64 implementation. > > Jeff Latimer (2): > wmvcore: Add stub implementation for WMCreateEditor. > wmvcore: Fix a typo. > > Juan Lang (2): > iphlpapi: Fix HRESULT/win32 error code confusion. > cryptui: Use add_usage_to_oid correctly. > > Julian Rüger (1): > po: Update German translation. > > Jörg Höhle (4): > ntdll: Use the monotonic time counter also for timer queues. > winmm: More compatible midiIn/Out[Un]Prepare MHDR_* flag handling. > winmm: More compatible waveIn/Out[Un]Prepare WHDR_* flag handling. > winmm: Handle GetTickCount overflow in MIDI player. > > Ken Thomases (25): > winemac: Implement ScrollDC(). > winemac: Implement support for minimizing windows. > winemac: Build a map from Mac virtual key codes to Win32 vkeys and > scan codes based on Mac keyboard layout. > winemac: Rebuild key map when Mac keyboard layout changes. > winemac: Generate KEY_PRESS/RELEASE events from Cocoa key events. > user32: In TranslateMessage, handle ToUnicode returning 2 or more > chars. > winemac: Implement ToUnicodeEx(). > winemac: Ignore Cocoa's window frame adjustments for off-screen > windows. > winemac: Implement Beep(). > winemac: Implement MapVirtualKeyEx(). > winemac: Implement VkKeyScanEx(). > winemac: Implement GetKeyNameText(). > winemac: Implement fake support for the active Windows keyboard > layout. > winemac: Implement SysCommand() to prevent Alt keypresses from > activating system menu. > winemac: Add WineApplication methods to convert from Cocoa to Win32 > coordinate space. > winemac: Implement MOUSE_MOVED(_ABSOLUTE) events. > winemac: Process clicks in an inactive window in addition to > activating it. > secur32: On Mac, add support for cipher suites defined in 10.8 SDK. > user32: Improve mouse wheel scrolling in edit control. > user32: Improve mouse wheel scrolling in listbox control. > comctl32: Eliminate redundant local variable (gcWheelDelta == > -wheelDelta). > comctl32: Improve mouse wheel scrolling in listview control. > comctl32: Improve mouse wheel scrolling in treeview control. > winemac: Implement MOUSE_SCROLL events. > winemac: Prevent Cocoa from consuming certain key-down events. > > Ludger Sprenker (1): > windowscodecs: Add enum type WICTiffCompressionOption. > > Marcus Meissner (1): > comdlg32: Free files on errorpath (Coverity). > > Michael Stefaniuc (20): > ddraw/tests: Use assignment instead of memcpy to copy structs. > crypt32: Use assignment instead of memcpy to copy structs. > wined3d: Remove ERR() on HeapAlloc failure for small sizes known at > compile time. > ieframe: Let C look like C. > krnl386.exe16: Let C look like C. > gphoto2.ds: Let C look like C. > iphlpapi: Let C look like C. > qedit: Let C look like C. > d3drm: Let C look like C. > riched20: Let C look like C. > usp10: Let C look like C. > d3d10core: Remove ERR() on HeapAlloc failure for small sizes known > at compile time. > d3d8: Remove ERR() on HeapAlloc failure for small sizes known at > compile time. > d3d9: Remove ERR() on HeapAlloc failure for small sizes known at > compile time. > d3dx9_36: Remove ERR() on HeapAlloc failure for small sizes known at > compile time. > d3drm: Remove ERR() on HeapAlloc failure for small sizes known at > compile time. > amstream: Remove ERR() on HeapAlloc failure for small sizes known at > compile time. > d3dcompiler_43: Remove ERR() on HeapAlloc failure for small sizes > known at compile time. > dmime: Remove ERR() on HeapAlloc failure for small sizes known at > compile time. > wineoss.drv: Use offsetof to calculate the size of a struct with > variable length array. > > Nikolay Sivov (3): > oledb32: Add a table of init properties, support Persist Security > Info switch in init string. > xmllite: Store start data pointer for comments. > xmllite: Basic test for chunk value read vs full value read. > > Nozomi Kodama (1): > d3dx9: Use const instead of CONST. > > Piotr Caban (11): > jscript: Rename jsheap_t to heap_pool_t. > jscript: Don't use jsstr_t in JSRegExp structure. > jscript: Don't use jsstr_t in js_NewRegExp. > jscript: Move code operating on JSRegExp out of do_regexp_match_next > function. > jscript: Make context generic in internal regular expression > functions. > jscript: Moved generic regular expressions code to separate file. > vbscript: Added IRegExp2 stub. > vbscript: Added IRegExp2_QueryInterface tests. > vbscript: Added partial implementation of IDispatch methods in > IRegExp2. > vbscript: Added IRegExp2::Pattern implementation. > vbscript: Rename vbsheap to heap_pool. > > Roman Dadkov (3): > ole32/tests: Add test for SetClientSite. > mpr/tests: Test to check the return values of WNetGetUniversalNameA. > ole32/tests: Add test for OleRun. > > Stefan Dösinger (2): > wined3d: Use the ARBfp ffp pipeline only if ARBfp is supported. > wined3d: Reserve one vs constant on r200. > > Vijay Kiran Kamuju (1): > msvcr90: Update the manifest version. > > -- > Alexandre Julliard > julliard(a)winehq.org > >

2 1

Re: [PATCH] Support a protection scheme which reset the GS selector - v2
by Sergey Guralnik 17 Feb '13

17 Feb '13

On 2013-02-07 17:00, Alessandro Pignotti wrote: >+ opcode=(unsigned char*)context->Eip; >+ if (*opcode==0x65 && /* GS segment instruction prefix */ >+ context->SegGs!=ntdll_get_thread_data()->gs) Segment-override prefix may be preceded by repeat or operand-size override prefixes. So instruction that refers to GS-segment doesn't always starts with 0x65. -- Sergey

3 2

Re: [PATCH] ntdll: Support a protection scheme which reset the GS selector - v3
by Ken Thomases 17 Feb '13

17 Feb '13

On Feb 17, 2013, at 4:18 AM, Alessandro Pignotti wrote: > Third attempt > > ---------------- > > Hi everyone, > > I've found two different games: > > -) Of orcs and men > -) The testament of sherlock holmes > > which are using a protection scheme which reset the GS segment selector, > possibly to confuse virtual machines. Since on linux the GS selector is > used internally by glibc the game would crash as soon as a native glibc > method is called by wine. The proposed patch tries to workaround this > problem by restoring the GS to a known working value in wine's SEGFAULS > handler and try the instruction again. > > Regards, > Alessandro Pignotti > > <0001-ntdll-Support-a-protection-scheme-which-reset-the-GS-v3.patch> Didn't Alexandre already fix this with <http://source.winehq.org/git/wine.git/?a=commit;h=64ddb263d25dfceeeae8457a0…>? -Ken

1 0

Fwd: Re: Fix catalyst brain damage to speed up Falcon BMS 2x
by Stanisław Halik 16 Feb '13

16 Feb '13

Ben allowed me to forward this email. Kudos to him for all the knowledge his brainbox contains! -------- Original Message -------- Subject: Re: Fix catalyst brain damage to speed up Falcon BMS 2x Date: Sat, 16 Feb 2013 11:20:35 -0500 From: Ben Supnik <bsupnik(a)xsquawkbox.net> To: Stanislaw Halik <sthalik(a)misaki.pl> Hi Guys, I'm afraid I don't know enough about the _specific_ situation you guys are seeing. I can tell you guys a few things from my GL work: 1. The ATI OpenGL Linux team is pretty accessible; do you guys have anyone in the fglrx beta program? 2. What we found was that for stream-draw buffers that need to be orphaned, mapped, unmapped and drawn, there was a fixed overhead in the ATI drivers compared to NV; this 'performance gap' is cross-platform - both NV and ATI use the same GL stack (more or less) for Windows and Linux, and we saw the slow-down on both. 3. We originally were using map buffer (not map buffer range) with a NULL glBufferData to "orphan" the buffer (the equivalent of d3d map-discard). I think I tried MBR and it didn't fix it - both were expensive because the fundamental memory mapping operation was slow. 4. The slowness was in milliseconds, e.g. "this hits our fps by 20% or 30%" - but it wasn't "this is 3x slower because it stalled the GPU." So if you're seeing truly face-meltingly bad performance, like a total pipeline stall, you have a different bug. 5. As a general statement, the original glMapBuffer is subject to a lot of heuristic behavior in the drivers; app developers are very fast and loose with how they use it, so the driver vendors tend to try to make it do the fastest, most useful, least crash-y thing because the apps use it like monkeys on type-writers. By comparison, MBR came out later and has much more specific semantics for particular optimizations, as a result, the MBR implementation will often do exactly what you say, _even_ if it's slower. Getting even one flag wrong in MBR can cause it to hit a face-meltingly slow path. We worked around the perf cost of mapping a buffer on ATI hw by using pinned memory (but we do have a Linux-only bug where we get corrupt geometry with pinned memory - it works on Windows); I have some todo items to investigate the problem more thoroughly now. Cheers Ben On 2/16/13 5:47 AM, Stanislaw Halik wrote: > On 2013-02-16 09:04, Stefan Dösinger wrote: >> What you really want to do is figure out why GL_ARB_map_buffer_range >> is slow on fglrx, and make sure that the problem is really fglrx >> specific. I fixed a number of dynamic buffer performance problems in >> the past months, but there are still problems if we're falling back >> to draw_strided_slow for some reason, like fixed function material >> tracking. > > Thanks for reviewing this. > > Going to ask Ben Supnik from Laminar Research (X-Plane developer) and > BCC him, since he has apparently run into the same issue. There's much > info of fglrx woes (not really Linux specific, either) on > http://developer.x-plane.com/ > > He said publicly to be in contact with AMD themselves, and been friendly > to OSS by releasing an X-Plane Linux version, as well as overall cool > fellow. > > Ben, Please help! > >> Other than being wrong conceptually, you're disabling dynamic buffers >> the wrong way: The "proper" way would be to add a quirk to the >> quirk_table in directx.c that removes ARB_map_buffer_range from the >> list of supported extensions if the driver vendor is AMD. > > Like this? Patch attached. > > I've run into hard GPU hangs with fglrx 13.2, no VT switch either. This > helps: > > [Software\\Wine\\Direct3D] > "DirectDrawRenderer"="gdi" > "Multisampling"="disabled" > "OffscreenRenderingMode"="fbo" > "UseGLSL"="enabled" > > Lack of GLSL disables HDR apparently. > > Without GDI, there's some nasty display corruption on FBOs. > > Also Catalyst likes to hang display when switching from 3D to 2D and VT > switch helps. > > But with all this busywork, performance is near-native. Catalyst at > least supports indirect addressing (whatever that means) and doesn't > choke on > 128 temps... FYI Mesa bug submitted: > > https://bugs.freedesktop.org/show_bug.cgi?id=55420 > > -sh > -- Scenery Home Page: http://scenery.x-plane.com/ Scenery blog: http://www.x-plane.com/blog/ Plugin SDK: http://www.xsquawkbox.net/xpsdk/ X-Plane Wiki: http://wiki.x-plane.com/ Scenery mailing list: x-plane-scenery(a)yahoogroups.com Developer mailing list: x-plane-dev(a)yahoogroups.com

1 0

Re: Fix catalyst brain damage to speed up Falcon BMS 2x
by Stefan Dösinger 16 Feb '13

16 Feb '13

Am 16.02.2013 um 08:39 schrieb Stanisław Halik <sthalik(a)misaki.pl>: > + dynamic_buffer_ok = gl_info->supported[APPLE_FLUSH_BUFFER_RANGE] || > + (!gl_info->[GL_AMDX_debug_output] && gl_info->supported[ARB_MAP_BUFFER_RANGE]); What you really want to do is figure out why GL_ARB_map_buffer_range is slow on fglrx, and make sure that the problem is really fglrx specific. I fixed a number of dynamic buffer performance problems in the past months, but there are still problems if we're falling back to draw_strided_slow for some reason, like fixed function material tracking. If you absolutely have to do some fglrx hacks for performant dynamic buffers, look into GL_AMD_pinned_memory. I'd prefer not to use this extension though. Other than being wrong conceptually, you're disabling dynamic buffers the wrong way: The "proper" way would be to add a quirk to the quirk_table in directx.c that removes ARB_map_buffer_range from the list of supported extensions if the driver vendor is AMD.

4 8

Re: Fix catalyst brain damage to speed up Falcon BMS 2x
by Stanislaw Halik 16 Feb '13

16 Feb '13

Updated patch following review.

1 0

Re: [website] Simplified Chinese translation for release 1.5.24
by Jactry Zeng 16 Feb '13

16 Feb '13

Oops...I made a mistake, this is the patch. So sorry :-(

1 0

mmsystem 16bit questions
by Joerg-Cyril.Hoehle＠t-systems.com 15 Feb '13

15 Feb '13

Hi, I noticed some dubious differences among winmm16 functions. I believe there should be none, but perhaps I'm missing some 16bit idiosyncrasies? Please compare waveOutPrepareHeader16, Unprepare16 and waveOutWrite16: http://source.winehq.org/source/dlls/mmsystem.dll16/mmsystem.c#L1287 UINT16 WINAPI waveOutUnprepareHeader16(HWAVEOUT16 hWaveOut, /* [in] */ SEGPTR lpsegWaveOutHdr, /* [???] */ UINT16 uSize) /* [in] */ { [...] return MMSYSTDRV_Message(..., WODM_UNPREPARE, lpsegWaveOutHdr, uSize); UINT16 WINAPI waveOutWrite16(HWAVEOUT16 hWaveOut, /* [in] */ LPWAVEHDR lpsegWaveOutHdr, /* [???] NOTE: SEGPTR */ UINT16 uSize) /* [in] */ { [...] return MMSYSTDRV_Message(..., WODM_WRITE, (DWORD_PTR)lpsegWaveOutHdr, uSize); The mmsystem.spec knows no difference: pascal waveOutPrepareHeader(word segptr word) waveOutPrepareHeader16 pascal waveOutUnprepareHeader(word segptr word) waveOutUnprepareHeader16 pascal waveOutWrite(word segptr word) waveOutWrite16 I believe: - SEGPTR should be used everywhere the .spec says; - (DWORD_PTR) cast then becomes obsolete. Shall I submit a patch? Furthermore, how to perform a 16bit NULL pointer check? waveInUnPrepareHeader16 uses: LPWAVEHDR lpWaveOutHdr = MapSL(lpsegWaveOutHdr); if (lpWaveInHdr == NULL) return MMSYSERR_INVALPARAM; waveInAddBuffer16 directly uses: if (lpsegWaveInHdr == NULL) return MMSYSERR_INVALPARAM; Last but not least, some but not all of the functions check for a NULL pointer. Why only some? When the check is missing, it looks like MMSYSTDRV_Message will crash when calling: map = drvtype->mapmsg16to32W(msg, &param1, &param2); http://source.winehq.org/source/dlls/mmsystem.dll16/message16.c?v=wine-1.5.… I don't know whether the check should occur or if we should let the app crash (all I know is that native MCI_PLAY crashes on w2k when given MCI_FROM/TO or callback flags with a NULL MCI_PARMS pointer, whereas Wine returns INVALPARAM, whereas a NULL pointer is ok in native when not setting any flags that require access via the pointer). If the check shall be done, then I believe that it should occur centrally in MMSYSTDRV_Message, not within the wave/midi* functions, such that if an app calls e.g. waveInMessage16(WIDM_UNPREPARE) that dispatches to MMSYSTDRV_Message, the check is not bypassed. BTW, MMSYSTDRV_WaveOut_UnMap16To32W forgets to deallocate the wh32 when waveOutPrepare fails. Same with wave in and MIDI. Thank you for 16bit enlightening, Jörg Höhle

2 1

Re: [PATCH 2/5] vbscript: Added IRegExp2_QueryInterface tests
by Marvin 15 Feb '13

15 Feb '13

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=24416 Your paranoid android. === WINEBUILD (build) === Make failed

2 1

MSI signing
by Marc-André Lureau 15 Feb '13

15 Feb '13

Hello! PE signing is already publicly documented by Microsoft, and we have an open-source tool (osslsigncode) capable of signing PE and Cabinet. A signed MSI dump easily reveals that the signature is under the '\005DigitalSignature' stream, and it's a regular pkcs#7 signature, whose content info type is 1.3.6.1.4.1.311.2.1.30 (SPC_SIPINFO_OBJID whatever that might be). To ease debugging, I added asn1parse of signature to msitools with "msidump --signature". You can also compare two MSI signatures with msidiff (http://git.gnome.org/browse/msitools) I found this blog http://qistoph.blogspot.com.es/2012/01/manual-verify-pkcs7-signed-data-with… very helpful, so my testing setup currently is: - self signed pkcs12 certificate - minimal "starting point" MSI crafted with msibuild mini.msi -s '', modified with hex editor for 0 length streams - signtool from 7.0A sdk, used simply "sign /f cert.pfx /v /p passphrase mini.msi" >From there, I get a "canonical" message digest sha1 value of 98C090F33284468D64F30EE7B8C00894135D54C8. Only the stream content seems to be used to compute it. All modifications I can think of to the MSI do not seem to alter that sha1, none of: OLECF internal data, stream name, number of (empty) streams, total file length, position of the streams, or whatever I could tweak in the OLECF data seems to change the resulting sha1. So it very much looks like an initial "seed", somehow? Based on my limited knowledge of sha1 computation, I have tried initializing the sha1 by modifying its initial value manually (the h values) to match with the "canonical" sha1, and added 1 byte to a stream. I was hoping to get the same result, but that didn't work that way. It could be that my modified sha1 is wrong, or that they apply further transformation on the stream content before computing the checksum, although this would be surprising since they don't do that for PE or cabinet file. Any suggestion or help is welcome! -- Marc-André Lureau

1 1

64bit integer overflow in 3 days
by Joerg-Cyril.Hoehle＠t-systems.com 15 Feb '13

15 Feb '13

Hi, You believe that 64bit integers give you plenty of room and time to avoid trouble like Y2k and Y2033, don't you? The trouble is, these large data types make using other large numbers more attractive than they used to be, e.g. counting time in 100 nanosecond units, representing one second as 10000000. Combining large numbers will cause an overflow sooner than you think. Specifically, the pattern X * numerator / denominator is troublesome. Let's analyse winealsa:AudioClock_GetPosition: QueryPerformanceCounter(&stamp); QueryPerformanceFrequency(&frequency); *qpctime = (stamp.QuadPart * (INT64)10000000) / frequency.QuadPart; QueryPerformanceCounter (QPC) returns time in an unspecified unit (frequency) and needs to convert that into 100 nanosecond units. Graphically, with g - garbage bits, s - shifted, X - valid bits: 6 5 4 3 2 1 4321098765432109876543210987654321098765432109876543210987654321 <<< shift left, multiply divide, shift right >>> Assuming QPC returns 64 valid bits: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX QPC Multiply with (INT64)10000000 (log2 ~ 23): XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXsssssssssssssssssssssss *10000000 Divide by frequency (happens to be 10000000 too): gggggggggggggggggggggggXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX /10000000 (100ns) You start to see how the number of valid bits already shrunk a lot. Now you don't care about nanoseconds, you want seconds. Divide again: ggggggggggggggggggggggggggggggggggggggggggggggXXXXXXXXXXXXXXXXXX /10000000 (seconds) Ouch, only 18bits left to express seconds! How many days is that? (/ (ash 1 18) 3600.0 24) -> ~3.03 So after 3 days in Wine, mmdevapi's GetPosition clock has wrapped. 3 days is not much compared to over 50000 years that 64 bit integers allow to express with 100 nanosecond units, isn't it? I don't know if GetPosition is related to bug #26968 where a user reports that foobar stops playing audio after 4-7 days, but you get a clue. Cross-check: 0x40000 is 1^18 seconds ~ 3 days 0x2625A000000 same in 100 nanosecond units 0x16BCC41E900000000 the * (INT64)10000000 part in winealsa ^1 bit unsigned overflow (more with signed integers) 0x6BCC41E900000000 clipped 0xB4DAD65435 after /10000000, a value already reached after ~21 hours There are even less bits, because LARGE_INTEGER is signed. There are several instances of that X * p / q pattern in Wine. Examples: ntdll/threadpool.c:queue_current_time: return now.QuadPart * 1000 / freq.QuadPart; ntdll/kernel_main.c:GetTickCount64: return counter.QuadPart * 1000 / frequency.QuadPart; IOW, GetTickCount64 does not offer 64 valid bits. ntdll/time.c:monotonic_counter: return mach_absolute_time() * timebase.numer / timebase.denom / 100; This means that on MacOS, QPC may overflow even earlier because it does not offer 64 valid bits. I've prepared a few patches to fix some of these. Generally, I don't know what to recommend. Use double floating point intermediates and loose 11 bits for the exponent but at least get the magnitude right? Regards, Jörg Höhle

2 1

Re: d3dx9: Specify arguments in trace to ease debugging
by Alexandre Julliard 15 Feb '13

15 Feb '13

Nozomi Kodama <nozomi.kodama(a)yahoo.com> writes: > Hello. > > I took advantage of this minor patch to clean up and make uniform the > coding style of this file. Please don't do that. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: vbscript: Added support for a few more constants
by Marvin 15 Feb '13

15 Feb '13

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=24408 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Re: d3dx9: Specify arguments in trace to ease debugging
by Rico Schüller 15 Feb '13

15 Feb '13

On 15.02.2013 08:20, Nozomi Kodama wrote: > @@ -721,9 +739,10 @@ D3DXMATRIX* WINAPI D3DXMatrixTransformation(D3DXMATRIX *pout, const D3DXVECTOR3 > > @@ -797,69 +821,70 @@ D3DXMATRIX* WINAPI D3DXMatrixTransformation2D(D3DXMATRIX *pout, const D3DXVECTOR Those two functions need a speed improvement. Normally we change only the code (and it's style) if we touch that area. I'm not a fan of changing that in one go in a huge patch, as it might introduce new mistakes, see below. I'm not sure if I caught all issues. > + rot.w = cos(rotation/2.0f); rot.w = cos(rotation / 2.0f); > > - TRACE("iface %p\n", iface); > + TRACE("iface %p, %pm\n", iface, pm); Typo. > + TRACE("iface %p, x %f, y %f, z %f\n", iface, x, y, z); > > + TRACE("(pout %p, pvpoint %p, pvnormal %p)\n", pout, pvpoint, pvnormal); Well, I would use the same style for both... I'd prefer the first one. Cheers Rico

1 0

Re: [PATCH 2/2] wininet: Set available bytes in InternetQueryDataAvailable even if it ends up in async call
by Marvin 14 Feb '13

14 Feb '13

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

2 1

Where to put Chinese translation of the Wine user guide?
by Jactry Zeng 14 Feb '13

14 Feb '13

Hi folks, A Chinese Wine user Liu Hongcong had translated [1] the Wine user guide [2] to Chinese three years ago, the translation looks mostly good to me. It is a pity to leave his translation outside of the official wine website. With his consent, I want to put his translation to winehq. But I can't find where to add it into in website's source [3]. Or I should add it into wiki? Thanks for any comment! [1] http://blog.csdn.net/hongmy525/article/details/2238600 [2] http://www.winehq.org/docs/wineusr-guide/index [3] http://source.winehq.org/git/website.git/

2 2

Re: [3/4] gdi32: IntersectClipRect should update actual clipping region for a EMF DC.
by Marvin 14 Feb '13

14 Feb '13

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

1 0

Re: [2/4] gdi32: OffsetClipRgn should update actual clipping region for a EMF DC.
by Marvin 14 Feb '13

14 Feb '13

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

1 0

Re: [1/4] gdi32: Add more EMF clipping tests.
by Marvin 14 Feb '13

14 Feb '13

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

1 0

Re: [PATCH] dsound: copy program parameters in SetFormat
by Andrew Eikum 13 Feb '13

13 Feb '13

On Mon, Feb 11, 2013 at 02:06:42PM +0100, Maarten Lankhorst wrote: > Fixes bug #32312, apparently some programs depend on the format it specifies being returned. > > Just set wBitsPerSample, nSamplesPerSec and nChannels to make those applications happy. > The patch seems fine, but can you add some tests for this so we can nail down exactly what we should be taking from the SetFormat format? E.g. should we just do "device->primary_fmt = CopyFormat(passed_fmt)" in all cases, or can you find a case where the GetFormat() result is changed? FYI, your patch applies with an offset and the Wine patch tracker didn't like this: > --- a/dlls/dsound/primary.c > +++ a/dlls/dsound/primary.c but git-am imported the raw mail file just fine. Andrew

1 0

Re: winmm: More compatible waveIn/Out[Un]Prepare WHDR_* flag handling.
by Andrew Eikum 13 Feb '13

13 Feb '13

These two patches look fine to me. Thanks! On Mon, Feb 11, 2013 at 01:28:09PM +0100, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Hi, > > This completes my winmm Prepare Header changes on the wave side. > > XyzPrepare: > + header->dwFlags &= ~(WHDR_DONE|WHDR_INQUEUE); /* flags cleared since w2k */ > > I choose to implement the behavior since w2k. Hopefully this will not break some w9x app. > > > WINMM_UnprepareHeader: > - header->dwFlags |= WHDR_DONE; > Never ever observed. Neither w95 nor xp or w7. > Perhaps MS would have been wise to do so, as simply looking at a header you cannot > tell whether it's been processed or not (returned with error code). > I choose to implement compatible behaviour. > > > - if(!(lpWaveInHdr->dwFlags & WHDR_PREPARED)) > - return MMSYSERR_NOERROR; > if(lpWaveInHdr->dwFlags & WHDR_INQUEUE) > return WAVERR_STILLPLAYING; > + if(!(lpWaveInHdr->dwFlags & WHDR_PREPARED)) > + return MMSYSERR_NOERROR; > Note the subtle difference in behaviour between wave and midi headers... > > > >IMHO calling named winmm:xyz functions should be equivalent to dispatching MM* messages > > I forgot to add that I'm still surprised that Andrew Eikum could reimplement > waveIn/OutMessage *without* using MMDRV_Message by simply returning MMSYSERR_NOTSUPPORTED. > > Either all apps use the named winmm:waveIn/OutXyz functions instead of calling waveOutMessage() > or nobody bothered to complain that some apps (perhaps w3.1 ones?) lack sound. > > That area obviously needs some testing... > > Regards, > Jörg Höhle

1 0

Re: kernel32: Indicate that HeapValidate called by GlobalHandle is not the sign of heap corruption.
by Alexandre Julliard 13 Feb '13

13 Feb '13

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > This helps to distinguish this one from real signs of heap corruption, > and saves quite a bit of effort analysing +heap or warn+heap logs. Avoiding HeapValidate would probably be a better approach. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: advapi32: Report world-access ownership by default for registry objects (try 2).
by Alexandre Julliard 13 Feb '13

13 Feb '13

"Erich E. Hoover" <ehoover(a)mymail.mines.edu> writes: > The attached patch fixes an issue where the Opera installer expects > registry keys to return ownership information (Bug #32904), concluding > the cleanup of [Get|Set]NamedSecurityInfo. This patch addresses the > issue by ensuring that NULL owner and group information is never > returned for registry keys and instead returns the World SID (S-1-1-0) > when this information is unavailable, which is sufficient to keep the > Opera installer from encountering an error. The included test shows > that this behavior is essentially the case for system keys on Windows, > though the Administrators SID is returned instead. Since > GetNamedSecurityInfo historically returned the World SID, and several > other routines use it as well) I've opted to use the World SID for > now. We should do the same as Windows unless there's a very good reason to be different. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] netstat: Clarify labels in UDP statistics.
by Frédéric Delanoy 13 Feb '13

13 Feb '13

On Sat, Feb 9, 2013 at 1:03 PM, Lauri Kenttä <lauri.kentta(a)gmail.com> wrote: > Change labels in UDP statistics so that they better reflect the actual meanings as described in MSDN [1]. > > [1] http://msdn.microsoft.com/en-us/library/windows/desktop/aa366929%28v=vs.85%… > --- > - IDS_UDP_NO_PORTS, "No Ports" > - IDS_UDP_RECV_ERRORS, "Receive Errors" > + IDS_UDP_NO_PORTS, "Invalid Port Errors" > + IDS_UDP_RECV_ERRORS, "Invalid Datagrams" > IDS_UDP_DGRAMS_SENT, "Datagrams Sent" "Invalid Datagrams" is too vague. It could mean datagrams sent or received. If you want to disambiguate/explain, use message contexts as explained in http://wiki.winehq.org/Translating Frédéric

2 3

Re: msi/tests: Move a couple of tests from install.c to msi.c.
by Marvin 13 Feb '13

13 Feb '13

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=24381 Your paranoid android. === WNT4WSSP6 (32 bit install) === install.c:5673: 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: gdi32: Make sure that actual clipping region is updated for a EMF DC.
by Alexandre Julliard 13 Feb '13

13 Feb '13

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > This patch not only fixes a todo_wine in the tests, but also makes print > preview and printing work in a pretty large application. You would most likely have to do that for all the clipping functions then. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: d3dx9: Implement D3DXSHEvalConeLight
by Matteo Bruni 12 Feb '13

12 Feb '13

Hi, in addition to what I already told you in #winehackers (that is, please rename the test struct field red_in to red_out and red_out to red_expected, or something like that), you should take the chance to do some more cleanup. That means e.g. use "const" instead of "CONST" as Rico already suggested and fix the indentation of the last comment you're adding. There are a few other things I don't really like but it's about code style and my personal preferences, so you are free to ignore them. I'd write the test structure declaration as: struct { float *red_out, *green_out, *blue_out; const float *red_expected, *green_expected, *blue_expected; float radius, red_offset, green_offset, blue_offset; } test[] = { {rout, gout, bout, table, &table[72], &table[144], 0.5f, 1.01f, 1.02f, 1.03f}, ... (I'm sure Gmail will wrap and make this piece of code unreadable, but well...) In general I'd also avoid using caps in variable names (e.g. r_intensity instead of Rintensity).

1 0

Re: [PATCH 2/4] urlmon: Fixed QueryInfo tests during BINDSTATUS_PROXYDETECTING notification
by Marvin 12 Feb '13

12 Feb '13

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=24361 Your paranoid android. === WVISTAADM (32 bit url) === url.c:1868: Test failed: binding failed: 800c0005, expected 00000000 url.c:1879: Test failed: res = 00002ee7, expected 00000000 url.c:3035: Test failed: IMoniker_BindToStorage failed: 800c0005 url.c:3036: Test failed: unk == NULL url.c:1868: Test failed: binding failed: 800c0005, expected 00000000 url.c:1879: Test failed: res = 00002ee7, expected 00000000 url.c:3035: Test failed: IMoniker_BindToStorage failed: 800c0005 url.c:3036: Test failed: unk == NULL url.c:1658: Test failed: unexpected call Obj_OnProgress_FINDINGRESOURCE url.c:1868: Test failed: binding failed: 800c0005, expected 00000000 url.c:1879: Test failed: res = 00002ee7, expected 00000000 url.c:1662: Test failed: unexpected call OnProgress_FINDINGRESOURCE url.c:1868: Test failed: binding failed: 800c0005, expected 00000000 url.c:1879: Test failed: res = 00002ee7, expected 00000000 url.c:3035: Test failed: IMoniker_BindToStorage failed: 800c0005 url.c:3036: Test failed: unk == NULL url.c:1868: Test failed: binding failed: 800c0005, expected 800c0019 url.c:1879: Test failed: res = 00002efd, expected 800c0019 url.c:3024: Test failed: Got 800c0005 url.c:3119: Test failed: expected QueryInterface_IHttpSecurity url.c:3120: Test failed: expected QueryService_IHttpSecurity url.c:3121: Test failed: expected OnSecurityProblem url.c:1662: Test failed: unexpected call OnProgress_FINDINGRESOURCE url.c:1868: Test failed: binding failed: 800c0005, expected 800c0019 url.c:1879: Test failed: res = 00002efd, expected 800c0019 url.c:3024: Test failed: Got 800c0005 url.c:3119: Test failed: expected QueryInterface_IHttpSecurity url.c:3120: Test failed: expected QueryService_IHttpSecurity url.c:3121: Test failed: expected OnSecurityProblem url.c:1662: Test failed: unexpected call OnProgress_FINDINGRESOURCE url.c:1868: Test failed: binding failed: 800c0005, expected 00000000 url.c:1879: Test failed: res = 00002efd, expected 00000000 url.c:3035: Test failed: IMoniker_BindToStorage failed: 800c0005 url.c:3036: Test failed: unk == NULL url.c:3119: Test failed: expected QueryInterface_IHttpSecurity url.c:3120: Test failed: expected QueryService_IHttpSecurity url.c:3121: Test failed: expected OnSecurityProblem url.c:3139: Test failed: expected OnResponse url.c:3143: Test failed: expected OnProgress_MIMETYPEAVAILABLE url.c:3144: Test failed: expected OnProgress_BEGINDOWNLOADDATA url.c:3145: Test failed: expected OnProgress_ENDDOWNLOADDATA url.c:3153: Test failed: expected OnDataAvailable url.c:1662: Test failed: unexpected call OnProgress_FINDINGRESOURCE url.c:1868: Test failed: binding failed: 800c0005, expected 00000000 url.c:1879: Test failed: res = 00002efd, expected 00000000 url.c:3027: Test failed: IMoniker_BindToStorage failed: 800c0005 url.c:3028: Test failed: unk == NULL url.c:3030: Test failed: Expected security problem to be ignored. url.c:3119: Test failed: expected QueryInterface_IHttpSecurity url.c:3120: Test failed: expected QueryService_IHttpSecurity url.c:3121: Test failed: expected OnSecurityProblem url.c:1662: Test failed: unexpected call OnProgress_FINDINGRESOURCE url.c:1868: Test failed: binding failed: 800c0005, expected 00000000 url.c:1879: Test failed: res = 00002ee7, expected 00000000 url.c:3133: Test failed: expected OnProgress_SENDINGREQUEST url.c:3139: Test failed: expected OnResponse url.c:3143: Test failed: expected OnProgress_MIMETYPEAVAILABLE url.c:3144: Test failed: expected OnProgress_BEGINDOWNLOADDATA url.c:3145: Test failed: expected OnProgress_ENDDOWNLOADDATA url.c:3157: Test failed: expected OnDataAvailable url.c:1662: Test failed: unexpected call OnProgress_FINDINGRESOURCE url.c:1868: Test failed: binding failed: 800c0005, expected 00000000 url.c:1879: Test failed: res = 00002ee7, expected 00000000 url.c:3133: Test failed: expected OnProgress_SENDINGREQUEST url.c:3139: Test failed: expected OnResponse url.c:3143: Test failed: expected OnProgress_MIMETYPEAVAILABLE url.c:3144: Test failed: expected OnProgress_BEGINDOWNLOADDATA url.c:3145: Test failed: expected OnProgress_ENDDOWNLOADDATA url.c:3157: Test failed: expected OnDataAvailable url.c:1658: Test failed: unexpected call Obj_OnProgress_FINDINGRESOURCE url.c:1868: Test failed: binding failed: 800c0005, expected 00000000 url.c:1879: Test failed: res = 00002ee7, expected 00000000 url.c:3353: Test failed: expected Obj_OnProgress_SENDINGREQUEST url.c:3357: Test failed: expected OnResponse url.c:3359: Test failed: expected Obj_OnProgress_MIMETYPEAVAILABLE url.c:3360: Test failed: expected Obj_OnProgress_BEGINDOWNLOADDATA url.c:3366: Test failed: expected Obj_OnProgress_CLASSIDAVAILABLE url.c:3367: Test failed: expected Obj_OnProgress_BEGINSYNCOPERATION url.c:3368: Test failed: expected Obj_OnProgress_ENDSYNCOPERATION url.c:3369: Test failed: expected OnObjectAvailable url.c:1662: Test failed: unexpected call OnProgress_FINDINGRESOURCE url.c:1868: Test failed: binding failed: 800c0005, expected 00000000 url.c:1879: Test failed: res = 00002ee7, expected 00000000 url.c:3133: Test failed: expected OnProgress_SENDINGREQUEST url.c:3139: Test failed: expected OnResponse url.c:3143: Test failed: expected OnProgress_MIMETYPEAVAILABLE url.c:3144: Test failed: expected OnProgress_BEGINDOWNLOADDATA url.c:3145: Test failed: expected OnProgress_ENDDOWNLOADDATA url.c:3157: Test failed: expected OnDataAvailable url.c:1658: Test failed: unexpected call Obj_OnProgress_FINDINGRESOURCE Timeout

2 1

winealsa: Have the MIDI recorder wait in poll(), not snd_seq_event_input().
by Joerg-Cyril.Hoehle＠t-systems.com 12 Feb '13

12 Feb '13

Johannes Kroll asked: >Did this patch get through? I don't see it on >http://source.winehq.org/patches/ ... It did. You looked too late in patches/. Committed patches are deleted sooner than rejected ones that are in turn deleted sooner than new/pending patches. I'm still interested in your testing my other MIDI patches. I fact I have a queue of half a dozen patches ready for submission, except that I'd like somebody to test them with real MIDI HW. There's another patch yet to be written: midiOutLongMessage CAN be used for coalesced non-sysex messages. This affects winealsa. Wineoss needs no change, because it simply dumps the bytes, one by one, regardless of SysEx or standard message. ALSA needs different API functions to be used. I've yet to check MacOSX CoreMIDI. Regards, Jörg Höhle

2 1

Re: winspool.drv: There is no need to speculate about wineps.drv default DEVMODE.
by Marvin 12 Feb '13

12 Feb '13

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=24350 Your paranoid android. === WINEBUILD (build) === Can't determine base name

1 0

Re: make_xftmpl: Explicitly use signed char when appropriate
by Alexandre Julliard 11 Feb '13

11 Feb '13

André Hentschel <nerv(a)dawncrow.de> writes: > For platforms where char is expected to be unsigned (e.g. it fixes a warning on ARM) There's no reason to make it signed. Please fix the bug correctly instead. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: windowscodecsext: Implement WICCreateColorTransform_Proxy and IWICColorTransform_Initialize_Proxy.
by Vincent Povirk 11 Feb '13

11 Feb '13

OK, I'm about to say something weird, and I'll understand if everyone else decides to ignore it. I don't think WICCreateColorTransform_Proxy, or any of the Proxy functions, should initialize or make use of COM. Instead, I think it should work by calling WICCreateImagingFactory_Proxy. I suspect that part of the purpose of the _Proxy functions is to make it possible to use WIC without needing COM at all, which is something we may want in the future if we want to use it from user32. (Another consequence of this is that we should be able to create instances of builtin decoders/encoders without COM, which we currently can't do. But I'd have to write a test for that, and currently there's been no demonstrated need for it.)

1 0

Re: winealsa: Have the MIDI recorder wait in poll(), not snd_seq_event_input().
by Johannes Kroll 11 Feb '13

11 Feb '13

On Thu, 24 Jan 2013 10:33:58 +0100 <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > Compare with wineoss which uses poll <= 0 already... > > Johannes Kroll mentioned that MIDIIn takes a long time to end. > Indeed, our testsuite ran 3 times into the "kill after 5s" timeout due to this bug. > Now the tests execute much faster. > > Regards, > Jörg höhle Did this patch get through? I don't see it on http://source.winehq.org/patches/ ...

1 0

Re: windowscodecsext: Implement WICCreateColorTransform_Proxy and IWICColorTransform_Initialize_Proxy.
by Marvin 11 Feb '13

11 Feb '13

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

1 0

Re: winspool.drv: Fallback to cupsGetPPD if cupsGetPPD3 is missing or failed.
by Huw Davies 11 Feb '13

11 Feb '13

On Mon, Feb 11, 2013 at 02:03:26PM +0800, Dmitry Timoshkov wrote: > - if (pcupsGetPPD3) return pcupsGetPPD3( http, name, modtime, buffer, bufsize ); > + if (pcupsGetPPD3) > + { > + http_status_t status; > + > + TRACE( "Calling cupsGetPPD3\n" ); > + status = pcupsGetPPD3( http, name, modtime, buffer, bufsize ); > + if (status == HTTP_OK) return HTTP_OK; > + TRACE("cupsGetPPD3 failed (status %d)\n", status); > + } > Under what conditions does cupsGetPPD succeed if cupsGetPPD3 fails? Huw.

2 2

Re: [2/2] xmllite: Basic test for chunk value read vs full value read
by Marvin 11 Feb '13

11 Feb '13

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

1 0

Debugging and steam
by Gediminas Jakutis 11 Feb '13

11 Feb '13

Good day! Does anyone has any experience on dealing with Steam when debugging a game which depends on Steam? I am trying to squash a bug which makes a game crash. I started from relay logs, but have a bit of a problem - calls from Steam itself produce a few megabytes worth of relay logs every second. Those get mixed together with calls originating from the game. Also, it appears the game takes a couple of seconds after that "bad" call before crashing. When it is mixed together with Steam's own spam, it is a nightmare finding where it went wrong. I tried every idea I could muster on how to get a "pure" log of the game. Not a single one turned out to be effective. I am all out of ideas now. So if anyone had to deal with this and found a satisfactory solution, please enlighten me. Thank You in advance! -- Gediminas Jakutis LDK Varčiai www.varciai.lt

2 1

Re: comctl32/listview: fix LVM_SETICONSPACING on 64bit machines
by Marvin 09 Feb '13

09 Feb '13

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

1 0

Re: ole32/tests: Add test for IDispatch interface in IOleObject_QueryInterface.
by Alistair Leslie-Hughes 09 Feb '13

09 Feb '13

On 9/02/2013 2:08 AM, Roman Dadkov wrote: > This test is necessary to show that the function > IOleObject_QueryInterface does not have enough processing IID_IDispatch, > but it works for Windose. Therefore, the creation of some objects in a > variety of applications leads to crash. > + hr = IOleObject_QueryInterface(ole_obj, &IID_IDispatch, (void**)&dispatch); > + todo_wine > + ok(hr == S_OK, "got %08x\n", hr); > The IDispatch Interface should be released. Best Regards Alistair Leslie-Hughes

1 0

Re: ole32/tests: Add test for IDispatch interface in IOleObject_QueryInterface.
by Dmitry Timoshkov 09 Feb '13

09 Feb '13

Roman Dadkov <romand(a)etersoft.ru> wrote: > + const CLSID non_existent_class = {0xa5f1772f, 0x3772, 0x490f, {0x9e, 0xc6, 0x77, 0x13, 0xe8, 0xb3, 0x4b, 0x5d}}; Probably it would be a good idea to try make CLSID really unique and bad enough that it's unlikely that somebody uses it for real. Something like 0xdeadbeef,0xde,0xad,0xbe,0xef,... -- Dmitry.

1 0

Re: ole32/tests: Add test for IDispatch interface in IOleObject_QueryInterface.
by Marvin 09 Feb '13

09 Feb '13

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=24324 Your paranoid android. === WNT4WSSP6 (32 bit defaulthandler) === defaulthandler.c:115: Test failed: got 80004002 === W2KPROSP4 (32 bit defaulthandler) === defaulthandler.c:115: Test failed: got 80004002 === WXPPROSP3 (32 bit defaulthandler) === defaulthandler.c:115: Test failed: got 80004002 === W2K3R2SESP2 (32 bit defaulthandler) === defaulthandler.c:115: Test failed: got 80004002 === WVISTAADM (32 bit defaulthandler) === defaulthandler.c:115: Test failed: got 80004002 === W2K8SE (32 bit defaulthandler) === defaulthandler.c:115: Test failed: got 80004002 === W7PRO (32 bit defaulthandler) === defaulthandler.c:115: Test failed: got 80004002 === W7PROX64 (32 bit defaulthandler) === defaulthandler.c:115: Test failed: got 80004002 === TEST64_W7SP1 (32 bit defaulthandler) === defaulthandler.c:115: Test failed: got 80004002 === W7PROX64 (64 bit defaulthandler) === defaulthandler.c:115: Test failed: got 80004002 === TEST64_W7SP1 (64 bit defaulthandler) === defaulthandler.c:115: Test failed: got 80004002

1 0

Re: [PATCH 1/2] shell32: Add a basic implementation for SHGetStockIconInfo
by Dmitry Timoshkov 08 Feb '13

08 Feb '13

Detlef Riekenberg <wine.dev(a)web.de> wrote: > +/**************************************************************************** > + * helper for SHGetStockIconInfo > + */ > +typedef struct stockiconentry_t { > + SHSTOCKICONID id; > + DWORD iconid; > +} stockiconentry; Why bother with a typedef? > +static stockiconentry stockicontable[] = { > + {SIID_DOCNOASSOC, IDI_SHELL_DOCUMENT}, > + {SIID_DOCASSOC, IDI_SHELL_DOCUMENT}, > + {SIID_FOLDER, IDI_SHELL_FOLDER}, > + {SIID_DRIVERNET, IDI_SHELL_NETDRIVE}, > + {SIID_DRIVERCD, IDI_SHELL_CDROM}, > + {SIID_DRIVERRAM, IDI_SHELL_RAMDISK}, > + {SIID_DESKTOPPC, IDI_SHELL_MY_COMPUTER}, > + {SIID_PRINTER, IDI_SHELL_PRINTER}, > + {SIID_SETTINGS, IDI_SHELL_CONTROL_PANEL}, > + {SIID_RECYCLERFULL, IDI_SHELL_FULL_RECYCLE_BIN}, > + {SIID_DELETE, IDI_SHELL_CONFIRM_DELETE}, > +}; Please don't forget to add 'const'. > +static int cmp_stockiconentry(const void *entry1, const void *entry2) > +{ > + stockiconentry *p1 = (stockiconentry *) entry1; > + stockiconentry *p2 = (stockiconentry *) entry2; > + > + return p1->id - p2->id; > +} Don't cast away 'const'. > +HRESULT WINAPI SHGetStockIconInfo(SHSTOCKICONID id, UINT flags, SHSTOCKICONINFO *sii) > +{ > + stockiconentry *entry; > + > + TRACE("(%d, 0x%x, %p)\n", id, flags, sii); > + if ((id < 0) | (id >= (SIID_MAX_ICONS - 1)) || !sii || (sii->cbSize != sizeof(SHSTOCKICONINFO))) > + return E_INVALIDARG; > + > + /* find the requested icon */ > + entry = bsearch(&id, stockicontable, sizeof(stockicontable)/sizeof(stockicontable[0]), > + sizeof(stockiconentry), cmp_stockiconentry); > + > + if (!entry) { > + FIXME("using fallback for id %d\n", id); > + entry = stockicontable; > + } > + > + if (flags) > + FIXME("flags 0x%x not implemented\n", flags); > + > + sii->hIcon = NULL; > + sii->iSysImageIndex = -1; > + sii->iIcon = - entry->iconid; > + > + GetModuleFileNameW(shell32_hInstance, sii->szPath, MAX_PATH); > + > + return S_OK; > +} GetModuleFileNameW can fail, so filling 'sii' may be a bit premature. -- Dmitry.

3 2

Re: [PATCH] winebuild: Use $CCAS to assemble if found
by Charles Davis 08 Feb '13

08 Feb '13

Hi, On Feb 3, 2013, at 7:33 PM, Alexandre Rostovtsev wrote: > Commit c14bdaf1 made winebuild use Clang to assemble if found. > > However, just because a user has some version of Clang installed, it > does not mean that she wants to use Clang to assemble Wine. For example, > a user who has both Clang and GAS installed may want to use GAS to avoid > textrels (see https://bugs.gentoo.org/show_bug.cgi?id=455308). Long term, that should really get fixed in LLVM/Clang. I'll file a PR (if one wasn't already). > > This patch allows the user to override which assembler gets used by > exporting CCAS at Wine configure time; the name CCAS was chosen for > compatibility with automake's standard AM_PROG_AS macro. I wrote the patch that prompted this one. And I'll freely admit, this is why I wanted to limit that patch to Mac OS--to minimize fallout on other platforms (like, obviously, Gentoo :). > --- > configure | 106 ++++++++++++++++++++++++++++++++++++++++++++ > configure.ac | 4 ++ > tools/winebuild/Makefile.in | 5 ++- > tools/winebuild/utils.c | 12 +++++ > 4 files changed, 126 insertions(+), 1 deletion(-) > > diff --git a/configure b/configure > index e3253ee..d0b7777 100755 > --- a/configure > +++ b/configure > @@ -732,6 +732,8 @@ FLEX > TOOLSDIR > WOW64_DISABLE > TARGETFLAGS > +ac_ct_CCAS > +CCAS > CPPBIN > ac_ct_CXX > CXXFLAGS > @@ -861,6 +863,7 @@ CPPFLAGS > CXX > CXXFLAGS > CCC > +CCAS > CPP > XMKMF' > > @@ -1549,6 +1552,7 @@ Some influential environment variables: > you have headers in a nonstandard directory <include dir> > CXX C++ compiler command > CXXFLAGS C++ compiler flags > + CCAS Assembler command > CPP C preprocessor > XMKMF Path to xmkmf, Makefile generator for X Window System > > @@ -4075,6 +4079,108 @@ cat >>confdefs.h <<_ACEOF > _ACEOF > > > + > +if test -n "$ac_tool_prefix"; then > + for ac_prog in clang gas as > + do > + # Extract the first word of "$ac_tool_prefix$ac_prog", so it can be a program name with args. > +set dummy $ac_tool_prefix$ac_prog; ac_word=$2 > +{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5 > +$as_echo_n "checking for $ac_word... " >&6; } > +if ${ac_cv_prog_CCAS+:} false; then : > + $as_echo_n "(cached) " >&6 > +else > + if test -n "$CCAS"; then > + ac_cv_prog_CCAS="$CCAS" # Let the user override the test. > +else > +as_save_IFS=$IFS; IFS=$PATH_SEPARATOR > +for as_dir in $PATH > +do > + IFS=$as_save_IFS > + test -z "$as_dir" && as_dir=. > + for ac_exec_ext in '' $ac_executable_extensions; do > + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then > + ac_cv_prog_CCAS="$ac_tool_prefix$ac_prog" > + $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 > + break 2 > + fi > +done > + done > +IFS=$as_save_IFS > + > +fi > +fi > +CCAS=$ac_cv_prog_CCAS > +if test -n "$CCAS"; then > + { $as_echo "$as_me:${as_lineno-$LINENO}: result: $CCAS" >&5 > +$as_echo "$CCAS" >&6; } > +else > + { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5 > +$as_echo "no" >&6; } > +fi > + > + > + test -n "$CCAS" && break > + done > +fi > +if test -z "$CCAS"; then > + ac_ct_CCAS=$CCAS > + for ac_prog in clang gas as > +do > + # Extract the first word of "$ac_prog", so it can be a program name with args. > +set dummy $ac_prog; ac_word=$2 > +{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5 > +$as_echo_n "checking for $ac_word... " >&6; } > +if ${ac_cv_prog_ac_ct_CCAS+:} false; then : > + $as_echo_n "(cached) " >&6 > +else > + if test -n "$ac_ct_CCAS"; then > + ac_cv_prog_ac_ct_CCAS="$ac_ct_CCAS" # Let the user override the test. > +else > +as_save_IFS=$IFS; IFS=$PATH_SEPARATOR > +for as_dir in $PATH > +do > + IFS=$as_save_IFS > + test -z "$as_dir" && as_dir=. > + for ac_exec_ext in '' $ac_executable_extensions; do > + if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then > + ac_cv_prog_ac_ct_CCAS="$ac_prog" > + $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 > + break 2 > + fi > +done > + done > +IFS=$as_save_IFS > + > +fi > +fi > +ac_ct_CCAS=$ac_cv_prog_ac_ct_CCAS > +if test -n "$ac_ct_CCAS"; then > + { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_ct_CCAS" >&5 > +$as_echo "$ac_ct_CCAS" >&6; } > +else > + { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5 > +$as_echo "no" >&6; } > +fi > + > + > + test -n "$ac_ct_CCAS" && break > +done > + > + if test "x$ac_ct_CCAS" = x; then > + CCAS=""$CC"" > + else > + case $cross_compiling:$ac_tool_warned in > +yes:) > +{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: using cross tools not prefixed with host triplet" >&5 > +$as_echo "$as_me: WARNING: using cross tools not prefixed with host triplet" >&2;} > +ac_tool_warned=yes ;; > +esac > + CCAS=$ac_ct_CCAS > + fi > +fi > + > + > case $host in > *-darwin*) > if test "x$enable_win64" = "xyes" > diff --git a/configure.ac b/configure.ac > index c93cd08..760f325 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -126,6 +126,10 @@ dnl We can't use AC_PROG_CPP for winegcc, it uses by default $(CC) -E > AC_CHECK_TOOL(CPPBIN,cpp,cpp) > AC_DEFINE_UNQUOTED(EXEEXT,["$ac_exeext"],[Define to the file extension for executables.]) > > +dnl Analogous to AM_PROG_AS > +AC_ARG_VAR([CCAS],[Assembler command]) > +AC_CHECK_TOOLS(CCAS,[clang gas as],["$CC"]) If the user doesn't set CCAS--which she doesn't the majority of the time--configure will pick up the first of {clang, gas, as} in the PATH. Are you sure that's what you want? One of the earlier versions of the "Use Clang to assemble" patch attempted to detect Clang in the PATH, and use it if it was there. I was told that winebuild should detect the binary to use at runtime instead. Perhaps we should just not define CCAS if the user didn't specify it. Then below, you can wrap the block you added in an #ifdef. AJ may have more to say about this. > + > case $host in > *-darwin*) > if test "x$enable_win64" = "xyes" > diff --git a/tools/winebuild/Makefile.in b/tools/winebuild/Makefile.in > index 2017129..3fe47a3 100644 > --- a/tools/winebuild/Makefile.in > +++ b/tools/winebuild/Makefile.in > @@ -1,4 +1,7 @@ > -DEFS = -D__WINESRC__ $(EXTRADEFS) > +DEFS = \ > + -DCCAS="\"@CCAS@\"" \ > + -D__WINESRC__ \ > + $(EXTRADEFS) > > PROGRAMS = winebuild$(EXEEXT) > MANPAGE = winebuild.man > diff --git a/tools/winebuild/utils.c b/tools/winebuild/utils.c > index 262ff3a..1c5f918 100644 > --- a/tools/winebuild/utils.c > +++ b/tools/winebuild/utils.c > @@ -352,6 +352,18 @@ struct strarray *get_as_command(void) > static int as_is_clang = 0; > struct strarray *args = strarray_init(); > > + if (!as_command && strlen( CCAS )) > + { > + struct stat st; > + > + if (!stat( CCAS, &st )) > + as_command = CCAS; > + else > + as_command = find_tool( CCAS, NULL ); > + > + if (as_command && strstr( as_command, "clang" )) as_is_clang = 1; You may recall that one of the earlier versions (later than the one that detected Clang in configure) used strstr(3) to detect Clang; I was then told not to use it. I suspect this is because some systems' strstr(3) exhibits quadratic-time behavior. I don't know if you can avoid that in this case, though. Maybe you can just grab the basename and strip off the CTARGET prefix; then you should just be able to do a strcmp(3). Or am I missing something? More generally, calling the variable "CCAS" implies that any old C compiler driver that knows how to assemble can be specified. If the user specifies a compiler that isn't Clang--GCC, for example--she'll get the wrong behavior. In particular, the 'as_is_clang' variable is used below to pass the right switches and options to Clang. Presumably we'd want to do that for the GCC case, too. > + } > + > if (!as_command) > { > as_command = find_tool( "clang", NULL ); > -- > 1.8.1.2 > > > I'm sorry for any inconvenience I might have caused, and I hope we can get this fixed soon. Chip

3 3

[PATCH v2 1/8] locks: make flock_lock_file take is_conflict callback parm
by Pavel Shilovsky 07 Feb '13

07 Feb '13

This parm demetermines how to check if locks have conflicts. This let us use flock_lock_file funtions further to add O_DENY* flags support through flocks. Signed-off-by: Pavel Shilovsky <piastry(a)etersoft.ru> --- fs/locks.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/fs/locks.c b/fs/locks.c index a94e331..9edfec4 100644 --- a/fs/locks.c +++ b/fs/locks.c @@ -697,14 +697,20 @@ static int posix_locks_deadlock(struct file_lock *caller_fl, return 0; } -/* Try to create a FLOCK lock on filp. We always insert new FLOCK locks +/* + * Try to create a FLOCK lock on filp. We always insert new FLOCK locks * after any leases, but before any posix locks. * * Note that if called with an FL_EXISTS argument, the caller may determine * whether or not a lock was successfully freed by testing the return * value for -ENOENT. + * + * Take @is_conflict callback that determines how to check if locks have + * conflicts or not. */ -static int flock_lock_file(struct file *filp, struct file_lock *request) +static int +flock_lock_file(struct file *filp, struct file_lock *request, + int (*is_conflict)(struct file_lock *, struct file_lock *)) { struct file_lock *new_fl = NULL; struct file_lock **before; @@ -760,7 +766,7 @@ find_conflict: break; if (IS_LEASE(fl)) continue; - if (!flock_locks_conflict(request, fl)) + if (!is_conflict(request, fl)) continue; error = -EAGAIN; if (!(request->fl_flags & FL_SLEEP)) @@ -1589,7 +1595,7 @@ int flock_lock_file_wait(struct file *filp, struct file_lock *fl) int error; might_sleep(); for (;;) { - error = flock_lock_file(filp, fl); + error = flock_lock_file(filp, fl, flock_locks_conflict); if (error != FILE_LOCK_DEFERRED) break; error = wait_event_interruptible(fl->fl_wait, !fl->fl_next); -- 1.8.1.1

2 20

Re: [PATCH] gdi32/tests: Skip justification tests where Times New Roman is not installed.
by Alexandre Julliard 07 Feb '13

07 Feb '13

Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > --- > dlls/gdi32/tests/font.c | 6 ++++++ > 1 file changed, 6 insertions(+) There's no reason to require Times New Roman in that test, it could fall back to some other font. -- Alexandre Julliard julliard(a)winehq.org

1 0

[PATCH v2 0/8] Add O_DENY* support for VFS and CIFS/NFS
by Pavel Shilovsky 07 Feb '13

07 Feb '13

This patchset adds support of O_DENY* flags for Linux fs layer. These flags can be used by any application that needs share reservations to organize a file access. VFS already has some sort of this capability - now it's done through flock/LOCK_MAND mechanis, but that approach is non-atomic. This patchset build new capabilities on top of the existing one but doesn't bring any changes into the flock call semantic. These flags can be used by NFS (built-in-kernel) and CIFS (Samba) servers and Wine applications through VFS (for local filesystems) or CIFS/NFS modules. This will help when e.g. Samba and NFS server share the same directory for Windows and Linux users or Wine applications use Samba/NFS share to access the same data from different clients. According to the previous discussions the most problematic question is how to prevent situations like DoS attacks where e.g /lib/liba.so file can be open with DENYREAD, or smth like this. That's why one extra flag O_DENYMAND is added. It indicates to underlying layer that an application want to use O_DENY* flags semantic. It allows us not affect native Linux applications (that don't use O_DENYMAND flag) - so, these flags (and the semantic of open syscall that they bring) are used only for those applications that really want it proccessed that way. So, we have four new flags: O_DENYREAD - to prevent other opens with read access, O_DENYWRITE - to prevent other opens with write access, O_DENYDELETE - to prevent delete operations (this flag is not implemented in VFS and NFS part and only suitable for CIFS module), O_DENYMAND - to switch on/off three flags above. The #1 patch bring infrastructure to let us add this capability easier. #2 patch adds flags to fcntl while #3 patch implement VFS part. Patches #4, #5, #6 are related to CIFS-specific changes. #7 and #8 describe NFS and NFSD parts. Also, I created the preliminary patch for Samba that replaces the existing use of flock/LOCK_MAND mechanism with O_DENY* flags: http://git.etersoft.ru/people/piastry/packages/?p=samba.git;a=commitdiff;h=… Pavel Shilovsky (8): locks: make flock_lock_file take is_conflict callback parm fcntl: Introduce new O_DENY* open flags vfs: Add O_DENYREAD/WRITE flags support for open syscall CIFS: Add O_DENY* open flags support CIFS: Use NT_CREATE_ANDX command for forcemand mounts CIFS: Translate SHARING_VIOLATION to -ETXTBSY error code for SMB2 NFSv4: Add O_DENY* open flags support NFSD: Pass share reservations flags to VFS fs/cifs/cifsacl.c | 10 ++-- fs/cifs/cifsglob.h | 12 +++- fs/cifs/cifsproto.h | 9 +-- fs/cifs/cifssmb.c | 47 ++++++++------- fs/cifs/dir.c | 14 +++-- fs/cifs/file.c | 18 ++++-- fs/cifs/inode.c | 11 ++-- fs/cifs/link.c | 10 ++-- fs/cifs/readdir.c | 2 +- fs/cifs/smb1ops.c | 15 ++--- fs/cifs/smb2file.c | 10 ++-- fs/cifs/smb2inode.c | 4 +- fs/cifs/smb2maperror.c | 2 +- fs/cifs/smb2ops.c | 10 ++-- fs/cifs/smb2pdu.c | 6 +- fs/cifs/smb2proto.h | 14 +++-- fs/fcntl.c | 5 +- fs/locks.c | 121 ++++++++++++++++++++++++++++++++++++--- fs/namei.c | 10 +++- fs/nfs/nfs4xdr.c | 24 ++++++-- fs/nfsd/nfs4state.c | 46 ++++++++++++++- include/linux/fs.h | 6 ++ include/uapi/asm-generic/fcntl.h | 14 +++++ 23 files changed, 324 insertions(+), 96 deletions(-) -- 1.8.1.1

3 6

Re: iphlpapi: Let C look like C.
by Austin English 07 Feb '13

07 Feb '13

On Feb 6, 2013 11:13 PM, "Michael Stefaniuc" <mstefani(a)redhat.de> wrote: > > --- > dlls/iphlpapi/ipstats.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/iphlpapi/ipstats.c b/dlls/iphlpapi/ipstats.c > index f8191ba..966d24e 100644 > --- a/dlls/iphlpapi/ipstats.c > +++ b/dlls/iphlpapi/ipstats.c > @@ -693,7 +693,7 @@ DWORD WINAPI GetIcmpStatisticsEx(PMIB_ICMP_EX stats, DWORD family) > } > > ret = GetIcmpStatistics(&ipv4stats); > - if SUCCEEDED(ret) > + if (SUCCEEDED(ret)) > { > stats->icmpInStats.dwMsgs = ipv4stats.stats.icmpInStats.dwMsgs; > stats->icmpInStats.dwErrors = ipv4stats.stats.icmpInStats.dwErrors; > -- > 1.7.6.5 Minor nitpick, "Make C look like C" would be a more proper title, imho.

3 3

Re: comctl32/tests: drop broken test
by Marvin 06 Feb '13

06 Feb '13

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

1 0

Re: [1/4] windowscodecs: Implement IWICColorContext::InitializeFromFilename.
by Ludger Sprenker 06 Feb '13

06 Feb '13

On Wed, 06 Feb 2013 13:51:32 +0100, Hans Leidekker wrote: > + handle = CreateFileW(filename, GENERIC_READ, 0, NULL, > OPEN_EXISTING, 0, NULL); > + if (handle == INVALID_HANDLE_VALUE) return > HRESULT_FROM_WIN32(GetLastError()); Hello Hans, I think, you are hiding a fixme for the default color profiles shipped with windows. (like "c:\windows\system32\spool\drivers\color\sRGB Color Space Profile.icm") I don't know the correct way to support these files. Maybe wine could search in "/usr/share/color/icc" for compatible profiles on runtime or take these files from other open source projects and include them in the wine installation. Regards, Ludger

2 1

Re: [4/4] windowscodecs: Implement IWICComponentFactory::CreateDecoderFromFileHandle.
by Vincent Povirk 06 Feb '13

06 Feb '13

> + hr = map_file(file, &map, &mem, &size); > + if (FAILED(hr)) return hr; > + ... > + > + hr = IWICStreamImpl_InitializeFromMemory(stream, mem, size.u.LowPart); > + if (FAILED(hr)) goto error; This makes me sad. Is this really simpler than implementing Write and Seek for a file handle?

2 1

kernel32: Use the monotonic counter in GetTickCount64.
by Joerg-Cyril.Hoehle＠t-systems.com 06 Feb '13

06 Feb '13

Hi, I believe we should use this opportunity and review the usage of timers in Wine. E.g. I have a patch to have CreateTimerqueue use the monotonic timer too that I'll submit after some more testing. Mmdevapi's audio currently depends on the TimerQueue which IMHO erroneously depends on gettimeofday() instead of clocks not affected by DST and NTP. As a result, strange things should happen to Wine audio each time the clock is adjusted... What do you think? BTW, MSDN is wonderfully inconsistent - witness "system time": "System time is the current date and time of day. [...] The system bases system time on coordinated universal time (UTC)." http://msdn.microsoft.com/en-us/library/windows/desktop/ms724961%28v=vs.85%… "The system time is the time, in milliseconds, since the Microsoft Windows operating system was started." http://msdn.microsoft.com/en-us/library/windows/desktop/dd743637%28v=vs.85%… The latter is within the context of windows multimedia. I believe different teams at MS wrote documents without cross-checking their use of vocabulary. As a result, expressions don't mean the same things. Regards, Jörg Höhle

1 0

Re: kernel32/tests : added tests for copyfileex try7
by Alexandre Julliard 06 Feb '13

06 Feb '13

Patrick Rudolph <siro(a)das-labor.org> writes: > + if( !GetTempPathA( MAX_PATH,tmppath ) ) > + { > + win_skip("GetTempPathA failed\n"); > + return; > + } > + > + /* create a dummy file for copy tests */ > + if( !GetTempFileNameA( tmppath,"IN",0,source_name ) ) > + { > + win_skip("GetTempFileNameA failed\n"); > + return; > + } > + > + /* create a dummy file for copy tests */ > + if( !GetTempFileNameA( tmppath,"OUT",0,dest_name ) ) > + { > + win_skip("GetTempFileNameA failed\n"); > + return; > + } > + > + source_handle = CreateFileA( source_name, GENERIC_WRITE, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0 ); > + if( !source_handle ) > + { > + win_skip("CreateFileA failed (%d)\n", GetLastError()); > + return; > + } > + > +#define COPYFILEEXFILESIZE 10000000 > + > + /* set filesize to COPYFILEEXFILESIZE */ > + TotalFileSize.QuadPart = COPYFILEEXFILESIZE; > + > + if( !pSetFilePointerEx(source_handle,TotalFileSize,NULL,FILE_BEGIN) ) > + { > + win_skip("SetFilePointerEx failed (%d)\n", GetLastError()); > + return; > + } > + > + if( !pSetEndOfFile(source_handle) ) > + { > + win_skip("SetEndOfFile failed (%d)\n", GetLastError()); > + return; > + } All these calls are not supposed to fail on Windows either. win_skip is not appropriate. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] Support a protection scheme which reset the GS selector
by Alexandre Julliard 06 Feb '13

06 Feb '13

Alessandro Pignotti <a.pignotti(a)sssup.it> writes: > Hi everyone, > > I've found two different games: > > -) Of orcs and men > -) The testament of sherlock holmes > > which are using a protection scheme which reset the GS segment selector, > possibly to confuse virtual machines. Since on linux the GS selector is > used internally by glibc the game would crash as soon as a native glibc > method is called by wine. The proposed patch tries to workaround this > problem by restoring the GS to a known working value in wine's SEGFAULS > handler and try the instruction again. This should be done similarly to the other checks in raise_segv_exception. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [2/5] windowscodecs: Basic tests for tiff encoder options (try2)
by Vincent Povirk 05 Feb '13

05 Feb '13

> @Vincent: I thought about adding the properties one at a time but it seemed > a bit like overkill for the tiff encoder, which has only two options. But I > will defenitly do this for the jpeg encoder, which has much more options. Well, actually, on further consideration I can understand why you did it this way, since adding a property is very easy and doesn't really require implementing that property. Though it'd be nice to get some notification when a property is used that we don't support.

1 0

Re: [2/5] windowscodecs: Basic tests for tiff encoder options
by Vincent Povirk 05 Feb '13

05 Feb '13

+ { wszTiffCompressionMethod, VT_UI1, VT_UI1, {.iVal=WICTiffCompressionDontCare} }, This .field=value initialization syntax is not acceptable for Wine (not in C89). I don't know another way to initialize unions. + if (clsid_encoder == &CLSID_WICTiffEncoder) + todo_wine test_specific_encoder_properties(options, testdata_tiff_props, all_props, cProperties2); It might be better to mark the individual properties with a todo, so they can be added one at a time.

1 0

Compiling Wine on Mac OS X 10.8.2?
by Jeremiah Flerchinger 05 Feb '13

05 Feb '13

Is anyone compiling Wine from the git repository for OS X version 10.8.2? At first I thought I broke my toolchain and could no longer compile Wine at all, but this is not the case. I can still compile old releases, but can no longer compile from git. I'm just curious if anyone else has tried...

5 8

Re: comctl32/listview: do not touch icon spacing if set explicitly
by Marvin 04 Feb '13

04 Feb '13

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

1 0

Re: comctl32/listview: always use large icon size when calculating icon spacing
by Marvin 04 Feb '13

04 Feb '13

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

1 0

Re: comctl32/listview: correct icon spacing calculation when set to 0 or -1
by Marvin 04 Feb '13

04 Feb '13

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

1 0

Re: [2/5] windowscodecs: Implement IPropertyBag2::CountProperties
by Marvin 04 Feb '13

04 Feb '13

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

2 1

Re: [3/5] windowscodecs: Add initializations for tiff encoder options
by Marvin 04 Feb '13

04 Feb '13

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

1 0

Re: Keynote made me remember Mac Icons
by Ken Thomases 03 Feb '13

03 Feb '13

Hi, On Feb 3, 2013, at 3:56 AM, Austin English wrote: > On Sun, Feb 3, 2013 at 9:45 AM, Jeremiah Flerchinger > <jeremiah.flerchinger(a)gmail.com> wrote: >> The keynote made me realize I have some Mac icons for Wine. Would anyone be >> interested in them? It's definitely more functional than just using the >> default terminal icon. I also had a winecfg icon somewhere but I can't >> remember where that one is right now. >> >> Let me know and tell me where to send them. > > Ken Thomases (cc'ed) is the person on winemac.drv, though wine-devel > or attaching them to bugzilla would likely be best to preserve a copy > of it. I may be missing some context. What icons is this referring to? Do you mean just the various icons for Wine and its programs (e.g. Notepad) but in ICNS format? I'm not sure yet how useful that will be. Although I haven't gotten this far in my Mac driver patch submissions, the Mac driver will eventually attempt to extract the icon for the current .exe and use that for the application icon of the running process. Not all executables have an icon, though, so in some cases it will still default to the terminal-looking icon. It probably would be better to use Wine's wine-glass icon in that case. However, there's a question of how to deploy the icon. I'm not sure a .icns file is useful. I don't know where such a .icns file would be kept and how it would be located relative to the Wine installation (or build directory, if running from there). So, it may just be easiest to embed a Windows ICO resource into the Mac driver .so file and extract it at runtime just like the code will extract the icon from the .exe file. So, thanks for the offer and I'll keep it in mind, but at this point I'm not sure what I would do with Mac icons for Wine. -Ken

2 1

Support for game DRM which overwrite the GS segment selector
by Alessandro Pignotti 03 Feb '13

03 Feb '13

Hi everyone, I'm trying to get a specific game which employs a seemingly custom protection scheme to work. The DRM does various bad things as usual, but a very bad one is manipulating to GS segment selector and setting it to a NULL segment. The GS segment is used by libc though in various ways (stack protection and syscall support, and probably others). I managed to get the activation procedure to go further and further by enclosing each offending syscall using the following 2 macros. #define SAFE_GS_START \ do { \ wine_set_gs(ntdll_get_thread_data()->gs); \ do #define SAFE_GS_END \ while(0); \ } while(0) Still, this method is very cumbersome since system calls happens in many places even outside of ntdll. Fixing the GS is also needed to support sigsetjmp which is used by wine's exception handling. I'd like to ask for feedback about what would be a sane way of supporting this application. A possible solution would be to modify wine's segfault handler to check if the instruction has a GS prefix (0x65 IIRC) and try to execute the instruction again after fixing the GS. Please keep me in CC since I'm not subscribed to the ML. Regards, Alessandro Pignotti

2 3

Re: fusion: return correct error for null public token
by Nikolay Sivov 03 Feb '13

03 Feb '13

> + ok(hr == FUSION_E_PRIVATE_ASM_DISALLOWED, "Expected S_OK, got %08x\n", hr); You could just strip excepted value message part to avoid typos like that. On Fri, Feb 1, 2013 at 8:10 AM, Alistair Leslie-Hughes < leslie_alistair(a)hotmail.com> wrote: > Hi, > The other fusion patch is superseded by this one. > > Changelog: > fusion: return correct error for null public token > > > Best Regards > Alistair Leslie-Hughes > > > > > >

1 0

Re: [PATCH] cryptui: use add_oid_to_usage correctly (Coverity)
by Juan Lang 02 Feb '13

02 Feb '13

Hi Marcus, - add_oid_to_usage(usage, ptr); + usage = add_oid_to_usage(usage, ptr); This looks fine, but would you mind making the same change on line 337? Thanks, --Juan

2 3

Re: kernel32/tests : added tests for copyfileex try7
by Marvin 01 Feb '13

01 Feb '13

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=24239 Your paranoid android. === WNT4WSSP6 (32 bit path) === path: unhandled exception c0000005 at 00000000

1 0

Re: kernel32/tests : added tests for copyfileex try6
by Marvin 31 Jan '13

31 Jan '13

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=24237 Your paranoid android. === WNT4WSSP6 (32 bit path) === Timeout

1 0

Re: [website] Added Simplified Chinese translation
by Jeremy Newman 31 Jan '13

31 Jan '13

Nice work. I did end up moving a few things around, and had to patch my language detection function, but it worked when I switched my browser over to zn-ch. I fixed the image as well. Also, please set your text editor to output 4 spaces instead of tabs. Thanks! -N On 01/30/2013 09:34 PM, Jactry Zeng wrote: > Hi folks, > this is Simplified Chinese translation for Wine's website, it's my first > patch, thanks Qian Hong, Aron Xu, Jeremy and Hin-Tak for review. > I appreciate for any comment. :-)

2 1

[website] Added simplified chinese
by Jactry 31 Jan '13

31 Jan '13

5 7

Re: kernel32/tests : added tests for copyfileex try5
by Marvin 31 Jan '13

31 Jan '13

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=24228 Your paranoid android. === WNT4WSSP6 (32 bit path) === Timeout === W2KPROSP4 (32 bit path) === path.c:1814: Test failed: Expected GetFileAttributesEx to return zero, got 1 === WXPPROSP3 (32 bit path) === path.c:1814: Test failed: Expected GetFileAttributesEx to return zero, got 1 === W2K3R2SESP2 (32 bit path) === path.c:1814: Test failed: Expected GetFileAttributesEx to return zero, got 1 === WVISTAADM (32 bit path) === path.c:1814: Test failed: Expected GetFileAttributesEx to return zero, got 1 === W2K8SE (32 bit path) === path.c:1814: Test failed: Expected GetFileAttributesEx to return zero, got 1 === W7PRO (32 bit path) === path.c:1814: Test failed: Expected GetFileAttributesEx to return zero, got 1 === W7PROX64 (32 bit path) === path.c:1814: Test failed: Expected GetFileAttributesEx to return zero, got 1 === TEST64_W7SP1 (32 bit path) === path.c:1814: Test failed: Expected GetFileAttributesEx to return zero, got 1 === W7PROX64 (64 bit path) === path.c:1814: Test failed: Expected GetFileAttributesEx to return zero, got 1 === TEST64_W7SP1 (64 bit path) === path.c:1814: Test failed: Expected GetFileAttributesEx to return zero, got 1

1 0

Re: [3/3] msi: Improve parsing of the supported platforms string.
by Marvin 31 Jan '13

31 Jan '13

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=24227 Your paranoid android. === WNT4WSSP6 (32 bit install) === install.c:6051: 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: Makedll.rules.in: Explicitly specify DLL name when building importlib
by Alexandre Julliard 31 Jan '13

31 Jan '13

Jacek Caban <jacek(a)codeweavers.com> writes: > --- > dlls/Makedll.rules.in | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Why do you need this? -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: fusion: Allow null to be the value of the public key
by Hans Leidekker 31 Jan '13

31 Jan '13

On Thu, 2013-01-31 at 19:35 +1100, Alistair Leslie-Hughes wrote: > diff --git a/dlls/fusion/asmname.c b/dlls/fusion/asmname.c > index 162a76b..2c4b379 100644 > --- a/dlls/fusion/asmname.c > +++ b/dlls/fusion/asmname.c > @@ -561,6 +561,10 @@ static HRESULT parse_pubkey(IAssemblyNameImpl *name, LPCWSTR pubkey) > { > int i; > BYTE val; > + static WCHAR nullstr[] = {'n','u','l','l',0}; This should be const. > + if(lstrcmpiW(pubkey, nullstr) == 0) > + return S_OK; Please add a test to show that it's case insensitive. > if (lstrlenW(pubkey) < CHARS_PER_PUBKEY) > return FUSION_E_INVALID_NAME; > diff --git a/dlls/fusion/tests/asmcache.c b/dlls/fusion/tests/asmcache.c > index e97cfbe..79f8709 100644 > --- a/dlls/fusion/tests/asmcache.c > +++ b/dlls/fusion/tests/asmcache.c > @@ -1016,6 +1016,10 @@ static void test_QueryAssemblyInfo(void) > 'p','u','b','l','i','c','K','e','y','T','o','k','e','n','=', > '2','d','0','3','6','1','7','b','1','c','3','1','e','2','f','5',',', > 'c','u','l','t','u','r','e','=','n','e','u','t','r','a','l',0}; > + static const WCHAR nullpublickey[] = { > + 'm','s','c','o','r','l','i','n',',','v','e','r','s','i','o','n','=','0', > + 'p','u','b','l','i','c','K','e','y','T','o','k','e','n','=','n','u','l', > + 'c','u','l','t','u','r','e','=','n','e','u','t','r','a','l',0}; > > size = MAX_PATH; > hr = pGetCachePath(ASM_CACHE_GAC, asmpath, &size); > @@ -1386,6 +1390,17 @@ static void test_QueryAssemblyInfo(void) > "Assembly path was changed\n"); > ok(info.cchBuf == MAX_PATH, "Expected MAX_PATH, got %d\n", info.cchBuf); > > + /* display name is "mscorlib.dll,version=0.0.0.0,publicKeyToken=null,culture=neutral" */ This comment doesn't agree with the string initialized above. > + INIT_ASM_INFO(); > + lstrcpyW(name, nullpublickey); > + hr = IAssemblyCache_QueryAssemblyInfo(cache, 0, name, &info); > + ok(info.cbAssemblyInfo == sizeof(ASSEMBLY_INFO), > + "Expected sizeof(ASSEMBLY_INFO), got %d\n", info.cbAssemblyInfo); You should check the return value of QueryAssemblyInfo but CreateAssemblyNameObject is actually a better way to test this.

1 0

Re: fusion: Allow null to be the value of the public key
by Nikolay Sivov 31 Jan '13

31 Jan '13

On 1/31/2013 12:35, Alistair Leslie-Hughes wrote: > Hi, > > > Changelog: > fusion: Allow null to be the value of the public key > + static const WCHAR nullpublickey[] = { > + 'm','s','c','o','r','l','i','n',',','v','e','r','s','i','o','n','=','0', > + 'p','u','b','l','i','c','K','e','y','T','o','k','e','n','=','n','u','l', > + 'c','u','l','t','u','r','e','=','n','e','u','t','r','a','l',0}; You have 'nul' here, not 'null'.

1 0

Clang warnings on OS X ML
by C.W. Betts 31 Jan '13

31 Jan '13

When compiling Wine using Clang, there are a bunch of warnings that pop up, such as: ld: warning: could not create compact unwind for .L__wine_spec_call16_p_pw: dwarf uses DW_CFA_same_value ld: warning: could not create compact unwind for ___wine_stub_VARBSTRFROMR8: stack subq instruction is too different from dwarf stack size On win16 DLLs. And these warnings are with general DLL: ld: warning: could not create compact unwind for ___wine_stub__aullshr: stack subq instruction is too different from dwarf stack size ld: warning: could not create compact unwind for .L__wine_spec_relay_entry_point_52: stack subq instruction is too different from dwarf stack size Another worrying warning is that __force_align_arg_pointer__ being an unknown attribute. There's also a lot of enum conversion warnings. There was also a linker warning about register usage, but I can't seem to find it again. I could upload the whole log, but it is fairly large: 6.4 MB.

2 1

Re: [website] Added Simplified Chinese translation
by Qian Hong 31 Jan '13

31 Jan '13

On Thu, Jan 31, 2013 at 11:34 AM, Jactry Zeng <jactry92(a)gmail.com> wrote: > Hi folks, > this is Simplified Chinese translation for Wine's website The translation looks good to me, thanks for the great work! -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/

1 0

[PATCH for valgrind] coregrind: implement GS override for arch_prctl on linux
by Maarten Lankhorst 30 Jan '13

30 Jan '13

Allows wine64 to run in valgrind! Apply with -Np0. :D Yes I know that %gs is still zero on linux amd64. Details details.. Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)ubuntu.com> --- Index: coregrind/m_translate.c =================================================================== --- coregrind/m_translate.c (revision 13279) +++ coregrind/m_translate.c (working copy) @@ -1486,7 +1486,7 @@ # if defined(VGP_amd64_linux) vex_abiinfo.guest_amd64_assume_fs_is_zero = True; # endif -# if defined(VGP_amd64_darwin) +# if defined(VGP_amd64_darwin) || defined(VGP_amd64_linux) vex_abiinfo.guest_amd64_assume_gs_is_0x60 = True; # endif # if defined(VGP_ppc32_linux) Index: coregrind/m_syswrap/syswrap-amd64-linux.c =================================================================== --- coregrind/m_syswrap/syswrap-amd64-linux.c (revision 13279) +++ coregrind/m_syswrap/syswrap-amd64-linux.c (working copy) @@ -564,6 +564,16 @@ *(unsigned long *)ARG2 = tst->arch.vex.guest_FS_ZERO; POST_MEM_WRITE(ARG2, sizeof(unsigned long)); } + else if (ARG1 == VKI_ARCH_SET_GS) { + tst = VG_(get_ThreadState)(tid); + tst->arch.vex.guest_GS_0x60 = ARG2; + } + else if (ARG1 == VKI_ARCH_GET_GS) { + PRE_MEM_WRITE("arch_prctl(addr)", ARG2, sizeof(unsigned long)); + tst = VG_(get_ThreadState)(tid); + *(unsigned long *)ARG2 = tst->arch.vex.guest_GS_0x60; + POST_MEM_WRITE(ARG2, sizeof(unsigned long)); + } else { VG_(core_panic)("Unsupported arch_prtctl option"); }

1 0

Re: [PATCH 8/8] wininet: Get rid of WORKREQ* types
by Juan Lang 30 Jan '13

30 Jan '13

Hi Jacek, just wanted to say these series of patches make me happy :) lpfnHungarianNotationDieDieDie ;) --Juan

1 0

Re: windowscodecs: Implement GetThumbnail in the ICO frame decoder.
by Hans Leidekker 30 Jan '13

30 Jan '13

On Wed, 2013-01-30 at 18:02 +0800, Dmitry Timoshkov wrote: > diff --git a/dlls/windowscodecs/icoformat.c b/dlls/windowscodecs/icoformat.c > index 7aec245..da5a733 100644 > --- a/dlls/windowscodecs/icoformat.c > +++ b/dlls/windowscodecs/icoformat.c > @@ -200,8 +200,12 @@ static HRESULT WINAPI IcoFrameDecode_GetColorContexts(IWICBitmapFrameDecode *ifa > static HRESULT WINAPI IcoFrameDecode_GetThumbnail(IWICBitmapFrameDecode *iface, > IWICBitmapSource **ppIThumbnail) > { > - FIXME("(%p,%p)\n", iface, ppIThumbnail); > - return E_NOTIMPL; > + TRACE("(%p,%p)\n", iface, ppIThumbnail); > + > + if (!ppIThumbnail) return E_INVALIDARG; > + > + *ppIThumbnail = NULL; > + return WINCODEC_ERR_CODECNOTHUMBNAIL; > } The test added by 6395af1ae7b0cc5f2f1f82796502e2a605bc5a6b says otherwise, GetThumbnail is supported for ICO frames.

2 3

Re: [2/6] windowscodecs: Implement ComponentFactory::CreateEncoderPropertyBag
by Alexandre Julliard 29 Jan '13

29 Jan '13

Ludger Sprenker <Ludger(a)sprenker.net> writes: > Previous "[2/5]" should have been "[3/6]" ... It doesn't build on Mac: gcc -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -DENTRY_PREFIX=WIC_ -DPROXY_DELEGATION -DWINE_REGISTER_DLL -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wwrite-strings -gstabs+ -fno-omit-frame-pointer -Wpointer-arith -I/sw/include/freetype2 -I/sw/include -I/sw/include -g -O2 -o icnsformat.o icnsformat.c icnsformat.c: In function 'IcnsEncoder_CreateNewFrame': icnsformat.c:666: warning: passing argument 1 of 'CreatePropertyBag2' from incompatible pointer type icnsformat.c:666: error: too few arguments to function 'CreatePropertyBag2' -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: gdiplus: Avoid not necessary memory allocation for BITMAPINFO.
by Vincent Povirk 29 Jan '13

29 Jan '13

Did you try running the tests in valgrind with this change? You're essentially reverting 0ecd8daa16e4aa3df157a1175c611cdffc66d6fe which I think was done to make valgrind happy.

1 0

Re: kernel32: dstlen < 0 causes error in codepage conversion
by Alexandre Julliard 29 Jan '13

29 Jan '13

Alex Henrie <alexhenrie24(a)gmail.com> writes: > This is a pretty straightforward patch to resolve a couple of test > failures marked todo_wine. Hopefully it's not controversial, but if it > is, I am willing to make any reasonable modifications that are > communicated to me. If it was that easy it would have been done already. There are places in Wine that depend on being able to use negative sizes, so it would need a code review of all callers before we can make that change. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: winealsa: Have the MIDI recorder wait in poll(), not snd_seq_event_input().
by Johannes Kroll 29 Jan '13

29 Jan '13

On Thu, 24 Jan 2013 10:33:58 +0100 <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > Compare with wineoss which uses poll <= 0 already... > > Johannes Kroll mentioned that MIDIIn takes a long time to end. > Indeed, our testsuite ran 3 times into the "kill after 5s" timeout due to this bug. > Now the tests execute much faster. Just a quick note to confirm that this patch does fix the waiting problem for me. Thanks a lot! - Johannes

1 0

Re: riched20: ME_StrDup() is no longer used so remove it.
by Huw Davies 29 Jan '13

29 Jan '13

On Tue, Jan 29, 2013 at 07:05:13AM +0100, Francois Gouget wrote: > --- > dlls/riched20/editor.h | 1 - > dlls/riched20/string.c | 5 ----- > 2 files changed, 6 deletions(-) I'm about to send in a patch that uses this again, so please hold off on this one. Huw.

1 0

Re: winemenubuilder: Try to wait for creating icon files (try 2).
by Sergey Guralnik 29 Jan '13

29 Jan '13

On 2013-01-23 16:34, Sergey Guralnik wrote: > It supersedes next patch: > > From 4ca51cf16c5be2bcf34dddb7f33fe043c1d777c4 Mon Sep 17 00:00:00 > 2001 > From: Sergey Guralnik <serhio(a)etersoft.ru> > Date: Tue, 22 Jan 2013 15:58:20 +0200 > Subject: winemenubuilder: Use only existing file for icon creating. > > The logic is the same as before - wait for parent process termination > if > required icon file doesn't exist yet. But now used easier way to do > this. Is something wrong with this patch? It's in queue about a week without any feedback. -- Sergey

1 0

Re: [PATCH] winebuild: Use Clang to assemble if found. (try 5)
by Alexandre Julliard 28 Jan '13

28 Jan '13

Charles Davis <cdavis5x(a)gmail.com> writes: > Try 5: Don't use strstr(3). > > The configure script invokes the C compiler to figure out if .cfi > pseudo-ops are supported, on the assumption that it will invoke the > system assembler. Winebuild, on the other hand, invokes the system > assembler directly. This caused a problem on Mac OS hosts when compiling > with Clang: configure would detect that .cfi ops were supported, because > Clang's integrated assembler supports them; however, when winebuild then > emitted assembly with .cfi ops in them, the system assembler would then > choke. This patch makes winebuild invoke Clang's assembler if it is > found in the path. It's causing warnings on my Mac: clang: warning: /usr/bin/clang: 'linker' input unused when '-c' is present clang: warning: /usr/bin/clang: 'linker' input unused when '-c' is present -- Alexandre Julliard julliard(a)winehq.org

1 0

Why 0.1.0.0 as local socket address instead of 127.0.0.1?
by Francois Gouget 27 Jan '13

27 Jan '13

The ws2_32:sock fails on some of my machines with the following error: sock.c:4794: Test failed: Local socket address is different 0.1.0.0 != 127.0.0.1 Does anyone know why we GetAcceptExSockaddrs() would return 0.1.0.0 instead of 127.0.0.1? Looking at the Windows 7 winetest results it does not appear to be correlated with either the SP1 or IE9. For instance got an error on Windows 7 + SP1 + IE9 (32 and 64-bit): http://test.winehq.org/data/b233d2054e64e216a5b3868f301bfc934b019b4b/win7_f… http://test.winehq.org/data/b233d2054e64e216a5b3868f301bfc934b019b4b/win7_f… But not here (Windows 7 + SP1 + IE9 64-bit): http://test.winehq.org/data/83846cd131aac33228bf08aefae0bf0ea93d4273/win7_f… I also got it failing at least once on a Windows 2000 SP4 VM: http://test.winehq.org/data/b233d2054e64e216a5b3868f301bfc934b019b4b/2000_f… But never saw it fail on my Windows XP or 2003 VMs. -- Francois Gouget <fgouget(a)codeweavers.com>

2 1

FOSDEM logistics
by Jeremy White 27 Jan '13

27 Jan '13

Hi folks, Alright, this is it - we're going to try to get together at FOSDEM starting this Friday. If you are planning on being there, you should make sure to subscribe to the wineconf mailing list: http://www.winehq.org/mailman/listinfo/wineconf All further logistics emails and discussions will take place there. So if you're not subscribed, you can't complain we didn't try to include you in the planning. We plan on informally assembling in the lobby / bar of the Best Western Hotel Royal Centre (http://www.royalcentre.be/) on Friday, most likely starting in late afternoon. I don't have any plans for Saturday; I'll likely go harangue the Xorg guys, and maybe catch the key note. We may try to informally gather as well. However, there is no plan for Saturday dinner (sorry, no sponsored dinner by CodeWeavers this year). I have no idea how FOSDEM usually works on Saturday night, so I figured we'd just play it be year. Advice is welcome. Our devroom starts Sunday at 9:00 am. We're in building K, which you can see on this map: http://www.ulb.ac.be/campus/solbosch/plan-K.html Main FOSDEM entrance / registration is in building H on that map. One bit of unsolicited advice - when I naively copy/paste the address on the FOSDEM page into Google maps for directions, I end up with the wrong location. If you're at the Best Western, it looks like Tram 94 goes to the Legrand stop in 16 minutes, and then a 10 minute walk carries you the rest of the way there. Looking forward to seeing you all on Friday! Cheers, Jeremy

1 0

Re: wined3d: Rebind texture before checking for its content in check_fbo_compat().
by Stefan Dösinger 27 Jan '13

27 Jan '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2013-01-26 22:32, schrieb Matteo Bruni: > + > gl_info->fbo_ops.glFramebufferTexture2D(GL_FRAMEBUFFER, > GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, tex, 0); Do you really have to re-attach it to the FBO? Or does glBindTexture(GL_TEXTURE_2D, tex) work as well? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRBFTlAAoJEN0/YqbEcdMw7bcQAIfUM81xBr3zIpcEYek3gMso jXPq49+8Dp8Y3xiJGU/nFD8yLH9Y24SXpyageueCMWZR2jnEQcXBL0l76MmL5ZYK Y/L1ytRwrOvdXP07pJ8p3ZXxmA6hl82fuNxMvYhlSYP8PVCoobhaH7MwGp9WPpGF Ij20eOOR3GQnDjb6M2qHHfP9s+mNREu5NrvZ76NCf/lURXLJyDECuMz+6TbSl4CM qv0xCKdtqxm13gTZio3ftKc3QZZUSstiYjUYQmFh5NXQe5oIr9j2/iueU2K0zA/M CqswN4divbFFbh7QwCIDaubwfGidRfiwIG3lCCiNpfIvnowQouELIoFKjIipQ1AL ihIIS7iyekasAxkErVZ3E8O8IJCKYbTC+tAXBfK3niKmSRfdUB9cmfo5nVZw4Xjb 3/Zz84WnjMlIznyBGsKyKX+VLKlqzXY5zCyboHuEWPxTXdS0FAbwHzz06Kv0zIqc Pe4X6dJOUz6EPnx2gkbtFygGFbAa8haWhiIcY01H1bMSa7NnZPU3QgQXimrvXaKK SbQofZfhbNSVv0dL1kxqUYeLPb5hKXqMRHO7yi/GeyejTie9onzjxrjt4zn4rxe3 9IEZ0ymUYs499ahUnW/DAe0yFJvX+EXiPIiWwLBGVpx/Dzduk0WADOLBaN/YwrEz 1gxkuQjF2tbVSTkP41yr =xi8z -----END PGP SIGNATURE-----

3 3

Implement D3DXSHEvalConeLight
by Nozomi Kodama 26 Jan '13

26 Jan '13

Hello what is the problem with the patch http://source.winehq.org/patches/data/93498 Nozomi

1 0

Re: [PATCH] gdi32: Adjust a fixed-pitch full-width character has double advance of a half-width character. (try 5)
by Alexandre Julliard 26 Jan '13

26 Jan '13

Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > Hi, > > This patch enhances full-width character glyph advance when we choose > fixed-pitch font. > > Windows 2000 (or XP for Japanese) and later adjust fixed-pitch > full-width character glyph advances so that two half-width characters' > advance equals to one full-width character's advance. Because CJK > fixed-pitch font, such as MS Gothic, is designed as full-width character > (e.g. Kanji) has a double advance of half-width character (e.g. ASCII) > and many developpers expect that. > > Please refer Microsoft document KB 417434 [1] and white paper [2] for > details. > > [1] ... http://support.microsoft.com/kb/417434/ja (written in Japanese) > [2] ... http://msdn.microsoft.com/ja-jp/library/cc979401.aspx (written in Japanese) > > try 5: > - Add patch description above. > - Fix avgAdvance's rounding method. (as in get_outline_text_metrics) > - Refine a commit message, "Ensure" to "Adjust" and "double width" to > "double advance". > > try 4: > - Fix full-width character detection that causes test failure. > > try 3: > - Improve full-width character detection. > - Support fake italic transformation. > - Choose non-linked fonts in the test case. > - Add more trace messages. > > try 2: > - Add rotated transformation tests. > > Regards, > Akihiro Sagawa > > --- > dlls/gdi32/freetype.c | 37 ++++++++++++++++++-- > dlls/gdi32/tests/font.c | 87 +++++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 121 insertions(+), 3 deletions(-) This is still failing here: ../../../tools/runtest -q -P wine -M gdi32.dll -T ../../.. -p gdi32_test.exe.so font.c && touch font.ok font.c:2549: Tests skipped: Font Droid Arabic Naskh doesn't contain 'x', skipping the test font.c:2549: Tests skipped: Font Droid Sans Armenian doesn't contain 'x', skipping the test font.c:2549: Tests skipped: Font Droid Sans Ethiopic doesn't contain 'x', skipping the test font.c:2549: Tests skipped: Font Droid Sans Georgian doesn't contain 'x', skipping the test font.c:2549: Tests skipped: Font Droid Sans Hebrew doesn't contain 'x', skipping the test font.c:2549: Tests skipped: Font Droid Sans Hebrew doesn't contain 'x', skipping the test font.c:3008: Tests skipped: Unable to retrieve first and last glyphs from cmap font.c:2549: Tests skipped: Font Droid Sans Japanese doesn't contain 'x', skipping the test font.c:2549: Tests skipped: Font Droid Sans Thai doesn't contain 'x', skipping the test font.c:2549: Tests skipped: Font OpenSymbol doesn't contain 'x', skipping the test font.c:2549: Tests skipped: Font rsfs10 doesn't contain 'x', skipping the test font.c:3756: Test failed: expected 19, got 0 (@IPAGothic:128) make[1]: *** [font.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH] winebuild: Use Clang to assemble if found. (try 4)
by Alexandre Julliard 25 Jan '13

25 Jan '13

Charles Davis <cdavis5x(a)gmail.com> writes: > @@ -346,13 +352,26 @@ struct strarray *get_as_command(void) > struct strarray *args = strarray_init(); > > if (!as_command) > + as_command = find_tool( "clang", NULL ); > + > + if (!as_command) > { > static const char * const commands[] = { "gas", "as", NULL }; > as_command = find_tool( "as", commands ); > } > + > + if (!as_command) > + fatal_error( "cannot find suitable assembler\n" ); > + > strarray_add_one( args, as_command ); > > - if (force_pointer_size) > + if (strstr( as_command, "clang" )) It's looking better, but strstr is not appropriate here. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/2] jscript: Fixed a leak in regexp_match function
by Marcus Meissner 25 Jan '13

25 Jan '13

On Fri, Jan 25, 2013 at 04:26:59PM +0100, Piotr Caban wrote: > --- > dlls/jscript/regexp.c | 11 ++++++++--- > 1 file changed, 8 insertions(+), 3 deletions(-) > > > diff --git a/dlls/jscript/regexp.c b/dlls/jscript/regexp.c > index 0d66551..fa2668c 100644 > --- a/dlls/jscript/regexp.c > +++ b/dlls/jscript/regexp.c > @@ -3466,10 +3466,15 @@ static HRESULT regexp_match(script_ctx_t *ctx, jsdisp_t *dispex, jsstr_t *str, B > break; > > if(ret_size == i) { > - if(ret) > - ret = heap_realloc(ret, (ret_size <<= 1) * sizeof(match_result_t)); > - else > + if(ret) { > + match_result_t *old_ret = ret; > + > + ret = heap_realloc(old_ret, (ret_size <<= 1) * sizeof(match_result_t)); > + if(!ret) > + heap_free(old_ret); Should be probably if (ret) heap_free(old_ret); here. > + }else { > ret = heap_alloc((ret_size=4) * sizeof(match_result_t)); > + } > if(!ret) { > hres = E_OUTOFMEMORY; > break; > >

2 1

Re: [1/5] comctl32/tests: more tests for icon spacing calculation
by Alexandre Julliard 25 Jan '13

25 Jan '13

Daniel Jelinski <djelinski1(a)gmail.com> writes: > +#ifdef _WIN64 > + /* NOTE: -1 is not treated the same as (DWORD)-1 by 64bit listview */ > + ret = SendMessage(hwnd, LVM_SETICONSPACING, 0, (DWORD)-1); > +todo_wine { > + expect(100, LOWORD(ret)); > + expect(0xFFFF, HIWORD(ret)); > +} > + ret = SendMessage(hwnd, LVM_SETICONSPACING, 0, 0xBAADF00DDEADBEEFLL); Please avoid ifdefs and long long constants. -- Alexandre Julliard julliard(a)winehq.org

3 2

Wine Wiki needs your help!
by Dimi Paun 25 Jan '13

25 Jan '13

Folks, As we all know, through the years spam has been an ongoing problem. We dealt with it OK, as we valued the openness of our wiki. That's good. However, all this churn has accumulated a lot of garbage on the system, as orphaned pages and dummy users. These have accumulated to such an extent that we are reaching system limits. I need your help to clean them out. First, we have to separate the spam from the real content. I've created a Google Spreadsheet for pages: https://docs.google.com/a/lattica.com/spreadsheet/ccc?key=0AmY-Kp_Ihu3idFNE… and one for users: https://docs.google.com/a/lattica.com/spreadsheet/ccc?key=0AmY-Kp_Ihu3idGdP… We need to mark spam as "Spam" and what's good as "OK" in the "Spam" column. I'll take that data and apply it to the wiki. Please let me know if we can do this any simpler or if there are any problems. Thanks! -- Dimi Paun Lattica, Inc.

8 18

Re: [1/6] windowscodecs: Add tests for IPropertyBag2
by Vincent Povirk 24 Jan '13

24 Jan '13

Other than the 6/6, this series looks good to me. Thanks for breaking this up. It makes it much easier to review.

1 0

Re: [6/6] windowscodecs: Implement IPropertyBag2::Read
by Vincent Povirk 24 Jan '13

24 Jan '13

+ if (idx > -1) + { + VariantInit(pvarValue+i); + res = VariantCopy(pvarValue+i, This->values+idx); + phrError[i] = res; + if (FAILED(res)) + break; + } This looks wrong to me. We have an array of error values to set for each read attempt, so it seems like each read should be independent - one failure shouldn't cause us to give up on the others, nor to free the values we already read successfully. If this is really how Windows works, we need a test for it.

1 0

Re: [5/6] windowscodecs: Implement IPropertyBag2::Write
by Vincent Povirk 24 Jan '13

24 Jan '13

if (This->properties[i].pstrName) { HeapFree(GetProcessHeap(), 0, This->properties[i].pstrName); + VariantClear( This->values+i ); /* Not initialized if pstrName not initialized */ } ... { This->properties = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(PROPBAG2)*count); - - if (!This->properties) + This->values = HeapAlloc(GetProcessHeap(), 0, sizeof(VARIANT)*count); + + if (!This->properties || !This->values) res = E_OUTOFMEMORY; else for (i=0; i < count; i++) Well, that explains why you had the NULL check in the previous patch. If you allocate values with HEAP_ZERO_MEMORY, you don't have to use VariantInit, and you could simplify your Release code (at least in terms of the effort required to verify that it is correct). I think the way it is now is technically correct though. + { + if (pPropBag[i].pstrName) + FIXME("Application tried to set the unknown option %s.\n", + debugstr_w(pPropBag[i].pstrName)); + /* FIXME: Function is not atomar on error, but MSDN does not say anything about it + * (no reset of items between 0 and i-1) */ + return E_FAIL; + } Bit of an indentation glitch there - the return statement isn't (and shouldn't be) in the if statement.

1 0

Re: [4/6] windowscodecs: Implement IPropertyBag2::GetPropertyInfo
by Vincent Povirk 24 Jan '13

24 Jan '13

+ if (This->properties[i].pstrName) + { + HeapFree(GetProcessHeap(), 0, This->properties[i].pstrName); + } HeapFree already checks for NULL, so there's no need for an if statement here.

1 0

Re: [PATCH] ieframe/tests: Don't convert to long path name until the file exists
by Marvin 24 Jan '13

24 Jan '13

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=24128 Your paranoid android. === WNT4WSSP6 (32 bit webbrowser) === Timeout === W2KPROSP4 (32 bit webbrowser) === webbrowser.c:2607: Test failed: expected GetOverridesKeyPath webbrowser.c:2612: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2613: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:3046: Test failed: doc_disp == NULL webbrowser: unhandled exception c0000005 at 00402F21

1 0

Re: ws2_32: Use assignment instead of memcpy to copy structs.
by Michael Stefaniuc 24 Jan '13

24 Jan '13

Forgot to add the credit for this patch series as I didn't wrote this coccinelle script: Found using the memcpy-assign.cocci script submitted for inclusion into the Linux kernel: https://systeme.lip6.fr/pipermail/cocci/2013-January/000121.html bye michael On 01/24/2013 02:21 PM, Michael Stefaniuc wrote: > --- > dlls/ws2_32/socket.c | 2 +- > dlls/ws2_32/tests/sock.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/ws2_32/socket.c b/dlls/ws2_32/socket.c > index c390828..6fd1e34 100644 > --- a/dlls/ws2_32/socket.c > +++ b/dlls/ws2_32/socket.c > @@ -2183,7 +2183,7 @@ static BOOL interface_bind( SOCKET s, int fd, struct sockaddr *addr ) > > if (setsockopt(fd, IPPROTO_IP, IP_UNICAST_IF, &ifindex, sizeof(ifindex)) != 0) > goto cleanup; /* Failed to suggest egress interface */ > - memcpy(&specific_interface_filter, &generic_interface_filter, sizeof(generic_interface_filter)); > + specific_interface_filter = generic_interface_filter; > specific_interface_filter.iface_rule.k = adapter->Index; > filter_prog.len = sizeof(generic_interface_filter)/sizeof(struct sock_filter); > filter_prog.filter = (struct sock_filter *) &specific_interface_filter; > diff --git a/dlls/ws2_32/tests/sock.c b/dlls/ws2_32/tests/sock.c > index 56a64bc..4b4b99a 100644 > --- a/dlls/ws2_32/tests/sock.c > +++ b/dlls/ws2_32/tests/sock.c > @@ -2725,7 +2725,7 @@ static void test_getsockname(void) > return; > } > > - memcpy(&sa_get, &sa_set, sizeof(sa_set)); > + sa_get = sa_set; > if (getsockname(sock, (struct sockaddr*) &sa_get, &sa_get_len) == 0) > ok(0, "getsockname on unbound socket should fail\n"); > else {

1 0

Re: ieframe: Fixed a race in tests
by Marvin 24 Jan '13

24 Jan '13

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=24121 Your paranoid android. === WNT4WSSP6 (32 bit webbrowser) === Timeout === W2KPROSP4 (32 bit webbrowser) === webbrowser.c:2607: Test failed: expected GetOverridesKeyPath webbrowser.c:2612: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2613: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:3046: Test failed: doc_disp == NULL webbrowser: unhandled exception c0000005 at 00402F21

1 0

Re: [PATCH 2/2] vbscript: Added GetObject tests
by Marvin 24 Jan '13

24 Jan '13

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=24115 Your paranoid android. === W2KPROSP4 (32 bit createobj) === createobj.c:999: Test failed: ParseScriptText failed: 8007007e createobj.c:1000: Test failed: expected QI_IObjectWithSite createobj.c:1001: Test failed: expected SetSite createobj.c:1002: Test failed: expected reportSuccess createobj.c:1008: Test failed: hres = 8007007e createobj.c:1009: Test failed: expected QI_IObjectWithSite createobj.c:1010: Test failed: expected SetSite createobj.c:1015: Test failed: ParseScriptText failed: 8007007e createobj.c:1016: Test failed: expected QI_IObjectWithSite createobj.c:1017: Test failed: expected reportSuccess

1 0

Please perform MIDI test with MS OS
by Joerg-Cyril.Hoehle＠t-systems.com 24 Jan '13

24 Jan '13

Hi, if you can, please download the test executable from https://testbot.winehq.org/JobDetails.pl?Key=24107 and run it on a native MS machine (32 and 64 bit). Please send me the results, no need to post. I particularly welcome test results from old w9k machines! Thank you, Jörg Höhle

1 0

Re: [PATCH] kernel32: implement condition variables (try 5)
by Marvin 24 Jan '13

24 Jan '13

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=24106 Your paranoid android. === W7PROX64 (32 bit sync) === sync.c:947: Test failed: DeleteTimerQueueTimer sync.c:948: Test failed: ChangeTimerQueueTimer

1 0

Re: [PATCH 5/5] d3d*/tests: Add simple DrawRectPatch tests
by Marvin 24 Jan '13

24 Jan '13

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=24105 Your paranoid android. === WXPPROSP3 (32 bit device) === device.c:6157: Test failed: Failed to get caps, hr 0x8876086a. === W2K3R2SESP2 (32 bit device) === device.c:6157: Test failed: Failed to get caps, hr 0x8876086a. === WVISTAADM (32 bit device) === device.c:6157: Test failed: Failed to get caps, hr 0x8876086a. === W2K8SE (32 bit device) === device.c:6157: Test failed: Failed to get caps, hr 0x8876086a. === W7PRO (32 bit device) === device.c:6157: Test failed: Failed to get caps, hr 0x8876086a. === W7PROX64 (32 bit device) === device.c:6157: Test failed: Failed to get caps, hr 0x8876086a. === TEST64_W7SP1 (32 bit device) === device.c:6157: Test failed: Failed to get caps, hr 0x8876086a. === W7PROX64 (64 bit device) === device.c:6157: Test failed: Failed to get caps, hr 0x8876086a. === TEST64_W7SP1 (64 bit device) === device.c:6157: Test failed: Failed to get caps, hr 0x8876086a.

1 0

Re: [PATCH 5/5] d3d*/tests: Add simple DrawRectPatch tests
by Marvin 24 Jan '13

24 Jan '13

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=24104 Your paranoid android. === WXPPROSP3 (32 bit device) === device.c:4661: Test failed: Failed to get caps, hr 0x8876086a. === W2K3R2SESP2 (32 bit device) === device.c:4661: Test failed: Failed to get caps, hr 0x8876086a. === WVISTAADM (32 bit device) === device.c:4661: Test failed: Failed to get caps, hr 0x8876086a. === W2K8SE (32 bit device) === device.c:4661: Test failed: Failed to get caps, hr 0x8876086a. === W7PRO (32 bit device) === device.c:4661: Test failed: Failed to get caps, hr 0x8876086a. === W7PROX64 (32 bit device) === device.c:4661: Test failed: Failed to get caps, hr 0x8876086a. === TEST64_W7SP1 (32 bit device) === device.c:4661: Test failed: Failed to get caps, hr 0x8876086a.

1 0

Re: po: Update Lithuanian translation
by Lauri Kenttä 23 Jan '13

23 Jan '13

I don't really read Lithuanian, but just in case: "No Ports" means "number of ports" or more exactly "number of datagrams which were rejected because the port in the datagram was invalid". Reference: http://msdn.microsoft.com/en-us/library/windows/desktop/aa366929%28v=vs.85%… André, any chance to make the original string (netstat.rc:52, "No Ports") better? -- Lauri Kenttä

1 0

Re: [PATCH 1/8] winhttp: Use schannel in netconn_secure_connect if OpenSSL is not available
by Alexandre Julliard 23 Jan '13

23 Jan '13

Jacek Caban <jacek(a)codeweavers.com> writes: > The following patch makes winhttp use schannel instead of OpenSSL for > SSL (HTTPS) connections. It is made to be as minimal change as possible > (but complete enough to replace all OpenSSL functionality) to limit the > scope for potential regressions. Further changes and improvements are > left for later. It doesn't work here: ../../../tools/runtest -q -P wine -M winhttp.dll -T ../../.. -p winhttp_test.exe.so winhttp.c && touch winhttp.ok net.c:607: read_ssl_chunk: Assertion `bufs[0].cbBuffer < ssl_buf_size' failed. wine: Assertion failed at address 0x68000822 (thread 0028), starting debugger... Unhandled exception: assertion failed in 32-bit code (0x68000822). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:68000822 ESP:0032f29c EBP:0032f2a8 EFLAGS:00000206( - -- I - -P- ) EAX:00000000 EBX:000057a6 ECX:000057a6 EDX:00000006 ESI:682e429f EDI:68308ff4 Stack dump: 0x0032f29c: 681d4941 68308ff4 0032f3c8 0032f3d0 0x0032f2ac: 681d7d72 00000006 0032f348 00000000 0x0032f2bc: 0032f2f0 682208ed 00000068 00000058 0x0032f2cc: 0032f3e0 0032f30c 00000068 00000058 0x0032f2dc: 00000050 7d99bd70 68308ff4 00000050 0x0032f2ec: 0000004f 0032f3b8 6820fa92 7d99bd78 Backtrace: =>0 0x68000822 GLIBC_2+0x822() in ld-linux.so.2 (0x0032f2a8) 1 0x681d7d72 abort+0x181() in libc.so.6 (0x0032f3d0) 2 0x681cdb58 __assert_fail+0xf7() in libc.so.6 (0x0032f418) 3 0x68510524 netconn_recv+0x7c3(conn=0x12e98c, buf=0x32fc8d, len=0x13, flags=0x100, recvd=0x32f508) [/home/julliard/wine/wine/dlls/winhttp/net.c:607] in winhttp (0x0032f4c8) 4 0x68513b91 receive_data_chunked+0x80(request=0x12e938, buffer=0x32fc8d, size=0x20, read=0x32fb14, async=0) [/home/julliard/wine/wine/dlls/winhttp/request.c:1733] in winhttp (0x0032fad8) 5 0x685186ed read_data+0x18c(request=0x12e938, buffer=0x32fc80, to_read=0x20, read=0x32fc6c, async=0) [/home/julliard/wine/wine/dlls/winhttp/request.c:1799] in winhttp (0x0032fb68) 6 0x6851a0c2 WinHttpReadData+0x81(hrequest=<couldn't compute location>, buffer=<couldn't compute location>, to_read=<couldn't compute location>, read=<couldn't compute location>) [/home/julliard/wine/wine/dlls/winhttp/request.c:2097] in winhttp (0x0032fbb8) 7 0x684ef626 func_winhttp+0xdd5() [/home/julliard/wine/wine/dlls/winhttp/tests/winhttp.c:879] in winhttp_test (0x0032fd38) 8 0x684de037 main+0x386(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/dlls/winhttp/tests/../../../include/wine/test.h:557] in winhttp_test (0x0032fe08) 9 0x684f2e60 __wine_spec_exe_entry+0x7f(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in winhttp_test (0x0032fe58) 10 0x7b8602bc call_process_entry+0xb() in kernel32 (0x0032fe78) 11 0x7b86149b start_process+0x6a(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/kernel32/process.c:1084] in kernel32 (0x0032feb8) 12 0x7bc7a2e0 call_thread_func_wrapper+0xb() in ntdll (0x0032fed8) 13 0x7bc7d09d call_thread_func+0x7c(entry=0x7b861430, arg=0x7ffdf000, frame=0x32ffc8) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2522] in ntdll (0x0032ffa8) 14 0x7bc7a2be call_thread_entry_point+0x11() in ntdll (0x0032ffc8) 15 0x7bc4fc4e start_process+0x1d(kernel_start=0x7b861430) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2691] in ntdll (0x0032ffe8) 16 0x6802947d wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) 17 0x6802953b wine_switch_to_stack+0x2a(func=0x7bc4fc30, arg=0x7b861430, stack=0x330000) [/home/julliard/wine/wine/libs/wine/port.c:59] in libwine.so.1 (0xfffe93e8) 18 0x7bc5573f LdrInitializeThunk+0x3be(kernel_start=<couldn't compute location>, unknown2=<couldn't compute location>, unknown3=<couldn't compute location>, unknown4=<couldn't compute location>) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2747] in ntdll (0xfffe9458) 19 0x7b867a78 __wine_kernel_init+0xbe7() [/home/julliard/wine/wine/dlls/kernel32/process.c:1257] in kernel32 (0xfffea368) 20 0x7bc55e13 __wine_process_init+0x182() [/home/julliard/wine/wine/dlls/ntdll/loader.c:2956] in ntdll (0xfffea3f8) 21 0x680270c2 wine_init+0x2a1(argc=0x3, argv=0xfffea944, error="", error_size=0x400) [/home/julliard/wine/wine/libs/wine/loader.c:841] in libwine.so.1 (0xfffea458) 22 0x7bf00e7b main+0x7a(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/loader/main.c:237] in <wine-loader> (0xfffea898) -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH] wined3d: Ignore clears if count = 0 and rects != NULL
by Henri Verbeet 23 Jan '13

23 Jan '13

On 23 January 2013 13:14, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > dlls/d3d8/tests/visual.c | 17 +++++++++++++++++ > dlls/d3d9/tests/visual.c | 16 ++++++++++++++++ > dlls/ddraw/tests/ddraw7.c | 36 ++++++++++++++++++++++++++++++++++++ > dlls/wined3d/device.c | 6 ++++++ > 4 files changed, 75 insertions(+) > Although I don't expect a difference in behaviour, it probably wouldn't hurt to add tests for the other ddraw versions as well (i.e. through the viewport interface).

2 2

Re: [PATCH] advapi32: Use the lower 32bit of the special HKEYs on 64bit.
by Alexandre Julliard 23 Jan '13

23 Jan '13

Rico Schüller <kgbricola(a)web.de> writes: > @@ -228,9 +228,9 @@ static NTSTATUS open_key( HKEY *retkey, ACCESS_MASK access, OBJECT_ATTRIBUTES *a > static HKEY create_special_root_hkey( HKEY hkey, DWORD access ) > { > HKEY ret = 0; > - int idx = (UINT_PTR)hkey - (UINT_PTR)HKEY_SPECIAL_ROOT_FIRST; > + int idx = (DWORD)hkey - (DWORD)HKEY_SPECIAL_ROOT_FIRST; > > - if (hkey == HKEY_CURRENT_USER) > + if ((DWORD)hkey == (DWORD)HKEY_CURRENT_USER) You want HandleToUlong and the like. > @@ -947,6 +948,57 @@ static void test_reg_open_key(void) > "RegOpenKeyEx with KEY_WOW64_64KEY failed (err=%u)\n", ret); > RegCloseKey(hkResult); > > + /* check special HKEYs on 64bit > + * only the lower 4 bytes of the supplied key are used > + */ > + if (ptr_size == 64) > + { > + DWORD mask = ~0U; > + HKEY hkBig = (HKEY)((ULONG_PTR)HKEY_CURRENT_USER & mask); > + > + ret = RegOpenKeyA(HKEY_CURRENT_USER, "Software", &hkResult); > + ok(ret == ERROR_SUCCESS, "expected ERROR_SUCCESS, got %d\n", ret); > + ok(hkResult != NULL, "expected hkResult != NULL\n"); > + hkPreserve = hkResult; > + RegCloseKey(hkResult); > + > + hkBig = (HKEY)(((ULONG_PTR)HKEY_CURRENT_USER & mask) | 0x100000000ULL); > + ret = RegOpenKeyA(hkBig, "Software", &hkResult); > + ok(ret == ERROR_SUCCESS, "expected ERROR_SUCCESS, got %d\n", ret); > + ok(hkResult == hkPreserve, "expected hkResult == hkPreserve\n"); > + RegCloseKey(hkResult); Please don't use long long constants. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] advapi32: Use the lower 32bit of the special HKEYs on 64bit.
by Rico Schüller 23 Jan '13

23 Jan '13

Hi, please don't apply this one, I somehow garbled the rebase ... Cheers Rico On 23.01.2013 12:24, Rico Schüller wrote: > --- > dlls/advapi32/registry.c | 18 +++++++------- > dlls/advapi32/tests/registry.c | 54 > ++++++++++++++++++++++++++++++++++++++++-- > 2 files changed, 61 insertions(+), 11 deletions(-) > > > > >

1 0

Re: [1/2] wineps.drv: Implement GetGlyphIndices.
by Dmitry Timoshkov 23 Jan '13

23 Jan '13

Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > ExtTextOutW calls GetTextExtentExPointI for the (char_extra || dc->breakExtra) > case, and one of its helpers unconditionally calls dc->GetGlyphIndices and > dc->GetTextExtentExPointI which crashes for a wineps.drv device. > > These 2 patches make ExtTextOutW work in this case. What is the reason that these patches are marked as pending? -- Dmitry.

2 5

Re: include: flesh out d3d11.idl (try 4)
by Dmitry Timoshkov 23 Jan '13

23 Jan '13

Austin English <austinenglish(a)gmail.com> wrote: > try 4: only include enough to add a stub for D3D11CreateDevice, You could also try to make it work for compilers that don't suppport anonymous unions. -- Dmitry.

1 0

Re: macdrv: implement getting and setting the screen saver state, version 6
by Ken Thomases 22 Jan '13

22 Jan '13

On Jan 22, 2013, at 5:33 PM, C.W. Betts wrote: > Yet another fix. Looks good to me. Thanks for doing this and for putting up with me. Cheers, Ken

1 0

macdrv: implement getting and setting the screen saver state. if(Style)
by Joerg-Cyril.Hoehle＠t-systems.com 22 Jan '13

22 Jan '13

Hi, Ken Thomases wrote: >> + if(success != kIOReturnSuccess) >Another style nitpick: please put a space between "if" and the condition. > That applies to the "if(count2)" above, too. I find this over the top. Where is the rule? Andrew Eikum's mmdevapi code -- which I don't consider very old in Wine -- uses exactly 0 space between if and (). So what is it that the Wine "project" can tell new contributors? The only rule I see is: "Look at the code surrounding the patch" and its corollary: "if you create a new module, you're the first and define the style others will have to follow." Regards, Jörg Höhle

3 2

Re: macdrv: implement getting and setting the screen saver state, version 5
by Ken Thomases 22 Jan '13

22 Jan '13

On Jan 22, 2013, at 12:22 PM, C.W. Betts wrote: > This version should fix the problems you mentioned Sorry about this – I should have thought about this last time – but I think you shouldn't fall through in the SPI_SETSCREENSAVEACTIVE case. It's asking for trouble in the future, if anybody adds another case to the switch statement. I think it would be better to just explicitly return FALSE and put in a comment explaining why (like you suggested for the X11 driver). Thanks for your persistence! -Ken

1 0

Re: usp10: add ShapeCharGlyphProp_Latin to properly handle invalid and zero width character properties for Latin
by Alexandre Julliard 22 Jan '13

22 Jan '13

Aric Stewart <aric(a)codeweavers.com> writes: > --- > dlls/usp10/shape.c | 33 +++++++++++++++++++++++++++------ > 1 files changed, 27 insertions(+), 6 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M usp10.dll -T ../../.. -p usp10_test.exe.so usp10.c && touch usp10.ok usp10.c:1407: Test failed: uJustification incorrect usp10.c:1410: Test failed: uJustification incorrect usp10.c:1411: Test failed: fClusterStart incorrect usp10.c:1414: Test failed: fClusterStart incorrect usp10.c:1190: Test failed: 0: uJustification incorrect (0) usp10.c:1190: Test failed: 0: fClusterStart incorrect (0) usp10.c:1190: Test failed: 3: uJustification incorrect (0) usp10.c:1190: Test failed: 3: fClusterStart incorrect (0) make[1]: *** [usp10.ok] Error 8 -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: dbghelp: Implement rudimentary stack walk for ARM64
by Eric Pouech 22 Jan '13

22 Jan '13

> + if ((frame->AddrPC.Mode == AddrModeFlat) && > + (frame->AddrFrame.Mode != AddrModeFlat)) this looks strange to me. I guess, you want to check that both mode address modes are AddrModeFlat A+ -- Eric Pouech

2 3

RFC: Remove auto-scan of ALSA devices from winealsa.drv (and get repeatable behaviour)
by Joerg-Cyril.Hoehle＠t-systems.com 22 Jan '13

22 Jan '13

Hi, please view the winmm:wave test results from Francois Gouget's machines fg-acer64-t32 fg-acer64-wow32 fg-acer64-t64 fg-acer64-wow64 http://test.winehq.org/data/dabde6a04f6d02233bc5074a8eba613b2c4adc68/index_… Is their configuration the same except for 32/64bit? We see 3 types of results 2x: 2 devices, no ALSA "default" device(!), one HDA-An, one HDA-HDMI 1x: 3 devices incl. ALSA "default", all tests successful 1x: 3 devices incl. ALSA "default", dev. 1 HDA-An yields MMSYSERR_ALLOCATED Is their configuration truly the same? Is that yet another aretefact of ALSA device enumeration? It could well be. Again, I argue in favor of removing the enumeration code. I want users to get repeatable results. I don't want Wine's winmm to map device 0 as ALSA "default" on one run and "HDMI-An" on another run. Andrew Eikum was in favour of this too and since implemented winmm device notification upon change. Remember the December thread: http://www.winehq.org/pipermail/wine-devel/2012-December/098114.html Of course, the winecfg/GUI issue need be addressed. Regards, Jörg Höhle

4 7

Re: [PATCH 6/8] winhttp: Added schannel-based netconn_get_cipher_strength implementation
by Hans Leidekker 22 Jan '13

22 Jan '13

On Tue, 2013-01-22 at 16:49 +0100, Jacek Caban wrote: > @@ -1460,6 +1460,13 @@ int netconn_get_cipher_strength( netconn_t *conn ) > pSSL_CIPHER_get_bits( cipher, &bits ); > return bits; > #else > - return 0; > + SecPkgContext_ConnectionInfo conn_info; > + SECURITY_STATUS res; > + > + if (!conn->secure) return 0; > + res = QueryContextAttributesW(&conn->ssl_ctx, SECPKG_ATTR_REMOTE_CERT_CONTEXT, (void*)&conn_info); That should be SECPKG_ATTR_CONNECTION_INFO.

2 1

winmm/tests: Allow more margin in the test_asyncWAVE() playback check.
by Joerg-Cyril.Hoehle＠t-systems.com 22 Jan '13

22 Jan '13

Francois, thank you for helping remove timing-caused flakiness from the tests. I believe you forgot to test your patch in Wine(!). The test + ok(400 <= p2 && p2 <= 600, "%ums is not in the expected 400-600ms range\n", p2); should fail in every version of Wine. Ironically, the reason is mentioned in your patch: /* Give Wine's asynchronous thread time to start up. Furthermore, * it uses 3 buffers per second, so that the positions reported * will be 333ms, 667ms etc. at best. */ IIRC, the first non-null position reported by Wine is 667ms, because it successfully queues two 333ms buffers to waveOut. I suggest adding a todo_wine plus an additional ok(0<p2 && strcmp(buf,"2000")) that Wine won't fail. And I'd decrease the sleep to e.g. 200 and 100 <= p2 && p2 <= 300 All those times sum up, the winmm test run long enough already. MCIWave should use winmm:waveOutGetPosition while playing, however the MCI devices hardly have any decent thread-safety and the construct if(status == MODE_PLAYING) waveOutGetPosition(hWave, &pos) else pos = stopped_pos; is unsafe, as the player may have exited meanwhile and closed hWave. It's a compatibility bug since day one of mciwave in git history that the position increments 3 times per second only. Yet so far, no app seems to have been bothered. Regards, Jörg Höhle

2 2

Re: macdrv: implement getting and setting the screen saver state. if(Style)
by Christian Costa 22 Jan '13

22 Jan '13

Well, 'grep "if(" * -r | wc -l' and 'grep "if (" * -r | wc -l'. :) 2013/1/22 Bruno Jesus <00cpxxx(a)gmail.com>: > Out of curiosity can you explain the shell wizardry you used to get the > stats? > > Thanks, > Bruno > > > On Tue, Jan 22, 2013 at 10:52 AM, Christian Costa <titan.costa(a)gmail.com> > wrote: >> >> 2013/1/22 <Joerg-Cyril.Hoehle(a)t-systems.com>: >> > Hi, >> > >> > Ken Thomases wrote: >> >>> + if(success != kIOReturnSuccess) >> >>Another style nitpick: please put a space between "if" and the >> >> condition. >> >> That applies to the "if(count2)" above, too. >> > >> > I find this over the top. Where is the rule? >> > Andrew Eikum's mmdevapi code -- which I don't consider very old in Wine >> > -- >> > uses exactly 0 space between if and (). >> > >> > So what is it that the Wine "project" can tell new contributors? >> > >> > The only rule I see is: "Look at the code surrounding the patch" and >> > its corollary: "if you create a new module, you're the first and define >> > the style others will have to follow." >> > >> >> Hi, >> >> Just some stats regard "if" before Dan beat me at it ;) : >> - without space => 39979 >> - with space => 144133 >> >> The space is better to make the distinction between C keyword and >> function name. Off course it's a personal taste. :) >> >> Bye, >> Christian >> >> > > > > -- > universe* god::bigbang (void); //and then it all began...

1 0

Re: user32/tests: Test standard scrollbar's initialization (try 2).
by Dmitry Timoshkov 22 Jan '13

22 Jan '13

Sergey Guralnik <serhio(a)etersoft.ru> wrote: > Subject: user32/tests: Test standard scrollbar's initialization (try 2). If it matters the test looks good to me. -- Dmitry.

1 0

Re: [PATCH] windowscodecs: Add support for DIB format.
by Dmitry Timoshkov 22 Jan '13

22 Jan '13

Christian Costa <titan.costa(a)gmail.com> wrote: > cpp_quote("DEFINE_GUID(CLSID_WICBmpDecoder, 0x6b462062,0x7cbf,0x400d,0x9f,0xdb,0x81,0x3d,0xd1,0x0f,0x27,0x78);") > +cpp_quote("DEFINE_GUID(CLSID_WICDibDecoder, 0x6b462062,0x7cbf,0x400d,0x9f,0xdb,0x81,0x3d,0xd1,0x0f,0x27,0x79);") > cpp_quote("DEFINE_GUID(CLSID_WICPngDecoder, 0x389ea17b,0x5078,0x4cde,0xb6,0xef,0x25,0xc1,0x51,0x75,0xc7,0x51);") > cpp_quote("DEFINE_GUID(CLSID_WICIcoDecoder, 0xc61bfcdf,0x2e0f,0x4aad,0xa8,0xd7,0xe0,0x6b,0xaf,0xeb,0xcd,0xfe);") > cpp_quote("DEFINE_GUID(CLSID_WICJpegDecoder, 0x9456a480,0xe88b,0x43ea,0x9e,0x73,0x0b,0x2d,0x9b,0x71,0xb1,0xca);") > @@ -1002,6 +1003,7 @@ cpp_quote("DEFINE_GUID(CLSID_WICWmpEncoder, 0xac4ce3cb,0xe1c1,0x44cd,0x82,0x15,0 > cpp_quote("DEFINE_GUID(CLSID_WICDefaultFormatConverter, 0x1a3f11dc,0xb514,0x4b17,0x8c,0x5f,0x21,0x54,0x51,0x38,0x52,0xf1);") > > cpp_quote("DEFINE_GUID(GUID_ContainerFormatBmp, 0x0af1d87e,0xfcfe,0x4188,0xbd,0xeb,0xa7,0x90,0x64,0x71,0xcb,0xe3);") > +cpp_quote("DEFINE_GUID(GUID_ContainerFormatDib, 0x0af1d87e,0xfcfe,0x4188,0xbd,0xeb,0xa7,0x90,0x64,0x71,0xcb,0xe4);") Is this mocked up names? I couldn't find WIC DIB decoder definitions in the PSDK headers. -- Dmitry.

3 10

Re: macdrv: implement getting and setting the screen saver state, version 4
by Ken Thomases 22 Jan '13

22 Jan '13

Hi, On Jan 21, 2013, at 6:21 PM, C.W. Betts wrote: > This version falls through in SPI_SETSCREENSAVEACTIVE. Sadly, you used C++ style for the fall-through comment. :-/ Also, you have some trailing whitespace and the patch no longer applies cleanly after today's commits of mine. It should be easy to fix that though. There aren't any serious conflicts. -Ken

1 0

Adding DECLSPEC_ALIGN(4) to structs for atomic DWORD access
by Joerg-Cyril.Hoehle＠t-systems.com 22 Jan '13

22 Jan '13

Hi, there are some places in Wine where I believe atomic access to 32bit entities is expected by the programmer, yet I see little or no measures to ensure this. DWORD-Alignment is essential when several threads can access the same DWORD variable outside of a mutex (or within the implementation of the mutex). DECLSPEC_ALIGN(4) is the declaration that could be used to enforce it within a struct, assuming the struct itself is somehow aligned. E.g. shouldn't CRITICAL_SECTION objects be aligned when used within other (non-public) structs? (Presumably public MS structs cannot be augmented with alignment declarations) DECLSPEC_ALIGN is hardly used in Wine http://source.winehq.org/ident?i=RTL_CRITICAL_SECTION Other examples where I'm considering adding DWORD-alignment to read DWORD-sized objects atomically: - MCI position values (for MCI_STATUS_POSITION) - MIDI end_thread control variable - mmdevapi GetCurrentPadding (as part of lock-less patch) Would such patches be welcome? Are they superfluous, assuming that DWORD-alignment is granted and using DECLSPEC_ALIGN() only for larger alignments, e.g. 8 or 16 (that seems to be the current use)? One benefit I see is to highlight those variables shared among several threads. Regards, Jörg Höhle

3 2

Re: x11drv: Return true when handling SPI_SETSCREENSAVEACTIVE
by Alexandre Julliard 22 Jan '13

22 Jan '13

"C.W. Betts" <computers57(a)hotmail.com> writes: > I noticed in my research that the X11 driver doesn't return true in > SystemParametersInfo when handling SPI_SETSCREENSAVEACTIVE. This patch > fixes this. That's on purpose, it also needs to update the registry entry. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: macdrv: implement getting and setting the screen saver state, version 3
by Ken Thomases 21 Jan '13

21 Jan '13

On Jan 21, 2013, at 11:50 AM, C.W. Betts wrote: > This version gets rid of redundant comments. According to Alexandre's comment on your X11 driver patch, you should be returning FALSE from the "SET" case so that user32 will update the registry. Otherwise, looking good. -Ken

1 0

Re: [PATCH] winebuild: Use Clang to assemble if found.
by Alexandre Julliard 21 Jan '13

21 Jan '13

Charles Davis <cdavis5x(a)gmail.com> writes: > @@ -319,26 +341,27 @@ char *find_tool( const char *name, const char * const *names ) > names = alt_names; > } > > - while (*names) > + /* If we have a target triple, we really need to try the list of names > + * twice: once with the triple, and once without. > + */ This doesn't make sense, if we have a target it means we are cross-compiling, and we need to use the correct tool. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: macdrv: implement getting and setting the screen saver state, version 2
by Ken Thomases 21 Jan '13

21 Jan '13

Hi, On Jan 20, 2013, at 2:00 PM, C.W. Betts wrote: > This version implements changes and advice from Ken Thomases, including using kIOPMAssertionTypePreventUserIdleDisplaySleep on Lion and later. Also, some comments were added. > + //Get pre-Lion no display sleep counts C++-style comments ("//") are not allowed in Wine C code. They aren't portable. > + CFNumberRef count = CFDictionaryGetValue(assertionStates, kIOPMAssertionTypeNoDisplaySleep); > + CFNumberRef count2 = NULL; > + long longCount = 0; > + long longCount2 = 0; > + CFNumberGetValue(count, kCFNumberLongType, &longCount); > + //If available, get Lion and later no display sleep counts > + count2 = CFDictionaryGetValue(assertionStates, kIOPMAssertionTypePreventUserIdleDisplaySleep); > + if (count2) > + CFNumberGetValue(count2, kCFNumberLongType, &longCount2); The issue discussed for the previous patch is still present. For example, the following code would be internally consistent and also safe: CFNumberRef count = CFDictionaryGetValue(assertionStates, kIOPMAssertionTypeNoDisplaySleep); CFNumberRef count2 = CFDictionaryGetValue(assertionStates, kIOPMAssertionTypePreventUserIdleDisplaySleep); long longCount = 0; long longCount2 = 0; if (count) CFNumberGetValue(count, kCFNumberLongType, &longCount); if (count2) CFNumberGetValue(count2, kCFNumberLongType, &longCount2); (Note that this reorganization also eliminates a dead store. You were initializing count2 and then unconditionally assigning it, making the initialization redundant. Such unnecessary initializations also defeat potentially valuable compiler warnings.) > + if (longCount || longCount2 ) There's an extraneous space before the closing parenthesis. > + //Release power assertion > + IOReturn success = IOPMAssertionRelease(powerAssertion); The comment is useless. It tells us nothing that the code doesn't. Please don't do that. In fact, most of the comments you added are like this. > + //Are we running Lion or later? > + if (kCFCoreFoundationVersionNumber >= kCFCoreFoundationVersionNumber10_7) > + //If so, use Lion's name > + assertName = kIOPMAssertionTypePreventUserIdleDisplaySleep; > + else > + //If not, use old name > + assertName = kIOPMAssertionTypeNoDisplaySleep; I'm not sure it's correct that these are two different names for roughly the same thing. I think the two assertion types do slightly different things. "NoDisplaySleep" seeks to prevent display sleep for any (non-forced) reason. "PreventUserIdleDisplaySleep" only seeks to prevent display sleep that is due to user idleness. As I suggested previously, I do want us to use PreventUserIdleDisplaySleep when it's available, so that's good. (Thank you for making that change.) What I'm saying now is mostly just that the comments are misleading. I suggest just removing the comments within the "if". The code is understandable without them. Also, this bit of code uses tabs to indent when none of the rest does. Please be consistent with the surrounding code. Thanks, Ken

2 2

Re: configure.ac: check for a good enough version of libv4l1.h (try 2)
by Alexandre Julliard 21 Jan '13

21 Jan '13

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > @@ -676,6 +676,22 @@ AC_CHECK_HEADERS([linux/videodev.h linux/videodev2.h libv4l1.h],,, > #include <asm/types.h> > #endif]) > > +dnl **** Check for libv4l1.h **** > +if test "x$with_v4l" != "xno" > +then > + ac_save_CPPFLAGS="$CPPFLAGS" > + if test "$PKG_CONFIG" != "false" > + then > + ac_libv4l1_libs="`$PKG_CONFIG --libs libv4l1 2>/dev/null`" > + ac_libv4l1_cflags="`$PKG_CONFIG --cflags libv4l1 2>/dev/null`" > + CPPFLAGS="$CPPFLAGS $ac_libv4l1_cflags" > + AC_CHECK_TYPES([struct video_picture],,,[#include <libv4l1.h>]) > + fi > + CPPFLAGS="$ac_save_CPPFLAGS" > + WINE_NOTICE_WITH(libv4l1,[test "x$ac_cv_type_struct_video_picture" = "x"], > + [libv4l1 ${notice_platform}development files not found or too old.]) > +fi It doesn't make sense to use pkg-config for the test since we don't use it when including the header. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/2] netstat: Implement the TCP stats output
by Frédéric Delanoy 21 Jan '13

21 Jan '13

On Sun, Jan 20, 2013 at 8:09 PM, André Hentschel <nerv(a)dawncrow.de> wrote: > --- > + IDS_TCP_SEGM_RECV, "Segments Recieved" Typo here: should be "Received" (same issue on the 2nd patch) Frédéric

1 0

Re: macdrv: implement getting and setting the screen saver state.
by Ken Thomases 21 Jan '13

21 Jan '13

Hi, On Jan 19, 2013, at 4:08 PM, C.W. Betts wrote: > This implements getting and setting the screen saver state on the Mac Wine driver. Thanks for your contribution to the Mac driver. There are some issues with the patch: > + CFDictionaryRef assertsionStats = NULL; That variable name has a misspelling. It should probably be "assertionStates". > + CFNumberRef count = CFDictionaryGetValue(assertsionStats, kIOPMAssertionTypeNoDisplaySleep); > + CFNumberRef count2 = NULL; > + long longCount = 0; > + long longCount2 = 0; > + CFNumberGetValue(count, kCFNumberLongType, &longCount); > + count2 = CFDictionaryGetValue(assertsionStats, kIOPMAssertionTypePreventUserIdleDisplaySleep); > + if(count2) > + CFNumberGetValue(count2, kCFNumberLongType, &longCount2); Why are the two assertion types handled differently here? You get the value in the initializer in one case but not in the other. You check if the CFNumber pointer is NULL in one case but not the other. They should probably both be handled the same way. Some better variable names would be nice, too. > + if (longCount + longCount2 > 0) If think it's better to use "if (longCount || longCount2)". We're really interested in whether or not either is non-zero. If, somehow, the sum overflows or one is a large negative value, we still want to consider that as the screen saver being disabled. > + { > + *(BOOL *)ptr_param = FALSE; > + } It's a minor style preference, but I prefer that single-statement bodies for "if"s not have braces. > + if(success != kIOReturnSuccess) Another style nitpick: please put a space between "if" and the condition. That applies to the "if(count2)" above, too. > + /* > + Introduced in 10.6, not available in 10.5 > + IOReturn success = IOPMAssertionCreateWithName( > + kIOPMAssertionTypeNoDisplaySleep, kIOPMAssertionLevelOn, > + CFSTR("Wine Process requesting no screen saver"), &powerAssertion); > + */ To Alexandre's chagrin, the Mac driver requires 10.6. So, you might as well use the newer function. > + IOReturn success = IOPMAssertionCreate(kIOPMAssertionTypeNoDisplaySleep, > + kIOPMAssertionLevelOn, &powerAssertion); We should use kIOPMAssertionTypePreventUserIdleDisplaySleep instead on OS versions where it's available. We could either check a framework version variable (e.g. kCFCoreFoundationVersionNumber) or check if the dictionary returned from IOPMCopyAssertionsStatus() contains kIOPMAssertionTypePreventUserIdleDisplaySleep as a key. > + break; This seems extraneous. Cheers, Ken

2 2

wiki
by Rico Schüller 20 Jan '13

20 Jan '13

Hi, is anyone able to get the wiki up again? Somehow the wiki (http://wiki.winehq.org/) is not reachable from here. Cheers Rico

4 3

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