February 2010 - Wine-Devel - list.winehq.org

Re: msxml3-implement-domcomment_replaceData
by Nikolay Sivov Feb. 6, 2010

Feb. 6, 2010

On 2/5/2010 20:18, jose rostagno wrote: > implement missing domcomment_replaceData > + if((offset == 0) || ((count + offset)>= len)) > + { > + if(offset == 0){ > + IXMLDOMComment_substringData(iface, count, len - count,&str); > + hr = IXMLDOMComment_put_data(iface, str); > + if(hr == S_OK) > + hr = IXMLDOMComment_appendData(iface, p); > This doesn't look right. You're appending replacement string to the rest of initial string data, and offset == 0 means to replace from the start (if I didn't miss something). Also we really need some tests here, and it's trivial to test here (look at existing test I recently added for deleteData() for example). Especially test for a case count != (p string length) is interesting. Minor things: - watch for indentation and please avoid tabs - most lines are indented with spaces, - don't use 'if () {' style. The rest of this file uses '{' on the next line, - correct your name in author filed to start with uppercase.

1 0

MDI client repaint issues (client and children) and conformance tests for this
by Reece Dunn Feb. 6, 2010

Feb. 6, 2010

Hi, I have been looking at http://bugs.winehq.org/show_bug.cgi?id=14312 which shows up as the MDI client window not being repainted properly when a new child is created given an already maximised child window being present. There is a related issue here that sometimes the child window frames are not being redrawn properly. I am trying to understand where this problem is occurring, and am failing to see the big picture. As I understand it, WM_MDIRESTORE is sent for the maximised child window, which calls ShowWindow(SW_RESTORE) on the child. This is then (from what I can tell) is handled by the windowing code (with the client behaving like a desktop window), which is taking care of the positioning and layout of the child windows. For some reason, the parent window (the client) is not being updated properly (i.e. a WM_ERASEBKGND+WM_PAINT is not being sent). Likewise, the child windows don't appear to be handling and/or receiving a WM_NCPAINT message to redraw their frame. In addition to this, looking at the message trail tests in user32/tests/msg.c, only some of these are testing a WM_ERASEBKGND+WM_PAINT message is being sent. How accurate are these with respect to WM_PAINT messages (that is, are WM_PAINT messages ignored in message trails unless explicitly tested for?). And in terms of a fix, what is the best approach for fixing the issue? That is, Alexandre does not like an explicit call to InvalidateRect in the WM_MDICREATE handler, so I assume that the repaint logic should be done in a more specific place or figure out why it is not being called for the MDI client. - Reece

2 3

Winehq donation and DATA COMPRESSION
by Gerold Jens Wucherpfennig Feb. 6, 2010

Feb. 6, 2010

Hi, I've donated some bucks to winehq by PayPal and want to spend more... Can I decide for which things will be spend? When donating money, how much of it will go to PayPal? Is there a better way than using PayPal (by the donate link of the winehq front-page)? BTW I've done some cabinet.dll stuff some years ago. Can anybody give me a hint to some easy-to-understand data compression documentation? I want to complete the cabinet.dll archive creation compression, if I get the required knowledge. It's so difficult... :-( Thanks and Bye, Gerold

6 5

Display drivers
by C.W. Betts Feb. 6, 2010

Feb. 6, 2010

An idea that popped into my head when I was thinking about a Quartz (OS X) driver that perhaps there could be separate drivers for Quartz (OS X) and X11. Such drivers would include OpenGL and DirectX "Drivers".

1 0

Implement D3DXDeclaratorFromFVF
by paulo lesgaz Feb. 6, 2010

Feb. 6, 2010

The patch is a copy/paste from the file d3d9/verdeclaration.c. So this file should be simplified too, if we simplify the d3dx9_36/mesh.c implementation. Obviously, to compute the size of the vertex, we can use D3DXGetDeclVertexSize, but we gain very few. So, what do you think about this? A+ David

1 0

Re: [1/3] d3dx9: Partial implementation of D3DXAssembleShader function. [try 2]
by Henri Verbeet Feb. 5, 2010

Feb. 5, 2010

On 4 February 2010 19:26, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > +void wpp_write_message_var(const char *fmt, ...) PRINTF_ATTR(1,2); > +void wpp_write_message_var(const char *fmt, ...) You can just do the following: +void PRINTF_ATTR(1,2) wpp_write_message_var(const char *fmt, ...) > + desc = HeapAlloc(GetProcessHeap(), 0, sizeof(struct mem_file_desc)); sizeof(*desc) is generally easier, but that's minor of course. > + if(desc->pos + len > desc->size) len = desc->size - desc->pos; It's usually safer to write expressions like that as "if (len > desc->size - desc->pos)" because "desc->pos + len" can wrap around if len is large, while "desc->size - desc->pos" should always be safe. Perhaps the caller is expected to always pass sane values here, but it's a somewhat dangerous construction in the general case in terms of reading/writing past the end of buffers. It can also be simplified to "len = min(len, desc->size - desc->pos);" here. > + if(wpp_output_size + len > wpp_output_capacity) Similar issue as above. > +int wpp_close_output(void) > +{ > + /* trim buffer to the effective size */ > + char *new_wpp_output = HeapReAlloc(GetProcessHeap(), 0, wpp_output, > + wpp_output_size + 1); > + if(!new_wpp_output) return 0; > + wpp_output[wpp_output_size]='\0'; > + return 1; > +} This doesn't really make sense. The comment is misleading, because you actually grow the buffer if "wpp_output_size == wpp_output_capacity". If you didn't, you wouldn't care about HeapRealloc() failure because the worst thing that could happen was that the buffer was a bit larger than it strictly needed to be. More importantly though, you assume new_wpp_output is the same pointer as wpp_output after a successful HeapReAlloc(), which isn't necessarily true. > + current_shader.buffer = HeapAlloc(GetProcessHeap(), 0, data_len + 1); ... > + ret = wpp_parse("", NULL); > + if(!wpp_close_output()) > + ret = 1; > + if(ret) > + { > + TRACE("Error during shader preprocessing\n"); > + HeapFree(GetProcessHeap(), 0, current_shader.buffer); I don't think it's very nice to have the HeapAlloc() and HeapFree() on different levels of the code like that. I.e., either have both in wpp_open_mem()/wpp_close_mem() or have both in the caller. The current scheme has the allocation in the caller and the deallocation in wpp_close_mem(), except sometimes when wpp_parse() fails to call wpp_close_mem(). (Can that even happen? Looking at the source of wpp_parse() it's not clear to me how.) Also, does wpp_parse() really need the input to be zero-terminated?

3 5

CJK default fonts for packagers to set
by Scott Ritchie Feb. 5, 2010

Feb. 5, 2010

My notes from Wineconf remind me that I need to create some manual links in the registry to whatever default CJK fonts are on the system. Can someone tell me what these are supposed to look like? Thanks, Scott Ritchie

3 3

Git does not build properly after daily pull -- font errors
by Susan Cragin Feb. 5, 2010

Feb. 5, 2010

What's up with the git repository? I do the following: git pull sudo make uninstall ./configure --enable-win64 && make distclean ./configure --enable-win64 && make depend && make and I get the following: warning: System 16: missing glyph for char f8c8 make[1]: *** No rule to make target `marlett.ttf', needed by `all'. Stop. make[1]: Leaving directory `/home/susan/wine/fonts' make: *** [fonts] Error 2 So I delete the git repository and download a new one.

3 2

Re: Git does not build properly after daily pull -- font errors
by Susan Cragin Feb. 5, 2010

Feb. 5, 2010

>Susan Cragin wrote: >> ./configure --enable-win64 && make distclean >> ./configure --enable-win64 && make depend && make >Huh? Are you actually trying to build the 64-bit version of Wine? Why >would you want to do that? Especially when 64-bit Wine isn't mature yet. > >Did you try it without --enable-win64? >> >> and I get the following: >> >> warning: System 16: missing glyph for char f8c8 >> make[1]: *** No rule to make target `marlett.ttf', needed by `all'. Stop. >> make[1]: Leaving directory `/home/susan/wine/fonts' >> make: *** [fonts] Error 2 >Check out commit 8350aafd5495c77ad4ba005dc4ae3f61a1ad1147: > > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Thu Feb 4 20:29:23 2010 +0100 > > fonts: Remove the rules for font symlinks and go back to standard VPATH >usage. > >I'll bet that has something to do with it... >> >> So I delete the git repository and download a new one. >OK? Then what happened? Did it work, or didn't it? The new git repository worked. I've been doing --enable-win64 because it has worked for me. I've been doing it for a couple of weeks and haven't had a problem. Susan

1 0

Re: confirm af48973b6246cef737c553415eed7349e89b5944
by L. Rahyen Feb. 5, 2010

Feb. 5, 2010

On 2010-02-02 (February, Tuesday) 15:00:01 wine-devel-request(a)winehq.org wrote: > Your membership in the mailing list wine-devel has been disabled due > to excessive bounces The last bounce received from you was dated > 26-Jan-2010. You will not get any more messages from this list until > you re-enable your membership. You will receive 2 more reminders like > this before your membership in the list is deleted. > > To re-enable your membership, you can simply respond to this message > (leaving the Subject: line intact), or visit the confirmation page at > > > http://www.winehq.org/mailman/confirm/wine-devel/af48973b6246cef737c553415 > eed7349e89b5944 > > > You can also visit your membership page at > > http://www.winehq.org/mailman/options/wine-devel/research%40science.su > > > On your membership page, you can change various delivery options such > as your email address and whether you get digests or not. As a > reminder, your membership password is > > xearaxon > > If you have any questions or problems, you can contact the list owner > at > > wine-devel-owner(a)winehq.org >

1 0