Re: ntdll: try to not raise exceptions when checking for atl thunks
Am 16.06.2010 11:37, schrieb Alexandre Julliard: Markus Amsler writes: + * Windows checks the following conditions before emulating an ATL thunk: + * - DEP policy allows emulating + * - thunk has memory type MEM_PRIVATE and is readable + * - jmp func is executable + * - thunk signature (movl, jmp) matches + * - a "secret" flag is set: + *The flag gets set before calling WndProc and cleared after WndProc + *or a thunk was emulated. + *In Windows XP SP 3 this flag is located at TEB+0xfb4. */ Where does that information come from? From my attemp to write a test for atl thunks. I had a hard time to get windows to emulate an atl thunk, so I worked my way backward from a working atl thunk example. I knew there had to be some secret flag, because in the WndProc atl thunks worked, outside not. So I took a hard look at the TEB and found it. It was clean reverse engineered. I put it into to patch, to document it somewhere. Markus
Re: Corrections for signal handlers
> 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 situation is different in the context of a signal handler because of the limited set of async-signal-safe functions. Regards, Markus smime.p7s Description: S/MIME Cryptographic Signature
Re: Corrections for signal handlers
> 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-signal-safety. > You'll have to come up with something that prints the same This will not happen at the moment because of conflicting expectations. > or don't touch it. I assume that the involved implementation details will be reconsidered some day in the future. Regards, Markus smime.p7s Description: S/MIME Cryptographic Signature
wine-devel@winehq.org
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\AudioCompressionManager\DriverCache\\aFormatTagCache. In my Wine environment this gives me 50 because
of driver msacm.msadpcm ( ... 0x32 0x00 0x00 0x00 ...).
According to the bug I'm currently inspecting I have the feeling that
in a Windows installation (even without additional acm drivers) this
value could be larger than registry may tell.
For that reason I ask if someone could run the attached testcase in an
native environment and could tell me if he can see a difference between
the result and the registry.
Thanks in advance.
Markus
--- a/dlls/msacm32/tests/msacm.c
+++ b/dlls/msacm32/tests/msacm.c
@@ -485,6 +485,9 @@ static void msacm_tests(void)
if (winetest_interactive)
trace("enabled drivers:\n");
+rc = acmMetrics(0, ACM_METRIC_MAX_SIZE_FORMAT, &dwCount);
+ok(1==0, "ACM_METRIC_MAX_SIZE_FORMAT=%u\n",dwCount);
+
rc = acmDriverEnum(DriverEnumProc, 0, 0);
ok(rc == MMSYSERR_NOERROR,
"acmDriverEnum() failed, rc=%08x, should be 0x%08x\n",
native retest needed: GetDeviceIdentifier()
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.c b/dlls/ddraw/tests/ddrawmodes.c
index bd8bec7..b52a903 100644
--- a/dlls/ddraw/tests/ddrawmodes.c
+++ b/dlls/ddraw/tests/ddrawmodes.c
@@ -645,6 +645,38 @@ static void testddraw3(void)
if(SUCCEEDED(hr) && dd3) IDirectDraw3_Release(dd3);
}
+static void testddraw7(void)
+{
+IDirectDraw7 *dd7;
+HRESULT hr;
+DWORD dddi2[0x110];
+DDDEVICEIDENTIFIER2 *pdddi2;
+
+hr = IDirectDraw_QueryInterface(lpDD, &IID_IDirectDraw7, (void **) &dd7);
+ok(hr==DD_OK, "IDirectDraw7_QueryInterface returned %08x\n", hr);
+
+if (hr==DD_OK)
+{
+ pdddi2 = (DDDEVICEIDENTIFIER2 *)dddi2;
+ dddi2[0x7f] = 0xdeadbeef;
+ dddi2[0xff] = 0xdeadbeef;
+ dddi2[0x10b] = 0xdeadbeef;
+ hr = IDirectDraw7_GetDeviceIdentifier(dd7, pdddi2, 0);
+ ok(hr==DD_OK, "get device identifier failed with %08x\n", hr);
+
+ if (hr==DD_OK)
+ {
+ /* check how strings are copied to the structure */
+ ok(1==0, "last bytes of szDriver string are %08x\n", dddi2[0x7f]);
+ ok(1==0, "last bytes of szDescription string are %08x\n", dddi2[0xff]);
+ /* verify that 8 byte structure size alignment will not overwrite memory */
+ ok(dddi2[0x10b]==0xdeadbeef, "memory beyond DDDEVICEIDENTIFIER2 overwritten\n");
+ }
+
+ IDirectDraw_Release(dd7);
+}
+}
+
START_TEST(ddrawmodes)
{
init_function_pointers();
@@ -663,6 +695,7 @@ START_TEST(ddrawmodes)
testdisplaymodes();
flushdisplaymodes();
testddraw3();
+testddraw7();
releasedirectdraw();
createdirectdraw();
help with native test: GetDeviceIdentifier() memory overwrite
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/visual.c
+++ b/dlls/ddraw/tests/visual.c
@@ -47,7 +47,8 @@ static BOOL createObjects(void)
HMODULE hmod = GetModuleHandleA("ddraw.dll");
WNDCLASS wc = {0};
DDSURFACEDESC2 ddsd;
-
+DWORD DDDI2[0x110];
+DDDEVICEIDENTIFIER2 *PDDDI2;
if(!hmod) return FALSE;
pDirectDrawCreateEx = (void*)GetProcAddress(hmod, "DirectDrawCreateEx");
@@ -57,6 +58,12 @@ static BOOL createObjects(void)
ok(hr==DD_OK || hr==DDERR_NODIRECTDRAWSUPPORT, "DirectDrawCreateEx returned: %x\n", hr);
if(!DirectDraw) goto err;
+PDDDI2=(DDDEVICEIDENTIFIER2 *)DDDI2;
+DDDI2[0x10b] = 0xdeadbeef;
+hr = IDirectDraw7_GetDeviceIdentifier(DirectDraw, PDDDI2, 0);
+ok(hr==DD_OK, "get device identifier failed with %08x\n", hr);
+ok(DDDI2[0x10b]==0xdeadbeef, "memory beyond DDDEVICEIDENTIFIER2 overwritten\n");
+
wc.lpfnWndProc = DefWindowProc;
wc.lpszClassName = "d3d7_test_wc";
RegisterClass(&wc);
Re: ddraw.h: disable DDEVICEIDENTIFIER size alignment
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). ddraw.h in PSDK doesn't have any > forced packing either. > Thanks for the help. But what about older applications/compilers that determined the size to be 4 bytes less and therefore reserved not enough stack space for the result structure. At least http://bugs.winehq.org/show_bug.cgi?id=12869 fails because of this. Should a patch better fix the copy behaviour of GetDeviceIdentifier()?
Re: ddraw.h: disable DDEVICEIDENTIFIER size alignment
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.
Re: ddraw.h structure alignment
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, > and check how much is overwritten. > > Otoh I find it strange that the struct is aligned to 8 bytes. Are you > running wine in 64 bit? Or do you have some other compiler flags that > make the compiler use 8 byte alignment? > You are right. - I'm working on 64 bit (gcc 4.3.3) - #pragma pack(push,4) / #pragma pack(pop) around DDDEVICEIDENTIFIER2 fixes the behaviour - a testcase fails without pragma: ok(sizeof(DDDEVICEIDENTIFIER2)==0x42c, "DDDEVICEIDENTIFIER2 too large (misaligned)\n"); I'll send a patch
ddraw.h structure alignment
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) bytes. Wine returns the > required structure but with the contents of dwWHQLLevel > stack contents are overwritten. > > Markus > Source of error was found. DDEVICEIDENTIFIER2 is aligned to 8 bytes and therefore 4 bytes too large (at least on my 64 bit Linux). Should a patch include a pragma pack handling in the ddraw.h file itself or is there any other location where one can fix that? Best regards. Markus
Re: use DDRAW4 instead of DDRAW7
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 following error: Application calls IDirectDraw GetDeviceIdentifier of DDRAW7 but only reserves memory with sizeof(DDEVICEIDENTIFIER) instead of sizeof(DDEVICEIDENTIFIER2) bytes. Wine returns the required structure but with the contents of dwWHQLLevel stack contents are overwritten. Markus
Re: use DDRAW4 instead of DDRAW7
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.
use DDRAW4 instead of DDRAW7
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
BSTR & Heap - a restart
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 message of what not to do is
understood. If my enthusiasm to reveal the reason for the error got me
too far I'm sorry and this is my official excuse. I'll try to rewind any
knowledge to the point where it all started.
And that was here:
The original goal of my journey was to understand why BSTR memory
structures constantly survived a SysFree cycle in Windows while they got
overwritten for some case in Wine. From what I read in bugzilla the
argumentation always explained, that this comes from heap management.
The tip to solve this with native oleaut, further links to MSDN
documentation about SetOaNoCache() and the KB article
http://support.microsoft.com/kb/937360 led the way that heap was not
freed upon calling SysFreeString.
With this bit of knowledge I ask if the following testcase will be
valid. It should not care about any code inside the "black box":
...
for (i=10;i<100;i++) {
s1 = SysAllocStringLen(sz128,i);
SysFreeString(s1);
HeapAlloc(GetProcessHeap(),0,10);
s2 = SysAllocStringLen(sz128,i);
SysFreeString(s1);
ok(s1==s2, "got a new memory address\n");
}
...
The only development goal this testcase has, is to request a function
that provides the same memory address in two subsequent Alloc/Dealloc
calls with the same string size. Noone should be forced to implement
something that goes anywhere close to native implementation.
A start maybe.
Re: Help needed: BSTR cache testing
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 occur. Markus
Re: Help needed: BSTR cache testing
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 you cannot catch when writing testcases only.
Re: Help needed: BSTR cache testing
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 preserve the contents of the heap and will put the address into some caching freelist. It does not matter how these freelists are organized because of two reasons: - The application does not know the state of oleaut freelists. Earlier calls could have filled them up to some state. - This leads to the second situation that the application cannot anticipate. Will it get a new memory area or something from a freelist when doing a SysAllocString. Reading bugzilla i can see that errors due to missing BSTR caching are ancient WINE companions. But only because of faulty applications. In my opinion there are three ways to go: - close all associated bugs and blame the developers - take some weeks and try to explore the caching behaviour of oleaut - implement only that bit of caching that is required for the bugs My sent in testcase is the basis for the third solution and as my code proposal shows I'm willing to spend some time to get it fixed. Best regards. Markus
Re: Help needed: BSTR cache testing
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: This will ensure that oleaut will allocate new memory instead of reusing its caches. Markus
Re: Help needed: BSTR cache testing
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 in > >> dlls/oleaut32/tests to verify that oleaut32 is caching BSTRs > >> properly, and make sure that test passes on Windows > >> and is marked todo_wine. > >> Once we have a test case like that checked into the Wine > >> source tree, we'll be in better shape to accept a patch > >> that fixes bug 12460. > >> Thanks! > > > > Already sent. Take a look here: > > http://www.winehq.org/pipermail/wine-devel/2009-October/078957.html > > > > So I will ask again with this mail if someone can verify if the test > > above succeeds in various Windows versions. Just to make sure that it > > only fails in Wine. If I get positive feedback I will send it do > > wine-patches. > > > > Thanks in advance. > > > > Markus > > > > > > > > > Hi Markus, > > Test results: > > Win98SE : no failures > WinME : no failures > NT4 : no failures > W2K : no failures > XP Prof : no failures > W2K3 : no failures > Vista Ult SP2 : no failures > Fine, thanks for that. I will sent a final version of the testcase.
Help needed: BSTR cache testing
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 > and is marked todo_wine. > Once we have a test case like that checked into the Wine > source tree, we'll be in better shape to accept a patch > that fixes bug 12460. > Thanks! Already sent. Take a look here: http://www.winehq.org/pipermail/wine-devel/2009-October/078957.html So I will ask again with this mail if someone can verify if the test above succeeds in various Windows versions. Just to make sure that it only fails in Wine. If I get positive feedback I will send it do wine-patches. Thanks in advance. Markus
Re: BSTR caching
> 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 freeing memory. I admit that the application is buggy in this case but the intention was to get some more programs running. Best regards.
Re: BSTR caching
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 with the speed of > > the native implementation. > > > > + * Windows standard behaviour is something like this: Keep 3 freelists of > > + * about 6-8 entries. One is for memory areas less than 32 bytes, the > > second > > + * is for areas between 32 and 64 bytes and the third is for strings > > larger > > + * than 64 bytes. Memory is allocated with length aligned to 16 bytes > How did you guess this? Is it document somewhere? > No, only the result of solving bug 12460, debugging & a few testcases that produce IMalloc log entries and in this way indirectly reflect the behaviour of native oleaut (at least XP version). Markus
Re: BSTR caching
> 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 or global heap. Important is, that the allocated memory constantly survives a SysFreeString call until the next SysAllocString call ist started. Related information: http://www.winehq.org/pipermail/wine-devel/2009-October/078957.html http://bugs.winehq.org/show_bug.cgi?id=3756 Additionally it reduces the time for Dealloc/Alloc Cycles of BSTR memory in best cases by about 50%. Best regards. Markus
BSTR caching
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. It is not yet
ready for implementation but will reflect the "big picture" I thought
of. I would be happy to receive some feedback on this work especially
the following questions are still open:
- Is DllMain the right location for Initialization/Cleanup
- I'm totally confused about the task of how to write a testcase
for this change.
Thanks for your help.
Markus
--- git/dlls/oleaut32/oleaut.c 2009-09-23 18:24:47.0 +0200
+++ wine/dlls/oleaut32/oleaut.c 2009-10-08 14:13:13.0 +0200
@@ -39,8 +39,6 @@
WINE_DEFAULT_DEBUG_CHANNEL(ole);
-static BOOL BSTR_bCache = TRUE; /* Cache allocations to minimise alloc calls? */
-
/**
* BSTR {OLEAUT32}
*
@@ -69,6 +67,276 @@
*/
/**
+ * BSTR caching
+ *
+ * NOTES
+ * The following functions implement some basic operations to avoid permanent
+ * heap allocation/deallocation when working with strings. The idea is to
+ * keep a list of allocated but no longer used memory for each thread. When
+ * the application allocates new strings we can look at those lists to find
+ * matching "free" memory and give it back. Thus one free/alloc cycle is
+ * saved. Additionally the lists are thread specific so concurrency can
+ * be improved.
+ *
+ * Windows standard behaviour is something like this: Keep 3 freelists of
+ * about 6-8 entries. One is for memory areas less than 32 bytes, the second
+ * is for areas between 32 and 64 bytes and the third is for strings larger
+ * than 64 bytes. Memory is allocated with length aligned to 16 bytes
+ *
+ * We will do it in a similar way. Memory is allocated in "16 bytes steps".
+ * Before freeing heap the memory size is determined. Freed strings with
+ * same heap sizes will be stored in containers. Each of them consists of
+ * a number of slots that are pointers memory that is available for reuse.
+ * When allocating new memory we will check if the matching container can
+ * provide unused memory. If not the next container with 16 bytes larger
+ * memory sizes is taken into account. If this fails too memory for the
+ * new BSTR will be allocated in the default way.
+ *
+ * Containers are only build for small memory sizes (<=96 bytes and thus
+ * strings with up to 45 wide chars). Longer strings will not benefit very
+ * much of this caching algorithm. They will be handled by an "overflow"
+ * slot. Memory of this slot will be only assigned to subsequent allocation
+ * calls if not too much memory is wasted.
+ */
+
+#define CBSTR_SLOTS 30
+#define CBSTR_CONTAINERS 6
+
+typedef struct
+{
+DWORD MaxUsed[CBSTR_CONTAINERS];
+DWORD* Slot[CBSTR_SLOTS];
+DWORD* LargeString;
+DWORD LargeSize;
+} CBSTR_CacheStruct;
+
+static DWORD CBSTR_MinSlot[CBSTR_CONTAINERS] = { 0, 6, 12, 17, 22, 26 };
+static DWORD CBSTR_MaxSlot[CBSTR_CONTAINERS] = { 5, 11, 16, 21, 25, 29 };
+static BOOL CBSTR_Active = TRUE;
+static DWORD CBSTR_Index;
+
+/**
+ * CBSTR_CalcMemory
+ *
+ * Determine the memory that is needed to allocate a string. This
+ * function will take care that the size is a multiple of 16.
+ */
+static inline DWORD CBSTR_CalcMemory(DWORD byteLen)
+{
+/* BUGGY!! do not risk a overflow at UINT_MAX */
+return ((byteLen + sizeof(WCHAR) + sizeof(DWORD) - 1) & 0xfff0) + 16;
+}
+
+
+/**
+ * CBSTR_ApplicationInit()
+ *
+ * Initialize BSTR caching for the application and all of its threads.
+ * This function is only called once
+ */
+static void CBSTR_ApplicationInit(void)
+{
+CBSTR_Index = TlsAlloc();
+if (CBSTR_Index==TLS_OUT_OF_INDEXES)
+{
+/* disable BSTR caching if something went wrong */
+CBSTR_Active = FALSE;
+FIXME("BSTR caching disabled due to missing TLS index\n");
+} else {
+FIXME("BSTR caching using TLS index %u\n", CBSTR_Index);
+}
+}
+
+/**
+ * CBSTR_ApplicationFree()
+ *
+ * Cleanup BSTR caching on application exit. Only called once.
+ */
+static void CBSTR_ApplicationFree(void)
+{
+if (CBSTR_Index!=TLS_OUT_OF_INDEXES)
+{
+TlsFree(CBSTR_Index);
+FIXME("BSTR caching freed TLS index %u\n", CBSTR_Index);
+}
+}
+
+/**
+ * CBSTR_ThreadInit()
+ *
+ * Initiali
Re: oleaut - SysAllocString/SysFreeString
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 all Windows versions either.
>
> bye
> michael
Hi,
nothing easier than this. But I guess it will not help us very much
because we are testing bad application behaviour that only works because
of Windows internal caching.
I have attached a testcase and hope it shows the expected behaviour - at
least it fails in my Wine git. Hopefully we can collect the results of
all Windows versions (including 7).
Markus
--- git/dlls/oleaut32/tests/vartest.c 2009-09-20 18:07:17.0 +0200
+++ wine/dlls/oleaut32/tests/vartest.c 2009-10-02 13:46:23.0 +0200
@@ -8555,10 +8555,41 @@
SysFreeString(true_str);
}
+static void test_SomethingStrange(void)
+{
+ BSTR s1,s2;
+ int i;
+
+ const WCHAR sz99[] = {'1','2','3','4','5','6','7','8','9','0',
+'1','2','3','4','5','6','7','8','9','0',
+'1','2','3','4','5','6','7','8','9','0',
+'1','2','3','4','5','6','7','8','9','0',
+'1','2','3','4','5','6','7','8','9','0',
+'1','2','3','4','5','6','7','8','9','0',
+'1','2','3','4','5','6','7','8','9','0',
+'1','2','3','4','5','6','7','8','9','0',
+'1','2','3','4','5','6','7','8','9','0',
+'1','2','3','4','5','6','7','8','9','0',
+'1','2','3','4','5','6','7','8','9','0',
+'1','2','3','4','5','6','7','8','9','0',
+'1','2','\0'};
+
+ s1 = SysAllocString(sz12);
+ i = SysStringLen(s1);
+ ok(i == 2, "string length should be 2\n");
+ SysFreeString(s1);
+ s2 = SysAllocString(sz99); /* simulate heap allocation */
+ SysFreeString(s2);
+ i = SysStringLen(s1);
+ ok(i == 2, "string was overwritten after SysFreeString\n");
+}
+
+
START_TEST(vartest)
{
init();
+ test_SomethingStrange();
test_VariantInit();
test_VariantClear();
test_VariantCopy();
@@ -8590,5 +8621,5 @@
test_VarAnd();
test_VarDiv();
test_VarIdiv();
- test_VarImp();
+ test_VarImp();
}
oleaut - SysAllocString/SysFreeString
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 unconvered when placing debug messages into IMalloc_xxx functions. A sequence of SysAllocString, SysFreeString will show something like that: Alloc olemalloc:IMalloc_fnAlloc (0x7ec47df8, 16) - addr is 0x12a1b8 Free olemalloc:IMalloc_fnGetSize (0x12a1b8) - 16 Alloc nothing Free olemalloc:IMalloc_fnGetSize (0x12a1b8) - 16 When exiting the program one can see a message like this olemalloc:IMalloc_fnFree (0x7ec47df8, 0x12a1b8) In Wine the heap will be released immediately. Why sould that be of any concern you may ask. This behaviour makes some buggy applications run with native oleaut32 (see bug 12460). In this case the application copies the contents of a string directly after it has been freed. Wine corrupts the heap in between and the application will crash. My question is: Should this behaviour declared as "application is buggy & will not be fixed" or has a patch a chance to find its way into git? An idea would be an deferred free like this. - TlsAlloc on entry of dll. - SysFreeString TlsGetValue for last address if value is set FreeHeap(address) TlsSetValue for current address - on exit of dll do some cleanup (heap & Tls) Of course this behaviour is far away from the oleaut implementation and will consume some more CPU cycles. Thanks for your feedback in inadvance. Markus
Re: set caps.dwBackBufferCount=0 for backbuffer surface
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 (implementation and test). > Hi Paul, what do You think of (I'm a little bit confused)? Thanks Markus
Re: help with dwBackBufferCount in backbuffer surfaces needed
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 patch immediately. Markus.
help with dwBackBufferCount in backbuffer surfaces needed
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 error condition and send in the final patch.
The idea is that backbuffer surfaces have dwBackBufferCount=0 in Windows
but on Wine they get the same count as the primary surface.
The test will fail in Windows and Wine to get the results in both cases.
The result will show like this:
dsurface.c:1264: Test failed: backbuffer surface has
dwBackBufferCount==2
Thanks for your help in advance.
Markus
--- git/dlls/ddraw/tests/dsurface.c 2009-09-20 18:07:17.0 +0200
+++ wine/dlls/ddraw/tests/dsurface.c 2009-09-29 13:11:47.0 +0200
@@ -1154,9 +1154,9 @@
HRESULT hr;
IDirectDraw7 *dd7;
IDirectDrawSurface7 *surface1, *surface2, *surface3, *surface4;
-DDSURFACEDESC2 ddsd;
+DDSURFACEDESC2 ddsd, ddsd2;
UINT num;
-DDSCAPS2 caps = {DDSCAPS_TEXTURE, 0, 0, 0};
+DDSCAPS2 caps = {DDSCAPS_TEXTURE, 0, 0, 0},caps2 = {DDSCAPS_BACKBUFFER,0,0,0};
HWND window = CreateWindow( "static", "ddraw_test", WS_OVERLAPPEDWINDOW, 100, 100, 160, 160, NULL, NULL, NULL, NULL );
hr = IDirectDraw_QueryInterface(lpDD, &IID_IDirectDraw7, (void **) &dd7);
@@ -1253,6 +1253,14 @@
hr = IDirectDraw7_CreateSurface(dd7, &ddsd, &surface1, NULL);
ok(hr==DD_OK,"CreateSurface returned: %x\n",hr);
+ddsd2.dwSize = sizeof(ddsd2);
+
+hr = IDirectDrawSurface7_GetAttachedSurface(surface1, &caps2, &surface2);
+ok(hr==DD_OK,"GetAttachedSurface returned: %x\n",hr);
+hr = IDirectDrawSurface7_GetSurfaceDesc(surface2,&ddsd2);
+ok(hr==DD_OK,"GetSurfaceDesc returned: %x\n",hr);
+ok(1==2,"backbuffer surface has dwBackBufferCount==%u\n",ddsd2.dwBackBufferCount);
+
num = 0;
IDirectDrawSurface7_EnumAttachedSurfaces(surface1, &num, SurfaceCounter);
ok(num == 1, "Primary surface has %d surfaces attached, expected 1\n", num);
Re: gdi32/bitblt: GdiAlphaBlend - Check for NULL Pointer (incl. testcase)
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 time. > > > > Best regards > > > > > > ---- > > > > > Hi Markus, > > After reading this patch again, it seems to me it's not a 100% correct. > There is a slight difference in passing hdcSrc as NULL compared to > retrieving dcSrc via get_dc_ptr. > > The actual test sets hdcSrc to NULL, so the corresponding test in the > implementation should be: > > if (!hdcSrc) > return FALSE; > > dcSrc = get_dc_ptr ( hdcSrc ); > > Now, I don't know whether get_dc_ptr can fail but that's a different matter. > Hi Paul, thanks for your attention but if I go through the whole dc_* stuff I can see that it will return NULL to dcSrc if an error occurs somewhere. This maybe because auf hdcSrc being NULL (other cases included). This would result in two cases to check: 1. Check if hdcSrc is not NULL (will be done in the dc_ functions). 2. Check if dcSrc is not NULL (that is missing) I'm a little bit lost if more testcases are needed. Best regards.
Re: New testcase for creating nested storage objects
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 > > storage objects. > > > > Best regards. > > > > Markus > > > Hi, Markus. > > Tests passes on XP, fails on current Wine. > > You should mark failing tests with todo_wine. Like that: > > c1 = IStorage_AddRef(stg); > > todo_wine ok(c1 == 2, "creating internal storage added > > references to ancestor\n"); > > c1 = IStorage_AddRef(stg); > > IStorage_Release(stg2); > > c2 = IStorage_AddRef(stg) - 1; > > todo_wine ok(c1 == c2, "releasing internal storage > > removed references to ancestor\n"); > otherwise it will fail on Wine. > > Also give a more appropriate patch name and don't forget to add a prefix > something like this: > ole32/tests: Test for nested storages reference counting. > > P.S. git diff patch is preferable here. > > Thanks for your work. Thanks for your assistance, I'm willing to learn but at the moment git is something I have to get used to. I'll resend the patch for the testcase with the fixes. BTW: I'm still missing your (and/or my) patches and testcases for the bitblt errors in Teamviewer. Is there any issue with it? Best regards.
Testcase for IStorage_CreateStorage
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 a Wine testcase resulted in the following code
that hopefully shows the difference between the two environments. I put
it somewhere in the storage32 tests to get it running. No warranty for
side effects.
static const WCHAR yyy[] = { 'x','.','t','x','t',0 };
r = StgOpenStorage( yyy, NULL,
STGM_TRANSACTED | STGM_SHARE_EXCLUSIVE |
STGM_READWRITE , NULL, 0, &stg);
ok(r==S_OK, "StgCreateStorage failed\n");
if(stg)
{
static const WCHAR xxx[] =
{ 'D','a','t','a','S','p','a','c','e','I','n','f','o',0 };
IStorage_CreateStorage(stg,xxx,STGM_READWRITE |
STGM_SHARE_EXCLUSIVE,0,0,&stg2);
if (stg2) {
r = IStorage_AddRef(stg);
ok(r == 2, "WINE ERROR: refcount should be 2\n");
IStorage_Release(stg2);
while ( r ) r=IStorage_Release(stg);
} else {
ok( 1 == 2, "IStorage::CreateStorage failed\n");
IStorage_Release(stg);
}
}
If I got everything in the right place this test should fail on Wine
wheres it will be ok in Windows. Before doing further research I hope
someone of the experts can check if the test really reveals the source
of the above mentioned bug.
Thanks in advance.
Re: bug #9575 - better this time - testcase help needed
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 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.txt', ... , ppstgOpen2 );
> >>
> >> I expect *ppstgOpen2 not to be NULL in Windows while being NULL under
> >> Wine.
> >>
> >> Best regards.
> >>
> >> Markus
> >
> > Uh, too fast when sending. Additionally the result code of HRESULT is
> > needed to get a clearer picture.
> >
> > Best regards.
> >
> >
> >
> Hi Markus,
>
> /* create the file */
> SetLastError(0xdeadbeef);
> r = StgCreateDocfile( filename, 0x11012, 0, &stg);
> trace("r : %08x\n", r);
> trace("GLE : %d/%08x\n", GetLastError(), GetLastError());
> IStorage_Release(stg);
>
> SetLastError(0xdeadbeef);
> r= StgOpenStorage( filename, NULL, 0x10012, NULL, 0, &stg);
> trace("r : %08x\n", r);
> trace("GLE : %d/%08x\n", GetLastError(), GetLastError());
>
> SetLastError(0xdeadbeef);
> r= StgOpenStorage( filename, NULL, 0x10012, NULL, 0, &stg);
> trace("r : %08x\n", r);
> trace("GLE : %d/%08x\n", GetLastError(), GetLastError());
>
> Output on W2K3:
>
> storage32.c:1498: r :
> storage32.c:1499: GLE : 0/
> storage32.c:1504: r :
> storage32.c:1505: GLE : 0/
> storage32.c:1509: r : 80030020
> storage32.c:1510: GLE : 32/0020
>
> Wine:
>
> storage32.c:1498: r :
> storage32.c:1499: GLE : 0/
> storage32.c:1504: r :
> storage32.c:1505: GLE : 0/
> storage32.c:1509: r : 80030020
> storage32.c:1510: GLE : 32/0020
>
> So I get STG_E_SHAREVIOLATION and a GLE of ERROR_SHARING_VIOLATION on
> both W2K3 and Wine for the second call.
>
> The grfMode is taken from the trace of running the application.
>
So I guess *ppstgOpen pointing to NULL in Wine can be the culprit.
Re: bug #9575 - better this time - testcase help needed
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: > > ... > HRESULT = StgOpenStorage( 'testfile.txt', ... , ppstgOpen1 ); > HRESULT = StgOpenStorage( 'testfile.txt', ... , ppstgOpen2 ); > > I expect *ppstgOpen2 not to be NULL in Windows while being NULL under > Wine. > > Best regards. > > Markus Uh, too fast when sending. Additionally the result code of HRESULT is needed to get a clearer picture. Best regards.
bug #9575 - better this time - testcase help needed
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.txt', ... , ppstgOpen2 ); I expect *ppstgOpen2 not to be NULL in Windows while being NULL under Wine. Best regards. Markus
RE: Help with a native Windows test program needed (CreateFileW).
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 to the malicous memory address before the application dump comes from CreateFileW. Best regards. Weitergeleitete Nachricht Von: wine-b...@winehq.org An: m...@collogia.de Betreff: [Bug 9575] IBExpert need windows native ole32.dll to run Datum: Sat, 12 Sep 2009 05:18:49 -0500 http://bugs.winehq.org/show_bug.cgi?id=9575 --- Comment #15 from Alexandre Julliard 2009-09-12 05:18:42 --- There's no such behavior. The test is broken.
Re: Help with a native Windows test program needed (CreateFileW).
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/11 Markus Stockhausen > > > 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', ..., dwShareMode = > 0, ...) > > Return the result of second call. I expect it to be a > valid handle on > Windows whereas Wine will return an invalid handle. > > Thanks in advance. > > Markus Thank you for your help, here is something really weird. I found someone to test the program in Windows 2003 and there we have completly different results: h0 : 0x07E0 - Result :0 h1 : 0x07E0 - Result : Sharing Violation The second call fails too, but it returns the last access handle to the file. So that means I need someone who can test the program http://www.ibexpert.com/download/setup_trial.exe in an Windows 2008 environment. It should fail as it does in Wine. Has anyone a good idea how to reflect/check this behaviour in a wine test? Best regards.
Help with a native Windows test program needed (CreateFileW).
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', ..., dwShareMode = 0, ...) Return the result of second call. I expect it to be a valid handle on Windows whereas Wine will return an invalid handle. Thanks in advance. Markus
Help with a native Windows test program needed (CreateFileW)
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', ..., dwShareMode = 0, ...) Return the result of second call. I expect it to be a valid handle on Windows whereas Wine will return an invalid handle. Thanks in advance. Markus
Re: bitblt.c - GdiAlphaBlend : Check for NULL Pointer
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 ret (as is done throughout this file).
>
Resending the desired changes and hoping to see them finding their way
into git ...
Best regards.
diff -ru wine/dlls/gdi32/bitblt.c new/dlls/gdi32/bitblt.c
--- wine/dlls/gdi32/bitblt.c 2009-09-10 22:44:09.0 +0200
+++ new/dlls/gdi32/bitblt.c 2009-09-11 09:08:09.0 +0200
@@ -518,9 +518,11 @@
DC *dcDst, *dcSrc;
dcSrc = get_dc_ptr( hdcSrc );
+if (!dcSrc) return FALSE;
+
if ((dcDst = get_dc_ptr( hdcDst )))
{
-if (dcSrc) update_dc( dcSrc );
+update_dc( dcSrc );
update_dc( dcDst );
TRACE("%p %d,%d %dx%d -> %p %d,%d %dx%d op=%02x flags=%02x srcconstalpha=%02x alphafmt=%02x\n",
hdcSrc, xSrc, ySrc, widthSrc, heightSrc,
@@ -533,7 +535,7 @@
xSrc, ySrc, widthSrc, heightSrc, blendFunction );
release_dc_ptr( dcDst );
}
-if (dcSrc) release_dc_ptr( dcSrc );
+release_dc_ptr( dcSrc );
return ret;
}
diff -ru wine/dlls/gdi32/tests/bitmap.c new/dlls/gdi32/tests/bitmap.c
--- wine/dlls/gdi32/tests/bitmap.c 2009-09-10 22:44:09.0 +0200
+++ new/dlls/gdi32/tests/bitmap.c 2009-09-11 00:35:22.0 +0200
@@ -2393,6 +2393,10 @@
expect_eq(pGdiAlphaBlend(hdcDst, 0, 0, 20, 20, hdcSrc, -1, 0, 30, 30, blend), TRUE, BOOL, "%d");
expect_eq(pGdiAlphaBlend(hdcDst, 0, 0, 20, 20, hdcSrc, 0, -1, 30, 30, blend), TRUE, BOOL, "%d");
+SetLastError(0xdeadbeef);
+expect_eq(pGdiAlphaBlend(hdcDst, 0, 0, 20, 20, NULL, 0, 0, 20, 20, blend), FALSE, BOOL, "%d");
+expect_eq(GetLastError(), 0xdeadbeef, int, "%d");
+
SelectObject(hdcDst, oldDst);
SelectObject(hdcSrc, oldSrc);
DeleteObject(bmpSrc);
Re: bitblt.c - GdiAlphaBlend : Check for NULL Pointer
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 passes.
>
Ok, attached you will find my second try. Testcase of Nicolay included
this time. Hopefully it will be better this time.
Best regards.
diff -ru wine/dlls/gdi32/bitblt.c new/dlls/gdi32/bitblt.c
--- wine/dlls/gdi32/bitblt.c 2009-09-10 22:44:09.0 +0200
+++ new/dlls/gdi32/bitblt.c 2009-09-11 00:29:39.0 +0200
@@ -518,9 +518,11 @@
DC *dcDst, *dcSrc;
dcSrc = get_dc_ptr( hdcSrc );
+if ( !dcSrc ) return ret;
+
if ((dcDst = get_dc_ptr( hdcDst )))
{
-if (dcSrc) update_dc( dcSrc );
+update_dc( dcSrc );
update_dc( dcDst );
TRACE("%p %d,%d %dx%d -> %p %d,%d %dx%d op=%02x flags=%02x srcconstalpha=%02x alphafmt=%02x\n",
hdcSrc, xSrc, ySrc, widthSrc, heightSrc,
@@ -533,7 +535,7 @@
xSrc, ySrc, widthSrc, heightSrc, blendFunction );
release_dc_ptr( dcDst );
}
-if (dcSrc) release_dc_ptr( dcSrc );
+release_dc_ptr( dcSrc );
return ret;
}
diff -ru wine/dlls/gdi32/tests/bitmap.c new/dlls/gdi32/tests/bitmap.c
--- wine/dlls/gdi32/tests/bitmap.c 2009-09-10 22:44:09.0 +0200
+++ new/dlls/gdi32/tests/bitmap.c 2009-09-11 00:35:22.0 +0200
@@ -2393,6 +2393,10 @@
expect_eq(pGdiAlphaBlend(hdcDst, 0, 0, 20, 20, hdcSrc, -1, 0, 30, 30, blend), TRUE, BOOL, "%d");
expect_eq(pGdiAlphaBlend(hdcDst, 0, 0, 20, 20, hdcSrc, 0, -1, 30, 30, blend), TRUE, BOOL, "%d");
+SetLastError(0xdeadbeef);
+expect_eq(pGdiAlphaBlend(hdcDst, 0, 0, 20, 20, NULL, 0, 0, 20, 20, blend), FALSE, BOOL, "%d");
+expect_eq(GetLastError(), 0xdeadbeef, int, "%d");
+
SelectObject(hdcDst, oldDst);
SelectObject(hdcSrc, oldSrc);
DeleteObject(bmpSrc);
Re: bitblt.c - GdiAlphaBlend : Check for NULL Pointer
Am Freitag, den 11.09.2009, 01:17 +0400 schrieb Nikolay Sivov: > Roderick Colenbrander wrote: > > Recently Nikolay Sivov wrote some tests for this call. His tests > > didn't make it in yet but I think those should enter and then based on > > those results changes should 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 Teamviewer application when a NULL pointer > >> is handed over. The attached check fixes that behaviour. > >> > >> Tanks in advance. > >> > >> Markus > >> > This is what Roderick is talking about: > > http://www.winehq.org/pipermail/wine-patches/2009-September/078293.html > > I don't think it will be committed, it should be included with a fix. > > You may take this part and resubmit: > --- > + SetLastError(0xdeadbeef); > + expect_eq(pGdiAlphaBlend(hdcDst, 0, 0, 20, 20, NULL, 0, 0, 20, 20, > blend), FALSE, BOOL, "%d"); > + expect_eq(GetLastError(), 0xdeadbeef, int, "%d"); > --- > > Phew, in 3 days from 0 to 100. Too much for me. If I get it right, there are two things to do. 1. I should optimize my patch and remove unnecessary dcSrc checks. 2. A testcase is needed to prove the correct function behaviour in Windows and Wine. The tastcase is already available but not commited yet. For me this means: 1. Wait for testcase implementation. 2. Create new patch and test under Wine 3. Ask someone to do test under Windows 2. Resent patch to mailing list. Thanks for your patience. Markus
regression: loader: Reserve some more memory to cover the native ole32 addresses.
commit 8d833ee2e7a1d8b82e2dccf51e0cbc20742a0833 Author: Alexandre Julliard Date: Thu Jun 25 14:19:09 2009 +0200 loader: Reserve some more memory to cover the native ole32 addresses. After this commit WoW with mesa/r500 falls back to indirect rendering. libGL tries to mmap 256M for the framebuffer but that fails with > libGL error: drmMap of framebuffer failed (Cannot allocate memory) Markus
Re: [dxdiagn] Implemented retrieval of b3DAccelerationEnabled property
On Monday 12 January 2009 11:50:27 Vitaliy Margolen wrote: > Markus wrote: > > +V_VT(&v) = VT_BOOL; V_BOOL(&v) = get_ddraw_acceleration(); > > +IDxDiagContainerImpl_AddProp( pDisplayAdapterSubCont, > > b3DAccelerationEnabled, &v ); +VariantClear(&v); > > Why don't you use add_prop_bool()? That was an oversight. I'll change the code in both files. Are there any other objections to the patches? http://www.winehq.org/pipermail/wine-patches/2009-January/067437.html http://www.winehq.org/pipermail/wine-patches/2009-January/067463.html -- Markus
Re: Implementing b3DAccelerationExists and b3DAccelerationEnabled in dxdiagn
On Wednesday 07 January 2009 06:55:12 Detlef Riekenberg wrote: > > This value should > > return true if e.g. hardware accelerated T&L is available on the system, > > which is primarily a result of driver and hardware capabilities. > > This is for b3DAccelerationExists and native dxdiagn in Wine with some > d3d* debug channels might help a bit. What I have found so far is that the native dxdiagn.dll retrieves the device capabilities using IDirect3D9Impl_GetDeviceCaps. However, I was unable to find any values for the caps struct, where the native dll would determine that b3DAccelerationExists was supposed to be false. The only result I got in that regard was that by setting caps->DevCaps to 0, a human readable warning about missing D3d9+ hardware acceleration would be added to szNotesLocalized. Does anyone have an idea on what else could be the basis for this flag? -- Markus
Re: Implementing b3DAccelerationExists and b3DAccelerationEnabled in dxdiagn
On Tuesday 06 January 2009 03:58:27 Detlef Riekenberg wrote: > On Mo, 2009-01-05 at 22:10 -0500, Markus wrote: > > can anyone tell me where to find information about the > > b3DAccelerationExists and b3DAccelerationEnabled properties in the > > display container returned by > > I suggest to use dxdiag and regmon on Windows. > In dxdiag, you can disable DirectDraw / Direct3D Acceleration. > Regmon will tell you, where the settings are saved. I do not think the registry is the correct place to look. This value should return true if e.g. hardware accelerated T&L is available on the system, which is primarily a result of driver and hardware capabilities. My current understanding is that a D3D caps struct would hold such information. The question now is which flag or combination of flags in it would cause the dxdiagn values to be 'true'? -- Markus
Implementing b3DAccelerationExists and b3DAccelerationEnabled in dxdiagn
Hello, can anyone tell me where to find information about the b3DAccelerationExists and b3DAccelerationEnabled properties in the display container returned by dxdiagn.dll and when they are supposed to be false or true? In fact, MSDN does not seem to provide information about any of the properties returned by that dll. Thanks, -- Markus
Re: Status of dxdiagn?
On Friday 02 January 2009 10:58:48 Dan Kegel wrote: > Got another game that needs dxdiagn fixes? Personally, I don't know of any other games that need dxdiagn fixes but I guess you already identified potential candidates earlier. > Or they could go ahead and do dxdiag on top of dxdiagn. That might be a good idea as it would simplify dxdiagn development by offering a GUI showing the retrieved values and those still missing. -- Markus
Re: Status of dxdiagn?
On Thursday 01 January 2009 22:35:51 Dan Kegel wrote: > On Thu, Jan 1, 2009 at 5:13 PM, Dan Kegel wrote: > >> In order to reach support for the two acceleration properties, I have > >> just submitted an updated patch based on my code from mid-2008: > >> http://www.winehq.org/pipermail/wine-patches/2009-January/066929.html > > > > World In Conflict is affected by this, right? > > http://bugs.winehq.org/show_bug.cgi?id=4 > > Looks like it (the demo, too). Yes, World in Conflict is what I am trying to fix dxdiagn for. The szDeviceIdentifier property added by the above patch is a prerequisite to have the game continue checking for 3D capabilities of the system. If szDeviceIdentifier is not present, the check will already consider 3D not to be available. > I got the demo to start by dropping in a native dxdiagn and disabling > d3dx10 as described in the full game's howto at > http://appdb.winehq.org/objectManager.php?sClass=version&iId=9237 > Sadly, I get no video other than the cursor, and I haven't > the foggiest idea of how to quit the game, so I have to kill > it from another terminal. The game used to run very well with previous versions of Wine. I am seeing the black screen too with HEAD, so this is possibly an unrelated recent regression. As long as the game starts, you're ok in regard to dxdiagn. > This is promising, though. The student could have the goal > of fixing dxdiagn so that wic's demo starts. If my patch above is accepted, only the two b3D properties remain to be implemented and then WiC should start fine. I don't think that is big enough of a project. -- Markus
Re: Status of dxdiagn?
Hi Dan, I have not worked on dxdiagn for a few months due to a lack of time. As far as missing functionality is concerned, I have only investigated properties related to the display container. I suspect that many games are trying to read the b3DAccelerationExists and/or b3DAccelerationEnabled properties in it to determine if 3D acceleration is available. However, compared to dx9, there are more than 45 other properties missing for this container alone, so there is still a lot of work left to be done. In order to reach support for the two acceleration properties, I have just submitted an updated patch based on my code from mid-2008: http://www.winehq.org/pipermail/wine-patches/2009-January/066929.html I will try to re-submit the test case in the next days depending on my time. Regarding an implementation of dxdiag.exe, it might be a good idea to first add all the missing properties to the dll, at least as stubs. Without them, there doesn't seem to be that much to retrieve and display with dxdiag.exe Markus On Sunday 28 December 2008 00:28:56 Dan Kegel wrote: > Hi Markus, > what's the status of dxdiagn these days? I see a number > of games that say they need a native copy: > http://www.google.com/search?q=dxdiagn+site%3Aappdb.winehq.org > Do you know what needs doing before we can get > native dxdiag working, > http://bugs.winehq.org/show_bug.cgi?id=1429 ? > > Also, how about your dxdiagn conformance test? > http://www.winehq.org/pipermail/wine-patches/2008-May/055355.html > I know it didn't do much, maybe you could have it check a > few required properties? > > I ask because I'm looking around for a student project, > and implementing dxdiag.exe came to mind; looking > around a bit, I saw dxdiagn, and figured it might be nice > to tie up some loose ends there, too. > - Dan -- Markus
Re: Windows version autodetection
Am 22.12.2008 um 11:51 schrieb Reece Dunn: > The same goes for applications released after Vista was released, but > only work well on XP. The date heuristic will say "Vista", ... just like the current-heuristic-less assumption. Undoubtly, there are many cases where a date heuristic doesn't help, but it won't worsen matters either. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: Windows version autodetection
Am 22.12.2008 um 05:16 schrieb Chris Robinson: > On Sunday 21 December 2008 07:48:58 pm Damjan Jovanovic wrote: >> The heuristic isn't "app works on this Windows version", it's "app is >> designed for this Windows version". > > Should that matter? Plenty of Win95 apps will work in WinXP. ... because WinXP has such a version heuristic already in place? I think it's perfectly possible to do an heuristic which is sometimes useful, but never harms. As already mentioned, the age of the installer/installed files is such a data point: Apps written in 1996 are never ever designed to run on WinXP. It's a matter of being conservative enough. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: wow, there are more win64 apps than I thought...
Am 20.12.2008 um 13:42 schrieb Dan Kegel: > I updated http://wiki.winehq.org/Wine64 with a list > of some win64 apps. There are lots more than I > expected. Well, Catia comes with a 64-bit flavour as well, like probably any serious CAD or FEA package. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: Canonical and wine
Am 13.12.2008 um 01:12 schrieb Ben Klein: > But I have to ask, what exactly is this system going to > replace? > > Current equivalent method is: > 1) Try your app with Wine > 2) If it doesn't work, check appdb for Wine version compatibility > 3) Follow any instructions on the appdb page, such as reg > settings/hacks, DLL overrides, specific Wine versions > 4) If it works, yay for you > > This proposal of packages for proprietary Windows software follows > these steps, then adds a step 5) Create a package based on what you've > found that automates step 3. I argue that a more correct way to deal > with this is education of newbies. As far as I followed the discussion, you'd replace 1) to 3). The one simple rule you'd have to teach people is "Before installing Windows software, install the appropriate compatibility package". Alternatively, if you want to have something like a default Wine package, teach them: "If your app doesn't work, look for a compatibility package". IMHO, the former is the better, because it's more consistent. You could name the packages like "Wine for Adobe applications" to avoid thousands of new packages. Also, "doesn't work" is a weak description, as non-working features might not be noticed by the user immediately. Third, it's likely tricky to replace Wine with a different version of Wine with the app already installed along other apps on a drive_c. BTW, how would you interact between different Windows apps running on different versions of Wine? MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: patch for gdi32
Am 04.12.2008 um 00:38 schrieb Xiangrong Fang: > but that is marked as FIXED and CLOSED?? Yes, Wine developers are sometimes pretty quick at closing bugs. The sad thing is, you can't comment on closed bugs and have to open a new one. > BTW, for these discussions, shall I use wine-devel or wine-patch? wine-patches is for patches only, -devel is where discussions should go. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: RFC: Wine Icons
Am 14.11.2008 um 18:46 schrieb Branan Riley: > On Mac, you should use the native mac icons, but that might not > work to do Obj-C issues On the Mac, icons are stored in separate files, so there's no need for system calls or Obj-C. Find them with find /System -name \*.icns Unfortunately, they are in the uncommon ICNS format. Here's a procedure to convert them to the PNG format: <http://slaptijack.com/graphics-design/converting-mac-os-x-icon-files- to-png/> I have the "sips" tool mentioned there installed, so it's likely part of the standard distribution. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: Bugzilla - Add keyword and remove OS's
Am 14.11.2008 um 15:11 schrieb James Mckenzie: > Markus: > > I don't think that Wine will build on MacOS 9 or earlier anymore. > > James McKenzie You might remember a very similar request, just over six weeks ago: <http://article.gmane.org/gmane.comp.emulators.wine.devel/63639> It was turned down, then. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: Bugzilla - Add keyword and remove OS's
Am 14.11.2008 um 10:15 schrieb Kai Blin: > On Friday 14 November 2008 09:53:03 Markus Hitter wrote: >> Am 14.11.2008 um 00:15 schrieb Austin English: >>> Howdy, >>> >>> The OS list in bugzilla is a bit excessive. [...] >>> Mac System 7 >>> Mac System 7.5 >>> Mac System 7.6.1 >>> Mac System 8.0 >>> Mac System 8.5 >>> Mac System 8.6 >>> Mac System 9.x >> >> You could merge them to "MacOS 9 and before" > > What's the point? Wine doesn't run on PPC anyway. Really? <http://darwine.sourceforge.net/> MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: Bugzilla - Add keyword and remove OS's
Am 14.11.2008 um 00:15 schrieb Austin English: > Howdy, > > The OS list in bugzilla is a bit excessive. [...] > Mac System 7 > Mac System 7.5 > Mac System 7.6.1 > Mac System 8.0 > Mac System 8.5 > Mac System 8.6 > Mac System 9.x You could merge them to "MacOS 9 and before" MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: winedos interrupts getting lost.
Peter Dons Tychsen wrote: > Hello. > > It starting with me trying to figure out why i was loosing keyboard > events in winedos. > > 1) I then traced the keyboard events to a call to signal(SIGUSR2) in > function DOSVM_QueueEvent(). > > 2) The signal() triggers code in ntdll, which generates an exception > EXCEPTION_VM86_STI for the current vm86 context. > > 3) The exception is supposed to trigger exception_handler(), which will > then handle the keyboard event, by kicking the event queue. > > This never happens however, as the mechanism stops working very quickly. > > I found out the code gets to raise_vm86_sti_exception in ntdll, and then > stops. ntdll_get_thread_data()->vm86_ptr is NULL, so the STI exception > is never signaled. > > Does anyone know more about the exception subsystem, and what could be > causing this kind of strange behavior? > > I can mention that the system can generate EXCEPTION_VM86_INTx > exceptions successfully, but fails to execute the EXCEPTION_VM86_STI. > > Thanks, > > /pedro > One issue with dos input is (was?), that since 2.6 linux kernel we should signal the thread not the process. Have a look at [1]. That patch once fixed all my dos input issues, although I haven't looked at this stuff for quite some time. I'm not sure you have the same problem, just a possible hint. Markus [1] http://www.winehq.org/pipermail/wine-patches/2004-November/013645.html
Re: Sugared Wine
Am 11.10.2008 um 16:30 schrieb Jeremy White: > But the key point was that he immediately and *emotionally* was > grabbed by the value of Wine. He grabbed _a_ value of Wine, but not the one making Wine unique, standing out of the crowd of countless competitive technology. Perhaps he even grabbed the wrong value, putting Wine on par with Qemu, VMware, VirtualPC, VirtualBox, and all the others. > And Wine is fundamentally different from and better than PC > emulation technology. Well, what "better" means can always be discussed. For me, emulators just work, running any application I throw at them. At the same time, Wine is making me headaches and often requires a lot of thinking. Also, Wine will always be somewhat behind Microsofts newest API creations by it's very nature. The single most important app in my business runs flawlessly in an emulator since the first time I tried. Nevertheless, I've put a lot of efforts into getting it to run in Wine. Wine has strengths you can't see at a first glance. > But the bottom line is that we're human, and our brains work in > funny ways. Yes. You're teaching "If you want to use commodity apps, use Sugar. If you want to use more powerful apps, switch to Windows mode. If you want to share files between them, understand how these two work together." Don't forget, young people don't have the brand recognition-like experience with the taskbar your John Gilmore has. Unless I miss something, there's no need to give it them, either. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: Sugared Wine
Am 11.10.2008 um 03:03 schrieb Vincent Povirk: > Getting Wine to actually work in that environment was harder than > anticipated, and taking a desktop that (in my opinion) is good for > Wine generally and dropping it into sugar did not produce something > that works well in sugar. Judging by the photoshopped image you put an an Windows-like desktop designed for adults into a desktop designed for childs. Now, if you'd at least hide the original (sugar) desktop you'd re-gain precious screen space and wouldn't have to explain the childs when to use which of both desktops. For me, I've always considered the strength of Wine to provide a seamless integration into the original operating system / desktop and _not_ to come with it's own taskbar / launch system. For the Windows- like experience, I'd always prefer an hardware emulator. Sorry to have no more encouraging comments. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: winequartz.drv Mac OS X UI discontinued?
Am 02.10.2008 um 20:16 schrieb Saulius Krasuckas: > * On Thu, 10 Jul 2008, Adam Strzelecki wrote: >>> Is it really technically impossible to access the Quartz APIs or >>> write Mac applications using C? >> >> Well it is possible, for example iTunes is non Objective-C Carbon >> (API) app AFAIK. Problem is that Carbon (pure C interface) is >> considered as deprecated by Apple and may disappear from future >> releases of OSXes at all, most 98% of applications are Objective-C >> Cocoa anyway. Moreover most of the functionality introduced in >> 10.5 or >> 10.4 went just into Cocoa, and never was backported to Carbon. >> So it isn't matter that it isn't possible, but it is IMHO more >> reasonable to do it in Objective-C. > > Then what about some thunking from carbonic source code to binary > Objective-C code? While the above is correct, modern Cocoa, in opposite to it's precedessor NeXTstep/OpenStep, is based on Quartz and CoreFoundation, both of which are plain C APIs. There's no need for neither Carbon nor Cocoa nor Objective-C to get some basic graphics to the Mac OS X screen. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: Discussion of bug versions
While on the topic, please remove Mac OS up to 10.3 from the list of operating systems. Mac OS X 10.4.x was the first publicly available Macintosh OS running on Intel processors, so there won't ever be anybody running Wine on e.g. MacOS 9. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: Detecting Wine
Am 30.09.2008 um 12:55 schrieb Eric Pouech: > Your design is wrong IMO. You don't handle reparse points at all; > you only > rely on the nature of a drive, which isn't sufficient in most > cases. See > mounting volumes for example where you can mount a whole volume > anywhere in > an NTFS partition. > > The correct fix would be to: > - ensure your code handles those cases correctly (which it doesn't) > - ensure that wine returns the correct relevant information for remote > mounted FS (which I'm pretty sure sure it's not done today) A reasonable 99% shortcut would probably be to parse C: only. This should be sufficient for almost all users, especially the clueless ones, on Wine as well as on Windows. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Taking advantage of debug libraries
Hello all, now, as I get better and better on juggling with the various debugger options, I'm at a point where I'd like to get advantage of MS' C++ runtime debug libraries. Looking at MSDN, they recommend to turn a few switches in the IDE and ... but this won't work, as I can't re-link my binary. Looking at what my app does, it obviously looks for mfc70.dll and is satisfied with getting mfc80.dll. To a Unix guy like me this looks weird. All Visual C++ distributions I could have a look at come with mfc42* libraries, no matter how recent the IDE distro is. So I've put this into C:/windows/system and hoped for even more magic - but it didn't happen. Still segment names only in winedbg. My question is: is it possible to take advantage of the mfc42d.dll/ mfc42d.map/mfc42d.pdb file trio to get debug symbols in winedbg? Or perhaps even in generic gdb? If yes, where would I put these files or how would I load their tables into the debugger? Thanks, MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: Debugging Wine thoughts
Am 10.09.2008 um 17:32 schrieb Stefan Dösinger: > You can attach any debugger to a Win32 process running in Wine. This > includes Linux debuggers like gdb, [...] As I didn't find hints on how to do this I tried myself: ** First, start gdb in the C: directory [EMAIL PROTECTED]:/otherubuntu/home/mah/.wine/drive_c$ gdb GNU gdb 6.8-debian Copyright [...] This GDB was configured as "x86_64-linux-gnu". (gdb) file wine Reading symbols from /usr/local/bin/wine...done. (gdb) directory /otherubuntu/home/mah/wine/ Source directories searched: /otherubuntu/home/mah/wine:$cdir:$cwd (gdb) ** Then, run the app (gdb) run windows/notepad.exe Starting program: /usr/local/bin/wine windows/notepad.exe [Thread debugging using libthread_db enabled] [New Thread 0xf7c628c0 (LWP 793)] [New Thread 0xf7c61b90 (LWP 796)] [Thread 0xf7c61b90 (LWP 796) exited] [New process 793] Executing new program: /usr/local/bin/wine-preloader warning: Cannot initialize thread debugging library: generic error warning: Cannot initialize thread debugging library: generic error [New process 793] Fontconfig warning: "/etc/fonts/conf.d/53-monospace-lcd-filter.conf", line 17: invalid constant used : lcdlegacy Fontconfig warning: "/etc/fonts/conf.d/53-monospace-lcd-filter.conf", line 17: invalid constant used : lcdlegacy Fontconfig warning: "/etc/fonts/conf.d/53-monospace-lcd-filter.conf", line 17: invalid constant used : lcdlegacy ** Notepad should be running here. Interrupt it from the command line to have a look: ^C Program received signal SIGINT, Interrupt. 0xf7fec430 in ?? () (gdb) bt #0 0xf7fec430 in ?? () #1 0x0008 in ?? () #2 0x7bc76516 in ?? () #3 [...] (gdb) list 1 /* 2* Preloader for ld.so 3* 4* Copyright (C) [...] As you see, listing appears to work in principle, while symbol lookup doesn't. It's no secret Wine runs multiple processes and Windows applications run multiple threads, so you might want to look up how to handle this in gdb: http://sources.redhat.com/gdb/current/onlinedocs/gdb_5.html My tries to break not into the preloader, but the actual Windows application weren't successful so far, gdb's console appears to lock up somehow when setting follow-fork-mode & friends. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Peb->BeingDebugged and a debugger messing up
Hello all, after wrestling severals days with Wine's debugging capabilities I think I need some advice. First, regardless wether my app (Catia) is launched with wine or winedbg, Peb->BeingDebugged is always False. To the best of my efforts I can't find the code snippet which sets this variable or does some sort of probing for the correct value. Oddly enough, the app breaks into the debugger after creation of a new process, anyways. As the app uses a launcher, I have the chance to set BeingDebugged explicitely to True. Some time later, after the app created a few threads, it's back to False. Are there applications out there setting this flag to what they think is best? Any other possible reasons for going BeingDebugged back to False while running in winedbg? None of the functions Wine provides and handles this variable appears to be called by the application. Third thing is, Wine's attempt to auto-launch the debugger messes up. Not only if BeingDebugged is reported wrongly, it obviously runs in conflicts if launched due to a exception stack overflow. Is it really wise to launch it by triggering an interrupt in DbgBreakPoint()? Short of better suggestions, I'd try to make debugger launching independent from Peb->BeingDebugged (server/kernel should know better), try to get rid of the interrupt in DbgBreakPoint() and/or make debugger autolaunching optional (at compile time). What do you think? Thanks, MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: crypt32: fixed the testGetCertChain tests on Vista.
Am 08.09.2008 um 01:30 schrieb James Hawkins: > For example, the following is significantly easier to read: > > ok(result == ERROR_BUFFER_TOO_SMALL || > result == ERROR_INVALID_USER_BUFFER || /* win98 */ > result == ERROR_INVALID_DATA, /* Vista */ > "Expected ERROR_BUFFER_TOO_SMALL, got %08d\n", result); Wouldn't it be even better to print the expected number in the same format as the actually received result? ... "Expected ERROR_BUFFER_TOO_SMALL (%08d), got %08d\n", ERROR_BUFFER_TOO_SMALL, result); This should ease log reading as well. MarKus
Re: ntdll/file.c: Fix a possible NULL dereferencing.
Am 27.08.2008 um 11:27 schrieb Nikolay Sivov: > Markus Hitter wrote: >> if (!attr || !attr->ObjectName) return STATUS_INVALID_PARAMETER; > Shouldn't this be splitted? It isn't safe to rely on evaluation order. > Or is it a default compiler setting for us? You know, this isn't part of the patch and answering to a patch submission essentially means it won't be applied. Thanks Gentlemen, my duties are done. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: ntdll/file.c: Allow to TRACE NtCreateFile return
Am 27.08.2008 um 11:40 schrieb Dmitry Timoshkov: > We all are in the same boat. Next time, please try to speak up earlier and more clearly. Four reviews, three patch reworks were done and about 20 messages were written, just to find out _any_ change is not welcome. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: ntdll/file.c: Allow to TRACE NtCreateFile return
Am 27.08.2008 um 10:14 schrieb Dmitry Timoshkov: > "Markus Hitter" <[EMAIL PROTECTED]> wrote: > >> Providing the file handle allows to map >> read/write requests to the corresponding file name. > > As pointed out by Alexander, you can use an appropriate debug > channel for that, +relay or +server. There is no need to pollute > the source with additional traces. If you think this way, you should get rid of all the TRACE()s in this source file. For me, it makes a difference, wether I can focus on file operations or if I have to wade through gigabyte-sized (no joke) log files. To give you an example how it looks: trace:ntdll:NtCreateFile handle=0x339750 access=8000 name=L"\\??\ \C:\\Programme\\Dassault Systemes\\B16\\intel_a\\EnvName.txt" objattr=0042 root=(nil) sec=(nil) io=0x339724 alloc_size=(nil) attr=0080 sharing=0003 disp=1 options=0050 ea=(nil). 0x trace:ntdll:NtCreateFile returning handle 0x144 trace:ntdll:NtReadFile (0x144,(nil),(nil),(nil), 0x3397c4,0xd93888,0x1000,(nil),(nil)),partial stub! trace:ntdll:NtReadFile = SUCCESS (17) All but one of these lines are already there. As there's nothing left to simplify, I take this patch back. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Patch workflow recommendations (was: Re: shlwapi ...)
Am 26.08.2008 um 16:46 schrieb Dan Kegel: > I updated http://wiki.winehq.org/SubmittingPatches with that info > (and lots more, too) The git sample commands there differ from the ones given in by the --keep-subject flag. Which one would be the better one? Citing the web page: > If your patch isn't committed in a day or two, improve it (perhaps > by adding more tests) and resend. Or continue on with more changes, > and send a longer patch series next time. Judging by my recent experience, how about: > If your patch isn't committed in a day ot two, first have a look at > the patchwatcher status page, wether your patch were approved. If > it was, you might want to ask on the wine-devel mailing list on how > it could be improved. Especially with your first patches, it might > take a resend or two to get it accustomed to the Wine development > process. I'd avoid recommending longer patch series. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: Add TRACEs to NtCreateFile returns (second try)
Am 26.08.2008 um 01:33 schrieb Juan Lang:
> It seems your tolerance for reworking patches is rather low.
Currently, yes. I'll have to take a breath.
> -if (!attr || !attr->ObjectName) return STATUS_INVALID_PARAMETER;
> +if (!attr || !attr->ObjectName)
> +{
> +TRACE("returning STATUS_INVALID_PARAMETER\n");
> +return STATUS_INVALID_PARAMETER;
> +}
>
> I agree with James that this is superfluous, or at least that it
> doesn't match the style of dlls/ntdll/file.c: when error is
> encountered, e.g. in NtReadFile line 568, it's returned directly.
It's returned, but won't show up in the console. I thought the idea
of TRACE()s is to allow some sort of cheap printf()-style debugging
and should be complete. Perhaps there are other uses I didn't figure
yet.
> if (attr->RootDirectory)
> {
> FIXME( "RootDirectory %p not supported\n", attr-
> >RootDirectory );
> +TRACE("returning STATUS_OBJECT_NAME_NOT_FOUND\n");
>
> Adding a trace after a fixme is clearly superfluous.
OK.
> -if (io->u.Status == STATUS_SUCCESS) io->Information =
> FILE_OPENED;
> +if (io->u.Status == STATUS_SUCCESS)
> +{
> +io->Information = FILE_OPENED;
> +TRACE("returning STATUS_SUCCESS, handle %p\n", *handle);
> +}
> +else
> +TRACE("returning 0x%08x\n", io->u.Status);
> return io->u.Status;
>
> Since the return is done regardless if the status, why do you trace a
> different value depending on the status?
Because *handle is valid on success only and to not confuse the
observer with invalid handles. Perhaps this is more care than needed.
> Please try to minimize the changes you're making
Sure. After the breath :-)
MarKus
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/
Re: Add TRACEs to NtCreateFile returns (second try)
Am 25.08.2008 um 21:39 schrieb James Hawkins:
As the code stands now, regardless of your patch, the check for
NULL attr on line 154 of dlls/kernel32/file.c will never be hit
because we will crash in the TRACE on line 148 of dlls/kernel32/
file.c.
Now I got it. You aren't talking about the TRACE() you cited, but a
different one. Thanks for the line numbers, applied to dlls/ntdll/
file.c they make sense.
So, why not fix this? Please push the patch trough Wine's patch
accepting mechanism yourself, I'm currently somewhat sick of it.
From e24b273d367aee0f200a0f57ddcceeac2396bf54 Mon Sep 17 00:00:00 2001
From: Markus Hitter <[EMAIL PROTECTED]>
Date: Tue, 26 Aug 2008 00:48:53 +0200
Subject: [PATCH] Fix a possible NULL dereferencing.
Spotted by James Hawkins, the variable at risk is "attr".
---
dlls/ntdll/file.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/dlls/ntdll/file.c b/dlls/ntdll/file.c
index 21f028a..d70bce2 100644
--- a/dlls/ntdll/file.c
+++ b/dlls/ntdll/file.c
@@ -145,17 +145,19 @@ NTSTATUS WINAPI NtCreateFile( PHANDLE handle, ACCESS_MASK
access, POBJECT_ATTRIB
ANSI_STRING unix_name;
int created = FALSE;
-TRACE("handle=%p access=%08x name=%s objattr=%08x root=%p sec=%p io=%p
alloc_size=%p\n"
- "attr=%08x sharing=%08x disp=%d options=%08x ea=%p.0x%08x\n",
- handle, access, debugstr_us(attr->ObjectName), attr->Attributes,
- attr->RootDirectory, attr->SecurityDescriptor, io, alloc_size,
- attributes, sharing, disposition, options, ea_buffer, ea_length );
+TRACE( "handle=%p access=%08x io=%p alloc_size=%p attr=%08x\n"
+ "sharing=%08x disp=%d options=%08x ea=%p.0x%08x\n",
+ handle, access, io, alloc_size, attributes, sharing, disposition,
+ options, ea_buffer, ea_length );
if (!attr || !attr->ObjectName)
{
TRACE("returning STATUS_INVALID_PARAMETER\n");
return STATUS_INVALID_PARAMETER;
}
+
+TRACE( "name=%s objattr=%08x root=%p sec=%p\n",
debugstr_us(attr->ObjectName),
+ attr->Attributes, attr->RootDirectory, attr->SecurityDescriptor );
if (alloc_size) FIXME( "alloc_size not supported\n" );
--
1.5.6.3
My comment still stands that the added TRACE is absolutely
superfluous.
Makes 2 pro, 1 neutral. Do whatever you want with it.
MarKus
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/
Re: Add TRACEs to NtCreateFile returns (second try)
Am 25.08.2008 um 17:58 schrieb James Hawkins:
> On Mon, Aug 25, 2008 at 3:12 AM, Markus Hitter <[EMAIL PROTECTED]>
> wrote:
>>
>> Am 25.08.2008 um 01:31 schrieb James Hawkins:
>>
>>> 2008/8/24 Markus Hitter <[EMAIL PROTECTED]>:
>>>
>>> -if (!attr || !attr->ObjectName) return
>>> STATUS_INVALID_PARAMETER;
>>> +if (!attr || !attr->ObjectName)
>>> +{
>>> +TRACE("returning STATUS_INVALID_PARAMETER\n");
>>> +return STATUS_INVALID_PARAMETER;
>>> +}
>
> If attr is NULL, you'll crash in the TRACE.
Pardon. If attr is NULL, the TRACE() isn't even reached.
As I obviously can't follow you how the additional TRACE() makes the
code more fragile, please go ahead and post a short sample code
showing how the above snippet is done right. Thanks.
Markus
P.S.: I took the freedom and extended your patch citation slightly.
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/
Re: Add TRACEs to NtCreateFile returns (second try)
Am 25.08.2008 um 01:31 schrieb James Hawkins:
> 2008/8/24 Markus Hitter <[EMAIL PROTECTED]>:
>>
>
> +if (!attr || !attr->ObjectName)
> +{
> +TRACE("returning STATUS_INVALID_PARAMETER\n");
> +return STATUS_INVALID_PARAMETER;
> +}
>
>
> These are all very useless TRACES, except for possibly the returned
> handle value.
Well, the idea is to TRACE() something for all possible return
values. Michael Karcher, Rob Shearman and me obviously consider them
as useful:
<http://thread.gmane.org/gmane.comp.emulators.wine.patches/54527/>
> As a side note of something I just noticed, the check for NULL attr
> will never be true because we'll crash in the TRACE when we
> dereference attr.
In case of (attr == NULL), same as (!attr), the code right to the ||
shouldn't be reached, so no dereferencing should take place, then.
TRACE()/printf() is capable of handling 0/NULL/nil values as well.
BTW., the TRACE() in the code you cited doesn't dereference anything
and for the other parts of the patch, dereferencing only takes place
where the current code dereferences anyways.
MarKus
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/
Re: New kernel development guide might be good model for Wine...
Am 19.08.2008 um 00:41 schrieb James Hawkins: > when the patch doesn't get committed, you should look back at it > and really think > outside the box about what could possibly be wrong with the patch. Essentially, you ask to change code on unfounded guesses (I did the best to my knowledge in the first place already) and to commit into a black hole until some unknown, not communicating person is satisfied to her/his taste. > You assume it wasn't noticed. I can guarantee that's not the case. So, what did the reviewing person then? Sitting there smiling "Heh, look, he could have done better, but, ha-ha, I won't tell him"? I hope this wasn't the case. > Give Alexandre a bit more credit than that. I'm fine with Alexandre personally but not so sure about Wine's current patch receiving process. That said I'm perfectly fine if Wine people consider this process as being effective. There's no law enforcing Wine to accept what I've sent. > [...] or ask the community or Alexandre what the problem is. Correct. Communication is a plus. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: New kernel development guide might be good model for Wine...
Am 18.08.2008 um 19:53 schrieb James Hawkins: > Why can't a developer review his own patch? If your patch is not > committed, the first thing you should do is look the patch over for > obvious mistakes. Obviously, some people here are used to receive more random diffs instead of carefully crafted patches. If there are obvious (to me) mistakes in a patch, I wouldn't even consider sending it. > then you can ask on wine-devel or IRC why your patch was rejected. ... or not even noticed. Thanks for the explanations, I'll take home "Wine developers don't care to be asked more than once". Thanks to Michael for reviewing my lines. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: New kernel development guide might be good model for Wine...
Am 18.08.2008 um 11:25 schrieb Michael Stefaniuc: > He [Alexandre] doesn't scale at replying to trivially "wrong" > patches but everybody > can reply to those and actually they should do that. Unfortunately, a developer can't review his patches himself and if the patch reviewing group is to busy to even drop a line "formatted wrongly" or "functionality not needed" it's unlikely new developers will ever pick up working for Wine. For now I've stopped my work as I haven't even an idea wether my patches will be applied some day, wether they were considered obsolete (they're small) or wether they are considered as wrong in some way. Worsely, there's no obvious way to learn how to do better as I followed the patch sending HowTo closely already. I'll try again in a few weeks, as suggested in the HowTo, and clutter Alexandre's mailbox even more. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: New kernel development guide might be good model for Wine...
Am 18.08.2008 um 06:57 schrieb James Hawkins: > Also, Julliard hasn't had trouble scaling with the pace of > development so far. I'd be not so sure about this. So far I've filed four bugs and sent two patches. Bugs get little or no attention, patches obviously rushed through unnoticed. Good thing is, with patchwatcher we have a tool for listing open patches now, allowing to monitor their status. At least I hope so. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: Is Wine portable to ARM arch?
Am 08.08.2008 um 20:24 schrieb Juan Lang: > It happens that the only platform > on which there might be some reason to write objective C is the Mac At the risk of getting even more off topic, Objective-C is one of gcc's dialects and works on Linux and *BSD just as fine as on Mac OS X. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: Bizarre idea: creating our own extension to msi for cross-platform installers
Am 27.07.2008 um 10:39 schrieb Scott Ritchie: > This way, a single .msi file could be a true universal installer for > both Windows machines and Linux machines. This is a good idea. However, if developers intentionally develop for Wine they can easily go a step further and build a native Linux (rpm, apt) package, even if they link against Wine libraries. The later will always have the better user experience as it integrates better into Linux distribution mechanisms and (optionally) frees from Windows' shortcomings. I doubt vendors will actively support (= be responsible for failures) installing apps with/in Wine. Even if they allow it or help fixing Wine bugs, this will always be a small but important niche. my $0.02 MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: crypt32/tests: check Vista error codes for the msg tests.
Am 23.07.2008 um 02:25 schrieb Reece Dunn:
>
> +/* last error -- NT: E_INVALIDARG, 9x/Vista: unchanged */
> +/* ret is FALSE on XP and earlier but TRUE on Vista, therefore
> it cannot be tested for */
> +ok((GetLastError() == E_INVALIDARG || GetLastError() ==
> 0xdeadbeef),
> + "Expected E_INVALIDARG or 0xdeadbeef, 0x%x\n", GetLastError
> ());
A more general question: Is it Wine's policy to just ignore
differences in behaviour between different Windows versions? From my
own (naive) standpoint I'd say something like this would be better
(pseudo-code):
if (WinVer <= XP) {
ok((!ret && [...]),
"Expected [...]);
} else {
ok((ret && [...]),
"Expected [...]);
}
Likely a often asked question, but I couldn't find hints about the
answer yet.
MarKus
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/
Visual Runtime conflicts with the debugger?
Hello all,
My pet app (Catia) works partially now. The thing most missing is, it
can't open a file. As soon as I attempt to do so, the app freezes for
a minute, then a "Visual C++ Runtime Exception" is shown. The shown
dialog doesn't feature any meaningful information.
So I moved from "wine" at the command line to "winedbg" to get a
grip. Unfortunately, this runtime exception doesn't cause the
debugger to jump in. All I get is one line:
> wine: Unhandled exception 0x8003 at address 0x7b844351 (thread
> 0027), starting debugger...
If I force the debugger to pay attention by typing Ctrl-C, I can even
get a tiny backtrace:
> Backtrace:
> =>1 0xe40e (0x0033f260)
> 2 0x0800 (0x0033f3a0)
> 3 0x7b84ab42 ReadFile+0x264(hFile=0x50, buffer=0x33f448,
> bytesToRead=0x800, bytesRead=0x33fcc0, overlapped=0x0) [/home/mah/
> wine/dlls/kernel32/file.c:451] in kernel32 (0x0033f420)
> 4 0x0040367b in catstart (+0x367b) (0x0033fc58)
Nevertheless, the app continues to run in the GUI as before, making
it impossible to check print variables or do stepping.
As a third chance, I tried "winedbg --gdb". However, this stops very
early:
> 0038:0013: exception code=0x8003
> warning: Target reported unsupported offsets:
> Text=00110e20;Data=00be;Bss=0008
> [New Thread 19]
> 0x7b8829fd in DbgBreakPoint () at ../../include/winternl.h:1828
> 1828 static inline void WINAPI DbgBreakPoint(void) { __asm__
> __volatile__("int3"); }
> trace: 98 => 80
After showing this, no debugger prompt follows and a Ctrl-C is
answered with a quit of both, the debugger and the app.
As a last resort I tried to insert printf() statements into the
source, finding me unable to repeat the numbers seen in the tiny
backtrace above. bytesToRead obviously never has the value 0x800 (=
2048).
So my question is: How would I go and debug such an issue? Is it even
possible to set breakpoints, to get meaningful backtraces and print()
statements and/or to catch Visual Whatever Runtime Exceptions?
Thanks,
Markus
P.S.: This is a current Wine (git) on Ubuntu 64-bit.
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/
Re: That tiny OpenGL app
Am 17.07.2008 um 11:21 schrieb Chris Robinson: > The cross-compiler comes with win32 import/static libs. Since MinGW > is a > Windows port of GCC (and the cross-compiler is basically a port > back), the > libs it comes with are native Windows. The -L switches, however, > point the > compiler to Wine's ELF libs, which the native .exe it produces doesn't > understand. This makes sense. Thanks for the explanation. >> I guess I'll have to set up a virtual machine running the real thing. >> There are so many levels of abstraction (64-bit Ubuntu -> 32-bit app, >> Linux environment -> Windows libraries, Linux build platform -> >> Windows binaries), making my setup pretty fragile. > > 64-bit Linux should run 32-bit Windows binaries fine with Wine. > OpenGL apps, > too. Of course you'll need the 32-bit Linux libs installed for Wine > to use, > however. I'm hunting for a few of the differences between "should" and "does" and try to catch them with test cases. See bug #10490. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: That tiny OpenGL app
Am 17.07.2008 um 01:04 schrieb Stefan Dösinger: >> -lopengl32 -lglu32 -o OpenGLBase.exe OpenGLBase.cpp >> /tmp/cclajgrA.o:OpenGLBase.cpp:(.text+0x10e): undefined reference to >> [EMAIL PROTECTED]' > I think this is in gdi32.dll Thanks for the suggestion. Tried to add them, but it doesn't make a difference. I guess I'll have to set up a virtual machine running the real thing. There are so many levels of abstraction (64-bit Ubuntu -> 32-bit app, Linux environment -> Windows libraries, Linux build platform -> Windows binaries), making my setup pretty fragile. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: That tiny OpenGL app
Am 17.07.2008 um 00:56 schrieb Chris Robinson: > On Wednesday 16 July 2008 03:38:37 pm Markus Hitter wrote: >> maybe I'm just missing the obvious, but I can't get my small one-file >> app to link. As I've just built Wine from scratch on this box, >> everything should be installed, including libGL... in /usr/lib32: > > Try linking with MinGW's libs, not Wine's. My understanding is, MinGW dosn't come with libs, but uses the native (Windows) ones. > Not sure if MinGW even understand ELF libs.. If I comment out the non-linkable lines, the apps runs under Wine and MessageBoxes pop up. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
That tiny OpenGL app
Hello all, maybe I'm just missing the obvious, but I can't get my small one-file app to link. As I've just built Wine from scratch on this box, everything should be installed, including libGL... in /usr/lib32: [EMAIL PROTECTED]:~/Wine Apps/GPWiki Framework$ make i586-mingw32msvc-g++ -pipe -mwindows \ -L/usr/local/lib/wine -L/lib32 -L/usr/lib32 \ -Wl,-rpath,/usr/local/lib/wine -Wl,-rpath,/lib32 -Wl,-rpath,/usr/ lib32 \ -lopengl32 -lglu32 -o OpenGLBase.exe OpenGLBase.cpp /tmp/cclajgrA.o:OpenGLBase.cpp:(.text+0x10e): undefined reference to [EMAIL PROTECTED]' /tmp/cclajgrA.o:OpenGLBase.cpp:(.text+0x134): undefined reference to [EMAIL PROTECTED]' /tmp/cclajgrA.o:OpenGLBase.cpp:(.text+0x15d): undefined reference to [EMAIL PROTECTED]' /tmp/cclajgrA.o:OpenGLBase.cpp:(.text+0x16a): undefined reference to [EMAIL PROTECTED]' collect2: ld returned 1 exit status make: *** [OpenGLBase.exe] Fehler 1 [EMAIL PROTECTED]:~/Wine Apps/GPWiki Framework$ for F in /lib32/* /usr/ lib32/* /usr/local/lib/wine/*; do if nm "$F" 2>/dev/null | grep glClearColor; then echo "$F"; fi; done U glClearColor 000621c0 T wine_glClearColor 000522f0 t wine_glClearColorIiEXT 00052240 t wine_glClearColorIuiEXT /usr/local/lib/wine/opengl32.dll.so 00102574 B glClearColor /usr/local/lib/wine/wined3d.dll.so [EMAIL PROTECTED]:~/Wine Apps/GPWiki Framework$ Short of solid knowledge I tried about anything I could imagine, but no joy. Any ideas, somebody? Thanks, MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: Compile error in wine-1.1.1
Am 15.07.2008 um 01:13 schrieb George Dunlap: > Downloaded wine-1.1.1.tar.bz2, and after unzipping, running configure > (which included adding some -dev libraries to make it happy) [...] You need really a lot of packages: <http://wiki.winehq.org/Recommended_Packages> If it still doesn't work, you can seek for the missing bits with: apt-rdepends -b --state-follow=NotInstalled wine ... and install packages until none but the kernel stuff and virtual packages are left in the list given by this command. Unfortunately, an "apt-get build-dep wine" recommended elsewhere didn't work for me. HTH, MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: How to phrase Wine's success rate
On Sunday 25 May 2008 20:41:51 Dan Kegel wrote: > One more try: > "Wine 1.0 runs apps like Photoshop CS2, World of Warcraft, Firefox 2, > and a thousand other apps (see http://appdb.winehq.org) well. > Try it on your favorite app and see if it works for you; the smaller > the app, the more likely it is to work well. > Photoshop CS3 and .NET applications are not yet supported. > Wine is continually improving, and many apps that didn't work well last > year work well now. Overall, about one in four apps tested work well as of > Wine 1.0. See the Wine FAQ (http://wiki.winehq.org) for more info." I think games are important to mention explicitly at least once. Therefore (+ a bit of restructuring): "Wine 1.0 runs thousands of applications and games well, among them Photoshop CS2 and World of Warcraft. To find out if your favorite applications work, try them on Wine yourself or consult our application database under http://appdb.winehq.org. While some complex applications such as Photoshop CS3 and software written with .NET are not supported yet, you will find that many simple applications will work. In addition, Wine is continually improving and we expect to support even more applications in the future. Overall, about one in four tested applications work well as of Wine 1.0. See the Wine FAQ (http://wiki.winehq.org) for more info." -- Markus
Regression in wined3d: Add read_from_framebuffer_texture which combines code from read_from_framebuffer (drawpixels) and LoadLocation.
Hi,
after investigating reports for the game 'World in Conflict', I identified the
following patch to cause the game graphics to freeze (ambient sounds are
still played though):
ba90a740beb9ce9a839cc843db8d87f5a37becdd is first bad commit
commit ba90a740beb9ce9a839cc843db8d87f5a37becdd
Author: Roderick Colenbrander <[EMAIL PROTECTED]>
Date: Sun Feb 10 22:20:15 2008 +0100
wined3d: Add read_from_framebuffer_texture which combines code from
read_from_framebuffer (drawpixels) and LoadLocation.
This makes the code easier to read and the pieces borrowed from
read_from_framebuffer are more correct than the code in LoadLocation.
:04 04 74e4bdc73e367c8f38cd3d0818df0fc86eb788bf
3e54409be7c9d2964efbf3d3c2f3d3b84a267047 M dlls
The freezes only seem to occur if the native (Windows) dxdiagn.dll is used, as
it lets the game properly detect the graphics card and thus enables
additional graphics options (highend shaders, high-res textures, etc.).
Apparently the freeze is only triggered with these options active.
The game uses events in its drawing code and ("always") hangs after the
following output:
fixme:d3d9:D3DPERF_BeginEvent (color 0x, name L"Update verlet
cloth") : stub
fixme:d3d9:D3DPERF_EndEvent (void) : stub
At one point, it was followed by this error:
err:d3d_surface:surface_prepare_system_memory Surface without memory or pbo
has SFLAG_INSYSMEM set!
The point of the freeze appears to depend on many factors. If I move the
camera around, it appears to freeze earlier than just letting the game run
(e.g. a replay of a match). But once the patch is excluded, the game no
longer freezes.
If more info is needed, please specify how I can obtain it.
--
Markus
Re: Shader compiler GL error
On Wednesday 16 January 2008 20:31:51 you wrote: > > fixme:d3d_surface:flush_to_framebuffer_drawpixels >>>>>>>>>>>>>>>>> > > GL_INVALID_VALUE (0x501) from glDrawPixels @ surface.c / 1061 > > You should get see what gets passed to glDrawPixels. According to the > opengl man pages GL_INVALID_VALUE can occur if e.g. the dimensions are > invalid. If these are indeed invalid, you need to figure out why they are > wrong (I see that the pitch is 6400, which could mean a width of 1600 > assuming bpp=4) This is a trace of the variables used to create the glDrawPixels call: trace:d3d_surface:flush_to_framebuffer_drawpixels right 0, left 0, bottom 0, top 0, mem 0x5db0040, bpp 4, pitch 6400 I assume GL is complaining because the rectangle passed to it has a size of (0,-1). Adding a simple right>left and bottom>top condition at least resolves this error. However, whether that is correctly emulating D3D behavior, I don't know. -- Markus
Re: Shader compiler GL error
On Wednesday 16 January 2008 18:41:46 you wrote:
> > the game's cached shaders. The game now crashes on startup with the
> > following
> > error:
> > fixme:d3d_surface:flush_to_framebuffer_drawpixels >>>>>>>>>>>>>>>>>
> > GL_INVALID_VALUE (0x501) from glDrawPixels @ surface.c / 1061
>
> You should try running the app with '+d3d_surface' on.
Here is (hopefully relevant) output with +d3d_surface set:
trace:d3d_surface:IWineD3DSurfaceImpl_LoadLocation Surface 0x4e8fdf0 is an
onscreen surface
trace:d3d_surface:IWineD3DSurfaceImpl_LoadLocation
(0x4e8fdf0)->(SFLAG_INDRAWABLE, (nil))
trace:d3d_surface:IWineD3DBaseSurfaceImpl_GetPitch (0x4e8fdf0)
trace:d3d_surface:IWineD3DBaseSurfaceImpl_GetPitch (0x4e8fdf0) Returning 6400
trace:d3d_surface:IWineD3DBaseSurfaceImpl_GetPitch (0x4e8fdf0)
trace:d3d_surface:IWineD3DBaseSurfaceImpl_GetPitch (0x4e8fdf0) Returning 6400
trace:d3d_surface:IWineD3DBaseSurfaceImpl_GetContainer (This 0x4e8fdf0, riid
{34d01b10-6f30-11d9-c687-00046142c14f}, ppContainer 0x1a9daa8)
trace:d3d_surface:IWineD3DBaseSurfaceImpl_GetContainer Relaying to
QueryInterface
trace:d3d_surface:surface_get_gl_buffer (0x4e8fdf0) : swapchain 0x4e7cc58
trace:d3d_surface:surface_get_gl_buffer Returning GL_BACK
trace:d3d_surface:flush_to_framebuffer_drawpixels Unlocking 0x405 buffer
trace:d3d_surface:flush_to_framebuffer_drawpixels glDrawBuffer call ok
surface.c / 1015
fixme:d3d_surface:flush_to_framebuffer_drawpixels >>>>>>>>>>>>>>>>>
GL_INVALID_VALUE (0x501) from glDrawPixels @ surface.c / 1061
trace:d3d_surface:flush_to_framebuffer_drawpixels glDrawBuffer(GL_BACK) call
ok surface.c / 1087
trace:d3d_surface:IWineD3DSurfaceImpl_ModifyLocation
(0x4e8fdf0)->(SFLAG_INDRAWABLE, TRUE)
trace:d3d_surface:IWineD3DBaseSurfaceImpl_GetContainer (This 0x4e8fdf0, riid
{34d01b10-6f30-11d9-c687-00046142c14f}, ppContainer 0x1a9dbc0)
Let me know if more info is needed.
--
Markus
Shader compiler GL error
Hi, while trying to fix the bug I posted a few days ago, the game's developer pointed out on request that the ingame shader issues are not related to the graphics card detection but more likely to a failing shader compilation. They are using d3d9_33.dll for development and recommended to try with this version. I've thus removed all other versions of the library and also deleted the game's cached shaders. The game now crashes on startup with the following error: fixme:d3d_surface:flush_to_framebuffer_drawpixels >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from glDrawPixels @ surface.c / 1061 If I use d3d9_31.dll instead, the shaders are compiled and the game starts but the water is again looking like a low-end fallback. Any ideas on this? Regards, -- Markus
How to fix bug #11114?
Hi, regarding bug #4, can anyone knowledgable in the area tell me how difficult it would be to resolve the issue? As far as I can see, the game World in Conflict is using dxdiag.dll to determine whether a system is capable of running the game. Is there an implementation for this dll at all in Wine? The native library appears to not fool the game sufficiently enough to start without an error. Using plain Wine (no native dxdiag dll) leads to the error in line 44725 of the logfile in the report. Thanks. -- Markus
Re: [Wine] wine proccess list
Am 11.12.2007 um 18:02 schrieb Gonzalo Martinez - Sanjuan Sanchez: > Is it possible using a hack/trick or a hidden option to change the > name of wine in the proccess lists? While this isn't a Wine specific question, you'd have to write your own executable-launcher. None of the shells I'm aware of allow to tweak argv[0]. The hearth of a custom launcher would be an execve() system call, see "man execve" on what it does. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: Anything wrong with my patch from 16.10. aboutw32x86andwin40creation?
> You could do it in GetPrinterDriverDirectory. ??? And if a Windows application simply queries systemdir and adds spool\drivers\w32x86 to copy printer driver files into it (ok, bad design, but I've seen a lot of that stuff in the past), it will still fail... And a native Windows system also comes with these both directories by default... So I think my patch is closer to the real... Anyway thanks for your time Markus
Re: Anything wrong with my patch from 16.10. about w32x86andwin40creation?
> We of course have to create the directory, but I think it would be > better if the dll that uses it did that. Hm, so you suggest putting it into WINSPOOL_LoadSystemPrinters()? Cause this looks like the only function who is definitely called during wine startup, isn't it? So we should include creation of "spool" and "spool/drivers" into this as well? Thanks for everybodies time Markus
Re: Anything wrong with my patch from 16.10. about w32x86 and win40creation?
So it's really ok to create a patch with only the patch as text without any attachment? Markus "Juan Lang" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >> I usually use the archives for viewing patches, sometimes the patches >> are archived separately to the email. >> >> Markus' patch is here: >> http://www.winehq.org/pipermail/wine-patches/2007-October/045288.html > > Right, that one had formatting characters in it due to the encoding. > Patches need to be either inline as text or attached as plaintext to > get looked at. > --Juan > > >
