May 2008 - Wine-devel - list.winehq.org

Can someone get a Maximizer 8 trial CD for me?
by Dan Kegel 19 May '08

19 May '08

http://www.cabc.co.uk/maximizer8/trial_personal.htm free cd, but only for people in the EU. I'm interested because http://www.mindstab.net/wordpress/archives/292 is a recent report some this being one of the two "must have" apps for someone's dad. Thanks, Dan

2 1

Right way to cope with user error in make test?
by Jeremy White 19 May '08

19 May '08

So...turns out that in this flood of new reporting, that one of the errors only happened to me, and it further turns out to be entirely user error; I didn't have libxslt. So, the obvious first solution is for me to actually read my configure results and deal with it. But I think I serve nicely as an example of the sort of incompetent user for whom it would still be nice to have make test work cleanly. I didn't see any obvious standard way of coping with this situation. Did I miss it? I imagined that maybe we'd skip these cases, but I didn't see evidence of that. I could also imagine a facility whereby we note that the configure was not clean, and then refuse to run make test (or at least refuse to run the full winetest battery). Should we make libxslt non optional (or at least require an explicit --without-libxslt in order to build without it)? Cheers, Jeremy

11 19

Re: kernel32: Add a few traces to help debug test failures [RESEND]
by Dmitry Timoshkov 19 May '08

19 May '08

"James Hawkins" <jhawkins(a)codeweavers.com> wrote: > if(detailed_info->lpRootManifestPath) > ok(!lstrcmpiW(detailed_info->lpRootManifestPath, exinfo->root_manifest_path), > - "unexpected detailed_info->lpRootManifestPath\n"); > + "unexpected detailed_info->lpRootManifestPath: %s %s\n", > + strw(detailed_info->lpRootManifestPath), strw(exinfo->root_manifest_path)); As far as I can see strw() uses static buffer and is not able to handle more than one string at once. -- Dmitry.

1 0

Re: Right way to cope with user error in make test?
by Rolf Kalbermatter 19 May '08

19 May '08

Please both calm down a bit. <dmitry(a)codeweavers.com> wrote: >"Steven Edwards" <winehacker(a)gmail.com> wrote: >><dmitry(a)codeweavers.com> wrote: >>> Not everyone supposed to run the Wine tests, only those do who >>> *really* can comprehend the results and able to do something with them. >> >> NO. Everyone that builds Wine from source should run make test. > >Why? Does it magically make something useful? Again, what about other >packages built from source? To limit running of the test frame work only to those that know exactly what they are doing is a to strict limitation IMHO. You should not forget that acceptance of a patch is based on the criteria that it runs make test. Which in may case has been always a limited make test in the directory itself only, since a whole make test seldom or never even got so far as to run for the component I was working at. While sending patches is of course the right thing to do, it has been and still is rather discouraging to get wine sources, building them on ones own box and finally run a make test and find that there are many areas where it simply reports failures or crashes altogether especially in areas I do not have the knowledge to do anything about and not the time to dig into much deeper. The fact that I couldn't get the whole make test to run out of the box on my system without bad crashes and/or numerous test failures has not only made me not run it anymore except in tree for the component I attempted to create a fix for, but has actually discouraged me in the past from working on more bug fixes or improvements other than what I have found strictly necessary to make a specific app working. >> It should pass 100% for everyone everywhere. If does not then there is >> something wrong. It does the world not 1 damn bit of good if passes on >> your system and no one elses. > >If the test doesn't pass for you, go ahead and fix it. I can't do that >for you if the test passes for me. But isn't that the crux of why this discussion started? Someone finding that a soft dependency of Wine on a library should not create a failure but a skip when that dependency was not satisifed and this was detectable in a sane way. And getting shot down that this system should be considerd broken. If the missing soft dependency should be considered a broken system then the dependency should be not soft and vice versa. I personally don't mind a test failure in a library that depends on something I know I don't use and consequently don't have installed but if it's possible to skip the tests for that why not do it? The test framework should not only help avoiding regressions for the VERY active developers but allow anyone working on Wine in one way or the other to have some confidence that he got it to build right. It's what I usually do when installing any source package to see if I missed something. Getting a long list of errors and sometimes crashes out of the box really leaves a bad taste and also makes it much harder to verify that my own modifications to it later on didn't break it in some ways. Rolf Kalbermatter

3 3

is run-time path translation standard
by Roumen Petrov 18 May '08

18 May '08

