Re: How is 0.0.0.0 handled in Wine?
On Tuesday 09 June 2009 07:10:40 Austin English wrote: > On Mon, Jun 8, 2009 at 7:14 PM, Ben Klein wrote: > >> Seems to me to be a bug, i.e., Wine shouldn't be able to use 0.0.0.0. > >> It seems that we're simply passing this on to the host os, which is > >> then routing it back to localhost. Perhaps we need to catch 0.0.0.0 as > >> a special case and refuse? > > > > I'm not sure Wine should be a special case if it's not breaking apps. > > While that's arguable , Putty can give a demonstratable corner case > that has behavior different on Windows than on Wine, and it's entirely > likely that there's some other app depending on that behavior that we > *don't* know about. There's a couple of cases where windows networking just works different from Unix networking. We could try to fix all of this in user space (some just can't work, like a socket bound to e.g. 192.168.0.23 on windows will still receive broadcast traffic going on on the vpn network with 10.0.0.255). I'm pretty sure there's more weird things going on. Given that you're not actually supposed to ever send anything to 0.0.0.0 anyway, I don't see how this is actually breaking windows apps that'd never expect this to work anyway. You're welcome to try and get patches about this past Alexandre, but I'd say that you'd be creating loads of special cases without much reason. It was annoying enough having to handle that modern linux distros always resolve the hostname to a loopback address and many windows apps think that gethostbyname(gethostname()) was a good idea to figure out what IP address to bind to when they actually want to bind to INADDR_ANY. (That's 0.0.0.0 btw, and will find you my "gethostname() should not resolve to localhost" hack.) In any case, unless we find an app that's really broken due to this, we can possibly reconsider. But I'd argue that if you ask your kernel to contact any IP address for you, you shouldn't be surprised if it's lazy and decides that any IP address might just be localhost. 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: How is 0.0.0.0 handled in Wine?
On Tue, Jun 9, 2009 at 12:15 AM, Erich Hoover wrote: > On Mon, Jun 8, 2009 at 11:10 PM, Austin English > wrote: >> >> ... >> > I'm not sure Wine should be a special case if it's not breaking apps. >> >> While that's arguable , Putty can give a demonstratable corner case >> that has behavior different on Windows than on Wine, and it's entirely >> likely that there's some other app depending on that behavior that we >> *don't* know about. >> >> -- >> -Austin > > 0.0.0.0 and broadcast packets cause some problems with the newer Command and > Conquer games, but the ticket was closed some time ago. I believe it was > decided that since the kernel devs wouldn't change how Linux handles these > cases that it would be too much trouble to work around it. > > Erich Hoover > ehoo...@mines.edu http://bugs.winehq.org/show_bug.cgi?id=7929 -- -Austin
Re: How is 0.0.0.0 handled in Wine?
On Mon, Jun 8, 2009 at 11:10 PM, Austin English wrote: > ... > > I'm not sure Wine should be a special case if it's not breaking apps. > > While that's arguable , Putty can give a demonstratable corner case > that has behavior different on Windows than on Wine, and it's entirely > likely that there's some other app depending on that behavior that we > *don't* know about. > > -- > -Austin 0.0.0.0 and broadcast packets cause some problems with the newer Command and Conquer games, but the ticket was closed some time ago. I believe it was decided that since the kernel devs wouldn't change how Linux handles these cases that it would be too much trouble to work around it. Erich Hoover ehoo...@mines.edu
Re: How is 0.0.0.0 handled in Wine?
On Mon, Jun 8, 2009 at 7:14 PM, Ben Klein wrote: >> Seems to me to be a bug, i.e., Wine shouldn't be able to use 0.0.0.0. >> It seems that we're simply passing this on to the host os, which is >> then routing it back to localhost. Perhaps we need to catch 0.0.0.0 as >> a special case and refuse? > > I'm not sure Wine should be a special case if it's not breaking apps. While that's arguable , Putty can give a demonstratable corner case that has behavior different on Windows than on Wine, and it's entirely likely that there's some other app depending on that behavior that we *don't* know about. -- -Austin
Re: How do I actually write a testcase for a 16-bit API ?
"Alex Villacís Lasso" wrote: I recently filed http://bugs.winehq.org/show_bug.cgi?id=18734 in which I showed that DlgDirList is behaving incorrectly for 16-bit apps. I also included a test program compiled with the Watcom C compiler, as well as a patch. Then a comment appeared saying that it should be possible to create a testcase for this API. By creating a test I meant to have a test for 32-bit behaviour first, then compare it with 16-bit one. -- Dmitry.
Re: Disable forum edits
"Igor Tarasov" wrote: 2009/6/9 Austin English : Users are editing their posts when asked for terminal output/wine version/etc. Those of us on the mailing list side don't get this information. Maybe just add notice on edit page stating that edits are for minor changes only, and if one has some additional information he should add it as a separate post? There is a request to not paste logs and backtraces when adding a comment to a bug, that doesn't prevent that very well. So disabling the feature is always a preference. -- Dmitry.
Re: Disable forum edits
On Mon, Jun 8, 2009 at 10:40 PM, Igor Tarasov wrote: > 2009/6/9 Austin English : >> Users are editing their posts when asked for terminal output/wine >> version/etc. Those of us on the mailing list side don't get this >> information. > > Maybe just add notice on edit page stating that edits are for minor > changes only, and if one has some additional information he should add > it as a separate post? I don't think the minor benefits of edits outweigh the downsides. 'Minor changes' is subject to interpretation, and we all know how that ends... -- -Austin
Re: Disable forum edits
2009/6/9 Austin English : > Users are editing their posts when asked for terminal output/wine > version/etc. Those of us on the mailing list side don't get this > information. Maybe just add notice on edit page stating that edits are for minor changes only, and if one has some additional information he should add it as a separate post? -- Igor
re: How do I actually write a testcase for a 16-bit API ?
See also http://lists.debian.org/debian-legal/2006/07/msg7.html I kind of doubt it will ever make it in to ubuntu. When I tried building win16 binaries with the Linux version, there were lots of path problems. That was two years ago, but I wouldn't be surprised if they're still there. These two things together make me suspect that installing the windows version in Wine is the way to go. We could make a script that does that in an alternate prefix and provides wrapper scripts that hide the wine-ness of it to some extent, maybe. That could be done as a stopgap while the test suite is refreshed and gotten ready to add into the wine tree. Once that's far enough along, it might then be worth looking at getting the linux version working and into a PPA. Or vice versa. Wish I had time to play with this stuff. I would really be happy if somebody got the win16 test suite into the wine tree! - Dan
Re: How is 0.0.0.0 handled in Wine?
2009/6/9 Austin English : > ping (in cmd.exe): > D:\appinstall>ping 0.0.0.0 > > Pinging 0.0.0.0 with 32 bytes of data: > > Destination specified is invalid. > Destination specified is invalid. > Destination specified is invalid. > Destination specified is invalid. > > Ping statistics for 0.0.0.0: > Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), > > Wine: > Putty -> 0.0.0.0 route to localhost, login succeeds (Not sure if it's > routing to localhost or 127.0.0.1) > > FWIW, Ubuntu: > ssh -> 0.0.0.0: routes to localhost, where I've got sshd running, connects > fine. > ping -> 0.0.0.0 routes to 127.0.0.1, succeeds This doesn't look right to me, but it also happens on my Debian box. Looks like that's how Linux works. > Seems to me to be a bug, i.e., Wine shouldn't be able to use 0.0.0.0. > It seems that we're simply passing this on to the host os, which is > then routing it back to localhost. Perhaps we need to catch 0.0.0.0 as > a special case and refuse? I'm not sure Wine should be a special case if it's not breaking apps.
Re: How is 0.0.0.0 handled in Wine?
FWIW, using Windows ping.exe under Wine: Pinging 0.0.0.0 with 32 bytes of data: Reply from 127.0.0.1: bytes=32 time<1ms TTL=64 Reply from 127.0.0.1: bytes=32 time<1ms TTL=64 Reply from 127.0.0.1: bytes=32 time<1ms TTL=64 Reply from 127.0.0.1: bytes=32 time<1ms TTL=64 Ping statistics for 0.0.0.0: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms -- -Austin
How is 0.0.0.0 handled in Wine?
Howdy all, Doing some testing with PuTTY, I've noticed some strange behavior. I've got windows XP in a VM, and when comparing behavior to Wine, I noticed some inconsistencies with respect to the '0.0.0.0' invalid address. Windows: Putty -> 0.0.0.0: throws an error "Network error: Cannot assign requested address" ping (in cmd.exe): D:\appinstall>ping 0.0.0.0 Pinging 0.0.0.0 with 32 bytes of data: Destination specified is invalid. Destination specified is invalid. Destination specified is invalid. Destination specified is invalid. Ping statistics for 0.0.0.0: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), Wine: Putty -> 0.0.0.0 route to localhost, login succeeds (Not sure if it's routing to localhost or 127.0.0.1) FWIW, Ubuntu: ssh -> 0.0.0.0: routes to localhost, where I've got sshd running, connects fine. ping -> 0.0.0.0 routes to 127.0.0.1, succeeds Seems to me to be a bug, i.e., Wine shouldn't be able to use 0.0.0.0. It seems that we're simply passing this on to the host os, which is then routing it back to localhost. Perhaps we need to catch 0.0.0.0 as a special case and refuse? Grepping in the source code for 0.0.0.0 only shows a few hits: comctl32 (unrelated), rpcrt4 (appears unrelated) and ws2_32 (but only in the tests, not in the implementation). -- -Austin
Re: Disable forum edits
On Mon, 8 Jun 2009 14:41:57 -0500 Austin English wrote: > Users are editing their posts when asked for terminal output/wine > version/etc. Those of us on the mailing list side don't get this > information. > +1 It's not quite as big a problem for those of us who use the forum, but if people don't mark their post as edited, it's not necessarily obvious even to us that something has been changed. Edits just cause problems, with no significant benefit that I can think of. -- Rosanne DiMesio
Re: Disable forum edits
On Mon, Jun 8, 2009 at 5:23 PM, Ben Klein wrote: > Ask them to put it in a new post? > > On 2009-06-09, Austin English wrote: >> Users are editing their posts when asked for terminal output/wine >> version/etc. Those of us on the mailing list side don't get this >> information. While we could do that, that would require doing so for just about every post that is made on wine-users, which is a bit ridiculous. -- -Austin
Re: Disable forum edits
Ask them to put it in a new post? On 2009-06-09, Austin English wrote: > Users are editing their posts when asked for terminal output/wine > version/etc. Those of us on the mailing list side don't get this > information. > > -- > -Austin > > >
Re: wine-devel Digest, Vol 47, Issue 32
Did we find out what the regression is for 1.1.23 that caused the ATI and other non NVIDIA cards to start failing? Chris
Re: How do I actually write a testcase for a 16-bit API ?
Steven Edwards writes: > On Mon, Jun 8, 2009 at 4:09 PM, Alex Villacís > Lasso wrote: >> I downloaded the tests from win16test.googlecode.com , but the tarball >> already has a small backlog of patches that have not yet been integrated >> into Wine (checked with patch --dry-run). Why? I could make a patch to the >> testsuite from win16test.googlecode.com, but will this help at all on >> getting the fix integrated into Wine? > > We need someone to do the configure magic of detecting OpenWatcom if > installed and teach configure and friends how to build. The win16 test > suite has kind of been in bitrot mode as no one has taken the time to > integrate it. Of course you might want to double check with Alexandre > as to his preference. He might prefer at this point to just keep the > win16 tests out of the tree. I don't know. They can remain out of tree, but still, being able to demonstrate a working test case will help getting the patch in, even if the test remains out for now. -- Alexandre Julliard julli...@winehq.org
Re: Wine translation statistics sources
André Hentschel wrote: > Paul Vriens schrieb: >> Alexandre Julliard wrote: >>> Mikołaj Zalewski writes: >>> It's online again. Having it on WineHQ would probably give a better uptime (and a much better latency, but this should also improve on my side, when I won't need a temporary SSH tunnel anymore and will move the HTTP server from my good old Pentium 100MHz to a new Atom machine). I've been in contact with Jeremy Newman about it some time ago, but, after a few exchanges, my e-mails got unanswered, so I assumed he is too busy to help with it (and, alone, I don't know how to do it). >>> >>> If you send me the necessary information I can probably take care of it. >>> >> >> And we of course need something to cope with the change to the clock >> resource files as mentioned by Michael Stefaniuc. >> > Or we should change our clock resources to fit in the rest of wine? You mean reverting Alexandre's patch? Doubt it. Alexandre and I talked on irc about that. The --verify-translation functionality needs to move out wrc and into a separate tool that parses the .res files or the binary. bye michael
Re: How do I actually write a testcase for a 16-bit API ?
On Mon, Jun 8, 2009 at 4:09 PM, Alex Villacís Lasso wrote: > I downloaded the tests from win16test.googlecode.com , but the tarball > already has a small backlog of patches that have not yet been integrated > into Wine (checked with patch --dry-run). Why? I could make a patch to the > testsuite from win16test.googlecode.com, but will this help at all on > getting the fix integrated into Wine? We need someone to do the configure magic of detecting OpenWatcom if installed and teach configure and friends how to build. The win16 test suite has kind of been in bitrot mode as no one has taken the time to integrate it. Of course you might want to double check with Alexandre as to his preference. He might prefer at this point to just keep the win16 tests out of the tree. I don't know. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
user32: Test request (cursoricon)
I've tested this on XP, but I would like to get somebody to test on 9x and
maybe even vista please and thank you. These tests are the prelude to
cursoricon patches including Griswold's animated cursors & themed cursors and
my fixes for LOTRO (mostly handling invalid calls properly).
Thanks,
Daniel
From acbbfdee105878c1f5f78293a1082e5bce908682 Mon Sep 17 00:00:00 2001
From: Daniel Santos
Date: Mon, 8 Jun 2009 15:51:40 -0500
Subject: user32/tests: Add more intensive tests for SetCursor.
---
dlls/user32/tests/cursoricon.c | 166 +++-
1 files changed, 145 insertions(+), 21 deletions(-)
diff --git a/dlls/user32/tests/cursoricon.c b/dlls/user32/tests/cursoricon.c
index 9475534..ea968fa 100644
--- a/dlls/user32/tests/cursoricon.c
+++ b/dlls/user32/tests/cursoricon.c
@@ -64,6 +64,14 @@ static HANDLE child_process;
#define PROC_INIT (WM_USER+1)
+#define __STRIZE2(x) #x
+#define __STRIZE(x) __STRIZE2(x)
+#define __FILE_SPOT __FILE__ ":" __STRIZE(__LINE__)
+
+inline static int is_win9x() {
+return GetVersion() & 0x8000;
+}
+
static LRESULT CALLBACK callback_child(HWND hwnd, UINT msg, WPARAM wParam,
LPARAM lParam)
{
BOOL ret;
@@ -76,10 +84,11 @@ static LRESULT CALLBACK callback_child(HWND hwnd, UINT msg,
WPARAM wParam, LPARA
SetLastError(0xdeadbeef);
ret = DestroyCursor((HCURSOR) lParam);
error = GetLastError();
-todo_wine ok(!ret || broken(ret) /* win9x */, "DestroyCursor on
the active cursor succeeded.\n");
+todo_wine ok(!ret || broken(is_win9x() && ret), /* win9x */
+"DestroyCursor on the active cursor succeeded.\n");
ok(error == ERROR_DESTROY_OBJECT_OF_OTHER_THREAD ||
- error == 0xdeadbeef, /* vista */
-"Last error: %u\n", error);
+error == 0xdeadbeef, /* vista */
+"Last error: %u\n", error);
return TRUE;
case WM_DESTROY:
PostQuitMessage(0);
@@ -768,9 +777,94 @@ static void test_LoadImageFile(const unsigned char *
image_data,
DeleteFileA(filename);
}
+/*
+ * test_SetCursor
+ *
+ * Encapsulates tests to SetCursor() function.
+ *
+ * PARAMS
+ * target [I] A handle to use when calling SetCursor
+ * shouldFail [I] Rather of not it should fail
+ * filespot [I] The file:line location this function was called from.
+ * retValTodo [I] True if return value is broken in wine (wine's return value
+ * is broken in some, but not all cases)
+ *
+ * RETURNS
+ * The return value of the SetCursor() call.
+ */
+static HCURSOR test_SetCursor(HANDLE hNewCursor, BOOL shouldFail,
+const char *filespot, BOOL retValTodo)
+{
+HCURSOR cursor1, cursor2, cursor3;
+DWORD error;
+
+/* GetCursor should have no errors */
+SetLastError(0xdeadbeef);
+cursor1 = GetCursor();
+error = GetLastError();
+ok(error == 0xdeadbeef, "(Called from %s) GetCursor() changed last error: "
+"%u.\n",
+filespot, error);
+
+/* Call SetCursor on supplied handle */
+SetLastError(0xdeadbeef);
+cursor2 = SetCursor(hNewCursor);
+error = GetLastError();
+cursor3 = GetCursor();
+
+if (shouldFail) {
+todo_wine ok(error == ERROR_INVALID_CURSOR_HANDLE,
+"(Called from %s) Last error is %u (0x%08x), expected "
+"ERROR_INVALID_CURSOR_HANDLE (%u).\n",
+filespot, error, error, ERROR_INVALID_CURSOR_HANDLE);
+
+if(retValTodo) {
+todo_wine ok(!cursor2,
+"(Called from %s) SetCursor() returned non-zero (%p).\n",
+filespot, cursor2);
+} else {
+ok(!cursor2,
+"(Called from %s) SetCursor() returned non-zero (%p).\n",
+filespot, cursor2);
+}
+
+todo_wine ok(cursor1 == cursor3,
+"(Called from %s) SetCursor() changed cursor.\n",
+filespot);
+} else {
+todo_wine ok(error == 0xdeadbeef,
+"(Called from %s) Last error is %u (0x%08x), expected "
+"0xdeadbeef.\n",
+filespot, error, error);
+
+/* WinXP: For some reason, SetCursor() is returning NULL when
hNewCursor
+ * is NULL. Is it this way on other versions? MSDN says it should
+ * return the old cursor.
+ */
+if(hNewCursor) {
+ok(cursor1 == cursor2,
+"(Called from %s) SetCursor() did not return the previous "
+"cursor. Expected %p, got %p.\n",
+filespot, cursor1, cursor2);
+} else {
+todo_wine ok(!cursor2,
+"(Called from %s) SetCursor() returned %p, expected
NULL\n",
+filespot, cursor2);
+}
+
+ok(cursor3 == hNewCur
Re: How do I actually write a testcase for a 16-bit API ?
Austin English escribió:
On Mon, Jun 8, 2009 at 2:46 PM, Alex Villacís
Lasso wrote:
I recently filed http://bugs.winehq.org/show_bug.cgi?id=18734 in which I
showed that DlgDirList is behaving incorrectly for 16-bit apps. I also
included a test program compiled with the Watcom C compiler, as well as a
patch. Then a comment appeared saying that it should be possible to create a
testcase for this API. So I tried. At first, I thought that since this was a
16-bit API, I should be adding -Wb,--subsystem,win16 to the Makefile.
However, this results in the linker complaining that it cannot find
WinMain16. So I removed it. Also, I had undefined link-time references to
SendMessage16 and similar (because I want everything to go through the
16-bit APIs, else the whole point of the test is lost), so I had to manually
add them to the spec files for kernel32 and user32. But after doing this and
getting a test program, an attempt to create the window out of the
registered class fails and triggers an assertion.
I have no examples of previous 16-bit tests (as opposed to 16-bit Wine dlls)
to draw upon, so I don't know how to proceed correctly to test a 16-bit API
in a way that convinces everyone that the patch is correct. What do you
think of this?
http://www.winehq.org/pipermail/wine-devel/2007-July/058084.html
http://www.winehq.org/pipermail/wine-devel/2007-July/057917.html
http://win16test.googlecode.com/
I downloaded the tests from win16test.googlecode.com , but the tarball
already has a small backlog of patches that have not yet been integrated
into Wine (checked with patch --dry-run). Why? I could make a patch to
the testsuite from win16test.googlecode.com, but will this help at all
on getting the fix integrated into Wine?
--
perl -e '$x=2.3;printf("%.0f + %.0f = %.0f\n",$x,$x,$x+$x);'
Re: How do I actually write a testcase for a 16-bit API ?
On Mon, Jun 8, 2009 at 2:46 PM, Alex Villacís Lasso wrote: > I recently filed http://bugs.winehq.org/show_bug.cgi?id=18734 in which I > showed that DlgDirList is behaving incorrectly for 16-bit apps. I also > included a test program compiled with the Watcom C compiler, as well as a > patch. Then a comment appeared saying that it should be possible to create a > testcase for this API. So I tried. At first, I thought that since this was a > 16-bit API, I should be adding -Wb,--subsystem,win16 to the Makefile. > However, this results in the linker complaining that it cannot find > WinMain16. So I removed it. Also, I had undefined link-time references to > SendMessage16 and similar (because I want everything to go through the > 16-bit APIs, else the whole point of the test is lost), so I had to manually > add them to the spec files for kernel32 and user32. But after doing this and > getting a test program, an attempt to create the window out of the > registered class fails and triggers an assertion. > > I have no examples of previous 16-bit tests (as opposed to 16-bit Wine dlls) > to draw upon, so I don't know how to proceed correctly to test a 16-bit API > in a way that convinces everyone that the patch is correct. What do you > think of this? http://www.winehq.org/pipermail/wine-devel/2007-July/058084.html http://www.winehq.org/pipermail/wine-devel/2007-July/057917.html http://win16test.googlecode.com/ -- -Austin
How do I actually write a testcase for a 16-bit API ?
I recently filed http://bugs.winehq.org/show_bug.cgi?id=18734 in which I
showed that DlgDirList is behaving incorrectly for 16-bit apps. I also
included a test program compiled with the Watcom C compiler, as well as
a patch. Then a comment appeared saying that it should be possible to
create a testcase for this API. So I tried. At first, I thought that
since this was a 16-bit API, I should be adding -Wb,--subsystem,win16 to
the Makefile. However, this results in the linker complaining that it
cannot find WinMain16. So I removed it. Also, I had undefined link-time
references to SendMessage16 and similar (because I want everything to go
through the 16-bit APIs, else the whole point of the test is lost), so I
had to manually add them to the spec files for kernel32 and user32. But
after doing this and getting a test program, an attempt to create the
window out of the registered class fails and triggers an assertion.
I have no examples of previous 16-bit tests (as opposed to 16-bit Wine
dlls) to draw upon, so I don't know how to proceed correctly to test a
16-bit API in a way that convinces everyone that the patch is correct.
What do you think of this?
--
perl -e '$x=2.3;printf("%.0f + %.0f = %.0f\n",$x,$x,$x+$x);'
Disable forum edits
Users are editing their posts when asked for terminal output/wine version/etc. Those of us on the mailing list side don't get this information. -- -Austin
Re: riched20/tests: fix test for vista
André Hentschel wrote: Vista turns the "(WCHAR)1234" into a "(unsigned char)1234". This causes error on vista machineshttp://test.winehq.org/data/7aeffc442cc1b9a454f1ff7d7b3175b4bba88b05/vista_esx-wvistaadm/riched20:editor.html editor.c:3249: Test failed: EM_GETPASSWORDCHAR returned Ò (210) when set to 'x', instead of x (120) --- dlls/riched20/tests/editor.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Hi André, Is there anything special about this box? Could it be that the locale plays a role in this. I'm asking as my Vista box (and several others seen on test.winehq.org) doesn't have this issue. -- Cheers, Paul.
Re: Wine translation statistics sources
Paul Vriens schrieb: Alexandre Julliard wrote: Mikołaj Zalewski writes: It's online again. Having it on WineHQ would probably give a better uptime (and a much better latency, but this should also improve on my side, when I won't need a temporary SSH tunnel anymore and will move the HTTP server from my good old Pentium 100MHz to a new Atom machine). I've been in contact with Jeremy Newman about it some time ago, but, after a few exchanges, my e-mails got unanswered, so I assumed he is too busy to help with it (and, alone, I don't know how to do it). If you send me the necessary information I can probably take care of it. And we of course need something to cope with the change to the clock resource files as mentioned by Michael Stefaniuc. Or we should change our clock resources to fit in the rest of wine?
Re: d3d9: Add DF16 support
Am 07.06.2009 um 23:34 schrieb Henri Verbeet: Ok, I guess the format could just be named badly, although Chris makes a good point about precision, even if the values are normalized. There's D3DFMT_D24FS8 in the standard d3d formats, so I guess if they just wanted to make it a float format there's no point in adding their own format Still needs testing though
Re: Try2: Website: Remove GIMP Fun Project
On Mon, 2009-06-08 at 16:57 +0200, Paul Vriens wrote: > > We have that same (or actually newer) page on the wiki: > > http://wiki.winehq.org/Fun_Projects > > Doesn't it make more sense to link this entire page to the wiki? I think it does. But it would be great if someone can spend a bit of time on the wiki page to colorize a bit the entries based on their status (DONE, TODO, etc), 'cause the page as it is now is a bit hard to follow... -- Dimi Paun Lattica, Inc.
Re: Try2: Website: Remove GIMP Fun Project
Ken Sharp wrote: Disregard first patch.. this one makes a little more sense. Ken Sharp wrote: See Bug 7976. Apparently this has already been done. We have that same (or actually newer) page on the wiki: http://wiki.winehq.org/Fun_Projects Doesn't it make more sense to link this entire page to the wiki? -- Cheers, Paul.
Re: [3/3] windowscodecs: add stub implementation of IWICImagingFactory
"Vincent Povirk" writes:
> --- a/tools/wine.inf.in
> +++ b/tools/wine.inf.in
> @@ -123,6 +123,8 @@ HKCR,.xml,"Content Type",2,"text/xml"
> HKCR,.xsl,"Content Type",2,"text/xsl"
> HKCR,chm.file,,2,"Compiled HTML Help File"
> HKCR,chm.file\shell\open\command,,2,"%11%\hh.exe %1"
> +HKCR,CLSID\{CACAF262-9370-4615-A13B-9F5539DA4C0A}\InProcServer32,,2,"windowscodecs.dll"
> +HKCR,CLSID\{CACAF262-9370-4615-A13B-9F5539DA4C0A}\InProcServer32,ThreadingModel,2,"Apartment"
> HKCR,cplfile,,2,"Control Panel Item"
> HKCR,cplfile\shell\cplopen,,2,"Open with Control Panel"
> HKCR,cplfile\shell\cplopen\command,,2,"rundll32.exe
> shell32.dll,Control_RunDLL ""%1"",%*"
This should be done by registering the dll.
--
Alexandre Julliard
julli...@winehq.org
Re: Wine translation statistics sources
Alexandre Julliard wrote: Mikołaj Zalewski writes: It's online again. Having it on WineHQ would probably give a better uptime (and a much better latency, but this should also improve on my side, when I won't need a temporary SSH tunnel anymore and will move the HTTP server from my good old Pentium 100MHz to a new Atom machine). I've been in contact with Jeremy Newman about it some time ago, but, after a few exchanges, my e-mails got unanswered, so I assumed he is too busy to help with it (and, alone, I don't know how to do it). If you send me the necessary information I can probably take care of it. And we of course need something to cope with the change to the clock resource files as mentioned by Michael Stefaniuc. -- Cheers, Paul.
Re: d3d9: Add DF16 support
2009. 06. 7, vasárnap keltezéssel 19.44-kor Stefan Dösinger ezt írta: > Am 07.06.2009 um 10:35 schrieb Henri Verbeet: > > > 2009/6/7 Frank Richter : > >> As far as I could gather DF16 is the "ATI way" of getting a > >> renderable > >> 16 bit depth texture. > > Without knowing much about the actual format, DF16 implies this should > > be a floating point format, similar to the ones provided by > > ARB_depth_buffer_float. Also, could you please add this at the same > > location as the other depth formats? > I don't think it is a float format, in spite of the name. I don't > understand what it exactly is, but it seems that ATI Windows drivers > cannot use regular D3DFMT_D16 or D24S8 as texture. That means that if > an app wants a depth texture it has to StretchRect from the depth > stencil to a D3DFMT_Lx texture. > > I think when D16 is used in a shader it is supposed to behave like > GL_ARB_shadow. Sometimes this is not flexible enough, and hearsay says > it does not work on ATI cards. > > My understanding is that the different formats work somewhat like this: > > D3DFMT_D16 / D24X8, D24S8(all? nv only?): GL_ARB_shadow / shadow2D() > in GLSL > DF16, DF24(ati): Like sampling DEPTH_COMPONENT24 formats with regular > texture2D > INTZ(nv): denormalized texture2D() > RAWZ(nv): Comparable to INTZ, but needs some extra calculations. I > guess we'll not implement this, only INTZ. > > If this is correct, Franks patch is content wise correct. I think > we'll need tests to see if my understanding of the formats is correct. > Hi, I think you can test these formats with Crysis demo, first it tries to use one of them, then falls back to a standard depth format. > > Andras
