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

I'm back
by Misha Koshelev June 22, 2010

June 22, 2010

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

2 2

Yagmark and localized Windows
by Francois Gouget June 22, 2010

June 22, 2010

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 !"

2 1

Re: [hhctrl.ocx] Null pointer fix, new patch
by Andrew Nguyen June 22, 2010

June 22, 2010

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.

3 3

Re: winex11.drv: warn and return when UploadGlyph fails in X11DRV_XRender_ExtTextOut
by Alexandre Julliard June 22, 2010

June 22, 2010

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

1 0

Re: wininet: Allow HTTPREQ_ReadFileEx read more then one data chunk
by Alexandre Julliard June 22, 2010

June 22, 2010

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

1 0

Re: [PATCH] ddraw: Grow indexbuffer as needed
by Henri Verbeet June 22, 2010

June 22, 2010

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.

1 0

damnit, X is crashing *every* time I run 3dmark2000
by Dan Kegel June 22, 2010

June 22, 2010

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.

4 4

Re: winecfg: Update Portuguese translation
by Frédéric Delanoy June 22, 2010

June 22, 2010

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

1 0

Re: Patches for Hebrew and Arabic
by Austin English June 21, 2010

June 21, 2010

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

1 0

Re: kernel32: Fix test output
by testbot＠testbot.winehq.org June 21, 2010

June 21, 2010

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.

1 0

Re: [APPDB] Updated test_appData
by Alexander Nicolaysen Sørnes June 21, 2010

June 21, 2010

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

2 2

Fwd: Italian translation of Wine at 100%
by Luca Bennati June 21, 2010

June 21, 2010

---------- 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.

1 0

Italian translation of Wine at 100%
by Paul Vriens June 21, 2010

June 21, 2010

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

1 0

Re: Richedit: Initial tests for EM_FINDWORDBREAK
by testbot＠testbot.winehq.org June 21, 2010

June 21, 2010

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

2 1

Re: [2/2] kernel32/tests: add test for CT_TYPE1 of GetStringTypeW
by James McKenzie June 21, 2010

June 21, 2010

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

2 1

Re: ntdll: fix race in NtRead/WriteFile
by Eric Pouech June 21, 2010

June 21, 2010

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

1 0

Is the appData table still holding bug links?
by Alexandru Băluț June 21, 2010

June 21, 2010

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

1 0

Speed/latency issues for development in a Wine environment
by Alan W. Irwin June 21, 2010

June 21, 2010

