wine-devel April 2013

wine-devel@winehq.org

80 participants
178 discussions

Re: includes: avoid confusing the preproccesor
by Alexandre Julliard 01 Apr '13

01 Apr '13

Austin English <austinenglish(a)gmail.com> writes: > See http://savannah.nongnu.org/bugs/?38557 > > ==== > > In fact, after some investigation, I found out that it's the correct > behavior as '0xfe+1' is considered as a number token by the > preprocessor. I've learned something today :) This has nothing to do with the preprocessor. It's a compiler bug. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: winehtml5.drv: Added new HTML5 driver.
by Ken Thomases 01 Apr '13

01 Apr '13

On Apr 1, 2013, at 6:41 AM, Jacek Caban wrote: > There are still some missing features. Most notably, it lacks support > for system tray baloons. I know; that's, like, the hardest thing to do! Great work, though! Actually, since HTML is available everywhere, there's little reason for me to continue with the Mac driver. -Ken

4 3

Re: [PATCH 3/4] d3d9/tests: Verify window style after exiting fullscreen mode. (try 2)
by Henri Verbeet 01 Apr '13

01 Apr '13

On 1 April 2013 02:40, Sam Edwards <cfsworks(a)gmail.com> wrote: > I opted not to write ddraw tests. The existing ddraw window style tests > suggest that DirectDraw doesn't even set WS_VISIBLE when initializing a > (non-visible) window, which is very odd, so any new tests would have been > todo_wine anyway. Nonetheless, my changes to wined3d are minimal and > shouldn't affect ddraw's behavior. > I think it's ok for the tests to be todo_wine, but we do want ddraw coverage for this in the tests. > + ZeroMemory( &d3dpp, sizeof(d3dpp) ); > + d3dpp.SwapEffect = D3DSWAPEFFECT_DISCARD; > + d3dpp.Windowed = TRUE; > + d3dpp.BackBufferWidth = screen_width / 2; > + d3dpp.BackBufferHeight = screen_height / 2; > + hr = IDirect3DDevice9_Reset(device, &d3dpp); > + ok(hr == D3D_OK, "IDirect3DDevice9_Reset failed with %08x\n", hr); I think you'll want to use reset_device() here. (Although I also just notice 766e732fb changed that to use screen_width x screen_height instead of 640x480, which is perhaps a bit of an unfortunate choice. It's fine to change reset_device() to use screen_width / 2 x screen_height / 2, if needed.)

2 2

Re: [1/4] windowscodecs: Basic tests for tiff encoder options (try3)
by Ludger Sprenker 01 Apr '13

01 Apr '13

Is there anything wrong with my patches? The first one is marked as "Pending". Am Dienstag, 26. März 2013, 18:46:23 schrieb Ludger Sprenker: > Try3: > - Removed last named value initialization > - Do not check initial value of properties, if the > precondition/initial-type is not matching > (both pointed out by Vincent) > > Note: This was priviously a set of 5 patches, but the original part one has > already been committed. > > --- > dlls/windowscodecs/tests/converter.c | 145 > ++++++++++++++++++++++++++++++++++ > 1 file changed, 145 insertions(+)

2 1

Re: dpnet: Increase reported buffer size
by Marvin 01 Apr '13

01 Apr '13

1 0

Problem about declarations of strcoll functions
by Jactry Zeng 01 Apr '13

01 Apr '13

