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

Re: Command line parameters

by Hin-Tak Leung

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

June 7, 2012

Command line parameters

by John Emmas

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

June 7, 2012

Re: [4/4] windowscodecs: Add WICIfdMetadataReader registration.

by Dmitry Timoshkov

Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Marvin <testbot(a)testbot.winehq.org> wrote: > > > === WINEBUILD (build) === > > Patch failed to apply > > Because it depends on a not yet applied > "windowscodecs: Add metadata reader information to the registry." I should add, that the patch adds nothing new to the tests, it just moves around a couple of todo_wine here and there to reflect current state of IFD metadata reader tests under Wine, so it shouldn't change anything for Windows testbot runs. -- Dmitry.

June 7, 2012

Re: [4/4] windowscodecs: Add WICIfdMetadataReader registration.

by Dmitry Timoshkov

Marvin <testbot(a)testbot.winehq.org> wrote: > === WINEBUILD (build) === > Patch failed to apply Because it depends on a not yet applied "windowscodecs: Add metadata reader information to the registry." -- Dmitry.

June 6, 2012

Re: [4/4] windowscodecs: Add WICIfdMetadataReader registration.

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

June 6, 2012

Re: comctl: allow label edit only if treeview style allows editing

by Daniel Jelinski

2012/6/4 Dan Kegel <daniel.r.kegel(a)gmail.com>: > 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.) Now that's much better! Thank you. I slightly modified the script and found that 5 tests from the good list fail with native comctl. Good indicator of areas that need more love :) -- Regards, Daniel

June 6, 2012

Re: urlmon: Use file content to verify MIME type reported by file protocol handler

by Alexandre Julliard

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

June 6, 2012

Re: 1.4 has dropped off the list for AppDB submissions

by Rosanne DiMesio

On Mon, 28 May 2012 16:00:49 +0200 André Hentschel <nerv(a)dawncrow.de> wrote: > Am 28.05.2012 15:26, schrieb Rosanne DiMesio: > > 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. > > > > I already sent a patch in March for this: http://www.winehq.org/pipermail/wine-patches/2012-March/112149.html > > -- It hasn't been committed, which means that currently users can submit test reports for 1.0.x and 1.2.x, but not 1.4. If that's really the intended behavior, I wish someone would explain why, because it doesn't make any sense to me. -- Rosanne DiMesio <dimesio(a)earthlink.net>

June 6, 2012

Re: [PATCH 2/3] server: STATUS_MORE_PROCESSING_REQUIRED does not indicate that an async operation is complete (try 4).

by Erich E. Hoover

On Wed, Jun 6, 2012 at 5:56 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > "Erich E. Hoover" <compholio(a)gmail.com> writes: > >> @@ -285,7 +285,9 @@ void async_set_result( struct object *obj, unsigned int status, unsigned int tot >> if (async->timeout) remove_timeout_user( async->timeout ); >> async->timeout = NULL; >> async->status = status; >> - if (async->data.cvalue) >> + if (status == STATUS_MORE_PROCESSING_REQUIRED) >> + async->status = STATUS_PENDING; >> + else if (async->data.cvalue) > > Why are you marking the async pending? That doesn't seem right, it's > terminated at that point. That would be because I misread the MSDN article a little bit (either that or the one I just looked up is a different one from what I originally read). Would you like me to resubmit everything or just part 2 and 3? Erich Hoover ehoover(a)mines.edu

June 6, 2012

Re: http://winetricks.googlecode.com/svn/trunk/src/install-gecko.sh also installs mono

by Vincent Povirk

> The core of mono is safe. It is covered under ECMA-334 (C# language) > and ECMA-335 (CLIR vm). > The mono MS Compatibility Stack, which includes: > - XML > - ASP.NET > - Windows.Forms > - ADO.NET > - Core cryptography > - Transactions > > is a grey area now since the project is not part of Novell anymore. > Novell and Microsoft had joint patent agreement, so there were no > problems. So the question is, does wine-mono include the compatibility > stack? I know Windows.Forms is included. I'm not familiar with the other items, but if mono builds them by default then they're included.

June 6, 2012