wine-devel January 2012

wine-devel@winehq.org

83 participants
193 discussions

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

[PATCH RFC 4/5] dsound: Clean up channels
by Joerg-Cyril.Hoehle＠t-systems.com 03 Jan '12

03 Jan '12

Alexander, You want to google the paper titled "Defining speaker locations in multi-channel streams and WDM audio drivers using the WAVEFORMATEXTENSIBLE structure" by Carsten Schulz to learn a lot about channel mapping as performed by w2k. It's a pity there's nothing like it for xp or w7! Wine's mmdevapi does not yet behave like native's 5:1 cards. People have sent me the following mmdevapi:render test data on native machines: render.c:182: chan: 6 render.c:183: rate: 48000 render.c:184: align: 24 render.c:191: Mask: 3f IOW, the system's mixer format is really 6 channels! There presumably, DSound sends stereo and 6 channel data to the mixer. I suppose MS evolved DSound's mixer into mmdevapi's one, with some lessons learned. BTW, as I'm not aware of a means to extract from ALSA the user's speaker configuration, Wine likely needs either a winecfg setting (like MS' system preferences) or a registry key to advertize the mixer's dwChannelMask (and default to 0x3f with 6 channels). Regards, Jörg Höhle

1 0

new d3d9/device.ok test always fails here, but not a regression?
by Joerg-Cyril.Hoehle＠t-systems.com 03 Jan '12

03 Jan '12

Hi, > Bugs in newly added code cannot be regressions. > > Similarly, if we add a dll and some app starts using it and breaks, > technically that's not a regression even though the behavior got worse, > because it has always been broken, it just wasn't exercised before. What does this distinction bring us? The old definition, "if it worked in version N and doesn't in N+1, then it is a regression" was straightforward and easy to understand. There was little to debate, no room left for confusion. Every such regression could be associated with the SHA1 of a commit. The new definition can get arbitrarily complex. Consider bug #19496. Bug resolution likely involves moving from mciwave to mciavi. As mciavi is not equally advanced, this move will likely cause bugs to appear in other apps. But we wouldn't call them regressions "because it has always been broken"?!? That makes no sense to users. What benefit does it have for developers? Having one's name appear less often in source.winehq.org/regressions when doing The Right Thing (TRT)? Regards, Jörg Höhle

5 5

Re: mscoree: Implement CLRRuntimeHost_ExecuteInDefaultAppDomain
by Vincent Povirk 03 Jan '12

03 Jan '12

Cool! Looks good to me. On Tue, Jan 3, 2012 at 4:23 AM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > Hi, > > > Changelog: > mscoree: Implement CLRRuntimeHost_ExecuteInDefaultAppDomain > > > Best Regards > Alistair Leslie-Hughes > > >

1 0

new d3d9/device.ok test always fails here, but not a regression?
by Dan Kegel 03 Jan '12

03 Jan '12

Happy New Year's Eve, everyone! 002447357c2b1feca5ef2649429fc55f70238901 added a IDirect3DDevice9::SetCursorPosition() test to d3d9. That test never worked here, I think. I filed http://bugs.winehq.org/show_bug.cgi?id=29094 for it, and marked it as a regression (since tests/device.c used to pass, but fails here after that commit). Henri removed the regression keyword and sha1sum without comment. What's the reasoning there? Is Henri saying there's something wrong with my test setup (stock ubuntu), or are new tests that cause 'make test' to fail not considered regressions? Or something else?

4 6

Re: [PATCH 3/5] d3d10/tests: Add a state groups test.
by Marvin 03 Jan '12

03 Jan '12

2 1

Re: [PATCH 2/5] wined3d: Recognize some more Intel GPUs.
by Christian Inci 03 Jan '12

