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

Re: configure.ac: when checking for ALSA, look for snd_pcm_recover() instead of snd_pcm_hw_params_get_access()

by Maarten Lankhorst

Hello, On 06-06-10 21:09, Austin English wrote: > On Sun, Jun 6, 2010 at 3:27 AM, Andrew Nguyen<arethusa26(a)gmail.com> wrote: > >> On Sun, Jun 6, 2010 at 2:50 AM, Austin English<austinenglish(a)gmail.com> wrote: >> >>> See http://bugs.winehq.org/show_bug.cgi?id=23003 >>> >>> -- >>> -Austin >>> >>> >>> >>> >>> >> You should probably drop the snd_pcm_hw_params_get_access argument >> check, both because it's not the function that's being tested, and >> because, as far as I can tell from the alsa-lib git repo, the >> prototype for the function has never changed. >> > Good call, thanks for catching. > Is snd_pcm_recover the only function missing? If so change it to dlsym, and add a copy of snd_pcm_recover to wine if it cannot find the libalsa one.. Cheers, Maarten

June 6, 2010

Re: configure.ac: when checking for ALSA, look for snd_pcm_recover() instead of snd_pcm_hw_params_get_access() (try 2)

by Andrew Nguyen

I hate to nitpick once more, but there are a few things I noticed. My alsa-lib tells me: include/pcm.h:int snd_pcm_recover(snd_pcm_t *pcm, int err, int silent); Therefore, the statement "int ret = snd_pcm_recover(NULL, NULL, NULL);" is somewhat incorrect. Secondly, I think it should be sufficient to drop the AC_COMPILE_IFELSE macro entirely. The purpose in the original test was to distinguish between the version supplied in ALSA 0.9.x and ALSA 1.x, so, while I don't feel strongly about the matter either way, just checking for the existence of the function should be sufficient, as is done in other tests.

June 6, 2010

Re: configure.ac: when checking for ALSA, look for snd_pcm_recover() instead of snd_pcm_hw_params_get_access() (try 2)

by Marcus Meissner

On Sun, Jun 06, 2010 at 02:21:33PM -0500, Austin English wrote: > -- > -Austin > diff --git a/configure.ac b/configure.ac > index 21c0203..46ac100 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -1,4 +1,4 @@ > -dnl Process this file with autoconf to produce a configure script. > +/dnl Process this file with autoconf to produce a configure script. Bad. Ciao, Marcus

June 6, 2010

Re: configure.ac: when checking for ALSA, look for snd_pcm_recover() instead of snd_pcm_hw_params_get_access()

by Austin English

On Sun, Jun 6, 2010 at 3:27 AM, Andrew Nguyen <arethusa26(a)gmail.com> wrote: > On Sun, Jun 6, 2010 at 2:50 AM, Austin English <austinenglish(a)gmail.com> wrote: >> See http://bugs.winehq.org/show_bug.cgi?id=23003 >> >> -- >> -Austin >> >> >> >> > > You should probably drop the snd_pcm_hw_params_get_access argument > check, both because it's not the function that's being tested, and > because, as far as I can tell from the alsa-lib git repo, the > prototype for the function has never changed. Good call, thanks for catching. -- -Austin

June 6, 2010

Re: Running tests on wine

by GOUJON Alexandre

2010/6/6 Nikolay Sivov<nsivov(a)codeweavers.com>: > You're running it with make, and a test results are from winetest runs. As I > remember winetest runs it as 'wine oleaut32_tests.exe typelib' with some env > variable to set a platform (this will enable todos output, AFAIK). You're right. I noticed this file but I prefered doing what was wrote on the wiki. 06/06/2010 20:25, Nicolas Le Cam : > Results are from a winetest64 test suite running under wine64. > If it's the failure on this particular box that you want to debug, > just ask, results were sent from my laptop. > All these tests succeeds in genuine Windows and fails on wine. Almost wine tests fails in the same way so I just picked up a link to show you what I would like to see. But thanks for the precision !

June 6, 2010

Re: Gecko64 status

by Jacek Caban

Hi Juan, On 6/6/10 7:35 PM, Juan Lang wrote: >> Any comments and suggestions are welcomed. >> > One suggestion is that bugs get logged about test failures on Wine > wherever possible. Dan has done that for the chromium test suite, and > that's led to several bugs getting converted to Wine regression tests, > and even a few fixes ;-) > I agree, that's something I'd like to see as well. There are, in fact, two ways interesting me for running these tests: - Tests of MSVC builds That would be similar Chrome tests. It would be compiled the same way (under Wine) as official Firefox, so we'd find Wine bugs this way. The work on it was done in parallel to Chrome work, but it was never completed. AFAIK the main stopper is currently cmd implementation, so the SoC project should help. Dan will know more details about it. - Get tests of our mingw build There is a config in Wine Gecko Git tree that enables building them. They compile fine, but there is a problem with running them. I've played a bit with it in the past. To run them, a combination of python and makefiles is used. The compilation is done in Linux environment, without Wine involved, so we have to teach Mozilla build environment to run tests under Wine. By adding a simple wrapper I was able to run some subset of tests and they found a few bugs. This way we test both problems with mingw compilation and Wine and they have to be separated. From my experience there were more build bugs than Wine's. They are, however, interesting for us as well (for me even more, as we can fix Wine anytime and Wine Gecko releases are rare). The problem with running more tests is that we really need python scripts to be ran under Windows python and that's more tricky. I've never found the time to investigate it further. Cheers, Jacek

June 6, 2010

Re: Running tests on wine

by Nicolas Le Cam

2010/6/6 Nikolay Sivov <nsivov(a)codeweavers.com>: > On 6/6/2010 21:03, GOUJON Alexandre wrote: >> >> Hi, >> >> I would like to do some (typelib) tests on wine. >> >> So I followed the instructions at >> http://www.winehq.org/docs/winedev-guide/testing-wine >> ( cd dlls/oleaut32/tests/ ; rm typelib.ok && make typelib.ok in my case) >> >> but I have err's and fixme's whereas the output on wineTestBot is quite >> different >> >> (http://test.winehq.org/data/9aa9a1229f2195a8b3ac575645a10242ae6e9bc8/wine_n…) > > It's not a test bot, it's a test result uploaded by contributor. >> >> I tried WINETEST_DEBUG=1 make typelib.ok but it's the same output. >> >> Am I missing something ? > > You're running it with make, and a test results are from winetest runs. As I > remember winetest runs it as 'wine oleaut32_tests.exe typelib' with some env > variable to set a platform (this will enable todos output, AFAIK). >> >> Thanks >> >> Results are from a winetest64 test suite running under wine64. If it's the failure on this particular box that you want to debug, just ask, results were sent from my laptop. -- Nicolas Le Cam

June 6, 2010

Re: Gecko64 status

by Juan Lang

Hi Jacek, > However, it doesn't mean that nothing is going on around Wine Gecko. I've > recently switched to mingw-w64 for 32-bit builds. I've very pleased with it. > They are far better in co-operation, don't have senseless politics like > mingw and their quality of headers and libraries is far better. Great news! This has been a senseless stumbling block for some time. I'm looking forward to the ability to build wine-gecko. > Any comments and suggestions are welcomed. One suggestion is that bugs get logged about test failures on Wine wherever possible. Dan has done that for the chromium test suite, and that's led to several bugs getting converted to Wine regression tests, and even a few fixes ;-) Cheers, --Juan

June 6, 2010

Re: Running tests on wine

by Nikolay Sivov

On 6/6/2010 21:03, GOUJON Alexandre wrote: > Hi, > > I would like to do some (typelib) tests on wine. > > So I followed the instructions at > http://www.winehq.org/docs/winedev-guide/testing-wine > ( cd dlls/oleaut32/tests/ ; rm typelib.ok && make typelib.ok in my case) > > but I have err's and fixme's whereas the output on wineTestBot is > quite different > (http://test.winehq.org/data/9aa9a1229f2195a8b3ac575645a10242ae6e9bc8/wine_n…) > It's not a test bot, it's a test result uploaded by contributor. > > I tried WINETEST_DEBUG=1 make typelib.ok but it's the same output. > > Am I missing something ? You're running it with make, and a test results are from winetest runs. As I remember winetest runs it as 'wine oleaut32_tests.exe typelib' with some env variable to set a platform (this will enable todos output, AFAIK). > > Thanks > >

June 6, 2010

Running tests on wine

by GOUJON Alexandre

Hi, I would like to do some (typelib) tests on wine. So I followed the instructions at http://www.winehq.org/docs/winedev-guide/testing-wine ( cd dlls/oleaut32/tests/ ; rm typelib.ok && make typelib.ok in my case) but I have err's and fixme's whereas the output on wineTestBot is quite different (http://test.winehq.org/data/9aa9a1229f2195a8b3ac575645a10242ae6e9bc8/wine_n…) I tried WINETEST_DEBUG=1 make typelib.ok but it's the same output. Am I missing something ? Thanks

June 6, 2010

Re: xrender.c is does not find fontconfig.h on OS X Tiger

by James McKenzie

Mike Kronenberg wrote: > Dear List > > OS X Tiger does has not have fontconfig, so I'm building it in ~/buildwine/usr to keep it out of /usr. > I include the headers and libs from ~/buildwine/usr with CPPFLAGS and CFLAGS. What Mike meant to say is that MacOSX does not include fontconfig functionality in the developer libraries, so he is building fontconfig version 2.8.0 and placing in outside of the systems files to prevent problems. > > > This worked fine until 1.2-rc1 and 1.2-rc2. > > Compiling xrender.c now exits with an error that FC_WEIGHT_THIN etc is not defined. > > This may be caused by a recent patch commited by AJ. Also, this error does not happen with the built-in fontconfig provided with MacOSX 10.5 and 10.6. > configure leaves me with > > SONAME_LIBFONTCONFIG='libfontconfig.1.dylib' > FONTCONFIGINCL='' > > in the config.log. > No luck even if I > > export FONTCONFIGINCL="-I//$HOME/buildwine/usr/include/fontconfig -I//$HOME/buildwine/usr/include' > > which resulted in a correct FONTCONFIGINCL, but the compiling still failed. > This should point to fontconfig's include files, but is it necessary to add in the library files as well? Everything else appears to be building up to this point and then failure happens. I cannot assist Mike with his regression efforts as I don't have an Intel Mac with MacOSX installed. Using the Software Development Kit for MacOSX 10.4 does not force this error to happen as the MacOSX development libraries are used. James McKenzie

June 6, 2010

Re: [PATCH 3/3] shlwapi: Implement SHSetIniStringW

by testbot＠testbot.winehq.org

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=2490 Your paranoid android. === W2KPROSP4 (32 bit ordinal) === ordinal.c:604: Test failed: GetShellSecurityDescriptor should fail ordinal.c:627: Test failed: returned value is not valid SD No test summary line found === W7PRO (32 bit ordinal) === ordinal.c:1776: Test failed: got 25 ordinal.c:1826: Test failed: got 25 ordinal.c:1834: Test failed: got 25 ordinal.c:1842: Test failed: got 36, length 37 ordinal.c:1853: Test failed: got 39 === W7PROX64 (32 bit ordinal) === ordinal.c:1776: Test failed: got 22 ordinal.c:1826: Test failed: got 22 ordinal.c:1834: Test failed: got 22 ordinal.c:1842: Test failed: got 31, length 32 ordinal.c:1853: Test failed: got 34 === W7PROX64 (64 bit ordinal) === ordinal.c:1776: Test failed: got 22 ordinal.c:1826: Test failed: got 22 ordinal.c:1834: Test failed: got 22 ordinal.c:1842: Test failed: got 31, length 32 ordinal.c:1853: Test failed: got 34

June 6, 2010

Re: [PATCH 2/3] shlwapi: Implement SHGetIniStringW

by testbot＠testbot.winehq.org

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=2489 Your paranoid android. === W2KPROSP4 (32 bit ordinal) === ordinal.c:603: Test failed: GetShellSecurityDescriptor should fail ordinal.c:626: Test failed: returned value is not valid SD No test summary line found === W7PRO (32 bit ordinal) === ordinal.c:1775: Test failed: got 25 ordinal.c:1825: Test failed: got 25 ordinal.c:1833: Test failed: got 25 ordinal.c:1841: Test failed: got 36, length 37 ordinal.c:1852: Test failed: got 39 === W7PROX64 (32 bit ordinal) === ordinal.c:1775: Test failed: got 22 ordinal.c:1825: Test failed: got 22 ordinal.c:1833: Test failed: got 22 ordinal.c:1841: Test failed: got 31, length 32 ordinal.c:1852: Test failed: got 34 === W7PROX64 (64 bit ordinal) === ordinal.c:1775: Test failed: got 22 ordinal.c:1825: Test failed: got 22 ordinal.c:1833: Test failed: got 22 ordinal.c:1841: Test failed: got 31, length 32 ordinal.c:1852: Test failed: got 34

June 6, 2010

Re: [PATCH 1/3] shlwapi: Be less strict on which type of IShellFolder can be enumerated

