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

Proposal: put Winetricks into Wine menu

by Dan Kegel

I know, when I wrote Winetricks, I meant it as a developers' tool only. But... then... people started using it, and it made sense to provide it as a way to download missing visual C++ runtimes etc. for average users. Quite a few newbies trip over the fact that it needs cabextract installed. Let's make it easy for folks, actually package it up along with Wine (SuSE does this already), and put it in the Wine menu right beneath "Uninstall Windows Software". What do people think? It might make life easier for a lot of folks. (And, come to think of it, we should include some documentation in that menu. "man wine" just doesn't cut it for the average gui user, and "wine manual page" in the gnome help browser is a broken link. But that's a separate issue.) - Dan

Feb. 14, 2009

Re: WINEGATE.DLL: Wine gateway to native Unix libraries

by Ben Klein

2009/2/14 Martin Hinner <martin(a)hinner.info>: > Purpose of this Wine DLL is to allow Windows applications to use > directly Unix library functions. This is useful for example for > applications which talk to specific drivers and it's not > efficient/possible to create system native DLL for such driver or > library. Win32 app. vendor is required only to detect execution under > Wine and load proper native library. Windows apps don't call *nix libraries directly as is, so I'm not sure I understand the purpose here. I can see it could potentially be useful for porting apps using winelib, but I don't see how it can be useful for full win32 apps precompiled for Windows systems. > I am sure there will be a lot of people arguing that Win32 > application SHOULD NOT be modified to behave differently in Wine. The main reason for this is if the win32 app depends on some function of Wine caused by a bug or missing feature, then a future version of Wine will break the application (because the application is already broken, and only behaves correctly under broken Wine). > I agree that in most cases it's better to fix Wine than applications, > but there are real world problems that cannot be efficiently solved > outside the application. One good example is when Win32 app has to > talk to custom hardware. In many cases there are native Linux drivers > that have different API/etc and it is very very difficult to create > wrapper library between Windows-style and Linux/Unix-style drivers. In > such cases it's much easier to modify source code of Windows app to > use either Linux or Windows drivers/DLLs/etc. Why not use winelib for these cases if *nix support is important enough to modify the source so it works nicer in Wine?

Feb. 14, 2009

WINEGATE.DLL: Wine gateway to native Unix libraries

by Martin Hinner

Hello, I have created a small library to allow Win32 applications running under Wine to load native Unix shared libraries (.so). First (one-hour hack) version is available at http://martin.hinner.info/tmp/winegate.tar.gz ; Please consider inclusion in WINE tree (dll/ directory). Please note that Makefile.in as well as configure scripts will likely need some changes. Purpose of this Wine DLL is to allow Windows applications to use directly Unix library functions. This is useful for example for applications which talk to specific drivers and it's not efficient/possible to create system native DLL for such driver or library. Win32 app. vendor is required only to detect execution under Wine and load proper native library. WinGate.DLL exports dlopen/dlsym/dlclose/dlerror functions which allow Windows app to load additional libraries and use them. This library should export all functions that are required to load additional libraries and detect type & version of system we're running on. I believe that NO additional functions are required as you can always import uname() and call it to obtain more information on the running system, so dlopen/dlsym/dlclose is enough. Maybe some 'getwineversion' function should be included - waiting for your comments. I am sure there will be a lot of people arguing that Win32 application SHOULD NOT be modified to behave differently in Wine. I agree that in most cases it's better to fix Wine than applications, but there are real world problems that cannot be efficiently solved outside the application. One good example is when Win32 app has to talk to custom hardware. In many cases there are native Linux drivers that have different API/etc and it is very very difficult to create wrapper library between Windows-style and Linux/Unix-style drivers. In such cases it's much easier to modify source code of Windows app to use either Linux or Windows drivers/DLLs/etc. Example how to use WINEGATE.DLL is in winesupp.zip (please note this is quite silly example). If you want to see real world application which uses this library, go to http://www.jtagtest.com I have chosen name Wingate because google did not reveal any other use of such name and I think it fits it's purpose. Feel free to suggest any other names or just rename the library. Martin

