June 2010 - Wine-Devel - list.winehq.org

Re: Addition of En resources to non-En resources

by Dmitry Timoshkov

Francois Gouget <fgouget(a)free.fr> wrote: > James never meant that Wine would not use rc files at all. What he meant > is that rc files would lose their status as the autoritative source for > the resource strings and would be mostly generated from po files. The .rc files are much more than just strings, in any case the translator need to edit/check the .rc files to get an acceptable result. I was replying to a comment saying basically "me too" which the sender tends to reply to almost every message. -- Dmitry.

June 23, 2010

Re: [hhctrl.ocx] Null pointer fix, new patch

by Dmitry Timoshkov

Jaroslav Šmíd <jardasmid(a)gmail.com> wrote: > diff -urN Wine-git.orig/dlls/hhctrl.ocx/chm.c Wine-git/dlls/hhctrl.ocx/chm.c > --- Wine-git.orig/dlls/hhctrl.ocx/chm.c 2010-06-22 12:41:54.034540000 +0200 > +++ Wine-git/dlls/hhctrl.ocx/chm.c 2010-06-22 12:51:07.454541388 +0200 > @@ -238,11 +238,11 @@ > info->WinType.pszIndex = strdupW(null); > info->WinType.fsValidMembers=0; > info->WinType.fsWinProperties=HHWIN_PROP_TRI_PANE; > - info->WinType.pszCaption=strdupW(info->pCHMInfo->defTitle); > + info->WinType.pszCaption=strdupW(info->pCHMInfo->defTitle ? > info->pCHMInfo->defTitle : null); > info->WinType.dwStyles=WS_POPUP; > info->WinType.dwExStyles=0; > info->WinType.nShowState=SW_SHOW; > - info->WinType.pszFile=strdupW(info->pCHMInfo->defTopic); > + info->WinType.pszFile=strdupW(info->pCHMInfo->defTopic ? > info->pCHMInfo->defTopic : null); > info->WinType.curNavType=HHWIN_NAVTYPE_TOC; > return TRUE; > } The patch is wrapped. -- Dmitry.

June 23, 2010

Re: [PATCH] winedevice: Use 64-bit wide delta when relocating

by Austin English

On Tue, Jun 22, 2010 at 8:31 PM, <alex.pigna(a)inventati.org> wrote: > Hi Everyone, > > when using Wine64 relocations should use 64-bit wide deltas, winedevice was > not compliant with this. Patch follows > > Regards, > Alessandro Pignotti Patches should be sent to wine-patches(a)winehq.org -- -Austin

June 23, 2010

[PATCH 2/2] d3dx9: Add stub and basic test for D3DXCreateSphere.

by Misha Koshelev

FYI, I am following the current definition of D3DXCreateBox, which is in the mesh.c file. If you think I should start a separate (shape.c) file for these functions, please let me know. Prior patch fixed an #include which should have been present in d3dx9.h Starting work on http://bugs.winehq.org/show_bug.cgi?id=22918 implementing D3DXCreateSphere Thank you Misha p.s. Actually I remember I used to be quite into game programming many years ago - "Tricks of the Game Programming Gurus", even wrote my own Mode X library at one point ;) - not 3D though --- dlls/d3dx9_36/d3dx9_36.spec | 2 +- dlls/d3dx9_36/mesh.c | 8 ++++++++ dlls/d3dx9_36/tests/mesh.c | 9 +++++++++ include/d3dx9shape.h | 7 +++++++ 4 files changed, 25 insertions(+), 1 deletions(-) diff --git a/dlls/d3dx9_36/d3dx9_36.spec b/dlls/d3dx9_36/d3dx9_36.spec index 19406e7..b9a00da 100644 --- a/dlls/d3dx9_36/d3dx9_36.spec +++ b/dlls/d3dx9_36/d3dx9_36.spec @@ -87,7 +87,7 @@ @ stub D3DXCreateSkinInfo @ stub D3DXCreateSkinInfoFromBlendedMesh @ stub D3DXCreateSkinInfoFVF -@ stub D3DXCreateSphere +@ stdcall D3DXCreateSphere(ptr long long long ptr ptr) @ stdcall D3DXCreateSprite(ptr ptr) @ stub D3DXCreateTeapot @ stub D3DXCreateTextA diff --git a/dlls/d3dx9_36/mesh.c b/dlls/d3dx9_36/mesh.c index 9691eed..5611030 100644 --- a/dlls/d3dx9_36/mesh.c +++ b/dlls/d3dx9_36/mesh.c @@ -335,3 +335,11 @@ HRESULT WINAPI D3DXCreateBox(LPDIRECT3DDEVICE9 device, FLOAT width, FLOAT height return E_NOTIMPL; } + +HRESULT WINAPI D3DXCreateSphere(LPDIRECT3DDEVICE9 device, FLOAT radius, UINT slices, + UINT stacks, LPD3DXMESH* mesh, LPD3DXBUFFER* adjacency) +{ + FIXME("(%p, %f, %d, %d, %p, %p): stub\n", device, radius, slices, stacks, mesh, adjacency); + + return E_NOTIMPL; +} diff --git a/dlls/d3dx9_36/tests/mesh.c b/dlls/d3dx9_36/tests/mesh.c index 8e4e26d..0086bb3 100644 --- a/dlls/d3dx9_36/tests/mesh.c +++ b/dlls/d3dx9_36/tests/mesh.c @@ -476,6 +476,14 @@ static void D3DXIntersectTriTest(void) ok( got_res == exp_res, "Expected result = %d, got %d\n",exp_res,got_res); } +static void D3DXCreateSphereTest(void) +{ + HRESULT hr; + + hr = D3DXCreateSphere(NULL, 0.0, 0, 0, NULL, NULL); + todo_wine ok( hr == D3DERR_INVALIDCALL, "Got result %x, expected %x (D3D_INVALIDCALL)\n",hr,D3DERR_INVALIDCALL); +} + static void test_get_decl_vertex_size(void) { static const D3DVERTEXELEMENT9 declaration1[] = @@ -556,5 +564,6 @@ START_TEST(mesh) D3DXDeclaratorFromFVFTest(); D3DXGetFVFVertexSizeTest(); D3DXIntersectTriTest(); + D3DXCreateSphereTest(); test_get_decl_vertex_size(); } diff --git a/include/d3dx9shape.h b/include/d3dx9shape.h index e1bf231..36bca6b 100644 --- a/include/d3dx9shape.h +++ b/include/d3dx9shape.h @@ -32,6 +32,13 @@ HRESULT WINAPI D3DXCreateBox(LPDIRECT3DDEVICE9 device, LPD3DXMESH* mesh, LPD3DXBUFFER* adjacency); +HRESULT WINAPI D3DXCreateSphere(LPDIRECT3DDEVICE9 device, + FLOAT radius, + UINT slices, + UINT stacks, + LPD3DXMESH* mesh, + LPD3DXBUFFER* adjacency); + #ifdef __cplusplus } #endif -- 1.7.1

June 23, 2010

Re: Porting Applications

by Roderick Colenbrander

Hi, It is certainly nice that a company offers support for this. Last year I did something even cooler and it doesn't require much effort. I used Visual Studio itself to remotely debug on Wine. I'm not sure if I used native dbghelp.dll or not (I think I didn't use it). The only thing I needed for it to be useful was a debug build of the app (+debugging visual c++ runtime libs). The only thing I had to do was to launch some remote debugging utility, 'msvcmon' in Wine and after that I had to fire up the app. After that I was able to connect to 'Wine' using Visual C++ on Windows and I was able to set break points and so on. It worked really well. Roderick On Tue, Jun 22, 2010 at 5:10 PM, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > Hi, > > Check out this ability to debug your windows in WINE. > > Sparx Systems Enterprise Architect allows you to debug Windows applications > under WINE. > http://www.sparxsystems.com/support/faq/enterprise-architect-WINE.html#nine > > The limitations are you need to use the native dbghelp.dll. You need the > PDB's of the > application you want to debug, and the source if want to set breakpoints. > > Features > 1. Allows debugging of a windows application. > 2. Allows sampling (profiling) of you application. > > What it doesn't do > 1. Allow Debugging of application you have the PDB's. > 2. Assembly level debugging, all breakpoints are at the source level only. > > This feature has been extremely useful in working out issues with running > Enterprise Architect in the > WINE environment. > > Best Regards > Alistair Leslie-Hughes > > >

June 23, 2010

[PATCH] winedevice: Use 64-bit wide delta when relocating

by alex.pigna＠inventati.org

Hi Everyone, when using Wine64 relocations should use 64-bit wide deltas, winedevice was not compliant with this. Patch follows Regards, Alessandro Pignotti --- programs/winedevice/device.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/programs/winedevice/device.c b/programs/winedevice/device.c index e0cd07b..1b5b87a 100644 --- a/programs/winedevice/device.c +++ b/programs/winedevice/device.c @@ -67,7 +67,8 @@ static HMODULE load_driver_module( const WCHAR *name ) IMAGE_NT_HEADERS *nt; const IMAGE_IMPORT_DESCRIPTOR *imports; size_t page_size = getpagesize(); - int i, delta; + int i; + intptr_t delta; ULONG size; HMODULE module = LoadLibraryW( name ); -- 1.7.1

June 23, 2010

Porting Applications

by Alistair Leslie-Hughes

Hi, Check out this ability to debug your windows in WINE. Sparx Systems Enterprise Architect allows you to debug Windows applications under WINE. http://www.sparxsystems.com/support/faq/enterprise-architect-WINE.html#nine The limitations are you need to use the native dbghelp.dll. You need the PDB's of the application you want to debug, and the source if want to set breakpoints. Features 1. Allows debugging of a windows application. 2. Allows sampling (profiling) of you application. What it doesn't do 1. Allow Debugging of application you have the PDB's. 2. Assembly level debugging, all breakpoints are at the source level only. This feature has been extremely useful in working out issues with running Enterprise Architect in the WINE environment. Best Regards Alistair Leslie-Hughes

June 23, 2010

Re: shell32/tests: SHELL_ArgifyW(%2|%*|%~3, ...) tests

by testbot＠testbot.winehq.org

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=2839 Your paranoid android. === W7PROX64 (64 bit shlexec) === shlexec.c:1738: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wtA1D5.tmp\test file.sde", null, null) failed: rc=29 err=2 shlexec.c:1738: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wtA1D5.tmp\test file.sde", null, null) failed: rc=29 err=2 shlexec.c:1738: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wtA1D5.tmp\test file.sde", null, null) failed: rc=29 err=2 shlexec.c:1738: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wtA1D5.tmp\test file.sde", null, null) failed: rc=29 err=2 shlexec.c:1738: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wtA1D5.tmp\test file.sde", null, null) failed: rc=29 err=2

June 22, 2010

Re: msvcr90/tests: Make test_invalid_parameter_handler() static.

by testbot＠testbot.winehq.org

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=2832 Your paranoid android. === WXPPROSP3 (32 bit msvcr90) === No test summary line found === W2K3R2SESP2 (32 bit msvcr90) === No test summary line found === WVISTAADM (32 bit msvcr90) === No test summary line found === W2K8SE (32 bit msvcr90) === No test summary line found

June 22, 2010

Re: shlwapi/tests: Make the XXX_Construct() functions static.

by testbot＠testbot.winehq.org

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=2830 Your paranoid android. === W2KPROSP4 (32 bit ordinal) === ordinal.c:593: Test failed: GetShellSecurityDescriptor should fail ordinal.c:616: Test failed: returned value is not valid SD No test summary line found === W7PRO (32 bit ordinal) === ordinal.c:1759: Test failed: got 13 ordinal.c:1765: Test failed: got 28 ordinal.c:1780: Test failed: got 10 ordinal.c:1793: Test failed: got 13 ordinal.c:1801: Test failed: got 13 ordinal.c:1815: Test failed: got 28 ordinal.c:1823: Test failed: got 28 ordinal.c:1831: Test failed: got 40, length 41 ordinal.c:1842: Test failed: got 43 ordinal.c:1853: Test failed: got 23 === W7PROX64 (32 bit ordinal) === ordinal.c:1759: Test failed: got 9 ordinal.c:1765: Test failed: got 25 ordinal.c:1780: Test failed: got 6 ordinal.c:1793: Test failed: got 9 ordinal.c:1801: Test failed: got 9 ordinal.c:1815: Test failed: got 25 ordinal.c:1823: Test failed: got 25 ordinal.c:1853: Test failed: got 19 ordinal.c:1864: Test failed: got 22 === W7PROX64 (64 bit ordinal) === ordinal.c:1759: Test failed: got 9 ordinal.c:1765: Test failed: got 25 ordinal.c:1780: Test failed: got 6 ordinal.c:1793: Test failed: got 9 ordinal.c:1801: Test failed: got 9 ordinal.c:1815: Test failed: got 25 ordinal.c:1823: Test failed: got 25 ordinal.c:1853: Test failed: got 19 ordinal.c:1864: Test failed: got 22

June 22, 2010

Re: msvcrt/tests: Make test_dup2() static.

by testbot＠testbot.winehq.org

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=2829 Your paranoid android. === W98SE (32 bit file) === file.c:988: Test failed: smaller size block: Wrong error data () file.c:996: Test failed: smaller size block: Stdout file shouldn't contain data

June 22, 2010

Re: Getting into the spirit of things... crosstest

by Misha Koshelev

