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

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