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

Current state of USBD.SYS
by louis＠museresearch.com 10 Aug '11

10 Aug '11

Hi, I'm in the process of migrating custom patches made to WINE 1.1.7 to WINE 1.3.24. Among those is USBD.SYS, which we use to run a Windows driver for a specific USB device which has no equivalent Linux driver. I was wondering what to expect from 1.3.24 as far as USB device discovery and Windows driver support goes. For example, our older patched version ties into Linux HAL to find devices, but there doesn't *appear* to be the same functionality in this newer stock version. Does anyone know what the goal of usbd.sys is in WINE 1.3.24? Also what I'd like to find out is if there is maybe a cutting-edge usbd.sys module that hasn't made it into the development WINE branch. Anyway, thanks for your time and any help is greatly appreciated, as always. -Louis

2 2

[PATCH] winealsa.drv: Fix AudioRenderClient write pointer calculation
by Joerg-Cyril.Hoehle＠t-systems.com 10 Aug '11

10 Aug '11

Hi, The buffering code in winealsa & wineoss is still very complex and I've had a hard time following it. Because of the complexity, it's potentially error-prone. Here's an error: Consider this sequence of calls: BufferSize 100 GetBuffer(80) Release(80) pcm_write(50) => offs = 50, held = 30 (80-50) GetBuffer(30) (max 70) =>LOCKED_WRAPPED (because pos 80 + 30 is > 100) Release(30) => wrap_buffer 20 at end & 10 at beginning => offs = 50, held = 60 (note offs+held > 100) GetBuffer(10) (max 40) =>LOCKED_NORMAL (fits into primary) Release(10) =>computes buffer = offs+held = 50+60 = 110 > 100! =>illegal memory access An easy fix would be to correct buffer = This->local_buffer + + (This->lcl_offs_frames + This->held_frames) * This->fmt->nBlockAlign; into (offs+held %buffer_size) However are we sure that's all? I'd love to see the code as understandable as winecoreaudio (although I know there need be more state variables to handle the two buffers). Precisely because winecoreaudio is more readable I was able to fix the Get/ReleaseBuffer ordering issue, while ALSA and OSS are still waiting (waiting too for another patch to have GetCurrentPadding simply return held_frames on top of it). IOW, the winecoreaudio driver is the best of the three, receiving fixes written easily, while ALSA and OSS are lagging behind because it's tedious to patch them correctly. Regards, Jörg Höhle

1 0

Best way to get Program Files/Common Files?
by Lucas Zawacki 09 Aug '11

09 Aug '11

I need to get the user configured path to Program Files/Common Files to save the dinput action mapping settings. What are the my options for doing this? One way I found is the SHGetSpecialFolderPath function, but it requires me to link to shell32 and I suspect there's a better way. Thanks

3 3

GSoC: dinput8 Action Mapping - dialog testing
by Marcus Meissner 09 Aug '11

09 Aug '11

On Tue, Aug 02, 2011 at 06:25:49PM -0300, Lucas Zawacki wrote: > Hello. I need some help here. > > Before commiting the ConfigureDevices patches tried to add a couple > simple tests for the function, the problem is that I now have to test > a dialog. What is the best way to do it? I'm thinking of creating > another thread and sending the desired messages to the dialog, is that > a good option? I'm open to suggestions. This is over my head... There are some dlls that test dialogs, like dlls/comdlg32/tests but it does not seem obvious how they do it. (I unthreaded this e-mail so more people can read it ... Perhaps post new stuff in new e-mail threads for more comments.) Ciao, Marcus

3 3

[rfc] WINE_ONCE macro
by Dan Kegel 09 Aug '11

09 Aug '11

