- wine-devel - winehq.org

Re: po: Remove English strings from the Slovenian translation.
by Francois Gouget 17 Jan '12

17 Jan '12

On Tue, 17 Jan 2012, Andrej Znidarsic wrote: [...] > As I am not a very technical person, downloading/commiting with git is very > cubersome/time consuming for me. I would highly appriciate if you would be > willing to download the .po files after string freeze for 1.4, zip them, > send them to me. Then i can review them/translate what is missing, send you > back the files and you can commit them. How does that sound? Usually we prefer when authors send their patches themselves as attribution is important to us and it gets trickier when there's a middle agent. Note that you can download the latest Slovenian PO file from the following URL: http://source.winehq.org/git/wine.git/blob_plain/HEAD:/po/sl.po Given this, would the following work for you? * Create a 'po' directory and download the above sl.po file into it * Make a copy of it called 'sl.po.orig' * Update the translation in 'sl.po' * When done, run the following command to generate a patch: diff -u po/sl.po.orig po/sl.po >sl.diff * Then email the 'sl.diff' file to wine-patches. If not I can work with you and I'm sure some other solution can be arranged. We're also trying to set things up so one can go to a web site and translate Wine there which I guess would be ideal for you. But we're being blocked by attribution issues. That is the existing systems appear to be unable to track who translated what and to preserve that information when submitting the patches. So unfortunately there's no ETA for when such a system will be ready. Hopefully this email will rekindle interest in finally overcomming this issue... -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ La terre est une bêta...

2 1

Re: [PATCH 2/2] dsound: Use correct buffer wraparound logic
by Andrew Eikum 17 Jan '12

17 Jan '12

Actually, don't commit this one. On Mon, Jan 16, 2012 at 02:02:49PM -0600, Andrew Eikum wrote: > --- > dlls/dsound/mixer.c | 3 +-- > 1 files changed, 1 insertions(+), 2 deletions(-) > > diff --git a/dlls/dsound/mixer.c b/dlls/dsound/mixer.c > index 23af6ce..b35a888 100644 > --- a/dlls/dsound/mixer.c > +++ b/dlls/dsound/mixer.c > @@ -539,8 +539,7 @@ static DWORD DSOUND_MixInBuffer(IDirectSoundBufferImpl *dsb, DWORD writepos, DWO > > /* increase mix position */ > dsb->primary_mixpos += len; > - if (dsb->primary_mixpos >= dsb->device->buflen) > - dsb->primary_mixpos -= dsb->device->buflen; > + dsb->primary_mixpos %= dsb->device->buflen; > return len; > } > >

1 0

Re: [PATCH 3/5] ddraw/tests: Add a IDirect3DDevice2 GetCaps test (try 2)
by Saulius Krasuckas 16 Jan '12

16 Jan '12

* On Tue, 6 Dec 2011, Stefan Dösinger wrote: > > try 2: Add infrastructure to rerun every test with new d3d objects. > --- > dlls/ddraw/tests/d3d.c | 211 ++++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 211 insertions(+), 0 deletions(-) Hi Stefan, this is http://source.winehq.org/git/wine.git/commitdiff/7ae81ba378c1633e574f130461… The patch introduced one failure on 64-bit XP running on virtual machine with VMware SVGA II" driver v11.6.0.35: http://test.winehq.org/data/95f81d10c9c852b72c6513eca0a2d0e066457f9e/xp_wtb… http://test.winehq.org/data/1fa1ab54376bace57f78d27ac13b7229caa56a2e/xp_wtb… d3d.c:5075: Test failed: CreateDevice failed: 88760091. Platform is i386 WOW64 -- probably 64-bit XP running 32-bit Winetest: http://test.winehq.org/data/1fa1ab54376bace57f78d27ac13b7229caa56a2e/xp_wtb… Would mind having a look and fixing the failure:)? S.

2 2

winecfg: Add tab for most Direct3D registry settings.
by Stephen Chao 16 Jan '12

16 Jan '12

