October 2009 - Wine-devel - list.winehq.org

meaning of "Hardware" field in bugzilla?
by Dan Kegel 13 Dec '09

13 Dec '09

Does "mac" mean "powerpc mac only"? I rather thought it meant "apple macintosh", regardless of cpu. I ask because Austin has just gone through and changed lots of "mac" bugs to "pc" even though the bugs were on Intel macs, which just seems wrong.

8 8

libsmbclient and wine?
by Dan Kegel 07 Nov '09

07 Nov '09

Hi folks, it's often been said that wine can't use libsmbclient because of license problems. I'd like to look at that assumption a bit. - What would wine like to use libsmbclient for, if it could? - Would it suffice to just link it in to wineserver, or would it need to be invoked directly by all sorts of dlls? - Would we just use the system's libsmbclient (I hope so) rather than trying to import its source? Also, fwiw, I think the Samba guys are willing to multiplex their listening daemon so Wine could handle incoming named pipe requests if we want to. Thanks, Dan

3 2

Re: mshtml/tests: Fix events test when pointer is on a corner.
by Jacek Caban 04 Nov '09

04 Nov '09

Hi Nicolas, Nicolas Le Cam wrote: > Hi, > > Since commit 8272ecd3f2235b923f2ec67bb51d051bdfbf466f I'm having > errors on events tests. > > I just found that it only fails if pointer is on any corner. As I'm > always putting it on upper right corner when running winetest it was > always failing for me. > > Minimizing the test window fixed it for me. > Tested on Win2k SP4 and WinXP SP2 (both with IE6). > Minimizing window changes what we test and will break test interactive mode. We should change tests to accept cursor in left corner. Thanks, Jacek

2 4

Playing ULAW sample correctly?
by Joerg-Cyril.Hoehle＠t-systems.com 04 Nov '09

04 Nov '09

Hi, Using the MCI, I've successfully played an ADPCM sample from Wikipedia, except at the very end of IMA ADPCM play: fixme:wavemap:wodWrite Not all src buffer has been written, expect bogus sound After play status length increased from 13813 to 13826! How comes? However, playing an ULAW sample, the same message occurs constantly (apparently once for each wavehdr played) and the sound is awfully chopped. The error could be anywhere (MCI, WAVE_MAPPER, gsm711 ACM, waveaudio ...). Are there audio tests in Wine beside winmm/wave.c? How is ulaw / how are the msacm/gsm711/gsm722/gsm602 tested? Does anybody know whether ULAW works in Wine? (Any app that uses it outside of MCI?) Thanks, Jörg Höhle

5 7

Re: [PATCH 0/3] Handling DOS drives in mountmgr (try 2)
by Charles Davis 03 Nov '09

03 Nov '09

Charles Davis wrote: > Hi, > > This patch series moves drive handling over to mountmgr. Mountmgr will > now associate UNIX device files directly to its created devices instead > of having ntdll handle converting something like \??\D: to > $WINEPREFIX/dosdevices/d::. This way, we can implement storage I/O > controls in mountmgr instead of ntdll, while the storage I/O controls > already in ntdll continue to work. > > It also allows drivers to associate UNIX device files to their device > objects, paving the way for separating the driver code from ntdll. > > Since nobody's said anything about my patches, I'll have to assume > they're good. (They work for me.) > > Chip > > I thought I fixed all the issues. What's wrong with my patches now? Chip

2 4

Re: dlls/winex11.drv/dib.c: initialize two warnings (RESEND)
by Alexandre Julliard 01 Nov '09

01 Nov '09

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > I looked into this in more detail, and now remember why I couldn't > do this. > > From X11DRV_GetDIBits() we invoke DIB_GetBitmapInfo() with these > two variables being passed by addresses which in turns forwards to > DIB_GetBitmapInfoEx(). And there we have a default case of > > ERR("(%d): unknown/wrong size for header\n", header->biSize ); > return -1; > > where indeed height and width are not initialized, so GCC 4.5 is right. No, because the error case causes the caller function to return without using them. The idea was to reorder the code so that gcc can figure this out, as it does already in the other cases. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Generate a WM_MOUSEMOVE event when warping the mouse
by Vitaliy Margolen 31 Oct '09