Dear Wine developers, Starting from version 2.x the libtool would like the create an environment where user to be able to run win32 programs. The former version 1.5x has this capability, but with some limitation in case of cross-compilation environment. The current libtool HEAD revision contain code that create binary executable (C-wrapper). This wrapper executable setup environment and run the real executable. The development in case of cygwin/msys native environment is finished and now on the road is cross-compilation. Lest see recent libtool 2x discussion started here: http://lists.gnu.org/archive/html/libtool-patches/2008-05/msg00044.html The question if about translation at run time of items in PATH environment variable. My test show that we can add absolute paths from build system to the PATH and at run time those paths are translated to the paths in emulated environment. Is this translation documented, i.e. standard or it is just a "side-effect"? If translation is non-standard, could Wine team confirm that will keep it ? Note that Charles may is not subscribed to the list and please CC to him. Roumen P.S. Also, please consider a minor issue with winepath: http://bugs.winehq.org/show_bug.cgi?id=13265

1 0

Re: WineD3D: workaround for lack of depth/stencil
by Stefan Dösinger 18 May '08

18 May '08

Am Sonntag, 18. Mai 2008 18:11:35 schrieb Roderick Colenbrander: > Hi, > > This patch is a workaround for a severe WineD3D issue which is too much > work and to risky to fix properly during the code freeze. It fixes drawing > issues in GTR2, Suppreme Commander, Call of Duty 2 Call of Duty 4 and > likely dozens of other games. Wouldn't it be better to write the FIXME only if the app requests a depth stencil format != D24S8?

1 0

What graphics cards do the d3d9 tests pass on?
by Dan Kegel 18 May '08

18 May '08

Anyone know how to get the d3d9 tests to pass? Are there a set of graphic cards that are known to work with them? Right now, nobody who's reported test results under wine is seeing them pass: http://test.winehq.org/data/2470b0b31605133ec046330dd79fdccaa7ba33fe/#group… And, come to think of it, ditto for Windows: http://test.winehq.org/data/200804161000/#group_XP:d3d9:visual (though the data's pretty thin there). All the apparant successes are really just skipped tests. - Dan

6 6

Configure question about Wine / HAL
by Kris Moore 17 May '08

17 May '08

I'm trying to get Wine to compile with HAL support on FreeBSD, and running into this error: > checking dbus/dbus.h usability... yes > checking dbus/dbus.h presence... yes > checking for dbus/dbus.h... yes > checking hal/libhal.h usability... yes > checking hal/libhal.h presence... yes > checking for hal/libhal.h... yes > checking for dbus_connection_close in -ldbus-1... no > configure: error: libhal development files not found, no dynamic device > support. > This is an error since --with-hal was requested. What exactly is -ldbus-1? Is there a way around this? Configure is finding the dbus and hal headers properly, and they both work properly on the system. -- Kris Moore PC-BSD Software http://www.pcbsd.com

4 11

curious failure and messages running a well-known installer
by Hin-Tak Leung 17 May '08

17 May '08

I install the win32 version of ghostscript quite routinely under wine; just taken the old one off and put the new one in with wine rc1, the first time it bombed out with: err:module:map_image Could not map section _winzip_, file probably truncated err:module:map_image Could not map section _winzip_, file probably truncated wine: could not load L"H:\\mirror.cs.wisc.edu\\pub\\mirrors\\ghost\\GPL\\current\\gs862w32.exe": Bad EXE format for and 2nd/3rd time it went to completion. This is the first time ever I have a failure installing ghostscript. There are some messages which I don't remember seeing before also: fixme:shell:IShellLinkA_fnGetPath (0x14a980): WIN32_FIND_DATA is not yet filled. fixme:shell:IShellLinkA_fnGetPath (0x14aae8): WIN32_FIND_DATA is not yet filled. I seem to recall the _winzip_ thing is a known and fixed problem? anyway, the installer is at http://mirror.cs.wisc.edu/pub/mirrors/ghost/GPL/current/gs862w32.exe and I'd be interested to hear if somebody else the _winzip_ failure message. __________________________________________________________ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html

3 2

Re: WIKI: Add forum link to wiki site
by Dimi Paun 17 May '08

17 May '08

On Sat, 2008-05-17 at 10:26 +0200, Rico Schüller wrote: > Hi, > > this patch adds the Wine Forum link to the WineHQ Menu in the wiki. Thanks! Now I'm just on my way out to New York, I'll get back in 3 days, I'll look at it when I get back. [If I don't commit it in 3-4 days, please ping me again, in case it felt through the cracks] -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

1 0