On Wednesday 27 October 2004 03:33, Juan Lang wrote:
> 1. English note: destruct_handle_table really should be
> destroy_handle_table. I know, "destructor" came into common use, but the
> verb is to destroy. Same with destruct_key, destruct_hash, etc.
Sure, no problem.
> 2. A CSP isn't allocatin
On Tue, 26 Oct 2004 15:43:45 -0700, you wrote:
> This breaks the msvcrt tests:
>
> ../../../tools/runtest -q -P wine -M msvcrt.dll -T ../../.. -p msvcrt_test.exe.so
> time.c && touch time.ok
> time.c:101: Test failed: Wrong date:Year 70 mon 0 yday 1 mday 2 wday 5 hour 0
> min 0 sec 0 d
--- Dmitry Timoshkov <[EMAIL PROTECTED]> wrote:
> > -IMPORTS = gdi32 advapi32 kernel32 ntdll
> > +IMPORTS = msimg32 gdi32 advapi32 kernel32 ntdll
>
> Use gdi32.GdiGradientFill instead of msimg32.GradientFill, the latter one
> is forwarded to gdi32 anyway.
>
Well, I can't find GdiGradientFi
"William Poetra Yoga H" <[EMAIL PROTECTED]> wrote:
> Well, I can't find GdiGradientFill by searching at MSDN. I found some links
> through Google, though. Is it a deprecated, old API? If that's the case, I
> think we'd better link to msimg32.
GdiGradientFill is the gdi32 entry point to which msim
Hi,
On Wed, Oct 27, 2004 at 04:42:22AM -0700, William Poetra Yoga H wrote:
> Well, I can't find GdiGradientFill by searching at MSDN. I found some links
> through Google, though. Is it a deprecated, old API? If that's the case, I
> think we'd better link to msimg32.
It might be a deprecated API, b
William Poetra Yoga H wrote:
Use GdiGradientFill (not GradientFill) to implement gradient caption bar (for now).
GradientFill is pretty slow, as it files the rectangle line by line.
I'm not sure how much this is going to slow down a normal application.
It used to draw pixel by pixel, and that was
Mike McCormack wrote:
William Poetra Yoga H wrote:
Use GdiGradientFill (not GradientFill) to implement gradient caption
bar (for now).
GradientFill is pretty slow, as it files the rectangle line by line.
I'm not sure how much this is going to slow down a normal application.
It used to draw pixe
I'm not sure if this is just Mozilla acting up but the patch doesn't
seem to be fully indented. Is this just UA wierdness?
Aneurin Price wrote:
Comments, anyone?
--- Michael Jung <[EMAIL PROTECTED]> wrote:
> > 2. A CSP isn't allocating a "real" handle, it's sort of a
> pseudohandle, so
> > the multiple-of-four business isn't necessary. When I was testing
> SSPs, I
> > found some of them return 0 as a valid handle value. So I think using
> the
> > index di
Hello,
Testing showed that the current implementation of notify_dispinfoT
doesnt work with W2K. (or at least not with SP4 (: )
The attached patch corrects that our Listview doesnt display anything on
native.
Following assumption proved to be wrong for the Message LVN_GETDISPINFOW:
/*
With test
Thorsten Kani wrote:
Hello,
Testing showed that the current implementation of notify_dispinfoT
doesnt work with W2K. (or at least not with SP4 (: )
The attached patch corrects that our Listview doesnt display anything
on native.
Following assumption proved to be wrong for the Message LVN_GETDI
Hello,
this is an updated version of my rsaenh.dll patch from yesterday with Juan's
suggestions implemented:
1.) Changed destruct_... function names to destroy_... .
2.) Removed the multiple-of-four behaviour for handles.
3.) Got rid of the splitting of handle management functions into one table
Looks good to me, Michael, though I'd suggest using /dev/random rather
than /dev/urandom: the blocking behavior of the former shouldn't be a
problem for Wine (since this DLL makes no timing guarantees anyway).
Since this replaces rsabase.dll, you could add a patch to wine.inf that
registers this r
Juan Lang <[EMAIL PROTECTED]> writes:
> Looks good to me, Michael, though I'd suggest using /dev/random rather
> than /dev/urandom: the blocking behavior of the former shouldn't be a
> problem for Wine (since this DLL makes no timing guarantees anyway).
That doesn't mean we want to block, especia
--- Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> That doesn't mean we want to block, especially for things like
> CPGenRandom that don't require the highest quality randomness.
Wait, why don't we require that much randomness? That doesn't make sense
to me; we don't know what the expectations o
Juan Lang <[EMAIL PROTECTED]> writes:
> --- Alexandre Julliard <[EMAIL PROTECTED]> wrote:
>> That doesn't mean we want to block, especially for things like
>> CPGenRandom that don't require the highest quality randomness.
>
> Wait, why don't we require that much randomness? That doesn't make sens
--- Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> That's why /dev/urandom is a better choice. The randomness is good
> enough for the vast majority of uses, and it doesn't block the process
> for no good reason. /dev/random should be used only when we
> specifically know that anything less than h
Rolf,
Thanks for cleaning up SHFileOperation.
Can you please try restructuring your code further to get rid of the
excessive number of branching points in that function? Last time I
counted, SHFileOperation had more than 60 if/while/for/case statements
in the one +500 line function... that make
Hi folks,
I have a question about dependencies when writing tests. Some tests use
LoadLibraryA and GetProcessAddress to get access to Windows / Wine APIs,
and other tests just include the appropriate header files and link to the
DLLs. One example of the first type is dlls/oleaut32/olefont.c:
==
19 matches
Mail list logo
