Re: kernel/tests: Test behaviour of TPIDRURW register with threads on ARMv7
André Hentschel wrote:
> +#if defined(__ARM_ARCH_7__) || defined(__ARM_ARCH_7A__) ||
> defined(__ARM_ARCH_7R__)
> +static inline void set_tpidrurw(DWORD tpidrurw)
> +{
> +__asm__ volatile ("mcr p15, 0, %0, c13, c0, 2" : : "r" (tpidrurw));
> +}
> +
> +static inline DWORD get_tpidrurw(void)
> +{
> +DWORD tpidrurw = 0;
> +__asm__ volatile ("mrc p15, 0, %0, c13, c0, 2" : "=r" (tpidrurw));
> +return tpidrurw;
> +}
This code is gcc specific and for instance won't compile with PSDK compiler.
It either needs to be protected or replaced with hex/binary form.
--
Dmitry.
Re: RFC: Three dots or Unicode ellipsis character
Francois Gouget wrote: > So should we go with the flow and switch to using ellipsis characters or > should we stick with three dots? 3 dots should be used in order to keep compatibility with bitmap fonts, fonts that don't have the ellipsis glyph and ansi APIs (GetMenuItemInfoA/GetWindowTextA). -- Dmitry.
Re: msxml3/tests: Add additional conformance tests to the xpath tests (try 2)
John Chadwick writes: > This patch adds additional xpath tests to the msxml3 tests. Following > Nikolay Sivov's advice, these provide a wide range of new tests, two > of which currently fail in Wine (for reasons previously described.) > These are now marked 'todo' in a much cleaner way. It doesn't work here: ../../../tools/runtest -q -P wine -M msxml3.dll -T ../../.. -p msxml3_test.exe.so domdoc.c && touch domdoc.ok domdoc.c:4468: Test succeeded inside todo block: query=ancestor-or-self::node(), invalid node list: D1 E2.D1, expected D1 E2.D1 domdoc.c:4468: Test succeeded inside todo block: query=(//a[1])[last()], invalid node list: E1.E4.E2.D1, expected E1.E4.E2.D1 make: *** [domdoc.ok] Error 2 -- Alexandre Julliard julli...@winehq.org
Fwd: Re: RFC: Three dots or Unicode ellipsis character
Original Message Subject: Re: RFC: Three dots or Unicode ellipsis character Date: Wed, 03 Jul 2013 19:32:15 +0200 From: Michael Stefaniuc To: Francois Gouget On 07/03/2013 04:45 PM, Francois Gouget wrote: > > Wine uses three dots (...) rather than the Unicode ellipsis character > (…) except in the Czech and Taiwanese translations that use the Unicode > ellipsis character. > > I think we should be consistent but the question is which to use. > > > I looked at the Windows interface guidelines and they don't have > anything to say on this. > > http://msdn.microsoft.com/en-us/library/windows/desktop/aa974176.aspx#punctuation > http://msdn.microsoft.com/en-us/library/windows/desktop/aa511453.aspx#ellipses > > Looking at what other platforms do, the Apple interface guidelines > recommend using the Unicode ellipsis character saying assistive > technologies need it. The GNOME and KDE guidelines don't have an > official position but seem to use the Unicode character anyway: > > http://simos.info/blog/archives/17 > > > So should we go with the flow and switch to using ellipsis characters or > should we stick with three dots? How will the substitution work in the W2A case? bye michael
Windows RT Applications finally can run in Wine/ARM with upcoming Linux releases
Hi, Wanted to let you know that the patch that allows that just got committed in Linus tree: [1] This means that Kernel 3.11 will have everything to run applications ported to Windows RT. A good list of such applications and libraries can be found at [2]. See [3] & [4] for more information on the Wine side. [1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a4780adeefd042482f624f5e0d577bf9cdcbb760 [2] http://forum.xda-developers.com/showthread.php?p=36534446 [3] http://bugs.winehq.org/show_bug.cgi?id=31322 [4] http://bugs.winehq.org/show_bug.cgi?id=31308
Re: RFC: Three dots or Unicode ellipsis character
On Wed, 3 Jul 2013 16:45:24 +0200 (CEST), Francois Gouget wrote: > So should we go with the flow and switch to using ellipsis characters or > should we stick with three dots? In most Japanese fonts, ellipsis character (U+2026) is designed like midline horizontal ellipsis (U+22EF). For instance, please look at 0x8163 in codepage 932 chart [1]. [1] http://msdn.microsoft.com/en-us/goglobal/gg638593 If we use ellipsis character (U+2026), Japanese user gets different impression from the character. Therefore, I prefer "three dots" style. The reason of this behaviour is Japanese Industrial Standard, JIS X 0208. JIS X 0208 defines 3-dot leader character. As its example glyph is three middle dots, most font vendors designed the glyph like that. In Unicode conversion, the character is mapped into U+2026. Thus, its glyph is not like ellipsis. Regards, Akihiro Sagawa
Re: po: Revert Japanese shell path name updates.
On Wed, 03 Jul 2013 16:23:11 +0200, Alexandre Julliard wrote: > Akihiro Sagawa writes: > > As I mention in the last mail[2], patch 91758[3] has some issues, > > especially when retrieving shell path names. Although path names are not > > localized in Japanese Windows Vista (and its successors), they are > > (mistakenly?) included in the last commit. > > Then they should be explicitly "translated" to the same English string > instead of an empty string, this way it doesn't look like the > translation is missing. I got it. I'll resubmit the patch. Actually, it was removed by 4c4e51700932e9ed6355afc1bf8ca0d18282634f. I misunderstood the intention of the commit at that time. Regards, Akihiro Sagawa
RFC: Three dots or Unicode ellipsis character
Wine uses three dots (...) rather than the Unicode ellipsis character (…) except in the Czech and Taiwanese translations that use the Unicode ellipsis character. I think we should be consistent but the question is which to use. I looked at the Windows interface guidelines and they don't have anything to say on this. http://msdn.microsoft.com/en-us/library/windows/desktop/aa974176.aspx#punctuation http://msdn.microsoft.com/en-us/library/windows/desktop/aa511453.aspx#ellipses Looking at what other platforms do, the Apple interface guidelines recommend using the Unicode ellipsis character saying assistive technologies need it. The GNOME and KDE guidelines don't have an official position but seem to use the Unicode character anyway: http://simos.info/blog/archives/17 So should we go with the flow and switch to using ellipsis characters or should we stick with three dots? -- Francois Gouget http://fgouget.free.fr/ 145 = 1! + 4! + 5!
Re: po: Revert Japanese shell path name updates.
Akihiro Sagawa writes: > Could you revert recent Japanese translation updates[1] or commit > attached patch? > As I mention in the last mail[2], patch 91758[3] has some issues, > especially when retrieving shell path names. Although path names are not > localized in Japanese Windows Vista (and its successors), they are > (mistakenly?) included in the last commit. Then they should be explicitly "translated" to the same English string instead of an empty string, this way it doesn't look like the translation is missing. -- Alexandre Julliard julli...@winehq.org
Re: gdiplus: Added support for UTF16 encoded strings in load_ttf_name_id
On 07/03/13 13:34, Alexandre Julliard wrote: Piotr Caban writes: This patch fixes bug 33880. It's reported as regression but I think that it stopped working because of game update. I would guess that it's because gdi32 is properly loading localized names now. Gdiplus should most likely replicate that method. I'll try to duplicate the code inside gdiplus. Thanks, Piotr
po: Revert Japanese shell path name updates.
Could you revert recent Japanese translation updates[1] or commit attached patch? As I mention in the last mail[2], patch 91758[3] has some issues, especially when retrieving shell path names. Although path names are not localized in Japanese Windows Vista (and its successors), they are (mistakenly?) included in the last commit. To prove this, I submitted a job to winetestbot [4]. However, new winetestbot seems to be stuck. Alternatively, I attach my Japanese Windows 7 result. The line which begins shellpath.c:443 is my additional output. You can see that all path names are not translated. [1] http://source.winehq.org/git/wine.git/commit/0fb9de61a5026ac6cf16bc3385c3828850a4c831 [2] http://www.winehq.org/pipermail/wine-devel/2013-June/100377.html [3] http://source.winehq.org/patches/data/97158 [4] https://newtestbot.winehq.org/JobDetails.pl?Key=1432 --- po/ja.po | 63 +++--- 1 file changed, 31 insertions(+), 32 deletions(-) diff --git a/po/ja.po b/po/ja.po index 1373b97..82975e6 100644 --- a/po/ja.po +++ b/po/ja.po @@ -5,15 +5,14 @@ msgstr "" "Project-Id-Version: Wine\n" "Report-Msgid-Bugs-To: http://bugs.winehq.org\n"; "POT-Creation-Date: N/A\n" -"PO-Revision-Date: 2013-07-02 23:19+0900\n" -"Last-Translator: Akira Nakagawa \n" +"PO-Revision-Date: 2013-07-03 19:21+0900\n" +"Last-Translator: Akihiro Sagawa \n" "Language-Team: æ¥æ¬èª <>\n" "Language: Japanese\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=1; plural=0;\n" -"X-Generator: Poedit 1.5.4\n" #: appwiz.rc:55 msgid "Install/Uninstall" @@ -7912,48 +7911,48 @@ msgstr "ããã°ã©ã " #: shell32.rc:201 msgid "My Documents" -msgstr "ãã¤ããã¥ã¡ã³ã" +msgstr "" #: shell32.rc:202 msgid "Favorites" -msgstr "ãæ°ã«å ¥ã" +msgstr "" #: shell32.rc:203 msgid "StartUp" -msgstr "ã¹ã¿ã¼ãã¢ãã" +msgstr "" #: shell32.rc:204 msgid "Start Menu" -msgstr "ã¹ã¿ã¼ãã¡ãã¥ã¼" +msgstr "" #: shell32.rc:205 msgid "My Music" -msgstr "ãã¤ãã¥ã¼ã¸ãã¯" +msgstr "" #: shell32.rc:206 msgid "My Videos" -msgstr "ãã¤ãããª" +msgstr "" #: shell32.rc:207 msgctxt "directory" msgid "Desktop" -msgstr "ãã¹ã¯ããã" +msgstr "" #: shell32.rc:208 msgid "NetHood" -msgstr "ãããã¯ã¼ã¯å " +msgstr "" #: shell32.rc:209 msgid "Templates" -msgstr "ãã³ãã¬ã¼ã" +msgstr "" #: shell32.rc:210 msgid "PrintHood" -msgstr "ããªã³ã¿å " +msgstr "" #: shell32.rc:211 winhlp32.rc:45 msgid "History" -msgstr "ãã¹ããª" +msgstr "" #: shell32.rc:212 msgid "Program Files" @@ -7961,7 +7960,7 @@ msgstr "Program Files" #: shell32.rc:214 msgid "My Pictures" -msgstr "ãã¤ãã¯ãã£" +msgstr "" #: shell32.rc:215 msgid "Common Files" @@ -7969,23 +7968,23 @@ msgstr "Common Files" #: shell32.rc:216 shell32.rc:147 shell32.rc:232 msgid "Documents" -msgstr "ããã¥ã¡ã³ã" +msgstr "" #: shell32.rc:217 msgid "Administrative Tools" -msgstr "管çè ç¨ãã¼ã«" +msgstr "" #: shell32.rc:218 msgid "Music" -msgstr "ãã¥ã¼ã¸ãã¯" +msgstr "" #: shell32.rc:219 msgid "Pictures" -msgstr "ãã¯ãã£" +msgstr "" #: shell32.rc:220 msgid "Videos" -msgstr "ãããª" +msgstr "" #: shell32.rc:213 msgid "Program Files (x86)" @@ -7993,19 +7992,19 @@ msgstr "Program Files (x86)" #: shell32.rc:221 msgid "Contacts" -msgstr "é£çµ¡å " +msgstr "" #: shell32.rc:222 winefile.rc:110 msgid "Links" -msgstr "ãªã³ã¯" +msgstr "" #: shell32.rc:223 msgid "Slide Shows" -msgstr "ã¹ã©ã¤ãã·ã§ã¼" +msgstr "" #: shell32.rc:224 msgid "Playlists" -msgstr "ãã¬ã¤ãªã¹ã" +msgstr "" #: shell32.rc:148 taskmgr.rc:326 msgid "Status" @@ -8021,35 +8020,35 @@ msgstr "æ©ç¨®å" #: shell32.rc:225 msgid "Sample Music" -msgstr "ãµã³ãã«ãã¥ã¼ã¸ãã¯" +msgstr "" #: shell32.rc:226 msgid "Sample Pictures" -msgstr "ãµã³ãã«ãã¯ãã£" +msgstr "" #: shell32.rc:227 msgid "Sample Playlists" -msgstr "ãµã³ãã«ãã¬ã¤ãªã¹ã" +msgstr "" #: shell32.rc:228 msgid "Sample Videos" -msgstr "ãµã³ãã«ãããª" +msgstr "" #: shell32.rc:229 msgid "Saved Games" -msgstr "ä¿åæ¸ã¿ã®ã²ã¼ã " +msgstr "" #: shell32.rc:230 msgid "Searches" -msgstr "æ¤ç´¢" +msgstr "" #: shell32.rc:231 msgid "Users" -msgstr "ã¦ã¼ã¶ã¼" +msgstr "" #: shell32.rc:233 msgid "Downloads" -msgstr "ãã¦ã³ãã¼ã" +msgstr "" #: shell32.rc:166 msgid "Unable to create new Folder: Permission denied." shellpath.txt Description: Binary data
Re: gdiplus: Added support for UTF16 encoded strings in load_ttf_name_id
Piotr Caban writes: > This patch fixes bug 33880. It's reported as regression but I think > that it stopped working because of game update. I would guess that it's because gdi32 is properly loading localized names now. Gdiplus should most likely replicate that method. -- Alexandre Julliard julli...@winehq.org
Re: wininet/tests: Statically initialize and name the notification_cs critical section.
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=26207 Your paranoid android. === WINEBUILD (build) === Make failed
Re: [wbemprox] Patches for adding currentclockspeed in record_processor
On Tue, 2013-07-02 at 20:34 +0900, Rosen Diankov wrote:
> you are right again, i'll be more careful. now, i've addressed every
> problem except creating the patches with git. any help would be
> appreciated.
See http://wiki.winehq.org/GitWine
> --- wine-1.6-rc4-old/dlls/wbemprox/builtin.c2013-06-29 04:53:55.0
> +0900
> +++ wine-1.6-rc4/dlls/wbemprox/builtin.c2013-07-02 19:30:39.157916619
> +0900
> @@ -168,6 +168,8 @@
> {'M','a','n','u','f','a','c','t','u','r','e','r',0};
> static const WCHAR prop_maxclockspeedW[] =
> {'M','a','x','C','l','o','c','k','S','p','e','e','d',0};
> +static const WCHAR prop_currentclockspeedW[] =
> +{'C','u','r','r','e','n','t','C','l','o','c','k','S','p','e','e','d',0};
> static const WCHAR prop_memberW[] =
> {'M','e','m','b','e','r',0};
> static const WCHAR prop_methodW[] =
> @@ -381,6 +383,7 @@
> { prop_familyW, CIM_UINT16, VT_I4 },
> { prop_manufacturerW, CIM_STRING|COL_FLAG_DYNAMIC },
> { prop_maxclockspeedW,CIM_UINT32, VT_I4 },
> +{ prop_currentclockspeedW,CIM_UINT32, VT_I4 },
> { prop_nameW, CIM_STRING|COL_FLAG_DYNAMIC },
> { prop_numcoresW, CIM_UINT32, VT_I4 },
> { prop_numlogicalprocessorsW, CIM_UINT32, VT_I4 },
> @@ -633,6 +636,7 @@
> UINT16 family;
> const WCHAR *manufacturer;
> UINT32 maxclockspeed;
> +UINT32 currentclockspeed;
> const WCHAR *name;
> UINT32 num_cores;
> UINT32 num_logical_processors;
> @@ -1690,20 +1694,30 @@
> regs_to_str( regs, 16, name + 32 );
> }
> }
Please keep properties sorted alphabetically.
> -static UINT get_processor_maxclockspeed( void )
> +static void get_processor_clockspeeds( UINT* maxclockspeed, UINT*
> currentclockspeed )
> {
> PROCESSOR_POWER_INFORMATION *info;
> -UINT ret = 1000, size = get_processor_count() *
> sizeof(PROCESSOR_POWER_INFORMATION);
> +UINT size = get_processor_count() * sizeof(PROCESSOR_POWER_INFORMATION);
> NTSTATUS status;
> -
> +UINT valueswritten=0;
> if ((info = heap_alloc( size )))
> {
> status = NtPowerInformation( ProcessorInformation, NULL, 0, info,
> size );
> -if (!status) ret = info[0].MaxMhz;
> +if (!status)
> +{
> +*maxclockspeed = info[0].MaxMhz;
> +*currentclockspeed = info[0].CurrentMhz;
> +valueswritten = 1;
> +}
> heap_free( info );
> }
> -return ret;
> +if( valueswritten == 0 )
> +{
> +*maxclockspeed = 1000;
> +*currentclockspeed = 1000;
> +}
> }
You don't need an extra variable, just return early.
