February 2013 - Wine-Devel - list.winehq.org

prelink --reloc-only versus ld -Ttext-segment

by Tijl Coosemans

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

Feb. 21, 2013

prelink --reloc-only versus ld -Ttext-segment

by Tijl Coosemans

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

Feb. 21, 2013

Re: webservices: Add new dll

by Hans Leidekker

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 :)

Feb. 21, 2013

Re: comctl32/listview: fix selection in ownerdata listview

by Nikolay Sivov

On 2/21/2013 11:01, Daniel Jelinski wrote: > Hello Nikolay, > I didn't have time to write and test a proper fix yet, and I'm not > sure when I will. I thought this hack may be better than what we have > now. Sure, I get it. The problem is that it's not a correct way to fix that. Such hack is ok to attach to a bug report to test with, but it shouldn't be committed. > If you want to fix this, please do. If not, I'll get back to it later. I do not plan to look at this right now. Anyway thanks for looking at this code and fixing other things. > Regards, > Daniel > > > 2013/2/21, Nikolay Sivov <nsivov(a)codeweavers.com>: >> 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.

Feb. 21, 2013

Re: comctl32/listview: fix selection in ownerdata listview

by Daniel Jelinski

Hello Nikolay, I didn't have time to write and test a proper fix yet, and I'm not sure when I will. I thought this hack may be better than what we have now. If you want to fix this, please do. If not, I'll get back to it later. Regards, Daniel 2013/2/21, Nikolay Sivov <nsivov(a)codeweavers.com>: > 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.

Feb. 21, 2013

Re: [0/13] Patch series description

by Saulius Krasuckas

* 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.

Feb. 21, 2013

Re: comctl32/listview: fix selection in ownerdata listview

by Nikolay Sivov

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.

Feb. 21, 2013

Re: Implement pinned memory for ATI where buffer regions are slow

by Stefan Dösinger

Am 20.02.2013 um 14:11 schrieb Stanislaw Halik <sthalik(a)misaki.pl>: > On 2013-02-17 15:40, Stefan Dösinger wrote: >>> Why is it included for every mapping in the first place, even for programs who never need it? >> The problem isn't that glMapBufferRange is used for maps, but that we create a VBO for dynamic buffers instead of drawing from system memory. > > Please see: > > http://bugs.winehq.org/show_bug.cgi?id=31644 It's not necessarily the same issue. There are other things that can go wrong with dynamic buffers, e.g. the game not using DISCARD or NOOVERWRITE properly.

Feb. 20, 2013

Re: Implement pinned memory for ATI where buffer regions are slow

by Stanislaw Halik

On 2013-02-17 15:40, Stefan Dösinger wrote: >> Why is it included for every mapping in the first place, even for programs who never need it? > The problem isn't that glMapBufferRange is used for maps, but that we create a VBO for dynamic buffers instead of drawing from system memory. Please see: http://bugs.winehq.org/show_bug.cgi?id=31644 NVIDIA has this problem too, and with other games.

Feb. 20, 2013

Re: Failing tests in the Japanese and Hebrew languages

by Akihiro Sagawa

On Mon, 18 Feb 2013 20:55:53 +0100 (CET), Francois Gouget wrote: > Do you know of a specific test that fails because the system locale is > currently set to English? I'm not sure about this, but it probably works fine except for progman_dde.c:377. Because few tests rely system locale or ANSI codepage as you observe. If I find another issue related locales, I'll send a patch or file a bug. Akihiro Sagawa

Feb. 20, 2013

Re: advapi32: Report administrator ownership by default for registry objects (try 3).

by Alexandre Julliard

"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

Feb. 19, 2013

Re: [14/14] gdiplus: Reimplement GdipDrawPath.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > > 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. Well, GdipWidenPath is actually good enough for the things I've tested so far, so it's basically working. What are the possible problems with it you are aware of? -- Dmitry.

Feb. 19, 2013

Re: [14/14] gdiplus: Reimplement GdipDrawPath.

by Vincent Povirk

> Well, GdipWidenPath is actually good enough for the things I've tested > so far, so it's basically working. What are the possible problems with > it you are aware of? It doesn't implement dashed lines and most line cap styles. I think it also mishandles pen->width == 0. It doesn't have to be perfect, but it should at least have the features we implement now.

Feb. 19, 2013

Re: [14/14] gdiplus: Reimplement GdipDrawPath.

by Vincent Povirk

> 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.

Feb. 19, 2013

Re: [PATCH 5/8] vbscript: Added RegExp.Execute tests

by Piotr Caban

On 02/19/13 12:47, Marvin wrote: > 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 > > Result of manual run: https://testbot.winehq.org/JobDetails.pl?Key=24457

Feb. 19, 2013

Re: [PATCH 7/8] vbscript: Added tests for invalid parameters in regular expression functions

by Piotr Caban

On 02/19/13 12:48, Marvin wrote: > 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 > Testbot failed to update wine. Here are the result of manual run: http://testbot.winehq.org/JobDetails.pl?Key=24449

Feb. 19, 2013

Re: [PATCH 7/8] vbscript: Added tests for invalid parameters in regular expression functions

by Marvin

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

Feb. 19, 2013

Re: [PATCH 5/8] vbscript: Added RegExp.Execute tests

by Marvin

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

Feb. 19, 2013

