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().
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.
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
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
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.
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.
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.
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.
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.