Re: [PATCH] comctl32/tests: DateTimePicker and MonthCalendar controls only support Gregorian calendar.
On 19 August 2010 16:34, Nikolay Sivov wrote: > On Thu, Aug 19, 2010 at 9:50 AM, Austin Lund wrote: >> http://www.microsoft.com/middleeast/msdn/ArabicCalendar.aspx > > Hi, Austin. > > This information is outdated probably. There's a message to set a > calendar for MonthCal at least, see: > > http://msdn.microsoft.com/en-us/library/bb760995%28VS.85%29.aspx > > Not sure about DateTimePicker, it uses Monthcal internally so a > calendar could still be switched. > Anyway this won't work on pre-Vista and without a manifest for v6, but > you could enable tests using V6 loading > helpers that we have already and MCM_SETCALID message, so tests will > run on Arabic or some Asian boxes. > I don't understand what you are suggesting exactly. Is it that the CALID of the MonthCal be set to the locale CALID or to set it to the Gregorian CALID? Either way I don't see how it helps as the problem is with the control of functions like GetDateFormat to choose a CALID which matches the one which the controls falls back on when the locale has a non-Gregorian calendar (something I haven't figured out).
Re: [PATCH] comctl32/tests: DateTimePicker and MonthCalendar controls only support Gregorian calendar.
On Thu, Aug 19, 2010 at 9:50 AM, Austin Lund wrote: > http://www.microsoft.com/middleeast/msdn/ArabicCalendar.aspx Hi, Austin. This information is outdated probably. There's a message to set a calendar for MonthCal at least, see: http://msdn.microsoft.com/en-us/library/bb760995%28VS.85%29.aspx Not sure about DateTimePicker, it uses Monthcal internally so a calendar could still be switched. Anyway this won't work on pre-Vista and without a manifest for v6, but you could enable tests using V6 loading helpers that we have already and MCM_SETCALID message, so tests will run on Arabic or some Asian boxes.
Re: [PATCH 5/5] ddraw: Allow creating back buffer for DirectX 1 interfaces. (try 5, resend)
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4557 Your paranoid android. === W2KPROSP4 (32 bit visual) === visual.c:1619: Test failed: Got color 000a246a, expected 00ff0040 or near visual.c:1625: Test failed: Got color 006b8bbd, expected 00ff0080 or near === W98SE (32 bit dsurface) === No test summary line found
Re: [PATCH 1/5] ddraw/tests: Add test for bad size of surface caps in CreateSurface. (try 5, resend)
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4553 Your paranoid android. === W98SE (32 bit dsurface) === No test summary line found
Re: [PATCH 2/2] gameux/tests: verifying registry values created by GameExplorer (try 2)
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4552 Your paranoid android. === W98SE (32 bit gameexplorer) === Failure running script in VM: Exceeded timeout limit of 315 sec === W2KPROSP4 (32 bit gameexplorer) === Timeout === WXPPROSP3 (32 bit gameexplorer) === Timeout
Re: ntdll: IMAGE_REL_BASED_HIGH, IMAGE_REL_BASED_HIGH and IMAGE_REL_BASED_HIGHLOW are supported on win64.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4548 Your paranoid android. === W98SE (32 bit rtl) === Failure running script in VM: Exceeded timeout limit of 315 sec
Re: dlls/d3dx9_36/bytecodewriter.c oddity
2010/8/18 Gerald Pfeifer :
> Metteo et al,
>
> I noticed d3dx9_36/bytecodewriter.c can be simplified as follows, but
> somewhat tells me this may rather point out a problem somewhere in that
> code, so I am not sending this to wine-patches.
>
> (The only functional difference should be the missing WARN in some cases,
> and I could restore that if desired, but...see above.)
>
> Thoughts? Guidance?
>
> Gerald
>
>
> diff --git a/dlls/d3dx9_36/bytecodewriter.c
> b/dlls/d3dx9_36/bytecodewriter.c
> index 07f96e7..e7bd8a5 100644
> --- a/dlls/d3dx9_36/bytecodewriter.c
> +++ b/dlls/d3dx9_36/bytecodewriter.c
> @@ -1035,7 +1035,7 @@ static const struct bytecode_backend vs_1_x_backend = {
> static void instr_ps_1_0123_texld(struct bc_writer *This,
> const struct instruction *instr,
> struct bytecode_buffer *buffer) {
> - DWORD idx, srcidx;
> + DWORD idx;
> struct shader_reg reg;
> DWORD swizzlemask;
>
> @@ -1074,17 +1074,6 @@ static void instr_ps_1_0123_texld(struct bc_writer
> *This,
> /* map the temp dstreg to the ps_1_3 texture temporary register */
> This->funcs->dstreg(This, &instr->dst, buffer, instr->shift,
> instr->dstmod);
> } else if(instr->src[0].type == BWRITERSPR_TEMP) {
> - if(instr->src[0].regnum == T0_REG) {
> - srcidx = 0;
> - } else if(instr->src[0].regnum == T1_REG) {
> - srcidx = 1;
> - } else if(instr->src[0].regnum == T2_REG) {
> - srcidx = 2;
> - } else if(instr->src[0].regnum == T3_REG) {
> - srcidx = 3;
> - } else {
> - WARN("Invalid address data source register r%u\n",
> instr->src[0].regnum);
> - }
>
> swizzlemask = (3 << BWRITERVS_SWIZZLE_SHIFT) |
> (3 << (BWRITERVS_SWIZZLE_SHIFT + 2)) |
>
Hmm, so srcidx is unused. Yes, that piece of code is useless now, it's
a remnant of an older version of that function where the source
register was handled by some ad-hoc code, which I since then replaced
with a call to the generic This->funcs->srcreg(). The function is
correct otherwise, there are some tests to confirm that.
In my opinion you can send the patch as is. Alternatively you can
replace that piece of code with just a check for instr->src[0].regnum
!= T[0123]_REG, to keep the WARN, but it's not worth the effort
probably.
Thanks!
dlls/d3dx9_36/bytecodewriter.c oddity
Metteo et al,
I noticed d3dx9_36/bytecodewriter.c can be simplified as follows, but
somewhat tells me this may rather point out a problem somewhere in that
code, so I am not sending this to wine-patches.
(The only functional difference should be the missing WARN in some cases,
and I could restore that if desired, but...see above.)
Thoughts? Guidance?
Gerald
diff --git a/dlls/d3dx9_36/bytecodewriter.c
b/dlls/d3dx9_36/bytecodewriter.c
index 07f96e7..e7bd8a5 100644
--- a/dlls/d3dx9_36/bytecodewriter.c
+++ b/dlls/d3dx9_36/bytecodewriter.c
@@ -1035,7 +1035,7 @@ static const struct bytecode_backend vs_1_x_backend = {
static void instr_ps_1_0123_texld(struct bc_writer *This,
const struct instruction *instr,
struct bytecode_buffer *buffer) {
-DWORD idx, srcidx;
+DWORD idx;
struct shader_reg reg;
DWORD swizzlemask;
@@ -1074,17 +1074,6 @@ static void instr_ps_1_0123_texld(struct bc_writer *This,
/* map the temp dstreg to the ps_1_3 texture temporary register */
This->funcs->dstreg(This, &instr->dst, buffer, instr->shift,
instr->dstmod);
} else if(instr->src[0].type == BWRITERSPR_TEMP) {
-if(instr->src[0].regnum == T0_REG) {
-srcidx = 0;
-} else if(instr->src[0].regnum == T1_REG) {
-srcidx = 1;
-} else if(instr->src[0].regnum == T2_REG) {
-srcidx = 2;
-} else if(instr->src[0].regnum == T3_REG) {
-srcidx = 3;
-} else {
-WARN("Invalid address data source register r%u\n",
instr->src[0].regnum);
-}
swizzlemask = (3 << BWRITERVS_SWIZZLE_SHIFT) |
(3 << (BWRITERVS_SWIZZLE_SHIFT + 2)) |
Re: [PATCH 1/3] gameux: Add definitions of resource identifiers to header file
W dniu 18.08.2010 19:34, GOUJON Alexandre pisze: On 08/18/2010 07:06 PM, Mariusz Pluciński wrote: Can I do it by passing __LINE__ macro as parameter to my _validate* functions? Some tests already use __LINE__ as a parameter. See http://source.winehq.org/git/wine.git/?a=blob;f=dlls/advapi32/tests/cred.c#l260 and http://source.winehq.org/git/wine.git/?a=blob;f=dlls/advapi32/tests/cred.c#l201 for instance. Thanks for these examples. I though about little different solution, but this looks really easier than my ideas.
Re: [PATCH 1/3] gameux: Add definitions of resource identifiers to header file
On 08/18/2010 07:06 PM, Mariusz Pluciński wrote: Can I do it by passing __LINE__ macro as parameter to my _validate* functions? Some tests already use __LINE__ as a parameter. See http://source.winehq.org/git/wine.git/?a=blob;f=dlls/advapi32/tests/cred.c#l260 and http://source.winehq.org/git/wine.git/?a=blob;f=dlls/advapi32/tests/cred.c#l201 for instance.
Re: [PATCH 1/3] gameux: Add definitions of resource identifiers to header file
W dniu 18.08.2010 18:09, Vincent Povirk pisze: I think it would be helpful if you passed a string description to your _validate functions so that in case of failure, you can tell where the original call to _validateGameRegistryKey was, instead of just the line containing the ok() call. Can I do it by passing __LINE__ macro as parameter to my _validate* functions?
Re: [PATCH 3/3] gameux/tests: verifying registry values created by GameExplorer
W dniu 18.08.2010 18:28, Andrew Eikum pisze: This result is strange, cause routine modified by this patch (called test_add_remove_game ) is not even called on these operating systems - and test added by my previous patch demonstrates it (and it succeeded). Did I something wrong? I cannot imagine how it could fail when previous test was succeeded. You can see the error message dialog in the screenshots on the testbot result webpage. In this case, you've got missing exports, ConvertSidToSidStringW and RegGetValueW. Some solutions are to make those into function pointers (and skip appropriately if they're missing), use the A versions if they exist, or use a different function that exists on more platforms. Andrew I understand. Thank you very much for the explanation. I did not know, that new code can interfere in any way on systems where it is never called. W dniu 18.08.2010 18:33, Vincent Povirk pisze: Oh. Personally, I would ignore failures on operating systems< Vista, since gameux won't be present and the tests would not normally be run. OK, I'll see if my patch is accepted despite of these results. If not, I'll modify it, to make it calling these routines through pointers.
Re: [PATCH 3/3] gameux/tests: verifying registry values created by GameExplorer
> You can see the error message dialog in the screenshots on the testbot > result webpage. In this case, you've got missing exports, > ConvertSidToSidStringW and RegGetValueW. Some solutions are to make those > into function pointers (and skip appropriately if they're missing), use the > A versions if they exist, or use a different function that exists on more > platforms. Oh. Personally, I would ignore failures on operating systems < Vista, since gameux won't be present and the tests would not normally be run.
Re: [PATCH 3/3] gameux/tests: verifying registry values created by GameExplorer
This result is strange, cause routine modified by this patch (called test_add_remove_game ) is not even called on these operating systems - and test added by my previous patch demonstrates it (and it succeeded). Did I something wrong? I cannot imagine how it could fail when previous test was succeeded. You can see the error message dialog in the screenshots on the testbot result webpage. In this case, you've got missing exports, ConvertSidToSidStringW and RegGetValueW. Some solutions are to make those into function pointers (and skip appropriately if they're missing), use the A versions if they exist, or use a different function that exists on more platforms. Andrew
Re: [PATCH 3/3] gameux/tests: verifying registry values created by GameExplorer
The testbot gives weird results at times. I wouldn't worry about it. 2010/8/18 Mariusz Pluciński : > W dniu 18.08.2010 17:49, (Marvin) pisze: >> >> Hi, >> >> While running your changed tests on Windows, I think I found new failures. >> Being a bot and all I'm not very good at pattern recognition, so I might >> be >> wrong, but could you please double-check? >> Full results can be found at >> http://testbot.winehq.org/JobDetails.pl?Key=4540 >> >> Your paranoid android. >> >> >> === W98SE (32 bit gameexplorer) === >> Failure running script in VM: Exceeded timeout limit of 315 sec >> >> === W2KPROSP4 (32 bit gameexplorer) === >> Timeout >> >> === WXPPROSP3 (32 bit gameexplorer) === >> Timeout >> > > This result is strange, cause routine modified by this patch (called > test_add_remove_game ) is not even called on these operating systems - and > test added by my previous patch demonstrates it (and it succeeded). Did I > something wrong? I cannot imagine how it could fail when previous test was > succeeded. > > >
Re: [PATCH 3/3] gameux/tests: verifying registry values created by GameExplorer
W dniu 18.08.2010 17:49, (Marvin) pisze: Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4540 Your paranoid android. === W98SE (32 bit gameexplorer) === Failure running script in VM: Exceeded timeout limit of 315 sec === W2KPROSP4 (32 bit gameexplorer) === Timeout === WXPPROSP3 (32 bit gameexplorer) === Timeout This result is strange, cause routine modified by this patch (called test_add_remove_game ) is not even called on these operating systems - and test added by my previous patch demonstrates it (and it succeeded). Did I something wrong? I cannot imagine how it could fail when previous test was succeeded.
Re: [PATCH 1/3] gameux: Add definitions of resource identifiers to header file
> @@ -32,7 +33,6 @@
>
> #include "wine/test.h"
>
> -
> static void test_create(BOOL* gameExplorerAvailable, BOOL*
> gameExplorer2Available)
> {
> HRESULT hr;
Don't put formatting changes in functional patches, please.
I think it would be helpful if you passed a string description to your
_validate functions so that in case of failure, you can tell where the
original call to _validateGameRegistryKey was, instead of just the
line containing the ok() call.
Re: [PATCH 3/3] gameux/tests: verifying registry values created by GameExplorer
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4540 Your paranoid android. === W98SE (32 bit gameexplorer) === Failure running script in VM: Exceeded timeout limit of 315 sec === W2KPROSP4 (32 bit gameexplorer) === Timeout === WXPPROSP3 (32 bit gameexplorer) === Timeout
Re: [PATCH 5/6] gameux: Add initial implementation of IGameExplorer2::CheckAccess method
Hello
W dniu 16.08.2010 10:00, Mariusz Pluciński pisze:
---
dlls/gameux/gameexplorer.c | 7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
This is patch I sent to wine-patches yesterday. It was marked as
"Pending". I know that what I sent is not proper solution. But as I
wrote in FIXME, it's in my opinion impossible to implement it properly,
cause from what I know Wine does not support parental control. So,
instead of doing real check, my function simply always grants access.
My question is: what should I do with it? It cannot be left stub, as
there's already bug caused by this (bug #23850). And probably every game
which uses Game Explorer will behave that same. Should I write test case
to demonstrate that native works that same in most cases?
>From 89f720c9883ed73472c6a8e4350d911672cd8c73 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Mariusz=20Pluci=C5=84ski?=
Date: Sun, 1 Aug 2010 22:05:01 +0100
Subject: gameux: Add initial implementation of IGameExplorer2::CheckAccess method
To: wine-patches
Reply-To: wine-devel
---
dlls/gameux/gameexplorer.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/dlls/gameux/gameexplorer.c b/dlls/gameux/gameexplorer.c
index b8f57a7..25360a8 100644
--- a/dlls/gameux/gameexplorer.c
+++ b/dlls/gameux/gameexplorer.c
@@ -206,8 +206,11 @@ static HRESULT WINAPI GameExplorer2Impl_CheckAccess(
BOOL *pHasAccess)
{
GameExplorerImpl *This = impl_from_IGameExplorer2(iface);
-FIXME("stub (%p, %s, %p)\n", This, debugstr_w(binaryGDFPath), pHasAccess);
-return E_NOTIMPL;
+TRACE("(%p, %s, %p)\n", This, debugstr_w(binaryGDFPath), pHasAccess);
+FIXME("not properly implemented due to lack of parental control support in Wine\n");
+/* access is always granted, it should make all applications working */
+*pHasAccess = TRUE;
+return S_OK;
}
static HRESULT WINAPI GameExplorer2Impl_InstallGame(
--
1.7.2
Re: [PATCH 1/1] d3dx9: Add tests for FVF <-> declaration conversion.
Misha Koshelev writes:
> +#define VDECL_CHECK(fcall) \
> +if(fcall != S_OK) \
> +trace(" Test failed on line #%d\n", __LINE__);
> +
> +#define VDECL_CHECK_FAIL(fcall) \
> +if(fcall != E_FAIL) \
> +trace(" Test failed on line #%d\n", __LINE__);
That's ugly. If the goal is to print the line number, you should pass it
to the test function.
--
Alexandre Julliard
julli...@winehq.org
Re: [PATCH 1/2] ntdll: Implement RtlIpv4AddressToString / RtlIpv4AddressToStringEx [try 3]
Detlef Riekenberg writes: > +in = *pin; What is this for? -- Alexandre Julliard julli...@winehq.org
Re: Wine64 debugger
On 18/08/10 01:51, Marcus Meissner wrote: On Wed, Aug 18, 2010 at 01:00:35AM +1000, Peter Urbanec wrote: I'm seeing crashes in FindNextFileW/FindNextFileA due to what looks like a 64 bit HANDLE value being truncated to 32 bits. Check if your code uses "int" in its FindNextFile or findfirst things. I had a good look at the wine source code as well as those parts of the application source code that I can get access to and it all looks good as far as correctly using HANDLE type to store HANDLE values. Unfortunately, the application in question also makes use of FLEXlm libraries from Macrovision and these binary blobs appear to be buggy. All the symptoms point to the FLEXlm code storing the 64-bit HANDLE value in a 32-bit int - this is evidenced by sign extension on some of the values. Of course, the initial cause and the issues with the debugger are essentially unrelated. I have sent some sample test binaries to Eric, to reproduce the debugger issue. The buggy Win64 application is another story. It looks like Win64 must most of the time return HANDLE values that fit within 31 bits, because from what I hear, Windows users go through thousands of invocations of this app without seeing any issues. I wonder if there is a way of making wine allocate the memory for the object pointed to by the HANDLE somewhere in the lower part of the address space. That ought to mitigate this particular application bug and bring the compatibility a little closer to what's observed under Win64.
have all MCI tests in winmm/tests/ or distributed across mci*/tests/?
Hi, although my patch creates mcicda/tests/ I'd like to query whether it would make more sense to have all mci tests grouped in winmm/tests/. Pro: + Future fixes to winmm/mci.c would affect winmm/tests/*.c only. E.g. when I'll make "stop all" work I'd have to touch mcicda/tests/mcicda.c as well to eliminate the todo_wine there. Same when I'll patch mciparse to accept [TT:]MM:SS:FF format. + When Maarten will write mciqtz tests, perhaps resources could be reused to execute mciavi tests as well (the file creation code need not be duplicated). Similar tests could be written for: "open foo.avi" (mciavi) and "open foo.avi type mpegvideo" (mciqtz) or "open foo.wav" (micwave) and "open foo.wav type mpegvideo" although there's some difference in behaviour. + The functions test_notification could be in one file only, not repeated. I can rewrite my current mcicda/tests/mcicda.c patch to live in winmm/tests/. What do you think? Jörg Höhle
Re: [PATCH] advapi32: Add magic codes to HCRYPTKEY and HCRYPTHASH.
On 18 August 2010 20:44, GOUJON Alexandre wrote: > On 08/18/2010 12:22 PM, Hans Leidekker wrote: >> >> They are often built from four character ascii strings to help find out >> where the structures come from. I don't know why this one was chosen >> but I guess you could use something like 0xA39E741E and 0xA39E741D. >> > > Yep, there are some magic values at http://en.wikipedia.org/wiki/Hexspeak > FYI, MAGIC_CRYPTPROV comes from the following commit > http://source.winehq.org/git/wine.git/?a=commitdiff;h=44cb0906da3dddbca1fe670e723b4d03aa3e2488 > None of that answers the "why" question except perhaps the part about unaligned pointer values which isn't really relevant for modern architectures. I'll wait for any further feedback, try something like above and resubmit tomorrow.
Re: wldap32: Fix handling of zero timeout value in ldap_search_extW. (try 2)
On Wed, 2010-08-18 at 13:41 +0200, test...@testbot.winehq.org wrote: > While running your changed tests on Windows, I think I found new failures. > Being a bot and all I'm not very good at pattern recognition, so I might be > wrong, but could you please double-check? > Full results can be found at > http://testbot.winehq.org/JobDetails.pl?Key=4530 > > Your paranoid android. > > > === W2KPROSP4 (32 bit parse) === > parse.c:101: Test failed: ldap_search_extW failed 0x0034 > parse.c:105: Test failed: ldap_search_extW failed 0x0051 0x34 == LDAP_UNAVAILABLE, likely caused by a network problem.
Re: wldap32: Fix handling of zero timeout value in ldap_search_extW. (try 2)
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4530 Your paranoid android. === W2KPROSP4 (32 bit parse) === parse.c:101: Test failed: ldap_search_extW failed 0x0034 parse.c:105: Test failed: ldap_search_extW failed 0x0051
Re: [4/5] msi: Handle signature filenames in short|long notation.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4528 Your paranoid android. === W7PROX64 (32 bit package) === package.c:8348: Test failed: Expected "C:\Program Files\VMware\VMware Tools\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\", got "C:\Program Files (x86)\VMware\VMware Tools\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\" === W7PROX64 (64 bit package) === package.c:8385: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8396: Test failed: Expected "C:\winetest\", got "" package.c:8407: Test failed: Expected "C:\winetest\", got "" package.c:8457: Test failed: Expected "C:\winetest\FileName3.dll", got "" package.c:8468: Test failed: Expected "C:\winetest\FileName5.dll", got "" package.c:8477: Test failed: Expected "C:\", got "" package.c:8483: Test failed: Expected "C:\winetest\", got "" package.c:8504: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8513: Test failed: Expected "C:\winetest\FileName1", got ""
Re: [3/5] msi/tests: Skip SourceDir tests on win9x.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4527 Your paranoid android. === W2K3R2SESP2 (32 bit install) === Timeout
Re: Wine64 debugger
the assertion `addr->Mode == AddrModeFlat' failed is likely an address returned by dbghelp which is not properly initialized. Could you send me off line the .exe (and associated DLL if any) so that I can check it TIA 2010/8/17 Peter Urbanec > > Hi, > > I'm trying to get a fairly complex Win64 application to work with wine. I'm > seeing crashes in FindNextFileW/FindNextFileA due to what looks like a 64 > bit HANDLE value being truncated to 32 bits. I thought that I would employ > winedbg to help me, but I can't get very far. I don't have any luck with > winedbg even on a simple x64 Win32 app. > > For my simplified test, I used MSVC2005 to generate an x64 executable > created from the standard MSVC2005 template Win32 application. This is a > simple app that just creates an empty window. As simple as one could get for > a Win32 test and it executes correctly when run as "./wine Test1.exe". When > I try to execute this test app under winedbg, I get an assert failure: > > ./wine winedbg Test1.exe > WineDbg starting on pid 001a > ./programs/winedbg/memory.c:37: be_cpu_linearize: Assertion `addr->Mode == > AddrModeFlat' failed. > wine: Assertion failed at address 0x7fec2fa657c5 (thread 0009), starting > debugger... > Unhandled exception: assertion failed in 64-bit code (0x7fec2fa657c5). > > Any ideas about why I can not use winedbg to run Win32 x64 code? > > Thanks, > >Peter Urbanec > > > > > > > -- -- Eric Pouech
Re: [2/5] msi/tests: Use HKEY_CURRENT_USER instead of HKEY_LOCAL_MACHINE for registry tests.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4526 Your paranoid android. === W2K3R2SESP2 (32 bit install) === Timeout
Re: [PATCH] advapi32: Add magic codes to HCRYPTKEY and HCRYPTHASH.
On 08/18/2010 12:22 PM, Hans Leidekker wrote: They are often built from four character ascii strings to help find out where the structures come from. I don't know why this one was chosen but I guess you could use something like 0xA39E741E and 0xA39E741D. Yep, there are some magic values at http://en.wikipedia.org/wiki/Hexspeak FYI, MAGIC_CRYPTPROV comes from the following commit http://source.winehq.org/git/wine.git/?a=commitdiff;h=44cb0906da3dddbca1fe670e723b4d03aa3e2488
Re: [1/5] msi/tests: Fix some WoW64 test failures.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4525 Your paranoid android. === W7PROX64 (32 bit package) === package.c:8329: Test failed: Expected "C:\Program Files\VMware\VMware Tools\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\", got "C:\Program Files (x86)\VMware\VMware Tools\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\" === W7PROX64 (64 bit package) === package.c:8366: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8377: Test failed: Expected "C:\winetest\", got "" package.c:8388: Test failed: Expected "C:\winetest\", got "" package.c:8438: Test failed: Expected "C:\winetest\FileName3.dll", got "" package.c:8449: Test failed: Expected "C:\winetest\FileName5.dll", got "" package.c:8458: Test failed: Expected "C:\", got "" package.c:8464: Test failed: Expected "C:\winetest\", got "" package.c:8485: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8494: Test failed: Expected "C:\winetest\FileName1", got ""
Re: [PATCH] advapi32: Add magic codes to HCRYPTKEY and HCRYPTHASH.
On Wed, 2010-08-18 at 20:02 +1000, Austin Lund wrote: > On 18 August 2010 18:34, Hans Leidekker wrote: > > On Wed, 2010-08-18 at 10:14 +1000, Austin Lund wrote: > > > >> #define MAGIC_CRYPTPROV 0xA39E741F > >> +#define MAGIC_CRYPTKEY 0xA39E741F > >> +#define MAGIC_CRYPTHASH 0xA39E741F > > > > The app might pass a crypto handle of the wrong type, so it would be > > better to use different magic values. > > > > Are there any rules to these magic values? Why was 0xA39E741F chosen? They are often built from four character ascii strings to help find out where the structures come from. I don't know why this one was chosen but I guess you could use something like 0xA39E741E and 0xA39E741D.
kernel32/tests: GetVolumeInformationA X: succeeds iff drive's default dir is root. (try 2)
Hi, please consider that patch, submitted on the 3rd of August, for inclusion. Tests pass on native w95,w98,w2k,xp,7. Greg Geldorp went into the extra effort to instrument the testbot machines (NT upto 7, not win9X) http://www.winehq.org/pipermail/wine-devel/2010-August/085919.html with a second drive to validate my new tests, avoiding the volume.c:345: Tests skipped: Please re-run from another device than C: of a normal testbot run, such that the GetVolumeInformation tests are not skipped when started from drive E: >In short: everything passes. Thank you, Jörg Höhle
Re: [PATCH] advapi32: Add magic codes to HCRYPTKEY and HCRYPTHASH.
On 18 August 2010 18:34, Hans Leidekker wrote: > On Wed, 2010-08-18 at 10:14 +1000, Austin Lund wrote: > >> #define MAGIC_CRYPTPROV 0xA39E741F >> +#define MAGIC_CRYPTKEY 0xA39E741F >> +#define MAGIC_CRYPTHASH 0xA39E741F > > The app might pass a crypto handle of the wrong type, so it would be > better to use different magic values. > Are there any rules to these magic values? Why was 0xA39E741F chosen?
Re: wldap32: Fix handling of zero timeout value in ldap_search_extW.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4524 Your paranoid android. === W98SE (32 bit parse) === parse.c:108: Test failed: ldap_search_extW failed 0x0059 === WNT4WSSP6 (32 bit parse) === parse.c:108: Test failed: ldap_search_extW failed 0x0059
Re: [PATCH] advapi32: Add magic codes to HCRYPTKEY and HCRYPTHASH.
On Wed, 2010-08-18 at 10:14 +1000, Austin Lund wrote: > #define MAGIC_CRYPTPROV 0xA39E741F > +#define MAGIC_CRYPTKEY 0xA39E741F > +#define MAGIC_CRYPTHASH 0xA39E741F The app might pass a crypto handle of the wrong type, so it would be better to use different magic values.
