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

Wine project aspirant for GSOC 2014 : Tools - Winetest Graphical User Interface

by Siddhartha Narang

Hello , I am Siddhartha Narang a second year Undergraduate in INFORMATION TECHNOLOGY at University Institute of Engineering and Technology (UIET) Panjab University, Chandigarh,India . Skill set :- I have a deep knowledge of C and C++ and have made various games on console like the snake and food, tunnel came , bouncing ball . I have a average knowledge of Data Structures ,linux, Html5. I am currently learning Css . I have gone through various projects of your's for GSOC and the one which interest me a most is Tools - Winetest Graphical User Interface . I am very keen to be a part of this project . What i could interpret from the idea's page about the project is that to build a graphical user interface where user can see the test results . I am very enthusiastic about the coding. I would put my best foot forward to learn as much as I can and try and contribute to your community . It will be very nice of you if you guide me how to go about this project and from where i could start and elaborate what i need to do . Hoping to hear from you soon. -- REGARDS SIDDHARTHA NARANG SECOND YEAR UNDERGRADUATE INFORMATION TECHNOLOGY UIET, PANJAB UNIVERSITY CHANDIGARH , INDIA

March 8, 2014

Re: [RFC 4/11] Linux FF: Linux effect parameter: periodic effect's phase

by Elias Vanderstuyft

On Wed, Mar 5, 2014 at 3:57 PM, Andrew Eikum <aeikum(a)codeweavers.com> wrote: > On Tue, Mar 04, 2014 at 08:20:01PM +0100, Elias Vanderstuyft wrote: >> phase should be related to time, not to angle: >> > > This seems correct to me. I would add a short comment noting that > we're performing the conversion because ff_effect's phase should be a > time parameter, while DIEFFECT's is angle. OK, updating: So change the following in dinput/effect_linuxinput.c:259 : tsp->lOffset = (This->effect.u.periodic.offset / 33) * 10; tsp->dwPhase = (This->effect.u.periodic.phase / 33) * 36; tsp->dwPeriod = (This->effect.u.periodic.period * 1000); to : tsp->lOffset = (This->effect.u.periodic.offset / 33) * 10; if (!This->effect.u.periodic.period) { /* Avoid division by zero period, set tsp->dwPhase arbitrarily to zero. */ tsp->dwPhase = 0; } else /* Conversion because ff_effect's phase is time based, while DIEFFECT's is angle based. */ tsp->dwPhase = (((int)This->effect.u.periodic.phase * 36000) / This->effect.u.periodic.period) % 36000; tsp->dwPeriod = (This->effect.u.periodic.period * 1000); and change the following in dinput/effect_linuxinput.c:486 : This->effect.u.periodic.offset = (tsp->lOffset / 10) * 32; This->effect.u.periodic.phase = (tsp->dwPhase / 9) * 8; /* == (/ 36 * 32) */ This->effect.u.periodic.period = tsp->dwPeriod / 1000; to : This->effect.u.periodic.offset = (tsp->lOffset / 10) * 32; This->effect.u.periodic.period = tsp->dwPeriod / 1000; /* Conversion because ff_effect's phase is time based, while DIEFFECT's is angle based. */ This->effect.u.periodic.phase = ((int)(tsp->dwPhase % 36000) * This->effect.u.periodic.period) / 36000; Elias

March 7, 2014

Re: [RFC 3/11] Linux FF: Linux effect parameter: start delay

by Elias Vanderstuyft

On Wed, Mar 5, 2014 at 3:56 PM, Andrew Eikum <aeikum(a)codeweavers.com> wrote: > On Tue, Mar 04, 2014 at 08:19:56PM +0100, Elias Vanderstuyft wrote: >> a) Keep in mind that startDelay is not supported in DX5 or lower: > > These seem like good fixes. You could add a test by using a DIEFFECT > with its dwSize member set to sizeof(DIEFFECT_DX5) to set/get the > delay value, and seeing if Windows modifies the delay value in the > struct. Alright, I'll create the tests when I have time. Elias

March 7, 2014

Re: [RFC 2/11] Linux FF: Linux effect status management

by Elias Vanderstuyft

