Re: advapi32: Fix GetSecurityInfo with NULL descriptor

[testbot]

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

Re: CUDA Wrapper err:module:import_dl

[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 c020).
err:module:import_dll Loading library cudart.dll (which is needed by 
L"Z:\\home\\sidicas\\.FAHGPU3\\FahCore_11.exe") failed (error c020).



|

|sidi...@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
sidi...@belldandy:~/.FAHGPU3$  |


|sidi...@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
sidi...@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
sidi...@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)
sidi...@belldandy:~/.FAHGPU3$
sidi...@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 (0xf702)
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)
sidi...@belldandy:~/.FAHGPU3$
sidi...@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 issu

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

[testbot]

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

Re: Removed sign comparison warning.

[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, grk...@gmail.com wrote:
>> From: Marko Nikolic
>>
>> ---
>>   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

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

[testbot]

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

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

[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

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

[testbot]

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

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

[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

Re: New Wine stuff in FreeWear.org

[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

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

[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

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

[testbot]

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

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

[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(-)

Re: Fully translate partially translated modules in Polish

[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

Re: Fully translate partially translated modules in Polish

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

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

[testbot]

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!

CUDA Wrapper err:module:import_dl

[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 c020).
err:module:import_dll Loading library cudart.dll (which is needed by
L"Z:\\home\\sidicas\\.FAHGPU3\\FahCore_11.exe") failed (error c020).


sidi...@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
sidi...@belldandy:~/.FAHGPU3$
sidi...@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
sidi...@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
sidi...@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)
sidi...@belldandy:~/.FAHGPU3$
sidi...@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 (0xf702)
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)
sidi...@belldandy:~/.FAHGPU3$
sidi...@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.sheln...@funtoo-64 ~/gpu3/wrapper/cudart $ make
winegcc -c  -mno-cygwin -m32 -I/us

Re: [RFC] advapi32 -- GetNamedSecurityInfo

[Austin English]

On Thu, Jun 3, 2010 at 10:39 AM, Austin English  wrote:
> On Thu, Jun 3, 2010 at 7:57 AM, GOUJON Alexandre  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

Re: [msi/tests] Testcases for CREATE TABLE

[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

Re: [msi/tests] Testcases for CREATE TABLE

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

Re: [msi/tests] Testcases for CREATE TABLE

[testbot]

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

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

[Paul Vriens]

On 06/03/2010 03:28 PM, Frédéric Delanoy wrote:

2010/6/2 Sven Baars mailto:sven.w...@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.

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

[Frédéric Delanoy]

2010/6/2 Sven Baars 

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

[RFC] advapi32 -- GetNamedSecurityInfo

[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
diff --git a/dlls/advapi32/security.c b/dlls/advapi32/security.c
index 821fb86..1c210d6 100644
--- a/dlls/advapi32/security.c
+++ b/dlls/advapi32/security.c
@@ -5272,15 +5272,24 @@ DWORD WINAPI GetNamedSecurityInfoW( LPWSTR name, SE_OBJECT_TYPE type,
 PACL* sacl, PSECURITY_DESCRIPTOR* descriptor )
 {
 DWORD needed, offset;
-SECURITY_DESCRIPTOR_RELATIVE *relative;
+SECURITY_DESCRIPTOR_RELATIVE *relative = NULL;
 BYTE *buffer;
 
 TRACE( "%s %d %d %p %p %p %p %p\n", debugstr_w(name), type, info, owner,
group, dacl, sacl, descriptor );
 
-if (!name || !descriptor) return ERROR_INVALID_PARAMETER;
+/* A NULL descriptor is allowed if any one of the other pointers is not NULL */
+if (!name || !(owner||group||dacl||sacl||descriptor) ) return ERROR_INVALID_PARAMETER;
 
-needed = sizeof(SECURITY_DESCRIPTOR_RELATIVE);
+/* If no descriptor, we have to check that there's a pointer for the requested information */
+if( !descriptor && (
+((info & OWNER_SECURITY_INFORMATION) && !owner)
+||  ((info & GROUP_SECURITY_INFORMATION) && !group)
+||  ((info & DACL_SECURITY_INFORMATION)  && !dacl)
+||  ((info & SACL_SECURITY_INFORMATION)  && !sacl)  ))
+return ERROR_INVALID_PARAMETER;
+
+needed = !descriptor ? 0 : sizeof(SECURITY_DESCRIPTOR_RELATIVE);
 if (info & OWNER_SECURITY_INFORMATION)
 needed += sizeof(sidWorld);
 if (info & GROUP_SECURITY_INFORMATION)
@@ -5290,25 +5299,37 @@ DWORD WINAPI GetNamedSecurityInfoW( LPWSTR name, SE_OBJECT_TYPE type,
 if (info & SACL_SECURITY_INFORMATION)
 needed += WINE_SIZE_OF_WORLD_ACCESS_ACL;
 
-/* must be freed by caller */
-*descriptor = HeapAlloc( GetProcessHeap(), 0, needed );
-if (!*descriptor) return ERROR_NOT_ENOUGH_MEMORY;
+if(descriptor)
+{
+/* must be freed by caller */
+*descriptor = HeapAlloc( GetProcessHeap(), 0, needed );
+if (!*descriptor) return ERROR_NOT_ENOUGH_MEMORY;
 
-if (!InitializeSecurityDescriptor( *descriptor, SECURITY_DESCRIPTOR_REVISION ))
+if (!InitializeSecurityDescriptor( *descriptor, SECURITY_DESCRIPTOR_REVISION ))
+{
+HeapFree( GetProcessHeap(), 0, *descriptor );
+return ERROR_INVALID_SECURITY_DESCR;
+}
+
+relative = *descriptor;
+relative->Control |= SE_SELF_RELATIVE;
+
+buffer = (BYTE *)relative;
+offset = sizeof(SECURITY_DESCRIPTOR_RELATIVE);
+}
+else
 {
-HeapFree( GetProcessHeap(), 0, *descriptor );
-return ERROR_INVALID_SECURITY_DESCR;
+buffer = (BYTE *)HeapAlloc( GetProcessHeap(), 0, needed );
+if (!buffer) return ERROR_NOT_ENOUGH_MEMORY;
+offset = 0;
 }
 
-relative = *descriptor;
-relative->Control |= SE_SELF_RELATIVE;
-buffer = (BYTE *)relative;
-offset = sizeof(SECURITY_DESCRIPTOR_RELATIVE);
-
 if (info & OWNER_SECURITY_INFORMATION)
 {
 memcpy( buffer + offset, &sidWorld, sizeof(sidWorld) );
-relative->Owner = offset;
+/* If we have a descriptor */
+if(relative)
+relative->Owner = offset;
 if (owner)
 *owner = buffer + offset;
 offset += sizeof(sidWorld);
@@ -5316,28 +5337,36 @@ DWORD WINAPI GetNamedSecurityInfoW( LPWSTR name, SE_OBJECT_TYPE type,
 if (info & GROUP_SECURITY_INFORMATION)
 {
 memcpy( buffer + offset, &sidWorld, sizeof(sidWorld) );
-relative->Group = offset;
+if(relative)
+relative->Group = offset;
 if (group)
 *group = buffer + offset;
 offset += sizeof(sidWorld);
 }
 if (info & DACL_SECURITY_INFORMATION)
 {
-relative->Control |= SE_DACL_PRESENT;
 GetWorldAccessACL( (PACL)(buffer + offset) );
-relative->Dacl = offset;
+if(relative)
+{
+relative->Control |= SE_DACL_PRESENT;
+relative->Dacl = offset;
+}
 if (dacl)
 *dacl = (PACL)(buffer + offset);
 offset += WINE_SIZE_OF_WORLD_ACCESS_ACL;
 }
 if (info & SACL_SECURITY_INFORMATION)
 {
-relative->Control |= SE_SACL_PRESENT;
 GetWorldAccessACL( (PACL)(buffer + offset) );
-relative->Sacl = offset;
+if(relative)
+{
+relative->Control |= SE_SACL_PRESENT;
+relative->Sacl = offset;
+}
 if (sacl)
 *sacl = (PACL)(buffer + offset);
 }
+
 return ERROR_SUCCESS;
 }
 
diff --git a/dlls/a

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

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

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

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

Re: Call for translators

[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:
> > 
> > 
> > 
> >> 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-guess-target-translation-language-virtaal
* 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/