August 2011 - Wine-Devel - list.winehq.org

w9x testbot state?
by Joerg-Cyril.Hoehle＠t-systems.com Aug. 8, 2011

Aug. 8, 2011

Hi, what happened to the w9x test bots? I'd like them to run some kernel32 tests. Testbot says "offline". Thank you for your help, Jörg Höhle

8 15

re: make "bisected" a keyword in bugzilla?
by Dan Kegel Aug. 8, 2011

Aug. 8, 2011

I think it's a good idea. 'regression' isn't as strong as 'bisected'. Unless there are objections, I'll add the keyword on Monday.

11 15

mmdevapi: playing silence is introducing delays
by Joerg-Cyril.Hoehle＠t-systems.com Aug. 8, 2011

Aug. 8, 2011

Hi, Andrew Eikum replied: >> - Questionable use of BUFFERFLAGS_SILENT in WOD_PushData. When no data >> is available now, the buffer is flooded with silence, hence data >> submitted shortly afterwards will be delayed by as much (PulseAudio >> will accumulate 2 seconds of buffer data...), not by a minimal amount. >Are you sure? BUFFERFLAGS_SILENT shouldn't silence the whole buffer, >just insert avail_frames worth of silence, which is what was intended. >We should only accumulate 2 seconds if there is a 2 second underrun from >WinMM's client. That seems like sane behavior to me. I opened issue #27937 which is related. This may surprise people, but I argue that winmm and mmdevapi (in rendering mode) have *no* notion of underrun. Therefore there's nothing like "insert avail_frames of silence, which was intended" there. - Send no data to winmm, and it will play nothing (silence). Send data again and it will start immediately (modulo HW period size). The API doesn't even tell you that a HW underrun occurred. You notice it indirectly when all your wave headers are returned... - mmdevapi in SHARED MODE implements a mixer. Send it no data and it will mix that with all other currently playing sounds, possibly optimizing the case when no app sends any sound. Start sending data again and I *bet* it'll start immediately (modulo 10ms as the native mixer seems to operate in chunks that size). GetCurrentPadding of zero is an indirect indicator that an underrun likely happened (some data may still be buffered with USB devices...) This is radically different from ALSA! Stop sending data for 10 seconds, and you need to either - restart or - quickly send 11 seconds worth of data, of which the first 10 will be ignored by ALSA!! Watch avail_update grow and snd_pcm_delay decrease towards minus infinity (modulo 32bit) while this happens... -- I wonder if that alone can explain a few issues in bugzilla where no sound is heard -- You can even pump the late data in chunks much larger than buffer size! e.g. 10MB Alternatively use snd_pcm_forward. It is only after you filed the gap that subsequent data will be fed to the speakers again and you are returned to normal mode where you can't write more than buffer_size and avail_update < buffer_size. OTOH, mmdevapi capture mode has that glitch flag. But I wasn't talking about capture here. All in all, I think ALSA's behaviour is good for sync'ing audio with video but otherwise quite surprising. That's why I argue that playing silence in mmdevapi is introducing delays that don't exist with native. Regards, Jörg Höhle

1 3

Re: [PATCH 8/8] ddraw: Avoid double increases of wined3d references.
by Henri Verbeet Aug. 8, 2011

Aug. 8, 2011

2011/8/8 Ričardas Barkauskas <rbarkauskas(a)codeweavers.com>: > > While normaly this shouldn't even happen, it is distracting when it does. You can't change ddraw_surface_add_iface() without also changing surface creation. IIRC the surface is created with references to both the surface and the texture. I guess keeping a reference to just one of them would work because of the little shared refcount dance wined3d surfaces do, but I think I'd prefer to keep that a detail of the wined3d implementation. However, do note that ddraw_surface_release_iface() only releases one of them. I think that may be wrong.

1 0

Re: [PATCH 7/8] ddraw: Fix SetTexture reference count behaviour.
by Stefan Dösinger Aug. 8, 2011

Aug. 8, 2011