Re: [PATCH 5/8] vbscript: Added RegExp.Execute tests

by Marvin

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

Feb. 19, 2013

Re: IE 6 related urlmon:protocol failures

by Francois Gouget

On Mon, 18 Feb 2013, Jacek Caban wrote: [...] > > wininet:http has the exact same problem. > > http://wiki.winehq.org/WineTestBotVMs#wininet > > > It seems to me like those tests could be simply removed. The part that > is failing is just a preparation for tests reading from cache. I'm not particularly attached to these tests so you'll get no objection from me. Thanks for looking into this! -- Francois Gouget <fgouget(a)codeweavers.com>,

Feb. 18, 2013

Re: Failing tests in the Japanese and Hebrew languages

by Francois Gouget

On Mon, 18 Feb 2013, Akihiro Sagawa wrote: > Did you change ANSI codepage? As you may know, Japanese (codepage > 932) is not compatible with Windows 1252 except for 7-bit ASCII > characters. So you have to change codepage settings, Language for > Non-Unicode Programs, in the Control Panel. Not specifically no. My understanding is that Windows 7 has essentially three separate locales. In this case we see that the test ran with: http://test.winehq.org/data/c41f6add0563252a5809c3c83cbb6a6e6f81c2d9/win7_f… * SystemDefaultLCID = 409 This is the system locale and it is set to English. http://www.sisulizer.com/_img/codepage-problems/w7-region-and-language-admi… * UserDefaultLCID = 40c The user locale here is set to French and determines the date / time format, number format, currency, etc. http://www.sisulizer.com/_img/codepage-problems/w7-regions-and-languages-fo… * UserDefaultUILanguage = 411 And this is the 'Display Language' which determines which language will be used for the GUI. Here it is set to Japanese. http://www.sisulizer.com/_img/codepage-problems/w7-region-and-language-lang… It's important for Wine to know which setting each API is impacted by. That's why I normally try to use different locales and display languages. I must admit I did not particularly pay attention to the system locale setting so all my VMs have it just set to English. But I'd like to keep it set differently from the others. I'd further argue that it's up to Wine's conformance tests to skip tests that don't make sense in the current environment. For instance there are tests where compare a result against a known English string, so these tests are skipped if running in a non-English locale (and here checking the right locale out of the three is crucial). Do you know of a specific test that fails because the system locale is currently set to English? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ It really galls me that most of the computer power in the world is wasted on screen savers. Chris Caldwell from the GIMPS project http://www.mersenne.org/prime.htm

Feb. 18, 2013

Re: [PATCH 1/2] wininet: Address string should never be converted to UNICODE in status notifications

by Jacek Caban

On 02/18/13 15:50, Marvin wrote: > 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. That's because TestBot still can't update to current Wine version: http://testbot.winehq.org/JobDetails.pl?Key=24423 Jacek

Feb. 18, 2013

Re: [PATCH 1/2] wininet: Address string should never be converted to UNICODE in status notifications

by Marvin

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

Feb. 18, 2013

Re: IE 6 related urlmon:protocol failures

by Jacek Caban

On 02/18/13 12:49, Francois Gouget wrote: > On Sat, 16 Feb 2013, Jacek Caban wrote: > >> On 2/16/13 1:28 AM, Francois Gouget wrote: >>> 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. >> I believe it's time to skip those tests on IE6 then. I will send a patch. >> Thanks for the analyze. > wininet:http has the exact same problem. > http://wiki.winehq.org/WineTestBotVMs#wininet It seems to me like those tests could be simply removed. The part that is failing is just a preparation for tests reading from cache. And the important part of those tests always fail on Windows (the comment says that they fail on new Windows, but AFAICS on both testbots, they always fail). Those tests are also marked todo_wine. It would be great to make proper use of cache in our http implementation, but that will require writing more tests anyway. > /me trying to push my luck<g>. Don't hesitate to push more if needed :) Cheers, Jacek

Feb. 18, 2013

Re: Failing tests in the Japanese and Hebrew languages

by Akihiro Sagawa

Did you change ANSI codepage? As you may know, Japanese (codepage 932) is not compatible with Windows 1252 except for 7-bit ASCII characters. So you have to change codepage settings, Language for Non-Unicode Programs, in the Control Panel. Most of wine test try to run ANSI version of APIs. Language specific texts (e.g. error messages, startup folder name, day of week names, font face name) aren't represented properly in other codepages. On Sun, 17 Feb 2013 10:52:06 +0100 (CET), Francois Gouget wrote: > * 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); It seems that this size depends on window appearance. I changed font size of "Icon" in "Window Color and Appearance" window. The test was passed in "Tahoma 8", but failed in "Meiryo 9", Japanese default settings in Windows 7. The default settings were "Tahoma 8" in Windows XP era, thus the testbot doesn't complain about this. (skip Hebrew topic...) > * 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 > */ Yes, I verified DceErrorInqTextA returned language-specific message on native Windows. I guess this caused by ANSI conversion error. But it is curious why test on line 164 was succeeded. Anyway, these tests succeeded on my PC, Japanese Windows 7 (x64). > * 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++); Ditto. There is ANSI conversion error, too. I guess "?????" is localized startup folder name that didn't convert into Windows 1252 characters. This test also succeeded on my PC. Regards, Akihiro Sagawa

Feb. 18, 2013