The error was a memory access of a freed object. In ME_AddUndoItem I
checked the top of the undo stack to end a coalescing undo transaction,
assuming that this should be either a valid undo item, or NULL, instead
it was already freed.
The undo item being added was actually being added to the redo
Dan Kegel wrote:
> Nikolai,
> your changes in
> http://source.winehq.org/git/wine.git/?a=commit;h=629761acde13283e0dfc6c42cab3e91e11fbbd88
> seem to have two valgrind errors,
> http://kegel.com/wine/valgrind/logs-2008-06-27/vg-gdiplus_graphicspath-diff.txt
>
> + Conditional jump or move depends on
Hi Maarten,
your recent changes may have triggered new valgrind warnings in qedit,
could you have a look?
http://kegel.com/wine/valgrind/logs-2008-06-27/vg-qedit_mediadet-diff.txt
+ Conditional jump or move depends on uninitialised value(s)
+at FilterGraph2_RemoveFilter (filtergraph.c:463)
+
Nikolai,
your changes in
http://source.winehq.org/git/wine.git/?a=commit;h=629761acde13283e0dfc6c42cab3e91e11fbbd88
seem to have two valgrind errors,
http://kegel.com/wine/valgrind/logs-2008-06-27/vg-gdiplus_graphicspath-diff.txt
+ Conditional jump or move depends on uninitialised value(s)
+at
Seem to be four or so new valgrind warnings in riched20 today,
probably due to Dylan's changes (though my cat may have been
sufing to friskies.com and affected the results, who knows):
http://kegel.com/wine/valgrind/logs-2008-06-27/vg-riched20_editor-diff.txt
+ Invalid read of size 4
+at ME_A
On Fri, Jun 27, 2008 at 6:24 PM, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
> Looking that libxslt only seems to be used by msxml3, I am wondering
> whether this really is worth a warning?
msi depends on msxml3 for some features.
--
Steven Edwards
"There is one thing stronger than all the armies
On Fri, Jun 27, 2008 at 4:01 PM, Warren Dumortier <[EMAIL PROTECTED]> wrote:
> What would you think of adding an entry in the wine menu to:
> 1) Launch wine reboot
> 2)Kill all wine processes
>
> This would be nice, imo. Also adding a error dialog when a program crashes
> or when a dll is missing w
On Fri, Jun 27, 2008 at 7:16 PM, Adam Petaccia <[EMAIL PROTECTED]> wrote:
>
> Subject: [Gdiplus 6/6] We're not checking to see if these functions
> succeed or not, they all just return Ok.
>
The point of regression tests is to prove that this is always the case...
--
James Hawkins
> Is there a way to reuse my recompiled win32 dlls (.so) directly within a
> native Linux app just as I would use regualr Linux dynamic libraries (.so) ?
This has been asked many times, and the answer is always the same: in
general, no. If your DLLs are not calling any Windows APIs at all,
yes.
> If somebody could have a look at the patch, or try it out or give me any
> other feedback, that would be appreciated.
I'm confused:
+if (!This->device->buffers)
+IKsBufferPropertySetImpl_Create(
(This->device->buffers[This->device->nrofbuffers - 1]),
(&Thi
Dylan Smith wrote:
> Currently msftedit.dll is implemented by loading riched20.dll and then
> riched20.dll registers the classes that msftedit.dll normally register.
> Native msftedit.dll appears to be a full implementation of the richedit
> controls, rather than a wrapper.
>
> Here are the opt
Hello,
I would like to reuse a large codebase composed of many win32 dlls
within a NATIVE Linux app.
I have tested with winelib but it seems that the only way to do this is
to use a recompiled win32 app in combination with my recompiled win32
dlls.
Is there a way to reuse my recompiled win32
Hi,
2008/6/27 Dylan Smith <[EMAIL PROTECTED]>:
> riched20.dll is implementing all the versions of richedit controls (1.0, 2.0,
> 3.0, and 4.1), so it is better to store the version that is being emulated.
> The bEmulateVersion10 value is replaced with dwEmulatedVersion.
I thought it implements 1.
*2.12. *When will Wine be finished?
* * Large software projects are never finished, only released. In any
case Wine is chasing a moving target since every new release of Windows
contains new API calls or variations on the existing ones.
Because Wine is being developed mainly by a single compa
Maarten Lankhorst wrote:
> Hi Martin,
>
> 2008/6/27 Martin <[EMAIL PROTECTED]>:
>> Hi.
>>
>> I am working on a patch to fix a bug which prevents certain games from
>> starting. The bug will make wine spit out:
>>
>> fixme:dsound3d:IDirectSound3DListenerImpl_QueryInterface Unknown IID
>> {31efac30-
Nikolay Sivov wrote:
> Vladimir Pankratov wrote:
>> Hello.
>>
>> I corrected punctuation and some sentences.
>>
>> Changelog:
>> Added README.ru file.
>>
>> Thanks for help.
> You may think I'm terrorizing you but I just want to get it better :).
> Something more:
>
> > Другие операционные систем
On Fri, Jun 27, 2008 at 3:01 PM, Warren Dumortier <[EMAIL PROTECTED]> wrote:
> Hi!
>
> What would you think of adding an entry in the wine menu to:
> 1) Launch wine reboot
> 2)Kill all wine processes
>
> This would be nice, imo. Also adding a error dialog when a program crashes
> or when a dll is m
Hi!
What would you think of adding an entry in the wine menu to:
1) Launch wine reboot
2)Kill all wine processes
This would be nice, imo. Also adding a error dialog when a program crashes
or when a dll is missing would be nice.
Kind regards, warren
Hi Martin,
2008/6/27 Martin <[EMAIL PROTECTED]>:
> Hi.
>
> I am working on a patch to fix a bug which prevents certain games from
> starting. The bug will make wine spit out:
>
> fixme:dsound3d:IDirectSound3DListenerImpl_QueryInterface Unknown IID
> {31efac30-515c-11d0-a9aa-00aa0061be93} right bef
Currently msftedit.dll is implemented by loading riched20.dll and then
riched20.dll registers the classes that msftedit.dll normally register.
Native msftedit.dll appears to be a full implementation of the richedit
controls, rather than a wrapper.
Here are the options that I can think of:
1. We co
Hi.
I am working on a patch to fix a bug which prevents certain games from
starting. The bug will make wine spit out:
fixme:dsound3d:IDirectSound3DListenerImpl_QueryInterface Unknown IID
{31efac30-515c-11d0-a9aa-00aa0061be93} right before it crashes(see bug 12240).
I am working on implementi
Neither am I looking to work on EM_FORMATRANGE. I am trying to get my work
on tables to be in a more stable state, since richedit controls need to be
able to support nested paragraphs for the v4.1 implementation of tables
(i.e. a table row is a paragraph, and cells are a container of nested
paragr
Vladimir Pankratov wrote:
> Hello.
>
> I corrected punctuation and some sentences.
>
> Changelog:
> Added README.ru file.
>
> Thanks for help.
You may think I'm terrorizing you but I just want to get it better :).
Something more:
> Другие операционные системы которые поддерживают нити ядра могут
James McKenzie escribió:
>>>
>>>
>> This patch has the corresponding test. Could you please send a patch
>> (one or more) that would test the behaviors fixed by the previous
>> patches? This will make it more likely for AJ to accept the patches, and
>> will also prevent someone (such
On Fri, Jun 27, 2008 at 12:22 PM, Alex Villacís Lasso <
[EMAIL PROTECTED]> wrote:
> Dan Kegel escribió:
> > 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.
>
>
> Good summary about C++ templates and Co skipped
>
> And this is where I discovered
> what a thunk it: Exactly a function that adjusts the this pointer
> before
> calling the main implementation; these thunks are unavoidable if
> functions from one vtable are forwarded to functions belonging to
> If I get it right, the correct fix is to add a thunk vtable for
> IDirectDraw4 that uses relaxed parameter checks on AddAttachedSurface.
Most likely yes
> [1] In fact, an API test is required. Strict or relaxed semantics might
also > depend on how the surface was created (from IDirectDraw4 or
>
Dan Kegel escribió:
> 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.
On Fri, 2008-06-27 at 16:46 +0200, Michael Karcher wrote:
> Am Freitag, den 27.06.2008, 15:27 +0100 schrieb Huw Davies:
> > > static const REAL mm_per_pixel = 25.4;
> > > +static const REAL points_per_inch = 1/72;
> > >
> >
> > I know there are several definitions of a point, but none are this
Am Freitag, den 27.06.2008, 09:13 -0400 schrieb Chris Ahrendt:
> > The problem is that currently, if the application requests a
> > IDirectDrawSurface4 what it gets is a IDirectDrawSurface7. Which is (on
> > the first look) not a issue, as the vtables are compatible (same
> > functions with same si
Am Freitag, den 27.06.2008, 15:27 +0100 schrieb Huw Davies:
> > static const REAL mm_per_pixel = 25.4;
> > +static const REAL points_per_inch = 1/72;
> >
>
> I know there are several definitions of a point, but none are this big!
>
> points_per_inch should be around 72.
And if this is code is
On Fri, Jun 27, 2008 at 03:27:44PM +0100, Huw Davies wrote:
> On Fri, Jun 27, 2008 at 10:16:41AM -0400, Adam Petaccia wrote:
> > --- a/dlls/gdiplus/font.c
> > +++ b/dlls/gdiplus/font.c
> > @@ -34,6 +34,7 @@ WINE_DEFAULT_DEBUG_CHANNEL (gdiplus);
> > #include "gdiplus_private.h"
> >
> > static con
On Fri, Jun 27, 2008 at 10:16:41AM -0400, Adam Petaccia wrote:
> The previous patch I sent incorrectly calculated font-height. Now its
> correctly calculated using points_per_inch and the user's DPI setting.
>
> diff --git a/dlls/gdiplus/font.c b/dlls/gdiplus/font.c
> index 86a3223..85df905 10064
> The problem is that currently, if the application requests a
> IDirectDrawSurface4 what it gets is a IDirectDrawSurface7. Which is (on
> the first look) not a issue, as the vtables are compatible (same
> functions with same signature at same offsets, except for
> IDirectDrawSurface7 having added
Am Freitag, den 27.06.2008, 07:46 -0400 schrieb Christopher J. Ahrendt:
> > If I get it right, the correct fix is to add a thunk vtable for
> > IDirectDraw4 that uses relaxed parameter checks on AddAttachedSurface.
> >
> > Regards,
> > Michael Karcher
> Are we sure its 6.0 and not 6.1? from what
Vitaliy Margolen wrote:
> [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 s
Michael Karcher wrote:
> Am Freitag, den 27.06.2008, 11:26 +0200 schrieb slawek:
>> I have one game, that needs DX6, but lowest clone version of DX is 7.
> That statement is wrong. dlls/ddraw implements DirectDraw 1 to 7. Core
> functionality for surfaces and DX7 special functions are in surface.c,
Am Freitag, den 27.06.2008, 11:26 +0200 schrieb slawek:
> I have one game, that needs DX6, but lowest clone version of DX is 7.
That statement is wrong. dlls/ddraw implements DirectDraw 1 to 7. Core
functionality for surfaces and DX7 special functions are in surface.c,
whereas DX1-5 surfaces are im
I have one game, that needs DX6, but lowest clone version of DX is 7.
The game don't run, because in
dlls/ddraw/surface.c:IDirectDrawSurface7Impl_AddAttachedSurface
is check the surface have z-buffer. There's a notice, that the check
been added, because of information in msdn about this function. T
"Juan Lang" <[EMAIL PROTECTED]> writes:
> Hi, these remaining five patches ended up on the cutting room floor.
> Did this cause a test failure, or is there something else I missed?
Yes, the tests fail:
../../../tools/runtest -q -P wine -M inetmib1.dll -T ../../.. -p
inetmib1_test.exe.so main.c
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:wine-devel-
> [EMAIL PROTECTED] On Behalf Of Christopher J. Ahrendt
> Sent: Friday, June 27, 2008 8:20 AM
> To: wine-devel@winehq.org
> Subject: in response to Alistair
Please do not start a new thread with each mail. Just use the Reply
On Fri, Jun 27, 2008 at 1:19 AM, Christopher J. Ahrendt
<[EMAIL PROTECTED]> wrote:
> 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
>
>
>
Please quit chang
42 matches
Mail list logo