03 Jan '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Henri, I'm using a Netbook with an Intel Atom N450 (Pineview, PCI ID: 8086:a011), which has 256MB under 2GB of RAM. Personally, I think we need a way for detecting the correct VRAM size for IGD's, as it usually depends on the total RAM size. (If not already implemented. I'm not familiar with the directx subset of Wine. ;-) ) Kind regards, Chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPAmH5AAoJEBs38cNfaEHvzBsH/2Xlg5bfOc6Cudr2dIgD2XJk +ru6bHLM51tN2aacQphRNm6y1e60DEPvEiBei8hSZ0dU+mP0C/WsuOMjHIz3+LIg kXfRgqfjExqXoCaZuDnjnFpVjkdnF+NJUJlvvqTRm2hmZIbvKIdvKUagyNx8rmnG 4Bro+00qzU7KlAuYHZZptlFcCF4efndllCKonMBt2IqxpePz84Kx7YfjTABXvZS4 +JeYVlMiZ8wcCzcE3C7MHWwXToas1vAE7BHWiCQ9sUrs0Me4e7KqurvFKm690sf+ L63eD16R9xfgS/SBWFEG74iehb8bEjZNZgpxMrjdZdU7vAVjskfhnAvAjFkkNxU= =IRzs -----END PGP SIGNATURE-----

2 1

Warning report for wine-1.3.36
by Jerome Leclanche 02 Jan '12

02 Jan '12

No change since 1.3.35. J. Leclanche

1 0

[PATCH RFC 4/5] dsound: Clean up channels
by Joerg-Cyril.Hoehle＠t-systems.com 02 Jan '12

02 Jan '12

Alexander, I'm not familiar with dsound + if (ichannels > 2) + FIXME("Conversion from %u to %u channels is not implemented, falling back to stereo", ichannels, ochannels); + dsb->mix_channels = 2; Does you code support 8 channels? Look through git history, and you'll see some patches made specifically for 6 or even 8 channel audio plus some 8->2 and 2->8 conversions. Without having a 5:1 or 7:1 card, I think this gives hints as to what apps expect from conversions. Of course, there's always a risk that an old bug analysis was biased by other bugs, leading to misconceptions and misbeliefs about the actual needs and behaviour. About dsound: convert from fixed to floating point Using floats for frequencies is not bad. After all, modern mmdevapi does it too in IAudioClockAdjustment::SetSampleRate Just avoid computing byte positions from floats... BTW, AUDCLNT_STREAMFLAGS_RATEADJUST hints that the DSound mixer implements stuff that mmdevapi's mixer needs... Regards, Jörg Höhle

1 0

Re: ieframe: Improved test traces
by Marvin 02 Jan '12