> On 6/22/2010 23:30, Misha Koshelev wrote: > > Dear All: > > > > As I am waiting for my wine GIT to compile, I have noticed that the > > following link no longer works: > > http://mirzam.it.vu.nl/mingw/ > > > > (from > > http://www.winehq.org/docs/winedev-guide/cross-compiling-tests > > for the MINGW WIN32API RPMS) > > > > I am running Ubuntu 10.04 and will first: > > i) try stock MINGW > > ii) then try to figure it out myself from sources if necessary > > > Page info is outdated probably. I don't have any problems with Debian 5 > package, as well as I didn't while was using Debian 4. > One problem I got was a libuuid a test was linked to. Now there's no > tests which import it, and newly added tests should go in without linking > to this lib. > > but if there are any other tips much appreciated. > > > > Thank you > > Misha > > > Thank you so much. Stock Ubuntu 10.04 amd64 mingw does indeed seem to be working! :) Misha p.s. :) misha(a)misha-d630:dpkg -l | grep mingw ii mingw32 4.2.1.dfsg-1ubuntu2 Minimalist GNU win32 (cross) compiler ii mingw32-binutils 2.20-0.1 Minimalist GNU win32 (cross) binutils ii mingw32-runtime 3.15.2-0ubuntu1 Minimalist GNU win32 (cross) runtime misha(a)misha-d630:~/src/wine/dlls/d3dx9_36$ uname -a Linux misha-d630 2.6.32-22-generic #36-Ubuntu SMP Thu Jun 3 19:31:57 UTC 2010 x86_64 GNU/Linux

June 22, 2010

Re: ddraw: Better validation of IDirectDrawSurface::BltFast parameters (2nd try)

by Iain Arnell

On Sat, Jun 19, 2010 at 9:02 AM, Iain Arnell <iarnell(a)gmail.com> wrote: > fixes #23238 - Repton 3: crashes when viewing map. > --- > dlls/ddraw/surface.c | 6 ++++++ > dlls/ddraw/tests/dsurface.c | 4 ++++ > 2 files changed, 10 insertions(+), 0 deletions(-) Scratch this - after thinking again about Henri's hint, I've moved the fix to wined3d. -- Iain.

June 22, 2010

Re: Add files generated by "make depend", PGO and gcov to .gitignore

by Alexandre Julliard

Peter Davies <ultratwo(a)gmail.com> writes: > Does this mean that "make depend" should be removed from README and > ./tools/wineinstall? It generates /conf* files. It shouldn't. What conf* files do you see? -- Alexandre Julliard julliard(a)winehq.org

June 22, 2010

Re: [PATCH 4/4] wined3d: use stretch_rect_fbo for swapchainless blits

by Roderick Colenbrander

On Wed, Apr 28, 2010 at 2:56 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 28 April 2010 14:29, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: >> + /* Early sort out of cases where no render target is used */ >> + if (!dstSwapchain && !srcSwapchain >> + && src_surface != device->render_targets[0] >> + && dst_surface != device->render_targets[0]) >> + { >> + if (fbo_blit_supported(&device->adapter->gl_info, BLIT_OP_BLIT, >> + &src_rect, src_surface->resource.usage, src_surface->resource.pool, src_surface->resource.format_desc, >> + &dst_rect, dst_surface->resource.usage, dst_surface->resource.pool, dst_surface->resource.format_desc)) >> + { >> + stretch_rect_fbo(device, src_surface, &src_rect, dst_surface, &dst_rect, Filter); >> + return WINED3D_OK; >> + } >> + >> + TRACE("No surface is render target, not using hardware blit.\n"); >> + return WINED3DERR_INVALIDCALL; >> + } >> + > You might as well try FBO blits first, before doing most of the other > checks. That's how it's eventually supposed to work anyway, and you > could remove the other strecth_rect_fbo() calls in that case. That > does depend on fbo_blit_supported() working properly, of course. > I'm investigating how I want to continue with this code after the code freeze is over. In the mean time I plan to write a few tests (if needed) to hopefully prevent regressions later on. I have a few questions left regarding this reply from a while back. In the end we want some mechanism to select the right blit_shader using 'blit_supported()' and use that to perform the requested blit. At this point I think that fbo_blit_supported() works properly for the cases we call stretch_rect_fbo (though there is still some unneeded if-statement in fbo_blit_supported which I still have to take out). Regarding BltOverride in what way did you want to 'try the FBO blit first'. Did you want fbo_blit_supported sorting out the 'unsupported swapchain cases' (it lacks surface info and only has flags) itself or was all you wanted just: if ( !unhandled_swapchain_cases && !color_keying && fbo_blit_supported(..)) stretch_rect_fbo(..); continue with all other checks I'm planning to write some more DirectDraw Blt tests to stress this code some more. Are there any specific tests (or perhaps some D3D9 tests) you want to see as well when I'm at it? Thanks, Roderick

June 22, 2010

Re: Getting into the spirit of things... crosstest

by Nikolay Sivov

On 6/22/2010 23:30, Misha Koshelev wrote: > Dear All: > > As I am waiting for my wine GIT to compile, I have noticed that the > following link no longer works: > http://mirzam.it.vu.nl/mingw/ > > (from > http://www.winehq.org/docs/winedev-guide/cross-compiling-tests > for the MINGW WIN32API RPMS) > > I am running Ubuntu 10.04 and will first: > i) try stock MINGW > ii) then try to figure it out myself from sources if necessary > Page info is outdated probably. I don't have any problems with Debian 5 package, as well as I didn't while was using Debian 4. One problem I got was a libuuid a test was linked to. Now there's no tests which import it, and newly added tests should go in without linking to this lib. > but if there are any other tips much appreciated. > > Thank you > Misha >

June 22, 2010

Re: Getting into the spirit of things... crosstest

by Jacek Caban

Hi Misha, On 6/22/10 9:30 PM, Misha Koshelev wrote: > Dear All: > > As I am waiting for my wine GIT to compile, I have noticed that the > following link no longer works: > http://mirzam.it.vu.nl/mingw/ > > (from > http://www.winehq.org/docs/winedev-guide/cross-compiling-tests > for the MINGW WIN32API RPMS) > > I am running Ubuntu 10.04 and will first: > i) try stock MINGW > ii) then try to figure it out myself from sources if necessary > > but if there are any other tips much appreciated The documentation is outdated. Wine no longer uses mingw importlibs (and uses its own instead), so you can install regular mingw package for your Linux distribution instead. Jacek

June 22, 2010

Getting into the spirit of things... crosstest

by Misha Koshelev

Dear All: As I am waiting for my wine GIT to compile, I have noticed that the following link no longer works: http://mirzam.it.vu.nl/mingw/ (from http://www.winehq.org/docs/winedev-guide/cross-compiling-tests for the MINGW WIN32API RPMS) I am running Ubuntu 10.04 and will first: i) try stock MINGW ii) then try to figure it out myself from sources if necessary but if there are any other tips much appreciated. Thank you Misha

June 22, 2010

Re: Add files generated by "make depend", PGO and gcov to .gitignore

by Peter Davies

Does this mean that "make depend" should be removed from README and ./tools/wineinstall? It generates /conf* files. Peter

June 22, 2010

Re: Add files generated by "make depend", PGO and gcov to .gitignore

by Alexandre Julliard

Peter Davies <ultratwo(a)gmail.com> writes: > @@ -79,6 +79,9 @@ my @ignores = ( > "*.ok", > "*.res", > "*.so", > + "*.gcno", > + "*.gcov", > + "/conf*", They are not generated by a standard build so they don't belong here. Put then in your local ignore file. -- Alexandre Julliard julliard(a)winehq.org

June 22, 2010

Re: I'm back

by Misha Koshelev

On Mon, 2010-06-21 at 15:27 -0700, James McKenzie wrote: > Misha Koshelev wrote: > > Dear All: > > > > Just wanted to let you know that after a long hiatus working on "big > > important" things, I now have time once again to contribute to the Wine > > project. > > > > I am going to have to take some time to get my feet wet, but the current > > plan, per suggestions of senior important Wine members :) is to work on > > DirectX and d3dx. > > > > Thus, I will focus on this. > > > > I look forward to our new and continued interactions. > > > Welcome back and I hope that you are pleased with the progress made in > your absence in both of these areas. However, much work needs to be done. > > James McKenzie > Wonderful and thank you for the welcome. I actually did not work on either of these areas prior to my return, but am very excited to be working on them now :) I especially love the wonderful Wine community. Misha

June 22, 2010

re: Yagmark and localized Windows

by Dan Kegel

I'd love to have yagmark be more internationalized. I did try to use button codes rather than english strings in wisotool, but sometimes it wasn't possible, and sometimes I didn't try hard enough. Not sure if I tried at all in yagmark yet. According to http://www.autohotkey.com/docs/commands/SetTitleMatchMode.htm Autohotkey supports regular expressions, so for the matching strings that can't be changed to button codes, we could list a bunch of alternatives, e.g. Save As|Enregistrer Sous Then the remaining mess is when we have to send a keystroke, we might need a switch statement to decide which keystroke to send based on the language. For the purposes of benchmarking wine, just setting LANG=en_US.UTF-8 solves the problem, but that doesn't help when you're trying to benchmark Windows. - Dan

June 22, 2010

Re: Yagmark and localized Windows

by Thomas Heckel

Francois Gouget schrieb: > I tested Yagmark on a Windows XP computer but I hit a snag with the > 3dmark 2000 and 2001 tests: they hang on the 'Save As' dialog because on > my French Windows XP it is called 'Enregistrer Sous'. > > I checked out the AutoHotKey documentation but they don't seem to have a > way to deal with this. Having a gettext-like function in AHK with a > built-in library of translations would have been nice. > > But maybe I am missing something. Is this something to handle outside > AHK? Did it get solved somewhere else already? (appinstall?) > > Should we be using some other way of identifying these dialogs? Like > some resource id or the id of a control it contains? > Hi Francois, I've dealed with similar problems with appinstall tests and german localization. I first tried to make generic language switches for system dialogues and for the specific application. Austin and Dan finally pointed out it's better to find ways which are language independent, i.e. the button number or other dialog parameters. Maybe it helps you further. bye thomas

June 22, 2010

Yagmark and localized Windows

by Francois Gouget

I tested Yagmark on a Windows XP computer but I hit a snag with the 3dmark 2000 and 2001 tests: they hang on the 'Save As' dialog because on my French Windows XP it is called 'Enregistrer Sous'. I checked out the AutoHotKey documentation but they don't seem to have a way to deal with this. Having a gettext-like function in AHK with a built-in library of translations would have been nice. But maybe I am missing something. Is this something to handle outside AHK? Did it get solved somewhere else already? (appinstall?) Should we be using some other way of identifying these dialogs? Like some resource id or the id of a control it contains? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Stolen from an Internet user: "f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng !"

June 22, 2010

Re: [hhctrl.ocx] Null pointer fix, new patch

by Jaroslav Šmíd

There is actually variable named "null" in the original source code, just read the whole function. It contains one character - terminating null. patch fixes http://bugs.winehq.org/show_bug.cgi?id=23247, see it for more information. On Tue, Jun 22, 2010 at 1:09 PM, Andrew Nguyen <arethusa26(a)gmail.com> wrote: > On Tue, Jun 22, 2010 at 5:56 AM, Jaroslav Šmíd <jardasmid(a)gmail.com> wrote: >> - info->WinType.pszCaption=strdupW(info->pCHMInfo->defTitle); >> + info->WinType.pszCaption=strdupW(info->pCHMInfo->defTitle ? >> info->pCHMInfo->defTitle : null); > > Perhaps I am missing something obvious, but isn't the new statement > practically the same as the one you removed? Adding a conditional > doesn't seem to change what strdupW receives, and thus what it > ultimately returns. > >> - info->WinType.pszFile=strdupW(info->pCHMInfo->defTopic); >> + info->WinType.pszFile=strdupW(info->pCHMInfo->defTopic ? >> info->pCHMInfo->defTopic : null); > > Same thing. Also, did you actually compile and test this patch? I > would think that writing "null" wouldn't compile. > -- Jaroslav Šmíd

June 22, 2010

Re: winex11.drv: warn and return when UploadGlyph fails in X11DRV_XRender_ExtTextOut

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > commit 082bc5ccbcc35e2058f1a3cd5c52345edf760631 > Author: Aric Stewart <aric(a)codeweavers.com> > Date: Tue Jun 22 16:58:38 2010 +0900 > > winex11.drv: warn and return when UploadGlyph fails in X11DRV_XRender_ExtTextOut > > this prevents crashing later when we are assuming that all the glyphs in the string have been realized and have valid data. Missing glyphs should be replaced by the font default char or something like that. -- Alexandre Julliard julliard(a)winehq.org

June 22, 2010

Re: wininet: Allow HTTPREQ_ReadFileEx read more then one data chunk

by Alexandre Julliard

