Am 25.09.2010 um 05:32 schrieb Luis Carlos Busquets Pérez:
> Concerning the e-mail
> http://www.winehq.org/pipermail/wine-devel/2010-April/082900.html
If I remember correctly d3dx is broken by design in that regard. See
D3DXCONSTTABLE_LARGEADDRESSAWARE in
D3DXGetShaderConstantTableEx:
http://m
Luis Carlos Busquets Pérez wrote:
> Concerning the e-mail
> http://www.winehq.org/pipermail/wine-devel/2010-April/082900.html
>
> it seems that it is broken because in wine there is no way to ensure
> that the string will be in the lower 2GB.
Wine behaviour depends on what application requests
Concerning the e-mail
http://www.winehq.org/pipermail/wine-devel/2010-April/082900.html
it seems that it is broken because in wine there is no way to ensure
that the string will be in the lower 2GB. Actually, according to the
Windows Memory Management model:
http://www.intellectualheaven.com
Michael Jung <[EMAIL PROTECTED]> writes:
> If the CSP's CPAcquireContext function fails, which is quite common (e.g.
> because the user specified key container does not exist), the "temp" variable
> is still free'd twice.
Yes, the free needs to be moved inside the if, sorry about that.
> I'm a
Alexandre,
I've noticed that you applied a modified version of my patch, which tries to
fix a potential double free of the "temp" variable in dlls/advapi32/crypt.c's
CryptAcquireContextA function. However, I think that the modified version
does not fix the problem. Here is a code snippet from t
