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

Re: hhctrl.ocx - null pointer bug

by Juan Lang

Hi Jaroslav, - if (!*caption) caption = info->pCHMInfo->defTitle; + if (!caption) caption = info->pCHMInfo->defTitle; I suspect a better fix would be: + if (!caption || !*caption) caption = info->pCHMInfo->defTitle; That is, either a NULL caption or an empty one results in info->pCHMInfo->defTitle getting used. --Juan

June 18, 2010

new winetricks 20100618: new verbs dxsdk_nov2006, windowscodecs

by Dan Kegel

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.) Changes: Dan Kegel Add dxsdk_nov2006, document how to use it etc. at http://kegel.com/wine/cl-howto-win7sdk.html directx9: override dxdiag.exe, too Update divx sha1sum Andrew Nguyen Add windowscodecs Jeff Zaroyko Fix vjrun20 path in non-quiet mode Austin English Update OpenWatcom to version 1.9

June 18, 2010

New wisotool 20100618: 19 new verbs (blur, spore, photoshop cs5, ...), and 75 old ones

by Dan Kegel

wisotool is a handy winetricks-like script for automatically installing games from .iso or .mds files copied from your own dvds (or, if the game is freely downloadable, it will download it). Just like winetricks, it is intended to make testing Wine easier, but might be useful for people who simply want to install games. Unlike winetricks, wisotool is quiet by default; it doesn't ask any questions (except, for now, it prompts for your password so it can mount the .iso file). Wisotool currently supports about 95 games and/or benchmarks (see below). Please consider contributing support for your favorite game, it's not (too) hard. I'm especially interested in recent or beta games; ideally wisotool would support good games or betas on or near their day of release. Wisotool is available at http://kegel.com/wine/wisotool You can read more about it at http://wiki.winehq.org/wisotool Please report bugs via http://code.google.com/p/winezeug/issues/ Changes since version 20100530: Austin English: New verbs proevolution2010_demo pscs5 pscs5_pickle pscs5_unpickle Dan Kegel: New verbs bioshock_demo blur rom Various bugfixes Eleazar Galano: New verbs avatar_demo braid braid_demo darknesswithin2_demo hegemonypom_demo hphbp_demo nfsps_demo popsot spore Travis Athougies: New verbs 7million msaoe_demo Vincent Pelletier: New verb beneath_a_steel_sky_gog Here's the current help message: Script to install games automatically. Usage: wisotool [options] package [package] ... Options: -q quieter -v verbose -V display Version Packages: 3dmark03 3D Mark 03 (Futuremark, 2003) [download] 3dmark05 3D Mark 05 (Futuremark, 2005) [download] 3dmark06 3D Mark 06 (Futuremark, 2006) [download] 3dmark2000 3DMark2000 (MadOnion.com, 2000) [download] 3dmark2001 3DMark2001 (MadOnion.com, 2001) [download] 7million 7Million (Deep Silver, 2009) [download] [broken on wine] abes_exoddus_gog Abes Exoddus (GOG.com) abes_oddysee_gog Abes Oddysee (GOG.com) assassinscreed Assassins Creed (Ubisoft, 2008) avatar_demo James Camerons Avatar The Game Demo (Ubisoft, 2009) [download] baldursgate2 Baldurs Gate 2 - Shadows of Amn (Bioware, 2000) battle_chess_gog Battle Chess (GOG.com) beneath_a_steel_sky_gog Beneath a Steel Sky (GOG.com, free) beyond_good_and_evil_gog Beyond Good and Evil (GOG.com) bfbc2 Battlefield Bad Company 2 (EA, 2010) bioshock Bioshock (2K Games, 2007) bioshock_demo Bioshock Demo (2K Games, 2007) blur Blur (Activision, 2010) braid Braid (Number None, 2009) [download] braid_demo Braid Demo (Number None, 2009) [download] codmw2 Call of Duty Modern Warfare 2 (Activision, 2009) [broken] darknesswithin2_demo Darkness Within 2 Demo (Zoetrope Interactive, 2010) [download] descent_1_2_gog Descent and Descent 2 (GOG.com) descent_3_gog Descent 3 (GOG.com) diablo2 Diablo II (Blizzard, 2000) dragonage Dragon Age: Origins (Bioware, 2009) dukenukem3d_gog Duke Nukem 3D (GOG.com) dukenukemmp_gog Duke Nukem Manhattan Project (GOG.com) earth_2150_trilogy_gog Earth 2150 trilogy (GOG.com) earth_2160_gog Earth 2160 (GOG.com) earthworm_jim_1_2_gog Earthworm Jim 1 & 2 (GOG.com) earthworm_jim_3d_gog Earthworm Jim 3D (GOG.com) empire_earth_gold_gog Empire Earth Gold (GOG.com) evil_genius_gog Evil Genius (GOG.com) fallout_2_gog Fallout 2 (GOG.com) fallout_gog Fallout (GOG.com) fallout_tactics_gog Fallout Tactics (GOG.com) far_cry_gog Far Cry (GOG.com) flatout_gog FlatOut (GOG.com) freespace_2_gog Freespace 2 (GOG.com) freespace_gog Freespace (GOG.com) ghost_master_gog Ghost Master (GOG.com) ground_control_2_gog Ground Control 2 (GOG.com) gta_vc Grand Theft Auto: Vice City (Rockstar, 2003) half_life_goty Half Life: Game of the Year Edition (Sierra, 2000) hegemonypom_demo Hegemony: Philip of Macedon Demo (Longbow Games, 2010) [download] help How to use this tool hon Heroes of Newerth (S2 Games, 2010) [download] hphbp_demo Harry Potter & The Half Blood Prince Demo (EA, 2009) [download] lswcs Lego Star Wars Complete Saga (Lucasarts, 2009) manhole The Manhole Masterpiece Edition (Cyan, 1994) masseffect2 Mass Effect 2 (BioWare, 2010) mdk2_gog MDK 2 (GOG.com) mdk_gog MDK (GOG.com) mnbw_demo Mount & Blade Warband Demo (Taleworlds, 2010) [download] morrowind The Elder Scrolls III: Morrowind (Bethesda, 2002) msaoe_demo Age of Empires Demo (Microsoft, 1997) [download] neighbours_from_hell_compilation_gog Neighbours From Hell 1 & 2 (GOG.com) nfsps_demo Need For Speed: Pro Street Demo (EA, 2007) operation_flashpoint_goty_gog Operation Flashpoint GOTY (GOG.com) orangebox Orange Box (Valve, 2007) painkiller_black_gog Painkiller Black (GOG.com) pcmark04 PC Mark 04 (Futuremark, 2004) [download] pcmark05 PC Mark 05 (Futuremark, 2005) [download] perimeter_gog Perimeter (GOG.com) plantsvszombies Plants vs. Zombies (PopCap Games, 2009) [download] popsot Prince of Persia Sands of Time (Ubisoft, 2003) popsot_demo Prince of Persia Sands of Time Demo (Ubisoft, 2003) praetorians_gog Praetorians (GOG.com) procycling08_demo Pro Cycling Manager 2008 Demo (Cyanide, 2008) [download, broken in wine] procycling09_nda Pro Cycling Manager 2009 (Cyanide, 2009) proevolution2010_demo Pro Evolution Soccer 2010 Demo (Konami, 2009) [download] pscs5 Photoshop CS5 Demo (Adobe, 2010) pscs5_pickle save Photoshop CS5 Demo to tarball pscs5_unpickle restore Photoshop CS5 Demo from tarball psychonauts_gog Psychonauts (GOG.com) quake3 Quake 3 (ID Software, 1999) re5bench Resident Evil 5 Benchmark (Capcom, 2009) [download] redneck_rampage_gog Redneck Rampage (GOG.com) robinson_requiem_collection_gog Robinson Requiem & Deus (GOG.com) rom Runes of Magic (Frogster Interactive, 2009) [download] settlers_2_gold_gog The Settlers 2 Gold (GOG.com) shogo_gog Shogo Mobile Armor Division (GOG.com) sims3 The Sims 3 (EA, 2009) splitsecond Split Second (Black Rock Studios, 2010) [wine bug 22865] splitsecond_demo Split Second Demo (Black Rock Studios, 2010) [wine bug 22865] spore Spore (EA, 2008) starcraft Starcraft Battle Chest (Blizzard, 1998) starcraft2 Starcraft II beta (Blizzard, 2010) stfu Starwars: The Force Unleashed (Aspyr, 2009) sto Star Trek Online (Cryptic, 2010) tex_murphy_1_and_2_gog Tex Murphy 1 & 2 (GOG.com) unigine_heaven Unigen Heaven 2 Benchmark (Unigen, 2010) [download] unreal_2_se_gog Unreal 2: The awakening Special Edition (GOG.com) unreal_gold_gog Unreal Gold Edition (GOG.com) ut2004_gog Unreal Tournament 2004 (GOG.com) ut_goty_gog Unreal Tournament GOTY (GOG.com) wog World of Goo demo (2D Boy, 2008) [download] wowbc World of Warcraft: Battle Chest (Blizzard, 2008) Pseudopackages: load Load a disc into the iso cache load=KEY Load a disc with given key; only works from commandline at moment ------------------------------------------------------ If the game is not marked with {download} or {loaded} in the menu, you have to insert its disc and give the 'load' command before you can choose that game in the menu. If the game has multiple discs, you have to do this for each disc. ------------------------------------------------------ ------------------------------------------------------ If the game has an install key, you have to enter that when loading the first disc. (You have to do that from the commandline, e.g. sh wisotool load=XXXX-YYYY-ZZZZ.) ------------------------------------------------------

June 18, 2010

Happy Father's Day From CodeWeavers: Get CrossOver Mac for 60% Off (This Weekend Only)

by James Ramey

Thank you for your past patronage of CrossOver Mac. We appreciate your business, and I was hoping to tempt you with an enticing offer to continue supporting our software. For this weekend only, you can purchase CrossOver (any version) for 60% off the list price. All you need to do is enter SPECIAL DEAL CODE: FATHERSDAY in the Special Deal Box in the cart screen (has to be the cart screen) of the order process. You'll see the discount applied before you complete your transaction. It's a quick and easy way to save money on your purchase of CrossOver. · A couple of factoids you might want to consider in making this purchase: · CrossOver 9.1 is due out within the next 45 days. CrossOver 9.1 should be an especially good release of CrossOver, and the upgrade to this version is included in your purchase. · CrossOver Mac Professional includes a license for CrossOver Mac Games. CrossOver Mac Games is now playing many new titles including Star Trek On-line. If you have an interest in playing games, you may want to consider purchasing CrossOver Mac Professional using the SPECIAL DEAL CODE. · All volume and educational discounts are still valid with this promotion. If you have an educational entitlement, you'll get your educational discount in addition to the SPECIAL DEAL CODE. Likewise if you purchase more than one license, you'll also get volume discounts. Again, this SPECIAL DEAL CODE is easy to use and will save you money!! · The SPECIAL DEAL CODE expires on Monday, June 21. Don't wait to buy. If you're interested, make your purchase now as this special deal is limited to only past customers and only to this weekend. · If this SPECIAL DEAL CODE isn't your cup of tea, I understand. This is the only e-mail that you will receive from me about renewing your support. You'll receive a nag e-mail or two from our system reminding you to renew your maintenance. Once those have past, we will not contact you again (ever) unless you have signed up for one of our many mailing lists. Finally, everyone at CodeWeavers appreciates your business. We appreciate your patience as we work to make our software ever better. We understand that it's not always easy to use our software and that our software doesn't always provide the support you want or need. We want you to know this and that we are making efforts to make the software better. Again, thank you. We sincerely appreciate your support of our software and our efforts to make our software better. With my best regards, James B. Ramey Vice President, Sales CodeWeavers, Inc. jramey(a)codeweavers.com

June 18, 2010

Re: The __WINE__ macro does not identify the Wine platform

by Alan W. Irwin

