April 2013 - Wine-devel - list.winehq.org

Re: oledb32: Implement GetConversionSize DBTYPE_WSTR->DBTYPE_WSTR
by Nikolay Sivov 20 Apr '13

20 Apr '13

On 4/20/2013 13:43, Alistair Leslie-Hughes wrote: > Hi, > > > Changelog: > oledb32: Implement GetConversionSize DBTYPE_WSTR->DBTYPE_WSTR > > > Best Regards > Alistair Leslie-Hughes Please add a test when caller supplies source length, at least one case is interesting - supplied length is less than lstrlenW result. Another case would be embedded nulls and source length larger than null terminated length.

1 0

Re: [PATCH 2/2]vbscript: Implemented builtin function CBool(try 2)
by Marvin 20 Apr '13

20 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=25206 Your paranoid android. === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP2 (32 bit) === No test summary line found === WXPX64 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAX64 (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 === WXPX64 (64 bit) === No test summary line found === WVISTAX64 (64 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 1/2]vbscript: Implemented builtin function CInt(try 2)
by Marvin 20 Apr '13

20 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=25204 Your paranoid android. === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP2 (32 bit) === No test summary line found === WXPX64 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAX64 (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 === WXPX64 (64 bit) === No test summary line found === WVISTAX64 (64 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 2/7] wined3d: Use ARB_internalformat_query2 to check for texture format rendering and blending support, where available.
by Henri Verbeet 19 Apr '13

19 Apr '13

On 18 April 2013 21:19, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + if (!format->glInternal) continue; > + > + gl_info->gl_ops.ext.p_glGetInternalformativ(GL_TEXTURE_2D, format->glInternal, > + GL_FRAMEBUFFER_RENDERABLE, 1, &value); > + if (value == GL_FULL_SUPPORT) > + { > + TRACE("Format %s is supported as FBO color attachment.\n", debug_d3dformat(format->id)); > + format->flags |= WINED3DFMT_FLAG_RENDERTARGET | WINED3DFMT_FLAG_FBO_ATTACHABLE; > + format->rtInternal = format->glInternal; > + > + if (!(format->flags & (WINED3DFMT_FLAG_DEPTH | WINED3DFMT_FLAG_STENCIL))) > + query_format_flag(gl_info, format, format->glInternal, GL_FRAMEBUFFER_BLEND, > + WINED3DFMT_FLAG_POSTPIXELSHADER_BLENDING, "post-pixelshader blending"); > + } This may be a bit dangerous, since you're now potentially adding WINED3DFMT_FLAG_RENDERTARGET for formats like e.g. WINED3DFMT_R8G8B8A8_SNORM that didn't previously had it, and where it's a bit questionable if it's really going to work as intended. Also, the depth/stencil check that follows is either redundant, or we're now also potentially setting WINED3DFMT_FLAG_RENDERTARGET for depth/stencil formats. At least initially we'll probably want to stick with formats that already have WINED3DFMT_FLAG_RENDERTARGET set, and only clear it if unsupported. At a later point we may want to do something more centered around the information we get from internalformat_query2, but I suspect it will be a bit harder than just checking if there's no fixup, no conversion function, etc.

2 1

Re: [PATCH 2/7] wined3d: Store vs_clipping in the adapter
by Henri Verbeet 19 Apr '13

19 Apr '13

On 19 April 2013 11:20, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Potential alternatives include keeping the status quo or introducing a > separate structure that holds these derived limits that is owned by the > device and linked in the contexts. We could also put it into gl_info, > but I dislike this idea because these limits are not GL limits, but > limits of our shader and fixed function pipeline implementations. I think we'll want a separate structure for this. Note that you essentially have two different kinds of data you're concerned with here though. One is derived state like e.g. the texture unit map, the stream info, or the view_indent from patch 1/7. We don't really want that in wined3d_state, because there's no reason for e.g. every stateblock to have a copy of that. Having the derived state structure be owned by the device is probably ok, although there may also be something to be said for making it part of the context instead. The other type of data is immutable data like derived caps and limits, as in this patch and following ones. In principle the adapter is the right place for that, but I do think we want a separate structure for that, and probably a pointer to it in the context, for similar reasons as having one to gl_info. Arguably things like the state table, format info and the shader backend would belong in the same structure. I.e., essentially we'd have a setup like wined3d_gl_info, but for more wined3d specific / derived info.

2 2

Re: [PATCH 3/7] wined3d: Use ARB_internalformat_query2 for the other texture format caps too.
by Henri Verbeet 19 Apr '13

19 Apr '13

On 18 April 2013 21:20, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + /* FIXME: We can't handle "partial" sRGB decode support right now, we could > + * introduce a new format flag and check for that. */ As mentioned on IRC, I don't think this is really an issue. The patch looks otherwise ok.

1 0

Re: [PATCH 1/3] msvcrt: Added _mbsncoll and _mbsncoll_l implementation.
by Akihiro Sagawa 19 Apr '13

19 Apr '13

On Fri, 19 Apr 2013 14:42:50 +0800, Jactry Zeng wrote: > +/********************************************************************* > + * _mbsncoll_l(MSVCRT.@) > + */ > +int CDECL _mbsncoll_l(const unsigned char *str1, const unsigned char *str2, MSVCRT_size_t count, > + MSVCRT__locale_t locale) > +{ > + return _mbsnbcoll_l(str1, str2, count, locale); > +} According to MSDN, _mbsncoll_l receives a number of characters, but _mbsnbcoll_l receives a number of bytes. This is a big difference in multibyte code page. So you should properly handle this situation, or add FIXME message based on multibyte code page if your application just needs this function. Regards, Akihiro Sagawa

2 1

Google Summer of Code 2013
by Anulesh Tiwari 19 Apr '13

19 Apr '13

Sir, I will be applying for GSoC 2013 under your mentoring team. Sorry for contacting very late with you as I was not aware of this program. I came to know yesterday that Gsoc is going to start. As a CS student and I have a well understanding of C C++ and Java and Data structures I am always very keenly interested in programming and coding. I devote my daily 8 hrs to it. As a potential linux user I have chosen Ideas from your list Cygwin Improvement I wish to apply on this topic and devote my each and every day of this summer to help my friends and colleagues to run Wine without bugs. Well one more thing to say Sir please give more Information and details what I have to do to assure my project to be done. Regards Anulesh Tiwari Bachelor of Science Department of Computer Science BHU INDIA

1 0

Fun with GCC 4.8
by James Eder 18 Apr '13

18 Apr '13

As many of you no doubt know, GCC recently released 4.8.0. This new version introduces a new optimization level enabled by -Og with the following description (from the man page): "Optimize debugging experience. -Og enables optimizations that do not interfere with debugging. It should be the optimization level of choice for the standard edit-compile-debug cycle, offering a reasonable level of optimization while maintaining fast compilation and a good debugging experience." Of course I had to try it out. I found that building Wine lead to GCC dieing with ... dlls/kernel32/console.c:1691:1: internal compiler error: Segmentation fault I also found ... dlls/kernel32/computername.c:701:1: internal compiler error: Segmentation fault I eventually stumbled my way into the enclosed patch which lets GCC build Wine with -Og. I'm not sure if this change (or something similar) makes sense for Wine. I'm fairly certain some changes make sense for GCC (I suspect that GCC should not segfault). I haven't submitted a bug for GCC because I suspect they'll want me to provide something simpler to compile than the Wine source tree. I certainly won't be upset if someone beats me too it. I'm not sure how much time in the near future I'll spend on it. "Eventually" is probably the word that fits. At any rate, I wanted to at least share my experiences in case anyone is interested in heading down the same path. -- Jim

3 3

Re: winex11.drv: Transmit WM_DEADCHAR messages to applications
by Alexandre Julliard 18 Apr '13

18 Apr '13

Simon Lipp <sloonz(a)gmail.com> writes: > @@ -389,6 +389,10 @@ static int process_events( Display *display, Bool (*filter)(Display*, XEvent*,XP > count++; > if (XFilterEvent( &event, None )) > { > + KeySym keysym = 0; > + XLookupString(&event.xkey, NULL, 0, &keysym, NULL); > + BOOL is_dead = (keysym >= XK_dead_grave && keysym <=XK_dead_semivoiced_sound); You can't assume that you have a key event here. -- Alexandre Julliard julliard(a)winehq.org

1 0