--- programs/winecfg/Makefile.in | 3 +- programs/winecfg/direct3d.c | 256 ++++++++++++++++++++++++++++++++++++++++++ programs/winecfg/main.c | 16 +++- programs/winecfg/resource.h | 8 ++ programs/winecfg/winecfg.h | 1 + programs/winecfg/winecfg.rc | 12 ++ 6 files changed, 294 insertions(+), 2 deletions(-) create mode 100644 programs/winecfg/direct3d.c diff --git a/programs/winecfg/Makefile.in b/programs/winecfg/Makefile.in index 0190854..1db9fec 100644 --- a/programs/winecfg/Makefile.in +++ b/programs/winecfg/Makefile.in @@ -13,7 +13,8 @@ C_SRCS = \ main.c \ theme.c \ winecfg.c \ - x11drvdlg.c + x11drvdlg.c \ + direct3d.c RC_SRCS = winecfg.rc PO_SRCS = winecfg.rc diff --git a/programs/winecfg/direct3d.c b/programs/winecfg/direct3d.c new file mode 100644 index 0000000..833999e --- /dev/null +++ b/programs/winecfg/direct3d.c @@ -0,0 +1,256 @@ +#include "winecfg.h" +#include "resource.h" +#include <wine/debug.h> + +WINE_DEFAULT_DEBUG_CHANNEL(winecfg); + +struct d3doption { + char key[64]; + char option1[64]; + char option2[64]; + char option3[64]; + char option4[64]; + char option5[64]; + char tip[2048]; +} *d3doptions; + +static const int numd3dkeys = 9; + +static void init_d3doptions(void) +{ + d3doptions = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(struct d3doption) * numd3dkeys); + + /* "auto" will be added for all options */ + /* registry options and defaults found in dlls/wined3d/wined3d_main.c */ + /* TODO: VideoPciDeviceID and VideoPciVendorID, see note in on_selection_change() */ + + strcpy(d3doptions[0].key, "VertexShaderMode"); + strcpy(d3doptions[0].option1, "none"); + strcpy(d3doptions[0].tip, "auto = hardware."); + + strcpy(d3doptions[1].key, "PixelShaderMode"); + strcpy(d3doptions[1].option1, "enabled"); + strcpy(d3doptions[1].option2, "disabled"); + strcpy(d3doptions[1].tip, "auto = enabled = hardware."); + + strcpy(d3doptions[2].key, "UseGLSL"); + strcpy(d3doptions[2].option1, "disabled"); + strcpy(d3doptions[2].tip, "auto = enabled. Needed for most modern games. May have performance increase when disabled but might not run/render properly."); + + strcpy(d3doptions[3].key, "OffscreenRenderingMode"); + strcpy(d3doptions[3].option1, "backbuffer"); + strcpy(d3doptions[3].option2, "fbo"); + strcpy(d3doptions[3].tip, "auto = fbo."); + + strcpy(d3doptions[4].key, "RenderTargetLockMode"); + strcpy(d3doptions[4].option1, "readdraw"); + strcpy(d3doptions[4].option2, "readtex"); + strcpy(d3doptions[4].tip, "auto = readtex. readdraw uses glReadPixels for reading, glDrawPixels for writing. readtex reads with glReadPixels, writes by drawing a textured quad."); + + strcpy(d3doptions[5].key, "VideoMemorySize"); + strcpy(d3doptions[5].option1, "0"); + strcpy(d3doptions[5].option2, "512"); + strcpy(d3doptions[5].option3, "1024"); + strcpy(d3doptions[5].tip, "auto = 0 = autodetect. Sets the amount of reported video memory (in megabytes). The default is a simple auto-detection based on the card type guessed from OpenGL capabilities."); + + strcpy(d3doptions[6].key, "Multisampling"); + strcpy(d3doptions[6].option1, "disabled"); + strcpy(d3doptions[6].tip, "auto = enabled."); + + strcpy(d3doptions[7].key, "StrictDrawOrdering"); + strcpy(d3doptions[7].option1, "enabled"); + strcpy(d3doptions[7].tip, "auto = disabled. This option ensures any pending drawing operations are submitted to the driver, but at a significant performance cost."); + + strcpy(d3doptions[8].key, "AlwaysOffscreen"); + strcpy(d3doptions[8].option1, "enabled"); + strcpy(d3doptions[8].tip, "auto = disabled. Use offscreen rendering for all render targets. The main effect this has is avoiding the depth buffer copy between offscreen and onscreen targets, which introduces fallbacks in some drivers and exposes bugs in others. There may be a performance hit depending on the specific driver."); +} + + +static void on_setoption(HWND dialog, WPARAM wParam) +{ + LVITEM item; + int selection; + char buffer[256]; + int index = -1; + + if(HIWORD(wParam) == CBN_SELENDOK) + { + selection = SendDlgItemMessage(dialog, IDC_D3DCOMBOVAL, CB_GETCURSEL, 0, 0); + SendDlgItemMessage(dialog, IDC_D3DCOMBOVAL, CB_GETLBTEXT, selection, (LPARAM) buffer); + } + else if(HIWORD(wParam) == CBN_EDITCHANGE) + { + SendDlgItemMessage(dialog, IDC_D3DCOMBOVAL, WM_GETTEXT, sizeof(buffer), (LPARAM) buffer); + } + + index = (int)SendDlgItemMessage (dialog, IDC_D3DCOMBOVAL, CB_GETITEMDATA, 0, 0); + WINE_TRACE("d3d index %d, setoption %s\n", index, buffer); + + set_reg_key(config_key, keypath("Direct3D\\"), d3doptions[index].key, buffer); + SendMessage(GetParent(dialog), PSM_CHANGED, (WPARAM) dialog, 0); + + item.mask = LVIF_TEXT; + item.pszText = buffer; + item.cchTextMax = lstrlen(item.pszText); + item.iItem = index; + item.iSubItem = 1; + + SendDlgItemMessage(dialog, IDC_D3DLIST, LVM_SETITEM, 0, (LPARAM) &item); +} + +static void on_selection_change(HWND dialog, HWND listview, LPNMLISTVIEW nmlistview) +{ + LVITEM item; + struct d3doption *option; + + item.iItem = nmlistview->iItem; + item.iSubItem = 1; + item.mask = LVIF_PARAM | LVIF_TEXT; + + + if (item.iItem == -1) return; + + SendMessage(listview, LVM_GETITEM, 0, (LPARAM) &item); + + WINE_TRACE("item.iItem=%d\n", nmlistview->iItem); + + option = (struct d3doption*)nmlistview->lParam; + + SetWindowText(GetDlgItem(dialog, IDC_D3DKEY), option->key); + + SendDlgItemMessage (dialog, IDC_D3DCOMBOVAL, CB_RESETCONTENT, 0, 0); + + if (option->option5[0]) SendDlgItemMessage (dialog, IDC_D3DCOMBOVAL, CB_INSERTSTRING, 0, (LPARAM)option->option5); + if (option->option4[0]) SendDlgItemMessage (dialog, IDC_D3DCOMBOVAL, CB_INSERTSTRING, 0, (LPARAM)option->option4); + if (option->option3[0]) SendDlgItemMessage (dialog, IDC_D3DCOMBOVAL, CB_INSERTSTRING, 0, (LPARAM)option->option3); + if (option->option2[0]) SendDlgItemMessage (dialog, IDC_D3DCOMBOVAL, CB_INSERTSTRING, 0, (LPARAM)option->option2); + if (option->option1[0]) SendDlgItemMessage (dialog, IDC_D3DCOMBOVAL, CB_INSERTSTRING, 0, (LPARAM)option->option1); + + /* Will have to take out "auto" for VideoPciDeviceID and VideoPciVendorID, 0xffff = autodetect */ + SendDlgItemMessage (dialog, IDC_D3DCOMBOVAL, CB_INSERTSTRING, 0, (LPARAM)"auto"); + + SendDlgItemMessage (dialog, IDC_D3DCOMBOVAL, CB_SELECTSTRING, -1, (LPARAM)item.pszText); + + /* attach d3d key index to the 0th combobox value */ + SendDlgItemMessage (dialog, IDC_D3DCOMBOVAL, CB_SETITEMDATA, 0, (LPARAM)item.iItem); + + SetWindowText(GetDlgItem(dialog, IDC_D3DTIP), option->tip); +} + +void load_d3d_registry(HWND dialog) +{ + LVITEM item, item2; + char *fromreg; + char szauto[] = "auto"; + int i; + + SendDlgItemMessage(dialog, IDC_D3DLIST, LVM_DELETEALLITEMS, 0, 0); + + for (i=0; i < numd3dkeys; i++) + { + item.mask = LVIF_TEXT | LVIF_PARAM; + item.pszText = d3doptions[i].key; + item.cchTextMax = lstrlen(item.pszText); + item.lParam = (LPARAM) &d3doptions[i]; + item.iItem = i; + item.iSubItem = 0; + + SendDlgItemMessage(dialog, IDC_D3DLIST, LVM_INSERTITEM, 0, (LPARAM) &item); + + fromreg = get_reg_key(config_key, keypath("Direct3D\\"), d3doptions[i].key, NULL); + if (fromreg == NULL) + { + /* set registry keys in case they didn't exist -- "auto" specifically */ + set_reg_key(config_key, keypath("Direct3D\\"), d3doptions[i].key, szauto); + SendMessage(GetParent(dialog), PSM_CHANGED, (WPARAM) dialog, 0); + item2.pszText = szauto; + } + else + { + item2.pszText = fromreg; + } + + item2.mask = LVIF_TEXT; + item2.cchTextMax = lstrlen(item.pszText); + item2.iItem = i; + item2.iSubItem = 1; + + SendDlgItemMessage(dialog, IDC_D3DLIST, LVM_SETITEM, 0, (LPARAM) &item2); + + HeapFree(GetProcessHeap(), 0, fromreg); + } +} + +static void init_d3dsheet(HWND dialog) +{ + char key[] = "Key"; + char val[] = "Value"; + + LVCOLUMN listColumn; + RECT viewRect; + int width; + + init_d3doptions(); + + GetClientRect(GetDlgItem(dialog, IDC_D3DLIST), &viewRect); + width = (viewRect.right - viewRect.left); + + listColumn.mask = LVCF_TEXT | LVCF_WIDTH | LVCF_SUBITEM; + listColumn.pszText = key; + listColumn.cchTextMax = lstrlen (listColumn.pszText); + listColumn.cx = 140; + + SendDlgItemMessage (dialog, IDC_D3DLIST, LVM_INSERTCOLUMN, 0, (LPARAM) &listColumn); + + listColumn.cx = width - 140; + listColumn.pszText = val; + listColumn.cchTextMax = lstrlen (listColumn.pszText); + + SendDlgItemMessage (dialog, IDC_D3DLIST, LVM_INSERTCOLUMN, 1, (LPARAM) &listColumn); +} + + +INT_PTR CALLBACK +Direct3DDlgProc (HWND hDlg, UINT uMsg, WPARAM wParam, LPARAM lParam) +{ +switch (uMsg) + { + case WM_INITDIALOG: + init_d3dsheet(hDlg); + break; + + case WM_SHOWWINDOW: + set_window_title(hDlg); + break; + + case WM_NOTIFY: + switch (((LPNMHDR)lParam)->code) + { + case LVN_ITEMCHANGED: + on_selection_change(hDlg, GetDlgItem(hDlg, IDC_D3DLIST), (LPNMLISTVIEW)lParam); + break; + case PSN_SETACTIVE: + load_d3d_registry(hDlg); + break; + case PSN_KILLACTIVE: + SetWindowLongPtr(hDlg, DWLP_MSGRESULT, FALSE); + break; + case PSN_APPLY: + apply(); + SetWindowLongPtr(hDlg, DWLP_MSGRESULT, PSNRET_NOERROR); + break; + } + case WM_COMMAND: + switch (HIWORD(wParam)) + { + case CBN_EDITCHANGE: + case CBN_SELENDOK: + on_setoption(hDlg, wParam); + break; + } + + break; + } + return 0; +} diff --git a/programs/winecfg/main.c b/programs/winecfg/main.c index 7376309..ccd59b0 100644 --- a/programs/winecfg/main.c +++ b/programs/winecfg/main.c @@ -60,7 +60,7 @@ PropSheetCallback (HWND hWnd, UINT uMsg, LPARAM lParam) return 0; } -#define NUM_PROPERTY_PAGES 7 +#define NUM_PROPERTY_PAGES 8 static INT_PTR doPropertySheet (HINSTANCE hInstance, HWND hOwner) @@ -84,6 +84,20 @@ doPropertySheet (HINSTANCE hInstance, HWND hOwner) pg++; /* + * Fill out the (Direct3D) PROPSHEETPAGE data structure + * for the property sheet + */ + psp[pg].dwSize = sizeof (PROPSHEETPAGEW); + psp[pg].dwFlags = PSP_USETITLE; + psp[pg].hInstance = hInstance; + psp[pg].u.pszTemplate = MAKEINTRESOURCEW (IDD_DIRECT3DCFG); + psp[pg].u2.pszIcon = NULL; + psp[pg].pfnDlgProc = Direct3DDlgProc; + psp[pg].pszTitle = load_string (IDS_TAB_DIRECT3D); + psp[pg].lParam = 0; + pg++; + + /* * Fill out the (Libraries) PROPSHEETPAGE data structure * for the property sheet */ diff --git a/programs/winecfg/resource.h b/programs/winecfg/resource.h index 6d9c450..826b840 100644 --- a/programs/winecfg/resource.h +++ b/programs/winecfg/resource.h @@ -45,6 +45,7 @@ #define IDS_SHELL_FOLDER 16 #define IDS_LINKS_TO 17 #define IDS_WINECFG_TITLE_APP 18 /* App specific title */ +#define IDS_TAB_DIRECT3D 19 #define IDI_WINECFG 100 #define IDD_MAINDLG 101 #define IDI_LOGO 102 @@ -54,6 +55,7 @@ #define IDD_GRAPHCFG 110 #define IDD_DLLCFG 111 #define IDD_DRIVECFG 112 +#define IDD_DIRECT3DCFG 113 #define IDD_DESKTOP_INTEGRATION 115 #define IDB_WINE_LOGO 200 #define IDC_TABABOUT 1001 @@ -197,6 +199,12 @@ #define IDC_SYSPARAM_COLOR 1416 #define IDC_SYSPARAM_FONT 1417 +/* direct3d tab */ +#define IDC_D3DLIST 1501 +#define IDC_D3DKEY 1502 +#define IDC_D3DCOMBOVAL 1503 +#define IDC_D3DTIP 1504 + #define IDC_SYSPARAMS_BUTTON 8400 #define IDC_SYSPARAMS_BUTTON_TEXT 8401 #define IDC_SYSPARAMS_DESKTOP 8402 diff --git a/programs/winecfg/winecfg.h b/programs/winecfg/winecfg.h index 1959409..6775707 100644 --- a/programs/winecfg/winecfg.h +++ b/programs/winecfg/winecfg.h @@ -88,6 +88,7 @@ INT_PTR CALLBACK LibrariesDlgProc (HWND hDlg, UINT uMsg, WPARAM wParam, LPARAM l INT_PTR CALLBACK AudioDlgProc (HWND hDlg, UINT uMsg, WPARAM wParam, LPARAM lParam); INT_PTR CALLBACK ThemeDlgProc (HWND hDlg, UINT uMsg, WPARAM wParam, LPARAM lParam); INT_PTR CALLBACK AboutDlgProc (HWND hDlg, UINT uMsg, WPARAM wParam, LPARAM lParam); +INT_PTR CALLBACK Direct3DDlgProc (HWND hDlg, UINT uMsg, WPARAM wParam, LPARAM lParam); /* Drive management */ BOOL load_drives(void); diff --git a/programs/winecfg/winecfg.rc b/programs/winecfg/winecfg.rc index 4ded308..34baad7 100644 --- a/programs/winecfg/winecfg.rc +++ b/programs/winecfg/winecfg.rc @@ -38,6 +38,7 @@ BEGIN IDS_TAB_DESKTOP_INTEGRATION "Desktop Integration" IDS_TAB_AUDIO "Audio" IDS_TAB_ABOUT "About" + IDS_TAB_DIRECT3D "Direct3D" IDS_WINECFG_TITLE "Wine configuration" IDS_WINECFG_TITLE_APP "Wine configuration for %s" IDS_THEMEFILE "Theme files (*.msstyles; *.theme)" @@ -153,6 +154,17 @@ BEGIN COMBOBOX IDC_WINVER,100,194,145,56,CBS_DROPDOWNLIST | WS_VSCROLL | WS_TABSTOP END +IDD_DIRECT3DCFG DIALOG 0, 0, 260, 220 +STYLE WS_CHILD | WS_DISABLED +FONT 8, "MS Shell Dlg" +BEGIN + GROUPBOX "Direct3D Settings", IDC_STATIC, 8, 4, 244, 210 + CONTROL "", IDC_D3DLIST, "SysListView32", WS_TABSTOP | WS_BORDER | LVS_ALIGNLEFT | LVS_SINGLESEL | LVS_REPORT, 15, 51, 148, 116 + COMBOBOX IDC_D3DCOMBOVAL, 167, 64, 79, 16, WS_TABSTOP | CBS_DROPDOWN | CBS_HASSTRINGS + EDITTEXT IDC_D3DKEY, 167, 52, 79, 12, NOT WS_BORDER | NOT WS_TABSTOP | ES_READONLY + EDITTEXT IDC_D3DTIP, 15, 174, 232, 36, WS_VSCROLL | NOT WS_TABSTOP | ES_MULTILINE | ES_READONLY +END + IDD_GRAPHCFG DIALOG 0, 0, 260, 220 STYLE WS_CHILD | WS_DISABLED FONT 8, "MS Shell Dlg" -- 1.7.8.3

