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
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
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
---
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 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 advance.
Markus
Sorry, wrong forum.
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
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)
instead of sizeof(DDEVICEIDENTIFIER2
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, 18:04 +0200 schrieb Stefan Dösinger:
Am 11.10.2009 um 17:44 schrieb Markus Stockhausen:
diff.patch
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 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).
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 Windows
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
Wine source tree. Please extend the test cases
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:
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
always
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 something
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 can
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 the
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.
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 heap
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 Wine could save some CPU cycles and can catch up
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
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 be
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 work on
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
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 send a
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 coding style of the file, or at least the
surrounding code
, Sep 10, 2009 at 10:56 PM, Markus Stockhausen
markus.stockhau...@collogia.de wrote:
Hi,
http://bugs.winehq.org/show_bug.cgi?id=18041 reveals a bug where
GdiAlphaBlend will crash in Teamviewer application when a NULL pointer
is handed over. The attached check fixes that behaviour
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 it
28 matches
Mail list logo