On 2010-06-18 19:26+0200 Roderick Colenbrander wrote: > On Fri, Jun 18, 2010 at 6:43 PM, Austin English <austinenglish(a)gmail.com> wrote: >> On Fri, Jun 18, 2010 at 11:37 AM, Alan W. Irwin >>> Which leads to a Wine newbie question. What is the best way to detect the >>> Wine >>> platform at run time? >> >> Doing so is discouraged. As you pointed out earlier, if you workaround >> a wine bug in your application on wine, it may break on windows. >> Similarly, if/when the wine bug is fixed, your application may break >> similarly. If you do use such workarounds, be sure to give the user a >> way to workaround it (see, for example, utorrent, which allows >> enabling/disabling the hacks in its preferences). >> >> To answer your question, though, you could check for wine specific >> exports in ntdll, e.g., NTDLL_wine_get_version. Keep in mind that >> doing so is unsupported, may break in the future, etc. >> >> -- >> -Austin > > The best thing you can do is when you discover differences in behavior > is to submit a bug report to bugzilla. Just to give some background here see http://bugs.winehq.org/show_bug.cgi?id=22286. There cmake got badly burnt on Wine by using a GetShortPathName -> GetLongPathName kludge to get the actual case for a filename. That use of GetShortPathName lead to a hash collision under Wine between two completely different file names used for language support under CMake. The wine developer response was won't fix since "If you need reliable short names you have to use a vfat filesystem." which seems a reasonable response to me although I don't have enough vfat knowledge to follow the logic completely. <aside> The assumption here is CMake's choice of language support file name was just unlucky, but an alternative interpretation is that hashing function is poorly implemented on Wine so the probability of hash collisions is substantially higher than it needs to be. Anyhow, I hope the wine developers do follow up by looking carefully at their hash code for this case to make sure it minimizes hash collisions. Of course, making collisions less probable would be great, but even if that is possible and implemented, it appears the statement is still correct that GetShortPathName is always going to be unreliable to a certain (hopefully low) degree under the combination of Wine and Linux filesystems. </aside> The CMake developers have responded now (CMake-2.8.2 release candidate) to this issue by replacing that kludge for getting the correct case of filenames with something completely reliable that does not use GetShortPathName. However, there are other instances of GetShortPathName in the CMake source code that are used for the #if defined(WIN32) && !defined(__CYGWIN__) case. I am not a CMake developer and don't understand all the issues, but I have been told GetShortPathName is used for these other cases because there are certain build tools under Windows that still do not handles spaces in file names correctly. GetShortPathName apparently works perfectly to get around such issues for the Microsoft Windows platform, but because of the above issue it _might_ be subject to hash collions under Wine (especially if the probability of those is much higher than it should be, see <aside> above). The Wine documentation actively discourages spaces in filenames (probably because of issues with Windows applications similar to those found by the CMake developers for certaint Windows build tools). Thus, it appeared to the CMake developers that the above could be changed to #if defined(WIN32) && !defined(__CYGWIN__) && !defined(__WINE__) However, because of the good reason discussed by Alexandre earlier in this thread I am now looking for an equivalent run-time test to recommend to the CMake developers so that GetShortPathName won't be used at all (instead the full pathname will be used just as in all cases other than WIN32 above) when Windows cmake happens to be run on Wine. Developer life sure is messy and full of compromises, ain't it? 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 18, 2010

Re: WineSkin v0.01

by ryan woodsmall

> 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

June 18, 2010

WineSkin v0.01

by Joel Holdsworth

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

June 18, 2010

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

by Mariusz Pluciński

Hi I fixed noted problems with my initial implementation of gameux.dll. The code freeze is still the fact, but I hope for some feedback. Thanks

June 18, 2010

kernel32 translation question

by Luca Bennati

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

June 18, 2010

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

by Alan W. Irwin

Hi Paul: Thanks for your ideas on reducing the command startup latency. On 2010-06-18 10:48+0300 Paul Chitescu wrote: > Alan, > > Try to keep the wineserver initialized and running - for example keep a > cmd.exe or notepad or something idle (in the same WINEPREFIX). I tried that by running wine cmd in another xterm (but the same WINEPREFIX) and left it idle at the command prompt rather than exiting. That made no significant difference to the startup latency timing results. I then tried the experiment of turning the wineserver off (wineserver -k). I double-checked that nothing was running wineserver by using "ps auxww". I also made sure there were no other idle wine commands running. For that experiment, the startup latencies still remained the same! So either I am not running wineserver properly (I use wineserver -p) or it makes absolutely no difference to simple commands that essentially do very little such as the three "--version" ones I am using to test startup latency. > To get more accurate timings run the test twice so the 2nd time the files > should be cached in memory. Always. > > If you are _sure_ you don't need a GUI you can unset DISPLAY (or run in a pure > text console) so wine won't be able to create any windows. But the fact the X > server matters suggests that some GUI components are used after all. The cmake and MinGW gcc and make commands are all pure command line. So I tried setting DISPLAY= and that actually made a small but significant reduction (a drop from near ~150 ms to ~125 ms on average for the --version option for those three commands) in the startup latency. Therefore, I think the conclusion must be that command startup under wine initializes GUI components even when they are not needed. I will test this hypothesis further by disabling X altogether by configuring a stripped-down build of wine and doing further command startup latency tests with that stripped-down version of wine. > > Also please verify how fast gcc is to start on Windows, it may not be a wine > problem. On Windows it is typically more expensive to start processes so > Windows programs are usually more complex, do more tasks (eventually > multithreaded) and live longer than the average UNIX program. 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. However, I would need help from others here to report command startup times under Microsoft Windows since I don't have access to that platform. The average of the times to run the commands "gcc --version", "cmake --version", and "mingw32-make --version" should be a pretty good measure of command startup time. Ideally, of course, these Wine versus Microsoft Windows startup time comparisons should be made on the same box, but we are looking for orders of magnitude here (The Linux startup times are two orders of magnitude lower) so I don't think this strict "same box" requirement is necessary so long as the boxes are roughly the same (mine is a garden-variety dual-core Intel 2.4 GHz). 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 18, 2010

Re: Please resend the fixed gcov patch by tomorrow so I can test building with it :)

by Peter Davies

On 18 June 2010 01:50, Scott Ritchie <scott(a)open-vote.org> wrote: > Hey Peter, > > Was just hoping you'd make the (I believe trivial) change to your gcov > patch that Alexandre wanted and submit it by tomorrow so it creeps into > the next RC. I want to start messing around with profiled package > builds this weekend :) > > Anyway, keep up the good work! > > Thanks, > Scott Ritchie > I didn't send it because the change was so trivial (I have now). Note you will need to build wine-preloader without PGO (and with a libport.a without PGO) or you will get libc linking errors. Peter

June 18, 2010

Re: The __WINE__ macro does not identify the Wine platform

by Roderick Colenbrander

On Fri, Jun 18, 2010 at 6:43 PM, Austin English <austinenglish(a)gmail.com> wrote: > On Fri, Jun 18, 2010 at 11:37 AM, Alan W. Irwin > <irwin(a)beluga.phys.uvic.ca> wrote: >>> If what you want is to add workarounds for Wine in your code, then >>> neither __WINE__ nor the build platform matter. What matters is the >>> platform your code is currently running on, which should be detected at >>> run-time. >> >> Excellent point. After my previous post, I thought some more about this >> whole issue, and if you detected Wine at compile time and built in different >> behaviour for that platform (say to work around a Wine issue), then that >> application could be potentially crippled on Microsoft Windows if you ran it >> there. I am pretty sure I would have gone on to the idea of run-time >> detection, but I hadn't done so yet so thanks for that! >> >> Which leads to a Wine newbie question. What is the best way to detect the >> Wine >> platform at run time? > > Doing so is discouraged. As you pointed out earlier, if you workaround > a wine bug in your application on wine, it may break on windows. > Similarly, if/when the wine bug is fixed, your application may break > similarly. If you do use such workarounds, be sure to give the user a > way to workaround it (see, for example, utorrent, which allows > enabling/disabling the hacks in its preferences). > > To answer your question, though, you could check for wine specific > exports in ntdll, e.g., NTDLL_wine_get_version. Keep in mind that > doing so is unsupported, may break in the future, etc. > > -- > -Austin The best thing you can do is when you discover differences in behavior is to submit a bug report to bugzilla. Even better would be to write a small test case showing the difference that way it might get fixed quickly (even better would be to fix the bug in Wine yourself if it is an easy one). If you want to detect Wine. An easy way is to check for Wine specific registry keys (not the most reliable one though since someone could have the same keys on Windows though unlikely). Another way is to check for wine specific functions like 'wine_get_unix_file_name' in kernel32. Roderick

June 18, 2010

Re: user32: Lock user32 in alloc_user_handle to fix races with get_user_handle_ptr

by Dan Kegel

On Fri, Jun 18, 2010 at 9:18 AM, Paul Chitescu <paulc(a)voip.null.ro> wrote: > On Friday 18 June 2010 07:04:14 pm Dan Kegel wrote: >> Say, that sounds like a kind of test we should have in our test suite. >> >> What apps does this fix? > > Sysinternal's autoruns.exe which populates a number of list/tree views with a > large number of icons extracted them the exes. It seems to do so from > different threads and it doesn't stop if one thread crashes (I wonder - > intentionally?) > > Unfortunately it's a race condition that doesn't always happen. Adding just a > TRACE suppressed the error. Adding if (...) ERR(...) showed that only 1-2 out > of about 150 icon creations would crash. Thanks for the info.

June 18, 2010

Re: The __WINE__ macro does not identify the Wine platform

by Austin English

On Fri, Jun 18, 2010 at 11:37 AM, Alan W. Irwin <irwin(a)beluga.phys.uvic.ca> wrote: >> If what you want is to add workarounds for Wine in your code, then >> neither __WINE__ nor the build platform matter. What matters is the >> platform your code is currently running on, which should be detected at >> run-time. > > Excellent point. After my previous post, I thought some more about this > whole issue, and if you detected Wine at compile time and built in different > behaviour for that platform (say to work around a Wine issue), then that > application could be potentially crippled on Microsoft Windows if you ran it > there. I am pretty sure I would have gone on to the idea of run-time > detection, but I hadn't done so yet so thanks for that! > > Which leads to a Wine newbie question. What is the best way to detect the > Wine > platform at run time? Doing so is discouraged. As you pointed out earlier, if you workaround a wine bug in your application on wine, it may break on windows. Similarly, if/when the wine bug is fixed, your application may break similarly. If you do use such workarounds, be sure to give the user a way to workaround it (see, for example, utorrent, which allows enabling/disabling the hacks in its preferences). To answer your question, though, you could check for wine specific exports in ntdll, e.g., NTDLL_wine_get_version. Keep in mind that doing so is unsupported, may break in the future, etc. -- -Austin

June 18, 2010

Re: The __WINE__ macro does not identify the Wine platform

by Alan W. Irwin

On 2010-06-18 11:44+0200 Alexandre Julliard wrote: > "Alan W. Irwin" <irwin(a)beluga.phys.uvic.ca> writes: > >> Note also, my whole argument is based on the assumption that some standard >> means already exists for telling compilers running on Wine to #define >> __WINE__ at run time. However, if such standard means do not already exist >> there is no way I would want to ask for changes in any compilers (as you >> incorrectly imply later in your post), and again I would just live with >> it. > > It sounds like you are confusing compile time and run time. The __WINE__ > define can be used at compile time to detect the Wine build > environment. If you are using a Windows compiler you have a Windows > build environment, not a Wine one, so __WINE__ is not defined. That the > Windows compiler is currently running under Wine is completely > irrelevant. > > If what you want is to add workarounds for Wine in your code, then > neither __WINE__ nor the build platform matter. What matters is the > platform your code is currently running on, which should be detected at > run-time. Excellent point. After my previous post, I thought some more about this whole issue, and if you detected Wine at compile time and built in different behaviour for that platform (say to work around a Wine issue), then that application could be potentially crippled on Microsoft Windows if you ran it there. I am pretty sure I would have gone on to the idea of run-time detection, but I hadn't done so yet so thanks for that! Which leads to a Wine newbie question. What is the best way to detect the Wine platform at run time? Finally, someone else in this thread mentioned this question has come up again and again to educate those like me who were making some incorrect assumptions about Wine platform identification. So perhaps a FAQ item on this subject would be appropriate? 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 18, 2010

Re: advapi32/tests: Fixed -Wsign-compare warnings in security tests (try 2)

by Alexandre Julliard

Marko Nikolic <grkoma(a)gmail.com> writes: > Fixed test failures in 64-bit build. It would be better to choose a more appropriate invalid value for a BOOL variable. -- Alexandre Julliard julliard(a)winehq.org

June 18, 2010

Re: user32: Force a minimum character size of 1x1 to prevent divisions by zero if setting the font failed

by Alexandre Julliard

Paul Chitescu <paulc(a)voip.null.ro> writes: > Changelog: > user32: Force a minimum character size of 1x1 to prevent divisions by zero if > setting the font failed > > Failing to set any font is unusual but can happen - for example: > DISPLAY= wine notepad It sounds like a gdi bug. It should be able to provide metrics even without a display. -- Alexandre Julliard julliard(a)winehq.org

June 18, 2010

Re: comctl32: restore focus if it was lost during the processing of PROPSHEET_SetWizButtons

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > This is triggering a bug on the mac that causes the window manager to > loose track of where to send messages causing the resulting dialog to > be unable to get mouse events. I find that surprising, the button focus should not be visible to the window manager. -- Alexandre Julliard julliard(a)winehq.org

June 18, 2010

Re: comctl32: restore focus if it was lost during the processing of PROPSHEET_SetWizButtons

by James Mckenzie

Aric Stewart <aric(a)codeweavers.com> wrote: > >Alexandre Julliard wrote: >> Aric Stewart <aric(a)codeweavers.com> writes: >> >>> commit 87f9053ec43e0272e27280e1e7ab9674fc79b109 >>> Author: Aric Stewart <aric(a)codeweavers.com> >>> Date: Fri Jun 18 13:21:56 2010 +0900 >>> >>> comctl32: restore focus if it was lost during the processing of PROPSHEET_SetWizButtons >> >> It would probably be better to not disable buttons that don't need >> it. What is this fixing? >> > >I can modify the patch to do that. > >This is triggering a bug on the mac that causes the window manager to >loose track of where to send messages causing the resulting dialog to be >unable to get mouse events. > Thank you for taking time to fix this. What is the bug report number so that I can go out and vote for it. I've experienced this lately while running some regression tests and I thought that it was just my system messing up (I've had to reboot it several times in the last week or so.) BTW, 10.6.4 has been released, 700MB download :( James McKenzie

June 18, 2010

Re: ddraw: Better validation of IDirectDrawSurface::BltFast parameters.

by Henri Verbeet

On 18 June 2010 15:52, Iain Arnell <iarnell(a)gmail.com> wrote: > - dsty + rsrc->bottom - rsrc->top > This->surface_desc.dwHeight) > + dsty + rsrc->bottom - rsrc->top > This->surface_desc.dwHeight || > + (dstx | dsty) & (1<<(sizeof(DWORD)*8-1)) /* dstx or dsty negative */ ) That's not very pretty. This looks like it's just an integer overflow, so that's probably also how you should handle it.