Piotr Caban <piotr(a)codeweavers.com> writes: > + read = 0; > + size = buffers->dwBufferLength; > + > + EnterCriticalSection( &req->read_section ); > + while(1) { > + res = HTTPREQ_Read(req, (char*)buffers->lpvBuffer+read, size-read, > + &buffers->dwBufferLength, !(flags & IRF_NO_WAIT)); > + if(res == ERROR_SUCCESS) > + read += buffers->dwBufferLength; > + else > + break; > + > + if(!req->read_chunked || read==size || req->dwContentLength!=req->dwContentRead > + || !req->dwContentLength || (req->gzip_stream && req->gzip_stream->end_of_data)) > + break; > + > + INTERNET_SendCallback(&req->hdr, req->hdr.dwContext, INTERNET_STATUS_RESPONSE_RECEIVED, > + &buffers->dwBufferLength, sizeof(buffers->dwBufferLength)); > + INTERNET_SendCallback(&req->hdr, req->hdr.dwContext, > + INTERNET_STATUS_RECEIVING_RESPONSE, NULL, 0); Calling the callbacks while holding the critical section is not a good idea. -- Alexandre Julliard julliard(a)winehq.org

June 22, 2010

Re: [hhctrl.ocx] Null pointer fix, new patch

by Andrew Nguyen

On Tue, Jun 22, 2010 at 6:13 AM, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > On 6/22/2010 15:09, Andrew Nguyen wrote: >> >> On Tue, Jun 22, 2010 at 5:56 AM, Jaroslav Šmíd<jardasmid(a)gmail.com> >> wrote: >> >>> >>> - info->WinType.pszCaption=strdupW(info->pCHMInfo->defTitle); >>> + info->WinType.pszCaption=strdupW(info->pCHMInfo->defTitle ? >>> info->pCHMInfo->defTitle : null); >>> >> >> Perhaps I am missing something obvious, but isn't the new statement >> practically the same as the one you removed? Adding a conditional >> doesn't seem to change what strdupW receives, and thus what it >> ultimately returns. >> > > static const WCHAR null[] = {0}; > > > > > You're perfectly correct, and I should have known better. I should perhaps get some rest.

June 22, 2010

Re: [hhctrl.ocx] Null pointer fix, new patch

by Nikolay Sivov

On 6/22/2010 15:09, Andrew Nguyen wrote: > On Tue, Jun 22, 2010 at 5:56 AM, Jaroslav Šmíd<jardasmid(a)gmail.com> wrote: > >> - info->WinType.pszCaption=strdupW(info->pCHMInfo->defTitle); >> + info->WinType.pszCaption=strdupW(info->pCHMInfo->defTitle ? >> info->pCHMInfo->defTitle : null); >> > Perhaps I am missing something obvious, but isn't the new statement > practically the same as the one you removed? Adding a conditional > doesn't seem to change what strdupW receives, and thus what it > ultimately returns. > static const WCHAR null[] = {0};

June 22, 2010

Re: [hhctrl.ocx] Null pointer fix, new patch

by Andrew Nguyen

On Tue, Jun 22, 2010 at 5:56 AM, Jaroslav Šmíd <jardasmid(a)gmail.com> wrote: > - info->WinType.pszCaption=strdupW(info->pCHMInfo->defTitle); > + info->WinType.pszCaption=strdupW(info->pCHMInfo->defTitle ? > info->pCHMInfo->defTitle : null); Perhaps I am missing something obvious, but isn't the new statement practically the same as the one you removed? Adding a conditional doesn't seem to change what strdupW receives, and thus what it ultimately returns. > - info->WinType.pszFile=strdupW(info->pCHMInfo->defTopic); > + info->WinType.pszFile=strdupW(info->pCHMInfo->defTopic ? > info->pCHMInfo->defTopic : null); Same thing. Also, did you actually compile and test this patch? I would think that writing "null" wouldn't compile.

June 22, 2010

Re: [PATCH] ddraw: Grow indexbuffer as needed

by Henri Verbeet

On 22 June 2010 09:15, Mikko Rasa <tdb(a)tdb.fi> wrote: > --- > dlls/ddraw/device.c | 27 ++++++++++++++++++++++++++- > 1 files changed, 26 insertions(+), 1 deletions(-) > This looks mostly ok, except for two things: - We'll probably want to grow the buffer by doubling the size until it's large enough (but be careful not to overflow the maximum value of an UINT) - The "child" pointer of "parent" will still be set to the old index buffer, so the relevant code in IDirect3DDeviceImpl_7_Release() / IParentImpl_Release() is going to try to release the old index buffer again.

June 22, 2010

Re: damnit, X is crashing *every* time I run 3dmark2000

by Scott Ritchie

On 06/22/2010 01:44 AM, Maarten Lankhorst wrote: > Hi Scott, > > 2010/6/22 Scott Ritchie <scott(a)open-vote.org>: >> On 06/21/2010 08:48 PM, Dan Kegel wrote: >>> And always after test 17 of 20, I think. I updated to the latest >>> nvidia driver supported by Ubuntu 10.04, no change. >>> >>> The crash persists even with WINEDEBUG=+d3d,+d3d7,+synchronous. >>> >>> I guess my next move is to drop 3dmark2000. >>> >>> >> >> This is exactly what I had hoped to happen when I experimented with >> putting Wine's test suite in checkbox (Ubuntu's main QA tool). I'll see >> if I can add yagmark to it too and then send it upstream so the tests >> get run semi-regularly on maverick. >> >> Maybe then we won't end up with a crashing driver in the release. > Depends, all d3d tests still seem a bit flaky on open source drivers, > sometimes even crashing Xorg entirely. :) > > Cheers, > Maarten That was exactly the point - to use Wine's test suite as a "make X crash" tool. That way Ubuntu can detect when it's shipping a buggy driver well before release. Thanks, Scott Ritchie

June 22, 2010

Re: Addition of En resources to non-En resources

by Francois Gouget

On Sun, 20 Jun 2010, Dmitry Timoshkov wrote: > James McKenzie <jjmckenzie51(a)earthlink.net> wrote: > > > Another good reason to drop .rc files and go with the po flow... > > Not really. If you'd know what stuff the .rc files contain you wouldn't do > such claims. The .rc files can't go away in general. James never meant that Wine would not use rc files at all. What he meant is that rc files would lose their status as the autoritative source for the resource strings and would be mostly generated from po files. > James, please learn subject before commenting. Doubly so before dishing out harsh critisism. James' meaning was obvious for anyone remotely involved in the move to po files. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt IP over Avian Carriers with Quality of Service

June 22, 2010

Re: winecfg: Update Portuguese translation

by Frédéric Delanoy

2010/6/22 Gustavo <gugamilare(a)gmail.com> > Second try. > > Gustavo Henrique Milaré > gugamilare(a)gmail.com If you resend the same patch, append (resend), if it was changed, append (try N). Cf. http://wiki.winehq.org/SubmittingPatches#head-2753aa29adcd5dfc10a88d4370973… Frédéric Delanoy

June 22, 2010

Re: damnit, X is crashing *every* time I run 3dmark2000

by Maarten Lankhorst

Hi Scott, 2010/6/22 Scott Ritchie <scott(a)open-vote.org>: > On 06/21/2010 08:48 PM, Dan Kegel wrote: >> And always after test 17 of 20, I think. I updated to the latest >> nvidia driver supported by Ubuntu 10.04, no change. >> >> The crash persists even with WINEDEBUG=+d3d,+d3d7,+synchronous. >> >> I guess my next move is to drop 3dmark2000. >> >> > > This is exactly what I had hoped to happen when I experimented with > putting Wine's test suite in checkbox (Ubuntu's main QA tool). I'll see > if I can add yagmark to it too and then send it upstream so the tests > get run semi-regularly on maverick. > > Maybe then we won't end up with a crashing driver in the release. Depends, all d3d tests still seem a bit flaky on open source drivers, sometimes even crashing Xorg entirely. :) Cheers, Maarten

June 22, 2010

Re: damnit, X is crashing *every* time I run 3dmark2000

by Scott Ritchie

On 06/21/2010 08:48 PM, Dan Kegel wrote: > And always after test 17 of 20, I think. I updated to the latest > nvidia driver supported by Ubuntu 10.04, no change. > > The crash persists even with WINEDEBUG=+d3d,+d3d7,+synchronous. > > I guess my next move is to drop 3dmark2000. > > This is exactly what I had hoped to happen when I experimented with putting Wine's test suite in checkbox (Ubuntu's main QA tool). I'll see if I can add yagmark to it too and then send it upstream so the tests get run semi-regularly on maverick. Maybe then we won't end up with a crashing driver in the release. Thanks, Scott Ritchie

June 22, 2010

Re: damnit, X is crashing *every* time I run 3dmark2000

by Edward Savage

On Tue, Jun 22, 2010 at 1:48 PM, Dan Kegel <dank(a)kegel.com> wrote: > And always after test 17 of 20, I think. I updated to the latest > nvidia driver supported by Ubuntu 10.04, no change. > > The crash persists even with WINEDEBUG=+d3d,+d3d7,+synchronous. > > I guess my next move is to drop 3dmark2000. > This is on the Steam page and covers your issue I believe. WARNING Nvidia 185 Driver Series Crash If you are using nVidia 185.x series drivers your X may crash when attempting to run this application. This is not a Wine bug and the solution is to upgrade your drivers. You can do this via nvidia.com or your distros package management system. Ubuntu 9.10 users can add the nvidia-vdpau PPA to obtain the upgrade.

June 22, 2010

damnit, X is crashing *every* time I run 3dmark2000

by Dan Kegel

And always after test 17 of 20, I think. I updated to the latest nvidia driver supported by Ubuntu 10.04, no change. The crash persists even with WINEDEBUG=+d3d,+d3d7,+synchronous. I guess my next move is to drop 3dmark2000.

June 22, 2010

Re: Patches for Hebrew and Arabic

by Austin English

On Mon, Jun 21, 2010 at 4:00 PM, Yaron Shahrabani <sh.yaron(a)gmail.com> wrote: > > Yaron Shahrabani There's a few problems... A) Please send one patch per email. B) The patches are incorrect: 0002-Arabic-Patch.patch: --- programs/notepad/Makefile.in | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/programs/notepad/Makefile.in b/programs/notepad/Makefile.in index 6b1fcdd..a0598e7 100644 --- a/programs/notepad/Makefile.in +++ b/programs/notepad/Makefile.in @@ -24,7 +24,6 @@ RC_SRCS = \ Es.rc \ Fi.rc \ Fr.rc \ - He.rc Hu.rc \ It.rc \ Ja.rc \ -- 1.7.0.4 You're removing the Hebrew rc file, but nothing else. 0003-Hebrew-Patch.patch: --- programs/notepad/Makefile.in | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/programs/notepad/Makefile.in b/programs/notepad/Makefile.in index a0598e7..372390e 100644 --- a/programs/notepad/Makefile.in +++ b/programs/notepad/Makefile.in @@ -14,7 +14,6 @@ C_SRCS = \ main.c RC_SRCS = \ - Ar.rc \ Bg.rc \ Cs.rc \ Da.rc \ @@ -24,6 +23,7 @@ RC_SRCS = \ Es.rc \ Fi.rc \ Fr.rc \ + He.rc \ Hu.rc \ It.rc \ Ja.rc \ -- 1.7.0.4 You're adding Hebrew back and removing Arabic. Neither patch actually adds a translation. You probably forgot to use 'git add' to tell git to add the file in your commit. You should also use a more helpful commit message. For example: notepad: add Hebrew translation Thanks for helping Wine! -- -Austin

June 21, 2010

Re: I'm back

by James McKenzie

Misha Koshelev wrote: > Dear All: > > Just wanted to let you know that after a long hiatus working on "big > important" things, I now have time once again to contribute to the Wine > project. > > I am going to have to take some time to get my feet wet, but the current > plan, per suggestions of senior important Wine members :) is to work on > DirectX and d3dx. > > Thus, I will focus on this. > > I look forward to our new and continued interactions. > Welcome back and I hope that you are pleased with the progress made in your absence in both of these areas. However, much work needs to be done. James McKenzie

June 21, 2010

I'm back

by Misha Koshelev

Dear All: Just wanted to let you know that after a long hiatus working on "big important" things, I now have time once again to contribute to the Wine project. I am going to have to take some time to get my feet wet, but the current plan, per suggestions of senior important Wine members :) is to work on DirectX and d3dx. Thus, I will focus on this. I look forward to our new and continued interactions. Misha Koshelev

June 21, 2010

Re: kernel32: Fix test output

by testbot＠testbot.winehq.org

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=2813 Your paranoid android. === W7PRO (32 bit thread) === thread.c:443: Test failed: threadFunc2 did not exit during 100 ms === W7PROX64 (64 bit thread) === thread.c:1394: Test failed: Expected FPU control word 0x27f, got 0x37f.

June 21, 2010

Re: [APPDB] Updated test_appData

by Alexander Nicolaysen Sørnes

Mandag 21. juni 2010 22.40.22 skrev Alexandru Băluț : > Hi Alexander, > > On Mon, Jun 21, 2010 at 21:52, Alexander Nicolaysen Sørnes < > > alex(a)thehandofagony.com> wrote: > > Mandag 21. juni 2010 20.52.20 skrev Alexandru Băluț : > > > Updated test_appData, because using downloadurl objects does not work > > > anymore, because appData.listSubmittedBy() ignores queued downloadurls. > > > I also fixed a bug in url.php: after creating an Url, the create > > > function does not update the object properly. > > > > Hello, > > > > It's great that you're submitting patches! You could split this patch in > > two, > > since it contains two separate changes. > > I was thinking the changed test also works as a test case for the url.php > change.. It does not matter, I'll resend. > > > Also, I see that you're using GIT to generate the patches. Could you do > that > > > with 'git format-patch -o out' and send the files generated in out/? > > What would be the improvement over the way I submitted the last 2 patches? > > Thanks, > Alex > It includes your name in the patch file so that you get credited for your contributions :) I have applied your patches now. Alexander

