Re: Request for review: [PATCH] Resize fullscreen window when DirectDraw changes the display mode [resubmit 4]

On Wed, Aug 12, 2009 at 3:05 AM, Stefan Dösinger stefandoesin...@gmx.atwrote: Am Tuesday 11 August 2009 23:43:33 schrieb Johan Gill: There is IWineD3DDeviceImpl_SetupFullscreenWindow, but that one is not exported so it can't be called from ddraw as it is. Calling it from within

Re: Winamp disappears when you move it's location

Peter Dons Tychsen donpe...@tdcadsl.dk writes: So... i have investigated other ways of fixing this. Would you accept a patch that uses _NET_WM_MOVERESIZ to move the window? That might also fix the issue. That message requests the WM to move the window at not X. I have now tested with

Re: tools/winebuild: add FreeBSD support (1/2) (RESEND) (fwd)

On Tue, 6 Oct 2009, Alexandre Julliard wrote: If you prefer, I'll be happy to convert the code into a switch statement. Just let me know! That would certainly be more elegant. Your wish is my command. :-) Gerald ChangeLog: Add support for PLATFORM_FREEBSD to get_ld_command. diff --git

Re: Winamp disappears when you move it's location

So... i have investigated other ways of fixing this. Would you accept a patch that uses _NET_WM_MOVERESIZ to move the window? That might also fix the issue. That message requests the WM to move the window at not X. I have now tested with _NET_WM_MOVERESIZ _NET_MOVERESIZE_WINDOW No cigar. They

Re: comctl32/monthcal: Make MONTHCAL_Get{Prev,Next}Month() static.

Francois Gouget wrote: --- Changed the inline placement as 'static inline' in one chunk seems more standard. dlls/comctl32/monthcal.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) I've changed this to static here:

Re: comctl32: Move inline to the beginning of the declaration.

Alexandre, please apply Francois version of this patch. bye michael Michael Stefaniuc wrote: Signed-off-by: Michael Stefaniuc mstef...@redhat.de --- dlls/comctl32/monthcal.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/dlls/comctl32/monthcal.c

Re: comctl32: Move inline to the beginning of the declaration.

Michael Stefaniuc wrote: Alexandre, please apply Francois version of this patch. bye michael Hi, guys. This piece of attracted a lot of people as I see). I've just resent an improved try2 version with keyword order fix (static was added in original 4/4 patch), also it fixes some

Re: Winamp disappears when you move it's location

Peter Dons Tychsen donpe...@tdcadsl.dk writes: What you should do first is spend a lot more time studying the code, before deciding that it has major problems and needs major changes. It's a very sensitive area where the smallest change has big consequences, and you have to be sure to know

Re: [3/5] ddraw: Implement and test DirectDrawEnumerateW.

Am 08.10.2009 um 09:46 schrieb Andrew Nguyen: --- dlls/ddraw/ddraw.spec|2 +- dlls/ddraw/main.c| 17 + dlls/ddraw/tests/ddrawenum.c | 37 + 3 files changed, 51 insertions(+), 5 deletions(-)

Re: [3/5] ddraw: Implement and test DirectDrawEnumerateW.

2009/10/8 Stefan Dösinger stefandoesin...@gmx.at: The patch looks ok to me(as do the others). I am just curious, how did you run into this function if its unimplemented on Windows? Just curiosity because it exists, or do you have an app that actually calls it? See

Re: [2/5] ddraw: Simplify and test DirectDrawEnumerateA.

Andrew Nguyen arethus...@gmail.com writes: The tests for the following series of patches succeed on Windows XP and Windows 7. The crash code is borrowed from the timer callback crash test in commit f20f411925e789a2aecf740776f441335837ac5f. --- dlls/ddraw/main.c|6 +-

BSTR caching

Hi, the last week I took some time to implement the first try of BSTR caching in oleaut.c. On the one hand this will fix a bug, on the other hand Wine could save some CPU cycles and can catch up with the speed of the native implementation. Attached you will find the result of my considerations.

Re: BSTR caching

2009/10/8 Markus Stockhausen markus.stockhau...@collogia.de: Hi, the last week I took some time to implement the first try of BSTR caching in oleaut.c. On the one hand this will fix a bug, on the other hand Wine could save some CPU cycles and can catch up with the speed of the native

Re: BSTR caching

Markus Stockhausen wrote: Hi, the last week I took some time to implement the first try of BSTR caching in oleaut.c. On the one hand this will fix a bug, on the other hand Wine could save some CPU cycles and can catch up with the speed of the native implementation. + * Windows standard

Re: BSTR caching

I'm not sure about the exact details of what this should fix, but wouldn't using a private heap have mostly the same effect? Hi Henri, it will definitely fix bug 12460 (self tested) and maybe 3756 as it implements deferred release of BSTR memory. It does not matter if we are using private heap

Re: BSTR caching

Am Donnerstag, den 08.10.2009, 18:26 +0400 schrieb Nikolay Sivov: Markus Stockhausen wrote: Hi, the last week I took some time to implement the first try of BSTR caching in oleaut.c. On the one hand this will fix a bug, on the other hand Wine could save some CPU cycles and can catch up

Re: rpcrt4: A signed 1-bit bitfield doesn't make much sense; use unsigned.

On 10/08/2009 11:22 AM, Francois Gouget wrote: --- While signed 1-bit bitfields don't make much sense, that's how they are defined in the PSDK. So maybe we want to stick with the signed definition anyway. If not then we can apply this patch. As far as I can tell this is the only place left

Re: BSTR caching

Markus Stockhausen markus.stockhau...@collogia.de writes: only the result of solving bug 12460, debugging a few testcases that produce IMalloc log entries and in this way indirectly reflect the behaviour of native oleaut (at least XP version). You should not be looking at the internal

Re: BSTR caching

You should not be looking at the internal behavior of native, only at the external behavior as observed through test cases. Hm, I know, that testcase - windows oleaut - wine ifs.c IMalloc logging is quite strange testing. Sadly this was the only way to explore the reason for not

Re: [ntdll] Move file attribute logic to new function DIR_get_attributes()

Hi Dan, You get a +1 from me on this one. Small note: +if (io-Information == FILE_CREATED) { +/* FIXME: is this an extra server round trip? */ (snip) +status = server_get_unix_fd( *handle, FILE_WRITE_DATA, fd, needs_close, NULL, NULL ); It is, but for most file

Re: Winamp disappears when you move it's location

What you should do first is spend a lot more time studying the code, before deciding that it has major problems and needs major changes. It's a very sensitive area where the smallest change has big consequences, and you have to be sure to know what you are doing. I already spent time on this

Re: comctl32: initial theming tests (try 4)

Owen Rudge schrieb: Ah, I see, no, it won't link I think without static. Some time ago I thought about adding v6util.c back and move code here, I'm not very familiar with makefile generation but I think we could place this new v6util.c into C_SRCS section of test makefile (if it's allowed of

Re: [try 4] Add help message box to dxdiag implementation

Brian Nguyen wrote: This patch adds a simple help message box to dxdiag; this change is intentionally small in order to start implementing features of dxdiag incrementally. How does it look? -- Brian Nguyen mtxc...@gmail.com mailto:mtxc...@gmail.com --- /dev/null +++ b/programs/dxdiag/En.rc

[try 4] Add help message box to dxdiag implementation

Looks fine to me. FWIW, I'd suggest continuing on with a second patch that adds one more feature, and post the two-patch series. Also, you're welcome to send it to Austin and me first for pre-review. [I 'spose you should have mentioned it's identical to the previous try.]