July 2014 - Wine-Devel - list.winehq.org

Re: [PATCH 1/4] vbscript: Implemented ScriptEngine

by Marvin

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 https://testbot.winehq.org/JobDetails.pl?Key=8114 Your paranoid android. === build (build) === Patch failed to apply

July 28, 2014

Partial fix for issue 17982 (PatBlt cannot draw arbitrary parallelograms based on the world transform)

by Alexander Almaleh

I made a partial fix of this bug - https://bugs.winehq.org/show_bug.cgi?id=17982, only for the PATCOPY rop. It's based on the observation that the Polygon() function does support arbitrary parallelograms, including when defined through the XFORM matrix, so for PATCOPY we can just delegate the implementation to it (with a NULL_PEN because PatBlt doesn't use a pen). Is this patch acceptable? I have no idea if delegating to Polygon() will hurt performance. If that is a concern, I can do it only in case the physical coordinates after the world transform are not rectangular. If it is, I will submit it to wine-patches, then.

July 28, 2014

XInput over SDL

by akjsdfk sdkfnskd

Long story short, while I helped my friend with his "up to the neck in MS API" game, I wrote him complete drop in solution library for XInput over SDL. And since making patch for wine was easier than testing his half done game... well, it came to full featured XInput handling It supports: - hotplugging/unplugging (well, only if game didn't use DInput to scan new devices. if it is pure XInput, then it just works) - all controllers supported by SDL are XInput capable - haptic works And before cleaning it, I just wanted to ask if XInput over SDL is wanted or not. There is no point in working on regular patch if that is out of question. Just short points why SDL and not native (which I'm not interested in even remotely): - far better API than XInput - controller database is updated - completely cross platform - same source can be reused to port game ... but, don't treat this as I would try starting some holy war. If it doesn't fit in wine plans, no problem. I can still provide it as standalone patch for those that want it with regards wh1sper_123

July 26, 2014

Re: [1/2] imagehlp/tests: Add test for BindImageEx (try 12)

by Bernhard Reiter