June 18, 2010

Re: Michael Stefaniuc : notepad: Fix an error in the Bulgarian translation.

by Eric Ahn

unsubscribe

June 18, 2010

Re: comctl32: restore focus if it was lost during the processing of PROPSHEET_SetWizButtons

by Aric Stewart

Alexandre Julliard wrote: > Aric Stewart <aric(a)codeweavers.com> writes: > >> commit 87f9053ec43e0272e27280e1e7ab9674fc79b109 >> Author: Aric Stewart <aric(a)codeweavers.com> >> Date: Fri Jun 18 13:21:56 2010 +0900 >> >> comctl32: restore focus if it was lost during the processing of PROPSHEET_SetWizButtons > > It would probably be better to not disable buttons that don't need > it. What is this fixing? > I can modify the patch to do that. This is triggering a bug on the mac that causes the window manager to loose track of where to send messages causing the resulting dialog to be unable to get mouse events. -aric

June 18, 2010

Re: notepad: substitute the page number in the footer

by Alexandre Julliard

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > Changelog: > * notepad: substitute the page number in the footer This needs to be more generic, there are other possible substitutions. At the very least it should handle escaped ampersands. -- Alexandre Julliard julliard(a)winehq.org

June 18, 2010

Re: jscript: Add the Romanian translation. (2nd try)

by Michael Stefaniuc

