May 2012 - Wine-Devel - list.winehq.org

Re: [1/3] user32/tests: Comment-out PostQuitMessage (causes tests skip)

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 http://testbot.winehq.org/JobDetails.pl?Key=18630 Your paranoid android. === W7PROX64 (32 bit dialog) === dialog.c:1373: Test failed: Dialog should not be visible. === TEST64_W7SP1 (32 bit dialog) === dialog.c:1373: Test failed: Dialog should not be visible. === W7PROX64 (64 bit dialog) === dialog.c:1373: Test failed: Dialog should not be visible. === TEST64_W7SP1 (64 bit dialog) === dialog.c:1373: Test failed: Dialog should not be visible.

May 28, 2012

Re: d3dx9_36/tests: Add tests for D3DXCreatePolygon

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 http://testbot.winehq.org/JobDetails.pl?Key=18615 Your paranoid android. === WINEBUILD (build) === Make failed

May 27, 2012

Re: func or pFunc in tests ?

by GOUJON Alexandre

On 05/27/2012 05:08 PM, Juan Lang wrote: > <snip> > Basically, if the function is available on all versions of Windows > that the test bot runs on, use func. If it's not available on some > versions, and you need to test whether it's available to avoid a > non-running test, use pFunc instead. > > Regarding the history, a lot of the usage of pFunc in the tests is for > Windows 95/98/ME, which we no longer test on, so their continued use > is "legacy." That's not true in all cases, e.g. often a function > wasn't available in Windows NT 4.0 either. So my plan is to submit my test to the WineTestBot and see if some Windows version complain. FYI, I've read [1] from [2] and the content seems to be a bit outdated / not complete. Documenting is not funniest part but would also help GSoC people. Anyway, thanks for the explanation and the historical part, it makes sense now. --- [1] : http://www.winehq.org/docs/winedev-guide/testing [2] : http://wiki.winehq.org/ConformanceTests

May 27, 2012

Re: func or pFunc in tests ?

by Juan Lang

Hi Alexandre, On Sun, May 27, 2012 at 6:22 AM, GOUJON Alexandre <ale.goujon(a)gmail.com> wrote: > Some tests call directly the function by its name (i.e. GetWindowsDirectory, > CreateFileA, CloseHandle...) while others declare a pointer to the function > (prefixing its name by 'p' and followed by a capital letter) retrieved via > GetProcAddress. > > I know that tests have been written by lots of different people at different > times and the general rule is "follow the style of the test file to be > consistent" but here, both styles exist in the same file > (kernel32/tests/volume.c). > > Is there any rule concerning using func over pFunc ? > Is it related to the module it comes from ? Basically, if the function is available on all versions of Windows that the test bot runs on, use func. If it's not available on some versions, and you need to test whether it's available to avoid a non-running test, use pFunc instead. Regarding the history, a lot of the usage of pFunc in the tests is for Windows 95/98/ME, which we no longer test on, so their continued use is "legacy." That's not true in all cases, e.g. often a function wasn't available in Windows NT 4.0 either. --Juan

May 27, 2012

func or pFunc in tests ?

by GOUJON Alexandre

Hi, I'm planning to add a test in the wine test suite and I noticed a difference. Some tests call directly the function by its name (i.e. GetWindowsDirectory, CreateFileA, CloseHandle...) while others declare a pointer to the function (prefixing its name by 'p' and followed by a capital letter) retrieved via GetProcAddress. I know that tests have been written by lots of different people at different times and the general rule is "follow the style of the test file to be consistent" but here, both styles exist in the same file (kernel32/tests/volume.c). Is there any rule concerning using func over pFunc ? Is it related to the module it comes from ? Thanks

May 27, 2012

[website] Logo license? Usable in a propritary App?

by André Hentschel

Hey, they use the "old" WineHQ Logo in this 99 Cent App: https://play.google.com/store/apps/details?id=com.appdevandroid.framework.w… Is that ok? If not, could the creater please contact them. The Icon could be misleading. -- Best Regards, André Hentschel

May 25, 2012

Fwd: [Freerdp-devel] WinPR: Windows Portable Runtime

by Pau Garcia i Quiles

