wine-devel May 2012

wine-devel@winehq.org

67 participants
174 discussions

Re: [2/5] d3dx9: Implement D3DXSaveSurfaceToFileInMemory.
by Vincent Povirk 28 May '12

28 May '12

> - hr = IWICImagingFactory_CreateStream(factory, &stream); > + hr = IWICImagingFactory_CreateStream(factory, &wic_stream); > IWICImagingFactory_Release(factory); > if (FAILED(hr)) goto cleanup_err; > > - hr = IWICStream_InitializeFromFilename(stream, dst_filename, GENERIC_WRITE); > + hr = CreateStreamOnHGlobal(NULL, TRUE, &stream); > if (FAILED(hr)) goto cleanup_err; > > + hr = IWICStream_InitializeFromIStream(wic_stream, stream); Why bother creating an IWICStream here? Just use your HGLOBAL stream to initialize the encoder.

1 0

Re: [1/5] windowscodecs: Implement IWICStream::InitializeFromIStream.
by Vincent Povirk 28 May '12

28 May '12

> +static HRESULT WINAPI StreamOnStream_Seek(IStream *iface, > + LARGE_INTEGER dlibMove, DWORD dwOrigin, ULARGE_INTEGER *plibNewPosition) > +{ > + StreamOnStream *This = StreamOnStream_from_IStream(iface); > + HRESULT hr=S_OK; > + TRACE("(%p)\n", This); > + > + EnterCriticalSection(&This->lock); > + hr = IStream_Seek(This->stream, dlibMove, dwOrigin, plibNewPosition); > + LeaveCriticalSection(&This->lock); > + > + return hr; > +} The IWICStream needs to have an independent position from the underlying stream. Also, why not just forward to InitializeFromIStreamRegion?

1 0

Re: [1/3] user32/tests: Comment-out PostQuitMessage (causes tests skip)
by Marvin 28 May '12

28 May '12

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.

1 0

Re: d3dx9_36/tests: Add tests for D3DXCreatePolygon
by Marvin 27 May '12

27 May '12

1 0

func or pFunc in tests ?
by GOUJON Alexandre 27 May '12

27 May '12

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

2 2

[website] Logo license? Usable in a propritary App?
by André Hentschel 25 May '12

25 May '12

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

1 0

Fwd: [Freerdp-devel] WinPR: Windows Portable Runtime
by Pau Garcia i Quiles 25 May '12

25 May '12

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)

1 0

Re: [5/5] propsys: Implement IPropertyStore::GetCount.
by Marvin 24 May '12

24 May '12

1 0

Re: [4/5] propsys: Implement IPropertyStore::SetValue and GetValue.
by Marvin 24 May '12

24 May '12

1 0

Re: gdiplus: Reimplement GdipIsEmptyRegion.
by Dmitry Timoshkov 24 May '12

24 May '12

Hello, I'm surprised that such a trivial patch wasn't accepted yet. But just in case it matters, current implementation doesn't work for paths and combined/complex regions. -- Dmitry.

2 2

← Newer
1
2
3
4
5
6
7
...
18
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel May 2012