On Monday 08 August 2011 00:26:38 Ričardas Barkauskas wrote: > + hr = wined3d_device_get_texture(This->wined3d_device, stage, &wined3d_texture); This will cause problems when the application is recording a stateblock. In this case set_texture will apply the texture in the update stateblock and get_texture will return the value from the main stateblock. I feel kinda sorry for you, but I am afraid fixing this properly will require a lot of work, starting with testing d3d7 stateblock behavior wrt refcounting. In the worst case fixing this might require re-implementing some of the stateblock logic in ddraw. Also make sure to test SetRenderTarget. In d3d8/9 the render target is not recorded in the stateblock, so there's no issue. d3d7 may be different. Unfortunately we have zero stateblock tests for d3d7. There's also SetCurrentViewport that addrefs, but IDirect3DDevice3 doesn't support stateblocks, so it is not an issue. The really crappy thing, and that's where my sorry feeling comes from, is that I haven't seen any application yet that uses d3d7's stateblocks. But I'm afraid if we want to stop the fix one app, regress another app problem we have with ddraw we'll have to do this properly and not hope no app ever runs into this.

2 1

Re: [PATCH 6/8] ddraw: Do not create implicit depth buffer.
by Henri Verbeet Aug. 8, 2011

Aug. 8, 2011

2011/8/8 Ričardas Barkauskas <rbarkauskas(a)codeweavers.com>: > - localParameters.EnableAutoDepthStencil = TRUE; > + localParameters.EnableAutoDepthStencil = FALSE; > localParameters.AutoDepthStencilFormat = WINED3DFMT_D16_UNORM; As Stefan mentioned on IRC, you should probably set the format to 0 / WINED3DFMT_UNKNOWN. I wouldn't be opposed to zeroing localParameters and only initializing fields that should be non-zero either though. That would get rid of about half of the fields. > + assert(FALSE); > return D3D_OK; > } Asserts don't do much on non-debug builds, so you probably want to at least return something like E_NOTIMPL. An ERR would probably be more descriptive than assert(FALSE), but it's probably mostly just personal preference.

1 0

Re: [PATCH 3/8] ddraw: Don't allow setting palette on non root surfaces.
by Henri Verbeet Aug. 8, 2011

Aug. 8, 2011

2011/8/8 Ričardas Barkauskas <rbarkauskas(a)codeweavers.com>: > We could also do this in wined3d, though I'm not sure if that would be much of an advantage. Also, does this imply that other miplevels should look at the base level to get their palette? I don't think we currently do this. How does this work for cube textures?

1 0

Re: Bug #27975 and one small change
by Vincent Povirk Aug. 8, 2011

Aug. 8, 2011

