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

tools/winegcc solaris link options patch
by sol11x86＠comcast.net 03 May '07

03 May '07

Please comment on this patch: This patch adds two options to toool/winegcc to allow Solaris linker flags to be passed through and recognized. Prior to this patch, libraries compiled with winegcc (despite overloading every link related env variable I could think of), had a single RPATH when evaulated with elfdump (which was the primary library from the compiler). The effect was that I was required to set an LD_LIBRARY_PATH prior to running any of the wine applications, since the RPATH was not fully populated. With this patch, and proper configuration of LDFLAGS, I am now able to build wine on Solaris without having to resort to an LD_LIBRARY_PATH when I run wine. The two flags that are added to winegcc.c are: -R <libdir> -z <linker flags> (-z allows me to control the link phase a little better for performance reasons). Thanks to Steleman who quickly recognized the problem, despite the facts were staring me in the face. Ben

1 0

Re: Implement MsiBreak Feature - Bug 8243
by James Hawkins 03 May '07

03 May '07

On 5/2/07, EA Durbin <ead1234(a)hotmail.com> wrote: > patch created by Anastasius Focht for Bug 8243. > + /* check "MsiBreak" environment variable */ + if( GetEnvironmentVariableW( envMsiBreakW, envMsiBreakValueW, MAX_PATH)) + { I think we need more investigation into this before accepting this patch. One of the things that needs to be checked is whether the windows installer checks the environment variable every single time a custom action is called, or if the environment variable is stored at the beginning of the installation and just the custom action name is checked every time a custom action is called. This can be tested on windows by setting MsiBreak to a certain custom action, and then change the environment variable to a different custom action while the message box is still asking to break. If the installer breaks on the next custom action, we'll know that it checks the environment variable each time. -- James Hawkins

1 0

Re: Implement MsiBreak Feature - Bug 8243
by Peter Oberndorfer 03 May '07

03 May '07

On Thursday 03 May 2007 05:45, EA Durbin wrote: Hi, > patch created by Anastasius Focht for Bug 8243. > >+#include <sys/types.h> /* for getpid() */ >+#include <unistd.h> /* for getpid() */ Do we really need to write out unix pid? AFAIK Winedbg can attach to windows process IDs just fine. >+ if( MessageBoxW( NULL, dbgMsgW, CustomActionName, MB_OKCANCEL) == IDOK) >+ { >+ return TRUE; >+ } nitpick: maybe remove {} to be consistent with rest of file? >+ if( IsMsiBreak( info->target)) >+ DebugBreak(); extra nitpick: maybe remove space before argument or place additional space before closing ) like foo( baz ); / foo(baz); It also seems like the patch is line wrapped. Greetings Peter

1 0

Re: Some Spanish translation updates
by Alexandre Julliard 03 May '07

03 May '07

José Manuel Ferrer Ortiz <jmfo1982(a)yahoo.es> writes: > By the way, I've changed the license of the files > 'oledlg/oledlg_Es.rc' and 'shdoclc/Es.rc' (I was the creator of > these two files) to LPGL version 2.1 (and not any later). Please don't do that. All of Wine should be under the same license, otherwise it will create major confusion. -- Alexandre Julliard julliard(a)winehq.org

1 0

What's the long term plan for 64 bit support?
by Scott Ritchie 03 May '07

03 May '07

In the (distant) future, will we support building Wine with both 64 bit and 32 bit libraries, and then the same Wine installation will run both 64 bit and 32 bit apps? As I understand it, this is the way Windows does in its 64 bit versions. I ask because there's a question of how to name the Wine packages for the 64 bit distribution - there's a standard of naming 32 bit packages something like "wine32", but if we're eventually going to have a unified multiarch package then we can still go with just keeping it as "wine" Thanks, Scott Ritchie

3 3

Re: [5/5] WineD3D: Software vertex blending
by H. Verbeet 03 May '07

03 May '07

>+ for(i = 0; i < 16 /* Max vertex attribs */; i++) { I think you should be using MAX_ATTRIBS there. Changing the strided data like that in drawPrimitive looks rather hacky to me.

2 2

Bug in Advapi32: CryptEnumProviderTypesA and CryptEnumProvidersA
by Mounir IDRASSI 02 May '07

02 May '07

Hi, During our tests of wine with our cryptographic suite, we have found a bug in the functions CryptEnumProviderTypesA and CryptEnumProvidersA in advapi32 dll: In case of failure, they both report a wrong last error through GetLastError. We have found and corrected the source of the bug: They both call their wide-char counterpart but they don't test the success of this call. The correction is simple: add an if statement and return immediately in case of error. I have attached a small patch with our correction. Should we fill a bugzilla report before submitting the patch? Thanks. Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr >From ab7323952138e725700ded1bad4afd17e42717e7 Mon Sep 17 00:00:00 2001 From: Mounir IDRASSI <mounir.idrassi(a)idrix.fr> Date: Wed, 2 May 2007 20:20:59 +0200 Subject: Correct bug in CryptEnumProviderTypesA and CryptEnumProvidersA: They report wrong last error in case of failure --- dlls/advapi32/crypt.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/dlls/advapi32/crypt.c b/dlls/advapi32/crypt.c index 1fd16c3..a7273b9 100644 --- a/dlls/advapi32/crypt.c +++ b/dlls/advapi32/crypt.c @@ -1139,7 +1139,8 @@ BOOL WINAPI CryptEnumProvidersA (DWORD dwIndex, DWORD *pdwReserved, TRACE("(%d, %p, %08x, %p, %p, %p)\n", dwIndex, pdwReserved, dwFlags, pdwProvType, pszProvName, pcbProvName); - CryptEnumProvidersW(dwIndex, pdwReserved, dwFlags, pdwProvType, NULL, &strlen); + if(!CryptEnumProvidersW(dwIndex, pdwReserved, dwFlags, pdwProvType, NULL, &strlen)) + return FALSE; if ( pszProvName && !(str = CRYPT_Alloc(strlen)) ) { SetLastError(ERROR_NOT_ENOUGH_MEMORY); @@ -1267,7 +1268,8 @@ BOOL WINAPI CryptEnumProviderTypesA (DWORD dwIndex, DWORD *pdwReserved, TRACE("(%d, %p, %08x, %p, %p, %p)\n", dwIndex, pdwReserved, dwFlags, pdwProvType, pszTypeName, pcbTypeName); - CryptEnumProviderTypesW(dwIndex, pdwReserved, dwFlags, pdwProvType, NULL, &strlen); + if(!CryptEnumProviderTypesW(dwIndex, pdwReserved, dwFlags, pdwProvType, NULL, &strlen)) + return FALSE; if ( pszTypeName && !(str = CRYPT_Alloc(strlen)) ) { SetLastError(ERROR_NOT_ENOUGH_MEMORY); -- 1.4.4.2

2 1

Any way to get the current code besides git?
by Tom Spear 02 May '07

02 May '07

I'm having an issue using git at work, where it will start downloading the packs, and then just stalls out at the same pack every time.. This has occurred since I first started working here Maybe someone knows the problem, and a solution? If not, is there a way to get git to show file names instead of md5 sums, like cvs did, back when we used it, so I can at least know what file is causing the problem? If there is no solution, then maybe someone does know where I can get current code aside from git? -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email

3 7

Patch question
by Tom Spear 02 May '07

02 May '07

Just curious if there was something wrong with the regedit patch I sent on Friday, or if maybe there is a particular reason that the /C was left out of the code in the first place, that I am missing, and would help me to understand. http://www.winehq.org/pipermail/wine-patches/2007-April/038652.html -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email

1 0

Re: Adding header files for the implementation of Winscard dll (Smart Cards support)
by Dmitry Timoshkov 02 May '07

02 May '07

"Mounir IDRASSI" <mounir.idrassi(a)idrix.fr> wrote: > diff --git a/include/scarderr.h b/include/scarderr.h > new file mode 100755 > index 0000000..c07833e > --- /dev/null > +++ b/include/scarderr.h ... > diff --git a/include/winscard.h b/include/winscard.h > new file mode 100755 > index 0000000..f302a9f > --- /dev/null > +++ b/include/winscard.h ... > diff --git a/include/winsmcrd.h b/include/winsmcrd.h > new file mode 100755 > index 0000000..cc03a35 > --- /dev/null > +++ b/include/winsmcrd.h This is a notice more for Alexandre this time, but next time please make sure to send the files with exec bits turned off (755 -> 644). -- Dmitry.

2 1