31 Oct '09

JesusFreke wrote: > --- > dlls/winex11.drv/mouse.c | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/dlls/winex11.drv/mouse.c b/dlls/winex11.drv/mouse.c > index 60351e5..7c24c64 100644 > --- a/dlls/winex11.drv/mouse.c > +++ b/dlls/winex11.drv/mouse.c > @@ -1004,6 +1004,7 @@ BOOL CDECL X11DRV_SetCursorPos( INT x, INT y ) > XFlush( display ); /* avoids bad mouse lag in games that do their own mouse warping */ > cursor_pos = pt; > wine_tsx11_unlock(); > + queue_raw_mouse_message( WM_MOUSEMOVE, NULL, x, y, 0, GetCurrentTime(), 0, 0 ); > return TRUE; > } > Can you explain why do you need this patch? What exactly is it fixing? And have you run any tests to verify this? I'm guessing no, because you ignored that Wine will generate mouse-move event when this operation comes back to Wine from X server.

3 3

mciwave: need to serialize record and play
by Joerg-Cyril.Hoehle＠t-systems.com 31 Oct '09

31 Oct '09

Eric, I've not yet tested your patches but I thought to additionaly use STATUS_NOT_READY as an intermittent marker for work in progress, so other threads know something is going on and don't pull the carpet under the feet. What do you think? E.g. play; play from 0; play from 1000; play from 0; seek to 0; should be handled correctly (including NOTIFY ABORTED with play notify; play from 0 notify; play ... notify; seek notify). This may or may not eventually be completed by a critical section in record+play. I don't know yet. Eric, I can stop working on mciwave for the moment to avoid git conflicts and go check another D3D issue. Do you plan to work on - the record+play as well as - the 333ms issues? After the new notification system gets in play, I'll change mcimidi and mcicda. Because these are the interesting drivers, mciwave has just the advantage that it does not depend on other broken code (Timidity). BTW, I found the ADPCM and µ-law samples I use on http://en.wikipedia.org/wiki/Dct_(File_Format) Regards, Jörg Höhle.

2 3

re: Nate Gallaher : msi: Add tablename tracking to VIEW_find_column
by Dan Kegel 31 Oct '09

31 Oct '09