Changes must be in patch form. See http://wiki.winehq.org/SubmittingPatches 2011/8/7 Adam Stachowicz <saibamenppl(a)gmail.com>: > Welcome. > > This is full file of dlls\inetcpl.cpl\cpl_Pl.rc: > > /* > * Internet control panel applet > * > * Copyright 2010 Łukasz Wojniłowicz > * > * This library is free software; you can redistribute it and/or > * modify it under the terms of the GNU Lesser General Public > * License as published by the Free Software Foundation; either > * version 2.1 of the License, or (at your option) any later version. > * > * This library is distributed in the hope that it will be useful, > * but WITHOUT ANY WARRANTY; without even the implied warranty of > * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > * Lesser General Public License for more details. > * > * You should have received a copy of the GNU Lesser General Public > * License along with this library; if not, write to the Free Software > * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > * > */ > > #include "inetcpl.h" > > LANGUAGE LANG_POLISH, SUBLANG_DEFAULT > > /* "General" propsheet */ > IDD_GENERAL DIALOG 0, 0, 320, 220 > STYLE WS_CAPTION | WS_CHILD | WS_DISABLED > FONT 8, "MS Shell Dlg" > CAPTION "Ogólne" > BEGIN > > GROUPBOX " Strona domowa ", IDC_STATIC, 4, 4, 312, 52 > LTEXT "Możesz wybrać adres strony, która będzie twoją stroną > domową.", > IDC_STATIC, 58, 10, 252, 10 > EDITTEXT IDC_HOME_EDIT, 58, 22, 252, 12, WS_VISIBLE | ES_AUTOHSCROLL > PUSHBUTTON "Użyj &bieżącej", IDC_HOME_CURRENT, 58, 36, 80, 14 > PUSHBUTTON "Użyj d&omyślnej", IDC_HOME_DEFAULT, 144, 36, 80, 14 > PUSHBUTTON "Użyj pu&stej", IDC_HOME_BLANK, 230, 36, 80, 14 > GROUPBOX " Historia przeglądania ", IDC_STATIC, 4, 60, 312, 46 > LTEXT "Możesz usunąć przechowywane strony, ciasteczka i inne > dane.", > IDC_STATIC, 58, 72, 252, 10 > PUSHBUTTON "&Usuń pliki...", IDC_HISTORY_DELETE, 144, 86, 80, 14 > PUSHBUTTON "Ustawie&nia...", IDC_HISTORY_SETTINGS, 230, 86, 80, 14 > > END > > /* "Delete browsing history" dialog */ > IDD_DELETE_HISTORY DIALOG 0, 0, 250, 250 > STYLE DS_MODALFRAME | WS_CAPTION | WS_SYSMENU > FONT 8, "MS Shell Dlg" > CAPTION "Usuwanie historii przeglądania" > BEGIN > > AUTOCHECKBOX "Tymczasowe pliki internetowe\nKopie stron sieci Web, > obrazów i certyfikatów.", > IDC_DELETE_TEMP_FILES, 10, 8, 230, 30, BS_TOP | > BS_MULTILINE > AUTOCHECKBOX "Pliki cookies\nPliki przechowywane na komputerze przez > witryny sieci Web w celu zapisania preferencji takich jak informacje > logowania.", > IDC_DELETE_COOKIES, 10, 38, 230, 30, BS_TOP | > BS_MULTILINE > AUTOCHECKBOX "Historia\nLista odwiedzonych witryn sieci Web.", > IDC_DELETE_HISTORY, 10, 68, 230, 30, BS_TOP | > BS_MULTILINE > AUTOCHECKBOX "Dane formularzy\nZapisane informacje, które zostały > wpisane w formularzach.", > IDC_DELETE_FORM_DATA, 10, 98, 230, 30, BS_TOP | > BS_MULTILINE > AUTOCHECKBOX "Hasła\nHasła uzupełniane automatycznie po zalogowaniu > się do wcześniej odwiedzonej witryny Web.", > IDC_DELETE_PASSWORDS, 10, 128, 230, 30, BS_TOP | > BS_MULTILINE > DEFPUSHBUTTON "Anuluj", IDCANCEL, 185, 230, 60, 15, WS_GROUP > PUSHBUTTON "Usuń", IDOK, 120, 230, 60, 15, WS_GROUP > > END > > /* "Security" propsheet */ > IDD_SECURITY DIALOG 0, 0, 320, 220 > STYLE WS_CAPTION | WS_CHILD | WS_DISABLED > FONT 8, "MS Shell Dlg" > CAPTION "Bezpieczeństwo" > BEGIN > > CONTROL "Listview", IDC_SEC_LISTVIEW, "SysListView32", > LVS_ICON | LVS_ALIGNLEFT | LVS_AUTOARRANGE | LVS_SINGLESEL | > LVS_SHOWSELALWAYS | WS_BORDER | WS_VSCROLL, > 4, 4, 312, 58 > LTEXT "", IDC_SEC_ZONE_INFO, 4, 68, 312, 20 > GROUPBOX "", IDC_SEC_GROUP, 4, 88, 312, 126 > CONTROL "trackbar", IDC_SEC_TRACKBAR, "msctls_trackbar32", > TBS_VERT | TBS_AUTOTICKS | TBS_BOTH | TBS_REVERSED, 8, 98, > 32, 100 > LTEXT "", IDC_SEC_LEVEL, 48, 102, 180, 12 > LTEXT "", IDC_SEC_LEVEL_INFO, 48, 114, 260, 80 > END > > /* "Content" propsheet */ > IDD_CONTENT DIALOG 0, 0, 320, 220 > STYLE WS_CAPTION | WS_CHILD | WS_DISABLED > FONT 8, "MS Shell Dlg" > CAPTION "Zawartość" > BEGIN > > GROUPBOX " Certyfikaty ", IDC_STATIC, 4, 4, 312, 50 > LTEXT "Certyfikaty są używane do twojej osobistej identyfikacji > oraz do identyfikacji wydawców i urzędów certyfikujących.", > IDC_STATIC, 58, 14, 252, 18 > PUSHBUTTON "Certyfikaty...", IDC_CERT, 146, 34, 80, 14 > PUSHBUTTON "Wydawcy...", IDC_CERT_PUBLISHER, 230, 34, 80, 14 > > END > > > This fixes bug http://bugs.winehq.org/show_bug.cgi?id=27975 > > And this small change in dlls\comdlg32\cdlg_Pl.rc: > > Line 112: > RADIOBUTTON "W po&ziomie", rad4, 50, 115, 40, 12 > > change this to: > > RADIOBUTTON "W po&ziomie", rad4, 50, 115, 48, 12 > > > Greetings. > > Adam "Saibamen" Stachowicz > ReactOS Forum Moderator and Polish translator > > > >