5 7

Re: kernel32: add stubs for GetConsoleCommandHistoryLengthA/W
by André Hentschel 16 Jan '12

16 Jan '12

Am 16.01.2012 18:56, schrieb Austin English: > http://bugs.winehq.org/show_bug.cgi?id=29620 just want to mention source.winehq.org/git/wine.git/blob?h=fdc45524c8b6c70070a03b9efdde4230114f1… here, did you noticed that? -- Best Regards, André Hentschel

1 0

Long translation patch
by Gustavo Henrique Milaré 16 Jan '12

16 Jan '12

Hello, Long time no see :D I've been updating the translation of Wine to Brazilian Portuguese for the last couple of days. I have checked and made extensive tests (I opened the programs, used XN Resource Editor on the resources of the dlls and made a fast review of the diff file). It turns out the patch is very large (around 6500 lines). Sorry if this is a lame question, but I guess I'll need to break it in 15 patches or so, right? Should I send all patches in the same day? I don't want to give the patch reviewers a headache :) Cheers, Gustavo

5 5

RFC: wined3d: Let GetRasterStatus return D3D_OK, again.
by Akihiro Sagawa 16 Jan '12

16 Jan '12

Hi, Attached patch lets GetRasterStatus in wined3d return D3D_OK with pseudo-raster status by QueryPerformanceCounter. Could someone please try the patch with retail version of StarCraft 2? This patch fixes bug 26917[1]. But I'm afraid another problem, especially for SC2. Because the current behavior was introduced to fix bug 23556[2] related SC2. I've already tried for SC2 current demo version. It looks fine. However, I couldn't find GetRasterStatus call in trace logs. Therefore, I'd like to test with retail version which I don't have. I also welcome comments or problem reports about my patch. [1] http://bugs.winehq.org/show_bug.cgi?id=26917 [2] http://bugs.winehq.org/show_bug.cgi?id=23556 -- Akihiro Sagawa

2 1

Re: [PATCH 1/2] winmm: Only start the devices thread when necessary
by Alexandre Julliard 16 Jan '12

16 Jan '12