On Wed, Mar 5, 2014 at 3:54 PM, Andrew Eikum <aeikum(a)codeweavers.com> wrote: > On Tue, Mar 04, 2014 at 08:19:39PM +0100, Elias Vanderstuyft wrote: >> => This has been discussed (see >> http://www.mail-archive.com/linux-input(a)vger.kernel.org/msg08513.html) >> and the following is true: >> My opinion appeared to be correct, but for to be sure, I was >> recommended to apply the change in Wine as well. >> > > Yes, we should also fix this in Wine to support "buggy" old kernels. > It would be worth adding a short comment to the code explaining which > kernel versions are affected by this bug. At the moment, I did not receive any reaction yet on my kernel patch (although it was suggested by one of the kernel devs): http://www.spinics.net/lists/linux-input/msg29920.html So I don't know yet in what kernel the bug will be resolved. If I my Wine patches make it first to release, what should I write then? "pending as of <current date>"? > >> b) Be more precise in returning errors. >> > > Seems fine. If you can add tests (EINVAL seems easy to test, at > least), that would be even better. But that may be FF driver dependent, for example: - the (soon deprecated) ff-memless driver does not return an error when setting periodic effects' period to zero - the newer ff-memless-next driver does return an error when setting periodic effects' period to zero, and when setting other invalid parameters And I don't know whether Wine tests may rely on drivers? (normally, then you would also need to own a FF capable joystick) Unless you use a dummy-device, of course, but again, I don't think we want to include that in the Wine test tree, right? However on the other hand, I do understand that this should be tested. What do you suggest? > >> c) The following in dinput/effect_linuxinput.c:336 : >> if (res != DI_OK) >> should be probably : >> if (FAILED(res)) >> for example if a device reports S_FALSE because it has already >> updated an identical effect. >> >> The same for line 549: >> if (retval != DI_OK) >> should be then : >> if (FAILED(retval)) >> > > Sure, seems fine. As an additional fix, you could demonstrate with > tests that Download and Start can return S_FALSE under those > circumstances on Windows, and fix the Wine behavior to match. I'm new to Wine's test-framework, suppose I managed to create such test and successfully run it on Wine, how can I compile that test for Windows? (I don't have MS VS, and I prefer to not use it) (Maybe I should also mention that I don't have enough time for the moment to create tests.) BTW, thanks for all feedback so far ;) Elias

March 7, 2014

Re: [RFC 1/11] Linux FF: Joystick control panel program

by Elias Vanderstuyft

On Wed, Mar 5, 2014 at 3:49 PM, Andrew Eikum <aeikum(a)codeweavers.com> wrote: > On Tue, Mar 04, 2014 at 08:19:16PM +0100, Elias Vanderstuyft wrote: >> a) When unloading conditional effects in joy.cpl, the program crashes: >> When unloading the conditional effect array entries, >> Wine tries to access an invalid (high) address because >> dieffect.lpvTypeSpecificParams was not set at the time the >> effect was created. >> So declare a valid 'standard' (maxed out) conditional effect. >> For other unknown effects: >> - The same can happen when CustomForce effects are available, >> but because Wine's FF dinput->linux translation does >> not support this yet, >> we simply print a FIXME to indicate a possible cause >> if a crash would happen. >> - The same for other (unsupported) effects (this is >> probably not safe?), >> but then we print a WARN. > > For unhandled types, it's probably best to print a FIXME and return > DIENUM_CONTINUE, rather than continue to rely on uninitialized data. Alright. Should I also write the extra if-test for the CustomForce type, or do I have to cover it with one if-test as an unhandled type? > Additionally, our IDirectInputEffect implementations could check for > NULL lpvTypeSpecificParams and fail appropriately instead of crashing, > if this is what Windows does. Well, I checked the SetParameters() function, and it does correctly check on NULL lpvTypeSpecificParams and fail appropriately. The problem seems again to be related with joy.cpl/main.c: there is no check performed on the result of IDirectInputDevice2_CreateEffect(), so change joy.cpl/main.c:784 : hr = IDirectInputDevice2_CreateEffect( joystick->device, &pdei->guid, &dieffect, &joystick->effects[joystick->cur_effect].effect, NULL); joystick->effects[joystick->cur_effect].params = dieffect; joystick->effects[joystick->cur_effect].info = *pdei; joystick->cur_effect += 1; return DIENUM_CONTINUE; to : hr = IDirectInputDevice2_CreateEffect( joystick->device, &pdei->guid, &dieffect, &joystick->effects[joystick->cur_effect].effect, NULL); if (FAILED(hr)) return DIENUM_CONTINUE; joystick->effects[joystick->cur_effect].params = dieffect; joystick->effects[joystick->cur_effect].info = *pdei; joystick->cur_effect += 1; return DIENUM_CONTINUE; Before I knew the joy.cpl app was to be blamed, and was searching in the IDirectInputEffect implementions, I saw something that is not conform MSDN: JoystickAImpl_EnumEffects and JoystickWImpl_EnumEffects should check on DIENUM_CONTINUE to continue the enumeration, or DIENUM_STOP to stop it: http://msdn.microsoft.com/en-us/library/windows/desktop/microsoft.directx_s… For example, in JoystickWImpl_EnumEffects(), each occurrence of "(*lpCallback)(&dei, pvRef);" should check whether the return value is DIENUM_CONTINUE or DIENUM_STOP. When the latter is the case, should we then first add a "goto" statement to jump to the last "if (xfd == -1) IDirectInputDevice8_Unacquire(iface);" statement, or directly return? And what should it return in that case, "DIERR_NOTINITIALIZED" (does stopping enumeration mean failure? that's not clear in MSDN), or "DI_OK"? And even worse, what if the return value of "(*lpCallback)(&dei, pvRef);" is not equal to DIENUM_CONTINUE or DIENUM_STOP? Should JoystickWImpl_EnumEffects() interpret it as the former or as the latter? (also not mentioned in MSDN) > >> b) Weirdly, I had to add these commands that evaluates the DIEFFECT >> pointers at the end of each if-case, >> otherwise the pointers seemed to point to other address or data on >> that address was getting overwritten: >> TRACE("&rforce=0x%x\n", &rforce); >> TRACE("&cforce=0x%x\n", &cforce); >> TRACE("&pforce=0x%x\n", &pforce); >> TRACE("&cxyforce[0]=0x%x; &cxyforce[1]=0x%x\n", >> &(cxyforce[0]), &(cxyforce[1])); >> > > This is an out of scope problem. pforce, rforce, etc are local to the > body of the if-blocks and fall out of scope when the if-blocks close. > They should be moved to the top of the function. Ah, interesting, thanks! I'll move their declarations to the top of the function in the corresponding patch that I will send. To clarify for other people: Change joy.cpl/main.c:741 : dieffect.cAxes = 2; dieffect.rgdwAxes = axes; dieffect.rglDirection = direction; if (IsEqualGUID(&pdei->guid, &GUID_RampForce)) to : dieffect.cAxes = 2; dieffect.rgdwAxes = axes; dieffect.rglDirection = direction; DIRAMPFORCE rforce; DICONSTANTFORCE cforce; DIPERIODIC pforce; DICONDITION cxyforce[2]; if (IsEqualGUID(&pdei->guid, &GUID_RampForce)) > > By the way, when you begin to send patches to wine-patches, please > only send up to 2-4 at a time, in logical groups. That way they can be > reasonably reviewed & resubmitted as necessary. OK, no problem ;) Elias

