April 2012 - Wine-devel - list.winehq.org

Re: [PATCH 1/4] amstream: rename mediastream to ddrawmediastream. (resend)
by Alexandre Julliard 23 Apr '12

23 Apr '12

Christian Costa <titan.costa(a)gmail.com> writes: > --- > dlls/amstream/Makefile.in | 2 > dlls/amstream/amstream.c | 6 + > dlls/amstream/amstream_private.h | 2 > dlls/amstream/ddrawmediastream.c | 256 ++++++++++++++++++++++++++++++++++++++ > dlls/amstream/mediastream.c | 251 ------------------------------------- > 5 files changed, 263 insertions(+), 254 deletions(-) > create mode 100644 dlls/amstream/ddrawmediastream.c > delete mode 100644 dlls/amstream/mediastream.c There's no reason to rename the file. Just put everything in there. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: iphlpapi: Move get_pid_map() and find_owning_pid() under #ifdef #ifdef __linux__.
by Alexandre Julliard 23 Apr '12

23 Apr '12

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > ...like their sole user. > > Otherwise this warns on everything which is not __linux__. ;-) That's a feature. It needs to be implemented on other platforms. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/3] dmusic: Pass creation parameters to DMUSIC_CreateDirectMusicBufferImpl then allocate data buffer and set format accordingly.
by Alexandre Julliard 23 Apr '12

23 Apr '12

Christian Costa <titan.costa(a)gmail.com> writes: > +HRESULT WINAPI DMUSIC_CreateDirectMusicBufferImpl(LPDMUS_BUFFERDESC desc, LPVOID* ret_iface) > +{ > + IDirectMusicBufferImpl* dmbuffer; > + > + TRACE("(%p, %p)\n", desc, ret_iface); > + > + dmbuffer = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(IDirectMusicBufferImpl)); > + if (!dmbuffer) { > + *ret_iface = NULL; > + return E_OUTOFMEMORY; > + } > + > + dmbuffer->lpVtbl = &DirectMusicBuffer_Vtbl; > + dmbuffer->ref = 0; /* Will be inited by QueryInterface */ > + > + memcpy(&dmbuffer->format, &desc->guidBufferFormat, sizeof(GUID)); > + dmbuffer->size = (desc->cbBuffer + 3) & ~3; /* Buffer size must be multiple of 4 bytes */ > + > + dmbuffer->data = HeapAlloc(GetProcessHeap(), 0, sizeof(dmbuffer->size)); > + if (!dmbuffer->data) { > + HeapFree(GetProcessHeap(), 0, dmbuffer); > + *ret_iface = NULL; > + return E_OUTOFMEMORY; > + } > + > + return IDirectMusicBufferImpl_QueryInterface((LPDIRECTMUSICBUFFER)dmbuffer, &IID_IDirectMusicBuffer, ret_iface); While you are changing the function please also make it handle errors properly. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/3] dmsynth: Check the rigth CLSID to create the DirectMusicSynthSink object. (resend)
by Marvin 21 Apr '12

21 Apr '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=17990 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

winedbg and program stdout
by Ilya Basin 21 Apr '12

21 Apr '12

When I debug a program with winedbg, it's output never goes to the same terminal. If it's compiled with -mconsole, it goes to a new console window; if compiled with -mwindows, the output is discarded. Any way to change this behavior?

2 1

Re: d3dx9_36: Add adjacency for D3DXCreateCylinder
by Rico Schüller 20 Apr '12

20 Apr '12

Am 20.04.2012 16:20, schrieb David Adam: > > + if (adjacency) > > I'm not sure that this is correct, but why is adjacency not touched? What should be returned for adjacency, maybe a test will show it? I guess the temp ID3DXBuffer should be returned instead of leaked when all is successful... Cheers Rico

1 0

Re: jscript: Added regexp 'pre-parser' to support non-backslash-sequenced non-terminating '/' in characted classes
by Marvin 20 Apr '12

20 Apr '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=17979 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Are we missing the small folder_open icons?
by Francois Gouget 20 Apr '12

20 Apr '12

In dlls/shell32/shell32.rc I see the following fixme: /* FIXME: Following three resources are not yet added */ /* @makedep: folder_open.ico */ IDI_SHELL_FOLDER_OPEN_SMALL ICON folder_open.ico /* @makedep: folder_open.ico */ IDI_SHELL_FOLDER_OPEN_LARGE ICON folder_open.ico /* @makedep: folder_open.ico */ IDI_SHELL_FOLDER_SMALL_XP ICON folder_open.ico However folder_open.ico is generated from an SVG file and we seem to be having it in multiple sizes. Also this fixme has been there forever. So is there really still something to be fixed? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U

2 1

Updating GSoC proposal
by Jacek Caban 19 Apr '12

19 Apr '12

Hi all, GSoC is starting this year and, if we want to have good applications, we need to update our proposals. Usually the most attention is directed into adding new ones, while we keep obviously bad (or just bad IMO) proposals on the page. I'm planning to remove following project proposals: Security - implement sandboxing Theming - Implement Wine theming support NTDLL - support performance registry keys Winelib Aware Scons (or cmake) Cleanup Winemenubuilder to support generating Application Bundles on Mac OS X Wine-based application virtualization If someone knows a reason to not remove them, please reply. Cheers, Jacek

2 1

Re: d3dx9/tests: Add DDS pixel format tests for D3DXGetImageInfoFromFileInMemory.
by Matteo Bruni 19 Apr '12

19 Apr '12

Il 19 aprile 2012 19:37, Józef Kucia <joseph.kucia(a)gmail.com> ha scritto: > --- > dlls/d3dx9_36/tests/surface.c | 65 +++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 65 insertions(+), 0 deletions(-) > > diff --git a/dlls/d3dx9_36/tests/surface.c b/dlls/d3dx9_36/tests/surface.c > index 87aa03e..51d6ebd 100644 > --- a/dlls/d3dx9_36/tests/surface.c > +++ b/dlls/d3dx9_36/tests/surface.c > @@ -22,6 +22,8 @@ > #include "wine/test.h" > #include "d3dx9tex.h" > #include "resources.h" > +#undef MAKE_DDHRESULT > +#include "ddraw.h" > I'm not sure that's a good idea. ddraw.h is not included in recent DirectX SDKs and the relevant definitions are "gone", as far as I know. So I think d3dx9 or its tests should not depend on that header. I'd just (re)declare the stuff you need privately in the test source file instead. You don't even need to use the same types/defines/variables names as those from ddraw.h, you just have to keep them compatible. On that point, I see that MSDN mentions the equivalent DDS_HEADER and DDS_PIXELFORMAT structures (http://msdn.microsoft.com/en-us/library/windows/desktop/bb943991%28v=vs.85%…) except those don't seem to be defined in the MS headers either. I guess you are free to use whatever names you like...

3 3