Hi,
maybe someone with deeper ACM knowledge can help me out. If I understand
the above call correctly it should give the size of the largest
WAVEFORMATEX structure of any driver. This should be more or less the
maximum number of each second DWORD in the registry in the key Software
\Microsoft\Audi
According to Stefans suggestion I have implemented a test for the string
copies into the identifier structure. Test is designed to fail to give
me a hint what is going on. Hopefully someone can post the results of a
test run in native environment.
Thank you
diff --git a/dlls/ddraw/tests/ddrawmodes
Thanks to Dimitry I have changed the test. Maybe someone could check if
the attached one works in native while it fails in my Wine environment.
Thanks a lot in advance.
Markus
diff --git a/dlls/ddraw/tests/visual.c b/dlls/ddraw/tests/visual.c
index 450d231..650f4ba 100644
--- a/dlls/ddraw/tests/
Am Montag, den 12.10.2009, 02:01 +0900 schrieb Dmitry Timoshkov:
> I have compiled the test alone and it fails here:
>
> ddrawmodes.c:37: Test failed: DDDEVICEIDENTIFIER2 too large (misaligned)
>
> It's natural that the structure is 8-byte aligned since it has a
> 64-bit member (LARGE_INTEGER). d
Am Sonntag, den 11.10.2009, 18:04 +0200 schrieb Stefan Dösinger:
> Am 11.10.2009 um 17:44 schrieb Markus Stockhausen:
>
> >
> >
> Did you compile this test with MSVC and the Microsoft headers on
> Windows?
>
I'm sorry but I have no Windows environment. Only Linux/GCC.
Am Sonntag, den 11.10.2009, 17:15 +0200 schrieb Stefan Dösinger:
> Does a pragma pack fix the issue? If yes, then that's probably the
> correct fix.
>
> Its probably worth writing a test that allocates e.g. a char data[64],
> then passes this to GetDeviceIdentifier, fill it with non-zero data,
Am Sonntag, den 11.10.2009, 13:18 +0200 schrieb Markus Stockhausen:
> Then I'm somehow in trouble. How can one explain the following
> error: Application calls IDirectDraw GetDeviceIdentifier of
> DDRAW7 but only reserves memory with sizeof(DDEVICEIDENTIFIER)
>
Am Sonntag, den 11.10.2009, 12:47 +0200 schrieb Stefan Dösinger:
> Which ddraw version an app uses isn't a setting you can change - its
> hardcoded into the app, just like usually its hardcoded whether an app
> uses opengl or d3d.
>
>
Then I'm somehow in trouble. How can one explain the fol
Am Sonntag, den 11.10.2009, 12:40 +0200 schrieb Markus Stockhausen:
> Hi,
>
> as I did not find anything in the Wiki maybe a stupid question: If I
> want an application to use DDRAW4 functions in Wine instead of DDRAW7,
> how can I accomplish that?
>
> Thanks in advanc
Hi,
as I did not find anything in the Wiki maybe a stupid question: If I
want an application to use DDRAW4 functions in Wine instead of DDRAW7,
how can I accomplish that?
Thanks in advance.
Markus
Am Freitag, den 09.10.2009, 15:44 +0200 schrieb Alexandre Julliard:
> If the test case is based on observing internal behavior that's not
> acceptable either. Even if someone else fixes it, the test would force
> the fixer to replicate internal details.
>
Hi,
I can see all of your concerns and t
Am Freitag, den 09.10.2009, 14:15 +0200 schrieb Paul Vriens:
> If that sz99 (or now sz128) came from "looking at internal behaviour",
> I'm not sure if that would raise some eyebrows.
>
... and I simply allocate a "very large" string to ensure that no reuse
of the just freed small memory portion
Am Freitag, den 09.10.2009, 14:15 +0200 schrieb Paul Vriens:
> If that sz99 (or now sz128) came from "looking at internal behaviour",
> I'm not sure if that would raise some eyebrows.
>
As I said "looking at internal behaviour" are debugging messages in the
IMalloc routines of ifs.c. Simply som
Am Freitag, den 09.10.2009, 13:43 +0200 schrieb Paul Vriens:
> Hi Markus,
>
> Isn't there a way that you can change the tests to show this number (in
> some kind of loop by creating a larger second string on the go)?
>
It simply boils down to this one and only testcase. A SysFreeString will
alw
Am Freitag, den 09.10.2009, 01:05 -0700 schrieb Dan Kegel:
> Also, how did you decide on the size of sz99?
I do not want to explain this in detail, as it is the result of looking
at internal behaviour (something that is not liked very much as I
understand now).
But to make a long story short: Thi
Am Freitag, den 09.10.2009, 09:56 +0200 schrieb Paul Vriens:
> On 10/09/2009 09:38 AM, Markus Stockhausen wrote:
> > Am Freitag, den 09.10.2009, 00:27 -0700 schrieb Dan Kegel:
> >> Hi Markus,
> >> Wine development is driven by test cases checked in to the
> >>
Am Freitag, den 09.10.2009, 00:27 -0700 schrieb Dan Kegel:
> Hi Markus,
> Wine development is driven by test cases checked in to the
> Wine source tree. Please extend the test cases in
> dlls/oleaut32/tests to verify that oleaut32 is caching BSTRs
> properly, and make sure that test passes on Wind
> You should not be looking at the internal behavior of native, only at
> the external behavior as observed through test cases.
>
Hm,
I know, that
testcase
-> windows oleaut
-> wine ifs.c IMalloc logging
is quite strange testing. Sadly this was the only way to explore the
reason for not
Am Donnerstag, den 08.10.2009, 18:26 +0400 schrieb Nikolay Sivov:
> Markus Stockhausen wrote:
> > Hi,
> >
> > the last week I took some time to implement the first try of BSTR
> > caching in oleaut.c. On the one hand this will fix a bug, on the other
> > hand Wi
> I'm not sure about the exact details of what this should fix, but
> wouldn't using a private heap have mostly the same effect?
Hi Henri,
it will definitely fix bug 12460 (self tested) and maybe 3756 as it
implements deferred release of BSTR memory. It does not matter if we are
using private hea
Hi,
the last week I took some time to implement the first try of BSTR
caching in oleaut.c. On the one hand this will fix a bug, on the other
hand Wine could save some CPU cycles and can catch up with the speed of
the native implementation.
Attached you will find the result of my considerations.
Am Freitag, den 02.10.2009, 12:56 +0200 schrieb Michael Stefaniuc:
> The best thing is to write a test for this behavior and test it on
> different Windows versions. If even Windows 7 behaves that way I figure
> we'll have to provide that "feature" too. Else the application is buggy
> and won't wor
Hi,
maybe this topic has discussed before but I did not find any threads in
the devel mailing list for the last months. Additionally i followed wine
development for only a few weeks. So here we go ...
oleaut.c in native Windows has some type of "heap reusage" when working
with strings. This can b
Am Dienstag, den 29.09.2009, 15:10 +0200 schrieb Paul Vriens:
> On 09/29/2009 03:01 PM, Markus Stockhausen wrote:
> >
> >
> >
> >
> >
> Hi Markus,
>
> Please stick to the
Am Dienstag, den 29.09.2009, 13:42 +0200 schrieb Paul Vriens:
> Hi Markus,
>
> On fully up-to-date Windows XP Professional SP3:
>
> dsurface.c:1262: Test failed: backbuffer surface has dwBackBufferCount==0
>
>
Thanks to Jeff and Paul for your cross checks. The result makes me happy
and I will
Hi,
currently I'm investigating bug 1660 and hopefully I found the reason
for the misbehaviour. The only problem is, that I do not know what
results I have to expect in windows. So it would be very helpful if
someone can execute the attached testcase in a native environment so
that I can fix the e
Am Freitag, den 18.09.2009, 14:09 +0200 schrieb Paul Vriens:
> On 09/18/2009 01:42 PM, Markus Stockhausen wrote:
> > Hi,
> >
> > as I was encouraged to resent the patch from last week in git format I
> > hope it will be better this
Am Freitag, den 18.09.2009, 14:20 +0400 schrieb Nikolay Sivov:
> Markus Stockhausen wrote:
> > Hi,
> >
> > attached you will find a new testcase that checks for differences
> > between Wine and Windows when handling reference counters for nested
> > stora
Hi,
as I'm still working on a resolution to bug #9575 I have digged into
several directions. My current opinion is that IStorage_CreateStorage
for some unkown reason increments the reference pointer of the
associated IStorage object. In native Windows this is not the case.
My 37th try in writing
Am Samstag, den 12.09.2009, 16:50 +0200 schrieb Paul Vriens:
> On 09/12/2009 04:13 PM, Markus Stockhausen wrote:
> > Am Samstag, den 12.09.2009, 15:52 +0200 schrieb Markus Stockhausen:
> >> Hi,
> >>
> >> hopefully the right explanation for the error can be fo
Am Samstag, den 12.09.2009, 15:52 +0200 schrieb Markus Stockhausen:
> Hi,
>
> hopefully the right explanation for the error can be found here
> http://bugs.winehq.org/show_bug.cgi?id=9575 . Once again I need someone
> with a Windows machine who can provide the following:
>
Hi,
hopefully the right explanation for the error can be found here
http://bugs.winehq.org/show_bug.cgi?id=9575 . Once again I need someone
with a Windows machine who can provide the following:
...
HRESULT = StgOpenStorage( 'testfile.txt', ... , ppstgOpen1 );
HRESULT = StgOpenStorage( 'testfile.t
Sorry for the the wrong feedback.
As I have limited possibilites creating executables on Windows I relied
on Thomas executable for the tests. Maybe you can post a corrected
version.
It is not my intention to confuse someone. Im just trying to narrow down
my initial analysis. The last write access
Am Samstag, den 12.09.2009, 01:39 +0200 schrieb Thomas Trummer:
> Actually, forget about the password and give the file without
> extension a .exe extension...
>
> 2009/9/12 Thomas Trummer
> pw: wine
>
> 2009/9/
Hi,
as I have no Windows machine and cannot test this. I'm in need for
someone who can build a small exe that gives further hints to my
observations in bug #9575.
The following is needed:
call CreateFileW( 'testfile.txt', ..., dwShareMode = 0, ...)
call CreateFileW( 'testfile.txt', ..., dwShareM
Hi,
as I have no Windows machine and cannot test this: I'm in need for
someone who can build a small exe that gives further hints to my
observations in bug #9575. The following is needed:
call CreateFileW( 'testfile.txt', ..., dwShareMode = 0, ...)
call CreateFileW( 'testfile.txt', ..., dwShareMo
Am Freitag, den 11.09.2009, 09:04 +0200 schrieb Paul Vriens:
> Hi Markus,
>
> One I see is a style issue with the if statement. There shouldn't be a
> space after the opening and before the closing bracket.
>
> Another thing (style again) is that maybe it's nicer to return FALSE
> instead of re
Am Freitag, den 11.09.2009, 01:56 +0400 schrieb Nikolay Sivov:
> Just correct your patch (as you mentioned before), include simple
> testcase and resend.
> So nothing to wait for.
>
> Basic test shows it doesn't crash on Windows and doesn't change last
> error - I already
> check this on XP and
be made.
> >
> > Roderick
> >
> > On Thu, Sep 10, 2009 at 10:56 PM, Markus Stockhausen
> > wrote:
> >
> >> Hi,
> >>
> >> http://bugs.winehq.org/show_bug.cgi?id=18041 reveals a bug where
> >> GdiAlphaBlend will crash in Teamv
39 matches
Mail list logo
