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

Re: shlwapi: Implemented StrToInt64ExA/W

by Jacek Caban

Hi Carlo, On 2/26/12 12:56 PM, carlo.bramix(a)libero.it wrote: > I improved the patch according to the suggestions that I received: > 1) Removed the C++ style comment > 2) Removed the WARN message > 3) Added the tests for the new functions. The test has been run successfully > on Ubuntu 11.10. > > Sincerely Thanks for fixing those. This version looks better, but still could use some improvements (mostly for failing tests on win2k). BOOL WINAPI StrToIntExA(LPCSTR lpszStr, DWORD dwFlags, LPINT lpiRet) { + LARGE_INTEGER li; + BOOL bRes; + + TRACE("(%s,%08X,%p)\n", debugstr_a(lpszStr), dwFlags, lpiRet); + + if (!lpiRet) + return FALSE; In previous patch you mentioned that Windows crashes in this situation. Thus there is no point in having this check on Wine. int str_to_int; int str_to_int_ex; int str_to_int_hex; + LONGLONG str_to_int64_ex; + LONGLONG str_to_int64_hex; AFAICS int str_to_int* always matches str_to_int64* values except for overflows. It means that you could simply change str_to_int_* to be LONGLONG and simply cast it to int before using it in existing tests. + { "0x44ff", 0, 0, 0x44ff, 0, 0x44ff }, + { "0x2bdc546291f4b1", 0, 0, 0x6291f4b1, 0, 0x2bdc546291f4b1 }, 64-bit literals are not portable. Something like ((ULONGLONG)0x2bdc54<<32) | (ULONGLONG)0x6291f4b1 would do the trick. + while (result->string) + { + return_val = -1; + bRet = StrToInt64ExA(result->string,0,&return_val); This function is not available on win2k (http://testbot.winehq.org/JobDetails.pl?Key=17105&scrshot_202=1#k202) so it needs to be loaded dynamically via GetProcAddress. See how other functions are handled. Cheers, Jacek

Feb. 26, 2012

Re: po: zh_TW translation updates

by Hin-Tak Leung

--- On Sun, 26/2/12, Francois Gouget <fgouget(a)free.fr> wrote: > +#, fuzzy > msgid "Connection unavailable.\n" > -msgstr "" > +msgstr "不可用; 。\n" meaning just 'useless/unavailable' - could be improved. > msgid "" > "This program is free software; you can redistribute it > and/or modify it " > "under the terms of the GNU Lesser General Public License as > published by the " > "Free Software Foundation; either version 2.1 of the > License, or (at your " > "option) any later version." > msgstr "" > "這個程式是自由軟體﹐您可以遵照\n" > "自由軟體基金會出版的 GNU LGPL 2.1\n" > "版或新版的許可條款來修改和重新\n" > "散佈這個程式。" "基金會" seems wrong. Are you sure that's FSF's chinese name? > msgid "Finished searching the document." > -msgstr "檔案搜尋結束。" > +msgstr "檔案查找結束." The older version is preferred. (may be it is just my opinion). > msgid "Failed to load the RichEdit library." > -msgstr "RichEdit 載入失敗。" > +msgstr "RichEdit 裝載失敗." ditto here. The older version is preferred. > msgid "Overwrite %1? (Yes|No|All)\n" > -msgstr "" > +msgstr "是否覆蓋 %1？ > （是｜否｜全部皆是）\n" This translation also looks dubious. BTW, where was the patch posted? I don't seem to have the very original patch submission (if it were posted to wine-devel).

Feb. 26, 2012

Re: po: fixed remaining Slovenian true positives in the winepo error report

by Jaka Kranjc

On Saturday 25 of February 2012 18:54:15 Francois Gouget wrote: > On Wed, 22 Feb 2012, Jaka Kranjc wrote: > [...] > > This brings up another can of worms though; capitalisation. We don't use > > title case at all, so these translation have the wrong case. Well, except > > for the first one being printed, but that is runtime knowledge, so we > > can't really fix it well. Gettext has no provisions for this (or gender > > or ...), so all that comes to mind is autocapitalisation depending on the > > locale, but that is probably ugly and I doubt it would work with more > > exotic scripts (but not sure if any would need it). > > I don't think we really care about capitalization in this specific case > (or that it can be handled right anyway). > > So would the attached patch work? Sure. > > Re usage strings: is there no 80 column limit imposed? I saw even some > > original strings were longer. > > If no line feed is hardcoded then the line will wrap at the 80th column. > The line feeds are only there to ensure words are not cut in the middle. > I suspect the authors of the command line tools did not care about that. > Or they did not want to hardcode line wrapping at 80 columns when the > terminal may be wider or narrower. And that issue was probably > overlooked in a number of cases too. So these are probably all > contributing factors to the current situation. This is the reason we have some extra newlines in usage strings. I saw you removed them as part of one of the patches today, but that's potentially a bad idea. They use a placeholder for the file name and you know how long they can get, especially if the dir name isn't stripped first. The extra newline saved a few characters to make it less likely to wrap. Probably it is best to reword the original string to not use the filename in the middle of a sentence and then put it into a separate line. LP -- To err is humor

Feb. 26, 2012

RE: msvcrt/file.c: file mode T (temporary file) (try 2)

by Robert van Herk

> > + case 'T': > > + FIXME("Implement T flag (temporary file, i.e. delete on close, don't flush to disk if possible)"); > > + break; > So what actually prevents you from properly implementing this? Especially > that Wine already supports temporary files. Search for MSVCRT__O_TEMPORARY My lack of knowledge of what was already implemented, I guess :-). Plus: I was already so happy that my Win32 application didn't crash any more :-). But OK, I try implementing it properly. Then I'll map as follows: 'T' -> MSVCRT__O_SHORT_LIVED 'D' -> MSVCRT__O_TEMPORARY I'll try to send a new version (try 3) tomorrow. By the way, 'R' also doesn't follow the MS spec: 'R' is supposed to mean "_O_RANDOM_" but the current Wine implementation maps it like 'r', which is "read". I find it scary to blindly change that, cause there may be some risky cases like "R+", etc. If I have time I'll try to investigate that too, but it'll have to go in a later patch... Regards, Robert

Feb. 26, 2012

Re: [PATCH] po: Update Swedish translation.

by Lauri Kenttä

Thanks, I'll do the corrections. I mostly trusted the previous translator and only changed the parts that were causing the "fuzzy" comments. On 2012-02-26 14:07, Jan-Peter Nilsson wrote: > I would assume 'Luminance' to be translated to 'Luminans', so Lum as > abbreviation makes sense to me. I translated it as 'Valör' (misled by the "V" in GIMP). GIMP actually uses 'Värde'. According to Wikipedia, HSV = NMI, where the I stands for 'Intensitet'. Which one would be best? What does Windows use? >> +msgstr "Verifiera blev %1\n" By the way, what do you think about translating "Verify" in the first place? It's some kind of flag, and it's left untranslated in many other languages. (See VERIFY command in cmd.exe.) > To me 'val' reads more like 'selection' than 'option'. You're probably right. Does 'flagga' sound any better? >> msgid "Wine File Manager" >> -msgstr "Winefile" >> +msgstr "Wine Filhanteraren" > > "Wine Filhanterare", unless we want definite form "The Wine File > Manager". Are you sure? I believe Windows used to have "Filhanteraren" and now has "Utforskaren". Also, Wine already has "Registereditorn". They're program names, so it makes sense to use the definite forms. -- Lauri Kenttä

Feb. 26, 2012

Spaces in the Korean translation.

by Francois Gouget

I noticed some leading and trailing space issues in the Korean translation. I think these are probably safe to change. However I then noticed that there was a lot of sentences mixed single and double spaces. So I wonder if that's normal, maybe tied to a Korean typography rule related to half vs. full width characters; or if only single or double spaces should be present. Here are a few examples: "주의: 이 파일 형식은 아마도 하나 이상의 인증서,인증서 파기 목록,인증서 신뢰 " ^^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ "목록을 가지고 있을 수 있음:" ^ ^ ^ ^ msgstr "'여기로부터'엔트리는 여기까지'엔트리에 도달 할 수 없습니다." ^^ ^ ^ ^ ^ msgstr "대기열에는 %d의 문서가 존재합니다" ^^ ^ ^ -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.

Feb. 26, 2012

Re: Wrong charcter encoding in winmm-tests

by Julian Rüger

OK, I think I finally found out what's going on here: in waveform.c waveOutGetErrorTextA() calls WideCharToMultiByte(CP_ACP,.... with the ANSI codepage. When I change that to CP_UTF8, it works as expected. Is this fix OK, or does that break anything? Should I send a patch? Thanks, Julian

Feb. 26, 2012

Re: msvcrt/file.c: file mode T (temporary file) (try 2)

by Vitaliy Margolen

On 02/25/2012 05:30 AM, Robert van Herk wrote: > Try 2 fixes some blatant memory bug in the conformance test > --------------------------------------------------------------------------- > > Windows fopen has some fancy file modes 'T' and 'D'. > Currently, wine wrongly interprets 'T' as 't'. They should be interpreted > differently though: 't' is text file, and 'T' is temporary file. > > I've fixed this, and added a conformance test. > + case 'T': > + FIXME("Implement T flag (temporary file, i.e. delete on close, don't flush to disk if possible)"); > + break; So what actually prevents you from properly implementing this? Especially that Wine already supports temporary files. Search for MSVCRT__O_TEMPORARY Vitaliy.

Feb. 26, 2012

Re: Wrong charcter encoding in winmm-tests

by Julian Rüger

> waveOutGetErrorTextA() if I am not mistaken. Forget that part please ;) So, the .po is UTF-8, the terminal is UTF-8 and my $LANG is de_DE.UTF-8, but somewhere it is converted to 8859-1...