1 0

Re: [1/2] user32/tests: Test what happens to a WM_QUIT posted to a window that gets destroyed.
by Marvin Aug. 7, 2011

Aug. 7, 2011

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=13344 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

2 1

Printing fixme's once (was: Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9)
by Dan Kegel Aug. 7, 2011

Aug. 7, 2011

Stefan wrote: > I think there was once a discussion about a FIXME_ONCE macro that took care of this. not sure what happened with that idea. Judging by http://source.winehq.org/git/wine.git/commitdiff/45ead7fe85e7107de91bd79a8c…, Alexandre's preferred idiom is static BOOL fixme_once; ... if(!fixme_once++) FIXME("Report bug to Aunt Tilly\n"); It occurs to me that #define WINE_ONCE(s) { static int once; if (!once++) s; } might suffice; you could then write WINE_ONCE(FIXME("Report bug to Aunt Tilly\n")); The previous attempt was more complicated: http://marc.info/?l=wine-devel&m=129396741411607&w=2 - Dan

2 1

Re: [5/5] shlwapi/tests: Test return value of StrFromTimeInterval with cchMax set to 0 (try2)
by Marvin Aug. 6, 2011

Aug. 6, 2011

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=13371 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

2 1

Re: [4/5] shlwapi/tests: Test for an unchanged buffer when cchMax=0 in StrFromTimeInterval
by Marcus Meissner Aug. 6, 2011

Aug. 6, 2011

On Sat, Aug 06, 2011 at 06:54:48AM -0700, Scott Ritchie wrote: > --- > dlls/shlwapi/tests/string.c | 15 +++++++++++++++ > 1 files changed, 15 insertions(+), 0 deletions(-) > > > diff --git a/dlls/shlwapi/tests/string.c b/dlls/shlwapi/tests/string.c > index 68028d7..ecc58cc 100644 > --- a/dlls/shlwapi/tests/string.c > +++ b/dlls/shlwapi/tests/string.c > @@ -615,6 +615,14 @@ static void test_StrFromTimeIntervalW(void) > result->return_value, ret); > ok(!strcmp(result->time_interval, szBuff), "Formatted %d %d wrong\n", > result->ms, result->digits); > + > + /* Test with 0 parameter, this should not change the buffer */ > + MultiByteToWideChar(0,0,"dontchange",-1,szBuffW,sizeof(szBuffW)); /sizeof(szBuffW[0]) missing. Ciao, Marcus

2 1

Re: configure: Disable gstreamer support if headers are not compatible with build environment. (try 2)
by Alex Villacís Lasso Aug. 6, 2011

Aug. 6, 2011

El 02/08/11 17:38, Octavian Voicu escribió: > When building a 32-bit wine in a 64-bit build environment with > default glib headers (gstreamer uses glib.h), glib 64-bit types > (such as gint64 and guint64) are not properly defined, causing > many compiler warnings and most likely a broken winegstreamer.dll. > > Although both gstreamer and glib are included in the ia32-libs > package (on Ubuntu, and possibly others), the lack of a proper > glibconfig.h makes the gstreamer headers unusable for 32-bit > builds. My build system is a Fedora 14 x86_64, and I am affected by this. What is really happening is that, on my 64-bit system, both glib2-devel.i686 and glib2-devel.x86_64 are installed: [alex(a)srv64 wine-build]$ rpm -qf /usr/lib64/glib-2.0/include/glibconfig.h glib2-devel-2.26.0-2.fc14.x86_64 [alex(a)srv64 wine-build]$ rpm -qf /usr/lib/glib-2.0/include/glibconfig.h glib2-devel-2.26.0-2.fc14.i686 [alex(a)srv64 wine-build]$ Instead of shipping a single header file that uses compiler or preprocessor defines, like /usr/include/stdint.h, glib2 ships two include files, one for each architecture. The pkg-config --cflags option does not handle the concept of an architecture-dependent include file correctly (or at all), so it ends up reporting the 64-bit header even for the 32-bit build. The 32-bit header defined gint64 as signed long long, but it is defined as signed long in the 64 bit header. Therefore the bug. A workaround I am testing is to force PKG_CONFIG_PATH to the 32-bit directory for the configure and make steps: [alex(a)srv64 wine-build]$ pkg-config --cflags gstreamer-app-0.10 -pthread -I/usr/include/gstreamer-0.10 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/libxml2 [alex(a)srv64 wine-build]$ PKG_CONFIG_PATH=/usr/lib/pkgconfig pkg-config --cflags gstreamer-app-0.10 -pthread -I/usr/include/gstreamer-0.10 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 [alex(a)srv64 wine-build]$ Is there any standard/known way of automating this?

