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

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

Feb. 26, 2013

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 Feb. 26, 2013

Feb. 26, 2013

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 Feb. 25, 2013

Feb. 25, 2013

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 Feb. 25, 2013

Feb. 25, 2013

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 Feb. 25, 2013

Feb. 25, 2013

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 Feb. 25, 2013

Feb. 25, 2013

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 Feb. 25, 2013

Feb. 25, 2013

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 Feb. 24, 2013

Feb. 24, 2013

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 Feb. 24, 2013

Feb. 24, 2013

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 Feb. 23, 2013

Feb. 23, 2013

* 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 Feb. 22, 2013

Feb. 22, 2013

> 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 Feb. 22, 2013

Feb. 22, 2013

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 Feb. 22, 2013

Feb. 22, 2013

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 Feb. 22, 2013

Feb. 22, 2013

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 Feb. 22, 2013

Feb. 22, 2013

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 Feb. 22, 2013

Feb. 22, 2013

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 Feb. 22, 2013

Feb. 22, 2013

"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 Feb. 22, 2013

Feb. 22, 2013

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 Feb. 21, 2013

Feb. 21, 2013

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 Feb. 21, 2013

Feb. 21, 2013

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 Feb. 21, 2013

Feb. 21, 2013

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 Feb. 21, 2013

Feb. 21, 2013

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 Feb. 21, 2013

Feb. 21, 2013

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 Feb. 20, 2013

Feb. 20, 2013

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 Feb. 20, 2013

Feb. 20, 2013

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