January 2012 - Wine-devel - list.winehq.org

Any bad side-effects from not building with HAL if udisks is enabled?
by Scott Ritchie 05 Jan '12

05 Jan '12

Assuming udisks support exists on the system, anything wrong with this? Does the new udisks do everything HAL used to do? Thanks, Scott Ritchie

2 2

Re: msvcrt: make WEOF returned from swscanf signed (try 2)
by Marvin 05 Jan '12

05 Jan '12

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=16280 Your paranoid android. === WXPPROSP3 (32 bit msvcr90) === msvcr90.c:1149: Test failed: swscanf returns 0 instead of ffff === W2K3R2SESP2 (32 bit msvcr90) === msvcr90.c:1149: Test failed: swscanf returns 0 instead of ffff === WVISTAADM (32 bit msvcr90) === msvcr90.c:1149: Test failed: swscanf returns 0 instead of ffff === W2K8SE (32 bit msvcr90) === msvcr90.c:1149: Test failed: swscanf returns 0 instead of ffff === W7PRO (32 bit msvcr90) === msvcr90.c:1149: Test failed: swscanf returns 0 instead of ffff === W7PROX64 (32 bit msvcr90) === msvcr90.c:1149: Test failed: swscanf returns 0 instead of ffff === TEST64_W7SP1 (32 bit msvcr90) === msvcr90.c:1149: Test failed: swscanf returns 0 instead of ffff === W7PROX64 (64 bit msvcr90) === msvcr90.c:1149: Test failed: swscanf returns 0 instead of ffff === TEST64_W7SP1 (64 bit msvcr90) === msvcr90.c:1149: Test failed: swscanf returns 0 instead of ffff

1 0

D3DXHANDLE for ID3DXConstantTable
by Rico Schüller 05 Jan '12

05 Jan '12

Hi, I'd like to get up the discussion for the D3DXHANLE in the ID3DXConstantTable again. There were several tries in the past, but there wasn't made a decision for one solution. My opinion about the handles is, that they have to allow at least the following options: 1. D3DXHANDLEs have to be global (not local to a ID3DXConstantTable), so the way the effect interface does it is not an ideal option for the ID3DXConstantTable 2. D3DXHANDLEs could also be strings and thus it is a requirement that this could be detected (at least for !D3DXCONSTTABLE_LARGEADDRESSAWARE) Ideally we may handle all D3DXHANDLEs the same way. Some possible solutions are listed in [3]. Any thoughts which way is preferred? Cheers Rico References: [1] http://www.winehq.org/pipermail/wine-devel/2010-April/082900.html [2] http://www.winehq.org/pipermail/wine-patches/2011-July/104325.html [3] http://www.winehq.org/pipermail/wine-devel/2011-July/091091.html

2 8

Re: [PATCH] msvcp60: Avoid a crash, when the ptr in basic_string_char is NULL
by Piotr Caban 05 Jan '12

05 Jan '12

Hi, > void __thiscall basic_string_char__Eos(basic_string_char *this, MSVCP_size_t len) > { > - this->size = len; > - this->ptr[len] = 0; > + if (this->ptr) { > + this->size = len; > + this->ptr[len] = 0; > + } > } This function should not be called if this->ptr is NULL. The bug is somewhere else. I'll take a look on it. Do you have a backtrace? Piotr

1 0

Re: msvcrt: make WEOF returned from swscanf signed
by Marvin 04 Jan '12

04 Jan '12

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=16267 Your paranoid android. === WNT4WSSP6 (32 bit scanf) === scanf.c:257: Test failed: sscanf returns 0 instead of ffff === W2KPROSP4 (32 bit scanf) === scanf.c:257: Test failed: sscanf returns 0 instead of ffff === WXPPROSP3 (32 bit scanf) === scanf.c:257: Test failed: sscanf returns 0 instead of ffff === W2K3R2SESP2 (32 bit scanf) === scanf.c:257: Test failed: sscanf returns 0 instead of ffff === WVISTAADM (32 bit scanf) === scanf.c:257: Test failed: sscanf returns 0 instead of ffff === W2K8SE (32 bit scanf) === scanf.c:257: Test failed: sscanf returns 0 instead of ffff === W7PRO (32 bit scanf) === scanf.c:257: Test failed: sscanf returns 0 instead of ffff === W7PROX64 (32 bit scanf) === scanf.c:257: Test failed: sscanf returns 0 instead of ffff === TEST64_W7SP1 (32 bit scanf) === scanf.c:257: Test failed: sscanf returns 0 instead of ffff === W7PROX64 (64 bit scanf) === scanf.c:257: Test failed: sscanf returns 0 instead of ffff === TEST64_W7SP1 (64 bit scanf) === scanf.c:257: Test failed: sscanf returns 0 instead of ffff