June 21, 2010

Re: [APPDB] Updated test_appData

by Alexandru Băluț

Hi Alexander, On Mon, Jun 21, 2010 at 21:52, Alexander Nicolaysen Sørnes < alex(a)thehandofagony.com> wrote: > Mandag 21. juni 2010 20.52.20 skrev Alexandru Băluț : > > Updated test_appData, because using downloadurl objects does not work > > anymore, because appData.listSubmittedBy() ignores queued downloadurls. > > I also fixed a bug in url.php: after creating an Url, the create function > > does not update the object properly. > > > > Hello, > > It's great that you're submitting patches! You could split this patch in > two, > since it contains two separate changes. > I was thinking the changed test also works as a test case for the url.php change.. It does not matter, I'll resend. Also, I see that you're using GIT to generate the patches. Could you do that > with 'git format-patch -o out' and send the files generated in out/? > What would be the improvement over the way I submitted the last 2 patches? Thanks, Alex

June 21, 2010

Re: [APPDB] Updated test_appData

by Alexander Nicolaysen Sørnes

Mandag 21. juni 2010 20.52.20 skrev Alexandru Băluț : > Updated test_appData, because using downloadurl objects does not work > anymore, because appData.listSubmittedBy() ignores queued downloadurls. > I also fixed a bug in url.php: after creating an Url, the create function > does not update the object properly. > Hello, It's great that you're submitting patches! You could split this patch in two, since it contains two separate changes. Also, I see that you're using GIT to generate the patches. Could you do that with 'git format-patch -o out' and send the files generated in out/? Alexander N. Sørnes

June 21, 2010

Fwd: Italian translation of Wine at 100%

by Luca Bennati

---------- Forwarded message ---------- From: Luca Bennati <lucak3(a)gmail.com> Date: 2010/6/21 Subject: Re: Italian translation of Wine at 100% To: Paul Vriens <paul.vriens.wine(a)gmail.com> 2010/6/21 Paul Vriens <paul.vriens.wine(a)gmail.com> Hi, > > And another one at a 100% !!! > > Many thanks to Luca for his efforts to get us this far. > > -- > Cheers, > > Paul. > Having completed this target before 1.2 release, i'm very happy, but surely the best is that now it won't be as strenous to keep it up to date. :) good luck to all the others translators.

June 21, 2010

Italian translation of Wine at 100%

by Paul Vriens

Hi, And another one at a 100% !!! Many thanks to Luca for his efforts to get us this far. -- Cheers, Paul.

June 21, 2010

Re: Richedit: Initial tests for EM_FINDWORDBREAK

by James McKenzie

(Marvin) wrote: > 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=2806 > > Your paranoid android. > > > === W7PRO (32 bit editor) === > editor.c:4696: Test failed: test paste: strcmp = 1, text='testing paste > editor.c:4714: Test failed: test paste: strcmp = 1 > editor.c:4726: Test failed: test paste: strcmp = -1 > editor.c:4756: Test failed: test paste: strcmp = -1, actual = 'Ts' > editor.c:5971: Test failed: Cursor is at 0 instead of 4 > editor.c:5977: Test failed: Cursor is at 0 instead of 9 > editor.c:5983: Test failed: Cursor is at 0 instead of 4 > editor.c:5997: Test failed: Cursor is at 8 instead of 9 > editor.c:6005: Test failed: Cursor is at 11 instead of 9 > editor.c:6016: Test failed: Cursor is at 0 instead of 8 > editor.c:6041: Test failed: Cursor is at 0 instead of 8 > > Random errors from running richedit tests... James McKenzie

June 21, 2010

Re: Richedit: Initial tests for EM_FINDWORDBREAK

by testbot＠testbot.winehq.org

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=2806 Your paranoid android. === W7PRO (32 bit editor) === editor.c:4696: Test failed: test paste: strcmp = 1, text='testing paste editor.c:4714: Test failed: test paste: strcmp = 1 editor.c:4726: Test failed: test paste: strcmp = -1 editor.c:4756: Test failed: test paste: strcmp = -1, actual = 'Ts' editor.c:5971: Test failed: Cursor is at 0 instead of 4 editor.c:5977: Test failed: Cursor is at 0 instead of 9 editor.c:5983: Test failed: Cursor is at 0 instead of 4 editor.c:5997: Test failed: Cursor is at 8 instead of 9 editor.c:6005: Test failed: Cursor is at 11 instead of 9 editor.c:6016: Test failed: Cursor is at 0 instead of 8 editor.c:6041: Test failed: Cursor is at 0 instead of 8

June 21, 2010

Re: [2/2] kernel32/tests: add test for CT_TYPE1 of GetStringTypeW

by Aric Stewart

I started by writing test testing characters based on unicode class. I used that to generate a first step of cpmap.pl. Then I wrote a program that dumped the C1_TYPE for every chracter between 0 and 0xffff, and diffed the output from windows 7 with the output from wine. That is how I generated the exceptions. Then I ran my resulting tests repeatedly though the testbot to get what the variations where between win98 and windows7. Things are not identical to windows7 because i think wine is using a more recent unicode spec and defines more characters that windows7 appears to. -aric James McKenzie wrote: > Aric Stewart wrote: >> ------------------------------------------------------------------------ >> >> > Aric: > > Where did you find the new values for C1_TYPE? > > James McKenzie > > >

June 21, 2010

Re: [2/2] kernel32/tests: add test for CT_TYPE1 of GetStringTypeW

by James McKenzie

Aric Stewart wrote: > ------------------------------------------------------------------------ > > Aric: Where did you find the new values for C1_TYPE? James McKenzie

June 21, 2010

Re: ntdll: fix race in NtRead/WriteFile

by Eric Pouech

why not simply setting send_completion to cvalue instead of TRUE, and remove the now unneeded test to cvalue ? - send_completion = TRUE; + send_completion = cvalue != 0; .... - if (send_completion && cvalue) .... + if (send_completion) .... A+ 2010/6/21 Andrey Turkin <andrey.turkin(a)gmail.com> > Long overdue patch to fix bug 11188 - make sure to send i/o completions > after all interactions with i/o status block are performed. > --- > dlls/ntdll/file.c | 24 ++++++++++++++++++++---- > 1 files changed, 20 insertions(+), 4 deletions(-) > > > > > -- -- Eric Pouech

June 21, 2010

Is the appData table still holding bug links?

by Alexandru Băluț

Hi, I see the "type" column in the appData table is an enum('screenshot','url','bug','downloadurl'), and I noticed that when linking a bug to a Version, a row is added in the buglinks table, not in appData. Is it ok to change the type of that column to enum('screenshot','url','downloadurl') - or shall I add a comment and say that it's obsolete, and that buglinks should be used instead? Thanks, Alex

June 21, 2010

Re: Release plans

by Scott Ritchie

On 06/20/2010 01:45 PM, wylda(a)volny.cz wrote: > > Hi, another week and Sunday gone, but this time i tried to look a bit > closely to the numbers... > > 340 regressions <-- release announcement > 356 regressions <-- release announcement + 1week > 339 regressions <-- release announcement + 2weeks(rc1) > 322 regressions <-- release announcement + 3weeks(rc2) > 325 regressions <-- release announcement + 4weeks > 326 regressions <-- release announcement + 5weeks(rc3) > 325 regressions <-- release announcement + 6weeks(rc4) > > > 3rd week in a row and unfortunately these numbers don't change significantly > to zero. Based on these following numbers we can't even say, that we > close at the same rate as new are opened. Closer look to "fixing" capacity > or in other words what is behind -1 fixed regression for this week: > > +24 Newly marked, opened (new/unconfirmed) > -16 Closed, resolved fixed > -09 Not a regression (invalid, duplicate) > ==== > -1 > > More IN than OUT could show that stable release is far a way. > I'll note that you'll see a very similar measure when just looking at Wine bugs in general. We are, nevertheless, making progress ;) Still, I do support delaying the release until it feels like there's a substantial drop in non-deferred patches. That's the sign that tells us we've run out of easy enough release bugs/regressions to fix and may as well release. Thanks, Scott Ritchie

June 21, 2010

Re: Speed/latency issues for development in a Wine environment

by Jeff Zaroyko

