June 2012 - Wine-devel - list.winehq.org

Re: [2/4] windowscodecs: Implement a better stub for MetadataHandler_GetCount.
by Vincent Povirk 07 Jun '12

07 Jun '12

It should be trivial to implement this correctly. On Wed, Jun 6, 2012 at 11:21 PM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > --- > dlls/windowscodecs/metadatahandler.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/dlls/windowscodecs/metadatahandler.c b/dlls/windowscodecs/metadatahandler.c > index 013fe04..0ea404b 100644 > --- a/dlls/windowscodecs/metadatahandler.c > +++ b/dlls/windowscodecs/metadatahandler.c > @@ -152,7 +152,8 @@ static HRESULT WINAPI MetadataHandler_GetCount(IWICMetadataWriter *iface, > if (!pcCount) return E_INVALIDARG; > > FIXME("(%p,%p): stub\n", iface, pcCount); > - return E_NOTIMPL; > + *pcCount = 0; > + return S_OK; > } > > static HRESULT WINAPI MetadataHandler_GetValueByIndex(IWICMetadataWriter *iface, > -- > 1.7.10.1 > > >

2 1

Re: [PATCH 1/7] urlmon: Use file content to verify MIME type reported by file protocol handler
by Jacek Caban 07 Jun '12

07 Jun '12

On 06/07/12 15:40, Jacek Caban wrote: > --- > dlls/urlmon/file.c | 8 +++++++- > dlls/urlmon/tests/protocol.c | 4 ++++ > 2 files changed, 11 insertions(+), 1 deletions(-) > Please skip this one. I didn't mean to send it in the series. Thanks, Jacek

1 0

Re: mscoree: Use .NET 2.0 for 1.0 assemblies
by Vincent Povirk 07 Jun '12

07 Jun '12

I was planning to do something like this eventually, as I was advised on #mono this was the way to go, but I didn't expect it to be that simple. +1. On Thu, Jun 7, 2012 at 4:27 AM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > Hi, > > Mono will use .NET 2.0 when a .NET 1.0/1.1 application is run. > > http://www.mono-project.com/Release_Notes_Mono_2.8 > Find: Removed .NET 1.1 Profile > > > Changelog: > mscoree: Use .NET 2.0 for 1.0 assemblies > > > Best Regards > Alistair Leslie-Hughes > > >

1 0

Re: po: Update Russian translation (try 2)
by Nikolay Sivov 07 Jun '12

07 Jun '12

On 6/5/2012 11:16, Архад wrote: Please, configure your mail client to use your real name in sent mails. > > #: appwiz.rc:28 > msgid "Add/Remove Programs" > -msgstr "Установка/удаление программ" > +msgstr "Установка/Удаление программ" Looks better as it is. Only start letter of a sentence supposed to be capital, if it's not a part of some name of course, which is not in this case. > > > #: appwiz.rc:35 shell32.rc:141 shell32.rc:238 regedit.rc:122 winefile.rc:104 > msgid "Name" > -msgstr "Имя" > +msgstr "Название" I don't think so. > > > > #: appwiz.rc:39 > msgid "Programs (*.exe)" > -msgstr "Программы (*.exe)" > +msgstr "Исполняемые файлы (*.exe)" No reason for that. > > #: appwiz.rc:40 avifil32.rc:30 cryptui.rc:80 shell32.rc:196 notepad.rc:73 > #: oleview.rc:101 progman.rc:79 regedit.rc:195 winedbg.rc:39 winhlp32.rc:87 > @@ -248,7 +247,7 @@ msgid "" > "file." > msgstr "" > "Ошибка контрольной суммы загруженного файла. Установка поврежденного файла " > -"отменяется." > +"будет отменена." English string doesn't say that it 'will be aborted', it says 'aborting' which means it's already in process to abort it. > > > > #: comdlg32.rc:157 comdlg32.rc:179 > msgid "&Directories:" > -msgstr "&Каталоги:" > +msgstr "&Папки:" It's better as it is. > > #: comdlg32.rc:160 comdlg32.rc:182 > msgid "List Files of &Type:" > -msgstr "Показывать файлы &типа:" > +msgstr "&Тип файлов:" This doesn't reflect original meaning. > > > > #: comdlg32.rc:282 > msgid "&Red:" > -msgstr "Крас&н:" > +msgstr "Крас&ный:" String length matters for this dialog as I remember. > > > > #: comdlg32.rc:315 comdlg32.rc:336 > msgid "Match &Whole Word Only" > @@ -817,20 +816,18 @@ msgid "" > "File does not exist.\n" > "Do you want to create file?" > msgstr "" > -"Файла не существует.\n" > -"Хотите ли вы его создать?" > +"Файла не существует. Создать?" This supposed to match original line splitting probably. > > > #: comdlg32.rc:68 > msgid "Unknown printer driver." > -msgstr "Неизвестный драйвер принтера." > +msgstr "Неопознанный драйвер принтера." This sounds like 'unknown' from UFO now. > > #: crypt32.rc:55 > msgid "On-line Certificate Status Protocol" > @@ -1371,7 +1367,7 @@ msgstr "Имя SSL-сервера Netscape" > > #: crypt32.rc:67 > msgid "Netscape Comment" > -msgstr "Комментарий Netscape" > +msgstr "Комментарии Netscape" Original word is in singular. ... I'm skipping the rest as it's too much to comment at once, but I think you got the idea how to improve that. Also winerror strings should be left as it is, cause nobody cares much anyway. And please pay attention to actual dialog testing, cause updated strings should fit in.

1 0

Re: Command line parameters
by Hin-Tak Leung 07 Jun '12

07 Jun '12

--- On Thu, 7/6/12, John Emmas <johne53(a)tiscali.co.uk> wrote: <snipped> > Is Wine clever enough to realise that the UTF8 string needs to be converted to a locale-specific string, so that the Windows app can understand it? Or does Wine simply pass whatever characters it received, without attempting any translation? Thanks. > John "Use the source, Luke!"... THe relevant code is in dlls/ntdll/file.c and dlls/ntdll/path.c which do the right thing. As a general windows programming note, in windows' land, file path related WIN32 APIs tend to have two variants, those ending with *A, and those ending with *W. The former expects ascii inputs, the latter expects WCHAR (I think it is basically UT16LE). The long answer is that wine leaves the former unchanged (except path separator translation, e.g. from unix "/" to windows "\", adding or removing drive letter prefixes, depending on the direction of translation), but will convert from utf8 to WCHAR for the latter, so that the application itself receives the right thing. It is still up to the application's author to use the right Windows APIs for reading/writing files, and whether the application itself expects ascii file paths or unicode (WCHAR) file paths. The short answer is that wine *does* translate from unix-like to windows-like file paths so that the application receives the right stuff. You have nothing to worry about.

2 1

Command line parameters
by John Emmas 07 Jun '12

07 Jun '12

Originally, I was going to post this on wine-users but after I wrote it, it seemed like wine-devel might be more appropriate. Please let me know if I need to re-submit it to wine-users. I understand that Wine is mostly used for running Windows apps on Linux - i.e. in most cases, the user will be launching the Windows app manually. But what about a Linux application that needs to launch a Windows app? What does Wine do (if anything) about command-line parameters..? After using fork() to create a new process, this would be a typical program command to start Wine and the Windows app:- execl (the_path_to_wine, "wine", path_to_the_windows_program, command_line_parameter_for_windows_app, NULL); Notice that execl() passes two command-line parameters to Wine (one of which gets passed to the Windows app). Let's assume this is a file path as that's easy to visualize. In the vast majority of cases, those command-line parameters will get passed to Wine as UTF8 strings. Wine will hopefully understand this when interpreting 'path_to_the_windows_program'. However, Windows programs themselves don't understand UTF8 at all - except for a very limited set of (mostly English) characters. So if that parameter was a file path (e.g. a file that the Windows program needed to open) it would only get understood in an English speaking locale. Non-English characters (accented characters etc) would only get understood if a locale translation takes place. Is Wine clever enough to realise that the UTF8 string needs to be converted to a locale-specific string, so that the Windows app can understand it? Or does Wine simply pass whatever characters it received, without attempting any translation? Thanks. John

1 0

Re: [4/4] windowscodecs: Add WICIfdMetadataReader registration.
by Marvin 07 Jun '12

07 Jun '12

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=18837 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

2 2

re: comctl: allow label edit only if treeview style allows editing
by Dan Kegel 06 Jun '12

06 Jun '12

> I stopped doing > make test on my machine some time ago Bad developer, no donut :-) > , when I found out that some > tests do consistently fail on my machine (clean prefix or not), and > others consistently hang, thus preventing make test -k. I had the same problem, and wrote a little script to skip the bad tests. It was written for buildbot, but can be run standalone. Try downloading http://winezeug.googlecode.com/svn/trunk/buildbot/dotests.sh and http://winezeug.googlecode.com/svn/trunk/buildbot/dotests_blacklist.txt then run sh dotests.sh goodtests That will skip all the tests known to hang or fail. (The list might be a bit out of date, but it's easy to add new tests to the blacklist.) > I don't install wine-gecko, maybe that's the reason. Run https://winetricks.googlecode.com/svn/trunk/src/install-gecko.sh then you'll never have to install it again. (Until it's updated, anyway.) - Dan