Feb. 26, 2012

Re: sk.po

by Francois Gouget

Thanks for the translation updates. I noticed some potential issues while proofreading it: "to modify its installed components, select it from the list and click Change/" "Remove." msgstr "" +"Nasledujúci program môže byť automaticky odinštalovaný. K odstráneniu programu " +"alebo k modifukácii jeho inštalovaných súčastí, zvoľte možnosť zo zoznamu a kliknite " +"Zmeniť/Odstrániť" There should probably be a trailing full stop. msgid "Publisher:" -msgstr "" +msgstr "Vydavateľ" msgid "Version:" -msgstr "" +msgstr "Verzia" These are missing the trailing colon (these are likely field labels in a dialog). msgid "&Settings..." -msgstr "" +msgstr "&Nastavenia" #, fuzzy msgid "&Modify..." -msgstr "Modifikovaný" +msgstr "&Zmeniť" #, fuzzy msgid "&Install" -msgstr "&Skomentovať..." +msgstr "&Inštalovať..." These are either missing the trailing ellipsis or have one that should not be there. Ellipses are very important because, for instance, they make all the difference between a 'Print' button that will send the page to the default printer right away, and a 'Print...' button that will first display a dialog that will let you choose the destination printer or cancel before anything happens. Note that I did not list all ellipsis issues here. Also this is one of the points that my script checks so you'll see any ellipsis issue in Wine's PO file there: http://fgouget.free.fr/wine-po/sk-errors.html #, fuzzy msgid "Unexpected network error.\n" -msgstr "Nedefinovaná externá chyba." +msgstr "Nedefinovaná sieťová chyba." This translation should have a trailing linefeed. Also I notice that you did not remove the 'fuzzy' flag, not only here but also for quite a few other translations, including two others above. The fuzzy flag indicates that the translation is potentially incomplete or incorrect and thus requires more work or a review. So as long as it is present the translation will not be used. Keep up the good work. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Any sufficiently advanced bug is indistinguishable from a feature. -- from some indian guy

Feb. 26, 2012