by testbot＠testbot.winehq.org

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=2488 Your paranoid android. === W2KPROSP4 (32 bit ordinal) === ordinal.c:595: Test failed: GetShellSecurityDescriptor should fail ordinal.c:618: Test failed: returned value is not valid SD No test summary line found === W7PRO (32 bit ordinal) === ordinal.c:1767: Test failed: got 25 ordinal.c:1817: Test failed: got 25 ordinal.c:1825: Test failed: got 25 ordinal.c:1833: Test failed: got 36, length 37 ordinal.c:1844: Test failed: got 39 === W7PROX64 (32 bit ordinal) === ordinal.c:1767: Test failed: got 22 ordinal.c:1817: Test failed: got 22 ordinal.c:1825: Test failed: got 22 ordinal.c:1833: Test failed: got 31, length 32 ordinal.c:1844: Test failed: got 34 === W7PROX64 (64 bit ordinal) === ordinal.c:1767: Test failed: got 22 ordinal.c:1817: Test failed: got 22 ordinal.c:1825: Test failed: got 22 ordinal.c:1833: Test failed: got 31, length 32 ordinal.c:1844: Test failed: got 34

June 6, 2010

Re: appwiz: Add the Polish translation

by Sven Baars

Hey Łukasz, all your translations are written in UTF-8, but to actually use UTF-8, you also have to include a #pragma code_page(65001) on top of the file. In this case for example +#include "res.h" + +LANGUAGE LANG_POLISH, SUBLANG_DEFAULT + +#pragma code_page(65001) Atm, if you compile wine with this patch applied you see: sven(a)sven-desktop:~/wine-git/dlls/appwiz.cpl$ make LD_LIBRARY_PATH="../../libs/wine:$LD_LIBRARY_PATH" ../../tools/wrc/wrc --nostdinc -I. -I. -I../../include -I../../include -D__WINESRC__ -foPl.res Pl.rc Warning: string "Aby doda� program z dysku, p�yty CD-ROM lub dyskietki, kliknij przycisk Zainstaluj" seems to be UTF-8 but codepage 1250 is in use. Warning: string "To oprogramowanie mo�e by� usuni�te automatycznie. Aby usun�� program lub zmieni� jego zainstalowane komponenty, zaznacz go z listy i naci�nij Zmie�/Usu�." seems to be UTF-8 but codepage 1250 is in use. Warning: string "&Zmie�..." seems to be UTF-8 but codepage 1250 is in use. Warning: string "&Usu�..." seems to be UTF-8 but codepage 1250 is in use. Warning: string "Podane informacje mog� by� przydatne przy otrzymaniu pomocy technicznej dla %s:" seems to be UTF-8 but codepage 1250 is in use. Warning: string "Dodaj/Usu� programy" seems to be UTF-8 but codepage 1250 is in use. Warning: string "Pozwala na instalacj� nowego lub usuni�cie ju� istniej�cego oprogramowania z twojego komputera." seems to be UTF-8 but codepage 1250 is in use. Warning: string "Nie mo�na uruchomi� programu odinstalowuj�cego, '%s'. Czy chcesz usun�� wpis o tym programie z rejestru?" seems to be UTF-8 but codepage 1250 is in use. Warning: string "Nie okre�lone" seems to be UTF-8 but codepage 1250 is in use. Warning: string "&Usu�..." seems to be UTF-8 but codepage 1250 is in use. Warning: string "&Zmie�/Usu�..." seems to be UTF-8 but codepage 1250 is in use. You get warnings like this for every patch that you sent in. You can check it yourself by running "make depend" from the git directory and then "make" from the directory that contains the program or dll. This is at least how I got them. Regards, Sven P.S. You're not the only one making this mistake. I also made it the first time ;) Łukasz Wojniłowicz wrote: > --- > dlls/appwiz.cpl/Makefile.in | 1 + > dlls/appwiz.cpl/Pl.rc | 84 +++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 85 insertions(+), 0 deletions(-) > create mode 100644 dlls/appwiz.cpl/Pl.rc >

June 6, 2010

Re: Release plans

by wylda＠volny.cz

> > 340 regressions<-- release announcement > > 356 regressions<-- release announcement + 1week > > 339 regressions<-- release announcement + 2weeks(rc1) > > > 322 regressions<-- release announcement + 3weeks(rc2) > > > 325 regressions<-- release announcement + 4weeks > > As we didn't have a release last Friday shouldn't you > subtract the > "RESOLVED and FIXED" ones? Or do you 'ignore' these > until possible fixes > are actually committed? That's what i always did, i.e. there is 340 unclosed regressions, but 15 are RESOLVED, so that's where 325 comes from. BTW: I'm in process of recovery of my winetest maschine AKA WyldBOT (MOBO came back from Asus repair center).

June 6, 2010

Re: Release plans

by Paul Vriens

On 06/06/2010 11:34 AM, wylda(a)volny.cz wrote: > > Hi, another week and Sunday gone so time for simple numbers... > > 340 regressions<-- release announcement > 356 regressions<-- release announcement + 1week > 339 regressions<-- release announcement + 2weeks(rc1) > 322 regressions<-- release announcement + 3weeks(rc2) > 325 regressions<-- release announcement + 4weeks As we didn't have a release last Friday shouldn't you subtract the "RESOLVED and FIXED" ones? Or do you 'ignore' these until possible fixes are actually committed? -- Cheers, Paul.

June 6, 2010

Re: Release plans

by wylda＠volny.cz

Hi, another week and Sunday gone so time for simple numbers... 340 regressions <-- release announcement 356 regressions <-- release announcement + 1week 339 regressions <-- release announcement + 2weeks(rc1) 322 regressions <-- release announcement + 3weeks(rc2) 325 regressions <-- release announcement + 4weeks Good trend from pasted weeks took a nap.

June 6, 2010

Re: configure.ac: when checking for ALSA, look for snd_pcm_recover() instead of snd_pcm_hw_params_get_access()

by Andrew Nguyen

On Sun, Jun 6, 2010 at 2:50 AM, Austin English <austinenglish(a)gmail.com> wrote: > See http://bugs.winehq.org/show_bug.cgi?id=23003 > > -- > -Austin > > > > You should probably drop the snd_pcm_hw_params_get_access argument check, both because it's not the function that's being tested, and because, as far as I can tell from the alsa-lib git repo, the prototype for the function has never changed.

June 6, 2010

Re: Advice about a new project, and similarity to Wine's start

by Edward Savage

On Sun, Jun 6, 2010 at 7:23 AM, Dan Kegel <dank(a)kegel.com> wrote: >> Did people use the early releases of Wine, even if they were missing features? > > Yes, as soon as they ran their favorite app. > > So in your case, as soon as your flash player can handle youtube.com > (or whatever free software afficianados can't live without), a > few people will start using it. > The reality is that most people don't use a lot of flash and those who have iPhones use even less. Each time I try an opensource flash player I go to youtube and if it works I just leave it as my default until I come across a media player that breaks it and if I really want to watch the content I switch back to adobe. This is surprisingly similar to my early experience using Linux over Windows! I would say your first goal is to support youtube. After that go out and find as many of the popular media players made in flash and support them based on that sites popularity. Once you have media players done start working on all of the silly little games and then stop (before you start implementing flash ads support!).

June 6, 2010

Re: Advice about a new project, and similarity to Wine's start

by Wolfram Sang

> Is the AppDB software available for use on other projects? It is here and being GPL, I think you can use it :) http://source.winehq.org/git/appdb.git/ Good luck, Wolfram

June 6, 2010

Re: Wine code comments

by John Voltz

Thanks for all the input. I forgot about using #if (0). That will make life much easier. John

June 5, 2010

Re: Wine code comments

by James McKenzie

Octavian Voicu wrote: > 2010/6/5 James McKenzie <jjmckenzie51(a)earthlink.net>: > >> Also if (0)'d code should have a comment block on when and why it was >> removed and what must be done to re-incorporate it and if someone is working >> on it, a name and durable contact information. Also, an anticpated >> completion date, if known, should be entered. Reliance on a particular >> release is not sufficient. >> > > Isn't that what `git blame' is for? > Extra comments can go in the commit that introduces the if (0). > > Git is a realitively new product. Wine has been around before this was released. Some of the commented out code has no one in git to blame.... Also, if I were looking at this code from a pure security standpoint (which I can do), git blame is NOT VALID. Thus, I stand on my original statement: If you put it there, there should be comments IN THE CODE. If you blocked something out, you should take ownership. Sorry, AJ, but that is a legal stance, not a practical one. James McKenzie

June 5, 2010

re: Advice about a new project, and similarity to Wine's start

by Dan Kegel

Alessandro Pignotti wrote: > how did Wine choose the feature set to support first? Pragmatically - by trying to get particular popular apps running. (Starting with solitaire :-) > Did people use the early releases of Wine, even if they were missing features? Yes, as soon as they ran their favorite app. So in your case, as soon as your flash player can handle youtube.com (or whatever free software afficianados can't live without), a few people will start using it. > Is the AppDB software available for use on other projects? Should be. > Any misc advice? The Wine project started moving faster when we switched to test-driven development. I highly recommend it. Do you have a test suite? And/or can you share existing test suites ( e.g. http://wiki.gnashdev.org/Testcases ) ? That said, visual stuff is hard to test automatically, so mostly our automated tests only test the API level. Visual tests are done manually and much less often (say, only when changing directly affected code). Automated performance benchmarks are a good idea, though we haven't done as much of that. Good luck! - Dan

June 5, 2010

Gecko64 status

by Jacek Caban

Hi all, I'd like to share with you progress on gecko64. First of all, I think that it was never said in public, although I've been asked about it: there won't be gecko64 for 1.2 release. I think we will have Gecko release in the second half of this year it will support 64-bit, but it's not yet clear when exactly. We may try to do it near the next Firefox release, but time will show how it will work. However, it doesn't mean that nothing is going on around Wine Gecko. I've recently switched to mingw-w64 for 32-bit builds. I've very pleased with it. They are far better in co-operation, don't have senseless politics like mingw and their quality of headers and libraries is far better. We won't need to maintain fixes to build envinonment anymore. (I've been even talking about better co-operation between our projects, but that's OT here and I will report progress when there will be more to say). We're much nearer to allow packagers to build their own Gecko now. Back to gecko64, I've completed the first step. I have a working 64-bit Firefox crosscompiled with mingw-w64. See: https://bugzilla.mozilla.org/show_bug.cgi?id=570342 for details. It starts and runs on Windows. Now I wait for patches to be committed to Mozilla. It may take awhile :/ Before we may think about support for gecko64 in MSHTML, we have to fix its issues in Wine. Firefox is a good Gecko test and it needs to be fixed first. Unfortunately it currently doesn't even start. I've put a build on server in case anyone would like to try it: http://gerwazy.lo3.wroc.pl/~jcaban/wine/firefox-mingw-w64.tar.bz2 Volunteers on working on Wine side are very welcomed. There are also some other tests from Mozilla code. Note that before fixing any more sophisticated bug, it's worth to make sure on Windows, that the bug is in Wine, not in the build. All I verified is that Firefox should start and basic functionality works (and doesn't work on Wine). Any comments and suggestions are welcomed. Cheers, Jacek

June 5, 2010

Re: shdoclc: Add the Polish translation (try 2)

by Paul Vriens

On 06/05/2010 01:38 PM, Łukasz Wojniłowicz wrote: > + MENUITEM "&Odœwie¿ > +", _IDM_REFRESH Hi Łukasz, Something went wrong here. -- Cheers, Paul.

June 5, 2010

Re: Wine code comments

by Octavian Voicu

2010/6/5 James McKenzie <jjmckenzie51(a)earthlink.net>: > Also if (0)'d code should have a comment block on when and why it was > removed and what must be done to re-incorporate it and if someone is working > on it, a name and durable contact information. Also, an anticpated > completion date, if known, should be entered. Reliance on a particular > release is not sufficient. Isn't that what `git blame' is for? Extra comments can go in the commit that introduces the if (0). Octavian

June 5, 2010

Advice about a new project, and similarity to Wine's start

by Alessandro Pignotti

