wine-devel August 2011

wine-devel@winehq.org

86 participants
258 discussions

Re: ieframe: Moved intshcut.c tests to ieframe
by Marvin 05 Aug '11

05 Aug '11

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=13201 Your paranoid android. === WNT4WSSP6 (32 bit intshcut) === intshcut.c:112: Test failed: interface {cabb0da0-da57-11cf-9974-0020afd79762} could not be queried intshcut.c:380: Test failed: SetUrl failed, hr=0x80041001 intshcut.c:381: Test failed: SetUrl failed, hr=0x80041001 intshcut.c:383: Test failed: unexpected URL change www.winehq.org -> http://www.winehq.org (expected http://www.winehq.org/) intshcut.c:384: Test failed: unexpected URL change ftp.winehq.org -> ftp://ftp.winehq.org (expected ftp://ftp.winehq.org/) intshcut.c:231: Test failed: Unable to get an IPropertySetStorage, hr=0x80004002 intshcut: unhandled exception c0000005 at 00402852

1 0

Re: [PATCH 1/2] wscript: skip some tests on wow64 (resend)
by Alexandre Julliard 05 Aug '11

05 Aug '11

Michał Ziętek <smierc.w.wenecji(a)gmail.com> writes: > changed message Please fix the test instead of skipping it. -- Alexandre Julliard julliard(a)winehq.org

1 0

IsFormatSupported tests & compatibility affects winmm's acceptable formats
by Joerg-Cyril.Hoehle＠t-systems.com 04 Aug '11

04 Aug '11

Hi, Apps that use WINMM are best served when the default sound card is a (pseudo-)device that supports all kinds of formats and rates that the app may throw at it (even 9123 samples/s). Resampling in the OS (e.g. ALSA plug pseudo-device) is preferable as that code is well maintained, whereas Wine's resamplers (dsound and msacm) are known for poor quality (bug #14717). It would not be wise to present a sound card that accepts only 48000 to the w95 era application. 22050 is (was?) the standard, and even winmm/tests/wave.c expects that rate (a bug in wave.c). However, testing mmdevapi:IsFormatSupported shows that native solely accepts a single rate and fixed number of channels (e.g. 48000 stereo), whereas Wine's accepts almost any standard PCM format. Wine's new winmm relies on mmdevapi to support all sorts of formats. BTW, native's w7 winmm accepts all formats too. As a result, Wine's winmm would not work with a native mmdevapi! In other words, native has a much more elaborate winmm->mmdevapi bridge than Wine currently does. So either Wine's IsFormatSupported is kept incompatible because Wine's winmm needs it, or the behaviour of IsFormatSupported is aligned with native's, requiring unforeseen changes to the current codebase. Here are the results of my experiments with test bot over the week end. Note that I've only tested SHARED mode and standard formats 8000 x 1|2 x 8|16 WAVE_FORMAT_PCM or EXTENSIBLE PCM. - Like MSDN documents, IsFormatSupported sets ClosestMatch if and only when it returns S_FALSE. WineALSA has a bug here (that confirms my partial patch from last week). - pClosestMatch looks like what GetMixFormat returns. E.g. IsFormatSupported(8000x1x8UINT) will suggest 48000x2x32FP. I've not tested with #channels >2. - IsFormatSupported S_FALSE => Initialize AUDCLNT_E_UNSUPPORTED_FORMAT. So S_FALSE does in no way mean "it's not my favourite, but I'd do it anyway". - Presumably a bug in native: after UNSUPP_FORMAT from Initialize, another call with a format that should work yields ALREADY_INITIALIZED. - Except for 48000x2x16 and 48000x2x8, all standard PCM formats I tested yield S_FALSE, i.e. they are rejected. That means that the native mixer accepts integer formats at its nominal rate (48000), but does not even convert mono to stereo. - AUDCLNT_STREAMFLAGS_RATEADJUST is not documented by MSDN http://msdn.microsoft.com/en-us/library/dd370791%28v=VS.85%29.aspx RATEADJUST causes the win7 and most w2k8 test bots to Initialize succesfully when suplying a rate != GetMixFormat. However 48000x1x16 (mono instead of stereo) is still refused! Google found one single app that uses that flag and the associated SetRate interface. Note that SetRate does not help with mono->stereo which is still refused. Regards, Jörg Höhle

2 1

kernel32: GetVolumeInformation and FS flags
by GOUJON Alexandre 04 Aug '11

04 Aug '11

As I'm updating GetVolumeInformation to add UDF support, I noticed file system flags differ from one Windows version to another. For instance, on TestBot and NTFS I get [1] : - 000700FF for XP and W2K3 - 002700FF for Vista and W2K8 - 03E700FF for 7 Should I - not test flags, don't bother ? (hides the issue) - set only common bits ? (make everyone happy) - set the most recent values ? (as we already mark results from older windows versions as broken) - set output values depending on windows version ? (something not to in wine as I know) Is there any known application depending on an exact value ? --- [1]: https://testbot.winehq.org/JobDetails.pl?Key=13304

1 0

wined3d: incorrect OpenGL renderer string for GTX 560 Ti
by William Pettersson 04 Aug '11

04 Aug '11