2 2

Re: [PATCH] gdi32: Avoid uninitialized fields in dst and src (Coverity)
by Octavian Voicu Aug. 6, 2011

Aug. 6, 2011

On Sat, Aug 6, 2011 at 1:06 PM, Marcus Meissner <marcus(a)jet.franken.de>wrote: > src.visrect.left = src.x = 0; > src.visrect.top = src.y = 0; > These two lines become redundant after your patch. Octavian

1 0

Re: [2/2] user32: When destroying a window, preserve the first WM_QUIT message that was posted to it.
by Marvin Aug. 5, 2011

Aug. 5, 2011

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=13345 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

1 0

Vacation
by Alexandre Julliard Aug. 5, 2011

Aug. 5, 2011

Folks, There won't be any commits for a while, since I'll be on vacation for the next two weeks. Also release 1.3.27 will be 3 weeks from now instead of 2. I hope you can all survive the commit withdrawal... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: kernel32: Implement K32GetProcessImageFileNameA().
by Marvin Aug. 5, 2011

Aug. 5, 2011

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=13315 Your paranoid android. === WVISTAADM (32 bit psapi_main) === psapi_main.c:110: Test failed: cbNeeded=100 === W2K8SE (32 bit psapi_main) === psapi_main.c:110: Test failed: cbNeeded=100 === W7PRO (32 bit psapi_main) === psapi_main.c:110: Test failed: cbNeeded=96 === W7PROX64 (32 bit psapi_main) === psapi_main.c:110: Test failed: cbNeeded=108

3 2

Re: [PATCH 1/3] ntdll: NtCancelIoFile(Ex) enters a nonaleratable wait state instead of an alertable one, this allows system apcs to run but blocks user apcs
by Alexandre Julliard Aug. 5, 2011

Aug. 5, 2011

Bernhard Loos <bernhardloos(a)googlemail.com> writes: > --- > dlls/ntdll/file.c | 4 ++-- > dlls/ntdll/tests/file.c | 8 ++++---- > 2 files changed, 6 insertions(+), 6 deletions(-) The whole point of the wait is to run user APCs... -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH] kernel32: Create(Named)Pipe uses an nonalertable io mode
by Alexandre Julliard Aug. 5, 2011

Aug. 5, 2011

Bernhard Loos <bernhardloos(a)googlemail.com> writes: > @@ -37,7 +37,11 @@ > static HANDLE alarm_event; > static BOOL (WINAPI *pDuplicateTokenEx)(HANDLE,DWORD,LPSECURITY_ATTRIBUTES, > SECURITY_IMPERSONATION_LEVEL,TOKEN_TYPE,PHANDLE); > +static DWORD WINAPI (*pQueueUserAPC)(PAPCFUNC pfnAPC, HANDLE hThread, ULONG_PTR dwData); > > +static void CALLBACK user_apc(ULONG_PTR param) > +{ > +} That doesn't really test anything. You should check if it's being called in various places. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH 1/2] wscript: skip some tests on wow64 (resend)
by Michał Ziętek Aug. 5, 2011

Aug. 5, 2011

I skipped them because of filesystem redirection on wow64 which makes GetSystemDirectory and SearchPath return the wrong values. How can I solve this problem?

2 1

Re: ieframe: Moved intshcut.c tests to ieframe
by Marvin Aug. 5, 2011

Aug. 5, 2011

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 Aug. 5, 2011

Aug. 5, 2011

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 Aug. 4, 2011

Aug. 4, 2011

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 Aug. 4, 2011

Aug. 4, 2011

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 Aug. 4, 2011

Aug. 4, 2011

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