Hi everyone, first of all congratulations. The current maturity of Wine is really, really impressive. Thanks for your work. Let's introduce myself, I'm the author of the Lightspark project (http://lightspark.sf.net) a modern, open source, flash player implementation. The project is currently in a very good shape, featuring scripting support, a JIT compiler and OpenGL accelerated rendering. But, although the core VM is mostly complete, a huge part of the runtime library is still missing. I'm asking advice here because this is probably a condition similar to the one faced by early Wine developers. I'm currently pretty confused about the roadmap of my project. Although some interest gathered after the announcement of the 0.3.0 release and some bug reports appeared I've not yet managed to gather the needed community feedback. Moreover, beside supporting the most popular flash applications (e.g. YouTube, which is mostly supported), I've no idea about what to do later and how to prioritize features. So my question is: how did Wine choose the feature set to support first? Did people use the early releases of Wine, even if they were missing features? Is the AppDB software available for use on other projects? Any misc advice? Thanks a lot for your help. and sorry for the quite OT message, Alessandro Pignotti

June 5, 2010

Re: Wine code comments

by James McKenzie

Frédéric Delanoy wrote: > On Sat, Jun 5, 2010 at 05:38, James McKenzie > <jjmckenzie51(a)earthlink.net <mailto:jjmckenzie51(a)earthlink.net>> wrote: > > John Voltz wrote: > > Hi everyone, > > I have a question about comments in the Wine code. I noticed while > tracking down a bug that a lot of the code comments are using the > block comment marker /*. This is a royal pain when trying to > comment > out large sections of code where there are a bunch of /* foo */ > comments. Why is this allowed? Is there are way around it without > having to change them all to //? > > > Simple answer: We use 'c' comment convention because some > compilers choke on the C++ style. > > You could use #if (0) and should use this to mark out possible > locations for buggy code as it was noted elsewhere. Using /* and > */ is not good coding practice to comment out code. > > James McKenzie > > > > (E. Hoover) > >Particularly, the section entitled "Avoid C++, C99 and non-portable C > >constructs." > > Actually, aside from debugging functions, and stuff in headers files, > "if (0)" would be more portable than "#if 0", with the additional > advantage that it leads to less code rot, since obsolete code tends to > be deleted earlier, and not simply forgotten. > > Besides, it shouldn't incur any runtime penalty, since "if (0)" blocks > are typically discarded at compile time. > If that works better, then use it. The OP was trying to block out sections of code that were causing problems to attempt isolate and then fix them. Some problems are introduced just because the API code is incomplete and needs a little 'filling out' with properly designed and engineered code. This cannot be iffed out. > What do you think about it? > Also if (0)'d code should have a comment block on when and why it was removed and what must be done to re-incorporate it and if someone is working on it, a name and durable contact information. Also, an anticpated completion date, if known, should be entered. Reliance on a particular release is not sufficient. James McKenzie

June 5, 2010

Re: [PATCH 1/3] shlwapi: Be less strict on which type of IShellFolder can be enumerated

by Andrew Eikum

> On 6/5/2010 19:09, Andrew Eikum wrote: >> I'm not sure I follow. As the tests in the patch show, QI is called up >> to >> two times, once for IPersist and once for IPersistFolder if the first >> fails. I can certainly add tests for returning different CLSIDs, though >> that seems uninteresting to me since they all behave identically. >> > I mean, create different types of shellfolders, then test that function > accepts them all. And a simple check that QI isn't called for > IShellFolder, so > argument expected to be IShellFolder pointer. Argh, webmail clients are frustrating. Here's the patch.

June 5, 2010

Re: [PATCH 1/3] shlwapi: Be less strict on which type of IShellFolder can be enumerated

by Andrew Eikum

> On 6/5/2010 19:09, Andrew Eikum wrote: >> I'm not sure I follow. As the tests in the patch show, QI is called up >> to >> two times, once for IPersist and once for IPersistFolder if the first >> fails. I can certainly add tests for returning different CLSIDs, though >> that seems uninteresting to me since they all behave identically. >> > I mean, create different types of shellfolders, then test that function > accepts them all. And a simple check that QI isn't called for > IShellFolder, so > argument expected to be IShellFolder pointer. Something like this, then?

June 5, 2010

Re: [PATCH 1/3] shlwapi: Be less strict on which type of IShellFolder can be enumerated

by Nikolay Sivov

On 6/5/2010 19:09, Andrew Eikum wrote: >>> Trouble is, I have no idea what it is used for. I tried testing most >>> of the CLSIDs in shlguid.h with different combinations of flags, none >>> of which had any effect. It must just be looking out for a small >>> number of specific CLSIDs. One possible guess is that it tweaks the >>> flags parameter when certain CLSIDs are detected, but none of my tests >>> turned up anything interesting. >>> >>> Any thoughts? Should I just send as-is? >>> >> So it doesn't care about classid returned from IPersist. I think it's >> enough now to add tests for not-called QI for IShellFolder and a test >> for a bunch of known CLSIDs for folders. After that (if you dummy CLSID >> is allowed too) probably it's ok to remove all checks. >> > I'm not sure I follow. As the tests in the patch show, QI is called up to > two times, once for IPersist and once for IPersistFolder if the first > fails. I can certainly add tests for returning different CLSIDs, though > that seems uninteresting to me since they all behave identically. > I mean, create different types of shellfolders, then test that function accepts them all. And a simple check that QI isn't called for IShellFolder, so argument expected to be IShellFolder pointer. > Removing the code in shlwapi.404 will lead to test failures since Windows > _does_ make QI and GetClassID calls, it's just unknown what it does with > the data it gets. > > What do you think? Remove the tests? Add todo_wine and remove the > 'dummy' code in shlwapi.404? > Remove tests and add a note in function code that this GetClassID method is actually called for unknown purpose. Another way is to make is accept another CLSID, if I got it right it is why you started to patch it. > Thanks for your feedback, > Andrew > >

June 5, 2010

Re: [PATCH 1/3] shlwapi: Be less strict on which type of IShellFolder can be enumerated

by Andrew Eikum

> On 6/4/2010 22:13, Andrew Eikum wrote: >> On 06/03/2010 03:47 PM, Andrew Eikum wrote: >> So, with this in mind, here are some much more extensive tests. As is >> explained in the comment, Windows _does_ get the ClassID of the object >> in this call. But, Windows crashes when a non-IShellFolder object is >> given to this function. Presumably it's trying to call >> IShellFolder_EnumObjects on it. So it must not be using the CLSID for >> this kind of type-checking. > And if pointer doesn't support IPersist does it crash too? Yes. The test where QueryInterface_fail is TRUE tests this condition. It always returns E_NOINTERFACE in QI, yet EnumObjects is still called. >> Trouble is, I have no idea what it is used for. I tried testing most >> of the CLSIDs in shlguid.h with different combinations of flags, none >> of which had any effect. It must just be looking out for a small >> number of specific CLSIDs. One possible guess is that it tweaks the >> flags parameter when certain CLSIDs are detected, but none of my tests >> turned up anything interesting. >> >> Any thoughts? Should I just send as-is? > So it doesn't care about classid returned from IPersist. I think it's > enough now to add tests for not-called QI for IShellFolder and a test > for a bunch of known CLSIDs for folders. After that (if you dummy CLSID > is allowed too) probably it's ok to remove all checks. I'm not sure I follow. As the tests in the patch show, QI is called up to two times, once for IPersist and once for IPersistFolder if the first fails. I can certainly add tests for returning different CLSIDs, though that seems uninteresting to me since they all behave identically. Removing the code in shlwapi.404 will lead to test failures since Windows _does_ make QI and GetClassID calls, it's just unknown what it does with the data it gets. What do you think? Remove the tests? Add todo_wine and remove the 'dummy' code in shlwapi.404? Thanks for your feedback, Andrew

June 5, 2010

Re: [PATCH 1/3] shlwapi: Be less strict on which type of IShellFolder can be enumerated

by Nikolay Sivov

On 6/4/2010 22:13, Andrew Eikum wrote: > On 06/03/2010 03:47 PM, Andrew Eikum wrote: >> On 06/03/2010 03:12 PM, Nikolay Sivov wrote: >>> No, this is not what I meant actually. The possible reason it was named >>> as IUnknown_EnumObjects is the same as for the rest of similar calls. >>> IUknown is a valid input for all of them and another _QueryInterface is >>> performed for IID_IShellFolder is case of this function. That makes no >>> sense to have such export as your patch makes it, but it's possible of >>> course. I expect that is does check that IShellFolder is supported. >> >> Okay, I see what you're saying now. I hadn't thought of that. After some >> quick tests, I think you're on the right path. I'll work on fixing it. >> Thanks! >> > > So, with this in mind, here are some much more extensive tests. As is > explained in the comment, Windows _does_ get the ClassID of the object > in this call. But, Windows crashes when a non-IShellFolder object is > given to this function. Presumably it's trying to call > IShellFolder_EnumObjects on it. So it must not be using the CLSID for > this kind of type-checking. And if pointer doesn't support IPersist does it crash too? > > Trouble is, I have no idea what it is used for. I tried testing most > of the CLSIDs in shlguid.h with different combinations of flags, none > of which had any effect. It must just be looking out for a small > number of specific CLSIDs. One possible guess is that it tweaks the > flags parameter when certain CLSIDs are detected, but none of my tests > turned up anything interesting. > > Any thoughts? Should I just send as-is? So it doesn't care about classid returned from IPersist. I think it's enough now to add tests for not-called QI for IShellFolder and a test for a bunch of known CLSIDs for folders. After that (if you dummy CLSID is allowed too) probably it's ok to remove all checks. > > Andrew

June 5, 2010

Re: shdoclc: Add the Polish translation

by Paul Vriens

On 06/04/2010 04:33 PM, Łukasz Wojniłowicz wrote: > + > +LANGUAGE LANG_POLISH, SUBLANG_NEUTRAL > + > +IDR_BROWSE_CONTEXT_MENU MENU Hi Łukasz, Sorry if I wasn't clearer before. You are having effectively two blocks with the same translations now. The reason the English resource file has two blocks is because it has effectively two translations (one for SUBLANG_DEFAULT and one for SUBLANG_NEUTRAL). There is no need to do that in most of the other resource files like Polish as there is only one Polish language (as far as resource files are concerned). Could you also add something to the Subject when resending? So for example "(Resend)" when sending the same patch again or "(Try x)" when you sent a new version of the patch. -- Cheers, Paul.

June 5, 2010

Wine on MIPS?

by André Hentschel

Hi, i just read that MIPS is planning to get on the mobil market. It will be available in 4G Smartphones with Android. Wine has a MIPS port which should also run those obsolete Win32 MIPS Apps, so i guess the winelib side is more interesting. So here my question: did anyone recently tried to compile Wine on MIPS and did it worked? If not, is anybody able to? -- Best Regards, André Hentschel

June 5, 2010

Re: Wine code comments

by Frédéric Delanoy

On Sat, Jun 5, 2010 at 05:38, James McKenzie <jjmckenzie51(a)earthlink.net>wrote: > John Voltz wrote: > >> Hi everyone, >> >> I have a question about comments in the Wine code. I noticed while >> tracking down a bug that a lot of the code comments are using the >> block comment marker /*. This is a royal pain when trying to comment >> out large sections of code where there are a bunch of /* foo */ >> comments. Why is this allowed? Is there are way around it without >> having to change them all to //? >> >> > Simple answer: We use 'c' comment convention because some compilers choke > on the C++ style. > > You could use #if (0) and should use this to mark out possible locations > for buggy code as it was noted elsewhere. Using /* and */ is not good > coding practice to comment out code. > > James McKenzie > > (E. Hoover) >Particularly, the section entitled "Avoid C++, C99 and non-portable C >constructs." Actually, aside from debugging functions, and stuff in headers files, "if (0)" would be more portable than "#if 0", with the additional advantage that it leads to less code rot, since obsolete code tends to be deleted earlier, and not simply forgotten. Besides, it shouldn't incur any runtime penalty, since "if (0)" blocks are typically discarded at compile time. What do you think about it? Frédéric

June 5, 2010

Re: Wine code comments

by James McKenzie

John Voltz wrote: > Hi everyone, > > I have a question about comments in the Wine code. I noticed while > tracking down a bug that a lot of the code comments are using the > block comment marker /*. This is a royal pain when trying to comment > out large sections of code where there are a bunch of /* foo */ > comments. Why is this allowed? Is there are way around it without > having to change them all to //? > Simple answer: We use 'c' comment convention because some compilers choke on the C++ style. You could use #if (0) and should use this to mark out possible locations for buggy code as it was noted elsewhere. Using /* and */ is not good coding practice to comment out code. James McKenzie

June 5, 2010

Re: Wine code comments

by Andrew Nguyen

On Fri, Jun 4, 2010 at 3:35 PM, John Voltz <john.voltz(a)gmail.com> wrote: > Is there are way around it without having to change them all to //? > For private, ad-hoc use, you could possibly use a preprocessor #if 0 block to achieve the desired comment effect.

June 5, 2010

Re: Wine code comments

by Erich Hoover

On Fri, Jun 4, 2010 at 2:35 PM, John Voltz <john.voltz(a)gmail.com> wrote: > ... > I have a question about comments in the Wine code. I noticed while > tracking down a bug that a lot of the code comments are using the > block comment marker /*. > ... See the wiki page on patches: http://wiki.winehq.org/SubmittingPatches Particularly, the section entitled "Avoid C++, C99 and non-portable C constructs." Erich Hoover ehoover(a)mines.edu

June 5, 2010

xrender.c is does not find fontconfig.h on OS X Tiger

by Mike Kronenberg

Dear List OS X Tiger does has not have fontconfig, so I'm building it in ~/buildwine/usr to keep it out of /usr. I include the headers and libs from ~/buildwine/usr with CPPFLAGS and CFLAGS. This worked fine until 1.2-rc1 and 1.2-rc2. Compiling xrender.c now exits with an error that FC_WEIGHT_THIN etc is not defined. configure leaves me with SONAME_LIBFONTCONFIG='libfontconfig.1.dylib' FONTCONFIGINCL='' in the config.log. No luck even if I export FONTCONFIGINCL="-I//$HOME/buildwine/usr/include/fontconfig -I//$HOME/buildwine/usr/include' which resulted in a correct FONTCONFIGINCL, but the compiling still failed. All the other custom compiled deps are working as usual. Any hint what I might missing? txs Mike

June 4, 2010

Wine code comments

by John Voltz

Hi everyone, I have a question about comments in the Wine code. I noticed while tracking down a bug that a lot of the code comments are using the block comment marker /*. This is a royal pain when trying to comment out large sections of code where there are a bunch of /* foo */ comments. Why is this allowed? Is there are way around it without having to change them all to //? Regards, John Voltz

June 4, 2010

Re: [PATCH 1/3] shlwapi: Be less strict on which type of IShellFolder can be enumerated

by Andrew Eikum

On 06/03/2010 03:47 PM, Andrew Eikum wrote: > On 06/03/2010 03:12 PM, Nikolay Sivov wrote: >> No, this is not what I meant actually. The possible reason it was named >> as IUnknown_EnumObjects is the same as for the rest of similar calls. >> IUknown is a valid input for all of them and another _QueryInterface is >> performed for IID_IShellFolder is case of this function. That makes no >> sense to have such export as your patch makes it, but it's possible of >> course. I expect that is does check that IShellFolder is supported. > > Okay, I see what you're saying now. I hadn't thought of that. After some > quick tests, I think you're on the right path. I'll work on fixing it. > Thanks! > So, with this in mind, here are some much more extensive tests. As is explained in the comment, Windows _does_ get the ClassID of the object in this call. But, Windows crashes when a non-IShellFolder object is given to this function. Presumably it's trying to call IShellFolder_EnumObjects on it. So it must not be using the CLSID for this kind of type-checking. Trouble is, I have no idea what it is used for. I tried testing most of the CLSIDs in shlguid.h with different combinations of flags, none of which had any effect. It must just be looking out for a small number of specific CLSIDs. One possible guess is that it tweaks the flags parameter when certain CLSIDs are detected, but none of my tests turned up anything interesting. Any thoughts? Should I just send as-is? Andrew

June 4, 2010

Re: [1/2]wineps.drv: make use of MAKEINTRESOURCEW

by Dmitry Timoshkov

André Hentschel <nerv(a)dawncrow.de> wrote: > +#define PAPER 99 > #define IDD_PAPERS 100 > #define IDD_ORIENT_PORTRAIT 101 > #define IDD_ORIENT_LANDSCAPE 102 You could try to find a less generic name for this. -- Dmitry.

June 4, 2010

Re: [2/2]wineps.drv: Import comctl32 instead of loading it

by Dmitry Timoshkov

André Hentschel <nerv(a)dawncrow.de> wrote: > -IMPORTS = user32 gdi32 winspool advapi32 kernel32 > +IMPORTS = user32 gdi32 winspool advapi32 kernel32 comctl32 It's being loaded for a reason. You can make it delay loaded though. -- Dmitry.

June 4, 2010

Re: [PATCH] msi/tests: Fix install tests for Win9x

by testbot＠testbot.winehq.org

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=2470 Your paranoid android. === WNT4WSSP6 (32 bit install) === Timeout === W7PROX64 (32 bit install) === install.c:5411: Test failed: Expected "C:\Program Files (x86)\msitest\maximus", got "Software\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\84A88FD7F6998CE40A22FB59F6B9C2BB\InstallProperties" install.c:5430: Test failed: Expected "01\msitest\augustus", got "Software\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\84A88FD7F6998CE40A22FB59F6B9C2BB\InstallProperties" install.c:5455: Test failed: Expected "C:\Program Files (x86)\msitest\maximus", got "Software\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\84A88FD7F6998CE40A22FB59F6B9C2BB\InstallProperties" install.c:5474: Test failed: Expected "01\msitest\augustus", got "Software\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\84A88FD7F6998CE40A22FB59F6B9C2BB\InstallProperties" === W7PROX64 (64 bit install) === install.c:3534: Test failed: Expected 314, got 1 install.c:8264: Test failed: RegQueryValueExA failed 2 (0)

June 4, 2010

Re: shdoclc: Add the Polish translation

by Paul Vriens

On 06/04/2010 01:05 PM, Łukasz Wojniłowicz wrote: > + > +LANGUAGE LANG_ENGLISH, SUBLANG_NEUTRAL This doesn't look correct for Polish ;) -- Cheers, Paul.

June 4, 2010

Re: appwiz: Add the Polish translation

by Paul Vriens

On 06/04/2010 01:05 PM, Łukasz Wojniłowicz wrote: > dlls/appwiz.cpl/Makefile.in | 1 + > dlls/appwiz.cpl/Pl.rc | 84 +++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 85 insertions(+), 0 deletions(-) > create mode 100755 dlls/appwiz.cpl/Pl.rc Hi Łukasz, Wrong mode here. Should be the normal 100644 (like you other recent patches). -- Cheers, Paul.

June 4, 2010

Re: [PATCH 2/2] cmd: Update Dutch translation

by Sven Baars

Hello Frédéric, Frédéric Delanoy wrote: > 2010/6/2 Sven Baars <sven.wine(a)gmail.com <mailto:sven.wine(a)gmail.com>> > > --- > programs/cmd/Nl.rc | 194 > ++++++++++++++++++++++++++++----------------------- > 1 files changed, 106 insertions(+), 88 deletions(-) > > > Hi Sven, > > Some remarks: > - You shouldn't change the line length as it makes the patch > unnecessarily big, for no change in text (for the affected hunks)\ I changed the line length, to be more consistent with the English translation. As it was done before, you just had the same words on a line as in English, but since Dutch usually needs more words than English, the lines didn't fit on a standard terminal. Now it's more-or-less in sync with the line length of the English translation, which is in my opinion a good thing. > - "bestaat keert de controle terug naar het bestand dat het aanriep. > DE CALL\n\" => "DE" should be "De" > Thanks. I'll resend. > Frédéric > Sven

June 4, 2010

Re: [RFC] advapi32 -- GetNamedSecurityInfo

by Austin English

On Thu, Jun 3, 2010 at 7:57 AM, GOUJON Alexandre <ale.goujon(a)gmail.com> wrote: > Hi, > > I'm trying to fix bug 18071 but I don't know anything about ACLs. > I wrote some tests (see attached patch and > https://testbot.winehq.org/JobDetails.pl?Key=2442) > and I modified the source according to my understanding of the issue (wich > may be totally wrong). When testing LastError, you need to set it first to a known value, to ensure that the test is really resetting LastError. Most tests use SetLastError(0xdeadbeef); to do this. -- -Austin

June 4, 2010

Re: CUDA Wrapper err:module:import_dl

by James McKenzie

Seth Shelnutt wrote: > |Alright, I'm stumped and everyone else is too. Few years ago we did > everything we are doing now and it all worked fine. Now using wine > 1.2rc2 we can't get a wrapper I compiled to work. What this wrapper > does is it translates/wraps the calls made to the cuda runtime dll > (cudart.dll or nvcuda.dll, same file different names) and sends it to > the linux library. The linux library and windows are identical except > for some missing dx functions in the linux library. My sources can be > found here. http://shelnutt2.host56.com/cudart/ and > http://shelnutt2.host56.com/cufft/ (However we aren't even getting to > the second dll yet). Anytime we try to run folding at home in wine, we > are getting the following. FAH checks for nvcuda.dll first because > that comes with the driver installs on windows, if it doesn't find it, > it defaults to cudart.dll which is packaged with fah, or can be > installed separately. We have replaced all the cuda dlls with the > compiled wrapper or sum linked to the compiled wrapper, just like we > use to with the original cuda wrapper that we came up with. > > > err:module:import_dll Loading library nvcuda.dll (which is needed by > L"Z:\\home\\sidicas\\.FAHGPU3\\FahCore_11.exe") failed (error c0000020). > err:module:import_dll Loading library cudart.dll (which is needed by > L"Z:\\home\\sidicas\\.FAHGPU3\\FahCore_11.exe") failed (error c0000020). > > > | > > |sidicas(a)Belldandy:~/.FAHGPU3$ ls -al *.dll > -rw-r--r-- 1 sidicas sidicas 1617920 2010-06-03 01:48 amdcalcl.dll > -rw-r--r-- 1 sidicas sidicas 2486272 2010-06-03 01:48 amdcalrt.dll > -rw-r--r-- 1 sidicas sidicas 124540 2010-06-02 07:50 > cudart32_30_14.dll > -rw-r--r-- 1 sidicas sidicas 124540 2010-06-02 07:50 cudart.dll > -rw-r--r-- 1 sidicas sidicas 82699 2010-06-01 21:39 > cufft32_30_14.dll > -rw-r--r-- 1 sidicas sidicas 82699 2010-06-01 21:39 cufft.dll > lrwxrwxrwx 1 sidicas sidicas 10 2010-06-03 02:12 nvcuda.dll > -> cudart.dll > sidicas(a)Belldandy:~/.FAHGPU3$ | > > > |sidicas(a)Belldandy:~/.FAHGPU3$ uname -a > Linux Belldandy 2.6.26-2-amd64 #1 SMP Sun Jun 21 04:47:08 UTC 2009 > x86_64 GNU/Linux > sidicas(a)Belldandy:~/.FAHGPU3$ nvcc --version > nvcc: NVIDIA (R) Cuda compiler driver > Copyright (c) 2005-2009 NVIDIA Corporation > Built on Fri_Feb_19_18:18:31_PST_2010 > Cuda compilation tools, release 3.0, V0.2.1221 > sidicas(a)Belldandy:~/.FAHGPU3$ ldd ./cudart.dll > linux-gate.so.1 => (0xf7ee3000) > libcudart.so.3 => /usr/local/cuda/lib/libcudart.so.3 > (0xf7e83000) > libwine.so.1 => /usr/lib/libwine.so.1 (0xf7d2d000) > libm.so.6 => /lib32/libm.so.6 (0xf7d09000) > libc.so.6 => /lib32/libc.so.6 (0xf7bb6000) > libdl.so.2 => /lib32/libdl.so.2 (0xf7bb2000) > libpthread.so.0 => /lib32/libpthread.so.0 (0xf7b9b000) > librt.so.1 => /lib32/librt.so.1 (0xf7b92000) > libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf7aa4000) > libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf7a97000) > /lib/ld-linux.so.2 (0xf7ee4000) > sidicas(a)Belldandy:~/.FAHGPU3$ > sidicas(a)Belldandy:~/.FAHGPU3$ ldd ./cufft.dll > linux-gate.so.1 => (0xf7f29000) > libcufft.so.3 => /usr/local/cuda/lib/libcufft.so.3 > (0xf7308000) > libwine.so.1 => /usr/lib/libwine.so.1 (0xf71b2000) > libm.so.6 => /lib32/libm.so.6 (0xf718e000) > libc.so.6 => /lib32/libc.so.6 (0xf703b000) > libdl.so.2 => /lib32/libdl.so.2 (0xf7037000) > libpthread.so.0 => /lib32/libpthread.so.0 (0xf7020000) > libcudart.so.3 => /usr/local/cuda/lib/libcudart.so.3 > (0xf6fdf000) > libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf6ef1000) > libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf6ee4000) > /lib/ld-linux.so.2 (0xf7f2a000) > librt.so.1 => /lib32/librt.so.1 (0xf6eda000) > sidicas(a)Belldandy:~/.FAHGPU3$ > sidicas(a)Belldandy:~/.FAHGPU3$ > | > > > More thorugh testing has been done, > http://foldingforum.org/viewtopic.php?f=54&t=14673&start=105#p146177 > <http://foldingforum.org/viewtopic.php?f=54&t=14673&start=105#p146177> > . When we makes reference to gpu2 wrapper, that is our original cuda > wrapper designed for cuda 2.0-2.2 built couple years ago. The GPU3 > wrapper is what we are having problems with. It is our cuda 3.0 > wrapper. The .dll files are in the folder (we even tried in system32), > ldd shows they are properly linked, yet it does not work. If we use > the old wrapper compile before it works fine with cuda 2.x or with > cuda 3.0 we just have to sym link the cuda lib to the old name it's > expecting. > > I've tried compiling the old wrapper and linking it to cuda 2.3 > however this fails. So I am thinking that if when I compile the old > wrapper which is shown to work (when an old compiled version is used) > but does not work when I compile on my funtoo box it must be some > weird compiling issue. I have wine installed (without 64bit support), > and I installed cuda runtime from nvidia's site as the one in portage > installs to /opt/ and I wanted to make sure there wasn't any weird > issues linking with that. > > I do get a few warnings when I compile but they aren't anything that > would effect this. > > s.shelnutt(a)funtoo-64 ~/gpu3/wrapper/cudart $ make > winegcc -c -mno-cygwin -m32 -I/usr/local/cuda/include/ -o cudart.o > cudart.c > In file included from /usr/local/cuda/include/cuda_runtime_api.h:53, > from /usr/local/cuda/include/crt/host_runtime.h:108, > from cudart.c:7: > /usr/local/cuda/include/host_defines.h:57:1: warning: "__cdecl" redefined > <command-line>: warning: this is the location of the previous definition > cudart.c: In function 'wine_cudaGetTextureReference': > cudart.c:430: warning: passing argument 1 of 'cudaGetTextureReference' > from incompatible pointer type > /usr/local/cuda/include/cuda_runtime_api.h:189: note: expected 'const > struct textureReference **' but argument is of type 'struct > textureReference **' > cudart.c: In function 'wine_cudaRegisterFatBinary': > cudart.c:800: warning: return makes pointer from integer without a cast > cudart.c: In function 'wine_cudaUnregisterFatBinary': > cudart.c:805: warning: 'return' with a value, in function returning void > cudart.c: In function 'wine_cudaRegisterVar': > cudart.c:810: warning: 'return' with a value, in function returning void > cudart.c: In function 'wine_cudaRegisterTexture': > cudart.c:815: warning: 'return' with a value, in function returning void > cudart.c: In function 'wine_cudaRegisterShared': > cudart.c:820: warning: 'return' with a value, in function returning void > cudart.c: In function 'wine_cudaRegisterSharedVar': > cudart.c:825: warning: 'return' with a value, in function returning void > cudart.c: In function 'wine_cudaRegisterFunction': > cudart.c:831: warning: 'return' with a value, in function returning void > winegcc -shared cudart.dll.spec -mno-cygwin -o cudart.dll.so > <http://cudart.dll.so> cudart.o -L/usr/local/cuda/lib/ -lcudart > -lodbc32 -lole32 -loleaut32 -lwinspool -lodbccp32 -luuid > > > If anyone has any ideas about why this doesn't work, that would be > great. I've exhausted everything I could think of. > Seth: Does this work with Wine-1.0.1? If so, we have a regression... You could run a mostly lengthy regression test and find the culprit if it is. James McKenzie

June 4, 2010

Re: advapi32: Fix GetSecurityInfo with NULL descriptor

by testbot＠testbot.winehq.org

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=2467 Your paranoid android. === WNT4WSSP6 (32 bit security) === No test summary line found

June 4, 2010

Re: advapi32: Fix GetSecurityInfo with NULL descriptor (try2:typo)

by testbot＠testbot.winehq.org

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=2466 Your paranoid android. === WNT4WSSP6 (32 bit security) === No test summary line found

June 4, 2010

Re: [PATCH 3/3] shlwapi: Implement SHSetIniStringW

by testbot＠testbot.winehq.org

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=2454 Your paranoid android. === W2KPROSP4 (32 bit ordinal) === ordinal.c:604: Test failed: GetShellSecurityDescriptor should fail ordinal.c:627: Test failed: returned value is not valid SD No test summary line found === W7PRO (32 bit ordinal) === ordinal.c:1770: Test failed: got 13 ordinal.c:1776: Test failed: got 27 ordinal.c:1791: Test failed: got 10 ordinal.c:1804: Test failed: got 13 ordinal.c:1812: Test failed: got 13 ordinal.c:1826: Test failed: got 27 ordinal.c:1834: Test failed: got 27 ordinal.c:1864: Test failed: got 22 ordinal.c:1875: Test failed: got 25 === W7PROX64 (32 bit ordinal) === ordinal.c:1776: Test failed: got 25 ordinal.c:1826: Test failed: got 25 ordinal.c:1834: Test failed: got 25 ordinal.c:1842: Test failed: got 34, length 35 ordinal.c:1853: Test failed: got 37 === W7PROX64 (64 bit ordinal) === ordinal.c:1776: Test failed: got 25 ordinal.c:1826: Test failed: got 25 ordinal.c:1834: Test failed: got 25 ordinal.c:1842: Test failed: got 34, length 35 ordinal.c:1853: Test failed: got 37

June 3, 2010

Re: [PATCH 1/3] shlwapi: Be less strict on which type of IShellFolder can be enumerated

by Andrew Eikum

On 06/03/2010 03:12 PM, Nikolay Sivov wrote: > No, this is not what I meant actually. The possible reason it was named > as IUnknown_EnumObjects is the same as for the rest of similar calls. > IUknown is a valid input for all of them and another _QueryInterface is > performed for IID_IShellFolder is case of this function. That makes no > sense to have such export as your patch makes it, but it's possible of > course. I expect that is does check that IShellFolder is supported. Okay, I see what you're saying now. I hadn't thought of that. After some quick tests, I think you're on the right path. I'll work on fixing it. Thanks! Andrew

June 3, 2010

Re: [PATCH 2/3] shlwapi: Implement SHGetIniStringW

by testbot＠testbot.winehq.org

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=2453 Your paranoid android. === W2KPROSP4 (32 bit ordinal) === ordinal.c:603: Test failed: GetShellSecurityDescriptor should fail ordinal.c:626: Test failed: returned value is not valid SD No test summary line found === W7PRO (32 bit ordinal) === ordinal.c:1769: Test failed: got 13 ordinal.c:1775: Test failed: got 27 ordinal.c:1790: Test failed: got 10 ordinal.c:1803: Test failed: got 13 ordinal.c:1811: Test failed: got 13 ordinal.c:1825: Test failed: got 27 ordinal.c:1833: Test failed: got 27 ordinal.c:1863: Test failed: got 22 ordinal.c:1874: Test failed: got 25 === W7PROX64 (32 bit ordinal) === ordinal.c:1775: Test failed: got 25 ordinal.c:1825: Test failed: got 25 ordinal.c:1833: Test failed: got 25 ordinal.c:1841: Test failed: got 34, length 35 ordinal.c:1852: Test failed: got 37 === W7PROX64 (64 bit ordinal) === ordinal.c:1775: Test failed: got 25 ordinal.c:1825: Test failed: got 25 ordinal.c:1833: Test failed: got 25 ordinal.c:1841: Test failed: got 34, length 35 ordinal.c:1852: Test failed: got 37

June 3, 2010

Re: [PATCH 1/3] shlwapi: Be less strict on which type of IShellFolder can be enumerated

by Nikolay Sivov

On 6/4/2010 00:00, Andrew Eikum wrote: > On 06/03/2010 02:40 PM, Nikolay Sivov wrote: >> On 6/3/2010 23:35, Andrew Eikum wrote: >>> >>> This fixes a bug with Internet Explorer 6's Favorites menu. >>> >>> This function used to be named IUnknown_EnumObjects, so my guess is >>> that the original implementor thought it'd be wise to verify the type >>> of the object before executing IShellFolder's methods on it. Since >>> it's now called IShellFolder_EnumObjects and explicitly takes an >>> LPSHELLFOLDER parameter, I see no reason to do the typecheck. >> And where is a test for that? > > In the patch. The object returned by SHGetDesktopFolder does not have > CLSID_ShellFSFolder, yet it does not fail in the shlwapi EnumObjects > call. Running the test with and without the functionality change > shows this. > > I guess I could go try to dig up some IShellFolder instance which > succeeds a plain IShellFolder_EnumObjects call and fails a shlwapi > EnumObjects call, but I wouldn't even know where to start for that. > If the old functionality was required, it needs a test or at least a > comment. As far as current knoweldge goes, it's both simpler and more > correct with this patch than it was without. No, this is not what I meant actually. The possible reason it was named as IUnknown_EnumObjects is the same as for the rest of similar calls. IUknown is a valid input for all of them and another _QueryInterface is performed for IID_IShellFolder is case of this function. That makes no sense to have such export as your patch makes it, but it's possible of course. I expect that is does check that IShellFolder is supported. > > Andrew

June 3, 2010

Re: New Wine stuff in FreeWear.org

by André Hentschel

Am 03.06.2010 13:21, schrieb Ismael Barros²: > Hello, > > We have decided to renew our offer of Wine T-shirts, as the current > T-shirt has had mostly no success at all, probably because users don't > feel identified nor appealed with the design. I'm attaching the pdf > with our new proposals (we hope you like them!). We decided to offer > the design in black garment, as in our experience it works much > better. > > We want to be transparent, so I'm attaching also a spreadsheet with > our expenses, donations and profits for each model. > > We usually collaborate with FOSS events, sending them stuff from our > catalogue for its sale on the event. In these cases, we make a double > donation: one to the organization of the event (higher, as they are in > charge of the sales) and another one to the corresponding FOSS > organization for the sold article. You can see the details in the > spreadsheet. If you have no objection, we'll send Wine stuff to the > event that require it. > > Currently, almost all organizations we work with have us linked from > their website. This helps boosting the sales, and therefore the > donations, so that everybody wins. We would be very glad if we could > get a link somewhere at winehq.org, or alternatively a news item, > which for us has the downside of having a limited front-page > life-span, but works nonetheless. > > We hope you like and approve the design. Suggestions are welcome. When > the design is approved, we'll upload it to our website. > > Kind regards, > Ismael > Hi, i like that one more than the actually available one. Specially the T-Shirt is really cool with the big image on the front. I think i will buy it. -- Best Regards, André Hentschel

June 3, 2010

Re: [PATCH 1/3] shlwapi: Be less strict on which type of IShellFolder can be enumerated

by Andrew Eikum

On 06/03/2010 02:40 PM, Nikolay Sivov wrote: > On 6/3/2010 23:35, Andrew Eikum wrote: >> >> This fixes a bug with Internet Explorer 6's Favorites menu. >> >> This function used to be named IUnknown_EnumObjects, so my guess is >> that the original implementor thought it'd be wise to verify the type >> of the object before executing IShellFolder's methods on it. Since >> it's now called IShellFolder_EnumObjects and explicitly takes an >> LPSHELLFOLDER parameter, I see no reason to do the typecheck. > And where is a test for that? In the patch. The object returned by SHGetDesktopFolder does not have CLSID_ShellFSFolder, yet it does not fail in the shlwapi EnumObjects call. Running the test with and without the functionality change shows this. I guess I could go try to dig up some IShellFolder instance which succeeds a plain IShellFolder_EnumObjects call and fails a shlwapi EnumObjects call, but I wouldn't even know where to start for that. If the old functionality was required, it needs a test or at least a comment. As far as current knoweldge goes, it's both simpler and more correct with this patch than it was without. Andrew

June 3, 2010

Re: [PATCH 1/3] shlwapi: Be less strict on which type of IShellFolder can be enumerated

by testbot＠testbot.winehq.org

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=2452 Your paranoid android. === W2KPROSP4 (32 bit ordinal) === ordinal.c:595: Test failed: GetShellSecurityDescriptor should fail ordinal.c:618: Test failed: returned value is not valid SD No test summary line found === W7PRO (32 bit ordinal) === ordinal.c:1767: Test failed: got 27 ordinal.c:1817: Test failed: got 27 ordinal.c:1825: Test failed: got 27 ordinal.c:1833: Test failed: got 38, length 39 ordinal.c:1844: Test failed: got 41 === W7PROX64 (32 bit ordinal) === ordinal.c:1767: Test failed: got 25 ordinal.c:1817: Test failed: got 25 ordinal.c:1825: Test failed: got 25 ordinal.c:1833: Test failed: got 34, length 35 ordinal.c:1844: Test failed: got 37 === W7PROX64 (64 bit ordinal) === ordinal.c:1767: Test failed: got 25 ordinal.c:1817: Test failed: got 25 ordinal.c:1825: Test failed: got 25 ordinal.c:1833: Test failed: got 34, length 35 ordinal.c:1844: Test failed: got 37

June 3, 2010

Re: [PATCH 1/3] shlwapi: Be less strict on which type of IShellFolder can be enumerated

by Nikolay Sivov

On 6/3/2010 23:35, Andrew Eikum wrote: > > This fixes a bug with Internet Explorer 6's Favorites menu. > > This function used to be named IUnknown_EnumObjects, so my guess is > that the original implementor thought it'd be wise to verify the type > of the object before executing IShellFolder's methods on it. Since > it's now called IShellFolder_EnumObjects and explicitly takes an > LPSHELLFOLDER parameter, I see no reason to do the typecheck. And where is a test for that? > > --- > dlls/shlwapi/ordinal.c | 19 +------------------ > dlls/shlwapi/tests/Makefile.in | 2 +- > dlls/shlwapi/tests/ordinal.c | 32 ++++++++++++++++++++++++++++++++ > 3 files changed, 34 insertions(+), 19 deletions(-)

June 3, 2010

Re: Fully translate partially translated modules in Polish

by Jacek Caban

Hi Łukasz, Great work, but it needs some polishing:-) First of all, please split the patch to the series of smaller patches, preferably one per module. On 6/3/10 11:51 AM, Łukasz Wojniłowicz wrote: > --- > dlls/mshtml/Pl.rc | 18 +- > dlls/setupapi/Pl.rc | 23 + > dlls/shell32/shell32_Pl.rc | 25 +- > dlls/wininet/wininet_Pl.rc | 25 +- > programs/notepad/Pl.rc | 21 +- > programs/reg/Pl.rc | 6 + > programs/regedit/Pl.rc | 14 +- > programs/taskmgr/Pl.rc | 1063 ++++++++++++++++++++----------------- > programs/wineboot/wineboot_Pl.rc | 11 + > programs/winecfg/Pl.rc | 35 +- > programs/winhlp32/Pl.rc | 29 +- > programs/wordpad/Pl.rc | 40 +- > 12 files changed, 762 insertions(+), 548 deletions(-) > mode change 100644 => 100755 programs/taskmgr/Pl.rc > > diff --git a/dlls/mshtml/Pl.rc b/dlls/mshtml/Pl.rc > index 8aa357e..b5713f8 100644 > --- a/dlls/mshtml/Pl.rc > +++ b/dlls/mshtml/Pl.rc > @@ -1,6 +1,7 @@ > /* > * Copyright 2005-2006 Jacek Caban > * Copyright 2008 Mikolaj Zalewski > + * Copyright 2010 £ukasz Wojni³owicz > * > * This library is free software; you can redistribute it and/or > * modify it under the terms of the GNU Lesser General Public > @@ -34,9 +35,9 @@ STYLE DS_MODALFRAME | DS_CENTER | WS_POPUP | WS_VISIBLE | WS_CAPTION | WS_SYSMEN > CAPTION "Instalator Wine Gecko" > FONT 8, "MS Shell Dlg" > { > - LTEXT "Wine could not find a Gecko package which is needed for applications embedding HTML " \ > - "to work correctly. Wine can automatically download and install it for you.\n\n" \ > - "Note: it's recommended to use distro packages instead. See http://wiki.winehq.org/Gecko for details.", > + LTEXT "Wine nie znalaz³o paczki Gecko potrzebnej do prawid³owego dzia³ania aplikacji " \ > That doesn't sound grammatically correct to me. I'd say that it should be "Wine nie znalazł..." or better "Nie znaleziono...". > + "zawieraj¹cych kod HTML . Wine mo¿e automatycznie pobraæ i zainstalowaæ t¹ paczkê dla ciebie.\n\n" \ > + "Notka: Lepiej jednak u¿yæ paczki z twojej dystrybucji. Po szczegó³y zajrzyj na http://wiki.winehq.org/Gecko.", > "Uwaga: " would be better choice IMO. Thanks, Jacek

June 3, 2010

Re: Removed sign comparison warning.

by Marko Nikolić

Hi Michael, Yes, you are right, casting is not the best solution. The idea was to have a controlled type conversion, thus avoiding implicit type conversion in readlink output parameter. Implicit conversion could lead to another warnings (with -Wconversion or -Wsign-conversion enabled). However, the above conversion warning options anyway produce lot of warning (possibly hard to remove, imho), so I'll change the patch to what you have suggested. Thanks, Marko Michael Stefaniuc wrote: > Hello Marko, > > thank you for your patch and welcome to Wine development. > While in general patches to make Wine use proper types are accepted > there is a slight problem with this patch. > > On 06/01/2010 11:42 PM, grkoma(a)gmail.com wrote: >> From: Marko Nikolic<grkoma(a)gmail.com> >> >> --- >> libs/wine/config.c | 4 ++-- >> 1 files changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/libs/wine/config.c b/libs/wine/config.c >> index 6bb87b0..c04b704 100644 >> --- a/libs/wine/config.c >> +++ b/libs/wine/config.c >> @@ -146,10 +146,10 @@ static char *get_runtime_bindir( const char *argv0 >> ) >> #ifdef linux >> for (size = 256; ; size *= 2) >> { >> - int ret; >> + ssize_t ret; >> if (!(bindir = malloc( size ))) break; >> if ((ret = readlink( "/proc/self/exe", bindir, size )) == -1) >> break; >> - if (ret != size) >> + if ((size_t)ret != size) /* Safe to cast, ret is> 0 here */ > Having to use a cast to silence a -Wsign-compare is worse than keeping > the warning; especially as that is an extra warning not included in the > -Wall used by Wine. Though in this specific case by using the proper > types the warning can be eliminated without resorting to casts. > >> { >> if (!(p = memrchr( bindir, '/', ret ))) break; >> if (p == bindir) p++; > > bye > michael

June 3, 2010

Re: Fully translate partially translated modules in Polish

by Paul Vriens

Hi Łukasz On 06/03/2010 11:51 AM, Łukasz Wojniłowicz wrote: > --- > dlls/mshtml/Pl.rc | 18 +- > dlls/setupapi/Pl.rc | 23 + > dlls/shell32/shell32_Pl.rc | 25 +- > dlls/wininet/wininet_Pl.rc | 25 +- > programs/notepad/Pl.rc | 21 +- > programs/reg/Pl.rc | 6 + > programs/regedit/Pl.rc | 14 +- > programs/taskmgr/Pl.rc | 1063 ++++++++++++++++++++----------------- > programs/wineboot/wineboot_Pl.rc | 11 + > programs/winecfg/Pl.rc | 35 +- > programs/winhlp32/Pl.rc | 29 +- > programs/wordpad/Pl.rc | 40 +- > 12 files changed, 762 insertions(+), 548 deletions(-) I think it's better to send separate patches (so 1 per module) although I must admit I don't have such an issue with this as they are translations. Nonetheless it could be worthwhile resending them to potentially avoid any delay once AJ comes back (and maybe he wants them to be split). > mode change 100644 => 100755 programs/taskmgr/Pl.rc > You have to resend anyway because this change is not needed. Thanks for helping the Polish translation get to 100% !! -- Cheers, Paul.

June 3, 2010

Re: advapi32/tests: Fixed -Wsign-compare warnings in security tests.

by testbot＠testbot.winehq.org

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=2444 Your paranoid android. === W7PROX64 (64 bit security) === security.c:922: Test failed: Access and/or AccessStatus were changed! security.c:939: Test failed: Access and/or AccessStatus were changed! security.c:950: Test failed: Access and/or AccessStatus were changed! security.c:961: Test failed: Access and/or AccessStatus were changed! security.c:972: Test failed: Access and/or AccessStatus were changed! security.c:994: Test failed: Access and/or AccessStatus were changed! security.c:1009: Test failed: Access and/or AccessStatus were changed! security.c:1022: Test failed: Access and/or AccessStatus were changed! security.c:1035: Test failed: Access and/or AccessStatus were changed!

June 3, 2010

CUDA Wrapper err:module:import_dl

by Seth Shelnutt

Alright, I'm stumped and everyone else is too. Few years ago we did everything we are doing now and it all worked fine. Now using wine 1.2rc2 we can't get a wrapper I compiled to work. What this wrapper does is it translates/wraps the calls made to the cuda runtime dll (cudart.dll or nvcuda.dll, same file different names) and sends it to the linux library. The linux library and windows are identical except for some missing dx functions in the linux library. My sources can be found here. http://shelnutt2.host56.com/cudart/ and http://shelnutt2.host56.com/cufft/(However we aren't even getting to the second dll yet). Anytime we try to run folding at home in wine, we are getting the following. FAH checks for nvcuda.dll first because that comes with the driver installs on windows, if it doesn't find it, it defaults to cudart.dll which is packaged with fah, or can be installed separately. We have replaced all the cuda dlls with the compiled wrapper or sum linked to the compiled wrapper, just like we use to with the original cuda wrapper that we came up with. err:module:import_dll Loading library nvcuda.dll (which is needed by L"Z:\\home\\sidicas\\.FAHGPU3\\FahCore_11.exe") failed (error c0000020). err:module:import_dll Loading library cudart.dll (which is needed by L"Z:\\home\\sidicas\\.FAHGPU3\\FahCore_11.exe") failed (error c0000020). sidicas(a)Belldandy:~/.FAHGPU3$ ls -al *.dll -rw-r--r-- 1 sidicas sidicas 1617920 2010-06-03 01:48 amdcalcl.dll -rw-r--r-- 1 sidicas sidicas 2486272 2010-06-03 01:48 amdcalrt.dll -rw-r--r-- 1 sidicas sidicas 124540 2010-06-02 07:50 cudart32_30_14.dll -rw-r--r-- 1 sidicas sidicas 124540 2010-06-02 07:50 cudart.dll -rw-r--r-- 1 sidicas sidicas 82699 2010-06-01 21:39 cufft32_30_14.dll -rw-r--r-- 1 sidicas sidicas 82699 2010-06-01 21:39 cufft.dll lrwxrwxrwx 1 sidicas sidicas 10 2010-06-03 02:12 nvcuda.dll -> cudart.dll sidicas(a)Belldandy:~/.FAHGPU3$ sidicas(a)Belldandy:~/.FAHGPU3$ uname -a Linux Belldandy 2.6.26-2-amd64 #1 SMP Sun Jun 21 04:47:08 UTC 2009 x86_64 GNU/Linux sidicas(a)Belldandy:~/.FAHGPU3$ nvcc --version nvcc: NVIDIA (R) Cuda compiler driver Copyright (c) 2005-2009 NVIDIA Corporation Built on Fri_Feb_19_18:18:31_PST_2010 Cuda compilation tools, release 3.0, V0.2.1221 sidicas(a)Belldandy:~/.FAHGPU3$ ldd ./cudart.dll linux-gate.so.1 => (0xf7ee3000) libcudart.so.3 => /usr/local/cuda/lib/libcudart.so.3 (0xf7e83000) libwine.so.1 => /usr/lib/libwine.so.1 (0xf7d2d000) libm.so.6 => /lib32/libm.so.6 (0xf7d09000) libc.so.6 => /lib32/libc.so.6 (0xf7bb6000) libdl.so.2 => /lib32/libdl.so.2 (0xf7bb2000) libpthread.so.0 => /lib32/libpthread.so.0 (0xf7b9b000) librt.so.1 => /lib32/librt.so.1 (0xf7b92000) libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf7aa4000) libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf7a97000) /lib/ld-linux.so.2 (0xf7ee4000) sidicas(a)Belldandy:~/.FAHGPU3$ sidicas(a)Belldandy:~/.FAHGPU3$ ldd ./cufft.dll linux-gate.so.1 => (0xf7f29000) libcufft.so.3 => /usr/local/cuda/lib/libcufft.so.3 (0xf7308000) libwine.so.1 => /usr/lib/libwine.so.1 (0xf71b2000) libm.so.6 => /lib32/libm.so.6 (0xf718e000) libc.so.6 => /lib32/libc.so.6 (0xf703b000) libdl.so.2 => /lib32/libdl.so.2 (0xf7037000) libpthread.so.0 => /lib32/libpthread.so.0 (0xf7020000) libcudart.so.3 => /usr/local/cuda/lib/libcudart.so.3 (0xf6fdf000) libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf6ef1000) libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf6ee4000) /lib/ld-linux.so.2 (0xf7f2a000) librt.so.1 => /lib32/librt.so.1 (0xf6eda000) sidicas(a)Belldandy:~/.FAHGPU3$ sidicas(a)Belldandy:~/.FAHGPU3$ More thorugh testing has been done, http://foldingforum.org/viewtopic.php?f=54&t=14673&start=105#p146177 . When we makes reference to gpu2 wrapper, that is our original cuda wrapper designed for cuda 2.0-2.2 built couple years ago. The GPU3 wrapper is what we are having problems with. It is our cuda 3.0 wrapper. The .dll files are in the folder (we even tried in system32), ldd shows they are properly linked, yet it does not work. If we use the old wrapper compile before it works fine with cuda 2.x or with cuda 3.0 we just have to sym link the cuda lib to the old name it's expecting. I've tried compiling the old wrapper and linking it to cuda 2.3 however this fails. So I am thinking that if when I compile the old wrapper which is shown to work (when an old compiled version is used) but does not work when I compile on my funtoo box it must be some weird compiling issue. I have wine installed (without 64bit support), and I installed cuda runtime from nvidia's site as the one in portage installs to /opt/ and I wanted to make sure there wasn't any weird issues linking with that. I do get a few warnings when I compile but they aren't anything that would effect this. s.shelnutt(a)funtoo-64 ~/gpu3/wrapper/cudart $ make winegcc -c -mno-cygwin -m32 -I/usr/local/cuda/include/ -o cudart.o cudart.c In file included from /usr/local/cuda/include/cuda_runtime_api.h:53, from /usr/local/cuda/include/crt/host_runtime.h:108, from cudart.c:7: /usr/local/cuda/include/host_defines.h:57:1: warning: "__cdecl" redefined <command-line>: warning: this is the location of the previous definition cudart.c: In function 'wine_cudaGetTextureReference': cudart.c:430: warning: passing argument 1 of 'cudaGetTextureReference' from incompatible pointer type /usr/local/cuda/include/cuda_runtime_api.h:189: note: expected 'const struct textureReference **' but argument is of type 'struct textureReference **' cudart.c: In function 'wine_cudaRegisterFatBinary': cudart.c:800: warning: return makes pointer from integer without a cast cudart.c: In function 'wine_cudaUnregisterFatBinary': cudart.c:805: warning: 'return' with a value, in function returning void cudart.c: In function 'wine_cudaRegisterVar': cudart.c:810: warning: 'return' with a value, in function returning void cudart.c: In function 'wine_cudaRegisterTexture': cudart.c:815: warning: 'return' with a value, in function returning void cudart.c: In function 'wine_cudaRegisterShared': cudart.c:820: warning: 'return' with a value, in function returning void cudart.c: In function 'wine_cudaRegisterSharedVar': cudart.c:825: warning: 'return' with a value, in function returning void cudart.c: In function 'wine_cudaRegisterFunction': cudart.c:831: warning: 'return' with a value, in function returning void winegcc -shared cudart.dll.spec -mno-cygwin -o cudart.dll.so cudart.o -L/usr/local/cuda/lib/ -lcudart -lodbc32 -lole32 -loleaut32 -lwinspool -lodbccp32 -luuid If anyone has any ideas about why this doesn't work, that would be great. I've exhausted everything I could think of. Thanks, Seth Shelnutt

June 3, 2010

Re: [RFC] advapi32 -- GetNamedSecurityInfo

by Austin English

On Thu, Jun 3, 2010 at 10:39 AM, Austin English <austinenglish(a)gmail.com> wrote: > On Thu, Jun 3, 2010 at 7:57 AM, GOUJON Alexandre <ale.goujon(a)gmail.com> wrote: >> Hi, >> >> I'm trying to fix bug 18071 but I don't know anything about ACLs. >> I wrote some tests (see attached patch and >> https://testbot.winehq.org/JobDetails.pl?Key=2442) >> and I modified the source according to my understanding of the issue (wich >> may be totally wrong). > > When testing LastError, you need to set it first to a known value, to > ensure that the test is really resetting LastError. > > Most tests use > SetLastError(0xdeadbeef); Sorry, misread your patch, ignore that comment. -- -Austin

June 3, 2010

Re: [msi/tests] Testcases for CREATE TABLE

by Andrew Eikum

On 06/03/2010 09:07 AM, Paul Vriens wrote: > Hi Matijn, > > This is not your doing. A patch from Andre Eikum is the culprit here > "msi: Publish icons into the correct directory". It uses > SHGetFolderPathA which is not implemented on Win9x/NT4. > > Andrew, could you have a look? > Ahh, these old Windows versions are a pain. Will submit a fix today, thanks. Andrew

June 3, 2010

Re: [msi/tests] Testcases for CREATE TABLE

by Paul Vriens

On 06/03/2010 03:45 PM, (Marvin) wrote: > 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=2443 > > Your paranoid android. > > > === W98SE (32 bit db) === > Failure running script in VM: Exceeded timeout limit of 315 sec > > === WNT4WSSP6 (32 bit db) === > Timeout > > Hi Matijn, This is not your doing. A patch from Andre Eikum is the culprit here "msi: Publish icons into the correct directory". It uses SHGetFolderPathA which is not implemented on Win9x/NT4. Andrew, could you have a look? -- Cheers, Paul.

June 3, 2010

Re: [msi/tests] Testcases for CREATE TABLE

by testbot＠testbot.winehq.org

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=2443 Your paranoid android. === W98SE (32 bit db) === Failure running script in VM: Exceeded timeout limit of 315 sec === WNT4WSSP6 (32 bit db) === Timeout

June 3, 2010

Re: [PATCH 2/2] cmd: Update Dutch translation

by Paul Vriens

On 06/03/2010 03:28 PM, Frédéric Delanoy wrote: > 2010/6/2 Sven Baars <sven.wine(a)gmail.com <mailto:sven.wine(a)gmail.com>> > > --- > programs/cmd/Nl.rc | 194 > ++++++++++++++++++++++++++++----------------------- > 1 files changed, 106 insertions(+), 88 deletions(-) > > > Hi Sven, > > Some remarks: > - You shouldn't change the line length as it makes the patch > unnecessarily big, for no change in text (for the affected hunks) I disagree here. I think having it cut down from 100+ is for the better. -- Cheers, Paul.

June 3, 2010

Re: [PATCH 2/2] cmd: Update Dutch translation

by Frédéric Delanoy

2010/6/2 Sven Baars <sven.wine(a)gmail.com> > --- > programs/cmd/Nl.rc | 194 > ++++++++++++++++++++++++++++----------------------- > 1 files changed, 106 insertions(+), 88 deletions(-) > Hi Sven, Some remarks: - You shouldn't change the line length as it makes the patch unnecessarily big, for no change in text (for the affected hunks) - "bestaat keert de controle terug naar het bestand dat het aanriep. DE CALL\n\" => "DE" should be "De" Frédéric

June 3, 2010

[RFC] advapi32 -- GetNamedSecurityInfo

by GOUJON Alexandre

Hi, I'm trying to fix bug 18071 but I don't know anything about ACLs. I wrote some tests (see attached patch and https://testbot.winehq.org/JobDetails.pl?Key=2442) and I modified the source according to my understanding of the issue (wich may be totally wrong). But as I'm not familiar with ACLs and because my changes are quite important, I'm sending here my patches hoping a advapi32 coder could have a look at it. Thanks in advance

June 3, 2010

New Wine stuff in FreeWear.org

by Ismael Barros²

Hello, We have decided to renew our offer of Wine T-shirts, as the current T-shirt has had mostly no success at all, probably because users don't feel identified nor appealed with the design. I'm attaching the pdf with our new proposals (we hope you like them!). We decided to offer the design in black garment, as in our experience it works much better. We want to be transparent, so I'm attaching also a spreadsheet with our expenses, donations and profits for each model. We usually collaborate with FOSS events, sending them stuff from our catalogue for its sale on the event. In these cases, we make a double donation: one to the organization of the event (higher, as they are in charge of the sales) and another one to the corresponding FOSS organization for the sold article. You can see the details in the spreadsheet. If you have no objection, we'll send Wine stuff to the event that require it. Currently, almost all organizations we work with have us linked from their website. This helps boosting the sales, and therefore the donations, so that everybody wins. We would be very glad if we could get a link somewhere at winehq.org, or alternatively a news item, which for us has the downside of having a limited front-page life-span, but works nonetheless. We hope you like and approve the design. Suggestions are welcome. When the design is approved, we'll upload it to our website. Kind regards, Ismael

June 3, 2010

Re: msi: Update the version strings to match Windows Installer 4.5.

by Andrew Nguyen

On 06/03/2010 03:15 AM, Hans Leidekker wrote: > On Thu, 2010-06-03 at 03:01 -0500, Andrew Nguyen wrote: > >> This pleases the Actel Libero IDE installer. >> --- >> dlls/msi/version.rc | 8 ++++---- >> 1 files changed, 4 insertions(+), 4 deletions(-) > > I think we should delay this until 1.2 is released because it > may trigger some installers to use unimplemented functionality > in msi. > > Hmm, that's a good point. It turns out that the patch is pretty minor anyway, as the installer happily permits continuing even if the native Windows Installer 4.5 redist fails, so I certainly don't have any objections for deferral.

June 3, 2010

Re: msi: Update the version strings to match Windows Installer 4.5.

by Hans Leidekker

On Thu, 2010-06-03 at 03:01 -0500, Andrew Nguyen wrote: > This pleases the Actel Libero IDE installer. > --- > dlls/msi/version.rc | 8 ++++---- > 1 files changed, 4 insertions(+), 4 deletions(-) I think we should delay this until 1.2 is released because it may trigger some installers to use unimplemented functionality in msi.

June 3, 2010

Re: Call for translators

by Dwayne Bailey

On Mon, 2010-05-31 at 13:13 +0200, Michael Stefaniuc wrote: > Dwayne Bailey wrote: > > On Thu, 2010-05-27 at 12:52 +0200, Paul Vriens wrote: > > > > <snip> > > > >> If you like to help out Wine but don't want to touch any of these > >> resource files we can help you out. Please sent us an email with the > >> language you'd like to translate Wine into and we will sent you the more > >> familiar po files. These files show all the translatable strings from a > >> resource file but in a less intriguing format. Once translated, you can > >> sent these files back and we will turn them into the proper resource files. > >> > >> 'We' for now are Michael Stefaniuc and Paul Vriens but I guess others > >> will chime in if needed. > > > > Could I offer to help an admin setup a Pootle server on Wine servers for > > those who want/need to translate in PO format? > Paul and I didn't plan to go that far yet but why not... > Jeremy Newman is the winehq.org admin but he is chronically out of spare > time. Jeremy, how can I help? Do you want to exchange some emails and we can see if we can build a plan for implementation of Pootle on winehq.org? > > In terms of PO format are you using rc2po from the Translate Toolkit? > Yes. rc2po seems to work just fine. Though there are problems with po2rc > but I didn't have yet time to look at fixing them. Glad to see its useful and looking forward to patches ;) -- Dwayne Bailey Associate Research Director +27 12 460 1095 (w) Translate.org.za ANLoc +27 83 443 7114 (c) Recent blog posts: * Localisation: How we guess the target translation language in Virtaal http://www.translate.org.za/blogs/dwayne/en/content/localisation-how-we-gue… * Continuous integration, can it work for software localisation? * Translate Toolkit - a powerful localisation toolkit Firefox web browser in Afrikaans - http://af.www.mozilla.com/af/ African Network for Localisation (ANLoc) - http://africanlocalisation.net/

June 3, 2010

Re: gameux: Add declaration of IGameExplorer2 interface

by Mariusz Pluciński

W dniu 02.06.2010 18:21, Vincent Povirk pisze: > Your change to configure.ac appears to add gameux.dll, which you don't > want to do just yet. Right, I did not notice it. This should be part of next commit in my local tree. Valid using git is still little problematic for me. > The patch adding the header file looks good to me and does not depend > on any other patches, so it may be accepted, or you may need to change > it. Or Alexandre may just wait for you to resend the whole series > correctly. I cannot guess. > OK, I'll fix and resend it. Thanks for your help.

June 2, 2010

msacm32: Remove dead "code" from rc files.

by Frédéric Delanoy

7 years old untouched cruft

June 2, 2010

Re: Removed sign comparison warning.

by Michael Stefaniuc

Hello Marko, thank you for your patch and welcome to Wine development. While in general patches to make Wine use proper types are accepted there is a slight problem with this patch. On 06/01/2010 11:42 PM, grkoma(a)gmail.com wrote: > From: Marko Nikolic<grkoma(a)gmail.com> > > --- > libs/wine/config.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/libs/wine/config.c b/libs/wine/config.c > index 6bb87b0..c04b704 100644 > --- a/libs/wine/config.c > +++ b/libs/wine/config.c > @@ -146,10 +146,10 @@ static char *get_runtime_bindir( const char *argv0 ) > #ifdef linux > for (size = 256; ; size *= 2) > { > - int ret; > + ssize_t ret; > if (!(bindir = malloc( size ))) break; > if ((ret = readlink( "/proc/self/exe", bindir, size )) == -1) break; > - if (ret != size) > + if ((size_t)ret != size) /* Safe to cast, ret is> 0 here */ Having to use a cast to silence a -Wsign-compare is worse than keeping the warning; especially as that is an extra warning not included in the -Wall used by Wine. Though in this specific case by using the proper types the warning can be eliminated without resorting to casts. > { > if (!(p = memrchr( bindir, '/', ret ))) break; > if (p == bindir) p++; bye michael

June 2, 2010

Release schedule

by Alexandre Julliard

Folks, The weekly rc schedule won't be quite weekly this week, I'll be out for the next few days so there won't be a release this Friday. The weekly schedule will resume with rc3 next Friday. Don't let that stop you, there are still enough regressions for everybody... -- Alexandre Julliard julliard(a)winehq.org

June 2, 2010

Re: gameux: Add declaration of IGameExplorer2 interface

by Vincent Povirk

> I attached configure files, cause they're part of main > tree. I though, that if they're intended to being generated, > they would already be listed in .gitignore file. > So, must I avoid sending both "configure" and "configure.ac" > files? The configure file is generated, and you should always avoid sending changes to that. That was not the reason I said you should not have them in the patch. Your change to configure.ac appears to add gameux.dll, which you don't want to do just yet. > Also, should I fix it, and resend these patches again now? You can do that, or you can wait and see what happens on http://source.winehq.org/patches/ The patch adding the header file looks good to me and does not depend on any other patches, so it may be accepted, or you may need to change it. Or Alexandre may just wait for you to resend the whole series correctly. I cannot guess.

June 2, 2010

Re: gameux: Add declaration of IGameExplorer2 interface

by Roderick Colenbrander

2010/6/2 Mariusz Pluciński <vshader(a)gmail.com>: > You're right, but I thought about numbering too late, when > I noticed my patches appeared in wrong order. > > I attached configure files, cause they're part of main > tree. I though, that if they're intended to being generated, > they would already be listed in .gitignore file. > So, must I avoid sending both "configure" and "configure.ac" > files? > configure.ac should be submitted but configure not since that one is generated. I'm not sure why configure isn't in .gitignore but AJ should be asked about that. Roderick

June 2, 2010

Re: gameux: Add declaration of IGameExplorer2 interface

by Nikolay Sivov

On 6/2/2010 20:07, Mariusz Pluciński wrote: > I attached configure files, cause they're part of main > tree. I though, that if they're intended to being generated, > they would already be listed in .gitignore file. Not necessary, configure is tracked too and provided in sources tarballs. > So, must I avoid sending both "configure" and "configure.ac" > files? No. You changed .ac, and it should be included. Alexandre will regenerate configure with his autoconf. Just don't 'git add' files you don't need to send.

June 2, 2010

Re: gameux: Add declaration of IGameExplorer2 interface

by Mariusz Pluciński

You're right, but I thought about numbering too late, when I noticed my patches appeared in wrong order. I attached configure files, cause they're part of main tree. I though, that if they're intended to being generated, they would already be listed in .gitignore file. So, must I avoid sending both "configure" and "configure.ac" files? Also, should I fix it, and resend these patches again now? W dniu 01.06.2010 22:26, Vincent Povirk pisze: > Also, when you're sending a series where the later patches depend on > the earlier patches, you should mark the correct order in your subject > (i.e. start the subject with [1/5], [2/5], etc.). > > On Tue, Jun 1, 2010 at 3:04 PM, Vincent Povirk <madewokherd(a)gmail.com> > wrote: >> I think you want to leave the configure change out of this patch. >> >> 2010/6/1 Mariusz Pluciński <vshader(a)gmail.com>: >>> --- >>> configure | 1 + >>> configure.ac | 1 + >>> include/gameux.idl | 16 ++++++++++++++++ >>> 3 files changed, 18 insertions(+), 0 deletions(-) >>> >>> >>> >>> >>> >>> >>> >> > >

June 2, 2010

Re: GPU driver version reporting

by Roderick Colenbrander

On Wed, Jun 2, 2010 at 5:03 PM, Seth Shelnutt <shelnutt2(a)gmail.com> wrote: > Is there any reason that across all files we don't report the same driver > version? Does windows not do this? Maybe it'd be easier to keep the code in > wined3d and just have user32 and such call for the driver details? I haven't > looked at how windows does it yet, but I'm just wondering if you guys have > any idea of the top of you head. We should behave the same way as Windows and also work as similar as possible. Calling wined3d from user32 is not the right way. In the end we likely have to move all the gpu detection stuff to winex11.drv and somehow let wined3d retrieve the info from there. Other sources like user32 (and perhaps registry keys) should also use this info. Roderick

June 2, 2010

Re: GPU driver version reporting

by Seth Shelnutt

Is there any reason that across all files we don't report the same driver version? Does windows not do this? Maybe it'd be easier to keep the code in wined3d and just have user32 and such call for the driver details? I haven't looked at how windows does it yet, but I'm just wondering if you guys have any idea of the top of you head. Thanks, Seth Shelnutt On Wed, Jun 2, 2010 at 8:06 AM, Roderick Colenbrander < thunderbird2k(a)gmail.com> wrote: > > > > Sure the code is in directx.c but the I suspect the issue Seth is > seeing is that different parts of Wine expose different version > numbers. Some games also have this issue (I believe they use some > user32 code which just returns the display driver name reported by > winex11.drv which is different from what wined3d mentions). It can be > that real windows also stores it somewhere in the registry which we > don't. > > Roderick >

June 2, 2010

Re: [msi]update korean resource

by Paul Vriens

On 06/02/2010 09:10 AM, Hwang YunSong(황윤성) wrote: > > updated Hi, the comments at the top look a bit funny now: /* * Korean resources for MSI - * - * Copyright 2005 YunSong Hwang - * + * + * Copyright 2005 Mike McCormack + * Copyright 2010 Detlef Riekenberg + * Copyright 2010 YunSong Hwang + * -- Cheers, Paul.

June 2, 2010

Re: Meaning of "Certificate Manifold" (crypt32/*.rc)

by Paul Chitescu

On Wednesday 02 June 2010 01:23:20 am Frédéric Delanoy wrote: > Hi, > > I'm reviewing Fr translation and am stuck on the 'IDS_CERT_MANIFOLD > "Certificate Manifold"' part. > > I tried to STFW for it, but apart from OID for "Microsoft Enrollment > Infrastructure", did not find explaining stuff. > > Can someone please explain me what it means? > > Thanks, > > Frédéric You can roughly interpret it as certificate ramifications or branches.

June 2, 2010

Re: bricscad goes native

by Scott Ritchie

On 05/26/2010 12:17 AM, Dmitry Timoshkov wrote: > Scott Ritchie <scott(a)open-vote.org> wrote: > >> I believe a reasonable alternative is to communicate directly with the >> distro Wine packager and have them test your app against whatever >> version of Wine they plan on shipping. That way you don't miss out on >> good changes in Wine either. > > That's unreasonable to put the testing burden of a commercial application > to a 3rd party that's not a part of QA or a support team. Obviosuly you can't > test all the aspects of the application, or even don't know how to do that, > or testing requires additional data or tools. > The idea is for the distro to become part of the QA process itself. By being forward about what version of Wine to ship (eg only the stable releases) the vendor can greatly narrow their testing focus. If multiple distros are using the same stable Wine version, that testing burden gets shared -- assuming the vendor even cares about more than a couple distros. This is, of course, assuming it's reasonable to stick to Wine's stable releases. That's only useful if they're relatively frequent - a year and a half was a bit too much time. I'm also, of course, assuming a distro that actively cares about Wine enough to devote some sort of QA resources towards it. Thanks, Scott Ritchie

June 2, 2010

Re: GPU driver version reporting

by Roderick Colenbrander

On Wed, Jun 2, 2010 at 5:20 AM, Albert Lee <trisk(a)forkgnu.org> wrote: > On Wed, 2 Jun 2010 03:14:34 +0000, Seth Shelnutt <shelnutt2(a)gmail.com> > wrote: >> I am trying to get folding at home gpu client working. The issue we are >> having now is that it detects the driver version and says it is not >> right, and it won't proceed. I've searched through the lines of a >> WINEDEBUG=+trace and I think the issue is: >> >> 0009:trace:d3d:init_driver_info OS version 5.1. >> 0009:trace:d3d_caps:init_driver_info Found card 10de:05e2 in driver DB. >> 0009:trace:d3d_caps:init_driver_info Reporting (fake) driver version >> 0x0006000f-0x000b21aa. >> >> It could also be from: >> 0009:trace:reg:NtSetValueKey (0x14,L"Driver",1,0xff883b94,20) >> 0009: set_key_value( hkey=0014, type=1, namelen=12, name=L"Driver", >> data={57,00,49,00,4e,00,45,00,20,00,53,00,43,00,53,00,49,00,00,00} ) >> >> But I think that is just trying to set a registry key, not get a > registry >> key (i.e. the driver version from the registry). >> >> What I can't figure out is what version this is reporting. I've searched >> but I can't find this driver DB, so I don't know what >> 0x0006000f-0x000b21aa corespondent too. Can someone point me in the > right >> directions? >> >> Thanks, >> >> Seth Shelnutt > > It's a table at: > http://source.winehq.org/source/dlls/wined3d/directx.c#L983 > Sure the code is in directx.c but the I suspect the issue Seth is seeing is that different parts of Wine expose different version numbers. Some games also have this issue (I believe they use some user32 code which just returns the display driver name reported by winex11.drv which is different from what wined3d mentions). It can be that real windows also stores it somewhere in the registry which we don't. Roderick

June 2, 2010

Re: 0003-winecfg-Update-spanish-translation

by Paul Vriens

On 06/01/2010 09:35 PM, jose rostagno wrote: > + PUSHBUTTON "Cancel",IDCANCEL,105,30,45,14,WS_GROUP Shouldn't that be "Cancelar" ? -- Cheers, Paul.

June 2, 2010

Re: GPU driver version reporting

by Albert Lee

On Wed, 2 Jun 2010 03:14:34 +0000, Seth Shelnutt <shelnutt2(a)gmail.com> wrote: > I am trying to get folding at home gpu client working. The issue we are > having now is that it detects the driver version and says it is not > right, and it won't proceed. I've searched through the lines of a > WINEDEBUG=+trace and I think the issue is: > > 0009:trace:d3d:init_driver_info OS version 5.1. > 0009:trace:d3d_caps:init_driver_info Found card 10de:05e2 in driver DB. > 0009:trace:d3d_caps:init_driver_info Reporting (fake) driver version > 0x0006000f-0x000b21aa. > > It could also be from: > 0009:trace:reg:NtSetValueKey (0x14,L"Driver",1,0xff883b94,20) > 0009: set_key_value( hkey=0014, type=1, namelen=12, name=L"Driver", > data={57,00,49,00,4e,00,45,00,20,00,53,00,43,00,53,00,49,00,00,00} ) > > But I think that is just trying to set a registry key, not get a registry > key (i.e. the driver version from the registry). > > What I can't figure out is what version this is reporting. I've searched > but I can't find this driver DB, so I don't know what > 0x0006000f-0x000b21aa corespondent too. Can someone point me in the right > directions? > > Thanks, > > Seth Shelnutt It's a table at: http://source.winehq.org/source/dlls/wined3d/directx.c#L983 -Albert

June 2, 2010

GPU driver version reporting

by Seth Shelnutt

I am trying to get folding at home gpu client working. The issue we are having now is that it detects the driver version and says it is not right, and it won't proceed. I've searched through the lines of a WINEDEBUG=+trace and I think the issue is: 0009:trace:d3d:init_driver_info OS version 5.1. 0009:trace:d3d_caps:init_driver_info Found card 10de:05e2 in driver DB. 0009:trace:d3d_caps:init_driver_info Reporting (fake) driver version 0x0006000f-0x000b21aa. It could also be from: 0009:trace:reg:NtSetValueKey (0x14,L"Driver",1,0xff883b94,20) 0009: set_key_value( hkey=0014, type=1, namelen=12, name=L"Driver", data={57,00,49,00,4e,00,45,00,20,00,53,00,43,00,53,00,49,00,00,00} ) But I think that is just trying to set a registry key, not get a registry key (i.e. the driver version from the registry). What I can't figure out is what version this is reporting. I've searched but I can't find this driver DB, so I don't know what 0x0006000f-0x000b21aa corespondent too. Can someone point me in the right directions? Thanks, Seth Shelnutt

June 2, 2010

Re: Meaning of "Certificate Manifold" (crypt32/*.rc)

by Juan Lang

Hi Frédéric, > I'm reviewing Fr translation and am stuck on the 'IDS_CERT_MANIFOLD > "Certificate Manifold"' part. > I tried to STFW for it, but apart from OID for "Microsoft Enrollment > Infrastructure", did not find explaining stuff. > Can someone please explain me what it means? Yikes. I wish I could explain it, but like you I'm stumped, and I put it in in the first place. I also tried looking for the OID, but it's a Microsoft OID, so that, as usual, is a bit of a dead end. Sorry. --Juan

June 1, 2010

Meaning of "Certificate Manifold" (crypt32/*.rc)

by Frédéric Delanoy

Hi, I'm reviewing Fr translation and am stuck on the 'IDS_CERT_MANIFOLD "Certificate Manifold"' part. I tried to STFW for it, but apart from OID for "Microsoft Enrollment Infrastructure", did not find explaining stuff. Can someone please explain me what it means? Thanks, Frédéric

June 1, 2010

Re: [PATCH 4/4] winecfg: Cosmetic improvements to the about panel

by Alexandre Julliard

Joel Holdsworth <joel(a)airwebreathe.org.uk> writes: > Ok, that's cool. I'll try and get that sorted within a couple of days. > > One other question; I got some feedback from Andre Herschel saying that > the patch failed to apply to some of the language rc files. I suspected > he ran into problems with varying character encodings. Did the patch > "[PATCH 4/4] winecfg: Cosmetic improvements to the about panel" apply > cleanly for you? It looked OK to me. Patch 3 got spam filtered though. I've tried to fix the spam rules, we'll see what happens when you resend... -- Alexandre Julliard julliard(a)winehq.org

June 1, 2010

Re: [PATCH 4/4] winecfg: Cosmetic improvements to the about panel

by Joel Holdsworth

On Tue, 2010-06-01 at 22:39 +0200, Alexandre Julliard wrote: > Joel Holdsworth <joel(a)airwebreathe.org.uk> writes: > > > Are you sure? I really do think using PNGs is preferable. The PNG is > > 22.8kB, whereas a BMP would be 237.2kB - over 10x larger! If I use a > > BMP, it will make the winecfg executable bloat up 25%. > > > > By contrast importing GDI+ or WIC seems to me like a small price to pay. > > We can add support for PNG icons after 1.2. Adding more dependencies to > winecfg is much more risky than a bloated icon. > Ok, that's cool. I'll try and get that sorted within a couple of days. One other question; I got some feedback from Andre Herschel saying that the patch failed to apply to some of the language rc files. I suspected he ran into problems with varying character encodings. Did the patch "[PATCH 4/4] winecfg: Cosmetic improvements to the about panel" apply cleanly for you?

June 1, 2010

Re: [PATCH 4/4] winecfg: Cosmetic improvements to the about panel

by Alexandre Julliard

Joel Holdsworth <joel(a)airwebreathe.org.uk> writes: > Are you sure? I really do think using PNGs is preferable. The PNG is > 22.8kB, whereas a BMP would be 237.2kB - over 10x larger! If I use a > BMP, it will make the winecfg executable bloat up 25%. > > By contrast importing GDI+ or WIC seems to me like a small price to pay. We can add support for PNG icons after 1.2. Adding more dependencies to winecfg is much more risky than a bloated icon. -- Alexandre Julliard julliard(a)winehq.org

June 1, 2010

Re: gameux: Add declaration of IGameExplorer2 interface

by Vincent Povirk

Also, when you're sending a series where the later patches depend on the earlier patches, you should mark the correct order in your subject (i.e. start the subject with [1/5], [2/5], etc.). On Tue, Jun 1, 2010 at 3:04 PM, Vincent Povirk <madewokherd(a)gmail.com> wrote: > I think you want to leave the configure change out of this patch. > > 2010/6/1 Mariusz Pluciński <vshader(a)gmail.com>: >> --- >> configure | 1 + >> configure.ac | 1 + >> include/gameux.idl | 16 ++++++++++++++++ >> 3 files changed, 18 insertions(+), 0 deletions(-) >> >> >> >> >> >> >> >

June 1, 2010