Hi Nate, your patch seems to have caused new valgrind warnings, could you have a look? Found via http://kegel.com/wine/valgrind/logs/2009-10-27-08.06/diff-msi_db.txt Details at http://kegel.com/wine/valgrind/logs/2009-10-27-08.06/vg-msi_db.txt Conditional jump or move depends on uninitialised value(s) at RtlFreeHeap (heap.c:1460) by msi_free (msipriv.h:1099) by VIEW_find_column (msiquery.c:82) by SELECT_AddColumn (select.c:392) by SELECT_CreateView (select.c:436) by INSERT_CreateView (insert.c:393) by sql_parse (sql.y:149) by MSI_ParseSQL (sql.y:960) by MSI_DatabaseOpenViewW (msiquery.c:137) by MsiDatabaseOpenViewW (msiquery.c:279) by MsiDatabaseOpenViewA (msiquery.c:110) by test_streamtable (db.c:1443) by func_db (db.c:8546) by run_test (test.h:535) by main (test.h:585) Uninitialised value was created by a stack allocation at VIEW_find_column (msiquery.c:60) ... 2 bytes in 1 blocks are definitely lost at notify_alloc (heap.c:214) by RtlAllocateHeap (heap.c:1421) by msi_alloc_zero (msipriv.h:1082) by table_create_new_row (table.c:1504) by TABLE_insert_row (table.c:1712) by TABLE_modify (table.c:1860) by MSI_ViewModify (msiquery.c:623) by MsiViewModify (msiquery.c:644) by test_viewmodify_delete_temporary (db.c:5892) by func_db (db.c:8570) by run_test (test.h:535) by main (test.h:585) ... 4 bytes in 1 blocks are definitely lost at notify_alloc (heap.c:214) by RtlAllocateHeap (heap.c:1421) by msi_alloc (msipriv.h:1076) by strdupW (msipriv.h:1132) by msi_create_table (table.c:664) by CREATE_execute (create.c:72) by MSI_ViewExecute (msiquery.c:462) by MsiViewExecute (msiquery.c:488) by run_query (db.c:177) by test_droptable (db.c:7073) by func_db (db.c:8580) by run_test (test.h:535) by main (test.h:585) ... 4 bytes in 1 blocks are definitely lost at notify_alloc (heap.c:214) by RtlAllocateHeap (heap.c:1421) by msi_alloc (msipriv.h:1076) by strdupW (msipriv.h:1132) by msi_makestring (table.c:943) by get_tablecolumns (table.c:1016) by table_get_column_info (table.c:608) by msi_update_table_columns (table.c:1053) by TABLE_remove_column (table.c:2040) by TABLE_drop (table.c:2293) by DROP_execute (drop.c:60) by MSI_ViewExecute (msiquery.c:462) by MsiViewExecute (msiquery.c:488) by run_query (db.c:177) by test_dbmerge (db.c:7408) by func_db (db.c:8581) by run_test (test.h:535) by main (test.h:585) ... 224 bytes in 28 blocks are definitely lost at notify_alloc (heap.c:214) by RtlAllocateHeap (heap.c:1421) by msi_alloc (msipriv.h:1076) by strdupW (msipriv.h:1132) by msi_makestring (table.c:943) by get_tablecolumns (table.c:1014) by table_get_column_info (table.c:608) by msi_update_table_columns (table.c:1053) by TABLE_remove_column (table.c:2040) by TABLE_drop (table.c:2293) by DROP_execute (drop.c:60) by MSI_ViewExecute (msiquery.c:462) by MsiViewExecute (msiquery.c:488) by run_query (db.c:177) by test_dbmerge (db.c:7385) by func_db (db.c:8581) by run_test (test.h:535) by main (test.h:585)k It also fails here: db.c:5260: Test failed: Expected ERROR_NO_MORE_ITEMS, got 0 db.c:5336: Test failed: Expected 4, got 8 db.c:5337: Test failed: Unexpected data db.c:5352: Test failed: Unexpected data db.c:5378: Test failed: Expected 64, got 68 db.c:5379: Test failed: Unexpected data db.c:6993: Test failed: Expected "", got "grape" db.c:6994: Test failed: Expected 0, got 5 db.c:7052: Test failed: Expected "", got "grape" db.c:7053: Test failed: Expected 0, got 5

2 2

Re: msvcrt: do not overlap in strcpy (valgrind) (try 2)
by Vitaliy Margolen 31 Oct '09

31 Oct '09

André Hentschel wrote: > > diff --git a/dlls/msvcrt/math.c b/dlls/msvcrt/math.c > index 010e1a6..08eaf73 100644 > --- a/dlls/msvcrt/math.c > +++ b/dlls/msvcrt/math.c > @@ -856,7 +856,7 @@ char * CDECL _ecvt( double number, int ndigits, int *decpt, int *sign ) > snprintf(data->efcvt_buffer, 80, "%.*le", prec - 1, number); > /* take the decimal "point away */ > if( prec != 1) > - strcpy( data->efcvt_buffer + 1, data->efcvt_buffer + 2); > + memmove( data->efcvt_buffer + 1, data->efcvt_buffer + 2, strlen(data->efcvt_buffer) ); You don't need additional strlen. You already have a length from snprintf (that's returned but not assigned to anything). Vitaliy.

2 2