On Sun, Nov 29, 2009 at 5:45 AM, Henri Verbeet wrote:
> 2009/11/20 Austin English :
>> Been happening for a few days...not sure what triggered it, but when
>> coming back from work I see my login screen, which explains the lack
>> of 64-bit tests/appinstall results. I don't know if any of the D3D
I can't do a deep review, but I did see that you have some
commented out code, and IIRC AJ doesn't like that. Better
to remove it than comment it out.
BTW, besides the three apps mentioned in
http://bugs.winehq.org/show_bug.cgi?id=6254,
what apps depend on this?
- Dan
All:
Time to beat on this patch again and make it better. I've also attached
it to bug 6254.
Please make comments constructive. I would like to get assistance where
to break this down so that it will be 'easier to swallow' pieces as this
is one huge patch that AJ has rejected before.
James McK
On Sun, Nov 29, 2009 at 2:24 PM, Dan Kegel wrote:
> On Sun, Nov 29, 2009 at 12:10 AM, Laurent wrote:
>> Yes, it would be. The fact is that makes a zero byte size HeapAlloc.
>> I'm not really sure how and why it is supposed to work in this case,
>
> It works fine, HeapReAlloc handles it ok, too.
>
> And don't ask me to actually think about what I'm doing,
I am still open for further discussions.
> it's too hard to figure out how to print a string and a number without using
> printf().
This data display (e. g. for the input command and line number) is generally
not a problem. But the si
> Original printed more useful information.
I am aware of the desire to get some data for easier program debugging
conveniently.
> Just dropping it in sake of "correctness" is wrong.
I have got an opposite opinion. I am curious if more software developers would
like to care for complete async
On Sun, Nov 29, 2009 at 1:21 AM, Ben Peddell
wrote:
>
So the behavior I'm seeing matches other versions of Windows and is
documented. Excellent. Thanks.
--
Vincent Povirk
On Sun, Nov 29, 2009 at 12:10 AM, Laurent wrote:
> Yes, it would be. The fact is that makes a zero byte size HeapAlloc.
> I'm not really sure how and why it is supposed to work in this case,
It works fine, HeapReAlloc handles it ok, too.
On Windows, it actually returns a heap block.
(On Posix, it
2009/11/20 Austin English :
> Been happening for a few days...not sure what triggered it, but when
> coming back from work I see my login screen, which explains the lack
> of 64-bit tests/appinstall results. I don't know if any of the D3D
> guys could take a look, but I'd appreciate it...
>
What do
Laurent wrote:
On Sun, Nov 29, 2009 at 2:32 AM, Dan Kegel wrote:
On Sat, Nov 28, 2009 at 5:04 PM, Laurent Vromman wrote:
-pStrokes = HeapAlloc(GetProcessHeap(), 0, numStrokes *
sizeof(GdiPath*));
-pStrokes[0] = HeapAlloc(GetProcessHeap(), 0, sizeof(GdiPath));
-PATH_InitGdi
On Sun, Nov 29, 2009 at 2:32 AM, Dan Kegel wrote:
> On Sat, Nov 28, 2009 at 5:04 PM, Laurent Vromman wrote:
>> - pStrokes = HeapAlloc(GetProcessHeap(), 0, numStrokes *
>> sizeof(GdiPath*));
>> - pStrokes[0] = HeapAlloc(GetProcessHeap(), 0, sizeof(GdiPath));
>> - PATH_InitGdiPath(pStrokes
11 matches
Mail list logo
