Re: Requesting comments on patchset to fix Bug 7929 (C&C 3 network does not work)
On Saturday 10 October 2009 01:15:17 Juan Lang wrote: > Hi Eric, > > it seems to me that if this is the best we can do, we're fixing it at > the wrong layer. Surely putting the fix in the Linux kernel would be > much smaller in code size, and higher performing, as we wouldn't have > to filter packets in user space. Been there, got wristslapped. The network subsystem maintainer of the Linux kernel is pretty clear that he won't add quirky windows behaviour to the Linux network stack just so Wine can get some apps to work. Erich's work seems to be the first real solution to a problem that affects a couple of games with developers who didn't get networking right. I'm pretty sure this only works by accident on windows as well, it'll break on dual-homed windows hosts just the way it breaks on Wine. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: Requesting comments on patchset to fix Bug 7929 (C&C 3 network does not work)
> This is rather embarrasing, but apparently I left server/protocol.def out of > the patchset. I could have sworn I tested these patches on a clean git, but > apparently I made a mistake. Is there any chance that this mistake is the > reason for the rejection? It very well could be, but you'll have better luck getting the opinion of The Man. If you ask nicely he might chime in, or catch him on irc. --Juan
Ballooning "dlls" folder
With the separation of the 16-bit APIs recently, the "dlls" folder has ballooned quite a bit. Is there any particular reason that the 16-bit and 32-bit DLLs are not in separate folders? Erich Hoover ehoo...@mines.edu
Re: Requesting comments on patchset to fix Bug 7929 (C&C 3 network does not work)
On Fri, Oct 9, 2009 at 5:15 PM, Juan Lang wrote: > Hi Eric, > > it seems to me that if this is the best we can do, we're fixing it at > the wrong layer. Surely putting the fix in the Linux kernel would be > much smaller in code size, and higher performing, as we wouldn't have > to filter packets in user space. > --Juan > I put this patchset together after reviewing several years of conversations people have had with the kernel developers. A simple summary of what the devs have said is that the functions in the kernel that provide the ability to do this "easily" require root privileges for very good reasons (essentialy, the easy ways of approaching this problem allow overriding certain permissions mechanisms). Their suggestion was to filter using IP_PKTINFO (which is what the patches do): http://www.mail-archive.com/linux-...@vger.kernel.org/msg01341.html The maintainer has pretty much "put his foot down" on the matter (several times actually, here's a nicer one): http://www.mail-archive.com/linux-...@vger.kernel.org/msg01306.html This is rather embarrasing, but apparently I left server/protocol.def out of the patchset. I could have sworn I tested these patches on a clean git, but apparently I made a mistake. Is there any chance that this mistake is the reason for the rejection? The additional code in these patches is only utilized (sans a call to getsockopt) on UDP broadcast sockets that have been bound to a specific interface. According to the kernel devs, this behavior is what IP_PKTINFO is meant to do and that they have no intention of adding an additional feature that does exactly the same thing. Erich Hoover ehoo...@mines.edu
Re: Requesting comments on patchset to fix Bug 7929 (C&C 3 network does not work)
Hi Eric, it seems to me that if this is the best we can do, we're fixing it at the wrong layer. Surely putting the fix in the Linux kernel would be much smaller in code size, and higher performing, as we wouldn't have to filter packets in user space. --Juan
Requesting comments on patchset to fix Bug 7929 (C&C 3 network does not work)
I've been a bit busy lately, but I sent in a patchset at the end of September to fix the C&C3 LAN networking bug. If I could get some feedback on these patches then I would greatly appreciate it: http://www.winehq.org/pipermail/wine-patches/2009-September/079193.html[1/6] http://www.winehq.org/pipermail/wine-patches/2009-September/079195.html[2/6] http://www.winehq.org/pipermail/wine-patches/2009-September/079194.html[3/6] http://www.winehq.org/pipermail/wine-patches/2009-September/079198.html[4/6] http://www.winehq.org/pipermail/wine-patches/2009-September/079196.html[5/6] http://www.winehq.org/pipermail/wine-patches/2009-September/079197.html[6/6] Erich Hoover ehoo...@mines.edu
Re: [try 4] Add help message box to dxdiag implementation
On Fri, Oct 9, 2009 at 7:32 AM, Joel Holdsworth wrote: > I'm just wondering how easy would it be to do something simple with a > proper dialog template. The reason I ask is that I've been working on an > icon for dxdiag (http://www.airwebreathe.org.uk/wine-icon/), and it'd be > nice if there was a dialog ready to receive it. It's no big deal though. > What do you think? > Joel The 'completed' version from UCLA that Brian, David and I have cleaned up has a complete dialog, along with quite a bit of functionality. Of course, the code is messy and still needs a lot of cleanup. I suppose it could be stripped down to just the skeleton dialog...I'll take a look in the next week or two. -- -Austin
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
Michael Stefaniuc writes: > Roderick Colenbrander wrote: >> Blackbox reverse engineering is feeding test input to a function and >> looking at the output. A trace of calls made by the native MS dll >> while looking under Wine isn't blackbox. It is considered about the >> same as looking at disassembled Microsoft code. >> >> I'm not sure how to proceed from this though. > He probably can still write the test case; I really doubt that Alexandre > will accept a patch to fix the issue. Somebody else would have to do it > based on Markus' description. 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. -- Alexandre Julliard julli...@winehq.org
Re: Help needed: BSTR cache testing
On 10/09/2009 02:15 PM, Paul Vriens wrote:
On 10/09/2009 02:07 PM, Markus Stockhausen wrote:
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
Hi Markus,
My question about a modified test case came from your statement:
"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)."
If that sz99 (or now sz128) came from "looking at internal behaviour",
I'm not sure if that would raise some eyebrows.
Ok, what about something like the attached testcase?
This one succeeds on W2K3 (didn't test on other boxes yet).
Does it prove anything?
--
Cheers,
Paul.
diff --git a/dlls/oleaut32/tests/vartest.c b/dlls/oleaut32/tests/vartest.c
index 68a4edf..c2e18b3 100644
--- a/dlls/oleaut32/tests/vartest.c
+++ b/dlls/oleaut32/tests/vartest.c
@@ -8555,10 +8555,48 @@ static void test_VarImp(void)
SysFreeString(true_str);
}
+static void test_SomethingStrange(void)
+{
+ BSTR s1, s2;
+ int i, j;
+
+ WCHAR szbig[128];
+ static const WCHAR W[] = {'W', 0};
+
+ s1 = SysAllocString(sz12);
+ i = SysStringLen(s1);
+ ok(i == 2, "string length should be 2\n");
+ SysFreeString(s1);
+
+ memset(szbig, 0, sizeof(szbig));
+ for (j = 0; j < sizeof(szbig); j++) lstrcatW(szbig, W);
+
+ for (j = sizeof(szbig); j >= 0; j--)
+ {
+ szbig[j] = 0;
+ s2 = SysAllocString(szbig);
+ ok(j == SysStringLen(s2), "blah");
+ SysFreeString(s2);
+ i = SysStringLen(s1);
+ if (j > 5)
+ {
+ ok(i == 2, "string length should be 2\n");
+ ok(!lstrcmpW(s1, sz12), "blah2");
+ }
+ else
+ {
+ ok(i == j, "string length should be %d\n", j);
+ ok(!lstrcmpW(s1, szbig), "blah3");
+ }
+ }
+}
+
+
START_TEST(vartest)
{
init();
+ test_SomethingStrange();
test_VariantInit();
test_VariantClear();
test_VariantCopy();
@@ -8590,5 +8628,5 @@ START_TEST(vartest)
test_VarAnd();
test_VarDiv();
test_VarIdiv();
- test_VarImp();
+ test_VarImp();
}
Re: Help needed: BSTR cache testing
Roderick Colenbrander wrote: > On Fri, Oct 9, 2009 at 2:25 PM, Markus Stockhausen > wrote: >> 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. >> > > Blackbox reverse engineering is feeding test input to a function and > looking at the output. A trace of calls made by the native MS dll > while looking under Wine isn't blackbox. It is considered about the > same as looking at disassembled Microsoft code. > > I'm not sure how to proceed from this though. He probably can still write the test case; I really doubt that Alexandre will accept a patch to fix the issue. Somebody else would have to do it based on Markus' description. bye michael
Re: Help needed: BSTR cache testing
On Fri, Oct 9, 2009 at 2:25 PM, Markus Stockhausen wrote: > 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. > Blackbox reverse engineering is feeding test input to a function and looking at the output. A trace of calls made by the native MS dll while looking under Wine isn't blackbox. It is considered about the same as looking at disassembled Microsoft code. I'm not sure how to proceed from this though. Roderick
Re: [try 4] Add help message box to dxdiag implementation
I'm just wondering how easy would it be to do something simple with a proper dialog template. The reason I ask is that I've been working on an icon for dxdiag (http://www.airwebreathe.org.uk/wine-icon/), and it'd be nice if there was a dialog ready to receive it. It's no big deal though. What do you think? Joel
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
On 10/09/2009 02:07 PM, Markus Stockhausen wrote: 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 Hi Markus, My question about a modified test case came from your statement: "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)." If that sz99 (or now sz128) came from "looking at internal behaviour", I'm not sure if that would raise some eyebrows. -- Cheers, Paul.
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: include/dwmapi.h: Add defenition of MIL_MATRIX3X2D
Louis. Lenders wrote:
needed to add a stub for //DwmGetGraphicsStreamTransformHint later on
//
Hi, Louis.
+typedef struct _MIL_MATRIX3X2D
+{
+DOUBLE S_11;
+DOUBLE S_12;
+DOUBLE S_21;
+DOUBLE S_22;
+DOUBLE DX;
+DOUBLE DY;
+} MIL_MATRIX3X2D;
+
This is called MilMatrix3x2D in PSDK. Would you mind to resend?
Re: Help needed: BSTR cache testing
On 10/09/2009 10:12 AM, Markus Stockhausen wrote: 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 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)? -- Cheers, Paul.
no LANG=C wine winecfg on Mac OS? (texts are always translated)
Hi, On Linux, I can toggle Wine's idea about the current language by starting with: LANG=C or =de_DE.UTF-8 or fr_... wine winecfg Winecfg then displays text in the chosen locale (english for C). This works well in Ubuntu for any locale with the language-pack-xyz packages installed (C always works). On my Mac, winecfg's texts are always German. Even LANG=C /path/to/wine winecfg does not display english texts! How to switch languages on the Mac? I'm using 1.1.30, compiled by myself on Mac OS X 10.5.7. Thanks for your help, Jörg Höhle.
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
Markus Stockhausen wrote: >> 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. > > Already sent. Take a look here: > http://www.winehq.org/pipermail/wine-devel/2009-October/078957.html Three problems: You didn't mark the test todo_wine. The name of the test is cryptic, don't you want to call it something like test_bstr_caching()? This change should not be included in the patch: - test_VarImp(); + test_VarImp(); Other notes: You might want to also verify the contents of the string rather than the length, and do it right after the free as well. Also, how did you decide on the size of sz99? > 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. Passes on vista. Have you tested it with 'winetricks dcom98'? Passing those two should suffice. - Dan
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.
Re: Help needed: BSTR cache testing
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 -- Cheers, Paul.
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
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!