Am 2014-07-24 um 18:33 schrieb Alexandre Julliard: > Bernhard Reiter <ockham(a)raz.or.at> writes: > >> @@ -31,6 +31,8 @@ >> static HMODULE hImageHlp; >> >> static BOOL (WINAPI *pImageGetDigestStream)(HANDLE, DWORD, DIGEST_FUNCTION, DIGEST_HANDLE); >> +static BOOL (WINAPI *pBindImageEx)(DWORD Flags, const char *ImageName, const char *DllPath, >> + const char *SymbolPath, void *StatusRoutine); > > That's not the correct prototype. Meaning I should change the const char*s to char*s (as MSDN says PSTR)? I was looking at the BindImageEx stub in dlls/imagehlp/modify.c, and that had PCSTRs. (Or do you mean using PIMAGEHLP_STATUS_ROUTINE instead of void* for StatusRoutine? Because that would require me to typecast testing_status_routine to that when invoking pBindImageEx, wouldn't it?) >> +static BOOL WINAPI testing_status_routine(IMAGEHLP_STATUS_REASON reason, char *ImageName, >> + char *DllName, ULONG_PTR Va, ULONG_PTR Parameter) >> +{ >> + char kernel32_path[MAX_PATH]; >> + >> + status_routine_called[reason]++; > > This will have nasty results if you get an unexpected code. Okay, I'll add checks if reason is in the expected range. > >> + default: >> + ok(0, "expected reason to be one of BindImportModule, BindImportProcedure, or " >> + "BindForwarderNOT, got %d\n", reason); > > Please simplify your error messages. In particular, this one would need > to be changed every time the test is expanded, that's not a good idea. I'm not exactly creative how to change this... would ok(0, "testing_status_routine got wrong reason %d\n", reason); be okay? >> +static void test_bind_image_ex(void) >> +{ >> + BOOL ret; >> + HANDLE file; >> + char temp_file[MAX_PATH] = "nonexistant.dll"; > > There's no reason to use a variable for this. But I need it later to retrieve the name of the file created by create_temp_file. Plus, if I change the const char*s in pBindImageEx's declaration to char*s, I will run into problems here if I pass a const char* to pBindImageEx, won't I? So is it okay to leave it as it is or am I overlooking something? >> + /* Under 64 bit images of Vista Ultimate, 2008 Server, and 7 Pro, StatusRoutine is called with >> + * reason BindForwarderNOT instead of BindImportProcedure. */ >> + todo_wine ok((status_routine_called[BindImportProcedure] == 1) || >> + (status_routine_called[BindForwarderNOT] == 1), >> + "Expected StatusRoutine to be called once with reason BindImportProcedure or " >> + "BindForwarderNOT, but it was called %d and %d times, respectively\n", >> + status_routine_called[BindImportProcedure], status_routine_called[BindForwarderNOT]); > > You'd most likely want the test to depend on 32/64-bit instead of always > accepting both. I had #if defined(_WIN64) macros there earlier, but the behavior isn't consistent: Windows 8 gives BindImportProcedure also with the 64 bit image. (I tried it with test job 7953, if that can be retrieved somehow. Could that BindForwarderNOT be due to a bug in WoW that was fixed in Windows 8?) I asked on #winehackers if I should add a check for the Windows version, but people suggested not to. What's your stance on this? Bernhard

July 25, 2014

Re: dlls/ntdll/signal_i386.c changes break FreeBSD

by Gerald Pfeifer

On Fri, 25 Jul 2014, Bruno Jesus wrote: > Wasn't it fixed by: > http://source.winehq.org/git/wine.git/commitdiff/09ffb97fddacbd5f6c424fcd6e… Yes, it is! That crossed with my looking into it and sending that mail. Thanks for Francois for the quick fix. Gerald

July 25, 2014

Re: dlls/ntdll/signal_i386.c changes break FreeBSD

by Bruno Jesus

On Thu, Jul 24, 2014 at 7:05 PM, Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > Over the last 24 hours, signal_i386.c stopped building on FreeBSD/i386 > 10.0 as follows: > .... > > Gerald Wasn't it fixed by: http://source.winehq.org/git/wine.git/commitdiff/09ffb97fddacbd5f6c424fcd6e… Best wishes, Bruno

July 25, 2014

Re: [1/3] oleaut32: Add test for TLB dependencies lookup in resources (try 2)

by Guillaume Charifi

Alexandre Julliard wrotes: > Simply create it directly into a temp dir, no moving needed. I am reusing a TLB created by building process, because this test requires two typelibs, to check whether or not, from a TypeInfo requested from one of them, we can get the corresponding RefTypeInfo from the other. The aim is to see if the imlementation can find the TypeLib in which the RefTypeInfo is. So I don't really need to create it at runtime, I just need it to be in the ressource table of the test program, and nowhere else.

July 25, 2014

Re: [1/3] oleaut32: Add test for TLB dependencies lookup in resources (try 2)

by Guillaume Charifi

Alexandre Julliard wrotes: > Simply create it directly into a temp dir, no moving needed. I am reusing a TLB created by building process, because this test requires two typelibs, to check whether or not, from a TypeInfo requested from one of them, we can get the corresponding RefTypeInfo from the other. The aim is to see if the imlementation can find the TypeLib in which the RefTypeInfo is. So I don't really need to create it at runtime, I just need it to be in the ressource table of the test program, and nowhere else.

July 25, 2014

Re: [1/3] oleaut32: Add test for TLB dependencies lookup in resources (try 2)

by Guillaume Charifi

Alexandre Julliard writes : > If the goal of the test is to see what happens when it can't be found in > the path, you need to make sure that it can never be found. If you skip > in that case you are not testing anything. Okay, I see. Am I right if I move the TLB in a temporary folder before the test, and move it back after?

July 25, 2014

Re: [1/3] oleaut32: Add test for TLB dependencies lookup in resources (try 2)

by Alexandre Julliard

Guillaume Charifi <guillaume.charifi(a)sfr.fr> writes: > Alexandre Julliard <julliard at winehq.org> writes: > It doesn't work > here: > > ../../../tools/runtest -q -P wine -T ../../.. -M > oleaut32.dll -p oleaut32_test.exe.so typelib && touch typelib.ok > > typelib.c:5528: Test failed: test_tlb.tlb is on the path or registered >> typelib.c:5542: Test succeeded inside todo block: got: 0 > make[1]: > *** [typelib.ok] Error 2 > > Yes, in fact the test does not make sense if the test_tlb.tlb is locatable on disk by the program, it must be out of the path. > That's why I was initially just skipping the test if test_tlb.tlb could be loaded from disk, but some suggested me to make the > test fail in that case. > Should I restore the old behaviour ? Or do something else ? If the goal of the test is to see what happens when it can't be found in the path, you need to make sure that it can never be found. If you skip in that case you are not testing anything. -- Alexandre Julliard julliard(a)winehq.org

July 25, 2014