In dlls/wined3d/directx.c video cards are identified by string comparisons to the OpenGL renderer string. I recently added support for the GTX 550 Ti, so I spent a bit of time perusing the code. The GTX 560 Ti is identified by the string "GeForce GTX 560 TI" but noticed that on my system, the renderer string is "GeForce GTX 550 Ti/PCI/SSE2". Note the difference in capitalisation of "TI" versus "Ti". When I added the GTX 550 Ti, I tested with both "TI" and "Ti" in the cards[] entry, and with "TI" my card is not recognised but with "Ti" wine does detect it correctly. Yes, I have a 550 and not a 560, hence I'm just asking here. I cannot confirm that the 560 renderer string has capital "TI", but google searches seem to imply that the capitalisation follows the 550 renderer, using "Ti" rather than "TI", and the advertising supports the capital-T lowercase-i version. Now, some questions. 1) Can anyone confirm that the GTX 560 Ti is detected correctly via the OpenGL renderer string, or even confirm that the OpenGL renderer string for the 560 GTX Ti has either "TI" or "Ti" as the capitalisation? 2) The capital "TI" is also used in gpu_description_table[], where it is returned as the description of video card. I don't know what Windows-based programs expect here, but I'm guessing that this possibly also should be "Ti". Is there any way I can check this? Thanks, William

2 1

Re: net: Convert to Unicode. (take 3)
by Octavian Voicu 04 Aug '11

04 Aug '11

On Thu, Aug 4, 2011 at 11:10 AM, Francois Gouget <fgouget(a)free.fr> wrote: > --- a/po/ja.po > +++ b/po/ja.po > @@ -8641,8 +8641,8 @@ msgstr "" > "---------------------------------------------------------------\n" > > #: net.rc:44 > -msgid "%s %S %S Open resources: %lu\n" > -msgstr "%s %S %S ???????????????: %lu\n" > +msgid "%s %s %s Open resources: %lu\n" > +msgstr "%s %s %s ???????????????: %lu\n" > Hello, It looks like the UTF8 characters got mangled in transit. Try sending the patch as an attachment. Octavian

1 0

Re: [2/8] dinput: Added ConfigureDevices dialog
by Alexandre Julliard 04 Aug '11

04 Aug '11

Lucas Fialho Zawacki <lfzawacki(a)gmail.com> writes: > --- > dlls/dinput/Makefile.in | 7 ++-- > dlls/dinput/configure_devices.c | 43 ++++++++++++++++++++++++++++ > dlls/dinput/configure_devices.rc | 45 ++++++++++++++++++++++++++++++ > dlls/dinput/configure_devices_resource.h | 17 +++++++++++ > dlls/dinput/dinput_main.c | 3 +- > dlls/dinput/dinput_private.h | 2 + > 6 files changed, 113 insertions(+), 4 deletions(-) > create mode 100644 dlls/dinput/configure_devices.c > create mode 100644 dlls/dinput/configure_devices.rc > create mode 100644 dlls/dinput/configure_devices_resource.h Please use more reasonable file names like config.c or resource.h. And resources that will be translated through po files should be in a file named dinput.rc so that we know which dlls they belong to. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/2] ntdll: Use swapping method to return . and .. as first entries. (try 4)
by Alexandre Julliard 04 Aug '11

04 Aug '11

Grazvydas Ignotas <notasas(a)gmail.com> writes: > - /* check if we still have enough space for the largest possible entry */ > - if (last_info && io->Information + max_dir_info_size(class) > length) > - { > - lseek( fd, 0, SEEK_SET ); /* reset pos to first entry */ > - res = 0; > - } > + filename = read_first_dent_name( swap_to, fd, next_pos, second_entry_pos, > + &de_first_two, buffer, size ); > + if (filename != NULL && (!strcmp( filename, "." ) || !strcmp( filename, ".." ))) > + filename = read_first_dent_name( swap_to ^ 1, fd, next_pos, second_entry_pos, > + &de_first_two, buffer, size ); "buffer" is the user's buffer, you can't read into that. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: cmd/tests: Add FOR /A tests
by Marvin 04 Aug '11

04 Aug '11

1 0

Possible off-by-1 in crypt32/chain.c match_common_names
by William Pettersson 04 Aug '11

04 Aug '11

Hey Juan (+list), Trying to get the new Blizzard systemcheck program working under Wine, I ran into an SSL issue. Initially the issue looked like: trace:chain:match_dns_to_subject_dn L"sea.battle.net" trace:crypt:CryptDecodeObjectEx (0x00000001, #0014, 0x14f5bc, 115, 0x00008001, (nil), 0xd1c25c, 0xd1c258) trace:crypt:CryptDecodeObjectEx returning 1 trace:crypt:CertFindRDNAttr "0.9.2342.19200300.100.1.25" 0x153fc8 trace:chain:match_common_name CN = L"*.battle.net\0000" warn:chain:match_domain_component domain component L"net" too short for L"net\0000" trace:chain:match_common_name returning 0 and resultingly I would get IRC helped point out that the "\0000" seems to be an off-by-one error in the length of a string. It seems, in match_common_name(), that allowed_len currently denotes the length of a string including the terminating NUL, but server_len doesn't include the terminating NUL. This results in comparisons not playing nice. I've tested simply by adding "allowed_len--;" and this does mean that my app now can successfully negotiate an SSL connection. I'm not really up on crypto in Wine, so I'm not sure if this actually is an off-by-one error, and if so where it should be fixed. I do think that nameAttr->Value.cbData should be used, as technically I think \0 characters in URLs are now allowed, so strlenW would not work correctly (and would be a security issue?), but then it seems the best fix is simply to just decrement allowed_len. Any thoughts or ideas on whether this is actually a bug and if so, how to fix it? William

2 1

Jump to page:

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 August 2011