FYI ---------- Forwarded message ---------- From: Marc-André Moreau <marcandre.moreau(a)gmail.com> Date: Fri, May 25, 2012 at 3:04 AM Subject: [Freerdp-devel] WinPR: Windows Portable Runtime To: freerdp-devel <freerdp-devel(a)lists.sourceforge.net> Dear FreeRDP community, I have an announcement to make regarding a new spin-off project which I've been preparing for a while. Please read as this will set the tone of future development :) You can find most current WinPR development work on the winpr branch: https://github.com/FreeRDP/FreeRDP/tree/winpr WinPR is a spin-off project of FreeRDP which aims at providing a portable implementation of important portions of the Windows API. Just like FreeRDP, WinPR is released under the Apache license. Unlike Wine, WinPR does not provide binary compatibility, and does not require applications to be built for Windows. Instead, WinPR provides API compatibility for applications targeting non-Windows environments. When on Windows, the original native API is being used instead of the equivalent WinPR implementation, without having to modify the code using it. WinPR is the result of long and thoughtful process that came up after years of FreeRDP development. RDP, as you know, is a protocol designed by Microsoft and is primarily “Windows to Windows”. In many instances, protocol messages rely heavily on Windows-specific APIs which have no direct equivalent on other operating systems. For instance, core graphical messages are based on GDI, network level authentication makes use of the Microsoft SSPI authentication modules (CredSSP, NTLM), and terminal server gateway makes use of both SSPI and MSRPC. That’s not even mentioning all the effort that went into mapping keyboard systems and time zones. Developing FreeRDP is in many ways all about implementing Windows APIs outside of Windows. Immense efforts have gone into the implementation of such features, to the point where they begin having value outside of FreeRDP itself. At this point, one of the most valuable part of WinPR is the set of SSPI modules. Various NTLM implementations exist, all with different interfaces, but the WinPR implementation is a direct replacement of the original. This is an advantage because the API is already well documented, with expected inputs and outputs. FreeRDP can also optionally build against the native SSPI modules when on Windows. Making this code easily reusable to any one means that application developers now have an easy way of porting their applications to make use of the Windows authentication architecture. WinPR is also a response to a recurrent problem in FreeRDP development: the proliferation of custom helpers and utility functions. While those are useful, they often need to be modified and updated to meet new requirements, causing frequent API changes. Breaking the API regularly obviously makes a lot of developers unhappy. By choosing to implement an existing and mature API, we can effectively get rid of the core of the problem. If a certain API has been used for years and it fits the needs of most people, you are less likely to need to break it yourself. Besides the argument of API stability, there is another huge advantage in using the Windows API over custom utility functions: the ability to easily share code with other projects that aim at implementing the same API. For instance, the SSPI modules currently developed in WinPR are of high interest to the ReactOS project. If the code was filled with custom utility functions, it would be much harder to use outside of FreeRDP, hindering such collaboration opportunities. For instance, instead of wrapping calls to MultiByteToWideChar() in a custom unicode conversion utility, we can use MultiByteToWideChar() as the utility function and provide an implementation on non-Windows systems. As a general rule in WinPR, if a utility function can be replaced by a part of the Windows API, then the Windows API will have precedence. Otherwise, a utility method can be used, keeping in mind the downsides of it. WinPR is also designed to be as modular as possible, using the MinWin architecture as a reference. MinWin is a refactoring effort of the Windows API which is more cleaner and comprehensive than the original. The API has been separated into logical sets, each with a DLL. Not a lot of documentation is available online about MinWin, but one can find its structure in the MSDN article “Windows API Sets”: http://msdn.microsoft.com/en-us/library/hh802935/ Just like MinWin, WinPR aims at being minimalistic and modular, such that one can have fine grained control over what is to be used. For projects making use of only a small amounts of WinPR, it should be possible to depend only on the minimum required. At last, why not simply use Wine or code from other projects like ReactOS or Samba? In all of these cases, there are both licensing and architectural problems which make it fairly hard for us to use in FreeRDP. For instance, Wine provides binary compatibility, and it’s not easy for a native Linux application to make use of parts of it without being built for Windows. Samba has an interesting MSRPC implementation, but it’s a fairly big dependency, without counting the fact that we can forget about portability on mobile platforms like Android and iOS. Unfortunately, none of these provide a highly portable implementation of the Windows API in the way we would like and under a license which is suitable to us, justifying the existence of WinPR. Through WinPR, investment done in FreeRDP development will take a new life and become even more valuable. We will open new doors to even higher levels of interoperability. We will foster collaboration with other projects following similar goals and reach new heights at an increasingly faster pace. Stay tuned, you will be amazed! ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Freerdp-devel mailing list Freerdp-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freerdp-devel -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)

May 25, 2012

Re: [5/5] propsys: Implement IPropertyStore::GetCount.

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

May 24, 2012

Re: [4/5] propsys: Implement IPropertyStore::SetValue and GetValue.

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

May 24, 2012

Re: gdiplus: Reimplement GdipIsEmptyRegion.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > Status is still "New". I guess a test could help, but I would be very > surprised if native can't detect things like empty paths. I don't see how that's related. -- Dmitry.

May 24, 2012