2 1

FYI: Pangolin script needs libfreeytype6-dev:386 but it cannot be installed
by Susan Cragin 04 Jan '12

04 Jan '12

The configure script seems to be looking for libfreetype6-dev:386 but this cannot be installed without removing the compilers and other files Should I alert Ubuntu? Isn't this their problem? Susan

2 1

Re: po: Update Italian translation
by Matteo Bruni 04 Jan '12

04 Jan '12

2012/1/4 Luca Bennati <lucak3(a)gmail.com>: > > > #: winmm.rc:34 > -#, fuzzy > msgid "There is no driver installed on your system!" > -msgstr "Non è stato installato nessun driver nel sistema !\n" > +msgstr "Non è presente nessun driver installato nel sistema!" Hi Luca, While your new translation is clearer than the previous one, I think in the new translation "presente" and "installato" mean more or less the same thing i.e. having both is redundant IMO. How about something like "Nessun driver è installato nel sistema!" (or "presente", or "attualmente installato"... you got it) instead?

1 0

Re: imm32: add a stub for ImmGetHotKey
by Dmitry Timoshkov 04 Jan '12

04 Jan '12

Austin English <austinenglish(a)gmail.com> wrote: > +BOOL WINAPI ImmGetHotKey(DWORD hotkey, UINT modifiers, UINT VKey, HKL hKL) What SDK/MSDN version does this match? Also please avoid using hungarian or capitalized variable names in Wine. > +@ stdcall ImmGetHotKey(long ptr ptr long) This doesn't match the implementation. -- Dmitry.

1 0

Re: [PATCH 2/7] wined3d: Move srgb checks away from d3dfmt_get_conv.
by Diego Nieto Cid 04 Jan '12

04 Jan '12

