Dmitry Timoshkov [mailto:[EMAIL PROTECTED] wrote:
>"Vitaly Budovski" <[EMAIL PROTECTED]> wrote:
>
>> Please show me how an unsigned int can represent values greater than
>> 2^32. This is why a float is used.
>
>Of course int can't, but neither float can. Perhaps you confuse it with
double?
I thi
"Andrew O. Shadoura" <[EMAIL PROTECTED]> wrote:
if (!src || (!dst && dstlen))
{
@@ -1774,18 +1773,12 @@ INT WINAPI MultiByteToWideChar( UINT page, DWORD flags,
LPCSTR src, INT srclen,
if (srclen < 0) srclen = strlen(src) + 1;
-if (!once && (flags & MB_USEGLYPHCHARS))
-{
-
On Wed, 2007-09-05 at 19:32 +0200, Alexandre Julliard wrote:
> Bill Medland <[EMAIL PROTECTED]> writes:
>
> > The only solutions I see are:
> >
> > + Leave it as it is (and hard luck to anyone who uses dates in the range
> > 1/1/100 to 1/1/1601)
>
> That's certainly the best way, unless we find a
On 09/05/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
(But this should go in a different patch, since the old code didn't free it
either. The patch is just fixing the data structure, not the behavior)
Yeah, it's just that this patch made me look at that part of the code.
Am Mittwoch 09 Mai 2007 19:07 schrieb H. Verbeet:
> This set applies on top of Stefan's
>
> Changelog:
> - Unload vertex weight data in case of EXT_VERTEX_WEIGHTING as well
Actually I was thinking about removing the whole (disabled) vertex weighting
code since I didn't find any card supporting t
Am Mittwoch 09 Mai 2007 18:33 schrieb H. Verbeet:
> On 09/05/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> > Fixes an endless loop in the startup of Traffic Giant.
>
> Shouldn't you free the private data when the resource is destroyed?
> (MSDN claims you should).
Yes, this makes sense, especiall
Bill Medland <[EMAIL PROTECTED]> writes:
> The only solutions I see are:
>
> + Leave it as it is (and hard luck to anyone who uses dates in the range
> 1/1/100 to 1/1/1601)
That's certainly the best way, unless we find an app that depends on
these dates.
> + Add support down in kernel32/ntdll to
On Wed, 2007-09-05 at 18:07 +0200, Alexandre Julliard wrote:
> Bill Medland <[EMAIL PROTECTED]> writes:
>
> > On Fri, 2007-04-05 at 11:22 -0700, Bill Medland wrote:
> >> Bill Medland ([EMAIL PROTECTED])
> >> Correct VarBstrFromDate for dates between DATE_MIN and 1601
> >>
> >
> > Has this been re
An int value can be more precise then a float can, however a float can
hold bigger numbers. It's the difference between having a 24 bit
fraction with 8 bits of exponent and 1 of sign vs 31/32 bits of
fraction data without exponent. Plus, integer operations are faster
then floating point operatio
On 5/8/07, James Hawkins <[EMAIL PROTECTED]> wrote:
Please don't change the names of variables. I chose the generic name
of path (which is used throught Wine), because that's exactly what the
variable contains throughout the functions. Also, msifile2 is a poor
choice of a variable name.
Thank
On 09/05/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
Fixes an endless loop in the startup of Traffic Giant.
Shouldn't you free the private data when the resource is destroyed?
(MSDN claims you should).
Dmitry Timoshkov wrote:
"Vitaly Budovski" <[EMAIL PROTECTED]> wrote:
Please show me how an unsigned int can represent values greater than
2^32. This is why a float is used.
Of course int can't, but neither float can. Perhaps you confuse it with
double?
I'm pretty sure I'm not confusing it
On 5/8/07, Dan Hipschman <[EMAIL PROTECTED]> wrote:
I'm not sure what version of C wine is strictly trying to conform to,
but it's usually best to go with the lowest common denominator. This is
not C89. The const keyword doesn't actually make the variable constant
(I know it's not the greatest
Bill Medland <[EMAIL PROTECTED]> writes:
> On Fri, 2007-04-05 at 11:22 -0700, Bill Medland wrote:
>> Bill Medland ([EMAIL PROTECTED])
>> Correct VarBstrFromDate for dates between DATE_MIN and 1601
>>
>
> Has this been rejected out of hand or is it still being considered?
Rejected, adding a secre
"Vitaly Budovski" <[EMAIL PROTECTED]> wrote:
Please show me how an unsigned int can
represent values greater than 2^32. This is why a float is used.
Of course int can't, but neither float can. Perhaps you confuse it with
double?
--
Dmitry.
On Fri, 2007-04-05 at 11:22 -0700, Bill Medland wrote:
> Bill Medland ([EMAIL PROTECTED])
> Correct VarBstrFromDate for dates between DATE_MIN and 1601
>
Has this been rejected out of hand or is it still being considered?
Bill
Dmitry Timoshkov wrote:
"Vitaly Budovski" <[EMAIL PROTECTED]> wrote:
+struct tinn
+{
+/* Pointer to an element in the list. */
+const RGBQUAD *data;
+/* Distance from the reference element. */
+float distance;
+};
Vitaly, why do you keep resending the same patch which uses flo
"Vitaly Budovski" <[EMAIL PROTECTED]> wrote:
+struct tinn
+{
+/* Pointer to an element in the list. */
+const RGBQUAD *data;
+/* Distance from the reference element. */
+float distance;
+};
Vitaly, why do you keep resending the same patch which uses float
values internally? Aga
Hi Alexandre,
I analyzed more deeply the code. The test is absolutely correct but the
the implementation of the function CertContext_SetKeyProvInfo is
definitely incorrect: in MSDN, it's stated that the dwKeySpec field of
CRYPT_KEY_PROV_INFO is "the specification of the private key to
retrieve". Or
Mounir IDRASSI <[EMAIL PROTECTED]> writes:
> Hi,
> This patch removed a hardcoded value (AT_SIGNATURE) from
> CertContext_SetKeyProvInfo. It also corrects a corresponding test.
Like I said, the test currently passes on Windows, so you can't simply
change it. Tests are supposed to reflect the beha
But I'm open to any ideas you may have as to how we could avoid using
floats, yet not run into the overflow situations so easily. We could
probably use division somewhere but I don't think that's actually any
better performance-wise.
It is, when implemented via bit-shifts (very cheap). I know w
Mounir IDRASSI <[EMAIL PROTECTED]> writes:
> Hi Alexandre,
> The problem comes from the file cert.c in crypt32 dll (the real one, not
> the one in tests): at line 1976, the value AT_SIGNATURE is hardcoded in
> case for failure of CryptGetProvParam. Without my patch, this function
> definitely fail
Hi Alexandre,
The problem comes from the file cert.c in crypt32 dll (the real one, not
the one in tests): at line 1976, the value AT_SIGNATURE is hardcoded in
case for failure of CryptGetProvParam. Without my patch, this function
definitely fail and the hardcoded value is written. So, a more comple
Mounir IDRASSI <[EMAIL PROTECTED]> writes:
> This patch adds support for mandatory parameters in
> RSAENH_CPGetProvParam. It also adds tests for them.
> The mandatory parameters are: PP_UNIQUE_CONTAINER, PP_PROVTYPE,
> PP_KEYSPEC, PP_KEYSET_TYPE, PP_KEYSTORAGE.
Thanks for resending, but unfortuna
Eric Pouech <[EMAIL PROTECTED]> writes:
> HeapFree(GetProcessHeap(), 0, actctx->assemblies);
> -actctx->magic = 0;
> +HeapFree(GetProcessHeap(), 0, (void*)actctx->config.info);
> +HeapFree(GetProcessHeap(), 0, (void*)actctx->app.info);
Please don't
Eric Pouech <[EMAIL PROTECTED]> writes:
> +static struct assembly* add_assembly(struct actctx* actctx, enum
> assembly_type at)
> +{
> +struct assembly*assembly;
> +
> +if (!actctx->num_assemblies)
> +actctx->assemblies = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY,
> sizeof
Jeff L <[EMAIL PROTECTED]> writes:
> My mistake. I had not got to a point where they were used, so they
> were untested. The reason I initialised them in the first place I was
> worried about copyright. I since saw something from about there is no
> copyright when defining an interface as there
Mounir IDRASSI <[EMAIL PROTECTED]> writes:
> From: Mounir IDRASSI <[EMAIL PROTECTED]>
> Date: Wed, 9 May 2007 03:33:45 +0200
> Subject: rsaenh: fix bug in RSAENH_CPGetProvParam
Could you please provide a more meaningful subject line to describe
your patch? "fix bug" applies to just about every c
Mikołaj Zalewski <[EMAIL PROTECTED]> writes:
> As I've understood from wine-devel to catch exceptions in tests I
> need to write my own handler. My handler is more compilcated than in
> ntdll/tests/exception.c as I can't assume the next instruction after
> the invalid one will be a 'ret' but is s
Alexandre Julliard wrote:
There's no reason to initialize the enum values explicitly,
particularly since all your values are wrong...
My mistake. I had not got to a point where they were used, so they were
untested. The reason I initialised them in the first place I was
worried about copyrigh
30 matches
Mail list logo