Feb. 14, 2009

msvcrt:file test failures under wine and winetest

by Austin Lund

I've been playing around with the odd failure that occurs on some platforms for the msvcrt:file tests. http://test.winehq.org/data/6a1537c4b5037be5253c33021fda3a02430533f7/#group… I am able to recreate it on my computer running ubuntu 8.10. (tag: apl-u810-dell630) I was trying to nail down what exactly problem was when I found the following: $ ./programs/winetest/winetest -o out -c msvcrt:file 2> /dev/null && tail -n 8 out Test output: msvcrt:file start dlls/msvcrt/tests/file.c - file: 3 tests executed (0 marked as todo, 0 failures), 0 skipped. file: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. file: 5 tests executed (0 marked as todo, 0 failures), 0 skipped. file: 5 tests executed (0 marked as todo, 0 failures), 0 skipped. file: 462 tests executed (0 marked as todo, 0 failures), 0 skipped. msvcrt:file done (0) It seemed to succeed when it was the only test run. I played around for a bit with this and found the combination of tests which causes the failure: $ ./programs/winetest/winetest -o out -c msvcrtd:debug msvcrt:file 2> /dev/null && tail -n 13 out Test output: msvcrtd:debug start dlls/msvcrtd/tests/debug.c - debug: 2 tests executed (0 marked as todo, 0 failures), 0 skipped. msvcrtd:debug done (0) msvcrt:file start dlls/msvcrt/tests/file.c - file: 3 tests executed (0 marked as todo, 0 failures), 0 skipped. file: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. file.c:1057: Test failed: fstat(stdin) failed: errno=2 file.c:1066: Tests skipped: stdin is not a char device? st_mode=100666 file: 5 tests executed (0 marked as todo, 0 failures), 0 skipped. file: 5 tests executed (0 marked as todo, 0 failures), 0 skipped. file: 458 tests executed (0 marked as todo, 1 failure), 1 skipped. msvcrt:file done (1) Also of note is that when doing "make test" this failure never occurs. So whatever is going on, it is a strange interaction between msvcrtd:debug msvcrt:file tests and winetest. Another point to make is that the error that corresponds to errno=2 is "No such file or directory", which is an odd message for a filedes which is meant to be stdin. Does anyone have any tips on what to look at to nail this one down?

Feb. 14, 2009

Please advise: Wine problem with Oracle database installation

by Robert

Dear support, I have met a problem when installing Oracle database with Wine. The error message is as follows: "Failed loading com.sun.java.accessibility.eventqueuemonitor:java.lang.classnotfoundexception:com.sun.java.accessibility.util.eventqueuemonitor" I wonder whether this problem is due to JDK plug-in is not supported in Wine. Please kindly advise. Thanks a lot! Regards Robert

Feb. 14, 2009

Re: Firefox 3 runs faster on Linux+Wine than on Linux -- comparative to running on Windows

by Reece Dunn

2009/2/13 Reece Dunn <msclrhd(a)googlemail.com>: > Hi, > > For those not monitoring slashdot [1], there is an article [2] that is > comparing the Google V8 benchmark on Windows and Linux versions of > Firefox 3. > > The result of this is that the Windows and Wine runs are pretty close > (241 vs 227) when compared to the Linux run (181) and Opera (155). > > I wonder what the results are like on Firefox 3.1 with tracemonkey > enabled on Windows, Wine and Linux. > > [1] http://tech.slashdot.org/article.pl?sid=09/02/13/0058251 > [2] http://www.tuxradar.com/content/browser-benchmarks-2-even-wine-beats-linux-… As a follow up, I have been doing some testing of my own. http://spreadsheets.google.com/pub?key=pCaFy3jQwNj5XFrxvcYJxPA&gid=3 shows the results for several different runs using different optimisation options on gcc for wine. For linux, wine and for wine optimised to better target the machine, I have taken the average of 3 runs. Because I overwrote my -O3 build of wine, I only have the one data point. What does this all mean? I'll leave that to the statisticians :D NOTE: I haven't tried Profile Guided Optimisation on wine, nor have I tried building Firefox 3 with optimisations on when running it on native Linux... yet! - Reece