March 7, 2014

Re: oleaut32: Resolve TypeLib dependencies with GUID

by guillaume.charifi＠sfr.fr

Hello, I have no certainty, and not even a test, but the Windows version of Skype (which you know is released by Microsoft) tries to load a TypeLib named "uc.tlb", which cannot be find in path, and even in the registry. In fact, this library is into Skype.exe resources section, but it can only be found using its GUID (only the GUID is present in the library, not the name "uc.tlb". In fact it is a unnamed library). So there seems that two possibilities remains : - All the Typelibs of the executable are probed at launch (I don't think so, but...) - The Windows' oleaut32.dll scans the TypeLibs embedded into the executable and tries to match them not only by their name, but by their GUID to. Thanks for your reading, Guillaume ======================================== Message du : 07/03/2014 16:18 De : "Jacek Caban " <jacek(a)codeweavers.com> A : wine-devel(a)winehq.org, guillaume.charifi(a)sfr.fr Copie à : Sujet : Re: oleaut32: Resolve TypeLib dependencies with GUID On 03/07/14 15:53, guillaume.charifi(a)sfr.fr wrote: > Bug: http://bugs.winehq.org/show_bug.cgi?id=34184 Please send a test convincing that that's what Windows does. We already have a typelib in oleaur32 tests, so this should be a matter of loading it by GUID without having it registered. Thanks, Jacek

March 7, 2014

Re: oleaut32: Resolve TypeLib dependencies with GUID

by Jacek Caban

On 03/07/14 15:53, guillaume.charifi(a)sfr.fr wrote: > Bug: http://bugs.winehq.org/show_bug.cgi?id=34184 Please send a test convincing that that's what Windows does. We already have a typelib in oleaur32 tests, so this should be a matter of loading it by GUID without having it registered. Thanks, Jacek

March 7, 2014

Re: [PATCH 2/2] vbscript: Directly access 'this' object properties in interpreter.

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://newtestbot.winehq.org/JobDetails.pl?Key=5490 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvista (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7pro64 (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found === w7pro64 (64 bit) === No test summary line found

March 7, 2014

Re: [PATCH 1/2] vbscipt: Added beginning support for arrays as class members.

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://newtestbot.winehq.org/JobDetails.pl?Key=5489 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvista (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7pro64 (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found === w7pro64 (64 bit) === No test summary line found

March 7, 2014

Re: ws2_32/tests: Mark some test results on Windows 8 as broken.

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://newtestbot.winehq.org/JobDetails.pl?Key=5487 Your paranoid android. === wvistau64 (32 bit sock) === sock: unhandled exception c0000005 at 00000000 === w2008s64 (32 bit sock) === sock: unhandled exception c0000005 at 00000000 === wvistau64 (64 bit sock) === sock: unhandled exception c0000005 at 0000000000000000

March 7, 2014