2 1

Re: urlmon: Use file content to verify MIME type reported by file protocol handler
by Alexandre Julliard 06 Jun '12

06 Jun '12

Jacek Caban <jacek(a)codeweavers.com> writes: > --- > dlls/urlmon/file.c | 8 +++++++- > dlls/urlmon/tests/protocol.c | 4 ++++ > 2 files changed, 11 insertions(+), 1 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M urlmon.dll -T ../../.. -p urlmon_test.exe.so protocol.c && touch protocol.ok protocol.c:2447: Test failed: expected ReportProgress_MIMETYPEAVAILABLE protocol.c:2447: Test failed: expected ReportProgress_MIMETYPEAVAILABLE protocol.c:2447: Test failed: expected ReportProgress_MIMETYPEAVAILABLE protocol.c:2447: Test failed: expected ReportProgress_MIMETYPEAVAILABLE protocol.c:2447: Test failed: expected ReportProgress_MIMETYPEAVAILABLE protocol.c:2445: Test failed: expected ReportProgress_VERIFIEDMIMETYPEAVAILABLE protocol.c:2445: Test failed: expected ReportProgress_VERIFIEDMIMETYPEAVAILABLE protocol.c:2445: Test failed: expected ReportProgress_VERIFIEDMIMETYPEAVAILABLE protocol.c:2445: Test failed: expected ReportProgress_VERIFIEDMIMETYPEAVAILABLE protocol.c:2445: Test failed: expected ReportProgress_VERIFIEDMIMETYPEAVAILABLE etc. -- Alexandre Julliard julliard(a)winehq.org

1 0

1.4 has dropped off the list for AppDB submissions
by Rosanne DiMesio 06 Jun '12

06 Jun '12

As of the release of 1.5.5, 1.4 has dropped off the list of Wine versions for which AppDB test reports can be submitted. Can someone please add it to the list of stable releases that are always available in the dropdown list? Until it's put back, users will not be able to submit new test reports for 1.4. We could avoid having this problem every time there's a new stable release if users were allowed to submit test reports for any version. Bugzilla lists every version, I don't see why the AppDB doesn't. -- Rosanne DiMesio <dimesio(a)earthlink.net>

2 2