Hi folks, I tried to implement a lot of strcoll function these days, and I meet some trouble when I added the declaration into include/msvcrt/*.h. With "grep coll *.spec" in dlls/msvcrt/ we can find there was a lot of strcoll function. Some of them was implemented and some of them not: @ cdecl ___lc_collate_cp_func() @ stub __lc_collate @ extern __lc_collate_cp MSVCRT___lc_collate_cp @ cdecl _mbscoll(str str) @ cdecl _mbscoll_l(str str ptr) @ cdecl _mbsicoll(str str) @ cdecl _mbsicoll_l(str str ptr) @ cdecl _mbsnbcoll(str str long) @ cdecl _mbsnbcoll_l(str str long ptr) @ cdecl _mbsnbicoll(str str long) @ cdecl _mbsnbicoll_l(str str long ptr) @ stub _mbsncoll(str str long) # stub _mbsncoll_l(str str long ptr) @ stub _mbsnicoll(str str long) # stub _mbsnicoll_l(str str long ptr) @ cdecl _strcoll_l(str str ptr) MSVCRT_strcoll_l @ cdecl _stricoll(str str) MSVCRT__stricoll @ cdecl _stricoll_l(str str ptr) MSVCRT__stricoll_l @ cdecl _strncoll(str str long) MSVCRT_strncoll_l @ cdecl _strncoll_l(str str long ptr) MSVCRT_strncoll @ cdecl _strnicoll(str str long) MSVCRT__strnicoll @ cdecl _strnicoll_l(str str long ptr) MSVCRT__strnicoll_l # stub _wcscoll_l(wstr wstr ptr) @ cdecl _wcsicoll(wstr wstr) MSVCRT__wcsicoll # stub _wcsicoll_l(wstr wstr ptr) @ cdecl _wcsncoll(wstr wstr long) MSVCRT__wcsncoll @ cdecl _wcsncoll_l(wstr wstr long ptr) MSVCRT__wcsncoll_l @ cdecl _wcsnicoll(wstr wstr long) MSVCRT__wcsnicoll # stub _wcsnicoll_l(wstr wstr long ptr) @ cdecl strcoll(str str) MSVCRT_strcoll @ cdecl wcscoll(wstr wstr) MSVCRT_wcscoll With "grep coll *.h" in include/msvcrt/ we can find some declarations of some strcoll function: crtdefs.h: unsigned int lc_collate_cp; mbstring.h:int __cdecl _mbscoll(const unsigned char*,const unsigned char*); mbstring.h:int __cdecl _mbsicoll(const unsigned char*,const unsigned char*); mbstring.h:int __cdecl _mbsnbcoll(const unsigned char*,const unsigned char*,size_t); mbstring.h:int __cdecl _mbsnbicoll(const unsigned char*,const unsigned char*,size_t); mbstring.h:int __cdecl _mbsncoll(const unsigned char*,const unsigned char*,size_t); mbstring.h:int __cdecl _mbsnicoll(const unsigned char*,const unsigned char*,size_t); string.h:int __cdecl _stricoll(const char*,const char*); string.h:int __cdecl strcoll(const char*,const char*); string.h:int __cdecl _wcsicoll(const wchar_t*,const wchar_t*); string.h:int __cdecl _wcsnicoll(const wchar_t*,const wchar_t*,size_t); string.h:int __cdecl wcscoll(const wchar_t*,const wchar_t*); string.h:static inline int stricoll(const char* s1, const char* s2) { return _stricoll(s1, s2); } string.h:static inline int wcsicoll(const wchar_t* str1, const wchar_t* str2) { return _wcsicoll(str1, str2); } wchar.h:int __cdecl _wcsicoll(const wchar_t*,const wchar_t*); wchar.h:int __cdecl _wcsnicoll(const wchar_t*,const wchar_t*,size_t); wchar.h:int __cdecl wcscoll(const wchar_t*,const wchar_t*); As we can see, _strcoll_l and _mbsnbcoll_l were implemented but they were not declared. Should we declare all of them? And whether the sequence was important? Thank you. -- Regards, Jactry Zeng

2 2

Re: mshtml: Fixed builtin getter call with arguments.
by Marvin 01 Apr '13

01 Apr '13

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=24910 Your paranoid android. === W2KPROSP4 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === W2K8SE (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

Re: [PATCH] wined3d: Add a registry key to configure buffer object placement
by Henri Verbeet 01 Apr '13

01 Apr '13

On 1 April 2013 10:30, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + if (wined3d_settings.placebo == PLACEBO_VIDMEM) > + { > + TRACE("Placing buffer %p in video memory\n", This); > + glHint(This->buffer_type_hint, GL_FASTEST); > + } > + I'm going to go out on a limb and call April fools on this. The state of GL drivers being what it is though, there's a slight chance such a thing actually exists, in which case please link to the documentation instead. Somewhat related, I do actually have a patch to change the usage hint for static vertex buffers to GL_STATIC_DRAW_ARB in my tree, which should actually make the driver more likely to initially place those in VRAM instead of GTT. (It mostly just helps with initial fps after a VB is just created, most drivers eventually figure out the optimal placement anyway and migrate the buffer to vram.)

1 0

Jump to page:

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 April 2013