Feb. 14, 2009

Re: wininet: parse cookie information from cookie value

by Rob Shearman

2009/2/13 Aric Stewart <aric(a)codeweavers.com>: > + if (CompareStringW(GetThreadLocale(), NORM_IGNORECASE, ptr, 6, > + szDomain, 6) == 2) LOCALE_INVARIANT should be used when comparing with a constant string. See here for the reasons why: http://blogs.msdn.com/michkap/archive/2004/12/29/344136.aspx http://blogs.msdn.com/larryosterman/archive/2004/07/01/171078.aspx http://msdn.microsoft.com/en-us/library/dd373795(VS.85).aspx It doesn't look like it's implemented in Wine, so I guess you should just use MAKELCID(LANG_ENGLISH, SUBLANG_DEFAULT) with a FIXME to use LOCALE_INVARIANT when it's implemented. And, yes, there's probably lots of other places where we do case insensitive comparisons incorrectly like this, but we should stop introducing new ones. -- Rob Shearman

Feb. 14, 2009

Re: atmlib: add stub dll

by Austin English

On Fri, Feb 13, 2009 at 4:37 PM, Austin English <austinenglish(a)gmail.com> wrote: > On Fri, Feb 13, 2009 at 4:27 PM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: >> Austin English wrote: >>> Needed by photoshop cs4. See bug 16385. >>> >>> diff --git a/dlls/atmlib/atmlib_main.c b/dlls/atmlib/atmlib_main.c >>> new file mode 100644 >>> index 0000000..bb17989 >>> --- /dev/null >>> +++ b/dlls/atmlib/atmlib_main.c >>> @@ -0,0 +1,45 @@ >>> +/* >>> + * MSSIGN32 implementation >>> + * >>> + * Copyright 2009 Austin English >>> + * >>> >> >> Hi, Austin, not mssign32 ). >> >> >> > > Whoops, thanks. Damn copy/paste...I'll resend. > > -- > -Austin > Apparently it's not a Microsoft DLL, but Adobe...nevermind. Must be installer error not copying it over.. -- -Austin

Feb. 13, 2009

Re: atmlib: add stub dll

by Austin English

On Fri, Feb 13, 2009 at 4:27 PM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > Austin English wrote: >> Needed by photoshop cs4. See bug 16385. >> >> diff --git a/dlls/atmlib/atmlib_main.c b/dlls/atmlib/atmlib_main.c >> new file mode 100644 >> index 0000000..bb17989 >> --- /dev/null >> +++ b/dlls/atmlib/atmlib_main.c >> @@ -0,0 +1,45 @@ >> +/* >> + * MSSIGN32 implementation >> + * >> + * Copyright 2009 Austin English >> + * >> > > Hi, Austin, not mssign32 ). > > > Whoops, thanks. Damn copy/paste...I'll resend. -- -Austin

Feb. 13, 2009

Re: atmlib: add stub dll

by Nikolay Sivov

Austin English wrote: > Needed by photoshop cs4. See bug 16385. > > diff --git a/dlls/atmlib/atmlib_main.c b/dlls/atmlib/atmlib_main.c > new file mode 100644 > index 0000000..bb17989 > --- /dev/null > +++ b/dlls/atmlib/atmlib_main.c > @@ -0,0 +1,45 @@ > +/* > + * MSSIGN32 implementation > + * > + * Copyright 2009 Austin English > + * > Hi, Austin, not mssign32 ).

Feb. 13, 2009