To introduce myself to this list, I am a complete Wine newbie with no Windows experience at all, but I do have years of experience developing software on Linux, and in the interests of testing that software on a free Windows platform, I have recently been using the combination of Windows native versions of MinGW and CMake to build and test applications and libraries under Wine. That is, I run a Windows version of cmake under wine to configure Makefiles followed by running a Windows version of MinGW make under Wine (which in turn runs MinGW gcc and other applications under Wine to build and test the software). So far this idea is going rather well, but I have run into some issues which I have been reporting on the wine-users mailing list. I find such preliminary discussion useful to help prepare a good bug report, but following a suggestion from Alexandre Julliard, I am moving the discussion of these issues here. Since at least some of you have already seen my posts on wine-users, I will only summarize the issues as I currently see them. The rest of this post concerns a slow software build issue I have discovered under Wine, and I will deal with a second issue in a later post. The issue is that Wine builds of software take roughly a factor of 5 longer than the equivalent Linux builds. This issue appears to be caused mostly by command startup latency. What I mean by that phrase is wine cmake --version (and the "--version" option for many commands you can run under wine) take roughly 150 ms (with wine-1.2-rc3 built with the -O3 option and running that wine version with WINEDEBUG='-all' and wineserver -p) to complete while Linux versions of the same commands require 1 ms to complete. It is a startup latency in the commands run under wine rather than a startup latency issue with the wine command itself because that command returns much faster than 150 ms if you give it an unknown command. Because many thousands of commands (e.g., "gcc"; several "cmake -E" variants per gcc command to help report progress; figure out dependencies, etc.; and various further make commands generated by the initial make command) are used to complete a typical build (say of cmake itself or PLplot), the startup latency for each of those commands accumulates and is a major factor which slows down the build (by roughly a factor of 5) compared to the equivalent Linux build. So a reduction of the command startup latency under Wine by an order of magnitude should largely solve the problem. I find the command startup latency depends very much on what X server I am using. Of course, the actual commands I am using (cmake, MinGW make, MinGW gcc, etc.) to build software under wine have nothing to do with X. So I am hoping if I build a stripped down version of wine configured to ignore X and all other systems (sound, etc.) that are not required for builds, then I might achieve the reduced command startup latency that I need. Before I try that, however, is there some less brute-force way to reduce command startup latency? 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 __________________________ ---------- Forwarded message ---------- Date: Sat, 12 Jun 2010 14:10:31 -0700 (PDT) From: Alan W. Irwin <irwin(a)beluga.phys.uvic.ca> To: wine-users(a)winehq.org Subject: Re: [Wine] Speed/latency issues for development in a Wine environment On 2010-06-11 18:09-0700 Alan W. Irwin wrote: The previous timing numbers were done with wine-1.1.42. Following a suggestion made off-list to me, I have built wine-1.2-rc3 today (with CFLAG=-O3) and immediately noticed the start-up latency for simple commands (e.g., cmake --version) was reduced from about 0.25 s to about 0.15 s. I don't know how the previous Debian wine-1.1.42 packages were optimized so that difference may just be due to an optimization difference or an actual improvement in the Wine code from 1.1.42 to 1.2-rc3. However, to see how -O3 optimized wine-1.2-rc3 does with the full tests, I have redone my timing tests for I. (cmake), II (make install), and III (make install latency) and the following reductions have been observed. > Wine I. > wine(a)raven> time wine cmake -G "MinGW Makefiles" \ > "-DCMAKE_INSTALL_PREFIX=z:/home/wine/cmake/install1" \ > z:/home/software/cmake/cmake-2.8.1_patched/ >& cmake.out > > real 14m17.124s ==> real 8m18.041s > Wine II. > > wine(a)raven> time wine mingw32-make install >& make_install.out > > real 20m13.421s ==> real 12m4.198s > Wine III. > wine(a)raven> time wine mingw32-make install >& make_install.out1 > > real 1m39.018s ==> real 0m51.045s For reference here are the corresponding Linux numbers which are still much better than the corresponding Wine-1.2-rc3 results. > Linux I. > > wine(a)raven> time cmake -G "Unix Makefiles" \ > "-DCMAKE_INSTALL_PREFIX=/home/wine/cmake/install_linux" \ > /home/software/cmake/cmake-2.8.1_patched/ >& cmake.out > > real 0m34.015s > Linux II. > > wine(a)raven> time make install >& make_install.out > > real 2m12.805s > Linux III. > > wine(a)raven> time make install >& make_install.out1 > > real 0m0.869s To summarize these findings, it appears that changes in startup latency for simple commands strongly correlates with timing results for build steps I, II, and III on Wine. This makes sense since we know that several thousand commands are run for, e.g., build step II so startup latency of hundreds of milliseconds per command must be a real build performance killer. So what can be done to reduce the simple startup latency from the current ~150 ms on Wine down much closer to the Linux startup latency for the same commands which is typically 1 ms? Simple commands requiring 150 ms to start must have an awful lot of extra start baggage. Is all that baggage really needed for command-line commands such as cmake, mingw32-make, gcc, etc.? 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 __________________________

5 10

RFC: Patch to add EM_FINDWORDBREAK tests
by James McKenzie June 21, 2010

June 21, 2010

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

1 0

*_queue.php files in AppDB
by Alexandru Băluț June 20, 2010

June 20, 2010

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

2 1

Re: richedit: Add WB_ISDELIMITER value to richedit.h
by Dylan Smith June 20, 2010

June 20, 2010

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.

2 1

Help wanted for bug#3023
by Eliot Blennerhassett June 20, 2010

June 20, 2010

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...

1 0

Help wanted re Bugzilla#3023 (one line fix for Orcad add new elements)
by Eliot Blennerhassett June 20, 2010

June 20, 2010

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

1 0

WineSkin v0.01
by Joel Holdsworth June 20, 2010

June 20, 2010

Hi All, I just wanted to highlight my new project - WineSkin http://www.airwebreathe.org.uk/wineskin/ 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. If anyone has any thoughts or comments, let me know; I'd love to hear them. All the best Joel

4 3

New flags in LoadLibraryEx
by Mariusz Pluciński June 20, 2010

June 20, 2010

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?

2 1