02 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=16234 Your paranoid android. === WNT4WSSP6 (32 bit webbrowser) === webbrowser.c:3089: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3089: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3089: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3089: Test failed: Creating WebBrowser object failed: 80040154 webbrowser.c:3166: Test failed: Creating WebBrowser object failed: 80040154 === W2KPROSP4 (32 bit webbrowser) === webbrowser.c:2473: Test failed: expected GetOverridesKeyPath webbrowser.c:2477: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2478: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:2087: Test failed: put_Resizable failed: 80004001 webbrowser.c:2088: Test failed: expected Invoke_WINDOWSETRESIZABLE webbrowser.c:2092: Test failed: put_Resizable failed: 80004001 webbrowser.c:2093: Test failed: expected Invoke_WINDOWSETRESIZABLE webbrowser.c:2473: Test failed: expected GetOverridesKeyPath webbrowser.c:2477: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2478: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:405: Test failed: unexpected call Exec_SETDOWNLOADSTATE_0 webbrowser.c:2087: Test failed: put_Resizable failed: 80004001 webbrowser.c:2088: Test failed: expected Invoke_WINDOWSETRESIZABLE webbrowser.c:2092: Test failed: put_Resizable failed: 80004001 webbrowser.c:2093: Test failed: expected Invoke_WINDOWSETRESIZABLE webbrowser.c:2473: Test failed: expected GetOverridesKeyPath webbrowser.c:2477: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2478: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:461: Test failed: unexpected nCmdID 29 webbrowser.c:959: Test failed: unexpected call GetContainer webbrowser.c:509: Test failed: unexpected call webbrowser.c:959: Test failed: unexpected call GetContainer webbrowser.c:509: Test failed: unexpected call webbrowser.c:2630: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2750: Test failed: expected TranslateUrl webbrowser.c:2751: Test failed: expected Invoke_BEFORENAVIGATE2 webbrowser.c:2752: Test failed: expected Invoke_PROPERTYCHANGE webbrowser.c:2758: Test failed: ReadyState = 1, expected 4 webbrowser.c:2582: Test failed: ReadyState = 1, expected 4 webbrowser.c:791: Test failed: unexpected call Invoke_PROPERTYCHANGE webbrowser.c:807: Test failed: unexpected call Invoke_BEFORENAVIGATE2 webbrowser.c:814: Test failed: ReadyState = 1, expected 4 webbrowser.c:606: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:606: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:609: Test failed: unexpected call Invoke_AMBIENT_DLCONTROL webbrowser.c:613: Test failed: unexpected call Invoke_AMBIENT_USERAGENT webbrowser.c:617: Test failed: unexpected call Invoke_AMBIENT_PALETTE webbrowser.c:1509: Test failed: unexpected call GetOptionKeyPath webbrowser.c:354: Test failed: unexpected call QueryStatus_SETPROGRESSTEXT webbrowser.c:791: Test failed: unexpected call Invoke_PROPERTYCHANGE webbrowser.c:791: Test failed: unexpected call Invoke_PROPERTYCHANGE webbrowser.c:791: Test failed: unexpected call Invoke_PROPERTYCHANGE webbrowser.c:791: Test failed: unexpected call Invoke_PROPERTYCHANGE webbrowser.c:461: Test failed: unexpected nCmdID 26 webbrowser.c:461: Test failed: unexpected nCmdID 29 webbrowser.c:959: Test failed: unexpected call GetContainer webbrowser.c:509: Test failed: unexpected call webbrowser.c:892: Test failed: ReadyState = 1, expected 4 webbrowser.c:1520: Test failed: unexpected call GetDropTarget webbrowser.c:959: Test failed: unexpected call GetContainer webbrowser.c:509: Test failed: unexpected call webbrowser.c:2630: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:3125: Test failed: doc != doc2 webbrowser.c:606: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:606: Test failed: unexpected call Invoke_AMBIENT_USERMODE webbrowser.c:609: Test failed: unexpected call Invoke_AMBIENT_DLCONTROL webbrowser.c:613: Test failed: unexpected call Invoke_AMBIENT_USERAGENT webbrowser.c:617: Test failed: unexpected call Invoke_AMBIENT_PALETTE webbrowser.c:1509: Test failed: unexpected call GetOptionKeyPath webbrowser.c:354: Test failed: unexpected call QueryStatus_SETPROGRESSTEXT webbrowser.c:461: Test failed: unexpected nCmdID 26 webbrowser.c:461: Test failed: unexpected nCmdID 29 webbrowser.c:959: Test failed: unexpected call GetContainer webbrowser.c:509: Test failed: unexpected call webbrowser.c:1520: Test failed: unexpected call GetDropTarget webbrowser.c:959: Test failed: unexpected call GetContainer webbrowser.c:509: Test failed: unexpected call webbrowser.c:2623: Test failed: expected TranslateUrl webbrowser.c:2630: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2843: Test failed: expected RequestUIActivate webbrowser.c:2935: Test failed: Got 0x80004002 webbrowser.c:3133: Test failed: doc != doc2 webbrowser.c:3030: Test failed: QueryService failed: 80004002 webbrowser: unhandled exception c0000005 at 0040C9B2

1 0

Re: urlmon: When detecting text/html look for HEAD or BODY tags too and only in first 256 bytes
by Jacek Caban 02 Jan '12

