wine-devel August 2009

wine-devel@winehq.org

97 participants
276 discussions

Re: [4/7] [try 2] mapi32: Load and store MAPI function pointers after loading MAPI providers
by Henri Verbeet 31 Aug '09

31 Aug '09

2009/8/31 Owen Rudge <orudge(a)codeweavers.com>: > + mapiFunctions.MAPIAddress = (void*) get_mapi_function("MAPIAddress"); That's redundant now. Since you load the pointers all at once, you don't need get_mapi_function() to do the NULL check on the module. You can just enclose the entire block in an if and use GetProcAddress().

1 0

Re: [1/7] [try 2] mapi32: Add stub functions for loading/unloading MAPI providers
by Henri Verbeet 31 Aug '09

31 Aug '09

2009/8/31 Owen Rudge <orudge(a)codeweavers.com>: > +BOOL load_mapi_providers(); > +void unload_mapi_providers(); That doesn't do what you think it does. Also, a return value isn't very useful if you're just going to ignore it.

1 0

Re: msxml3: Add IDispatchEx support to IXMLDOMElement
by Jacek Caban 31 Aug '09

31 Aug '09

Hi Alistair, Alistair Leslie-Hughes wrote: > Hi, > > > Changelog: > msxml3: Add IDispatchEx support to IXMLDOMElement +static const tid_t domelem_iface_tids[] = { + IXMLDOMNode_tid, + IXMLDOMElement_tid, IXMLDOMElement inherits from IXMLDOMNode, so there is not need to add IXMLDOMNode here. Jacek

1 0

d3dx9: Implement converting and copying surface data in D3DXLoadSurfaceFromMemory (review please)
by Tony Wasserka 31 Aug '09

31 Aug '09

Hi everyone, D3DXLoadSurfaceFromMemory is used to load a chunk of pixel data into a surface, performing any pixel format conversion from signed/unsigned ARGB, floating point or FourCC formats to any other format and also performs various types of filtering actions (one of copying, point filtering, linear filtering, triangular filtering and bov filtering and additionally dithering). I've partially implemented this function during my GSoC project, supporting only unsigned ARGB formats (with 1-4 bytes) and copying for now (supporting signed formats and point filtering is trivial to add to this version), but due to the huge functionality of the function it's a hard task to get the code right without either being somewhat slower than the native dll or having thousands of lines of code for each conversion/filtering scenario. My current approach is to implement various specific converters (which actually do converting AND filtering): - converting from and to "small" signed/unsigned ARGB formats - converting "large" ARGB formats to small ones - converting "large" ARGB formats to other large ARGB formats - converting DXT formats to other DXT formats - converting DXT formats to small ARGB formats - .... - additionally, I plan to a function for each filter which filters data when the source and destination formats are the same (which gives a huge performance boost which is e.g. necessary for mipmap generation) As you can see, that's still a great bunch of code, but we don't necessarily need to implement all of these (we could just implement the to/from small ARGB part for each format type and use a buffer if we need to convert from one "unusual" format to another unusual one). These converters will need to be duplicated across the various filter types. This architecture is the only way I could think of managing the implementation of this function without macros (although they would really improve the code in this scenario) and still keeping up to speed with the native dll. I have attached a patch providing my current implementation, providing support for copying data from small unsigned ARGB data to small unsigned ARGB data. A few notes on these few lines of code: 1. if(DestFormat.rbits) { 2. if(SrcFormat.rbits) { 3. for(shift = DestShiftR; shift > DestFormat.rshift; shift -= SrcFormat.rbits) *pPixel |= r << shift; 4. *pPixel |= (r >> (DestFormat.rshift - shift)) << DestFormat.rshift; 5. } else *pPixel |= DestFormat.rmask; 6. } 1: There's no need to mess around with the red component if we don't need it in the destination color anyways 2/5: If the source color does not provide a red component, we assume the maximum red value (which is the red mask) 3/4: These lines convert the source color component to the destination color component; the for loop is needed to make sure that e.g. an R5 0b11111 maps to an 0b11111111 in R8 instead of 0b11111000 (the for loop is faster than using floating point calculation for this) The actual D3DXLoadSurfaceFromMemory implementation doesn't do anything special, the "critical" stuff happens in copy_simple_data. I hope the code is understandable in the other parts, my few main questions are: Do you agree that the architecture is the best approach or can you think of a better one? would using macros be legal here since it could really help reduce code duplication when implementing the other filters? Is the code itself okay? Suggestions about coding style or other things are welcome. Is there any optimization I missed? - I spend a somewhat large amount of time getting the right balance between wide format support and good performance, but maybe things can be improved a bit more. Right now my implementation is about 10 % slower than the native one. Any other comments which could be interesting to me at this point are also appreciated, of course. Best regards, Tony

4 8

RFC: Fixing kernel32:locale tests on Vista and higher
by Ge van Geldorp 31 Aug '09

31 Aug '09

There are quite a few failures in kernel32:locale on Vista+. The attached patch tries to address those. Although any comment on the patch is welcome, I'm particularly interested in feedback on the changes to test_FoldStringW() (the part that starts at "@@ -2081,43 +2136,49 @@ static void test_FoldStringW(void)".) The problem with this test was that FoldStringW() behaves very differently on Vista+ for the MAP_FOLDCZONE and MAP_EXPAND_LIGATURES cases. The tests were broken off after more than 50 failures, if I remove that then I get 7455 failures for MAP_FOLDCZONE and 1350 failures for MAP_EXPAND_LIGATURES. Now, it is possible to fix all those failures. However, doing so would require us to duplicate the tables that Microsoft uses. This is basically the same problem that we have with the collation tables. To work around this, I simply skip the test on Vista+, just like we skip the sorting test. Does this sound like the right approach? Thanks, Ge.

5 5

Missing libxml2 -> msxml3 compilation error
by Francois Gouget 31 Aug '09

31 Aug '09

It turns out I was missing libxml2 in one of my environments and this lead to the following compilation error: $ gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -DCOM_NO_WINDOWS_H -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wwrite-strings -Wpointer-arith -g -O2 -o dispex.o dispex.c dispex.c:49: field `tid' has incomplete type dispex.c:76: `LAST_tid' undeclared here (not in a function) dispex.c:115: parameter `tid' has incomplete type ... The problem is that tid_t is defined by msxml_private.h in a section enclosed in an #ifdef HAVE_LIBXML2. But it's then used in dispex.c regardless of HAVE_LIBXML2. So should tid_t always be defined or should the relevant portions of dispex.c be enclosed in an #ifdef HAVE_LIBXML2? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux: It is now safe to turn on your computer.

2 1

Re: RFC: Fixing kernel32:locale tests on Vista and higher
by Greg Geldorp 30 Aug '09

30 Aug '09

From: Reece Dunn > Does anyone understand what these are doing and (in a general sense) > what the changes to Vista are? When you specify the MAP_FOLDCZONE flag, FoldStringW() on Vista will try to return a "simple" presentation for the Unicode characters. For example, if you pass in 0x01c7 ("LATIN CAPITAL LETTER LJ", L and J combined into a single Unicode character, see http://www.fileformat.info/info/unicode/char/01c7/index.htm) then FoldStringW() will return two characters: the letter L (0x004c) and the letter J (0x004a). Versions prior to Vista simply returned the exact same code that you passed in for all codes < 0xf900. Flag MAP_EXPAND_LIGATURES does something similar for ligatures. > I suppose the main questions to ask are: > 1/ are there applications that depend on the pre-Vista locale rules? > 2/ are the Linux/*BSD/Mac/OpenSolaris (or glibc, uLibc, ...) locale > rules *compatible* with Windows? > > I haven't seen anything on the locale changes for Vista breaking > anything except the Wine tests. As a result, it should (in theory) be > possible to use the native version. This would then remove the need > for Wine to copy the Microsoft locale tables. Right. But that wouldn't fix the current tests. Ge.

1 0

Weekly cppcheck run against Aug 27 Git Tree
by chris ahrendt 30 Aug '09

30 Aug '09

This is the result of running cppcheck 1.35 with the --all parm against the august 27th Git tree: [../wine-git/dlls/dbghelp/msc.c:88]: (possible error) Array index out of bounds [../wine-git/dlls/dbghelp/msc.c:89]: (possible error) Array index out of bounds [../wine-git/dlls/msvcrt/tests/file.c:982]: (error) Deallocating a deallocated pointer: stream2 [../wine-git/dlls/msvcrt/tests/file.c:966]: (error) Resource leak: stream3 [../wine-git/dlls/msvcrt/tests/file.c:973]: (error) Resource leak: stream4 [../wine-git/dlls/msvcrt/tests/heap.c:433]: (possible error) Memory leak: mem [../wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd [../wine-git/dlls/rpcrt4/tests/server.c:1189]: (possible error) Array index out of bounds [../wine-git/dlls/shell32/cpanelfolder.c:562]: (error) Possible null pointer dereference: rgfInOut [../wine-git/dlls/shell32/shfldr_desktop.c:437]: (error) Possible null pointer dereference: rgfInOut [../wine-git/dlls/shell32/shfldr_fs.c:577]: (error) Possible null pointer dereference: rgfInOut [../wine-git/dlls/shell32/shfldr_mycomp.c:474]: (error) Possible null pointer dereference: rgfInOut [../wine-git/dlls/shell32/shfldr_netplaces.c:352]: (error) Possible null pointer dereference: rgfInOut [../wine-git/dlls/user32/tests/msg.c:63]: (error) Invalid number of character ({). Can't process file. [../wine-git/dlls/winealsa.drv/waveinit.c:745]: (possible error) Buffer overrun [../wine-git/dlls/wined3d/arb_program_shader.c:907]: (possible error) Buffer overrun [../wine-git/dlls/wined3d/arb_program_shader.c:915]: (possible error) Buffer overrun [../wine-git/dlls/wined3d/glsl_shader.c:3416]: (possible error) Buffer overrun [../wine-git/dlls/wined3d/glsl_shader.c:3418]: (possible error) Buffer overrun [../wine-git/dlls/wined3d/glsl_shader.c:3519]: (possible error) Buffer overrun [../wine-git/dlls/wined3d/glsl_shader.c:3521]: (possible error) Buffer overrun [../wine-git/dlls/wineoss.drv/mixer.c:1458]: (possible error) Buffer overrun [../wine-git/dlls/wineps.drv/init.c:270]: (error) Possible null pointer dereference: dmW [../wine-git/programs/oleview/pane.c:152]: (error) Possible null pointer dereference: hWndCreated [../wine-git/programs/winetest/main.c:114]: (possible error) Buffer overrun [../wine-git/programs/winetest/main.c:116]: (possible error) Buffer overrun [../wine-git/programs/winetest/main.c:119]: (possible error) Buffer overrun [../wine-git/programs/winetest/main.c:121]: (possible error) Buffer overrun [../wine-git/server/file.c:235]: (possible error) Buffer overrun [../wine-git/tools/fnt2bdf.c:656]: (error) Resource leak: fd [../wine-git/tools/fnt2fon.c:303]: (error) Memory leak: file_lens [../wine-git/tools/makedep.c:337]: (error) Resource leak: file [../wine-git/tools/widl/write_msft.c:2540]: (error) Deallocating a deallocated pointer: fd [../wine-git/tools/winedump/pe.c:1549]: (possible error) Memory leak: map Chris

7 7

re: PATCH[1/6] user32.dll:SwitchDesktop API Implementation
by Dan Kegel 30 Aug '09

30 Aug '09

It'd be cool if you mentioned what this patch series does for users. Does it fix some app that's broken? You probably need to include conformance tests for the new functions you implement. You may find that the maintainer is very picky about changes to wineserver. Don't be discouraged if your patch series isn't accepted at first, just keep improving it, addressing the issues people raise, and resubmitting.

1 0

Re: PATCH[1/6] user32.dll:SwitchDesktop API Implementation
by Mike Kaplinskiy 29 Aug '09

29 Aug '09

On Sat, Aug 29, 2009 at 1:51 AM, shanmukha sainath addepalli<sainath.addepalli(a)gmail.com> wrote: > > Hi, > > These are the series of patches for SwitchDesktop and > OpenInputDesktop API implementation in user32.dll > > SwitchDesktop API when called switches to another desktop and makes > it active. > > First patch is the implementation of SwitchDesktop API in > user32/win.c.This function calls the Declaration handler for the > switchdesktop. > > Change Log: Implemented SwitchDesktop API > > --- > Regards > Sainath A > > Sainath, Some comments (note these are general, I don't actually know the functions you're implementing): - You shouldn't mix tabs and spaces in your patches (match the format of the file). - The wine tree has to compile after every patch (the reason is regression testing). You can split this queue up into two parts - first implement OpenInputDesktop, then SwitchDesktop (or the other way around) - to have 4 patches: 1 - add open_input_desktop server request, 2 - implement OpenInputDesktop, 3 - add switch_desktop server request, 4 - implement SwitchDesktop. - You don't have to pass the calling thread's tid to the server - the server has a global called current which is the thread * object that made the request. - You seem to sometimes return error codes from the server, but changing things nonetheless. Something seems off about that. Also you sometimes just do return; without setting an error code. - I'm not quite sure what you're doing in close_desktop. - Code: Don't do if (!(... == ...)), just use if (... != ...). If you break; in either case of the if, do it outside the if. You don't need to check &desktop_ops != NULL. - Don't use HTML emails, most people don't like those. Mike.

1 0

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 August 2009