- wine-devel - winehq.org

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

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