There are many places in the wine source that use a static to print a fixme just once. Here's a simple macro that combines declaring and testing the static. Thoughts? diff --git a/include/wine/debug.h b/include/wine/debug.h index ba6fabe..3112401 100644 --- a/include/wine/debug.h +++ b/include/wine/debug.h @@ -250,6 +250,8 @@ static inline const char *wine_dbgstr_longlong( ULONGLONG ll ) #define WINE_DPRINTF wine_dbg_printf #define WINE_MESSAGE wine_dbg_printf +#define WINE_ONCE(s) { static int once; if (!once++) s; } + #ifdef __WINESRC__ /* Wine uses shorter names that are very likely to conflict with other software */ @@ -276,6 +278,8 @@ static inline const char *debugstr_w( const WCHAR *s ) { return wine_dbgstr_wn( #define ERR_(ch) WINE_ERR_(ch) #define ERR_ON(ch) WINE_ERR_ON(ch) +#define ONCE(s) WINE_ONCE(s) + #define DPRINTF WINE_DPRINTF #define MESSAGE WINE_MESSAGE And here's an example of its use: diff --git a/dlls/msvcr90/msvcr90.c b/dlls/msvcr90/msvcr90.c index fd24f11..af75095 100644 --- a/dlls/msvcr90/msvcr90.c +++ b/dlls/msvcr90/msvcr90.c @@ -310,9 +310,7 @@ int CDECL _atoflt( _CRT_FLOAT *value, char *str ) DEFINE_THISCALL_WRAPPER(MSVCRT_type_info_name_internal_method,8) const char * __thiscall MSVCRT_type_info_name_internal_method(type_info * _this, struct __type_info_node *node) { - static int once; - - if (node && !once++) FIXME("type_info_node parameter ignored\n"); + if (node) ONCE(FIXME("type_info_node parameter ignored\n")); if (!_this->name) {

3 3

Re: wldap32/tests: Skip tests if ldap_init failed (try 3)
by Hans Leidekker 09 Aug '11

09 Aug '11

On Tue, 2011-08-09 at 19:31 +0200, André Hentschel wrote: > diff --git a/dlls/wldap32/tests/parse.c b/dlls/wldap32/tests/parse.c > index 4cf8564..ed37d88 100644 > --- a/dlls/wldap32/tests/parse.c > +++ b/dlls/wldap32/tests/parse.c > @@ -128,7 +128,11 @@ START_TEST (parse) > LDAP *ld; > > ld = ldap_initA((char *)"ldap.itd.umich.edu", 389 ); > - ok( ld != NULL, "ldap_init failed\n" ); > + if (!ld) > + { > + skip("ldap_init failed, skipping tests\n"); > + return; > + } > > test_ldap_parse_sort_control( ld ); > test_ldap_search_extW( ld ); If it fails on Wine it's probably because LDAP development files were not present at build time. I'm not sure if we want to hide this failure though, applications may expect ldap_init to succeed.

3 2

Re: wldap32/tests: Skip tests if ldap_init failed
by Hans Leidekker 09 Aug '11

09 Aug '11

On Tue, 2011-08-09 at 19:17 +0200, André Hentschel wrote: > diff --git a/dlls/wldap32/tests/parse.c b/dlls/wldap32/tests/parse.c > index 4cf8564..faad474 100644 > --- a/dlls/wldap32/tests/parse.c > +++ b/dlls/wldap32/tests/parse.c > @@ -128,7 +128,11 @@ START_TEST (parse) > LDAP *ld; > > ld = ldap_initA((char *)"ldap.itd.umich.edu", 389 ); > - ok( ld != NULL, "ldap_init failed\n" ); > + if (!ld) > + { > + win_skip("ldap_init failed, skipping tests\n"); > + return; > + } > > test_ldap_parse_sort_control( ld ); > test_ldap_search_extW( ld ); Do you see it fail on Windows?

2 1

Re: Bug #27975 and one small change
by Frédéric Delanoy 09 Aug '11

09 Aug '11

2011/8/8 Adam Stachowicz <saibamenppl(a)gmail.com>: > From f91549a682b52b77853b53a475011c7869f861b2 Mon Sep 17 00:00:00 2001 > From: Saibamen <saibamenppl(a)gmail.com> > Date: Mon, 8 Aug 2011 15:43:48 +0200 > Subject: Resize control to allow wider string of polish translator and bug > 27975 Please see http://wiki.winehq.org/SubmittingPatches for how to submit in the correct patch format. Frédéric

2 3

Re: [1/4] explorer: implement the explorer using IExplorerBrowser (try 3)
by Austin English 08 Aug '11

08 Aug '11

On Sat, Jun 11, 2011 at 14:42, Jay Yang <jkelleyy(a)gmail.com> wrote: > --- > configure.ac | 2 +- > programs/explorer/Makefile.in | 6 +- > programs/explorer/explorer.c | 208 ++++++++++++++++++++++++++++++----------- > programs/explorer/explorer.rc | 26 +++++ > programs/explorer/resource.h | 26 +++++ > 5 files changed, 213 insertions(+), 55 deletions(-) > create mode 100644 programs/explorer/explorer.rc > create mode 100644 programs/explorer/resource.h Introduced a regression, see http://bugs.winehq.org/show_bug.cgi?id=28029. -- -Austin

1 0

bugzilla: merge OS X/Windows OS versions
by Austin English 08 Aug '11

08 Aug '11

This was mentioned a while back, though I can't find the reference on wine-devel, perhaps it was in #winehackers... Anyway, would anyone be opposed to merging the Mac OS X versions (and possibly the Windows versions) in the OS field in Bugzilla? We don't differentiate any other OS, and for Windows, there are very few bugs filed anyway (mostly against the test suite or building on cygwin). So, instead of: Windows 3.1 Windows 95 Windows 98 Windows ME Windows 2000 Windows NT Windows XP Windows Vista Mac OS X 10.2 Mac OS X 10.3 Mac OS X 10.4 Mac OS X 10.5 Mac OS X 10.6 We'd have: Windows (All versions) Mac OS X I meant to do this a while ago, but forgot, and http://bugs.winehq.org/show_bug.cgi?id=27930 reminded me -- -Austin

2 2