2008/6/26 Dan Kegel <[EMAIL PROTECTED]>:
> Your subject line was confusing; what's this about?
>
> Your patches seem malformed, they come across with
> question marks for tabs, e.g.
They look fine on my googlemail account :), and it looks like they are
spaces, not tabs.
> --- context.c??? 2008-06
--- On Thu, 6/26/08, Huw Davies <[EMAIL PROTECTED]> wrote:
>
> You need to select out the hfont before deleting it.
>
> So the SelectObject should look like
> hfont_old = SelectObject(hdc, hfont);
> then after the
> GetTextMetrics
> do
> DeleteObject(SelectObject(hdc, hfont_old))
>
> (then you
2008/6/26 Kai Blin <[EMAIL PROTECTED]>:
> On Thursday 26 June 2008 16:34:51 you wrote:
>
>> @@ -52,6 +52,7 @@ NET_API_STATUS WINAPI NetApiBufferFree(LPVOID Buffer)
>> {
>> TRACE("(%p)\n", Buffer);
>> HeapFree(GetProcessHeap(), 0, Buffer);
>> +Buffer = NULL;
>> return NERR_Succes
is the path getting passed in?
OR is it in an ini file that is read...
Either way you could parse the first few characters for the usual
windows / dos format and branch that way
> If you expect the patches to be applied, they
> need to go to wine-patches, not wine-devel.
I think he doesn't want them to be applied, he's hunting a bug in some app
and these patches happen to work around some problems. So they are a start
for further discussion/debugging, but as such they are
Hi Detlef,
2008/6/26 Detlef Riekenberg <[EMAIL PROTECTED]>:
> On Mi, 2008-06-25 at 21:34 -0700, Maarten Lankhorst wrote:
>> Because of the magnitude of the change I cannot split this patc hup,
>> my apologies for this.
>
> Without any view at your code, the sentense above is wrong by design.
> A T
Adam Petaccia wrote:
> On Wed, 2008-06-25 at 10:41 +0200, Paul Vriens wrote:
>> Hi,
>>
>> I've noticed that the mentioned tests crashes when run via Paul Millar's
>> winetest executable. Compiling myself and running the test works fine.
>>
>> Any one else seeing this?
>>
>
> I've noticed it crash
Vladimir Pankratov wrote:
> Hello.
>
> Changelog:
> Added README.ru file.
> Corrected some errors and fixed text formatting (as I think) since
> last patch.
> Thanks.
Further suggestions:
> Wine это программа которая позволяет запускать программы Microsoft
> Windows (включая DOS, Windows 3.x и W
Under Valgrind, on my nice fast e7200 system,
the entire suite of tests takes about three hours to run.
The slowest ten percent of the tests take over a third of the runtime.
riched20's editor.c in particular spends way too long
(I think) on test_EM_AUTOURLDETECT.
The min, median, and max times
Alex Villacís Lasso wrote:
> Dylan Smith escribió:
>
>> EM_STOPGROUPTYPING simply ends the undo coalescing transaction. The
>> remarks for this message on MSDN explains what events stops group
>> typing, which led me to adding the delete key to the actions that stop
>> group typing.
>>
>> The
On Thu, Jun 26, 2008 at 2:11 PM, Reece Dunn <[EMAIL PROTECTED]> wrote:
> 2008/6/26 Dan Kegel <[EMAIL PROTECTED]>:
>> Your subject line was confusing; what's this about?
Celticht32, please don't change the subject line when replying.
It makes it very hard to follow the thread.
And please use a desc
"Alistair Leslie-Hughes" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> +/* Support for loading xml files from a Wine Windows drive */
> +static int wineXmlMatchCallback (char const * filename)
> +{
> +BSTR sFilename = bstr_from_xmlChar( (xmlChar*)filename);
> +BSTR sColon =
[EMAIL PROTECTED] wrote:
> on the patch list...
>
> The first patch is for a bug I tracked down in context.c that is causing
> some of the behavior that wine is having with the ATI graphics driver.
That patch is no-op - it doesn't change anything.
>
> The second patch was something I noticed i
On Wed, 2008-06-25 at 10:41 +0200, Paul Vriens wrote:
> Hi,
>
> I've noticed that the mentioned tests crashes when run via Paul Millar's
> winetest executable. Compiling myself and running the test works fine.
>
> Any one else seeing this?
>
I've noticed it crashes if Wine is compiled with -O0
on the patch list...
The first patch is for a bug I tracked down in context.c that is causing some
of the behavior that wine is having with the ATI graphics driver.
The second patch? was something I noticed in the code as well that looked a
little off which also relates to the way iPixel shade
Your subject line was confusing; what's this about?
Your patches seem malformed, they come across with
question marks for tabs, e.g.
--- context.c??? 2008-06-26 13:52:57.0 -0400
+++ context.c.patch1??? 2008-06-26 15:19:15.0 -0400
@@ -145,9 +145,7 @@ static int WineD3D_ChoosePixelF
Thank you so much for being patient and showing me how to do this.. with much
help from everyone here is what the results are :
Patch 1 :
File : wine-1.0/dlls/wined3d/context.c
--- context.c??? 2008-06-26 13:52:57.0 -0400
+++ context.c.patch1??? 2008-06-26 15:19:15.0 -0400
@@ -1
On Do, 2008-06-26 at 14:38 -0400, [EMAIL PROTECTED] wrote:
I have no Idea about the touched code, but still some more hints:
You must use your real name
> +WineD3D_PixelFormat *cfgs = This->adapter->cfgs;
> +BOOL exactDepthMatch = FALSE; /*Changed june 23,08 */
> +PIXELFORMATDESC
Joris Huizer wrote:
> A modified patch, taking hints into account from Huw Davies
>
You need to select out the hfont before deleting it.
So the SelectObject should look like
hfont_old = SelectObject(hdc, hfont);
then after the
GetTextMetrics
do
DeleteObject(SelectObject(hdc, hfont_old))
(then y
As others have said, there are plenty of unnecessary changes, but you
probably need some pointing at them, so here goes:
> --- context.c2008-06-26 13:52:57.0 -0400
> +++ context.c.change2008-06-26 14:32:48.0 -0400
> @@ -116,13 +116,12 @@
> int iPixelFormat=0;
> sh
On Mi, 2008-06-25 at 21:34 -0700, Maarten Lankhorst wrote:
> Because of the magnitude of the change I cannot split this patc hup,
> my apologies for this.
Without any view at your code, the sentense above is wrong by design.
A Test is always independant from the implementation,
and what permit a s
Hi Nikolay:
> +pathData->Points = GdipAlloc(sizeof(PointF) * pathData->Count);
> +if(!pathData->Points)
> +return OutOfMemory;
> +
> +pathData->Types = GdipAlloc(pathData->Count);
> +if(!pathData->Points)
Greetings from Copy & Paste
pathData->Points => pathData->Types
Hi Dan, most of that advice was good, but I'll comment on one thing you said:
> Lastly, once the patch is clean and you can send it correctly (test on
> yourself and compare with patches sent that get accepted), send it to
> the correct list for patches, which is wine-patches, not wine-devel.
It'
On Thu, Jun 26, 2008 at 1:38 PM, <[EMAIL PROTECTED]> wrote:
> I am sorry everyone for the spam =)
> been awhile since I developed stuff, been so used to designing things =)
>
> here in all its glorry is the diff -u context.c context.c.new > diff.txt
> file
>
> I couldnt get the -c option to work
On Thu, Jun 26, 2008 at 02:06:18PM -0400, [EMAIL PROTECTED] wrote:
> ok sorry for cutting and pasting the whole routine.. did not see to do just
> the diff ...
> (give the old guy a break.. I am an architect now not a programmer )
>
Your diff is getting corrupted. See all the ???:
http://www.w
I am sorry everyone for the spam =)
been awhile since I developed stuff, been so used to designing things? =)
here in all its glorry is the diff -u context.c context.c.new > diff.txt file
I couldnt get the -c option to work so here is just the -u
--- context.c??? 2008-06-26 13:52:57.0
On Thu, Jun 26, 2008 at 02:06:18PM -0400, [EMAIL PROTECTED] wrote:
> ok sorry for cutting and pasting the whole routine.. did not see to do just
> the diff ...
> (give the old guy a break.. I am an architect now not a programmer )
Please pass at least the -u option for diff.
Ciao, Marcus
ok sorry for cutting and pasting the whole routine.. did not see to do just the
diff ...
(give the old guy a break.. I am an architect now not a programmer )
here is the diff :
119d118
<
122d120
adapter->cfgs;
124,125c122,124
WineD3D_PixelFormat *cfgs = This->adapter->cfgs;
> BOOL exa
On Thursday 26 June 2008 19:51:41 Juan Lang wrote:
> So setting Buffer' to NULL has no impact on the HeapFree of Buffer''.
> The fact that this makes a Valgrind warning disappear still seems like
> a Valgrind bug. If it were doing static analysis, I'd say it's gotten
> confused by aliasing. Since
> You said Buffer was a local variable, but it's a parameter passed from the
> test.
>From the point of view of NetApiBufferFree, Buffer is a parameter,
which is equivalent to a local variable. In C, all parameters are
pass-by-value. You can simulate pass-by-reference by passing a
pointer, but i
On Thursday 26 June 2008 18:07:59 you wrote:
> > Not that I know anything but it seems that HeapFree calls RtlFreeHeap
> > and RtlFreeHeap checks to make sure the pointer is not null before
> > trying to free it. So explicitly setting it to null makes the erorr
> > go away.
>
> That might be true
Zac Brown wrote:
> Add checking for control characters in both standard and byte-reversed
> forms to (Rtl)IsTextUnicode.
>
> Changelog:
> * Add if-statement to ensure we only found control characters in the
> first 256 indices. If we found them beyond that, we don't care since
> Windows doesn't
> Not that I know anything but it seems that HeapFree calls RtlFreeHeap
> and RtlFreeHeap checks to make sure the pointer is not null before
> trying to free it. So explicitly setting it to null makes the erorr
> go away.
That might be true if setting Buffer to NULL happened before the call
to He
On Thu, Jun 26, 2008 at 8:13 AM, Francois Gouget <[EMAIL PROTECTED]> wrote:
>
> I see that these patches have not yet been applied to the AppDB. Is
> there anything wrong with them?
>
> * [AppDB] Assorted spelling fixes.
> http://www.winehq.org/pipermail/wine-patches/2008-June/056192.html
>
> *
On Thu, Jun 26, 2008 at 10:50 AM, Juan Lang <[EMAIL PROTECTED]> wrote:
>> The fix should be
>>*Buffer = NULL;
>> not
>>Buffer = NULL;
>> since p (in the tests) would still be valid after the NetApiBufferFree call.
>
> That's also not correct, as you'd be dereferencing an invalid pointer.
>
> The fix should be
>*Buffer = NULL;
> not
>Buffer = NULL;
> since p (in the tests) would still be valid after the NetApiBufferFree call.
That's also not correct, as you'd be dereferencing an invalid pointer.
NetApiBufferFree takes a void *, not a void ** (unlike
NetApiBufferAllocate).
M
> Has anyone looked at the changes put on the list for context.c?
James already replied: diff is your friend. As the site says, send a
diff (in git format, or in unified diff format if for some bad reason
you're not using git) if you want feedback, it's too hard to read your
changes otherwise.
-
[EMAIL PROTECTED] wrote:
> Has anyone looked at the changes put on the list for context.c? Just had
> not heard anything..
>
> I assume it is because I am new and all but still...just trying to help
> per the request on the wine site =)
>
>
> chris
> ---
On Thursday 26 June 2008 13:25:15 Nikolay Sivov wrote:
> Przemysław Białek wrote:
> > Hi!
> >
> > I sent a patch last Friday to the wine-patches list. I think that I
> > fulfill the rules that I read on winehq website. Patch is simple
> > implementation of function GdipDrawEllipse, and is based on
Yesterday, there were a bunch of new valgrind warnings in gdiplus,
and they're still there today. See
http://kegel.com/wine/valgrind/logs-2008-06-26/vg-gdiplus_font.txt
For instance,
Invalid read of size 4
at GdipCreateFont (font.c:99)
by test_createfont (font.c:57)
by func_font (f
Has anyone looked at the changes put on the list for context.c? Just had not
heard anything..
I assume it is because I am new and all but still...just trying to help per the
request on the wine site =)
chris
On Thursday 26 June 2008 16:34:51 you wrote:
> @@ -52,6 +52,7 @@ NET_API_STATUS WINAPI NetApiBufferFree(LPVOID Buffer)
> {
> TRACE("(%p)\n", Buffer);
> HeapFree(GetProcessHeap(), 0, Buffer);
> +Buffer = NULL;
> return NERR_Success;
> }
>
> I don't get it. How does setting a l
Alexandre Julliard wrote:
> "Juan Lang" <[EMAIL PROTECTED]> writes:
>
>>> These tests import snmpapi, which isn't available on win95. Do we need to
>>> cater for that and do LoadLibrary/GetProcAddress ?
>> Hm. Yeah, I suppose so. That or duplicate the SnmpUtil functions the
>> tests use, which s
"Juan Lang" <[EMAIL PROTECTED]> writes:
>> These tests import snmpapi, which isn't available on win95. Do we need to
>> cater for that and do LoadLibrary/GetProcAddress ?
>
> Hm. Yeah, I suppose so. That or duplicate the SnmpUtil functions the
> tests use, which shouldn't be that hard either.
I
Kai Blin wrote:
> This fixes a Valgrind warning triggered by the NetApiBufferFree() test
> where a buffer is free()d twice.
@@ -52,6 +52,7 @@ NET_API_STATUS WINAPI NetApiBufferFree(LPVOID Buffer)
{
TRACE("(%p)\n", Buffer);
HeapFree(GetProcessHeap(), 0, Buffer);
+Buffer = NULL;
> These tests import snmpapi, which isn't available on win95. Do we need to
> cater for that and do LoadLibrary/GetProcAddress ?
Hm. Yeah, I suppose so. That or duplicate the SnmpUtil functions the
tests use, which shouldn't be that hard either.
--Juan
I don't understand IF the testcase returns NULL without a context
(which should do anyways), both in linux and in windows, and what the
patch does is tu ensure that, with no crash, what's bad with it ?
In AutoCad's installer it's just called WITHOUT a proper opengl context,
in windows it's
On Thu, Jun 26, 2008 at 3:28 AM, Przemysław Białek <[EMAIL PROTECTED]> wrote:
> Hi!
>
> I sent a patch last Friday to the wine-patches list. I think that I fulfill
> the rules that I read on winehq website. Patch is simple implementation of
> function GdipDrawEllipse, and is based on existing funct
I see that these patches have not yet been applied to the AppDB. Is
there anything wrong with them?
* [AppDB] Assorted spelling fixes.
http://www.winehq.org/pipermail/wine-patches/2008-June/056192.html
* [AppDB] application_queue: Fix update().
http://www.winehq.org/pipermail/wine-patch
On Thu, Jun 26, 2008 at 02:05:15AM -0700, Joris Huizer wrote:
> Untested, but this seems trivial/obvious, unless I overlooked something
>
>
>
>
> From 4026f68e4404c4b1822eefe0b3419db4f896e055 Mon Sep 17 00:00:00 2001
> From: Joris Huizer <[EMAIL PROTECTED](none)>
> Date: Thu, 26 Jun 2008
Przemysław Białek wrote:
> Hi!
>
> I sent a patch last Friday to the wine-patches list. I think that I fulfill
> the rules that I read on winehq website. Patch is simple implementation of
> function GdipDrawEllipse, and is based on existing function GdipFillEllipse.
> This is my first patch to the
>As I mentioned before this requires a test case.
As i tried to explain , in a simple test glGetString just return null, it will
not crash for me, like it does in the program.
>I remember from the gl log that the program didn't create a WGL context at
>all. It isn't allowed >to make opengl call
On Thu, Jun 26, 2008 at 03:25:30AM -0700, Joris Huizer wrote:
>
>
> dlls/gdiplus/font.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
>diff --git a/dlls/gdiplus/font.c b/dlls/gdiplus/font.c
>index 9ef8edc..86122da 100644
>--- a/dlls/gdiplus/font.c
>+++ b/dlls/gdiplus/font.c
>@@ -42
Hi!
I sent a patch last Friday to the wine-patches list. I think that I fulfill
the rules that I read on winehq website. Patch is simple implementation of
function GdipDrawEllipse, and is based on existing function GdipFillEllipse.
This is my first patch to the Wine project. I don't have deeper W
"Maarten Lankhorst" <[EMAIL PROTECTED]> writes:
> +FIXME("Waiting for %u to terminate\n", x);
> +/* Make the thread return first */
> +SetEvent(stream->packet_queued);
> +if (WaitForSingleObject(stream->thread, 1) == WAIT_TIMEOUT)
> +exit(1);
Don't
As I mentioned before this requires a test case. I remember from the gl log
that the program didn't create a WGL context at all. It isn't allowed to make
opengl calls because of that.
You should figure out why that is done. Either some other check in the program
failed due to which it wasn't ab
Does this crash occur with Mesa as well? If yes, it might be interesting to
step through the Mesa code to see what is going wrong in there.
Otherwise, drivers are never bug free of course. This could be a bug in the
Nvidia driver
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Beh
Am Donnerstag, den 26.06.2008, 10:37 +0200 schrieb Massimo:
> What could be the reason of an app running fine with no relay enabled,
> but exiting very soon with it enabled ?
Different reasons.
- A debugger detection that detects the relay thunks as debugger. Some
copy protection schemes are a b
What could be the reason of an app running fine with no relay enabled,
but exiting very soon with it enabled ?
Best Regards
Max
59 matches
Mail list logo