Andrew Eikum <aeikum(a)codeweavers.com> writes: > Fixes bug 28042. > > dlls/winmm/waveform.c | 106 ++++++++++++++++++++++++++++++++++++------------- > 1 files changed, 78 insertions(+), 28 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M quartz.dll -T ../../.. -p quartz_test.exe.so filtergraph.c && touch filtergraph.ok wine: Unhandled page fault on read access to 0x69187f74 at address 0x558812f9 (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x69187f74 in 32-bit code (0x558812f9). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:558812f9 ESP:0032e840 EBP:0032f778 EFLAGS:00010206( R- -- I - -P- ) EAX:0012ff90 EBX:5588f200 ECX:69187f60 EDX:0012fe30 ESI:00000000 EDI:0032ecdc Stack dump: 0x0032e840: 0012ff90 5588816c 0032f504 0032f754 0x0032e850: 55887f4c 0032f504 0032f6e0 00000000 0x0032e860: 00000000 00000000 00000000 00000000 0x0032e870: 0012fda8 0012fe30 0032e908 68352582 0x0032e880: 000000a0 00000000 6834ed1d 683b710c 0x0032e890: 0032eb18 00000000 0032e978 0032f834 Backtrace: =>0 0x558812f9 DEVENUM_ICreateDevEnum_CreateClassEnumerator+0x10c9(iface=0x55891e4c, clsidDeviceClass=0x32f834, ppEnumMoniker=0x32f870, dwFlags=0) [/home/julliard/wine/wine/dlls/devenum/createdevenum.c:727] in devenum (0x0032f778) 1 0x69104bb2 (0x0032f898) 2 0x69101229 (0x0032faa8) 3 0x6876955a test_render_filter_priority+0x1589() [/home/julliard/wine/wine/dlls/quartz/tests/filtergraph.c:1846] in quartz_test (0x0032fcd8) 4 0x68769fa3 func_filtergraph+0x562() [/home/julliard/wine/wine/dlls/quartz/tests/filtergraph.c:1895] in quartz_test (0x0032fd58) 5 0x68763392 main+0x3a1(argc=*** Invalid address 0x69187f60 *** , argv=*** Invalid address 0x69187f64 *** Internal symbol error: unable to access memory location 0x69187f64) [/home/julliard/wine/wine/dlls/quartz/tests/../../../include/wine/test.h:556] in quartz_test (0x0032fe28) 6 0x6876f865 __wine_spec_exe_entry+0x74(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in quartz_test (0x0032fe70) 7 0x684895bc call_process_entry+0xb() in kernel32 (0x0032fe88) 8 0x6848a73f start_process+0x5e(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/kernel32/process.c:1084] in kernel32 (0x0032fec8) 9 0x68376de0 call_thread_func_wrapper+0xb() in ntdll (0x0032fed8) 10 0x68379acd call_thread_func+0x7c(entry=0x6848a6e0, arg=0x7ffdf000, frame=0x32ffc8) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2532] in ntdll (0x0032ffa8) 11 0x68376dbe call_thread_entry_point+0x11() in ntdll (0x0032ffc8) 12 0x6834eece start_process+0x1d(kernel_start=0x6848a6e0) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2612] in ntdll (0x0032ffe8) 13 0x68028a9d wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) 0x558812f9 DEVENUM_ICreateDevEnum_CreateClassEnumerator+0x10c9 [/home/julliard/wine/wine/dlls/devenum/createdevenum.c:727] in devenum: call *0x14(%ecx) 727 res = IFilterMapper2_RegisterFilter(pMapper, -- Alexandre Julliard julliard(a)winehq.org

1 0

Wine 1.3.37 Gecko engine fails on Arch Linux x86
by Saulius Krasuckas 15 Jan '12

15 Jan '12

I decided to run latest Winetest on my linux box and chose to install Gecko package during prefix setup: $ rm -rf ~/.wine $ wine start wine: created the configuration directory '/home/s2/.wine' fixme:urlmon:DownloadBSC_OnProgress Unsupported status 3 fixme:wininet:InternetLockRequestFile STUB fixme:storage:create_storagefile Storage share mode not implemented. err:mscoree:LoadLibraryShim error reading registry key for installroot err:mscoree:LoadLibraryShim error reading registry key for installroot err:mscoree:LoadLibraryShim error reading registry key for installroot err:mscoree:LoadLibraryShim error reading registry key for installroot err:mscoree:LoadLibraryShim error reading registry key for installroot err:mscoree:LoadLibraryShim error reading registry key for installroot err:module:import_dll Loading library ssl3.dll (which is needed by L"C:\\windows\\system32\\gecko\\1.4\\wine_gecko\\xul.dll") failed (error c0000020). Could not load wine-gecko. HTML rendering will be disabled. wine: configuration in '/home/s2/.wine' has been updated. Another try produced a crash: $ rm -rf ~/.wine $ wine start wine: created the configuration directory '/home/s2/.wine' fixme:urlmon:DownloadBSC_OnProgress Unsupported status 3 fixme:wininet:InternetLockRequestFile STUB wine: Unhandled page fault on read access to 0x149cb074 at address 0x7def0a3a (thread 0018), starting debugger... err:seh:raise_exception Unhandled exception code c0000005 flags 0 addr 0x7bc49a59 Could not load wine-gecko. HTML rendering will be disabled. wine: configuration in '/home/s2/.wine' has been updated. Should I report a bug? S.

4 5

Re: [4/5] d3drm: Add IDirect3DRMWinDevice interface
by Nikolay Sivov 15 Jan '12

15 Jan '12

On 1/15/2012 19:04, André Hentschel wrote: > --- > dlls/d3drm/device.c | 165 +++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 165 insertions(+), 0 deletions(-) > > diff --git a/dlls/d3drm/device.c b/dlls/d3drm/device.c > index f02ce33..957b465 100644 > --- a/dlls/d3drm/device.c > +++ b/dlls/d3drm/device.c > @@ -29,17 +29,20 @@ > #include "wingdi.h" > > #include "d3drm_private.h" > +#include "d3drmwin.h" > > WINE_DEFAULT_DEBUG_CHANNEL(d3drm); > > typedef struct { > IDirect3DRMDevice2 IDirect3DRMDevice2_iface; > IDirect3DRMDevice3 IDirect3DRMDevice3_iface; > + IDirect3DRMWinDevice IDirect3DRMWinDevice_iface; > LONG ref; > } IDirect3DRMDeviceImpl; > > static const struct IDirect3DRMDevice2Vtbl Direct3DRMDevice2_Vtbl; > static const struct IDirect3DRMDevice3Vtbl Direct3DRMDevice3_Vtbl; > +static const struct IDirect3DRMWinDeviceVtbl Direct3DRMWinDevice_Vtbl; You can move instance creation call after all vtables initialization, so you won't need these forwards. > > static inline IDirect3DRMDeviceImpl *impl_from_IDirect3DRMDevice2(IDirect3DRMDevice2 *iface) > { > @@ -51,6 +54,11 @@ static inline IDirect3DRMDeviceImpl *impl_from_IDirect3DRMDevice3(IDirect3DRMDev > return CONTAINING_RECORD(iface, IDirect3DRMDeviceImpl, IDirect3DRMDevice3_iface); > } > > +static inline IDirect3DRMDeviceImpl *impl_from_IDirect3DRMWinDevice(IDirect3DRMWinDevice *iface) > +{ > + return CONTAINING_RECORD(iface, IDirect3DRMDeviceImpl, IDirect3DRMWinDevice_iface); > +} > + > HRESULT Direct3DRMDevice_create(REFIID riid, IUnknown** ppObj) > { > IDirect3DRMDeviceImpl* object; > @@ -66,6 +74,7 @@ HRESULT Direct3DRMDevice_create(REFIID riid, IUnknown** ppObj) > > object->IDirect3DRMDevice2_iface.lpVtbl =&Direct3DRMDevice2_Vtbl; > object->IDirect3DRMDevice3_iface.lpVtbl =&Direct3DRMDevice3_Vtbl; > + object->IDirect3DRMWinDevice_iface.lpVtbl =&Direct3DRMWinDevice_Vtbl; > object->ref = 1; > > if (IsEqualGUID(riid,&IID_IDirect3DRMFrame3)) > @@ -96,6 +105,10 @@ static HRESULT WINAPI IDirect3DRMDevice2Impl_QueryInterface(IDirect3DRMDevice2* > { > *object =&This->IDirect3DRMDevice3_iface; > } > + else if(IsEqualGUID(riid,&IID_IDirect3DRMWinDevice)) > + { > + *object =&This->IDirect3DRMWinDevice_iface; > + } > else > { > FIXME("interface %s not implemented\n", debugstr_guid(riid)); > @@ -1021,3 +1034,155 @@ static const struct IDirect3DRMDevice3Vtbl Direct3DRMDevice3_Vtbl = > IDirect3DRMDevice3Impl_GetStateChangeOptions, > IDirect3DRMDevice3Impl_SetStateChangeOptions > }; > + > + > +/*** IUnknown methods ***/ > +static HRESULT WINAPI IDirect3DRMWinDeviceImpl_QueryInterface(IDirect3DRMWinDevice* iface, > + REFIID riid, void** object) > +{ > + IDirect3DRMDeviceImpl *This = impl_from_IDirect3DRMWinDevice(iface); > + return IDirect3DRMDevice2_QueryInterface(&This->IDirect3DRMDevice2_iface, riid, object); > +} > + > +static ULONG WINAPI IDirect3DRMWinDeviceImpl_AddRef(IDirect3DRMWinDevice* iface) > +{ > + IDirect3DRMDeviceImpl *This = impl_from_IDirect3DRMWinDevice(iface); > + > + TRACE("(%p)\n", This); > + > + return InterlockedIncrement(&This->ref); > +} > + > +static ULONG WINAPI IDirect3DRMWinDeviceImpl_Release(IDirect3DRMWinDevice* iface) > +{ > + IDirect3DRMDeviceImpl *This = impl_from_IDirect3DRMWinDevice(iface); > + ULONG ref = InterlockedDecrement(&This->ref); > + > + TRACE("(%p)\n", This); > + > + if (!ref) > + HeapFree(GetProcessHeap(), 0, This); > + > + return ref; > +} AddRef and Release should be forwards as well.

1 0

Re: [PATCH 1/2] winecoreaudio: Fix AudioCaptureClient Get/ReleaseBuffer protocol.
by Francois Gouget 14 Jan '12

14 Jan '12

On Fri, 13 Jan 2012, Joerg-Cyril.Hoehle(a)t-systems.com wrote: [...] > - Francois' machine crashes in AudioCaptureClient_ReleaseBuffer > http://test.winehq.org/data/5eecdc80e14d2c6cf74a64ac5423dd6ce7c37a3a/mac_fg… > Mine doesn't, even without my patches. Just in case this helps understand what's going on, this Mac Mini is connected to my amplifier via an optical link. I know one consequence is that I cannot set the volume on the Mac. Maybe it has consequences on sound capture to? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Computers are like airconditioners They stop working properly if you open WINDOWS

1 0

Re: [3/3] user32: Move the server call up in order to perform the thread input check earlier in SetActiveWindow.
by Alexandre Julliard 14 Jan '12

14 Jan '12

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > SetForegroundWindow already does a similar thing. Yes but that's because it doesn't have to call a hook first. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: msvcp90: start rfind from given position
by Marvin 13 Jan '12

13 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=16431 Your paranoid android. === WVISTAADM (32 bit string) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation

3 2

Named pipe message mode
by Adam Martinson 13 Jan '12

13 Jan '12

Need some extra pairs of eyes on these; any feedback would be helpful. ~Adam

1 0

Re: mscoree: Implement DllGetClassObject (try 3)
by Vincent Povirk 13 Jan '12

13 Jan '12

+HRESULT create_monodata(REFIID riid, LPVOID *ppObj ) ... + IID iid; You mean clsid here, not riid, right? Otherwise, looks good to me.

1 0

Re: services: Avoid a race when service_entry is freed and process is terminated
by Piotr Caban 13 Jan '12

13 Jan '12

On 01/13/12 20:40, Piotr Caban wrote: > --- > programs/services/rpc.c | 7 ++++--- > 1 files changed, 4 insertions(+), 3 deletions(-) > Please ignore this patch.

1 0

Mac OSX: Use existing Pictures/ Music/ Videos/ etc. directories
by Joerg-Cyril.Hoehle＠t-systems.com 13 Jan '12

13 Jan '12

Hi, winecfg on Mac OSX (10.5.6 and .7) does not link "My Videos" etc. to the equivalent directories on the Mac. Everything is linked to $HOME (or was it Desktop/?) instead. What a pity! See enhancement request/bug 19028 Wouldn't that be an easy patch for Wine+MacOS starters and a nice thing to have in wine-1.4 too? Thank you, Jörg Höhle

1 0

err:ntdll:RtlDeleteResource Deleting active MRSW lock, expect failure
by Joerg-Cyril.Hoehle＠t-systems.com 13 Jan '12

13 Jan '12

Hi, Does anyone know about this error? It sometimes occurs on a Linux machine after the mmdevapi capture tests exited, with a delay as if originating from the server (or a service.exe). Some capture logs sent to me contain this too. Looking up bugzilla, you'll find this error mentioned half a dozen times with various apps. Regards, Jörg Höhle

2 1

[PATCH 2/2] winealsa: Fix AudioCaptureClient Get/ReleaseBuffer protocol.
by Joerg-Cyril.Hoehle＠t-systems.com 13 Jan '12

13 Jan '12

Hi, I forgot to mention that with "winmm: GetCurrentPadding is superfluous while recording" in git, the ALSA patch 82525 can be applied to enforce strict checking of method sequencing: "winealsa: Fix AudioCaptureClient Get/ReleaseBuffer protocol" Regards, Jörg Höhle

1 0

Re: [PATCH 1/4] server: Add mechanism to store and retrieve information about a socket (try 2).
by Vitaliy Margolen 13 Jan '12

13 Jan '12

On 01/13/2012 12:05 AM, Erich E. Hoover wrote: > Real Name: > Erich Hoover > > Changelog: > server: Add mechanism to store and retrieve information about a socket. > > + > +/* Get and set user-accessible socket variables */ > +@REQ(get_socket_variable) > + obj_handle_t handle; /* handle to the socket */ > + unsigned int varcode; /* variable to return */ > + unsigned int varsize; /* size of variable to return */ > +@REPLY > + char ok; /* operation status */ > + int value; /* returned value of variable */ > +@END > + > +@REQ(set_socket_variable) > + obj_handle_t handle; /* handle to the socket */ > + unsigned int varcode; /* variable to set */ > + unsigned int varsize; /* size of variable to set */ > + int value; /* value of variable to set */ > +@REPLY > + char ok; /* operation status */ > +@END You are not using "ok" parameters in either of the calls. You should use status returned by wine_server_call_() for things like that. Also size seems to be redundant here. If it's an int - store it as int on both sides. This also implies you should use an array instead of struct for a storage. And drop size checks. One more thing, keep in mind that time_t is not unsigned int. But long. Vitaliy.

1 0

Re: kernel32: Specify the access rights when creating a file object.
by Alexandre Julliard 13 Jan '12

13 Jan '12

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > While investigating how to fix the file section access tests in kernel32 I've > found that some places in Wine deliberately create objects with access rights > set to 0, that leads to creation of potentially not accessible objects. Many of these are deliberate. You'll need test cases to show that you can require more permissions. -- Alexandre Julliard julliard(a)winehq.org

2 5

Re: [PATCH 1/4] server: Add mechanism to store and retrieve information about a socket (try 2).
by Alexandre Julliard 13 Jan '12

13 Jan '12

"Erich E. Hoover" <ehoover(a)mines.edu> writes: > Real Name: > Erich Hoover > > Description: > This patch implements storing of internal information about a > socket. The intent for this approach is to add a dynamic mechanism to > permit the storage of various variables that are accessible in user > space, such as storing of the connect() time (part 2). That's ugly, you don't need an arbitrary opaque variable storage mechanism. Just store the connect time and return it as such. Besides, you don't even need to set it from the client side, the server is notified on connect. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: comctl32: Return correct background color
by Marvin 13 Jan '12

13 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=16419 Your paranoid android. === WNT4WSSP6 (32 bit treeview) === treeview.c:638: Test failed: Default background color reported as 0xffffffff === W2KPROSP4 (32 bit treeview) === treeview.c:638: Test failed: Default background color reported as 0xffffffff === WXPPROSP3 (32 bit treeview) === treeview.c:638: Test failed: Default background color reported as 0xffffffff === W2K3R2SESP2 (32 bit treeview) === treeview.c:638: Test failed: Default background color reported as 0xffffffff === WVISTAADM (32 bit treeview) === treeview.c:638: Test failed: Default background color reported as 0xffffffff === W2K8SE (32 bit treeview) === treeview.c:638: Test failed: Default background color reported as 0xffffffff === W7PRO (32 bit treeview) === treeview.c:638: Test failed: Default background color reported as 0xffffffff === W7PROX64 (32 bit treeview) === treeview.c:638: Test failed: Default background color reported as 0xffffffff === TEST64_W7SP1 (32 bit treeview) === treeview.c:638: Test failed: Default background color reported as 0xffffffff === W7PROX64 (64 bit treeview) === treeview.c:638: Test failed: Default background color reported as 0xffffffff === TEST64_W7SP1 (64 bit treeview) === treeview.c:638: Test failed: Default background color reported as 0xffffffff

1 0

Re: po: Update French translation
by Francois Gouget 12 Jan '12

12 Jan '12

On Thu, 12 Jan 2012, Frédéric Delanoy wrote: [...] > #: appwiz.rc:64 > msgid "&Support Info" > -msgstr "Inf&ormations de support..." > +msgstr "Inf&ormations de support" I don't know why 'Information' was abbreviated in English. This should be checked and unabbreviated if it was abusive. But if it's because of a lack of space, for instance, then we should probably abbreviate it in French too (even if it means the spellchecker complains :-/). Besides that, thanks a lot for the patch. It looks like it's going to fix a lot of the issues reported on my wine-po site: http://fgouget.free.fr/wine-po/ Btw, if anyone feels like tackling some of them I'll gladly accept all the help I can get. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux: It is now safe to turn on your computer.

2 2

Vista/w2k8/w7 + ALSA users, please test mmdevapi capture
by Joerg-Cyril.Hoehle＠t-systems.com 12 Jan '12

12 Jan '12

Hi, Thanks to all five users who sent me data. I've a new testbot job. Please download mmdevapi_test32|64.exe http://testbot.winehq.org/JobDetails.pl?Key=16386 you don't need a microphone, just a capture capable sound card, unlike testbot. there should be next to 0 failures in lines 200-410. Failures in 411-600 (function test_capture2) are not interesting. It would be good to repeat the test a few times to see whether there's a random failure. Also, please compare mmdevapi_test[64].exe capture with mmdevapi_test[64].exe capture > capture.log Redirecting to a file leads to vastly different results (in the render tests) because output to the MS-DOS shell is extremely slow and thus affects timing. On a 64bit machine, you may also compare the output of both executables. The behaviour is apparently not the same! On Unix with ALSA, you may try my latest patches from source.winehq.org/patches and see if it works for you. - Stop without snd_pcm_drop patch - Reset accounting patch - CaptureClient protocol patch I'm at 0 failures (ignoring test_capture2) and a few todo with dmix and 0-1 (random) with PulseAudio. Please post or send me the results -- not just the failures, the console output too including position/padding/flags. Thank you for testing, Jörg Höhle

3 2

Re: [PATCH 1/5] ddraw/tests: Add some clipper tests.
by Saulius Krasuckas 12 Jan '12

12 Jan '12

* On Wed, 4 Jan 2012, Henri Verbeet wrote: > --- > dlls/ddraw/tests/ddraw1.c | 217 +++++++++++++++++++++++++++++++++++++++++++++ > dlls/ddraw/tests/ddraw2.c | 217 +++++++++++++++++++++++++++++++++++++++++++++ > dlls/ddraw/tests/ddraw4.c | 216 ++++++++++++++++++++++++++++++++++++++++++++ > dlls/ddraw/tests/ddraw7.c | 216 ++++++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 866 insertions(+), 0 deletions(-) It's http://source.winehq.org/git/wine.git/commitdiff/3997457574a0e3f1c2fa095e23… These tests fail on real machines (running XP and w7) with nVidia cards (FX5200 and GF 310M): http://test.winehq.org/data/b00e7039c5fcaa613b9776a38fe60bb697146b42/index_… http://test.winehq.org/data/a86b765a50cdf76e66c8993977f892d825f52ec0/index_… On XP + FX5200 the first three tests (dd1, dd2, dd4) generates crash with failing hr = 0x8876021c. The other cases just fail by some color matches. Plus, tests fail on one WTB machine running XP with russian localisation + "VMware SVGA II" v11.6.0.35 in yet different way: http://test.winehq.org/data/b00e7039c5fcaa613b9776a38fe60bb697146b42/xp_wtb… Other virtual XP machines do OK with similar setup. My humble guess -- that's just one broken setup out of many virtual machines. Henri, would you be as kind as to fix the tests:)? S.