Hi, I beleive this patch introduced some kind of regression. While testing Fallout the following message was printed to the screen: trace:d3d_surface:surface_allocate_surface (0x1a25f0) : Creating surface (target 0xde1) level 0, d3d format WINED3DFMT_P8_UINT, internal format 0x80e5, width 1024, height 512, gl format 0x1908, gl type=0x1401 err:d3d_surface:surface_allocate_surface >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from glTexImage2D @ surface.c / 2571 Internal format 0x80e5 (GL_COLOR_INDEX8_EXT) is not valid for the format 0x1908 (GL_RGBA). Initially, the surface's format is 0x1900 (GL_COLOR_INDEX) which is compatible with the internal format above. On Thu, Apr 08, 2010 at 10:49:46PM +0200, Roderick Colenbrander wrote: > [...] > @@ -1553,7 +1581,7 @@ void surface_prepare_texture(IWineD3DSurfaceImpl *surface, const struct wined3d_ > > if (surface->Flags & alloc_flag) return; > > - d3dfmt_get_conv(surface, TRUE, TRUE, &desc, &convert, srgb); > + d3dfmt_get_conv(surface, TRUE, TRUE, &desc, &convert); > if(convert != NO_CONVERSION) surface->Flags |= SFLAG_CONVERTED; > else surface->Flags &= ~SFLAG_CONVERTED; > > @@ -1569,7 +1597,7 @@ void surface_prepare_texture(IWineD3DSurfaceImpl *surface, const struct wined3d_ > } > > surface_bind_and_dirtify(surface, srgb); > - surface_allocate_surface(surface, gl_info, &desc, width, height); > + surface_allocate_surface(surface, gl_info, &desc, srgb, width, height); > surface->Flags |= alloc_flag; > } > However before surface_allocate_surface is called d3dfmt_get_conv which translates the format to GL_RGBA. But the internal format remains in an incompatible value due to a reordering of the instructions which was introduced by the patch. On Thu, Apr 08, 2010 at 10:49:46PM +0200, Roderick Colenbrander wrote: > [...] > @@ -2126,18 +2153,6 @@ HRESULT d3dfmt_get_conv(IWineD3DSurfaceImpl *This, BOOL need_alpha_ck, BOOL use_ > *desc = *This->resource.format_desc; > *convert = NO_CONVERSION; > > - /* TODO: the caller should perform this check */ > - if(srgb_mode) { > - desc->glInternal = glDesc->glGammaInternal; > - } > - else if (This->resource.usage & WINED3DUSAGE_RENDERTARGET > - && surface_is_offscreen((IWineD3DSurface *) This)) > - { > - desc->glInternal = glDesc->rtInternal; > - } else { > - desc->glInternal = glDesc->glInternal; > - } > - > /* Ok, now look if we have to do any conversion */ > switch(This->resource.format_desc->format) > { Before applying the changes the processing of srgb_mode was done inside d3dfmt_get_conv. Depending on the value of this variable one of glGammaInternal, rtInternal or glInternal was used. But those values were overriden because the conversion was applied afterwards. On Thu, Apr 08, 2010 at 10:49:46PM +0200, Roderick Colenbrander wrote: > [...] > @@ -783,11 +797,25 @@ static void surface_upload_data(IWineD3DSurfaceImpl *This, const struct wined3d_ > * the correct texture. */ > /* Context activation is done by the caller. */ > static void surface_allocate_surface(IWineD3DSurfaceImpl *This, const struct wined3d_gl_info *gl_info, > - const struct wined3d_format_desc *format_desc, GLsizei width, GLsizei height) > + const struct wined3d_format_desc *format_desc, BOOL srgb, GLsizei width, GLsizei height) > { > BOOL enable_client_storage = FALSE; > const BYTE *mem = NULL; > - GLenum internal = format_desc->glInternal; > + GLenum internal; > + > + if (srgb) > + { > + internal = format_desc->glGammaInternal; > + } > + else if (This->resource.usage & WINED3DUSAGE_RENDERTARGET > + && surface_is_offscreen((IWineD3DSurface *)This)) > + { > + internal = format_desc->rtInternal; > + } > + else > + { > + internal = format_desc->glInternal; > + } > > if (format_desc->heightscale != 1.0f && format_desc->heightscale != 0.0f) height *= format_desc->heightscale; > After the change was applied the result of the conversion done inside d3dfmt_get_conv only takes effect in the else branch of srgb processing. The following code is the conversion involved in this particular test case. format->glFormat = GL_RGBA; format->glInternal = GL_RGBA; format->glType = GL_UNSIGNED_BYTE; format->conv_byte_count = 4; It's located in d3dfmt_get_conv under the WINED3DFMT_P8_UINT case. For some reason only glInternal is updated by the conversion. In any case it didn't matter before the patch as none of the internal values were actually used in case a conversion was applied. Should the three internal values be updated by the conversion now that any of them could be used? Even if it would work I'm not sure how correct would be to do that. Could some wined3d developer review the patch with all this in mind? Thanks!

2 5

Re: [PATCH 1/6] [lib/port]: Added a unicode POSIX compliant regular expression library
by Alexandre Julliard 03 Jan '12

03 Jan '12

Eric Pouech <eric.pouech(a)orange.fr> writes: > A+ > --- > > include/wine/regexw.h | 66 ++++++ > libs/port/Makefile.in | 1 > libs/port/regexw.c | 513 +++++++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 580 insertions(+), 0 deletions(-) > create mode 100644 include/wine/regexw.h > create mode 100644 libs/port/regexw.c I still think dbghelp should do its own regexp matching. It's not hard to do, and it would avoid the ugly regexp munging we have now. We don't really need a Posix compliant regexp. -- Alexandre Julliard julliard(a)winehq.org

1 0