02 Jan '12

On 01/02/12 14:53, Paul Chitescu wrote: > Changelog: > urlmon: When detecting text/html look for HEAD or BODY tags too and only in > first 256 bytes Please add a test case. > > This fixes bug #27115 and similar. > > Note that this is just a minor improvement. The entire implementation should > be changed to follow the IE way: > http://msdn.microsoft.com/en-us/library/ms775147(v=vs.85).aspx > It mostly is except that page is full of mistakes (as proven by our tests). Jacek

1 0

Release plans
by Alexandre Julliard 02 Jan '12

02 Jan '12

Happy New Year to everyone! As you probably know, 2012 will be the year when we release 1.4. I know I already said this last year, but this time I mean it... The release features are in good shape now, and the plan is to enter code freeze as soon as the DIB engine can be considered done, which should be Real Soon Now. At this point it looks like there will be a 1.3.37 release (if only because that's a fun release number...), but it's likely that the release after that will be 1.4rc1. This means that if there are changes you want to get in before code freeze, they need to be done in the next 3 weeks or so. I'm thinking in particular of the audio changes that people have been discussing. Now would also be a good time to look for your name on the Regression Hall of Shame (http://source.winehq.org/regressions) and see if you can do something to bring your count down, as I expect the counts will go up again once rc1 is out and users start testing it. And if you don't have any regressions to your name, feel free to tackle some of mine ;-) -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] jscript: functions that return -1 should have signed return (Coverity)
by Jacek Caban 02 Jan '12

02 Jan '12

Hi Marcus, On 12/31/11 15:43, Marcus Meissner wrote: > Hi, > > Side issue of CID 5504. > > Ciao, Marcus > --- > dlls/jscript/compile.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/jscript/compile.c b/dlls/jscript/compile.c > index 60b0c2e..96497b6 100644 > --- a/dlls/jscript/compile.c > +++ b/dlls/jscript/compile.c > @@ -146,7 +146,7 @@ static BSTR compiler_alloc_bstr(compiler_ctx_t *ctx, const WCHAR *str) > return ctx->code->bstr_pool[ctx->code->bstr_cnt++]; > } > > -static unsigned push_instr(compiler_ctx_t *ctx, jsop_t op) > +static int push_instr(compiler_ctx_t *ctx, jsop_t op) > { > assert(ctx->code_size>= ctx->code_off); > > @@ -328,7 +328,7 @@ static HRESULT compile_member_expression(compiler_ctx_t *ctx, member_expression_ > > #define LABEL_FLAG 0x80000000 > > -static unsigned alloc_label(compiler_ctx_t *ctx) > +static int alloc_label(compiler_ctx_t *ctx) > { > if(!ctx->labels_size) { > ctx->labels = heap_alloc(8 * sizeof(*ctx->labels)); This patch just moves the problem around by introducing a lot of int to unsigned int assignments. Introducing something like INVALID_HANDLE_VALUE would solve the problem here, but I've sent more widespread changes that will fix this problem as well. Thanks, Jacek

1 0

Strange comdlg32 resource string
by Francois Gouget 01 Jan '12

01 Jan '12

André Hentschel pointed me to a strange cmdlg32 resource string: IDS_ABOUTBOX "&About FolderPicker Test" The text seems unlikely to be correct. IDS_ABOUTBOX was introduced in 87b81de0 but was not used even in that patch and as far as I can see it is still not used by Wine. Looking at the Windows comdlg32 dll I see no string resource (but that mostly make me suspicious of the tool I used). Furthermore, none of the other strings in that string table seem to be used either: IDS_DOCUMENTFOLDERS "Document Folders" IDS_PERSONAL "My Documents" IDS_FAVORITES "My Favorites" IDS_PATH "System Path" IDS_DESKTOP "#msgctxt#display name#Desktop" IDS_FONTS "Fonts" IDS_MYCOMPUTER "My Computer" -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U

1 0

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 January 2012