2 2

Re: [2/2] msvcrt: Forward strftime() to wcsftime(). Take 2.
by Alexandre Julliard 12 Jan '12

12 Jan '12

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > + len = MultiByteToWideChar( CP_ACP, 0, format, -1, NULL, 0 ); > + if ((fmt = MSVCRT_malloc( len * sizeof(MSVCRT_wchar_t) ))) > + { > + MultiByteToWideChar( CP_ACP, 0, format, -1, fmt, len ); > + > + if ((len = MSVCRT_wcsftime( s, max, fmt, mstm ))) > + { > + len = WideCharToMultiByte( CP_ACP, 0, s, len, str, max, NULL, NULL ); > + if (len < max) str[len] = 0; > + } The overflow handling still looks suspicious. It probably needs some more test cases. -- Alexandre Julliard julliard(a)winehq.org

2 6

Re: mscoree: Implement DllGetClassObject (try 2)
by Vincent Povirk 12 Jan '12

12 Jan '12

You're still using a single static class object, and I'm not convinced GetIDispatchForObject is a good idea. On Wed, Jan 11, 2012 at 5:02 AM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > Hi, > Use RegGetValueW for the class. > > Changelog: > mscoree: Implement DllGetClassObject > > > Best Regards > Alistair Leslie-Hughes > > > >

1 0

[PATCH 5/8] dsound: Make capture behave like native in regards to COM aggregation.
by Joerg-Cyril.Hoehle＠t-systems.com 12 Jan '12

12 Jan '12

Hi, Michael Stefaniuc wrote: >static HRESULT WINAPI IDirectSoundCaptureImpl_CreateCaptureBuffer + if (pUnk) { + WARN("invalid parameter: pUnk != NULL\n"); + /* *lplpDSCaptureBuffer = NULL; Not done by native dsound */ + return DSERR_NOAGGREGATION; + } What's your rationale for doing so? Bug compatibility with native is fine, however not setting NULL is problematic before you've reached 100% compatibility, have you? What I mean is that if there's a situation where Wine's CreateCaptureBuffer returns some DSERR such as NOTIMPL where native does not, then that's an unexpected situation for the app which it may not be well prepared to handle, as it is untestable on native. Now not zeroing output pointers may make it even harder for the app to remain in sane state. Then blame the app or Wine for a crash? If OTOH you know that the Wine module *always* returns the exact same values as native, then I've no objection in not zeroing output pointers when native does neither. Yet you'll have to consider that native may do so in the future, witness a growing number of MSDN documents covering later APIs that specifically mention zeroing pointers in case of failure. IIRC, AJ removed from my mmdevapi tests one snippet that showed that native's GetService does not zero an output pointer even though MSDN says so -- Wine zeroes. Yet perhaps I got confused, messed up with patches and submitted the one that did not contain that test so maybe AJ never had a chance to see it. I'll have to check that. Regards, Jörg Höhle

3 3

Re: jscript: Don't use break in funally block on pre-IE8 jscript
by Marvin 12 Jan '12

12 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=16400 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

2 1

Interesting - performance issues in Natural Selection 2 dedicated server
by Scott Ritchie 12 Jan '12

12 Jan '12

The game is still in beta development, but I just learned something odd - there are no Linux server binaries (yet), and a lot of admins are running the dedicated server using Wine. Wine works, but is actually performing fairly poorly here. I find this really interesting, as the dedicated server isn't graphical in any way. Would profiling here be worthy of pursuing? Are there known areas of bad performance other than graphics? Thanks, Scott Ritchie

2 1

Re: [PATCH] mshtml: Add interface for nsIWebBrowserChrome2 and 3
by Jacek Caban 12 Jan '12

12 Jan '12

Hi Detlef, Why do you add them? nsiface.idl should contain only interfaces that we use. Otherwise it's just adding me more work on each Gecko merge. Jacek

1 0

d3dx9: Implement D3DXCreatePolygon
by David Adam 12 Jan '12

12 Jan '12

Hello are there still problems with the patches: http://source.winehq.org/patches/data/82408 and http://source.winehq.org/patches/data/82409 ? Thanks in advance A+ David

1 0

MacOS recording audio - chunking 4096 frames
by Joerg-Cyril.Hoehle＠t-systems.com 12 Jan '12

12 Jan '12

Hi, looking at mmdevapi/tests/capture logs, I found 2 issues 1. the 5 buffers initially sent are all returned with 0 bytes So I added a loop to return empty buffers to the audio input queue, such that GetBuffer returns data when GetCurrentPadding shows it. But why were these buffers returned at all? Why initially submit the buffers if they are always returned empty? 2. Using a ~500ms mmdevapi duration, Wine gave MacOS CoreAudio 5 buffers of ~4399 frames each. However, MacOS solely returned 4096 frames. Is anybody aware of such chunking? I'd like to know about such chunking, because IMHO the correct way to handle it would be to advertise mmdevapi's a matching default recording period -- obviously not 10ms. I believe the current mmdevapi code did not expect that behaviour and therefore does not manage to fill as much frames as GetBufferSize would allow into a buffer. I haven't checked smaller buffers. I'd like to avoid bombarding CoreAudio with 10ms buffer requests of 480 frames each just because native mmdevapi advertises a 10ms period. Thank you for your help, Jörg Höhle

2 1

Vista/w2k8/w7 users, please test mmdevapi capture
by Joerg-Cyril.Hoehle＠t-systems.com 11 Jan '12

11 Jan '12

Hi, you don't need a microphone, just a capture capable sound card, unlike testbot. Please download mmdevapi_test32|64.exe from testbot: http://testbot.winehq.org/JobDetails.pl?Key=16376 run: mmdevapi_test capture and post or send me the results -- not just the failures, the console output too including position/padding/flags. Don't be afraid of some test failures in lines 300-499. I'm still investigating underrun and start/stop/reset behaviour. Thank you for testing, Jörg Höhle

3 2

Re: mscoree: Implement DllGetClassObject
by Vincent Povirk 11 Jan '12

11 Jan '12

You can't just use a static class factory for all the classes. There's no need for GetIDispatchForObject when we already have GetIUnknownForObject (and all you use is QueryInterface). + res = RegGetValueA( key, NULL, "Class", RRF_RT_REG_SZ, NULL, classname, &dwBufLen); We should probably use a W function here and convert to utf8, rather than assume that's the default encoding.

2 2

Re: [PATCH 3/5] d3d9: Don't expose wined3d internal flags to the application.
by Alexandre Julliard 11 Jan '12

11 Jan '12

Henri Verbeet <hverbeet(a)codeweavers.com> writes: > --- > dlls/d3d9/buffer.c | 4 ++-- > dlls/d3d9/cubetexture.c | 2 +- > dlls/d3d9/surface.c | 2 +- > dlls/d3d9/texture.c | 2 +- > dlls/d3d9/volume.c | 2 +- > dlls/d3d9/volumetexture.c | 2 +- > 6 files changed, 7 insertions(+), 7 deletions(-) This is causing test failures: ../../../tools/runtest -q -P wine -M d3dx9_36.dll -T ../../.. -p d3dx9_36_test.exe.so mesh.c && touch mesh.ok mesh.c:331: Test succeeded inside todo block: Test createmesh1, result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test createmesh2, result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test createmeshfvf, result 0, expected 0 mesh.c:2497: Tests skipped: D3DXCreateBox failed mesh.c:331: Test succeeded inside todo block: Test sphere (0, 2, 2), result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test sphere (1, 2, 2), result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test sphere (1, 3, 2), result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test sphere (1, 4, 4), result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test sphere (1, 3, 4), result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test sphere (5, 6, 7), result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test sphere (10, 11, 12), result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test cylinder (0, 0, 0, 2, 1), result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test cylinder (1, 1, 1, 2, 1), result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test cylinder (1, 1, 2, 3, 4), result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test cylinder (3, 2, 4, 3, 4), result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test cylinder (2, 3, 4, 3, 4), result 0, expected 0 mesh.c:331: Test succeeded inside todo block: Test cylinder (3, 4, 5, 11, 20), result 0, expected 0 mesh.c:3679: Test succeeded inside todo block: Test text ('wine', 340282346638528859811704183484516925440.000000, 0.400000), result 0, expected 0 mesh.c:3679: Test succeeded inside todo block: Test text ('wine', 0.001000, 0.000000), result 0, expected 0 mesh.c:3679: Test succeeded inside todo block: Test text ('wine', 0.001000, 0.000000), result 0, expected 0 mesh.c:3679: Test succeeded inside todo block: Test text ('wine', 0.001000, 340282346638528859811704183484516925440.000000), result 0, expected 0 mesh.c:3679: Test succeeded inside todo block: Test text ('wine', 0.000000, 1.000000), result 0, expected 0 make: *** [mesh.ok] Error 21 -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: httpapi: add method stub for HttpAddUrl()
by Nikolay Sivov 11 Jan '12

11 Jan '12

On 1/11/2012 13:41, Arash Cordi wrote: > + > +ULONG WINAPI HttpAddUrl( HANDLE handle, PCWSTR url, PVOID reserved ) > +{ > + FIXME( "(%p %p %p): stub!\n", handle, url, reserved); > + return ERROR_CALL_NOT_IMPLEMENTED; > +} > + Please use %s format for 'url' so it will be visible in logs.

2 1

What other conferences do Wine people attend?
by Dan Kegel 11 Jan '12

11 Jan '12

In the wineconf thread, the question came up: What other conferences people do wine developers/users attend, if any? If you send me the names of the conference(s) you attended in the last two years, I'll summarize for the list.

5 4

Re: cryptui: Use the same capitalization for the same string
by Francois Gouget 11 Jan '12

11 Jan '12

On Tue, 10 Jan 2012, André Hentschel wrote: > So that the string needs only one translation in po files - GROUPBOX "Certification path", -1,6,10,245,165, BS_GROUPBOX + GROUPBOX "Certification Path", -1,6,10,245,165, BS_GROUPBOX Unfortunately this goes against the Windows User Experience Interaction Guidelines. Group box labels are supposed to use sentence-style capitalization: http://msdn.microsoft.com/en-us/library/aa511459.aspx But dialog box titles are supposed to use title-style capitalization, hence the case difference: http://msdn.microsoft.com/en-us/library/aa511268.aspx#titles Glossary: * Sentence-style capitalization http://msdn.microsoft.com/en-us/library/aa511441.aspx#SentenceCaps * Title-style capitalization http://msdn.microsoft.com/en-us/library/aa511441.aspx#TitleCaps -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ E-Voting: Those who cast the votes decide nothing. Those who count the votes decide everything.

1 1

Re: [2/5] dinput: SetActionMap saving simple configurations to an .ini file (try 2)
by Vitaliy Margolen 11 Jan '12

11 Jan '12

On 01/09/2012 10:18 AM, Lucas Fialho Zawacki wrote: > From: Lucas Fialho Zawacki<lfzawacki(a)gmail.com> > > +static BOOL _write_private_profile_intW(const char *format, WCHAR* section, WCHAR* key, int value, WCHAR* file) I don't think this is such a good idea to mix ASCII and WCHAR parameters. > + static WCHAR path[] = { > + '%','C','o','m','m','o','n','P','r','o','g','r','a','m','F','i','l','e','s','%','\\', > + 'D','i','r','e','c','t','X','\\', > + 'D','i','r','e','c','t','I','n','p','u','t','\\', > + 'U','s','e','r',' ','M','a','p','s','\0'}; Why do you think it should be there in the first place? > + expanded_path = HeapAlloc(GetProcessHeap(), 0, sizeof(WCHAR)*expanded_path_size); No error checking. > +static HRESULT _save_mapping_settings(IDirectInputDevice8W *iface, LPDIACTIONFORMATW lpdiaf, LPCWSTR lpszUsername) > +{ > + static WCHAR mapexists[] = {'M','a','p','E','x','i','s','t','s','\0'}; > + static WCHAR numactions[] = {'N','u','m','A','c','t','i','o','n','\0'}; Should be "static const WCHAR". > + IDirectInputDevice8_GetDeviceInfo(iface,&didev); No error checking. > + va_start(args, format); > + while (1) > + { > + buffer = HeapAlloc(GetProcessHeap(), 0, size); > + if (buffer == NULL) > + break; > + n = vsnprintfW(buffer, size, formatW, args); > + if (n == -1) > + size *= 2; > + else if (n>= size) > + size = n + 1; > + else > + break; > + HeapFree(GetProcessHeap(), 0, buffer); > + } > + va_end(args); You can't do this. It seems to be you have not tested it with initial buffer too small. You have to do va_start & va_end every time you pass "args" to another function. > + > + if (buffer == NULL) return NULL; > + ret = HeapReAlloc(GetProcessHeap(), 0, buffer, sizeof(WCHAR)*(strlenW(buffer)+1) ); > + if (ret == NULL) ret = buffer; Why reallocate? It's pointless. > +extern WCHAR* _get_mapping_path(const WCHAR *device, const WCHAR *username) DECLSPEC_HIDDEN; Would you please drop leading underscore from all of your function names? Vitaliy.

2 2

RFH: Applications that call stuff from DllMain
by Andrew Eikum 10 Jan '12

10 Jan '12

This mail is about bugs 28042[1] and 28677[2]. In short, what I'm trying to deal with is buggy applications that make calls to DSound and WinMM from within DllMain(), causing deadlocks. On almost any entry into DSound or WinMM's wave functions, the modules launch a thread to communicate with MMDevAPI. We create a new thread for two reasons. First, to CoInitialize() the thread, which we shouldn't do on a user thread. Second, the MMDevAPI docs say that the device objects should be created and destroyed from the same thread[3], which we can't guarantee if we create them on a user thread (I think dsound currently violates this, actually). Wine holds the loader critical section during calls to DllMain(). However, launching a new thread requires using the loader, and so we hit a deadlock. This is the problem reported by these bugs. While we might be able to perform some of these functions without launching a new thread, I'm not sure that that's a general solution, since we will have to launch a thread at some point. Analysis on Windows 7 shows that DirectSoundEnumerate() does not launch any additional threads, but mixerGetNumDevs() actually does launch a thread, yet the application still launches successfully. So, I'm asking for insights. Should I try hard to avoid launching threads unless absolutely necessary? Is this a known deficiency in the loader, and I should do nothing? Is there some other way to work around this? Thanks, Andrew [1] http://bugs.winehq.org/show_bug.cgi?id=28042 [2] http://bugs.winehq.org/show_bug.cgi?id=28677 [3] http://msdn.microsoft.com/en-us/library/windows/desktop/dd370873%28v=VS.85%…

3 4

Re: winmm: GetCurrentPadding is superfluous while recording.
by Alexandre Julliard 10 Jan '12

10 Jan '12

Joerg-Cyril.Hoehle(a)t-systems.com writes: > Hi, > > now winmm recording does not depend on chunking by mmdevapi. > > + if(packet > 0) > + WARN("losing %u frames\n", packet); > That part is interesting. Another approach would have been to check whether > all of GetData could be stuffed into winmm buffers and use ReleaseBuffer(0) if not > (much more complicated in the presence of several buffers). > > As long as winmm supplies enough buffers in advance, that doesn't matter. > > With that in place, the "Fix AudioCaptureClient protocol" patches can be applied on > the winmm side. I have not checked the dsound code. > > I'm sorry winmm:ACMPullData was broken by my former notification patch. I'll have to fix that. > ACMPullData is also not very robust (return; after GetBuffer will prevent any subsequent GetBuffer > with OUT_OF_ORDER). It doesn't work here: ../../../tools/runtest -q -P wine -M winmm.dll -T ../../.. -p winmm_test.exe.so mci.c && touch mci.ok [...] err:winmm:WID_PullData GetBuffer failed: 88890007 err:winmm:WID_PullData GetBuffer failed: 88890007 err:winmm:WID_PullData GetBuffer failed: 88890007 err:winmm:WID_PullData GetBuffer failed: 88890007 err:winmm:WID_PullData GetBuffer failed: 88890007 err:winmm:WID_PullData GetBuffer failed: 88890007 err:winmm:WID_PullData GetBuffer failed: 88890007 err:winmm:WID_PullData GetBuffer failed: 88890007 err:winmm:WID_PullData GetBuffer failed: 88890007 etc. forever -- Alexandre Julliard julliard(a)winehq.org

1 0

[PATCH] wineoss.drv: Fix IAudioRenderClient::{Get,Release}Buffer protocol
by Joerg-Cyril.Hoehle＠t-systems.com 10 Jan '12

10 Jan '12

Andrew Eikum wrote: >I think the GetPosition and GetCurrentPadding failures are caused by >using GETOSPACE instead of GETODELAY in GetPosition(). Please write that patch too. It needs good testing to get the start/stop/underrun corner cases right. My hope is that Wine-1.4.0 will have 3 drivers of comparable if not equal quality. What I plan is to submit my render patch with almost all GetPosition tests lifted behind if(winetest_debug>1): render.c:1062: Tests skipped: Rerun with WINETEST_DEBUG=2 for GetPosition tests. This one perhaps should move as well, although it indicates a problem. render.c:1166: Test failed: Position should have been further along... render.c:1227: Test failed: GetCurrentPadding returned 512, should be 0 No idea, please check. render.c:1228: Test failed: Position 142756 at end vs. 143268 submitted frames In shared mode, the end position must be the sum of released frames. In exclusive mode, I've seen some cards return a little less. Your RenderClient patch looks good. Regards, Jörg Höhle

2 1

Re: jscript: Fixed continue inside for..in statement
by Marvin 10 Jan '12

10 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=16361 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Re: gdi32: GetGlyphIndices doesn't substitute glyph.
by Marvin 10 Jan '12

10 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=16359 Your paranoid android. === WNT4WSSP6 (32 bit font) === Timeout

1 0

Re: [PATCH] programs/explorer: Fix explorer's command line parsing (try 2)
by Vitaliy Margolen 10 Jan '12

10 Jan '12

On 01/08/2012 08:45 PM, Jay Yang wrote: > Fixed some small formatting issues from last time. > Your patch strips spaces all over the place. For example: + LPWSTR *argv; + if(commandline[0]=='\0') Need an empty line after variable declarations. No space after "if". No space around equal operator. + for(i=0;i<argc;i++) No spaces after semi-colon. + copy_path_string(parameters->root,curr); No space after coma. Some other issues - you will parse over parameters given to the program. Ex: explorer /desktop=foo,800x600 program.exe /n /e Parsing inside parameters is incorrect: + LPWSTR end=strchrW(curr,','); + LPWSTR next; + if(end==NULL) + next=(end=strchrW(curr,'\0')); + else + next=end+1; ... + curr=next; You end up parsing something like this as a valid param: /n,/e,/select,c:\\ Vitaliy.

2 2

Re: [4/5] dinput: Device username being assigned at creation time (try 2)
by Vitaliy Margolen 10 Jan '12

10 Jan '12

On 01/09/2012 10:18 AM, Lucas Fialho Zawacki wrote: > From: Lucas Fialho Zawacki<lfzawacki(a)gmail.com> You leaking FindFile handle. Need to use FindClose() to close it. This is on top of more unchecked returns from HappAlloc. Vitaliy.

1 0

Re: [3/5] dinput: SetActionMap setting username
by Vitaliy Margolen 10 Jan '12

10 Jan '12

On 01/09/2012 10:18 AM, Lucas Fialho Zawacki wrote: > From: Lucas Fialho Zawacki<lfzawacki(a)gmail.com> > > + /* Set username in device */ > + HeapFree(GetProcessHeap(), 0, This->username); > + This->username = HeapAlloc(GetProcessHeap(), 0, sizeof(WCHAR) * (lstrlenW(username) + 1)); > + lstrcpyW(This->username, username); No error checking if allocation fails. > + > + /* Free username */ > + HeapFree(GetProcessHeap(), 0, This->username); > + Comment is kind of redundant the property already called "username". Vitaliy.

1 0

UTF-7
by Alex Henrie 10 Jan '12

10 Jan '12

Hello, I have been thinking about implementing UTF-7 support in MultiByteToWideChar and WideCharToMultiByte. The guts of the code that needs to be added have already been posted to bug 27388. What more needs to be done? Should a libs/wine/utf7.c file be created for the new functions, similar to libs/wine/utf8.c? -Alex

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