On 02/16/2010 10:08 PM, Dan Kegel wrote:
Without this, editing the .cmd file and then running make would
cause make to overwrite the .out file with a copy of the .cmd file!
Evidently '.out' is not appropriate as a suffix for a nongenerated
source file. The arbitrarily-chosen .exp suffix works
On 02/18/2010 09:50 AM, Paul Vriens wrote:
On 02/16/2010 10:08 PM, Dan Kegel wrote:
Without this, editing the .cmd file and then running make would
cause make to overwrite the .out file with a copy of the .cmd file!
Evidently '.out' is not appropriate as a suffix for a nongenerated
source file.
On 17 February 2010 17:54, Christian Costa titan.co...@wanadoo.fr wrote:
+if (TRACE_ON(d3d_shader))
+{
+int size = strlen(comment) + 1;
+char* str = (char*)HeapAlloc(GetProcessHeap(), 0, size);
+int i = 0;
+
Henri Verbeet a écrit :
On 17 February 2010 17:54, Christian Costa titan.co...@wanadoo.fr wrote:
+if (TRACE_ON(d3d_shader))
+{
+int size = strlen(comment) + 1;
+char* str = (char*)HeapAlloc(GetProcessHeap(), 0, size);
+
On 02/18/2010 11:36 AM, Paul Vriens wrote:
On 02/18/2010 09:50 AM, Paul Vriens wrote:
On 02/16/2010 10:08 PM, Dan Kegel wrote:
Without this, editing the .cmd file and then running make would
cause make to overwrite the .out file with a copy of the .cmd file!
Evidently '.out' is not appropriate
On 02/18/2010 01:32 PM, Paul Vriens wrote:
On 02/18/2010 11:36 AM, Paul Vriens wrote:
On 02/18/2010 09:50 AM, Paul Vriens wrote:
On 02/16/2010 10:08 PM, Dan Kegel wrote:
Without this, editing the .cmd file and then running make would
cause make to overwrite the .out file with a copy of the
On 02/18/2010 02:35 PM, Paul Vriens wrote:
Hi,
This should fix the test failures for Wine (on test.winehq.org).
Not sure how to write a (simple) test for this. The test is there in
fact but it will only show up on test.winehq.org or when doing a make
batch.ok from a directory with an uppercase
Paul Vriens paul.vriens.w...@gmail.com writes:
diff --git a/programs/cmd/batch.c b/programs/cmd/batch.c
index 28744d4..6cb732c 100644
--- a/programs/cmd/batch.c
+++ b/programs/cmd/batch.c
@@ -91,7 +91,7 @@ void WCMD_batch (WCHAR *file, WCHAR *command, int called,
WCHAR *startLabel, HAN
On 02/18/2010 02:51 PM, Alexandre Julliard wrote:
Paul Vrienspaul.vriens.w...@gmail.com writes:
diff --git a/programs/cmd/batch.c b/programs/cmd/batch.c
index 28744d4..6cb732c 100644
--- a/programs/cmd/batch.c
+++ b/programs/cmd/batch.c
@@ -91,7 +91,7 @@ void WCMD_batch (WCHAR *file, WCHAR
Paul Vriens paul.vriens.w...@gmail.com writes:
In any case the test environment needs to be comparing paths in a
case-insensitive way, it doesn't make sense to require exact case.
So the memcmp needs to change into some strcmp form?
Yes, though you probably need CompareString.
--
Alexandre
On 02/18/2010 03:33 PM, Alexandre Julliard wrote:
Paul Vrienspaul.vriens.w...@gmail.com writes:
In any case the test environment needs to be comparing paths in a
case-insensitive way, it doesn't make sense to require exact case.
So the memcmp needs to change into some strcmp form?
Yes,
Paul Vriens paul.vriens.w...@gmail.com writes:
On 02/18/2010 03:33 PM, Alexandre Julliard wrote:
Paul Vrienspaul.vriens.w...@gmail.com writes:
In any case the test environment needs to be comparing paths in a
case-insensitive way, it doesn't make sense to require exact case.
So the memcmp
On 2/18/2010 15:46, Dmitry Timoshkov wrote:
Listview receives notifications not only from built-in header control,
but also from custom or subclassed application controls, there is no
need to assert(0) on application input, printing a FIXME is the maximum
we can do on an unknown input.
The
On Thu, Feb 18, 2010 at 3:47 AM, Hans Leidekker h...@codeweavers.com wrote:
---
dlls/msi/install.c | 12 +++-
dlls/msi/tests/automation.c | 4 ++--
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/dlls/msi/install.c b/dlls/msi/install.c
index
On Thursday 18 February 2010 19:56:17 James Hawkins wrote:
default:
-FIXME(%d %d\n, hInstall, iRunMode);
+FIXME(unimplemented run mode\n);
r = TRUE;
}
It's nice to see which run mode we're not handling by quickly looking
at the FIXME. Any reason
On 02/18/2010 01:44 PM, MD.IMAM HOSSAIN wrote:
The bug is from DirectX 8.1 SDK, C++ samples, Direct3D samples, SkinnedMesh.
Please, see the attached file for clear idea.
Tested with latest wine 1.1.38
Probably this: http://bugs.winehq.org/show_bug.cgi?id=6955
Missing vertex blending.
--
Hi Alexandre,
+if (ReadEventLogA(handle, EVENTLOG_SEQUENTIAL_READ |
EVENTLOG_FORWARDS_READ,
+ 0, buf, sizeof(EVENTLOGRECORD), read, needed))
+{
I don't think this is correct. The first call will always fail as the
buffer is not big enough. This now
On Mon, Feb 15, 2010 at 4:05 PM, Ove Kaaven o...@arcticnet.no wrote:
Sure it might be confusing, because that's not how the logic goes in the
Microsoft world. Over there, the big machine acting as Terminal Server
thing is the server, and the Remote Desktop client, which provides the
actual
On 18 February 2010 22:08, Steven Edwards winehac...@gmail.com wrote:
On Mon, Feb 15, 2010 at 4:05 PM, Ove Kaaven o...@arcticnet.no wrote:
Sure it might be confusing, because that's not how the logic goes in the
Microsoft world. Over there, the big machine acting as Terminal Server
thing is
Steven Edwards skrev:
On Mon, Feb 15, 2010 at 4:05 PM, Ove Kaaven o...@arcticnet.no wrote:
Sure it might be confusing, because that's not how the logic goes in the
Microsoft world. Over there, the big machine acting as Terminal Server
thing is the server, and the Remote Desktop client, which
In exploring a bug in a game we* ran across an interesting difference
between how Windows versions handle a multiple-processor request. In
essence, this supposedly invalid request will succeed on newer Windows
versions **:
SetThreadAffinityMask(curthread,(-1));
So, the question I have is whether
Hi Erich,
On Thu, Feb 18, 2010 at 3:15 PM, Erich Hoover ehoo...@mines.edu wrote:
In exploring a bug in a game we* ran across an interesting difference
between how Windows versions handle a multiple-processor request. In
essence, this supposedly invalid request will succeed on newer Windows
On Thu, Feb 18, 2010 at 8:51 PM, Erich Hoover ehoo...@mines.edu wrote:
Real Name:
Erich Hoover
Description:
The attached patch adds a test for
SetThreadAffinityMask(thread,-1), which succeeds on Windows Vista and
newer. This all processors flag is not documented, but was
discovered
On Thu, Feb 18, 2010 at 8:29 PM, Andrew Nguyen arethus...@gmail.com wrote:
On Thu, Feb 18, 2010 at 8:51 PM, Erich Hoover ehoo...@mines.edu wrote:
...
The attached patch adds a test for
SetThreadAffinityMask(thread,-1), which succeeds on Windows Vista and
newer.
...
The test shouldn't
Then the test could only be triggered in Wine. What if this feature
gets removed again in some later version of Windows?
broken() only applies to Windows versions, Wine never succeeds with a
broken feature. It really is what you want.
--Juan
On Thu, Feb 18, 2010 at 8:45 PM, Juan Lang juan.l...@gmail.com wrote:
Then the test could only be triggered in Wine. What if this feature
gets removed again in some later version of Windows?
broken() only applies to Windows versions, Wine never succeeds with a
broken feature. It really is
I'm not arguing with the behavior of broken(). I'm saying that since
this feature is undocumented it's entirely possible that it could get
removed in some future version of Windows*, so if we're not testing
the version we wouldn't know that it got removed. We were lucky to
stumble upon this
On Thu, Feb 18, 2010 at 8:59 PM, Juan Lang juan.l...@gmail.com wrote:
I'm not arguing with the behavior of broken(). I'm saying that since
this feature is undocumented it's entirely possible that it could get
removed in some future version of Windows*, so if we're not testing
the version we
Erich Hoover wrote:
Real Name:
Erich Hoover
Description:
Patch 2 added support for the all processors flag, so this is
no-longer a todo. This version is against the revised patch 1, please
note that patch 2 is unchanged.
ChangeLog:
kernel32/tests: Test for 'all processors' now
29 matches
Mail list logo