Michael Stefaniuc wrote: > Hello Octavian! > > Octavian Voicu wrote: >> On Fri, Jun 18, 2010 at 12:14 PM, Michael Stefaniuc <mstefani(a)redhat.de> wrote: >>> + IDS_INVALID_CALL_ARG "Apel de procedură sau argument nevalid" >>> + IDS_SEMICOLON "„;” presupus" >>> + IDS_LBRACKET "„(” presupus" >>> + IDS_RBRACKET "„)” presupus" >>> + IDS_UNTERMINATED_STR "Constantă de șir nedeterminată" >>> + IDS_NOT_FUNC "Funcție presupusă" >>> + IDS_NOT_NUM "Număr presupus" >>> + IDS_OBJECT_EXPECTED "Obiect presupus" >>> + IDS_NOT_BOOL "Obiect boolean presupus" >>> + IDS_JSCRIPT_EXPECTED "Obiect JScript presupus" >>> + IDS_REGEXP_SYNTAX_ERROR "Eroare de sintaxă în expresie rațională" >>> + IDS_URI_INVALID_CHAR "URI care trebuie codificat conține caractere nevalide" >>> + IDS_ARRAY_EXPECTED "Obiect matrice presupus" >> "expresie rațională" should be translated as "expresie regulată" (I've >> also seen "regulară", but never "rațională") [1] >> >> "nevalid" sounds really odd and it's almost never used; imho "invalid" >> should be used instead [2] "Invalid" should be avoided actually as it also means a handicapped person. Reference http://i18n.ro/Glosar . "Nevalid" can be used or "caractere care nu sunt valide" if you want to avoid "nevalid". >> "presupus" sounds really confusing; something in the lines of "Se >> aștepta un obiect" sounds better to me and seems more standard [3] >> >> I really think we should try to make translations a bit standard, >> especially when it comes to technical terms. > Please work then with Claudia on the translations. I think she will > appreciate any help with them. > >> [1] http://ro.wikipedia.org/wiki/Expresie_regulat%C4%83 >> [2] http://ro.wikipedia.org/wiki/Special:C%C4%83utare/Invalid >> [3] http://translationproject.org/latest/coreutils/ro.po bye michael

June 18, 2010

Re: jscript: Add the Romanian translation. (2nd try)

by Michael Stefaniuc

Hello Octavian! Octavian Voicu wrote: > On Fri, Jun 18, 2010 at 12:14 PM, Michael Stefaniuc <mstefani(a)redhat.de> wrote: >> + IDS_INVALID_CALL_ARG "Apel de procedură sau argument nevalid" >> + IDS_SEMICOLON "„;” presupus" >> + IDS_LBRACKET "„(” presupus" >> + IDS_RBRACKET "„)” presupus" >> + IDS_UNTERMINATED_STR "Constantă de șir nedeterminată" >> + IDS_NOT_FUNC "Funcție presupusă" >> + IDS_NOT_NUM "Număr presupus" >> + IDS_OBJECT_EXPECTED "Obiect presupus" >> + IDS_NOT_BOOL "Obiect boolean presupus" >> + IDS_JSCRIPT_EXPECTED "Obiect JScript presupus" >> + IDS_REGEXP_SYNTAX_ERROR "Eroare de sintaxă în expresie rațională" >> + IDS_URI_INVALID_CHAR "URI care trebuie codificat conține caractere nevalide" >> + IDS_ARRAY_EXPECTED "Obiect matrice presupus" > > "expresie rațională" should be translated as "expresie regulată" (I've > also seen "regulară", but never "rațională") [1] > > "nevalid" sounds really odd and it's almost never used; imho "invalid" > should be used instead [2] > > "presupus" sounds really confusing; something in the lines of "Se > aștepta un obiect" sounds better to me and seems more standard [3] > > I really think we should try to make translations a bit standard, > especially when it comes to technical terms. Please work then with Claudia on the translations. I think she will appreciate any help with them. > [1] http://ro.wikipedia.org/wiki/Expresie_regulat%C4%83 > [2] http://ro.wikipedia.org/wiki/Special:C%C4%83utare/Invalid > [3] http://translationproject.org/latest/coreutils/ro.po thanks bye michael

June 18, 2010

Re: jscript: Add the Romanian translation. (2nd try)

by Octavian Voicu

On Fri, Jun 18, 2010 at 12:14 PM, Michael Stefaniuc <mstefani(a)redhat.de> wrote: > + IDS_UNTERMINATED_STR "Constantă de șir nedeterminată" Forgot about this one, maybe try "Constantă șir neterminată" [1]. When not sure how to translate a term, maybe this will help: google for "UNKNOWN TERM ro.po site:http://translationproject.org/". Octavian [1] http://translationproject.org/PO-files/ro/indent-2.2.8.ro.po

June 18, 2010

Re: jscript: Add the Romanian translation. (2nd try)

by Octavian Voicu

On Fri, Jun 18, 2010 at 12:14 PM, Michael Stefaniuc <mstefani(a)redhat.de> wrote: > + IDS_INVALID_CALL_ARG "Apel de procedură sau argument nevalid" > + IDS_SEMICOLON "„;” presupus" > + IDS_LBRACKET "„(” presupus" > + IDS_RBRACKET "„)” presupus" > + IDS_UNTERMINATED_STR "Constantă de șir nedeterminată" > + IDS_NOT_FUNC "Funcție presupusă" > + IDS_NOT_NUM "Număr presupus" > + IDS_OBJECT_EXPECTED "Obiect presupus" > + IDS_NOT_BOOL "Obiect boolean presupus" > + IDS_JSCRIPT_EXPECTED "Obiect JScript presupus" > + IDS_REGEXP_SYNTAX_ERROR "Eroare de sintaxă în expresie rațională" > + IDS_URI_INVALID_CHAR "URI care trebuie codificat conține caractere nevalide" > + IDS_ARRAY_EXPECTED "Obiect matrice presupus" "expresie rațională" should be translated as "expresie regulată" (I've also seen "regulară", but never "rațională") [1] "nevalid" sounds really odd and it's almost never used; imho "invalid" should be used instead [2] "presupus" sounds really confusing; something in the lines of "Se aștepta un obiect" sounds better to me and seems more standard [3] I really think we should try to make translations a bit standard, especially when it comes to technical terms. Octavian [1] http://ro.wikipedia.org/wiki/Expresie_regulat%C4%83 [2] http://ro.wikipedia.org/wiki/Special:C%C4%83utare/Invalid [3] http://translationproject.org/latest/coreutils/ro.po

June 18, 2010

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

by Jerome Leclanche

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? > 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. > > Thank you > Damjan Jovanovic > > > Icons look good indeed. Is there a switch I can flick to turn off the version numbers though? -- J. Leclanche

June 18, 2010

Re: Xinput / DirectInput xbox360 controller support

by Alexandre Julliard

Vitaliy Margolen <wine-devel(a)kievinfo.com> writes: > Using Xorg for joystick enumeration seems to be like a good idea, except it > won't really help you much. You'll still have to find which evdev you have > to talk to, get all the joystick parameters, settings, etc. You won't get > all that info from xorg. You should. File bugs with Xorg to give you the info. -- Alexandre Julliard julliard(a)winehq.org

June 18, 2010

Re: The __WINE__ macro does not identify the Wine platform

by Alexandre Julliard

"Alan W. Irwin" <irwin(a)beluga.phys.uvic.ca> writes: > Note also, my whole argument is based on the assumption that some standard > means already exists for telling compilers running on Wine to #define > __WINE__ at run time. However, if such standard means do not already exist > there is no way I would want to ask for changes in any compilers (as you > incorrectly imply later in your post), and again I would just live with > it. It sounds like you are confusing compile time and run time. The __WINE__ define can be used at compile time to detect the Wine build environment. If you are using a Windows compiler you have a Windows build environment, not a Wine one, so __WINE__ is not defined. That the Windows compiler is currently running under Wine is completely irrelevant. If what you want is to add workarounds for Wine in your code, then neither __WINE__ nor the build platform matter. What matters is the platform your code is currently running on, which should be detected at run-time. -- Alexandre Julliard julliard(a)winehq.org

June 18, 2010

Re: comctl32: restore focus if it was lost during the processing of PROPSHEET_SetWizButtons

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > commit 87f9053ec43e0272e27280e1e7ab9674fc79b109 > Author: Aric Stewart <aric(a)codeweavers.com> > Date: Fri Jun 18 13:21:56 2010 +0900 > > comctl32: restore focus if it was lost during the processing of PROPSHEET_SetWizButtons It would probably be better to not disable buttons that don't need it. What is this fixing? -- Alexandre Julliard julliard(a)winehq.org

June 18, 2010

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

by Damjan Jovanovic

On Fri, Jun 18, 2010 at 2:55 AM, Scott Ritchie <scott(a)open-vote.org> wrote: > Screenshot/blog here: http://yokozar.org/blog/archives/225 > > A bug was fixed recently in Gnome that allows thumbnailers to not be > 96x96 pixels. Combine this with a standard Wine icon, icoutils for > extracting an exe/dll's embedded icon, and a bit of magic and you can > get icons like those above. > > The version numbers come from the .exe metadata. I think it's really > slick, and will try and have it installed by default with Wine 1.2. At > the moment it exists as thumbnailer code for Gnome, which means other > desktops won't benefit, however provided they can be told to run a > script to generate an icon it should be fairly easy to port. > > Code is available in the gnome-exe-thumbnailer source package here: > https://edge.launchpad.net/~ubuntu-wine/+archive/ppa > > Please note that this is an updated version of the proof of concept > gnome-exe-thumbnailer package I put in Lucid (which is ugly and uses the > overly large 96x96 icons, and is thus not default and has so far gone > unnoticed). > > Thanks, > Scott Ritchie > > > 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). 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. Thank you Damjan Jovanovic

June 18, 2010

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

by Paul Chitescu

On Friday 18 June 2010 03:05:08 am Alan W. Irwin wrote: > On 2010-06-17 17:07-0400 Mike Kaplinskiy wrote: > > > On Thu, Jun 17, 2010 at 4:35 PM, Alan W. Irwin > >> 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. [...] > >> 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? > > > > > To make sure your numbers are somewhat consistent, you might want to > > do `wineserver -p; wine notepad` before tests to make sure the > > wineserver is loaded. It should help with timing of a single app > > startup, but probably won't help in the cmake case. > > I don't think I have access to notepad, but I assume that was just your > template for any wine app I am timing. I agree timing results depend > strongly on what has been previously cached in memory so the startup latency > timing tests, I report e.g., > > wine(a)raven> time wine gcc --version > gcc.exe (GCC) 4.5.0 > Copyright (C) 2010 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.143s > user 0m0.088s > sys 0m0.020s > > wine(a)raven> time wine lxxxx > wine: cannot find L"C:\\windows\\system32\\lxxxx.exe" > > real 0m0.011s > user 0m0.004s > sys 0m0.008s > > wine(a)raven> time gcc --version > gcc (Debian 4.3.2-1.1) 4.3.2 > Copyright (C) 2008 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.001s > user 0m0.000s > sys 0m0.004s > > are all quoted for the second run of the command with "wineserver -p" > running and with "export WINEDEBUG='all'" set. That typical difference > between ~150 ms startup latency on wine versus ~1 ms startup latency on > Linux is what I need to reduce in order to obtain reasonable build speeds on > Wine. > > Ideas? > > Alan > __________________________ > Alan W. Irwin Alan, Try to keep the wineserver initialized and running - for example keep a cmd.exe or notepad or something idle (in the same WINEPREFIX). To get more accurate timings run the test twice so the 2nd time the files should be cached in memory. If you are _sure_ you don't need a GUI you can unset DISPLAY (or run in a pure text console) so wine won't be able to create any windows. But the fact the X server matters suggests that some GUI components are used after all. Also please verify how fast gcc is to start on Windows, it may not be a wine problem. On Windows it is typically more expensive to start processes so Windows programs are usually more complex, do more tasks (eventually multithreaded) and live longer than the average UNIX program. Paul

June 18, 2010

Re: Xinput / DirectInput xbox360 controller support

by Roderick Colenbrander

On Thu, Jun 17, 2010 at 7:03 PM, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > On 06/16/2010 12:59 PM, Roderick Colenbrander wrote: >> I'm wondering how to proceed with XInput. My main issue is the >> 'joystick access part'. Would it be fine to directly access the >> controller from Xinput (so we would need multiple hardware backends >> later on). Code size won't be a problem though since XInput doesn't >> support much functionality at all (the current mostly working version >> is less than 500 lines of code; half of that is for the Linux >> backend). One small issue is though that DirectInput and XInput might >> have to cooperate since typically games use DirectInput to enumerate >> all joysticks, see for instance >> http://msdn.microsoft.com/en-us/library/ee417014%28VS.85%29.aspx > > IMHO directly accessing joysticks via evdev would be the best way. DInput is > a mess you don't want to deal with it (both in and out). And as you noted it > doesn't implement everything you need for xinput. > > Using Xorg for joystick enumeration seems to be like a good idea, except it > won't really help you much. You'll still have to find which evdev you have > to talk to, get all the joystick parameters, settings, etc. You won't get > all that info from xorg. > > Vitaliy. > It looks like on Windows xinput also directly access the USB device (the hardware buffer directly maps onto the xinput datatypes). In the far away future once we have WMI it might make sense to use that in both xinput and dinput to enumerate devices (I wouldn't be surprised if dinput used that internally these days and perhaps dxdiag and other dlls use it as well). As I mentioned the xinput API is really basic but for my liking it is slightly too basic. What I don't like is that there is no function to open the device (it is all about XInputGetState and also about XInputSetKeyStroke which is needed for force feedback). Right now I'm opening/closing the file descriptor each call and I don't like that. You also can't keep them open because xinput allows hotplugging :( Not sure if this is going to be an issue though. If we really wanted we might be able to layer xinput on top of dinput (we would need a private property for the force feedback part) but I think it would cause all sorts of issues and the APIs don't match well at all. Some people attempted to do this already to support non-xbox joysticks in xinput but it has issues (I think they have issues with Acquire). Roderick

June 18, 2010

Re: Xinput / DirectInput xbox360 controller support

by Vitaliy Margolen

On 06/16/2010 12:59 PM, Roderick Colenbrander wrote: > I'm wondering how to proceed with XInput. My main issue is the > 'joystick access part'. Would it be fine to directly access the > controller from Xinput (so we would need multiple hardware backends > later on). Code size won't be a problem though since XInput doesn't > support much functionality at all (the current mostly working version > is less than 500 lines of code; half of that is for the Linux > backend). One small issue is though that DirectInput and XInput might > have to cooperate since typically games use DirectInput to enumerate > all joysticks, see for instance > http://msdn.microsoft.com/en-us/library/ee417014%28VS.85%29.aspx IMHO directly accessing joysticks via evdev would be the best way. DInput is a mess you don't want to deal with it (both in and out). And as you noted it doesn't implement everything you need for xinput. Using Xorg for joystick enumeration seems to be like a good idea, except it won't really help you much. You'll still have to find which evdev you have to talk to, get all the joystick parameters, settings, etc. You won't get all that info from xorg. Vitaliy.

June 18, 2010

Re: The __WINE__ macro does not identify the Wine platform

by Vitaliy Margolen

On 06/17/2010 02:56 PM, Alan W. Irwin wrote: > However, that doesn't appear to work for Windows native MinGW on wine. Correct. Programs running under Wine should not and are not aware of the fact they are running on Wine and not the real Windows. This aspect 100% analogous to a software running under virtual machine. The whole notion of "Wine detectability" was brought up multiple times and all conversions concluded with the answer "No, Wine will not provide a specific "blessed" mechanism of detecting Wine". However such means do exist. > I was aware of __WINE__ being defined for winegcc, but from the man page > it appears to me that winegcc is a cross-compiler which is a technique I > want to avoid. Winegcc is not a "cross-compiler". It's nothing more then a thin wrapper around system's compiler (be it gcc or something else). Winegcc can not create WinPE binaries, but only ELF winelib binaries, that can only run under Wine. I'm sure that's not what you are looking for. Vitaliy

June 18, 2010

Re: Help with simple winelib dll

by Seth Burleigh

Thanks all! I got it to work! There was 2 mistakes with my thing - first, i had an empty definition for DllMain which caused the error 126 and then , well, i called the wrong function from metatrader. I shouldve been calling MyWinFunction. I guess i wasn't doing this because i wasn't seeing it when doing nm MyWin.dll.so, i guess all that magic is done by some wine functions in the dll which i see are there!

June 18, 2010

Re: The __WINE__ macro does not identify the Wine platform

by Alan W. Irwin

On 2010-06-18 01:23+0100 Hin-Tak Leung wrote: > Alan W. Irwin wrote: >> Thus, is there not some standard means that could be used >> for wine to tell the various MinGW compilers built on Microsoft Windows but >> run under wine to always #define __WINE__? > > I am quite sure AJ will object to any such things - as far as the various > compilers (and windows applications in general) are concerned, they should > just believe they are running under windows. If a compiler (or a windows > application) behaves differently under Microsoft Windows vs under wine, it is > a bug for wine. I recommend you read the complete thread at http://www.mail-archive.com/wine-devel(a)winehq.com/msg15669.html where your point of view was expressed, but was eloquently answered to the point where the rest of the thread (including AJ) consisted of discussing implementation details. Of course it is quite possible AJ's views back then have changed now (or I misunderstood that thread). In that case I will just live with it, but let's let AJ speak for himself on this issue. Note also, my whole argument is based on the assumption that some standard means already exists for telling compilers running on Wine to #define __WINE__ at run time. However, if such standard means do not already exist there is no way I would want to ask for changes in any compilers (as you incorrectly imply later in your post), and again I would just live with it. 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 18, 2010

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

by Scott Ritchie

Screenshot/blog here: http://yokozar.org/blog/archives/225 A bug was fixed recently in Gnome that allows thumbnailers to not be 96x96 pixels. Combine this with a standard Wine icon, icoutils for extracting an exe/dll's embedded icon, and a bit of magic and you can get icons like those above. The version numbers come from the .exe metadata. I think it's really slick, and will try and have it installed by default with Wine 1.2. At the moment it exists as thumbnailer code for Gnome, which means other desktops won't benefit, however provided they can be told to run a script to generate an icon it should be fairly easy to port. Code is available in the gnome-exe-thumbnailer source package here: https://edge.launchpad.net/~ubuntu-wine/+archive/ppa Please note that this is an updated version of the proof of concept gnome-exe-thumbnailer package I put in Lucid (which is ugly and uses the overly large 96x96 icons, and is thus not default and has so far gone unnoticed). Thanks, Scott Ritchie

June 18, 2010

Re: The __WINE__ macro does not identify the Wine platform

by Hin-Tak Leung

Alan W. Irwin wrote: > Thus, is there not some standard means that could be used > for wine to tell the various MinGW compilers built on Microsoft Windows but > run under wine to always #define __WINE__? I am quite sure AJ will object to any such things - as far as the various compilers (and windows applications in general) are concerned, they should just believe they are running under windows. If a compiler (or a windows application) behaves differently under Microsoft Windows vs under wine, it is a bug for wine. AFAIK, the only "recommended/supported" way for an application to tell that it is running under wine vs under windows is by querying the presence of one of wine-specific registry entries. It is quite "evil" for a compiler to query the registry. Microsoft compilers probably try to probe the host about which versions of windows it is running in to work around "silently" various bugs in different/older versions of OSes which are fixed later, but I doubt any mingw people or GNU people for that matter, want to go down that path. In other words, don't even think about it.

June 18, 2010

Re: Brazilian Portuguese translation of winecfg

by Gustavo

Sorry, wrong list. My mistake. Em 17 de junho de 2010 20:56, Gustavo <gugamilare(a)gmail.com> escreveu: > Hello, > > I've updated the translation of winecfg in Brazilian Portuguese. > > Making comparisons, I also noted that the "Windows Version" (Versão do > Windows) drop-down menu disappeared and the Browse... (Localização:) text > in the Drives was cut to half when you execute wine with LANG="pt_PT.UTF-8" > (the Portuguese from Portugal). I've managed to fix that as well. > > So I sent two separate patches: one with the Brazilian translation and > another with the Portuguese fixes. Let me know if I did anything wrong. > > Gustavo Henrique Milaré >

June 18, 2010

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

by Alan W. Irwin

On 2010-06-17 17:07-0400 Mike Kaplinskiy wrote: > On Thu, Jun 17, 2010 at 4:35 PM, Alan W. Irwin >> 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. [...] >> 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? > > To make sure your numbers are somewhat consistent, you might want to > do `wineserver -p; wine notepad` before tests to make sure the > wineserver is loaded. It should help with timing of a single app > startup, but probably won't help in the cmake case. I don't think I have access to notepad, but I assume that was just your template for any wine app I am timing. I agree timing results depend strongly on what has been previously cached in memory so the startup latency timing tests, I report e.g., wine(a)raven> time wine gcc --version gcc.exe (GCC) 4.5.0 Copyright (C) 2010 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.143s user 0m0.088s sys 0m0.020s wine(a)raven> time wine lxxxx wine: cannot find L"C:\\windows\\system32\\lxxxx.exe" real 0m0.011s user 0m0.004s sys 0m0.008s wine(a)raven> time gcc --version gcc (Debian 4.3.2-1.1) 4.3.2 Copyright (C) 2008 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.001s user 0m0.000s sys 0m0.004s are all quoted for the second run of the command with "wineserver -p" running and with "export WINEDEBUG='all'" set. That typical difference between ~150 ms startup latency on wine versus ~1 ms startup latency on Linux is what I need to reduce in order to obtain reasonable build speeds on Wine. Ideas? 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 18, 2010

Brazilian Portuguese translation of winecfg

by Gustavo

Hello, I've updated the translation of winecfg in Brazilian Portuguese. Making comparisons, I also noted that the "Windows Version" (Versão do Windows) drop-down menu disappeared and the Browse... (Localização:) text in the Drives was cut to half when you execute wine with LANG="pt_PT.UTF-8" (the Portuguese from Portugal). I've managed to fix that as well. So I sent two separate patches: one with the Brazilian translation and another with the Portuguese fixes. Let me know if I did anything wrong. Gustavo Henrique Milaré

June 17, 2010

Re: The __WINE__ macro does not identify the Wine platform

by Alan W. Irwin

On 2010-06-17 17:13-0400 Mike Kaplinskiy wrote: > On Thu, Jun 17, 2010 at 4:56 PM, Alan W. Irwin > <irwin(a)beluga.phys.uvic.ca> wrote: >> According to some old discussion >> (http://www.mail-archive.com/wine-devel(a)winehq.com/msg15669.html) on >> wine-devel it appears that __WINE__ was going to be the macro used to >> identify the Wine platform, [...] >> Is the lack of a macro to identify the wine platform a bug I should report >> or am I missing something? > > You're compiling _under_ wine, and since wine attempts to be windows, > gcc will think you're on windows. If you want to compile a winelib > program/dll (i.e. a dll built specifically for wine and not windows) > you use winegcc which defines __WINE__. winegcc -E -dM foo.c should > contain #define __WINE__ 1. On 2010-06-17 21:30-0000 Hin-Tak Leung wrote: > You seems to have made one mistake - it is "winegcc", (without space) not "wine gcc". winegcc does define __WINE__ . To Mike and Hin-Tak: As alluded to by Mike, what I am doing is building software under wine using the Windows versions of MinGW, CMake, and MinGW make. I was aware of __WINE__ being defined for winegcc, but from the man page it appears to me that winegcc is a cross-compiler which is a technique I want to avoid. Note, that cmake configures MinGW make not only to build applications but also to test them. You cannot do the test part with just a cross compiler, and although I think it may be technically possible with CMake, it appears somewhat complicated to me to cross-compile from Linux to wine using Linux CMake, and then switch to the Wine platform for testing of the result using Windows CMake. Anyhow, to keep my build and test life simple, I just want to do everything on Wine. Furthermore, I would like to be free to choose any of the large variety of different versions of MinGW compilers. These considerations appear to rule out winegcc as a _general_ solution to the platform identification issue for those building software on Wine. I take Mike's point that currently Wine mimics Microsoft Windows so well that MinGW gcc thinks it is building on Microsoft Windows. In fact, that is an excellent statement of the problem. Because it is so useful to distinguish platforms when building software (the excellent motivation for this, e.g., to work around Wine bugs, is discussed in the mailing-list thread referenced above), I hope a general solution can be found for this problem. I am not familiar at all with run-time configuration of compilers, but my understanding is that compilers must be quite flexible about such configuration. Thus, is there not some standard means that could be used for wine to tell the various MinGW compilers built on Microsoft Windows but run under wine to always #define __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 17, 2010

RE: comctl32: Update English resource

by Ken Sharp

: -----Original Message----- : From: Alexandre Julliard [mailto:julliard(a)winehq.org] : Sent: Wednesday, 16 June 2010 7:10 PM : To: Juan Lang : Cc: Ken Sharp; Wine Devel : Subject: Re: comctl32: Update English resource : : Juan Lang <juan.lang(a)gmail.com> writes: : : > I don't understand why you would want to create multiple : > "translations" when their content is identical. If it's because the : > statistics you're generating claim a particular variant of English is : > incomplete, then you should fix the tool you're using to generate the : > statistics: unless there's an actual difference between American : > English and the variant, there's no need for a translation. : : The title is different, but I don't think that such minor spelling : differences justify having 4 copies of every resource. I'd suggest : waiting for po files support. But isn't that the point of SUBLANGs in the first place? All SUBLANGs will have minor differences. I was also told no translation would be wasted. Minor or not, spelling things correctly would be nice. People over here can't spell as it is. How soon are we going to see PO file support? PO files are definitely easier and smaller, and nicer. : : -- : Alexandre Julliard : julliard(a)winehq.org

June 17, 2010

RE: comctl32: Update English resource

by Ken Sharp

: -----Original Message----- : From: Juan Lang [mailto:juan.lang(a)gmail.com] : Sent: Wednesday, 16 June 2010 6:41 PM : To: Ken Sharp : Cc: Wine Devel : Subject: Re: comctl32: Update English resource : : Hi Ken, : : +LANGUAGE LANG_ENGLISH, SUBLANG_ENGLISH_CAN : + : +IDD_TBCUSTOMIZE DIALOG DISCARDABLE 10, 20, 357, 125 : +STYLE DS_MODALFRAME | WS_POPUP | WS_VISIBLE | WS_CAPTION | WS_SYSMENU : +CAPTION "Customize Toolbar" : +FONT 8, "MS Shell Dlg" : +BEGIN : + DEFPUSHBUTTON "&Close", IDCANCEL,308,6,44,14 : + PUSHBUTTON "R&eset", IDC_RESET_BTN,308,23,44,14 : + PUSHBUTTON "&Help", IDC_HELP_BTN,308,40,44,14 : + PUSHBUTTON "Move &Up", IDC_MOVEUP_BTN,308,74,44,14 : + PUSHBUTTON "Move &Down", IDC_MOVEDN_BTN,308,91,44,14 : + LTEXT "A&vailable buttons:", -1,4,5,84,10 : + LISTBOX IDC_AVAILBTN_LBOX,4,17,120,100, LBS_NOTIFY | : LBS_OWNERDRAWFIXED | LBS_HASSTRINGS | LBS_NOINTEGRALHEIGHT | : LBS_DISABLENOSCROLL | WS_BORDER | WS_VSCROLL | WS_HSCROLL | WS_TABSTOP : + PUSHBUTTON "&Add ->", IDOK, 131, 42, 44, 14 : + PUSHBUTTON "<- &Remove", IDC_REMOVE_BTN,131,62,44,14 : + LTEXT "&Toolbar buttons:", -1,182,5,78,10 : + LISTBOX IDC_TOOLBARBTN_LBOX, 182,17,120,100,LBS_NOTIFY | : LBS_OWNERDRAWFIXED | LBS_HASSTRINGS | LBS_NOINTEGRALHEIGHT | : LBS_DISABLENOSCROLL | WS_BORDER | WS_VSCROLL | WS_HSCROLL | WS_TABSTOP : +END : : I don't understand why you would want to create multiple : "translations" when their content is identical. If it's because the : statistics you're generating claim a particular variant of English is : incomplete, then you should fix the tool you're using to generate the : statistics: unless there's an actual difference between American : English and the variant, there's no need for a translation. : --Juan SUBLANG_ENGLISH_CAN picks up SUBLANG_NEUTRAL not SUBLANG_DEFAULT, and the spellings are different.

June 17, 2010

Re: Brazilian Portuguese translation

by Michael Stefaniuc

On 06/17/2010 11:48 PM, Gustavo wrote: > Sorry, forgot to CC. > > > 2010/6/17 André Hentschel <nerv(a)dawncrow.de <mailto:nerv(a)dawncrow.de>> > > > Try editing the rc files directly, it is not that hard. > also you might want to change some sizes(when text is wrapped in > your rebuild version of winecfg), that is also done in the rc files... > > -- > > Best Regards, André Hentschel > > > No that you mentioned it, it looks like po2rc is buggy as well. The > entries in the .rc file generated sometimes are repeated. po2rc has even more bugs. Now i'm fighting with it to read the po file as utf-8 and not as ASCII. Having to filter out non 7bit clean characters makes po2rc pretty pointless. There is a reason why Paul and I pledged to deal with this pain... bye michael > > For example: > > GROUPBOX " &Resolução da Tela ",IDC_STATIC,8,95,244,49 > [...] > > GROUPBOX " &Resolução da Tela ",IDC_STATIC,8,151,244,63 > [...] > > > While it should actually be > > GROUPBOX " Direct3D ",IDC_STATIC,8,95,244,49 > [...] > > GROUPBOX " &Resolução da Tela ",IDC_STATIC,8,151,244,63 > [...] > > > I double checked the .po file, and it translates Direct3D as Direct3D. > > I'll edit the .rc files directly :/ > > > Em 17 de junho de 2010 18:12, Michael Stefaniuc <mstefani(a)redhat.com > <mailto:mstefani(a)redhat.com>> escreveu: > > Hello Gustavo, > > If you prefer PO files please let Paul and I know and we can try > (there are other bugs in rc2po) to provide them to you. > > > Well, nevermind, I can edit .rc files directly. > > I've already finished translating the winecfg, now I'm going to test it. > I'll send the patches once I'm done. -- Michael Stefaniuc Tel.: +49-711-96437-199 Consulting Communications Engineer Fax.: +49-711-96437-111 -------------------------------------------------------------------- Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach Handelsregister: Amtsgericht Muenchen HRB 153243 Geschäftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera

June 17, 2010

Re: Brazilian Portuguese translation

by Gustavo

Sorry, forgot to CC. 2010/6/17 André Hentschel <nerv(a)dawncrow.de> > Try editing the rc files directly, it is not that hard. > also you might want to change some sizes(when text is wrapped in your > rebuild version of winecfg), that is also done in the rc files... > > -- > > Best Regards, André Hentschel > No that you mentioned it, it looks like po2rc is buggy as well. The entries in the .rc file generated sometimes are repeated. For example: GROUPBOX " &Resolução da Tela ",IDC_STATIC,8,95,244,49 [...] GROUPBOX " &Resolução da Tela ",IDC_STATIC,8,151,244,63 [...] While it should actually be GROUPBOX " Direct3D ",IDC_STATIC,8,95,244,49 [...] GROUPBOX " &Resolução da Tela ",IDC_STATIC,8,151,244,63 [...] I double checked the .po file, and it translates Direct3D as Direct3D. I'll edit the .rc files directly :/ Em 17 de junho de 2010 18:12, Michael Stefaniuc <mstefani(a)redhat.com>escreveu: > Hello Gustavo, > > If you prefer PO files please let Paul and I know and we can try (there are > other bugs in rc2po) to provide them to you. > Well, nevermind, I can edit .rc files directly. I've already finished translating the winecfg, now I'm going to test it. I'll send the patches once I'm done.

June 17, 2010

Re: usp10/tests: having numbers in the ScriptStringXtoCP tests causes unpredictable behavior

by Aric Stewart

lats wrote: > When does this unpredictability occur? The tests have always run ok for > me. The issue appears to be, and I am still investigating, sometimes usp10 will reorder the numbers differently. It appears to have to do with if windows and hdcs are repeatedly created and destroyed and cannot generally be recreated reliably. But if you look at earlier test runs you can see how the occasional machine was reporting ordering errors. They are still appearing on some machines so I am trying to continue to understand this, but removing the number greatly increased the reliability of the test. I have a modified test that demonstrates the issue. (loops and it does an Enum fonts and then then ScriptStringXtoCP test for each font. In the whole set of fonts looped 3-4 times machines will demonstrate this unreliability a few times) If you are interested in this modified test I can send you the patch. -aric

June 17, 2010

Re: The __WINE__ macro does not identify the Wine platform

by Hin-Tak Leung

You seems to have made one mistake - it is "winegcc", (without space) not "wine gcc". winegcc does define __WINE__ . --- On Thu, 17/6/10, Alan W. Irwin <irwin(a)beluga.phys.uvic.ca> wrote: > According to some old discussion > (http://www.mail-archive.com/wine-devel(a)winehq.com/msg15669.html) > on > wine-devel it appears that __WINE__ was going to be the > macro used to > identify the Wine platform, > > However, that doesn't appear to work for Windows native > MinGW on wine. > > To show this, I attach results from running > > wine gcc -E -dM foo.c >| /tmp/wine_gcc_dM.out > > where foo.c is an empty file, and gcc is the MinGW 4.5.0-1 > version. The > equivalent command under Linux gcc shows several macros, > (e.g., __linux__) > are defined to identify that platform, but I cannot find > anything in the > attached file that similarly identifies the Wine > platform. Furthermore, I > have compiled and run a simple test code under Wine that > shows that __WINE__ > is not available (see previous post on wine-users for > details). > > An excellent general motivation for such an identifying > macro for wine is > given in the above older wine-devel discussion, and I > understand the CMake > developers have an immediate use for such a macro within > the CMake code > itself. > > Is the lack of a macro to identify the wine platform a bug > I should report > or am I missing something? > > 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 17, 2010

Re: The __WINE__ macro does not identify the Wine platform

by Mike Kaplinskiy

On Thu, Jun 17, 2010 at 4:56 PM, Alan W. Irwin <irwin(a)beluga.phys.uvic.ca> wrote: > According to some old discussion > (http://www.mail-archive.com/wine-devel(a)winehq.com/msg15669.html) on > wine-devel it appears that __WINE__ was going to be the macro used to > identify the Wine platform, > > However, that doesn't appear to work for Windows native MinGW on wine. > > To show this, I attach results from running > > wine gcc -E -dM foo.c >| /tmp/wine_gcc_dM.out > > where foo.c is an empty file, and gcc is the MinGW 4.5.0-1 version. The > equivalent command under Linux gcc shows several macros, (e.g., __linux__) > are defined to identify that platform, but I cannot find anything in the > attached file that similarly identifies the Wine platform. Furthermore, I > have compiled and run a simple test code under Wine that shows that __WINE__ > is not available (see previous post on wine-users for details). > > An excellent general motivation for such an identifying macro for wine is > given in the above older wine-devel discussion, and I understand the CMake > developers have an immediate use for such a macro within the CMake code > itself. > > Is the lack of a macro to identify the wine platform a bug I should report > or am I missing something? > > 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 > __________________________ > > > You're compiling _under_ wine, and since wine attempts to be windows, gcc will think you're on windows. If you want to compile a winelib program/dll (i.e. a dll built specifically for wine and not windows) you use winegcc which defines __WINE__. winegcc -E -dM foo.c should contain #define __WINE__ 1. Mike.

June 17, 2010

Re: Brazilian Portuguese translation

by Michael Stefaniuc

Hello Gustavo, On 06/17/2010 07:47 PM, Gustavo wrote: > I can see that the Brazilian translation is bad, so I'm translating > winecfg. I followed the instruction in the wiki [1] to create a .po > file. At first I tried to recover from the file Pt.rc > > rc2po -t En.rc Pt.rc Pt.po > > but I didn't have much luck, no existing translations are shown. Adding > the options there is a bug in rc2po that prevents the generation of a PO file from an existing translation. Paul and I work with a hacked up version. > --lang=LANG_PORTUGUESE --sublang=SUBLANG_PORTUGUESE_BRAZILIAN > > or even just > > --lang=LANG_PORTUGUESE > > fails to create the file. Not much of a problem, I started from scratch. > The problem is, when I use the .po file to create the .rc file > > po2rc --lang=LANG_PORTUGUESE --sublang=SUBLANG_PORTUGUESE_BRAZILIAN -t > En.rc Pt.po Pt.rc > > only Brazilian Portuguese entries are created, and the Pt.rc file had > "Portuguese Portuguese" entries as well. > > What should I do? If you prefer PO files please let Paul and I know and we can try (there are other bugs in rc2po) to provide them to you. bye michael

June 17, 2010

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

by Mike Kaplinskiy

On Thu, Jun 17, 2010 at 4:35 PM, Alan W. Irwin <irwin(a)beluga.phys.uvic.ca> wrote: > 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 > __________________________ > > > To make sure your numbers are somewhat consistent, you might want to do `wineserver -p; wine notepad` before tests to make sure the wineserver is loaded. It should help with timing of a single app startup, but probably won't help in the cmake case. Mike.

June 17, 2010

The __WINE__ macro does not identify the Wine platform

by Alan W. Irwin

According to some old discussion (http://www.mail-archive.com/wine-devel(a)winehq.com/msg15669.html) on wine-devel it appears that __WINE__ was going to be the macro used to identify the Wine platform, However, that doesn't appear to work for Windows native MinGW on wine. To show this, I attach results from running wine gcc -E -dM foo.c >| /tmp/wine_gcc_dM.out where foo.c is an empty file, and gcc is the MinGW 4.5.0-1 version. The equivalent command under Linux gcc shows several macros, (e.g., __linux__) are defined to identify that platform, but I cannot find anything in the attached file that similarly identifies the Wine platform. Furthermore, I have compiled and run a simple test code under Wine that shows that __WINE__ is not available (see previous post on wine-users for details). An excellent general motivation for such an identifying macro for wine is given in the above older wine-devel discussion, and I understand the CMake developers have an immediate use for such a macro within the CMake code itself. Is the lack of a macro to identify the wine platform a bug I should report or am I missing something? 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 17, 2010

Re: Anotated 'make test' log

by Max TenEyck Woodbury

On 06/16/2010 04:48 PM, Dan Kegel wrote: > Max wrote: >> [Maybe we should modify FIXME itself to only print out once.] > > That's worth discussing, but changing FIXME itself might be going a > bit too far during the current code freeze. > You could try adding a FIXME_ONCE macro, though, and use it to quiet > some particular message that really gets in the way of (i.e. slows down) > a real application. > Something along the lines of? #define FIXME_ONCE(...) \ do { static volatile unsigned char once = 0U; \ if ( once == 0U ) { /* The race here is ignorable. */ \ once = ^0U; \ FIXME(__VA_ARGS__); \ } \ } while(0)

June 17, 2010

Speed/latency issues for development in a Wine environment

by Alan W. Irwin

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 __________________________

June 17, 2010

Re: Brazilian Portuguese translation

by André Hentschel

Am 17.06.2010 19:47, schrieb Gustavo: > Hello, > > I can see that the Brazilian translation is bad, so I'm translating > winecfg. I followed the instruction in the wiki [1] to create a .po > file. At first I tried to recover from the file Pt.rc > > rc2po -t En.rc Pt.rc Pt.po > > but I didn't have much luck, no existing translations are shown. Adding > the options > > --lang=LANG_PORTUGUESE --sublang=SUBLANG_PORTUGUESE_BRAZILIAN > > or even just > > --lang=LANG_PORTUGUESE > > fails to create the file. Not much of a problem, I started from scratch. > The problem is, when I use the .po file to create the .rc file > > po2rc --lang=LANG_PORTUGUESE --sublang=SUBLANG_PORTUGUESE_BRAZILIAN -t > En.rc Pt.po Pt.rc > > only Brazilian Portuguese entries are created, and the Pt.rc file had > "Portuguese Portuguese" entries as well. > > What should I do? > > Gustavo. > > [1] http://wiki.winehq.org/Translating > > > > Try editing the rc files directly, it is not that hard. also you might want to change some sizes(when text is wrapped in your rebuild version of winecfg), that is also done in the rc files... -- Best Regards, André Hentschel

June 17, 2010

Brazilian Portuguese translation

by Gustavo

Hello, I can see that the Brazilian translation is bad, so I'm translating winecfg. I followed the instruction in the wiki [1] to create a .po file. At first I tried to recover from the file Pt.rc rc2po -t En.rc Pt.rc Pt.po but I didn't have much luck, no existing translations are shown. Adding the options --lang=LANG_PORTUGUESE --sublang=SUBLANG_PORTUGUESE_BRAZILIAN or even just --lang=LANG_PORTUGUESE fails to create the file. Not much of a problem, I started from scratch. The problem is, when I use the .po file to create the .rc file po2rc --lang=LANG_PORTUGUESE --sublang=SUBLANG_PORTUGUESE_BRAZILIAN -t En.rc Pt.po Pt.rc only Brazilian Portuguese entries are created, and the Pt.rc file had "Portuguese Portuguese" entries as well. What should I do? Gustavo. [1] http://wiki.winehq.org/Translating

June 17, 2010

wined3d: Add NPOT quirk for GeforceFX 5200

by Roderick Colenbrander

June 17, 2010

Re: Help with simple winelib dll

by André Hentschel

Am 17.06.2010 04:52, schrieb Seth Burleigh: > OK, so i have the dll built. However, it doesn't seem to be able to > open. Let me explain, im using it in metatrader and so all im doing is > moving the dll.so (and renamed it to MyWin.dll) to its libraries folder > and doing an import statement in mql4. However, i then get a system > error 'Cannot load MyWin.dll (error 126)'. Ive looked it up and that > means 'The specified module could not be found' However, when checking > its dependencies using ldd MyWin.dll, it says it has found all > dependencies. So, is there something i need to do to register the dll so > that it can be loaded properly? > > Im assuming metatrader is using a dynamic loading scheme, though i don't > really know. > from the spec file there is a def file generated... change the def-file: replace "LIBRARY MyWin.dll.so" with "LIBRARY MyWin.dll" the run make again and you should get a dll which might be some more adaptive. -- Best Regards, André Hentschel

June 17, 2010

Re: usp10/tests: having numbers in the ScriptStringXtoCP tests causes unpredictable behavior

by lats

When does this unpredictability occur? The tests have always run ok for me.

June 17, 2010

Re: msvcrt/tests: Re-order tests to work around weird win_skip failure bug. (try 2)

by Alexandre Julliard

Alexander Scott-Johns <alexander.scott.johns(a)googlemail.com> writes: > Try 2: Re-order function bodies as well. > > From a51f6b7f855ccb1d9252a3d5e2698cdbe73ad053 Mon Sep 17 00:00:00 2001 > From: Alexander Scott-Johns <alexander.scott.johns(a)googlemail.com> > Date: Fri, 11 Jun 2010 14:13:52 +0100 > Subject: msvcrt/tests: Re-order tests to work around weird win_skip failure bug. > > Paul Vriens found which test caused the breakage. There's no need to reorder the functions, but there's a need to understand why that test is breaking win_skip. -- Alexandre Julliard julliard(a)winehq.org

June 17, 2010

Re: [2/2]kernel32/tests: Test the collation table much more

by Alexandre Julliard

André Hentschel <nerv(a)dawncrow.de> writes: > I added some ranges to test, so it is easy extensible That's still not a very convincing test... -- Alexandre Julliard julliard(a)winehq.org

June 17, 2010

Re: (resend) usp10/tests: Windows 95 does not set invalid glyphs to 0 but instead 0x80

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=2742 Your paranoid android. === WVISTAADM (32 bit usp10) === usp10.c:1395: Test failed: ScriptStringFree should return E_INVALIDARG or E_FAIL not 00000000 === W2K8SE (32 bit usp10) === usp10.c:1395: Test failed: ScriptStringFree should return E_INVALIDARG or E_FAIL not 00000000

June 17, 2010

Re: usp10/tests: Windows 95 does not set invalid glyphs to 0 but instead 0x80

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=2739 Your paranoid android. === WVISTAADM (32 bit usp10) === usp10.c:1395: Test failed: ScriptStringFree should return E_INVALIDARG or E_FAIL not 00000000 === W2K8SE (32 bit usp10) === usp10.c:1395: Test failed: ScriptStringFree should return E_INVALIDARG or E_FAIL not 00000000

June 17, 2010

Re: Anotated 'make test' log

by James McKenzie

Dan Kegel wrote: > Max wrote: > >> [Maybe we should modify FIXME itself to only print out once.] >> > > That's worth discussing, but changing FIXME itself might be going a > bit too far during the current code freeze. > You could try adding a FIXME_ONCE macro, though, and use it to quiet > some particular message that really gets in the way of (i.e. slows down) > a real application. > > Dan: I've run into this with the fixme's in richedit many times. I've seen screen 'studdering' and really don't know where the fixme belongs in my use/test of several programs over the last few days. I will have time this weekend to look further into a couple of regressions (hopefully we will see one more cycle before Wine 1.2 is released) and possibly be able to fix or point out a fix to at least one of them. James McKenzie

June 17, 2010

Re: Help with simple winelib dll

by Seth Burleigh

OK, so i have the dll built. However, it doesn't seem to be able to open. Let me explain, im using it in metatrader and so all im doing is moving the dll.so (and renamed it to MyWin.dll) to its libraries folder and doing an import statement in mql4. However, i then get a system error 'Cannot load MyWin.dll (error 126)'. Ive looked it up and that means 'The specified module could not be found' However, when checking its dependencies using ldd MyWin.dll, it says it has found all dependencies. So, is there something i need to do to register the dll so that it can be loaded properly? Im assuming metatrader is using a dynamic loading scheme, though i don't really know.

June 17, 2010

Re: [PATCH] winspool/tests: Handle the Windows bug in GetPrinterDataEx

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=2720 Your paranoid android. === WINEBUILD (build) === Can't determine base name

June 17, 2010

Re: PGO and wine

by Scott Ritchie

On 06/16/2010 09:58 AM, Austin English wrote: > On Wed, Jun 16, 2010 at 11:54 AM, Reece Dunn <msclrhd(a)googlemail.com> wrote: >> On 16 June 2010 09:11, Peter Davies <ultratwo(a)gmail.com> wrote: >>> On 16 June 2010 02:37, Dan Kegel <dank(a)kegel.com> wrote: >>>> But does PGO improve performance measurably? >>>> >>> >>> Probably, to test it I need a program that runs wine like a typical >>> program, that I can run autonomously. Anyone have any ideas? >> >> We could see if using Firefox or Chrome on some sites and benchmarks >> helps boost its performance when using a PGO version of Wine. >> >> We could also try out some games (stressing the D3D/DirectDraw logic) >> to see if the framerate improves. > > Using Dan's yagmark would be good for this task: > http://wiki.winehq.org/yagmark > By the way the profiling data is plain text and can be stored inside the debian/ folder when making an Ubuntu package. I imagine something similar can be done for other package systems as well. An alternative approach is to generate the profiling data at package build time using a sort of "make profiledbuild" and giving it a script such as yagmark. This is more or less what Mozilla does, except it was broken on Linux until recently and still isn't included in the Ubuntu packages... Thanks, Scott Ritchie

June 17, 2010

Re: Xinput / DirectInput xbox360 controller support

by Roderick Colenbrander

On Wed, Jun 16, 2010 at 11:42 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: > Roderick Colenbrander <thunderbird2k(a)gmail.com> writes: > >> I'm wondering how to proceed with XInput. My main issue is the >> 'joystick access part'. Would it be fine to directly access the >> controller from Xinput (so we would need multiple hardware backends >> later on). Code size won't be a problem though since XInput doesn't >> support much functionality at all (the current mostly working version >> is less than 500 lines of code; half of that is for the Linux >> backend). One small issue is though that DirectInput and XInput might >> have to cooperate since typically games use DirectInput to enumerate >> all joysticks, see for instance > > That sort of thing should really go through X11. > I agree this stuff should work through X11 but it still isn't ready for this stuff. There is joystick support (it might have improved thanks to XInput2) but there is no support for force feedback (though they took that into account for the protocol). Not sure if they will add it though since the trend seems to solve problems outside of X11 instead of fixing it in there... Roderick

June 16, 2010

Re: wrong link between bug and AppDB

by Austin English

2010/6/16 <wylda(a)volny.cz>: > > Hi, i just made a mistake and linked bug 9264 with http://appdb.winehq.org/objectManager.php?sClass=version&iId=20179. > > But i wanted to link 19264 instead of 9264. What are the correct steps > to fix this mistake? Looks like it already is fixed. -- -Austin

June 16, 2010

wrong link between bug and AppDB

by wylda＠volny.cz

Hi, i just made a mistake and linked bug 9264 with http://appdb.winehq.org/objectManager.php?sClass=version&iId=20179. But i wanted to link 19264 instead of 9264. What are the correct steps to fix this mistake? -- Kaspersky Internet Security 2010 + Kaspersky Mobile Security jen za 1199,-Kč. Ochraňte svůj počítač i mobil před zneužitím či ztrátou dat. Kupte si 2 produkty za cenu jednoho. www.kaspersky.cz

June 16, 2010

Re: Xinput / DirectInput xbox360 controller support

by Alexandre Julliard

Roderick Colenbrander <thunderbird2k(a)gmail.com> writes: > I'm wondering how to proceed with XInput. My main issue is the > 'joystick access part'. Would it be fine to directly access the > controller from Xinput (so we would need multiple hardware backends > later on). Code size won't be a problem though since XInput doesn't > support much functionality at all (the current mostly working version > is less than 500 lines of code; half of that is for the Linux > backend). One small issue is though that DirectInput and XInput might > have to cooperate since typically games use DirectInput to enumerate > all joysticks, see for instance That sort of thing should really go through X11. -- Alexandre Julliard julliard(a)winehq.org

June 16, 2010

Re: Anotated 'make test' log

by Dan Kegel

Max wrote: > [Maybe we should modify FIXME itself to only print out once.] That's worth discussing, but changing FIXME itself might be going a bit too far during the current code freeze. You could try adding a FIXME_ONCE macro, though, and use it to quiet some particular message that really gets in the way of (i.e. slows down) a real application. (p.s. the mail bounces are really distracting; they look like this: Delivery to the following recipient failed permanently: max(a)mtew.isa-geek.net Technical details of permanent failure: Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550 5.7.1 <max(a)mtew.isa-geek.net>... Relaying denied (state 14).)

June 16, 2010

Re: Wine on cygwin now compiles!

by Steven Edwards

On Wed, Jun 16, 2010 at 4:04 PM, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > I don't expect Wine itself to ever work on cygwin. Last year I asked > AJ about it and there are some special file handle features which are > needed. This stuff is supported in SUA but at least in the Vista > version this was broken. They MIGHT have fixed it for Win7, so if Wine > can work on Windows it would need Win7 but still you would need a > version which supports SUA (which are Ultimate and perhaps some > business version). If anyone is sufficiently interested in the sendrecv message sockets over file descriptor stuff (I know I am not anymore) there may be an archived email with a regression test I found showing the problem. Even though it was now listed as a supported operation, it kinda sorta worked in limited cases under Server 2003 and hung in others which Wine stress. I don't even recall all of the details at this point but it culminated in me presenting my findings to the SUA team developers and them saying 'that's nice, call our support to file a bug report'. Since I could not actually file the bug report myself online and calling Microsoft support is like a $200 (even if they do issue a refund or not charge your CC if it's a new real bug), I decided to waste no more time with it. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

June 16, 2010

Re: Wine on cygwin now compiles!

by Roderick Colenbrander

I don't expect Wine itself to ever work on cygwin. Last year I asked AJ about it and there are some special file handle features which are needed. This stuff is supported in SUA but at least in the Vista version this was broken. They MIGHT have fixed it for Win7, so if Wine can work on Windows it would need Win7 but still you would need a version which supports SUA (which are Ultimate and perhaps some business version). Roderick

June 16, 2010

Re: Wine on cygwin now compiles!

by David Gerard

On 16 June 2010 20:41, Austin English <austinenglish(a)gmail.com> wrote: > Thanks to a few recent commits by AJ (and several commits over the > past months by others), wine now builds on Cygwin. > Not everything works, of course, but still a neat exercise in recursion. And thus the fifth seal was broken! (Sixth is someone writing a program loader for Wine on Cygwin. Seventh is Win16 working in the Cygwin build.) I suppose we can't have this in the 1.2 press release, really ;-) - d.

June 16, 2010

Re: Xinput / DirectInput xbox360 controller support

by Marcus Meissner

On Wed, Jun 16, 2010 at 08:59:26PM +0200, Roderick Colenbrander wrote: > Hi all, > > I'm interested in adding Xbox 360 controller support to Wine. For > people who don't know how this works and what's so special I will > first give a small introduction. > I'm wondering how to proceed with XInput. My main issue is the > 'joystick access part'. Would it be fine to directly access the > controller from Xinput (so we would need multiple hardware backends > later on). Code size won't be a problem though since XInput doesn't > support much functionality at all (the current mostly working version > is less than 500 lines of code; half of that is for the Linux > backend). One small issue is though that DirectInput and XInput might > have to cooperate since typically games use DirectInput to enumerate > all joysticks, see for instance > http://msdn.microsoft.com/en-us/library/ee417014%28VS.85%29.aspx I think it is fine to directly access the device in xinput. In the case there likely DINPUT will not acquire the device. Ciao, Marcus

June 16, 2010

Wine on cygwin now compiles!

by Austin English

Thanks to a few recent commits by AJ (and several commits over the past months by others), wine now builds on Cygwin. Not everything works, of course, but still a neat exercise in recursion. I've put a screenshot of wine's notepad running on XP on bugzilla (http://bugs.winehq.org/show_bug.cgi?id=21181) see: http://bugs2.winehq.org/attachment.cgi?id=28896 -- -Austin

June 16, 2010

Xinput / DirectInput xbox360 controller support

by Roderick Colenbrander

Hi all, I'm interested in adding Xbox 360 controller support to Wine. For people who don't know how this works and what's so special I will first give a small introduction. The Xbox 360 controller is a normal USB device which you can use from 'xinput*.dll' (typically xinput1_3.dll is used). The xinput API is very easy (and it is the same what is used on the Xbox360) and in total it exports a handful of functions. Basically there is a call to query the capabilities, a call to poll which button was pressed and a call to 'set the controller to a certain state' (rumble stuff) and a few other not so important calls. The dll can ONLY be used for xbox 360 compatible controllers and other controllers should use dinput. In Wine we have a stubbed xinput implementation. Last year Michael Gruber submitted a number of patches which added implementations for most calls but the code wasn't added. I tested his XInput code on current Wine and it actually works well in DirectX SDK examples including force feedback! After he submitted the code there was a short discussion on wine-devel but then it stopped. Michael his xinput code directly interfaces with the Linux input event interface. It was asked whether XInput can't be layered on top of DirectInput but that's not possible since DirectInput doesn't expose all the needed functionality (it doesn't support the Xbox360 force feedback). The other way around is also not possible because XInput is only for Xbox 360 controllers/joysticks while DirectInput also supports keyboard and mouse. I'm wondering how to proceed with XInput. My main issue is the 'joystick access part'. Would it be fine to directly access the controller from Xinput (so we would need multiple hardware backends later on). Code size won't be a problem though since XInput doesn't support much functionality at all (the current mostly working version is less than 500 lines of code; half of that is for the Linux backend). One small issue is though that DirectInput and XInput might have to cooperate since typically games use DirectInput to enumerate all joysticks, see for instance http://msdn.microsoft.com/en-us/library/ee417014%28VS.85%29.aspx Roderick

June 16, 2010

Re: comctl32: Update English resource

by Alexandre Julliard

Juan Lang <juan.lang(a)gmail.com> writes: > I don't understand why you would want to create multiple > "translations" when their content is identical. If it's because the > statistics you're generating claim a particular variant of English is > incomplete, then you should fix the tool you're using to generate the > statistics: unless there's an actual difference between American > English and the variant, there's no need for a translation. The title is different, but I don't think that such minor spelling differences justify having 4 copies of every resource. I'd suggest waiting for po files support. -- Alexandre Julliard julliard(a)winehq.org

June 16, 2010

Re: [PATCH] ntdll: The FPU control word for newly created threads is 0x27f.

by Alexandre Julliard

Henri Verbeet <hverbeet(a)gmail.com> writes: > On 16 June 2010 19:36, Alexandre Julliard <julliard(a)winehq.org> wrote: >> This should be done inside signal_init_thread(), that's already meant >> for platform-specific setup, there's no need to add a separate entry >> point. > That was the original plan, but signal_init_thread() is also called by > thread_init(). You have to handle that anyway. If you add a generic init_thread_fpu() entry point it has to be called for all threads too, otherwise it's not really generic. The initial thread can be detected for instance by checking if the process heap exists. -- Alexandre Julliard julliard(a)winehq.org

June 16, 2010

Re: [PATCH] ntdll: The FPU control word for newly created threads is 0x27f.

by Henri Verbeet

On 16 June 2010 19:36, Alexandre Julliard <julliard(a)winehq.org> wrote: > This should be done inside signal_init_thread(), that's already meant > for platform-specific setup, there's no need to add a separate entry > point. That was the original plan, but signal_init_thread() is also called by thread_init().

June 16, 2010

Re: comctl32: Update English resource

by Juan Lang

Hi Ken, +LANGUAGE LANG_ENGLISH, SUBLANG_ENGLISH_CAN + +IDD_TBCUSTOMIZE DIALOG DISCARDABLE 10, 20, 357, 125 +STYLE DS_MODALFRAME | WS_POPUP | WS_VISIBLE | WS_CAPTION | WS_SYSMENU +CAPTION "Customize Toolbar" +FONT 8, "MS Shell Dlg" +BEGIN + DEFPUSHBUTTON "&Close", IDCANCEL,308,6,44,14 + PUSHBUTTON "R&eset", IDC_RESET_BTN,308,23,44,14 + PUSHBUTTON "&Help", IDC_HELP_BTN,308,40,44,14 + PUSHBUTTON "Move &Up", IDC_MOVEUP_BTN,308,74,44,14 + PUSHBUTTON "Move &Down", IDC_MOVEDN_BTN,308,91,44,14 + LTEXT "A&vailable buttons:", -1,4,5,84,10 + LISTBOX IDC_AVAILBTN_LBOX,4,17,120,100, LBS_NOTIFY | LBS_OWNERDRAWFIXED | LBS_HASSTRINGS | LBS_NOINTEGRALHEIGHT | LBS_DISABLENOSCROLL | WS_BORDER | WS_VSCROLL | WS_HSCROLL | WS_TABSTOP + PUSHBUTTON "&Add ->", IDOK, 131, 42, 44, 14 + PUSHBUTTON "<- &Remove", IDC_REMOVE_BTN,131,62,44,14 + LTEXT "&Toolbar buttons:", -1,182,5,78,10 + LISTBOX IDC_TOOLBARBTN_LBOX, 182,17,120,100,LBS_NOTIFY | LBS_OWNERDRAWFIXED | LBS_HASSTRINGS | LBS_NOINTEGRALHEIGHT | LBS_DISABLENOSCROLL | WS_BORDER | WS_VSCROLL | WS_HSCROLL | WS_TABSTOP +END I don't understand why you would want to create multiple "translations" when their content is identical. If it's because the statistics you're generating claim a particular variant of English is incomplete, then you should fix the tool you're using to generate the statistics: unless there's an actual difference between American English and the variant, there's no need for a translation. --Juan

June 16, 2010

Re: [PATCH] ntdll: The FPU control word for newly created threads is 0x27f.

by Alexandre Julliard

Henri Verbeet <hverbeet(a)codeweavers.com> writes: > diff --git a/dlls/ntdll/thread.c b/dlls/ntdll/thread.c > index 36f1499..0d383bd 100644 > --- a/dlls/ntdll/thread.c > +++ b/dlls/ntdll/thread.c > @@ -384,6 +384,7 @@ static void start_thread( struct startup_info *info ) > thread_data->pthread_id = pthread_self(); > > signal_init_thread( teb ); > + signal_init_thread_fpu(); > server_init_thread( func ); > pthread_sigmask( SIG_UNBLOCK, &server_block_set, NULL ); This should be done inside signal_init_thread(), that's already meant for platform-specific setup, there's no need to add a separate entry point. Also you may want to do an fninit if new threads are not supposed to inherit FPU state. -- Alexandre Julliard julliard(a)winehq.org

June 16, 2010

Re: PGO and wine

by Austin English

On Wed, Jun 16, 2010 at 11:54 AM, Reece Dunn <msclrhd(a)googlemail.com> wrote: > On 16 June 2010 09:11, Peter Davies <ultratwo(a)gmail.com> wrote: >> On 16 June 2010 02:37, Dan Kegel <dank(a)kegel.com> wrote: >>> But does PGO improve performance measurably? >>> >> >> Probably, to test it I need a program that runs wine like a typical >> program, that I can run autonomously. Anyone have any ideas? > > We could see if using Firefox or Chrome on some sites and benchmarks > helps boost its performance when using a PGO version of Wine. > > We could also try out some games (stressing the D3D/DirectDraw logic) > to see if the framerate improves. Using Dan's yagmark would be good for this task: http://wiki.winehq.org/yagmark -- -Austin

June 16, 2010

Re: PGO and wine

by Reece Dunn

On 16 June 2010 09:11, Peter Davies <ultratwo(a)gmail.com> wrote: > On 16 June 2010 02:37, Dan Kegel <dank(a)kegel.com> wrote: >> But does PGO improve performance measurably? >> > > Probably, to test it I need a program that runs wine like a typical > program, that I can run autonomously. Anyone have any ideas? We could see if using Firefox or Chrome on some sites and benchmarks helps boost its performance when using a PGO version of Wine. We could also try out some games (stressing the D3D/DirectDraw logic) to see if the framerate improves. - Reece

June 16, 2010

Re: Help with simple winelib dll

by André Hentschel

Am 16.06.2010 15:50, schrieb Seth Burleigh: > Thanks, the example helped, i added in the dll main part. But im still > getting the WinMain error and im convinced it has something to do with > how im executing winemaker. > > winemaker . --nosource-fix --dll --single-target MyWin --nomfc -I"." > -L"." -iMyLinuxFunc > > The new command line result of make is > winegcc -c -I. -I. -o MyLinuxFunc.o MyLinuxFunc.c > winegcc -c -I. -I. -o MyWin.o MyWin.c > winegcc -o MyWin.so MyLinuxFunc.o MyWin.o -L. -lMyLinuxFunc > /usr/lib/wine/libwinecrt0.a(exe_main.o): In function `main': > (.text+0xa0): undefined reference to `WinMain' > collect2: ld returned 1 exit status > winegcc: i486-linux-gnu-gcc failed > make: *** [MyWin.so] Error 2 > The winemaker problem is something for me, i will look into it these days... -- Best Regards, André Hentschel

June 16, 2010

Re: PGO and wine

by André Hentschel

Am 16.06.2010 10:11, schrieb Peter Davies: > On 16 June 2010 02:37, Dan Kegel <dank(a)kegel.com> wrote: >> But does PGO improve performance measurably? >> > > Probably, to test it I need a program that runs wine like a typical > program, that I can run autonomously. Anyone have any ideas? > > Peter > > 7zip has a builtin benchmark... -- Best Regards, André Hentschel

June 16, 2010

Re: Help with simple winelib dll

by Seth Burleigh

Well, adding the -shared worked! Thanks! Is there any way i can get winemaker to do this automatically? I thought the -dll option would work?

June 16, 2010

Re: Help with simple winelib dll

by Seth Burleigh

Thanks, the example helped, i added in the dll main part. But im still getting the WinMain error and im convinced it has something to do with how im executing winemaker. winemaker . --nosource-fix --dll --single-target MyWin --nomfc -I"." -L"." -iMyLinuxFunc The new command line result of make is winegcc -c -I. -I. -o MyLinuxFunc.o MyLinuxFunc.c winegcc -c -I. -I. -o MyWin.o MyWin.c winegcc -o MyWin.so MyLinuxFunc.o MyWin.o -L. -lMyLinuxFunc /usr/lib/wine/libwinecrt0.a(exe_main.o): In function `main': (.text+0xa0): undefined reference to `WinMain' collect2: ld returned 1 exit status winegcc: i486-linux-gnu-gcc failed make: *** [MyWin.so] Error 2 The problem with doing -lMyLinuxFunc (where i have libMyLinuxFunc.so in the directory) is that for some reason the output i get when doing make is seth(a)seth-laptop:~/devel/meta$ make winegcc -o MyWin.so MyLinuxFunc.o MyWin.o -L. MyLinuxFunc winegcc: File does not exist: MyLinuxFunc make: *** [MyWin.so] Error 2 and the -L. is there to indicate the directory my library is in. Ive looked up the winmain error and it looks like it appears that im attempting to build a winmain application instead of a dll? How do i specify a dll? Im using wine1.2-dev and wine1.2 (well actually it says to the right that its 1.1.42 installed version) from the lucid 10.04 ubuntu repositories.

June 16, 2010

Re: [PATCH] ntdll: The FPU control word for newly created threads is 0x27f.

by Henri Verbeet

I forgot to mention this, but this fixes a regression introduced by commit e6611e22fb037a879205f1330d1a3485f9f18705.

June 16, 2010

Re: Help with simple winelib dll

by Seth Shelnutt

Seth, Take a look at the source code to the CUDA 3.0 wrapper I just finished. You have some mistakes in your coding and this should help provide you a better example. When I first was coding the CUDA 2.0 wrapper some people told me to look at opengl and how it was wrapper to the linux library so that is how I came up with this. http://shelnutt2.host56.com/wrapper.tar.gz Generally the specfile goes like @ stdcall cudaGetDeviceProperties( ptr long ) wine_cudaGetDeviceProperties Then in your .c file: cudaError_t WINAPI wine_cudaGetDeviceProperties( struct cudaDeviceProp *prop, int device) { WINE_TRACE("\n"); return cudaGetDeviceProperties(prop, device); } Also your linking looks off. You shouldn't be linking -l"." . You need to specify the exact file, like for CUDA we did -lcudart or -lcufft. I hope that help you some. -Seth Shelnutt On Wed, Jun 16, 2010 at 2:04 AM, Seth Burleigh <seth(a)tewebs.com> wrote: > Im attempting to build a dll which a windows program running under wine > can dynamically load. The dll will be a wrapper around a linux library. > In preparation ive tried to follow the instructions here > http://www.winehq.org/docs/winelib-guide/bindlls > with a simple example but have not succeeded. Below is the contents of > the files in my directory and the commands i executed. Can anyone help > out? Thanks! > > > > MyLinuxFunc.c > int MyLinuxFunc(int a,int b) { > return a+b; > } > ----------------------------- > MyLinuxFunc.h > int MyLinuxFunc(int,int); > ----------------------------- > libMyLinuxFunc.so > ----------------------------- > MyWin.dll.spec > 2 stdcall MyWinFunc (long long) MyProxyWinFunc > ----------------------------- > MyWin.c > > #include <MyLinuxFunc.h> > #include <windef.h> > int WINAPI MyProxyWinFunc (int a,int b) > { > return MyLinuxFunc(a,b); > } > ----------------------------- > > > winemaker . --nosource-fix --dll --single-target MyWin --nomfc -I"." > -L"." -iMyLinuxFunc > > make > winegcc -o MyWin.so MyLinuxFunc.o MyWin.o -L. -lMyLinuxFunc > MyWin.o: In function `MyProxyWinFunc': > MyWin.c:(.text+0x20): undefined reference to `MyLinuxFunc' > /usr/lib/wine/libwinecrt0.a(exe_main.o): In function `main': > (.text+0xa0): undefined reference to `WinMain' > collect2: ld returned 1 exit status > winegcc: i486-linux-gnu-gcc failed > make: *** [MyWin.so] Error 2 > > > > >

June 16, 2010

Re: [RESEND 2] Changes to enable the use of gcov and PGO

by Peter Davies

>LDFLAGS are already passed to winegcc where appropriate. Oops, hadn't noticed they got in though $(ALL_LIBS), you can omit that part of the patch then. Why do we silently drop unrecognized args in "winegcc" anyway? Peter

June 16, 2010

Re: Anotated 'make test' log

by Max TenEyck Woodbury

> Dan wrote: >> OK. I'd suggest starting by looking at >> http://bugs.winehq.org/show_bug.cgi?id=15435 >> "Wine logs too verbose, quieter fixme's needed" and sending >> in a patch to make one of the overly-verbose fixme's a bit >> quieter. > > Thanks. I'll look at it. > Summary: Wine logs too verbose, quieter fixme's needed The bug report contains, among other things, this suggestion: > One thing we've done in the past is added a check to only > print the fixme the first time it's hit. This is probably the > way to go. ... > I took a look at this one, but it seems there's a > WINE_SPI_FIXME macro in there, which makes it a bit harder to > fix. Which suggests to me that the macro(s) could be modified to: 1. Use a local code block to declare a static flag variable. 2. Check that variable for zero (the default initial value IIUC) 3. and if it is zero, set the flag non-zero and print the message. There is a short race where different threads might see the zero value. If that happens, the message would be printed more than once. I believe that is acceptable because the alternate is to create a critical section, which is over-kill. That would limit ALL fixme's to one printing. The bug report mentioned variable information that might be included but implied that any such information is more properly included in a 'trace'. - Max

June 16, 2010

Re: [2/9] setupapi: Validate the cabinet filename parameter in SetupIterateCabinetA.

by Alexandre Julliard

Andrew Nguyen <anguyen(a)codeweavers.com> writes: > --- > dlls/setupapi/setupcab.c | 7 ++- > dlls/setupapi/tests/Makefile.in | 1 + > dlls/setupapi/tests/setupcab.c | 121 +++++++++++++++++++++++++++++++++++++++ > 3 files changed, 128 insertions(+), 1 deletions(-) > create mode 100644 dlls/setupapi/tests/setupcab.c It doesn't work here: wine: Unhandled page fault on write access to 0x6864dd7b at address 0x686a1c89 (thread 003a), starting debugger... Unhandled exception: page fault on write access to 0x6864dd7b in 32-bit code (0x686a1c89). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:686a1c89 ESP:0032f6e0 EBP:0032fa68 EFLAGS:00010246( R- -- I Z- -P- ) EAX:6864dd7b EBX:686b2cfc ECX:00000000 EDX:00000024 ESI:6865d68f EDI:0032f838 Stack dump: 0x0032f6e0: 0032f93c 6864dd7b 0032f838 0032fa4c 0x0032f6f0: 686a14e0 00000000 0032f724 ffffffff 0x0032f700: 0032fa40 0032f9e4 0032f768 7bc70be0 0x0032f710: 0000000e 00000002 00000001 0032f93c 0x0032f720: 00110060 acabfeed 00121100 00000000 0x0032f730: 00000000 00038080 2e366338 00706d74 Backtrace: =>0 0x686a1c89 SetupIterateCabinetA+0xc9(CabinetFile="", Reserved=0, MsgHandler=0x6864b9a0, Context=0x0(nil)) [/home/julliard/wine/wine/dlls/setupapi/setupcab.c:588] in setupapi (0x0032fd38) 1 0x6864bd95 test_invalid_parametersA+0x384() [/home/julliard/wine/wine/dlls/setupapi/tests/setupcab.c:108] in setupapi_test (0x0032fd88) 2 0x6864df0e run_test+0x14d(name=<is not available>) [/home/julliard/wine/wine/dlls/setupapi/tests/../../../include/wine/test.h:557] in setupapi_test (0x0032fe48) 3 0x6864e0e2 main+0x131(argc=<couldn't compute location>, argv=<couldn't compute location>) [/home/julliard/wine/wine/dlls/setupapi/tests/../../../include/wine/test.h:607] in setupapi_test (0x0032fe90) 4 0x6864e27c __wine_spec_exe_entry+0x7b(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in setupapi_test (0x0032fea8) 5 0x7b854ebc call_process_entry+0xb() in kernel32 (0x0032fee8) 6 0x7b85756b start_process+0x5a(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/kernel32/process.c:996] in kernel32 (0x0032fef8) 7 0x7bc71a40 call_thread_func+0xb() in ntdll (0x0032ffc8) 8 0x7bc71c10 call_thread_entry_point+0x6f(entry=0x7b857510, arg=0x7ffdf000) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2466] in ntdll (0x0032ffe8) 9 0x7bc4d5ca start_process+0x29(kernel_start=0x7b857510) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2612] in ntdll (0x00000000) 0x686a1c89 SetupIterateCabinetA+0xc9 [/home/julliard/wine/wine/dlls/setupapi/setupcab.c:588] in setupapi: movb $0x0,0x0(%eax) 588 *p = '\0'; -- Alexandre Julliard julliard(a)winehq.org

June 16, 2010

Re: ntdll: try to not raise exceptions when checking for atl thunks

by Alexandre Julliard

Markus Amsler <markus.amsler(a)oribi.org> writes: > From my attemp to write a test for atl thunks. I had a hard time to > get windows to emulate an atl thunk, so I worked my way backward from > a working atl thunk example. I knew there had to be some secret flag, > because in the WndProc atl thunks worked, outside not. So I took a > hard look at the TEB and found it. > > It was clean reverse engineered. I put it into to patch, to document > it somewhere. It would be better to document it as a test then (not necessarily the TEB flag, we probably don't need to go that far, but at least the basic case that was causing Shrinker to fail). -- Alexandre Julliard julliard(a)winehq.org

June 16, 2010

Re: ntdll: try to not raise exceptions when checking for atl thunks

by Markus Amsler

Am 16.06.2010 11:37, schrieb Alexandre Julliard: > Markus Amsler<markus.amsler(a)oribi.org> writes: > > >> + * Windows checks the following conditions before emulating an ATL thunk: >> + * - DEP policy allows emulating >> + * - thunk has memory type MEM_PRIVATE and is readable >> + * - jmp func is executable >> + * - thunk signature (movl, jmp) matches >> + * - a "secret" flag is set: >> + * The flag gets set before calling WndProc and cleared after WndProc >> + * or a thunk was emulated. >> + * In Windows XP SP 3 this flag is located at TEB+0xfb4. >> */ >> > Where does that information come from? > > From my attemp to write a test for atl thunks. I had a hard time to get windows to emulate an atl thunk, so I worked my way backward from a working atl thunk example. I knew there had to be some secret flag, because in the WndProc atl thunks worked, outside not. So I took a hard look at the TEB and found it. It was clean reverse engineered. I put it into to patch, to document it somewhere. Markus

June 16, 2010

Re: kernel32: stop CopyFile from overwriting a file with itself

by Alexandre Julliard

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > + if (h2 != INVALID_HANDLE_VALUE) > + { > + BY_HANDLE_FILE_INFORMATION info2; > + if (GetFileInformationByHandle( h2, &info2 )) > + { > + if (info.dwVolumeSerialNumber == info2.dwVolumeSerialNumber && > + info.nFileIndexLow == info2.nFileIndexLow && > + info.nFileIndexHigh == info2.nFileIndexHigh) The volume serial number is not the appropriate check. -- Alexandre Julliard julliard(a)winehq.org

June 16, 2010

Re: [RESEND 2] Changes to enable the use of gcov and PGO

by Alexandre Julliard

Peter Davies <ultratwo(a)gmail.com> writes: > @@ -72,7 +72,7 @@ MAKECTESTS = $(TOOLSDIR)/tools/make_ctests$(TOOLSEXT) > WRC = $(TOOLSDIR)/tools/wrc/wrc$(TOOLSEXT) > WMC = $(TOOLSDIR)/tools/wmc/wmc$(TOOLSEXT) > WIDL = $(TOOLSDIR)/tools/widl/widl$(TOOLSEXT) > -WINEGCC = $(TOOLSDIR)/tools/winegcc/winegcc $(TARGETFLAGS) -B$(TOOLSDIR)/tools/winebuild --sysroot=$(TOPOBJDIR) @UNWINDFLAGS@ > +WINEGCC = $(TOOLSDIR)/tools/winegcc/winegcc $(TARGETFLAGS) -B$(TOOLSDIR)/tools/winebuild --sysroot=$(TOPOBJDIR) @UNWINDFLAGS@ $(LDFLAGS) LDFLAGS are already passed to winegcc where appropriate. -- Alexandre Julliard julliard(a)winehq.org

June 16, 2010