On Sun, Jun 20, 2010 at 1:46 PM, Alan W. Irwin <irwin(a)beluga.phys.uvic.ca> wrote: > > So for mingw32-make our wine startup latencies are essentially identical > (near 150 ms) and substantially worse than the Windows numbers (30 ms) and > much worse than the Linux numbers (~1 ms). "make" startup latency matters > for builds configured by CMake because typically the top-level Makefile > is configured in a way to run make many times per > build. > > "cmake" startup latency also matters a lot because special modes for it are > used during the build (typically two times per object file that is compiled > by gcc) to figure out dependencies, keep track of progress, etc. If you are > game for one more download (from > http://cmake.org/cmake/resources/software.html) what are your cmake > --version startup latency numbers? > > > In sum, you do have one rather large startup latency for mingw32-make that > agrees with mine and which confirms the problem in that case and a much > shorter startup latency for an old version of MinGW compared to mine. So > the results are currently ambiguous, but we will find out more if you are > willing to do the appropriate downloads of CMake and modern MinGW gcc. > > Thanks for your continuing help in narrowing down the factor(s) that are > killing performance for CMake-based builds under Wine. > > Alan I'd test further but unfortunately it seems as though my video card (nvidia 8800) has bought the farm - no video signal at POST following a system freeze, which leaves me with only a Windows laptop. Jeff

June 21, 2010

RFC: Patch to add EM_FINDWORDBREAK tests

by James McKenzie

All: While working on a problem with The Sword (a bible program), I noticed that an empty yellow box kept appearing. I then ran the program from the terminal and up popped what looked like a never ending stream of EM_FINDWORDBREAK stub entries. A further investigation (with Google's help) reveals that Brian Chang submitted implementation of this function with tests. I then found Dan's reply that one of the tests needed. I attempted to add this test and am requesting assistance, and if possible crosstest file so I can run it on XP. Thank you. James McKenzie

June 21, 2010

Re: *_queue.php files in AppDB

by Alexander Nicolaysen Sørnes

They are wrapper classes for submitting and processing new entries to the AppDB. When submitting an entry, such as a version, we also need a testData entry, maybe also a maintainer, downloadurl, monitor, or distribution entry. This is handled in the _queue clases. Alexander N. Sørnes Mandag 21. juni 2010 01.00.16 skrev Alexandru Băluț : > Hi, > > Why exactly are these AppDB files needed? > > ./include/testData_queue.php > ./include/version_queue.php > ./include/application_queue.php > > Thanks, > Alex >

June 20, 2010

Re: richedit: Add WB_ISDELIMITER value to richedit.h

by James McKenzie

Dylan Smith wrote: > On Sun, Jun 20, 2010 at 6:00 PM, James McKenzie > <jjmckenzie51(a)earthlink.net <mailto:jjmckenzie51(a)earthlink.net>> wrote: > > While looking for implementation guidance at google.com > <http://google.com>, came across the value for WB_ISDELIMITER > which was not in richedit.h. This patch adds this value which > will be necessary for full implementation of this function. > > WB_LEFT, WB_RIGHT, and WB_ISDELIMITER are defined in winuser.h because > they are used by the normal edit control. The other WB_* constants > are used by the richedit control, so are defined in richedit.h. > > Just include winuser.h. You are correct. I've added a line to my in-process richedit.h to annotate this. The patch can and should be ignored. BTW, I'm looking at an old patch (again) and am working on the tests first. James McKenzie

June 20, 2010

*_queue.php files in AppDB

by Alexandru Băluț

Hi, Why exactly are these AppDB files needed? ./include/testData_queue.php ./include/version_queue.php ./include/application_queue.php Thanks, Alex

June 20, 2010

Re: richedit: Add WB_ISDELIMITER value to richedit.h

by Dylan Smith

On Sun, Jun 20, 2010 at 6:00 PM, James McKenzie <jjmckenzie51(a)earthlink.net>wrote: > While looking for implementation guidance at google.com, came across the > value for WB_ISDELIMITER which was not in richedit.h. This patch adds this > value which will be necessary for full implementation of this function. > > WB_LEFT, WB_RIGHT, and WB_ISDELIMITER are defined in winuser.h because they are used by the normal edit control. The other WB_* constants are used by the richedit control, so are defined in richedit.h. Just include winuser.h.

June 20, 2010

Help wanted for bug#3023

by Eliot Blennerhassett

Greetings, I'm hoping to get some with disposing of http://bugs.winehq.org/show_bug.cgi?id=3023 Short summary: Commenting line 934 of dlls/user32/dialog.c in EndDialog makes OrCad (electronic schematic cad package) usable (otherwise several essential functions don't work) EndDialog( HWND hwnd, INT_PTR retval ) { ... // comment the following line if (hwnd == GetActiveWindow()) WINPOS_ActivateOtherWindow( hwnd ); ... } MSDN says "HWND A handle to the dialog box to be destroyed. Dialog boxes created by the DialogBox, DialogBoxParam, DialogBoxIndirect, and DialogBoxIndirectParam functions must be destroyed using the EndDialog function. An application calls EndDialog from within the dialog box procedure; the function must not be used for any other purpose. " Now, can anybody explain what the purpose of the suspect line is? or what possible bad things might happen if it was removed? I have run Wine for several years with this one line patch, and seen no ill effects AFAIK. If removing the line completely is not an option, is there a way to conditinally avoid executing it based on environment or registry? eg if (!ALLOW_ORCAD_TO_WORK) { original code } thanks -- Eliot Blennerhassett 5 years of recompiling wine from source with a 1 line patch...

June 20, 2010

Help wanted re Bugzilla#3023 (one line fix for Orcad add new elements)

by Eliot Blennerhassett

Greetings, Help wanted Re: http://bugs.winehq.org/show_bug.cgi?id=3023 Short summary: Commenting line 934 of dlls/user32/dialog.c in EndDialog makes OrCad usable. EndDialog( HWND hwnd, INT_PTR retval ) { ... // comment the following line if (hwnd == GetActiveWindow()) WINPOS_ActivateOtherWindow( hwnd ); ... } MSDN says "HWND A handle to the dialog box to be destroyed. Dialog boxes created by the DialogBox, DialogBoxParam, DialogBoxIndirect, and DialogBoxIndirectParam functions must be destroyed using the EndDialog function. An application calls EndDialog from within the dialog box procedure; the function must not be used for any other purpose. " Now, can anybody explain what the purpose of the suspect line is? or what possible bad things might happen if it was removed. I have run Wine for several years with this one line patch, and seen no ill effects AFAIK. If removing the line completely is not an option, is there a way to conditinally avoid executing it based on environment or registry? eg if (!ALLOW_ORCAD_TO_WORK) { original code } thanks -- Eliot Blennerhassett

June 20, 2010

Re: Release plans

by wylda＠volny.cz

Hi, another week and Sunday gone, but this time i tried to look a bit closely to the numbers... 340 regressions <-- release announcement 356 regressions <-- release announcement + 1week 339 regressions <-- release announcement + 2weeks(rc1) 322 regressions <-- release announcement + 3weeks(rc2) 325 regressions <-- release announcement + 4weeks 326 regressions <-- release announcement + 5weeks(rc3) 325 regressions <-- release announcement + 6weeks(rc4) 3rd week in a row and unfortunately these numbers don't change significantly to zero. Based on these following numbers we can't even say, that we close at the same rate as new are opened. Closer look to "fixing" capacity or in other words what is behind -1 fixed regression for this week: +24 Newly marked, opened (new/unconfirmed) -16 Closed, resolved fixed -09 Not a regression (invalid, duplicate) ==== -1 More IN than OUT could show that stable release is far a way. Another relese barometr could be Milestones 1.2: 59 bugs <-- release announcement + 5weeks(rc3) 46 bugs <-- release announcement + 6weeks(rc4) Decoding shows much better numbers than in case of regressions: +02 Newly marked, opened (new/unconfirmed) -11 Closed, resolved fixed -04 Not a Milestone-1.2 ==== -13 W.

June 20, 2010

Re: WineSkin v0.01

by Michael Mc Donnell

On Fri, Jun 18, 2010 at 9:47 PM, ryan woodsmall <rwoodsmall(a)mac.com> wrote: >> Hi All, >> >> I just wanted to highlight my new project - WineSkin >> >> http://www.airwebreathe.org.uk/wineskin/ > > Might want to rethink the name: > > http://wineskin.doh123.com/Information.html How about the name WineLooks instead of wineskin? That would be a reference to Clearlooks in Gnome. Looks really nice btw :-) Michael Mc Donnell

June 20, 2010

Re: New flags in LoadLibraryEx

by Juan Lang

Hi Mariusz, > if( flags & LOAD_IGNORE_CODE_AUTHZ_LEVEL ) > FIXME("unsupported flag: LOAD_IGNORE_CODE_AUTHZ_LEVEL\n"); > > if( flags & LOAD_LIBRARY_AS_IMAGE_RESOURCE ) > FIXME("unsupported flag: LOAD_LIBRARY_AS_IMAGE_RESOURCE\n"); > > if( flags & LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE ) { > FIXME("unsupported flag: LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE\n"); > /* temporary solution which should let some application working */ > flags |= LOAD_LIBRARY_AS_DATAFILE; > } > > if( flags & LOAD_LIBRARY_REQUIRE_SIGNED_TARGET ) > FIXME("unsupported flag: LOAD_LIBRARY_REQUIRE_SIGNED_TARGET\n"); This is a bit verbose. Better to create some constant with all the unsupported flags, e.g. static const DWORD unsupported = LOAD_IGNORE_CODE_AUTHZ_LEVEL | LOAD_LIBRARY_AS_IMAGE_RESOURCE... then check if any of them is set. --Juan

June 20, 2010

New flags in LoadLibraryEx

by Mariusz Pluciński

Hello, wine-devel It seems, that Microsoft introduced new flags for kernel32.LoadLibraryEx function, which are not yet available in Wine. Those flags are: LOAD_IGNORE_CODE_AUTHZ_LEVEL, LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE, LOAD_LIBRARY_AS_IMAGE_RESOURCE and LOAD_LIBRARY_REQUIRE_SIGNED_TARGET. Most of them were added with Vista introduction, and the last one is not documented in MSDN. I don't want to implement them (at least, not now), but want to add some "stubby" support. So, I added flags into winuser.h and the following code on the beginning of kernel32.load_library routine: if( flags & LOAD_IGNORE_CODE_AUTHZ_LEVEL ) FIXME("unsupported flag: LOAD_IGNORE_CODE_AUTHZ_LEVEL\n"); if( flags & LOAD_LIBRARY_AS_IMAGE_RESOURCE ) FIXME("unsupported flag: LOAD_LIBRARY_AS_IMAGE_RESOURCE\n"); if( flags & LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE ) { FIXME("unsupported flag: LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE\n"); /* temporary solution which should let some application working */ flags |= LOAD_LIBRARY_AS_DATAFILE; } if( flags & LOAD_LIBRARY_REQUIRE_SIGNED_TARGET ) FIXME("unsupported flag: LOAD_LIBRARY_REQUIRE_SIGNED_TARGET\n"); Of course it works, but is it acceptable by Wine project?

June 20, 2010

Re: Addition of En resources to non-En resources

by James McKenzie

Dmitry Timoshkov wrote: > James McKenzie <jjmckenzie51(a)earthlink.net> wrote: > > >> Another good reason to drop .rc files and go with the po flow... >> > > Not really. If you'd know what stuff the .rc files contain you wouldn't do > such claims. The .rc files can't go away in general. James, please learn > subject before commenting. > > Dmitry: I know what .rc files do. I also know that adding .po functionality will reduce the size of the .rc files. Also, adding a new language will not take as much effort and will allow build-out in stages. That is one of the wonderful features of using these files. Right now, we are missing major language groups. Adding .po functionality might make it easier to add them. And my comment was that it appears that Wine is making a stride forward to assist those whose native language is NOT English. James McKenzie

June 20, 2010

Re: DIBEngine and gdi32/user32 controls drawing loop performance

by James McKenzie

Amico Amico wrote: > Hello, > since I had a poor performance in drawing many buttons and text input > fields at the same time into a window with wine, I applied the > DIBEngine patch (http://wiki.winehq.org/DIBEngine) that is available > for wine 1.1.44 (http://bugs.winehq.org/attachment.cgi?id=27879) to > the 1.1.44 version of wine and started my application program that > needs to draw many button and text input fields in a single window > with the enviroment variable "WINEDIB=ON wine ./App.exe". > > Now that the DIBEngine patch is applied a little speedup in the > drawing of the buttons and the text input fields is shown, but now the > problem is that they are still drawn in blocks of a subset of the > total number and then wine waits a little bit, then it draws another > block of text input fields and buttons and then wine still waits, then > it draws, and so on. The result is that my App.exe application window > that is full of buttons and text input fields is drawn in subsequent > times, and groups of buttons and input fields are drawn in blocks with > a delay between the drawing of a group of controls and the others. This does duplicate Windows performance as not all controls are drawn at the same time. If you used a slower/older machine this is very apparent. Because of the delays induced by Wine's use of opengl this shows. > > The fact that not all the controls are drawn at a time but in more > times is frustrating, since the CPU is a core2duo, and I think that it > is powerful enough to draw all of the controls in the window at a > time, specially with the DIBEngine patch applied and the DIBEngine > activated. So I thought that the problem could be in the main event > loop that manages the App.exe application window, and in particular > the problem could be that the loop yields the drawing of the controls > after a certain number of controls have been drawn in order to avoid > CPU high load and then the loop starts again to draw other controls > after a while and then it stops and yields and waits again, and so on. This is what Windows does as well. It is very interesting to watch on my older PIII/750 machine running WindowsXP. However, if you feel that you can improve performance, you are welcome to try. I plan on picking up and examining the DIB Engine code after the release of Wine 1.2 and building a few more features that are missing from richedit. James McKenzie

June 20, 2010

DIBEngine and gdi32/user32 controls drawing loop performance

by Amico Amico

Hello, since I had a poor performance in drawing many buttons and text input fields at the same time into a window with wine, I applied the DIBEngine patch (http://wiki.winehq.org/DIBEngine) that is available for wine 1.1.44 (http://bugs.winehq.org/attachment.cgi?id=27879) to the 1.1.44 version of wine and started my application program that needs to draw many button and text input fields in a single window with the enviroment variable "WINEDIB=ON wine ./App.exe". Now that the DIBEngine patch is applied a little speedup in the drawing of the buttons and the text input fields is shown, but now the problem is that they are still drawn in blocks of a subset of the total number and then wine waits a little bit, then it draws another block of text input fields and buttons and then wine still waits, then it draws, and so on. The result is that my App.exe application window that is full of buttons and text input fields is drawn in subsequent times, and groups of buttons and input fields are drawn in blocks with a delay between the drawing of a group of controls and the others. The fact that not all the controls are drawn at a time but in more times is frustrating, since the CPU is a core2duo, and I think that it is powerful enough to draw all of the controls in the window at a time, specially with the DIBEngine patch applied and the DIBEngine activated. So I thought that the problem could be in the main event loop that manages the App.exe application window, and in particular the problem could be that the loop yields the drawing of the controls after a certain number of controls have been drawn in order to avoid CPU high load and then the loop starts again to draw other controls after a while and then it stops and yields and waits again, and so on. Where can I modify such a behaviour? In particular my App.exe program use many gdi32 drawing commands for drawing buttons and text input fields, so the files dlls/user32/button.c and dlls/user32/edit.c are involved. I think that the dlls/user32/winproc.c file, where the Code: LRESULT WINAPI EditWndProcA( HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam ) { return wow_handlers.edit_proc( hwnd, msg, wParam, lParam, FALSE ); } function is defined is the file where I should do some changes; this function calls Code: LRESULT EditWndProc_common( HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam, BOOL unicode ) that is implemented in the dlls/user32/edit.c file, but the fact is that in the EditWndProc_common function there are many cases like this one that manages the various edit messages and window messages sent Code: switch (msg) { case EM_GETSEL: result = EDIT_EM_GetSel(es, (PUINT)wParam, (PUINT)lParam); break; .... and I don't know how to modify the fact that the main loop of the window should handle more messages in order to draw all of the controls at a time and that it should not yield for waiting and then starting drawing again after some time. What can I do? Thanks in advance, AmoxT _________________________________________________________________ Taglia i costi. Chiama e videochiama da Messenger http://www.messenger.it/videoconversazioni.aspx

June 20, 2010

Re: [RFC] gameux.dll implementation stub [try 2]

by Henri Verbeet

2010/6/19 Vincent Povirk <madewokherd(a)gmail.com>: > I would change the second argument type of the instance creation > functions to IUnknown**. When I see an LPVOID* argument on a > COM-related function, I immediately expect to see a REFIID argument > and a QueryInterface somewhere in the function. Actually, when I see something like "LPCRAP lpSomeVar" I mostly think "*Please* don't do that." :-\

June 20, 2010

Re: new winetricks 20100618: new verbs dxsdk_nov2006, windowscodecs

by Scott Ritchie

On 06/18/2010 04:47 PM, Dan Kegel wrote: > Another month, another Winetricks. > > Online as always at > http://kegel.com/wine/winetricks > or > http://winezeug.googlecode.com > (Bug reports to the issue tracker at the above URL, please.) > Uploaded to Ubuntu Wine PPA Thanks, Scott Ritchie

June 20, 2010

Re: gnome-exe-thumbnailer -- using embedded icons for .exe and .dll files

by Scott Ritchie

On 06/18/2010 03:18 AM, Jerome Leclanche wrote: > On Fri, Jun 18, 2010 at 10:57 AM, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: >> The icons look cute and I like the version numbers, but you can't >> thumbnail all Windows files outside Wine - for example .lnk files >> internally specify a C:\path\to\file.ico style path to the icon which >> then requires Wine's drive settings to resolve (or worse, use the file >> extension's default icon from the Windows registry). > > Can't this be fixed with winepath magic? > What was the plan for .lnk files anyway? Last I heard we were discussing ways to hide them from the interface entirely, so giving them an icon wouldn't really matter. >> I am planning to add thumbnailing for .exe files to Wine's >> winemenubuilder when my .lnk thumbnailing patch gets accepted - >> probably post Wine 1.2. In addition Windows has its own thumbnailing >> mechanism that applications can register with, which Wine could >> integrate into freedesktop.org as well at some stage. >> >> Your new wineglass icon looks good. Could you please send a patch to >> replace programs/winemenubuilder/wine.xpm with your one? Also, with >> the recent patches, winemenubuilder should hardly ever generate the >> wineglass for menus any more. >> Shouldn't that icon just be the normal new straight-up wineglass icon that we use elsewhere? ie: http://www.airwebreathe.org.uk/wine-icon/oic_winlogo-48-32.png > > Icons look good indeed. Is there a switch I can flick to turn off the > version numbers though? > No, not at the moment. Even more worrisome is that there's nowhere to see the version information other than by squinting at the icon itself -- right click->properties would be a good place for that, but that's another task. Thanks, Scott Ritchie

June 20, 2010

Re: Speed/latency issues for development in a Wine environment

by Alan W. Irwin

On 2010-06-20 11:16+1000 Jeff Zaroyko wrote: > On Sun, Jun 20, 2010 at 12:50 AM, Alan W. Irwin > <irwin(a)beluga.phys.uvic.ca> wrote: >> Thanks very much Jeff, for providing some independent timing numbers for >> startup latency which are an order of magnitude (!) smaller than mine. >> So what is different about our wine platforms to cause that huge >> difference? More below. >> >> On 2010-06-19 12:55+1000 Jeff Zaroyko wrote: >> >>> >>> Windows: >>> $ time gcc --version >>> gcc.exe (GCC) 3.4.5 (mingw-vista special r3) >>> Copyright (C) 2004 Free Software Foundation, Inc. >>> This is free software; see the source for copying conditions. There is NO >>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >>> PURPOSE. >>> >>> real 0m0.020s >>> user 0m0.000s >>> sys 0m0.015s >>> >>> Wine: >>> jeffz(a)genera:~$ WINEPREFIX=/home/jeffz/wine-cpbench time >>> ~/git/wine/wine "c:\mingw\bin\gcc" "--version" >>> gcc.exe (GCC) 3.4.5 (mingw-vista special r3) >>> Copyright (C) 2004 Free Software Foundation, Inc. >>> This is free software; see the source for copying conditions. There is NO >>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >>> PURPOSE. >>> >>> 0.00user 0.01system 0:00.02elapsed 66%CPU (0avgtext+0avgdata >>> 0maxresident)k >>> 0inputs+0outputs (0major+1567minor)pagefaults 0swaps >> >> So to the level of your measurement precision you are consistently getting >> 20 ms elapsed time for both Windows and Wine for the gcc --version >> experiment on boxes very similar to mine. For the same experiment (I went >> out of my way to use the same syntax you did) I am getting ~150 ms for one X >> server and ~300 ms for the other. So that is an order of magnitude >> difference in our results. When I can reduce my wine application startup >> latency to 20 ms, I will be a happy camper, but the question is how can >> I do that? >> >> One difference between us is I am using MinGW-4.5.0-1, but it is hard to >> believe that the time taken to process the --version option for that has >> changed so drastically from your gcc-3.4.5. Also, I believe the startup >> latency on my platform is a general problem on my platform >> and nothing to do with gcc. I >> get essentially identical startup latency results with "mingw32-make >> --version" and "gcc --version". "cmake --version" tends to be about 10 per >> cent longer than the other two. Presumeably you have convenient access to >> mingw32-make. Do you also get only ~20 ms startup latency for that? > > Wine 1.2-rc3: > jeffz(a)genera:~$ WINEPREFIX=/home/jeffz/wine-cpbench time > ~/git/wine/wine "c:\mingw\bin\mingw32-make.exe" "--version" > GNU Make 3.81 > Copyright (C) 2006 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. > There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A > PARTICULAR PURPOSE. > > This program built for i386-pc-mingw32 > 0.09user 0.02system 0:00.14elapsed 81%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (0major+8432minor)pagefaults 0swaps > > Windows: > $ time mingw32-make.exe --version > GNU Make 3.81 > Copyright (C) 2006 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. > There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A > PARTICULAR PURPOSE. > > This program built for i386-pc-mingw32 > > real 0m0.030s > user 0m0.015s > sys 0m0.000s So for mingw32-make our wine startup latencies are essentially identical (near 150 ms) and substantially worse than the Windows numbers (30 ms) and much worse than the Linux numbers (~1 ms). "make" startup latency matters for builds configured by CMake because typically the top-level Makefile is configured in a way to run make many times per build. "cmake" startup latency also matters a lot because special modes for it are used during the build (typically two times per object file that is compiled by gcc) to figure out dependencies, keep track of progress, etc. If you are game for one more download (from http://cmake.org/cmake/resources/software.html) what are your cmake --version startup latency numbers? Of course, the gcc startup latency matters as well (for builds made with lots of different source files), but perhaps our numbers vary there because of our different MinGW gcc versions. If you are interested in trying the MinGW 4.5.0-1 compiler, it and its dependencies are available from http://sourceforge.net/projects/mingw/files/MinGW/BaseSystem. >> The other thing that bothers me is I get the same identical result whether >> wineserver is active or not. Can you confirm that for your wine timing >> experiment or is that an unusual result? I am still interested in that question. >> >> Other data here that may be relevant to the comparison with you: >> >> My hardware is 64-bit. >> >> Linux raven 2.6.26-2-amd64 #1 SMP Wed May 12 18:03:14 UTC 2010 x86_64 >> GNU/Linux > > Likewise, but an older kernel: > Linux genera 2.6.22-15-generic #1 SMP Fri Jul 11 18:56:36 UTC 2008 > x86_64 GNU/Linux > X.Org X Server 1.4.0.90 > 8GB of ram, 6GB of swap. 2GB ram, 6GB swap here. > >> I am running 32-bit wine (wine-1.2-rc3 compiled with the -O3 option for >> Debian Lenny) which uses the following libraries: >> >> irwin(a)raven> ldd /home/software/wine/install/bin/wine >> linux-gate.so.1 => (0xf77a2000) >> libwine.so.1 => /home/software/wine/install/bin/../lib/libwine.so.1 >> (0xf765d000) >> libpthread.so.0 => /lib32/libpthread.so.0 (0xf7625000) >> libc.so.6 => /lib32/libc.so.6 (0xf74d3000) >> libdl.so.2 => /lib32/libdl.so.2 (0xf74ce000) >> /lib/ld-linux.so.2 (0xf77a3000) > > Ubuntu 8.04 > I've compiled from git with the default -O2. > > I'm running wine from the source directory as you may have noticed. > jeffz(a)genera:~$ ldd git/wine/loader/wine > linux-gate.so.1 => (0xffffe000) > libwine.so.1 => /home/jeffz/git/wine/loader/../libs/wine/libwine.so.1 > (0xf7deb000) > libpthread.so.0 => /lib32/libpthread.so.0 (0xf7dd2000) > libc.so.6 => /lib32/libc.so.6 (0xf7c83000) > libdl.so.2 => /lib32/libdl.so.2 (0xf7c7f000) > /lib/ld-linux.so.2 (0xf7f2d000) > > >> Previously, I got ~50 per cent larger startup latency numbers with the >> Debian Lenny package for wine-1.1.42 provided by WineHQ which is why I >> switched to to building my own wine-1.2-rc3, but 150 ms with the latter just >> doesn't cut it compared to your 20 ms. > > Are you still compiling with -O3 here? Yes. I will try -O2 also just to match as closely as possible to you, but I think that is a reach. In sum, you do have one rather large startup latency for mingw32-make that agrees with mine and which confirms the problem in that case and a much shorter startup latency for an old version of MinGW compared to mine. So the results are currently ambiguous, but we will find out more if you are willing to do the appropriate downloads of CMake and modern MinGW gcc. Thanks for your continuing help in narrowing down the factor(s) that are killing performance for CMake-based builds under Wine. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net) PLplot scientific plotting software package (plplot.org) the libLASi project (unifont.org/lasi) the Loads of Linux Links project (loll.sf.net) and the Linux Brochure Project (lbproject.sf.net) __________________________ Linux-powered Science __________________________

June 20, 2010

Re: Addition of En resources to non-En resources

by Dmitry Timoshkov

James McKenzie <jjmckenzie51(a)earthlink.net> wrote: > Another good reason to drop .rc files and go with the po flow... Not really. If you'd know what stuff the .rc files contain you wouldn't do such claims. The .rc files can't go away in general. James, please learn subject before commenting. -- Dmitry.

June 20, 2010

Re: Speed/latency issues for development in a Wine environment

by Jeff Zaroyko

On Sun, Jun 20, 2010 at 12:50 AM, Alan W. Irwin <irwin(a)beluga.phys.uvic.ca> wrote: > Thanks very much Jeff, for providing some independent timing numbers for > startup latency which are an order of magnitude (!) smaller than mine. > So what is different about our wine platforms to cause that huge > difference? More below. > > On 2010-06-19 12:55+1000 Jeff Zaroyko wrote: > >> >> Windows: >> $ time gcc --version >> gcc.exe (GCC) 3.4.5 (mingw-vista special r3) >> Copyright (C) 2004 Free Software Foundation, Inc. >> This is free software; see the source for copying conditions. There is NO >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >> PURPOSE. >> >> real 0m0.020s >> user 0m0.000s >> sys 0m0.015s >> >> Wine: >> jeffz(a)genera:~$ WINEPREFIX=/home/jeffz/wine-cpbench time >> ~/git/wine/wine "c:\mingw\bin\gcc" "--version" >> gcc.exe (GCC) 3.4.5 (mingw-vista special r3) >> Copyright (C) 2004 Free Software Foundation, Inc. >> This is free software; see the source for copying conditions. There is NO >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >> PURPOSE. >> >> 0.00user 0.01system 0:00.02elapsed 66%CPU (0avgtext+0avgdata >> 0maxresident)k >> 0inputs+0outputs (0major+1567minor)pagefaults 0swaps > > So to the level of your measurement precision you are consistently getting > 20 ms elapsed time for both Windows and Wine for the gcc --version > experiment on boxes very similar to mine. For the same experiment (I went > out of my way to use the same syntax you did) I am getting ~150 ms for one X > server and ~300 ms for the other. So that is an order of magnitude > difference in our results. When I can reduce my wine application startup > latency to 20 ms, I will be a happy camper, but the question is how can > I do that? > > One difference between us is I am using MinGW-4.5.0-1, but it is hard to > believe that the time taken to process the --version option for that has > changed so drastically from your gcc-3.4.5. Also, I believe the startup > latency on my platform is a general problem on my platform > and nothing to do with gcc. I > get essentially identical startup latency results with "mingw32-make > --version" and "gcc --version". "cmake --version" tends to be about 10 per > cent longer than the other two. Presumeably you have convenient access to > mingw32-make. Do you also get only ~20 ms startup latency for that? Wine 1.2-rc3: jeffz(a)genera:~$ WINEPREFIX=/home/jeffz/wine-cpbench time ~/git/wine/wine "c:\mingw\bin\mingw32-make.exe" "--version" GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for i386-pc-mingw32 0.09user 0.02system 0:00.14elapsed 81%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+8432minor)pagefaults 0swaps Windows: $ time mingw32-make.exe --version GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for i386-pc-mingw32 real 0m0.030s user 0m0.015s sys 0m0.000s > How about file systems? My experiments were done on ext3. What filesystem > were you using on the box where you did the wine timing experiment? ext3 also > The other thing that bothers me is I get the same identical result whether > wineserver is active or not. Can you confirm that for your wine timing > experiment or is that an unusual result? > > Other data here that may be relevant to the comparison with you: > > My hardware is 64-bit. > > Linux raven 2.6.26-2-amd64 #1 SMP Wed May 12 18:03:14 UTC 2010 x86_64 > GNU/Linux Likewise, but an older kernel: Linux genera 2.6.22-15-generic #1 SMP Fri Jul 11 18:56:36 UTC 2008 x86_64 GNU/Linux X.Org X Server 1.4.0.90 8GB of ram, 6GB of swap. > I am running 32-bit wine (wine-1.2-rc3 compiled with the -O3 option for > Debian Lenny) which uses the following libraries: > > irwin(a)raven> ldd /home/software/wine/install/bin/wine > linux-gate.so.1 => (0xf77a2000) > libwine.so.1 => /home/software/wine/install/bin/../lib/libwine.so.1 > (0xf765d000) > libpthread.so.0 => /lib32/libpthread.so.0 (0xf7625000) > libc.so.6 => /lib32/libc.so.6 (0xf74d3000) > libdl.so.2 => /lib32/libdl.so.2 (0xf74ce000) > /lib/ld-linux.so.2 (0xf77a3000) Ubuntu 8.04 I've compiled from git with the default -O2. I'm running wine from the source directory as you may have noticed. jeffz(a)genera:~$ ldd git/wine/loader/wine linux-gate.so.1 => (0xffffe000) libwine.so.1 => /home/jeffz/git/wine/loader/../libs/wine/libwine.so.1 (0xf7deb000) libpthread.so.0 => /lib32/libpthread.so.0 (0xf7dd2000) libc.so.6 => /lib32/libc.so.6 (0xf7c83000) libdl.so.2 => /lib32/libdl.so.2 (0xf7c7f000) /lib/ld-linux.so.2 (0xf7f2d000) > Previously, I got ~50 per cent larger startup latency numbers with the > Debian Lenny package for wine-1.1.42 provided by WineHQ which is why I > switched to to building my own wine-1.2-rc3, but 150 ms with the latter just > doesn't cut it compared to your 20 ms. Are you still compiling with -O3 here? > Let me know if there is any additional comparison data I can provide. For > me the important question is what is fundamentally different between our two > software platforms or wine configurations that causes this order of > magnitude difference in startup latency on similar hardware? > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state implementation > for stellar interiors (freeeos.sf.net) PLplot scientific plotting software > package (plplot.org) the libLASi project (unifont.org/lasi) the Loads of > Linux Links project (loll.sf.net) and the Linux Brochure Project > (lbproject.sf.net) > __________________________ > > Linux-powered Science > __________________________ >

June 20, 2010

Re: Addition of En resources to non-En resources

by James McKenzie

Michael Stefaniuc wrote: > On 06/19/2010 04:09 PM, Frédéric Delanoy wrote: >> Sometimes, when a developer adds a string to En resource file, (s)he >> adds it as well to all other non-En resource files. >> >> Isn't that unnecessary? >> >> http://wiki.winehq.org/SublangNeutral says the search order is >> >> 1. LANG_NEUTRAL, SUBLANG_NEUTRAL >> 2. LANG_FRENCH, SUBLANG_FRENCH_BELGIAN >> 3. LANG_FRENCH, SUBLANG_NEUTRAL >> 4. LANG_ENGLISH, SUBLANG_ENGLISH_US >> >> Would a patch removing En resources in non En rc files be accepted? This >> would allow for more accurate translation stats. >> >> Or doesn't a fallback mechanism always apply? > The fallback mechanism works only at resource granularity not a string > level. A resource is is a menu, dialog, 16 STRINGTABLE strings, etc. > Thus to not break a resource one has to copy the English string over. > The move to PO files will fix this. Another good reason to drop .rc files and go with the po flow... James McKenzie

June 19, 2010

Re: [PATCH 3/3] shdocvw: Return IHTMLDocument2's IDispatch in get_Document.

by testbot＠testbot.winehq.org

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=2780 Your paranoid android. === WXPPROSP3 (32 bit htmldoc) === htmldoc.c:4524: Test failed: disp != dispex htmldoc.c:4524: Test failed: disp != dispex === W2K3R2SESP2 (32 bit htmldoc) === htmldoc.c:4524: Test failed: disp != dispex htmldoc.c:4524: Test failed: disp != dispex === WVISTAADM (32 bit htmldoc) === htmldoc.c:4524: Test failed: disp != dispex htmldoc.c:4524: Test failed: disp != dispex === W2K8SE (32 bit htmldoc) === htmldoc.c:4524: Test failed: disp != dispex htmldoc.c:4524: Test failed: disp != dispex === W7PRO (32 bit htmldoc) === htmldoc.c:4524: Test failed: disp != dispex htmldoc.c:4524: Test failed: disp != dispex === W7PROX64 (32 bit htmldoc) === htmldoc.c:4524: Test failed: disp != dispex htmldoc.c:4524: Test failed: disp != dispex === W7PROX64 (64 bit htmldoc) === htmldoc.c:4524: Test failed: disp != dispex htmldoc.c:4524: Test failed: disp != dispex

June 19, 2010

Re: [PATCH 3/3] shdocvw: Return IHTMLDocument2's IDispatch in get_Document.

by testbot＠testbot.winehq.org

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=2779 Your paranoid android. === W98SE (32 bit webbrowser) === webbrowser.c:1216: Test failed: unexpected call UpdateUI webbrowser.c:295: Test failed: unexpected nsCmdID 21 webbrowser.c:239: Test failed: unexpected call QueryStatus_STOP === WNT4WSSP6 (32 bit webbrowser) === webbrowser.c:2485: Test failed: CoCreateInterface failed: 80040154 webbrowser.c:2485: Test failed: CoCreateInterface failed: 80040154 === W2K8SE (32 bit webbrowser) === webbrowser.c:1216: Test failed: unexpected call UpdateUI webbrowser.c:295: Test failed: unexpected nsCmdID 21 webbrowser.c:239: Test failed: unexpected call QueryStatus_STOP

June 19, 2010

Re: [PATCH] [Mmsystem.drv]: always map parameters for all callback kinds

by Juan Lang

Hi Eric, minor comment on this patch: + case CALLBACK_FUNCTION: + TRACE("Function (32 bit) !\n"); + /* 16 bit func, call it */ + TRACE("Function (16 bit) %x!\n", thunk->callback); The back-to-back traces look a little strange. So does the indenting here. --Juan

June 19, 2010

Re: Addition of En resources to non-En resources

by Michael Stefaniuc

On 06/19/2010 04:09 PM, Frédéric Delanoy wrote: > Sometimes, when a developer adds a string to En resource file, (s)he > adds it as well to all other non-En resource files. > > Isn't that unnecessary? > > http://wiki.winehq.org/SublangNeutral says the search order is > > 1. LANG_NEUTRAL, SUBLANG_NEUTRAL > 2. LANG_FRENCH, SUBLANG_FRENCH_BELGIAN > 3. LANG_FRENCH, SUBLANG_NEUTRAL > 4. LANG_ENGLISH, SUBLANG_ENGLISH_US > > Would a patch removing En resources in non En rc files be accepted? This > would allow for more accurate translation stats. > > Or doesn't a fallback mechanism always apply? The fallback mechanism works only at resource granularity not a string level. A resource is is a menu, dialog, 16 STRINGTABLE strings, etc. Thus to not break a resource one has to copy the English string over. The move to PO files will fix this. bye michael

June 19, 2010

Apologies for the marketing message

by Jeremy White

It's not clear how it happened; it was not intended. These are direct emails James sends periodically to customers reaching the end of their support period. We speculate that someone signed up with the mailing list address as 'their' address. At any rate, by way of apology I'd like to remind everyone that all contributors to Wine are entitled to VIP status with CodeWeavers, which gets you free lifetime subscriptions to CrossOver. (This way, there is no chance James could ever sell you anything <grin>). Write to me if you'd like me to set you up. We are deeply grateful for everyones contributions to Wine, and very sorry for the off topic emails. Cheers, Jeremy

June 19, 2010

Re: Speed/latency issues for development in a Wine environment

by Alan W. Irwin

Thanks very much Jeff, for providing some independent timing numbers for startup latency which are an order of magnitude (!) smaller than mine. So what is different about our wine platforms to cause that huge difference? More below. On 2010-06-19 12:55+1000 Jeff Zaroyko wrote: > > Windows: > $ time gcc --version > gcc.exe (GCC) 3.4.5 (mingw-vista special r3) > Copyright (C) 2004 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > real 0m0.020s > user 0m0.000s > sys 0m0.015s > > Wine: > jeffz(a)genera:~$ WINEPREFIX=/home/jeffz/wine-cpbench time > ~/git/wine/wine "c:\mingw\bin\gcc" "--version" > gcc.exe (GCC) 3.4.5 (mingw-vista special r3) > Copyright (C) 2004 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > 0.00user 0.01system 0:00.02elapsed 66%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (0major+1567minor)pagefaults 0swaps So to the level of your measurement precision you are consistently getting 20 ms elapsed time for both Windows and Wine for the gcc --version experiment on boxes very similar to mine. For the same experiment (I went out of my way to use the same syntax you did) I am getting ~150 ms for one X server and ~300 ms for the other. So that is an order of magnitude difference in our results. When I can reduce my wine application startup latency to 20 ms, I will be a happy camper, but the question is how can I do that? One difference between us is I am using MinGW-4.5.0-1, but it is hard to believe that the time taken to process the --version option for that has changed so drastically from your gcc-3.4.5. Also, I believe the startup latency on my platform is a general problem on my platform and nothing to do with gcc. I get essentially identical startup latency results with "mingw32-make --version" and "gcc --version". "cmake --version" tends to be about 10 per cent longer than the other two. Presumeably you have convenient access to mingw32-make. Do you also get only ~20 ms startup latency for that? How about file systems? My experiments were done on ext3. What filesystem were you using on the box where you did the wine timing experiment? The other thing that bothers me is I get the same identical result whether wineserver is active or not. Can you confirm that for your wine timing experiment or is that an unusual result? Other data here that may be relevant to the comparison with you: My hardware is 64-bit. Linux raven 2.6.26-2-amd64 #1 SMP Wed May 12 18:03:14 UTC 2010 x86_64 GNU/Linux I am running 32-bit wine (wine-1.2-rc3 compiled with the -O3 option for Debian Lenny) which uses the following libraries: irwin(a)raven> ldd /home/software/wine/install/bin/wine linux-gate.so.1 => (0xf77a2000) libwine.so.1 => /home/software/wine/install/bin/../lib/libwine.so.1 (0xf765d000) libpthread.so.0 => /lib32/libpthread.so.0 (0xf7625000) libc.so.6 => /lib32/libc.so.6 (0xf74d3000) libdl.so.2 => /lib32/libdl.so.2 (0xf74ce000) /lib/ld-linux.so.2 (0xf77a3000) Previously, I got ~50 per cent larger startup latency numbers with the Debian Lenny package for wine-1.1.42 provided by WineHQ which is why I switched to to building my own wine-1.2-rc3, but 150 ms with the latter just doesn't cut it compared to your 20 ms. Let me know if there is any additional comparison data I can provide. For me the important question is what is fundamentally different between our two software platforms or wine configurations that causes this order of magnitude difference in startup latency on similar hardware? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net) PLplot scientific plotting software package (plplot.org) the libLASi project (unifont.org/lasi) the Loads of Linux Links project (loll.sf.net) and the Linux Brochure Project (lbproject.sf.net) __________________________ Linux-powered Science __________________________

June 19, 2010

Re: new winetricks 20100618: new verbs dxsdk_nov2006, windowscodecs

by Vincent Povirk

On Sat, Jun 19, 2010 at 9:31 AM, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > On 6/19/2010 18:25, Vincent Povirk wrote: >>> >>> Is it possible to add this in existing target d3dx dll that will be using >>> new decoder? >>> >> >> Yes, but they'll have to share the decoder for the DDS format somehow. >> It doesn't make much sense for d3dx9 to load d3dx11 for this. >> > > If native d3dx11 uses d3dx9 for that it's not a problem, cause this will be > still separated and both overrides will work. > If not - it's sad, additional winetricks re-registration will be needed, > etc. And if our windowscodecs is complete enough > we should probably forget about all of that and never use its override. Well, we need to register a decoder coclass to do this most cleanly, using WIC's built-in image format detection. These classes aren't present on any native dll's. Even if we didn't use a coclass, we'd need some sort of extension to a builtin dll. Most of the extra formats are only needed by d3dx9 (it seems native d3dx10 and d3dx11 use WIC, so they mostly support the WIC formats). DDS, however, can be loaded in d3dx9, d3dx10, and d3dx11. If we put a coclass for DDS in one of these dll's, the other two will have to load it when a program needs to read a DDS file.

June 19, 2010

Re: new winetricks 20100618: new verbs dxsdk_nov2006, windowscodecs

by Nikolay Sivov

On 6/19/2010 18:06, Vincent Povirk wrote: >> Isn't windowscodecs supposed to be extensible with 3rd party plugins?... >> So you could provide the additional formats D3DX would use as plugins >> instead of built-in; that should make these available with both wine's >> as well as native windowscodecs. >> > Yes, that was what I was planning, but Alexandre told me it wasn't > worth creating a new dll for this. > Is it possible to add this in existing target d3dx dll that will be using new decoder?

June 19, 2010

Addition of En resources to non-En resources

by Frédéric Delanoy

Sometimes, when a developer adds a string to En resource file, (s)he adds it as well to all other non-En resource files. Isn't that unnecessary? http://wiki.winehq.org/SublangNeutral says the search order is 1. LANG_NEUTRAL, SUBLANG_NEUTRAL 2. LANG_FRENCH, SUBLANG_FRENCH_BELGIAN 3. LANG_FRENCH, SUBLANG_NEUTRAL 4. LANG_ENGLISH, SUBLANG_ENGLISH_US Would a patch removing En resources in non En rc files be accepted? This would allow for more accurate translation stats. Or doesn't a fallback mechanism always apply? Frédéric

June 19, 2010

Re: new winetricks 20100618: new verbs dxsdk_nov2006, windowscodecs

by Vincent Povirk

> Isn't windowscodecs supposed to be extensible with 3rd party plugins?... > So you could provide the additional formats D3DX would use as plugins > instead of built-in; that should make these available with both wine's > as well as native windowscodecs. Yes, that was what I was planning, but Alexandre told me it wasn't worth creating a new dll for this.

June 19, 2010

Re: kernel32 translation question

by Frédéric Delanoy

On Fri, Jun 18, 2010 at 21:15, Luca Bennati <lucak3(a)gmail.com> wrote: > I found out why it didn't build: a numeric code in the first lines was in a > wrong format. > But now i need help to know what exactly i need to put there, because i > don't know anymore. > The lines are these (example got from french file): > > LanguageNames=(FRA=0x0c:winerr) > CodePages=(FRA=65001:0) > > The problem is only the hexadecimal code in the first line: where i find > the right value for ITA? > The one i put (incorrectly) was from ita.nls ... > The 65001 is the codepage for UTF-8. You should put there whatever codepage you used to create the file. UTF8 is preferred encoding. Frédéric

June 19, 2010

Re: hhctrl.ocx - null pointer bug

by Jaroslav Šmíd

Crash happens in 7-zip when opening context help from help menu On Sat, Jun 19, 2010 at 7:05 AM, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > Jaroslav Šmíd <jardasmid(a)gmail.com> wrote: > >> Patch http://www.winehq.org/pipermail/wine-patches/2010-June/089135.html >> sent by Dmitry Timoshkov contains bug resulting in wine crash due to >> possible null pointer dereference. Please, see bug report at >> http://bugs.winehq.org/show_bug.cgi?id=23247 for more information. > > You need to fix dlls/hhctrl.ocx/chm.c,LoadWinTypeFromCHM() to fill defaults > in all cases instead. > > Is that a real or just "possible" crash? From your description and the bug report > it sounds like a theoretical issue. > > -- > Dmitry. > -- Jaroslav Šmíd

June 19, 2010

Re: kernel32 translation question

by Michael Stefaniuc

On 06/18/2010 09:15 PM, Luca Bennati wrote: > I found out why it didn't build: a numeric code in the first lines was > in a wrong format. > But now i need help to know what exactly i need to put there, because i > don't know anymore. > The lines are these (example got from french file): > > LanguageNames=(FRA=0x0c:winerr) > CodePages=(FRA=65001:0) > > The problem is only the hexadecimal code in the first line: where i find > the right value for ITA? > The one i put (incorrectly) was from ita.nls ... Easiest from the translation statistics page ;) FRA is http://source.winehq.org/transl/lang.php?lang=00c%3A01 ITA is http://source.winehq.org/transl/lang.php?lang=010%3A01 so you need (ITA=0x10:winerr) bye michael

June 19, 2010

Re: new winetricks 20100618: new verbs dxsdk_nov2006, windowscodecs

by Frank Richter

On 19.06.2010 06:30, Vincent Povirk wrote: > I guess it's not a problem. It's just that up until now, I've been > trying to keep them interchangeable. Isn't windowscodecs supposed to be extensible with 3rd party plugins?... So you could provide the additional formats D3DX would use as plugins instead of built-in; that should make these available with both wine's as well as native windowscodecs. -f.r.

June 19, 2010

Re: gnome-exe-thumbnailer -- using embedded icons for .exe and .dll files

by Damjan Jovanovic

On Fri, Jun 18, 2010 at 12:18 PM, Jerome Leclanche <adys.wh(a)gmail.com> wrote: > On Fri, Jun 18, 2010 at 10:57 AM, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: >> The icons look cute and I like the version numbers, but you can't >> thumbnail all Windows files outside Wine - for example .lnk files >> internally specify a C:\path\to\file.ico style path to the icon which >> then requires Wine's drive settings to resolve (or worse, use the file >> extension's default icon from the Windows registry). > > Can't this be fixed with winepath magic? The .lnk file is opened and the icon path and index are extracted by an IShellLink[A/W]_Xxx() function. First that icon path is opened as an .exe or .dll and the given index in its resource table is searched for the best looking icon. Failing that, the icon path is opened as a .ico file and the best looking icon is searched there instead. Failing that, the extension of the icon path (eg. .hlp) is looked up as a subkey of HKEY_CLASSES_ROOT, and the DefaultIcon entry is used as before (first try .exe, then .ico). Failing that, the default icon for the open handler of that extension (eg. winhlp32.exe for .hlp) is extracted and used. Failing even that, the wineglass icon is used. Little of this can be done outside Wine for .lnk, which will be going on the desktop instead of .desktop files soon enough (http://bugs.winehq.org/show_bug.cgi?id=3548 comment 27 and later). Damjan Jovanovic

June 19, 2010

Re: [RFC] gameux.dll implementation stub [try 2]

by Vincent Povirk

I don't have as much to say this time. You should release the interfaces you create in your tests, so there are no memory leaks. I would change the second argument type of the instance creation functions to IUnknown**. When I see an LPVOID* argument on a COM-related function, I immediately expect to see a REFIID argument and a QueryInterface somewhere in the function. Really, all the caller expects is an IUnknown pointer (it takes care of querying the correct interface), so the signature should reflect that. The way the IGameExplorer and IGameExplorer2 interfaces are shared looks good to me. I would probably combine those patches and start with a stub IGameExplorer/IGameExplorer2 implementation. But it's easy to combine patches and not so easy to split them, so maybe you should err on the side of keeping things separate.

June 19, 2010

Re: hhctrl.ocx - null pointer bug

by Dmitry Timoshkov

Jaroslav Šmíd <jardasmid(a)gmail.com> wrote: > Patch http://www.winehq.org/pipermail/wine-patches/2010-June/089135.html > sent by Dmitry Timoshkov contains bug resulting in wine crash due to > possible null pointer dereference. Please, see bug report at > http://bugs.winehq.org/show_bug.cgi?id=23247 for more information. You need to fix dlls/hhctrl.ocx/chm.c,LoadWinTypeFromCHM() to fill defaults in all cases instead. Is that a real or just "possible" crash? From your description and the bug report it sounds like a theoretical issue. -- Dmitry.

June 19, 2010

Re: new winetricks 20100618: new verbs dxsdk_nov2006, windowscodecs

by Vincent Povirk

> I'm not quite sure what the correct way to deal with this situation > would be, if we want to address this at all. I figure that most users > of games that rely on the D3DX utility DLLs usually won't have any > reason to install the WIC redist, and most of the time, they would > have cause to install the native d3dx9_*.dll libraries to work around > unimplemented functionality, which would sidestep the issue. > > I suppose, given that winetricks does offer verbs that potentially > break builtins, the issue could simply be ignored, or a warning could > be issued regarding the potential issue, if you think that's merited. I guess it's not a problem. It's just that up until now, I've been trying to keep them interchangeable. I don't think there's a need for a warning, as long as it's easy to identify the situation from logs, starting from the default output. It should be pretty obvious: a failure to instantiate a builtin WIC clsid followed by a d3dx fixme.

June 19, 2010

Re: new winetricks 20100618: new verbs dxsdk_nov2006, windowscodecs

by Andrew Nguyen

On Fri, Jun 18, 2010 at 6:58 PM, Vincent Povirk <madewokherd(a)gmail.com> wrote: >> Andrew Nguyen >> Add windowscodecs > > Um, I'm planning to break this soon. We need additional decoders for > d3dx dlls, and I've been told not to make a new dll for them. That > means they either have to go into windowscodecs or individual d3dx > dll's, and putting them in windowscodecs seems to make more sense. > > Since native won't have these decoders, it will break builtin d3dx. > > > I'm not quite sure what the correct way to deal with this situation would be, if we want to address this at all. I figure that most users of games that rely on the D3DX utility DLLs usually won't have any reason to install the WIC redist, and most of the time, they would have cause to install the native d3dx9_*.dll libraries to work around unimplemented functionality, which would sidestep the issue. I suppose, given that winetricks does offer verbs that potentially break builtins, the issue could simply be ignored, or a warning could be issued regarding the potential issue, if you think that's merited.

June 19, 2010

Re: Speed/latency issues for development in a Wine environment

by Jeff Zaroyko

On Sat, Jun 19, 2010 at 11:00 AM, David Gerard <dgerard(a)gmail.com> wrote: > On 18 June 2010 20:12, Alan W. Irwin <irwin(a)beluga.phys.uvic.ca> wrote: > >> That would be a most interesting comparison. In computer terms 150 ms is an >> absolutely enormous time that allows something like 150 million (!) >> operations to occur on modern PC's. So I would be surprised if Microsoft >> Windows required that long to start up applications. > > > Creating processes on Windows is *expensive*. Do a > "./configure;make;make install" natively in Cygwin for any piece of > open source software and you'll be amazed how slow ./configure is to > run. This is because ./configure works by making a source code file, > compiling it in gcc and then running the resultant binary; this is > easy on a Unix, very laborious on Windows. > > So I don't know, but I would be unsurprised if it's Wine doing all the > stuff it has to do to pretend to be Windows. > > Cygwin runs under Wine. How does ./configure for a given program > running on Cygwin on Wine compare to ./configure for the same program > running on Cygwin on Windows on the same hardware? > > > - d. Since mingw isn't a cygwin application, what relevance does cygwin's sh and configure have here? It's a much more complicated beast. I think you would be right to say that creating processes in the cygwin environment is expensive, but otherwise if we should restrict the obersvation to mingw's gcc since that's what was mentioned: Windows: $ time gcc --version gcc.exe (GCC) 3.4.5 (mingw-vista special r3) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. real 0m0.020s user 0m0.000s sys 0m0.015s Wine: jeffz(a)genera:~$ WINEPREFIX=/home/jeffz/wine-cpbench time ~/git/wine/wine "c:\mingw\bin\gcc" "--version" gcc.exe (GCC) 3.4.5 (mingw-vista special r3) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. 0.00user 0.01system 0:00.02elapsed 66%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+1567minor)pagefaults 0swaps If we look at serial process creation with 1000 invocations of gcc --version #include <windows.h> #include <stdio.h> int main(void) { STARTUPINFO si; PROCESS_INFORMATION pi; char* proc = "c:\\mingw\\bin\\gcc.exe --version"; int i; ZeroMemory(&si, sizeof(si)); si.cb = sizeof(si); ZeroMemory(&pi, sizeof(pi)); for(i = 0; i < 1000;i++) { if(!CreateProcessA(NULL, proc, NULL,NULL, FALSE,0,NULL,NULL,&si,&pi)) { puts("fail\n"); } WaitForSingleObject(pi.hProcess, INFINITE); CloseHandle(pi.hProcess); CloseHandle(pi.hThread); } return 0; } This takes 3.2 seconds on Windows Vista SP2 with output directed to nul, Intel Core 2 2.6GHz. 8 seconds under Wine (with wineserver already running) 1.2-rc3 with output directed to /dev/null. Intel Core 2 2.4GHz. If we test actual compiling, so gcc does some IO. Both mingw gcc 3.4.5, 50 iterations of compiling the following: #include <windows.h> #include <stdio.h> int main(void) { STARTUPINFO si; PROCESS_INFORMATION pi; char* proc = "c:\\mingw\\bin\\gcc.exe cp2.c -o cp2.exe"; int i; ZeroMemory(&si, sizeof(si)); si.cb = sizeof(si); ZeroMemory(&pi, sizeof(pi)); for(i = 0; i < 100;i++) { if(!CreateProcessA(NULL, proc, NULL,NULL, FALSE,0,NULL,NULL,&si,&pi)) { puts("fail\n"); } WaitForSingleObject(pi.hProcess, INFINITE); CloseHandle(pi.hProcess); CloseHandle(pi.hThread); } return 0; } Windows: $ gcc cp2.c -o cp2bench.exe && time cp2bench.exe real 0m22.453s user 0m0.000s sys 0m0.000s Wine: jeffz(a)genera:~$ WINEPREFIX=/home/jeffz/wine-cpbench time ~/git/wine/wine cmd "/c cp2bench.exe" 0.10user 0.02system 0:26.53elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k I don't use cmake, so I'm not sure how that behaves, but otherwise mingw-gcc doesn't seem to have enough of a performance difference that would bother me. Jeff

June 19, 2010

Re: WineSkin v0.01

by James McKenzie

Joel Holdsworth wrote: > Hi All, > > I just wanted to highlight my new project - WineSkin > > http://www.airwebreathe.org.uk/wineskin/ > Joel: WineSkin is already taken for a method to build .app files on MacOSX. > WineSkin is an attempt to create a set of scripts that auto-generate the > necessary themes, visual styles and registry keys to visually integrate > wine with the host desktop environment. At the moment I only support > integrating 5 icons with the host, when the DE is Gnome. I'm hoping that > the project will grow and eventually I'll be able to integrate with KDE > and MacOS. For now I'm just focussing on trying to get any kind of good > integration going. > > Also, WineBottler is Mike Kronenberg's method of doing the same thing. Hmmm. I don't know of a name this could be changed to, but if you drop on the User list post a message about this and ask for an appropriate new name... James McKenzie

June 19, 2010

Re: Speed/latency issues for development in a Wine environment

by David Gerard

On 18 June 2010 20:12, Alan W. Irwin <irwin(a)beluga.phys.uvic.ca> wrote: > That would be a most interesting comparison. In computer terms 150 ms is an > absolutely enormous time that allows something like 150 million (!) > operations to occur on modern PC's. So I would be surprised if Microsoft > Windows required that long to start up applications. Creating processes on Windows is *expensive*. Do a "./configure;make;make install" natively in Cygwin for any piece of open source software and you'll be amazed how slow ./configure is to run. This is because ./configure works by making a source code file, compiling it in gcc and then running the resultant binary; this is easy on a Unix, very laborious on Windows. So I don't know, but I would be unsurprised if it's Wine doing all the stuff it has to do to pretend to be Windows. Cygwin runs under Wine. How does ./configure for a given program running on Cygwin on Wine compare to ./configure for the same program running on Cygwin on Windows on the same hardware? - d.

June 19, 2010

Re: new winetricks 20100618: new verbs dxsdk_nov2006, windowscodecs

by Vincent Povirk

> Andrew Nguyen > Add windowscodecs Um, I'm planning to break this soon. We need additional decoders for d3dx dlls, and I've been told not to make a new dll for them. That means they either have to go into windowscodecs or individual d3dx dll's, and putting them in windowscodecs seems to make more sense. Since native won't have these decoders, it will break builtin d3dx.

June 18, 2010

Re: hhctrl.ocx - null pointer bug

by Jaroslav Šmíd

Perhaps. I don't mind as long as it doesn't crash :-) -- Jaroslav Šmíd

June 18, 2010