November 2009 - Wine-Devel - list.winehq.org

Re: My script for doing testing

by Avery Pennarun

On Wed, Nov 25, 2009 at 12:08 PM, Austin English <austinenglish(a)gmail.com> wrote: > On Wed, Nov 25, 2009 at 10:33 AM, Jeremy White <jwhite(a)codeweavers.com> wrote: >> As promised, I'm attaching the script I'm using. > > I really wish you had said something to me before..I've been cleaning > my script up, with some help from Vincent. It's pretty similar, but a > bit more advanced (and supports Linux, BSD, Solaris and supposedly > Mac, but that's untested): > > http://winezeug.googlecode.com/svn/trunk/build_script/daily.sh It looks like you guys might benefit from my own project, gitbuilder: http://github.com/apenwarr/gitbuilder/ It does pretty much what you're describing (including a timeout), but with a few added features: - you can build any program, not just wine, and test it using a shell script of your choosing - you can run it as often as you want, and it'll build the latest commit on *all* branches and tags - it avoids an unnecessary extra 'git clone' and uses 'git clean -fdx' instead - the test script can return a pass/fail exit code, and if it fails, gitbuilder will automatically 'git bisect' to find the commit that introduced the problem. That last one is a huge benefit for our group, although of course if your tests don't ever 100% pass, it's not as useful :( Some example output for one of my company's projects: http://versabanq.com/demo/build/versaplex/ Have fun, Avery

Nov. 25, 2009

Re: Whitespace cleanups

by Nate Gallaher

Ken Thomases wrote: > One important reason to avoid whitespace-only changes is it makes git-blame essentially useless for finding the real source of functional changes. > But is that really important? git-bisect would put you on the other side of any whitespace changes, and a prudent bug-hunter should be referring to the commit logs anyway. There should be a path to eventual codebase sanity, no matter how slow. ~Nate

Nov. 25, 2009

Re: My script for doing testing

by Austin English

On Wed, Nov 25, 2009 at 10:33 AM, Jeremy White <jwhite(a)codeweavers.com> wrote: > So I have done my penance for failing to set up > a cron to run testing. I've got routine testing > going every night on 2 boxes. It seems solid. > > I see that many others have done this as well - test.winehq.org > wine results are really looking good. > > As promised, I'm attaching the script I'm using. > > This is my crontab line: > 06 02 * * 2-6 /home/jwhite/bin/winetestcron --repo /home/jwhite/w/wine/.git --tag jw-nv-32 > e.g. run the script at 2:06 am Tuesdays through Saturdays. > > I don't want this to be a general call for everyone > to run this script; rather, this might be a handy tool for > developers who are already running winetest to > save them a little hassle. > > My script probably has only one materially useful > feature - it uses a trap to enforce a timeout. > The rest is all pretty easy/obvious stuff. > > Also, I've only tested on Linux, not Mac. Sorry :-(. I really wish you had said something to me before..I've been cleaning my script up, with some help from Vincent. It's pretty similar, but a bit more advanced (and supports Linux, BSD, Solaris and supposedly Mac, but that's untested): http://winezeug.googlecode.com/svn/trunk/build_script/daily.sh By default, just running: $ sh daily.sh will test for $HOME/wine-git, run git fetch in it, then clone it to a temp directory, run make and winetest.exe in that directory, then remove the temp directory. Gecko is handled automatically, similar to yours. If $HOME/wine-git doesn't exist (you can override that directory with the $WINEGIT environmental variable), then it will run a git clone --depth 1 for you. The tag is also handled in a similar way, overridable, but by default will use the username and hostname of the machine. What I've done a bit different is allowing for some different testing configurations: WINEDEBUG=+heap, oss, esound, jack, pbuffer, backbuffer, glsl-disabled, virtual desktop, etc. The other neat thing is that it will run git fetch in a loop every 30 minutes (again, overridable), so that you can run it in the morning while waiting for AJ to commit. Once commits are made to the git master branch (but not stable), the script will kick into motion. I'm not depending on others to run this script, but if anyone does use it and find it useful, please send me any bug reports or file them on winezeug. I'm using this daily on my Linux box, but would love to see this being used daily on a FreeBSD/Solaris/OS X box (though I think a couple people are now submitting OS X results daily, so not as big of a deal there). -- -Austin

Nov. 25, 2009

Re: wineserver: Added support for read/only Registry, similar to unprivileged users

by Paul Chitescu

On Wednesday 25 November 2009 06:36:46 pm Paul Chitescu wrote: > Changelog: > wineserver: Added support for read/only Registry, similar to unprivileged > users > [...] How to test (if it gets accepted): chmod -w $WINEPREFIX/system.reg $WINEPREFIX/userdef.reg What to expect: Major breakage :-( for now err:font:delete_external_font_keys Can't create Windows font reg key err:wineboot:start_services_process Unexpected termination of services.exe - exit code 5 err:font:update_reg_entries Can't create Windows font reg key err:font:delete_external_font_keys Can't create Windows font reg key err:font:update_reg_entries Can't create Windows font reg key err:winspool:WINSPOOL_EnumPrinters Can't create Printers key err:winspool:CUPS_LoadPrinters Can't create Printers key err:winspool:PRINTCAP_ParseEntry Can't create Printers key err:winspool:WINSPOOL_EnumPrinters Can't create Printers key err:menubuilder:init_xdg error looking up the desktop directory err:font:delete_external_font_keys Can't create Windows font reg key err:font:update_reg_entries Can't create Windows font reg key err:winecfg:get_config_key RegOpenKey failed on wine config key (res=5) err:winecfg:get_config_key RegOpenKey failed on wine config key (res=5) err:winecfg:get_config_key RegOpenKey failed on wine config key (res=5) err:winecfg:get_config_key RegOpenKey failed on wine config key (res=5) err:winecfg:get_config_key RegOpenKey failed on wine config key (res=5) err:winecfg:get_config_key RegOpenKey failed on wine config key (res=5) err:winecfg:open_mountmgr failed to open mount manager err 2

Nov. 25, 2009

Re: [PATCH] kernel32: Respect the LANG environment variable on Mac OS.

by Ken Thomases

On Nov 24, 2009, at 7:52 AM, Charles Davis wrote: > I just realized something. The reason Wine doesn't respect LANG is that > it overrides the LC_MESSAGES setting if it is set to the default. It > will be set to the default if there is no LC_MESSAGES in the > environment. So we don't want to override LC_MESSAGES if there's a LANG > variable in the environment. Besides, why do all that work if we're not > going to override LANG anyway if it's already set? Mac OS X's Language & Text (formerly known as International) settings in System Preferences don't quite map exactly to Unix LANG or LC_* environment variables, which are a poor intermediary for mapping to Windows settings. The user's preferred language corresponds to LC_MESSAGES in intent. All the other LC_* variables correspond roughly to the settings on the Formats tab of the preference pane. One problem with trusting the LANG variable is that its UNIX semantics are as a fallback for the LC_* variables, not an override. Given that the user has selected a language and formats in System Preferences, that's like setting all of the various LC_* variables, so LANG should be ignored. Allowing LANG to override the user's preference settings would make Wine behave badly when run from Terminal.app if the user's preferred language and formats don't match (e.g. Japanese language, U.S. formats). Terminal (at least, recent versions) has a setting in its preferences to set the locale environment variables in shells it creates. However, it really only sets LANG according to the Region selected on the Formats tab. It does not set individual LC_* variables. It completely ignores the user's preferred language. If Wine were to rely on LANG, then all users with mismatched language and formats who launch it from Terminal would not get their preferred language. If you as a user want to override the language that Wine displays, you can set LC_MESSAGES in your environment rather than LANG. Setting LC_ALL would achieve that, plus override the various other locale categories. Set LANG is the wrong approach, in my opinion. -Ken

Nov. 25, 2009

Re: Fixing the kernel32:actctx tests on Vista+

by Jacek Caban

Hi Paul, Paul Vriens wrote: > Hi Jacek, > > You are the original author of these tests. Is there any reason the > "test3.manifest" name is reused? > > The tests currently crash (intermittently on some) on Vista+ and with > the attached patch things seem to get better. I'm just renaming one of > the manifest files so there are no duplicates in these tests. I don't remember much about these tests, but looking at the code I don't see any reason to reuse the name, so your patch looks good for me. Thanks, Jacek

Nov. 25, 2009

My script for doing testing

by Jeremy White

So I have done my penance for failing to set up a cron to run testing. I've got routine testing going every night on 2 boxes. It seems solid. I see that many others have done this as well - test.winehq.org wine results are really looking good. As promised, I'm attaching the script I'm using. This is my crontab line: 06 02 * * 2-6 /home/jwhite/bin/winetestcron --repo /home/jwhite/w/wine/.git --tag jw-nv-32 e.g. run the script at 2:06 am Tuesdays through Saturdays. I don't want this to be a general call for everyone to run this script; rather, this might be a handy tool for developers who are already running winetest to save them a little hassle. My script probably has only one materially useful feature - it uses a trap to enforce a timeout. The rest is all pretty easy/obvious stuff. Also, I've only tested on Linux, not Mac. Sorry :-(. Cheers, Jeremy #!/bin/bash #---------------------------------------------------- # winetestcron # script to run the Wine tests in an unattended fashion # Intended to be run from cron. If you run it in the # crontab of the user that is logged in to DISPLAY :0, # it should work. Otherwise, you might want to do a # xauth extract /your/file in your .xsession, and an # xauth merge /your/file in this script. #---------------------------------------------------- function usage() { echo -n "$0 --repo /path/to/your/.git/dir " echo "[--tag tag-to-report] " echo -n " [--gecko gecko-path] " echo "[--timeout secs] [--update-repo]" echo " [--configure extra-configure-args]" echo "repo is mandatory, must give the location of a .git directory, and " echo "will not be changed by default. If you specify update-repo, then a " echo "git fetch will be done in your repository before running winetest. " echo "The working tree will not be changed in any case." echo "tag is the tag name to report; see common tags on test.winehq.org for guidance." echo "timeout sets an overall script timeout, in seconds. Default is $TIMEOUT" echo "gecko specifies a path to the Gecko CAB file. Default is $GECKO_LOCATION" echo "configure will pass through the options to ./configure" } function parse_args() { GOPT=`getopt -o "" -l repo:,tag:,gecko:,timeout:,configure:,update-repo -- "$@"` GOPTERR=`getopt -o "" -l repo:,tag:,gecko:,timeout:,configure:,update-repo -- "$@" 2>&1` eval set -- "$GOPT" if [ $? != 0 -o "$GOPT" != "$GOPTERR" ] ; then usage exit 1 fi while true ; do case "$1" in --repo) export REFERENCE_GIT="$2"; shift 2;; --tag) export TAG="$2"; shift 2;; --gecko) export GECKO_LOCATION="$2"; shift 2;; --configure) export CONFIG_EXTRAS="$2"; shift 2;; --update-repo) export UPDATE_REPO="y"; shift;; --) shift; break;; *) echo "Error: uknown option $@"; usage ; exit ;; esac done if [ $# -gt 0 ] ; then echo "Error: Unexpected parameters $@" usage exit 1 fi if [ ! -d "$REFERENCE_GIT" ] ; then echo "Error: --repo must point to the .git directory of a valid WineHQ clone." usage exit 1 fi } function cleanup { "$TESTDIR/wine/server/wineserver" -k find /tmp -maxdepth 1 -type d -name 'winetest*' -ctime +2 -exec rm -rf {} \; exit } #--- # Set defaults #---- export GECKO_LOCATION=/usr/share/wine/gecko/ export TIMEOUT=3600 export TAG=`echo -n \`whoami\`-\`uname -m\` | sed 's/_/-/g'` #--- # Validate arguments #---- parse_args "$@" #--- # Get going... #---- TESTDIR=`mktemp -d /tmp/winetest.XXXXXXXX` TMPGITDIR="$TESTDIR/wine" mkdir "$TESTDIR/gecko" if [ -f "$GECKO_LOCATION/wine_gecko-1.0.0-x86.cab" ] ; then cp "$GECKO_LOCATION/wine_gecko-1.0.0-x86.cab" "$TESTDIR/gecko/" else echo $GECKO_LOCATION/wine_gecko-1.0.0-x86.cab not found. Bandwidth being wasted... ( cd "$TESTDIR/gecko" ; \ wget -o "$TESTDIR/wget.log" http://downloads.sourceforge.net/wine/wine_gecko-1.0.0-x86.cab \ ) fi if [ "$UPDATE_REPO" = "y" ] ; then git "--git-dir=$REFERENCE_GIT" fetch origin fi git clone --reference "$REFERENCE_GIT" git://source.winehq.org/git/wine.git "$TMPGITDIR" >"$TESTDIR/clone.log" 2>&1 cd "$TMPGITDIR" (./configure "$CONFIG_EXTRAS" && nice make ) > "$TESTDIR/build.log" 2>&1 export WINEPREFIX="$TESTDIR/.wine" export PATH="$TMPGITDIR:$PATH" export DISPLAY=:0 cd "$TESTDIR" # Set a trap to cleanup when a child exits. We either exit when # the Wine tests are complete, or the timeout happens; whichever # comes first set -m trap cleanup CHLD # Run the actual tests "$TMPGITDIR/wine" "$TMPGITDIR/programs/winetest/winetest.exe.so" -c -t "$TAG" >wine.log 2>&1 & # Set a timer to force an exit after $TIMEOUT sleep $TIMEOUT

Nov. 25, 2009

Re: Whitespace cleanups

by Ken Thomases

On Nov 25, 2009, at 9:13 AM, Nate Gallaher wrote: > I understand the "preserve existing format" rule, particularly in cases of braces, inter-paren spacing, variable > names, function names, and alignment, but I don't see the benefit of keeping 80-cols insanity around. One important reason to avoid whitespace-only changes is it makes git-blame essentially useless for finding the real source of functional changes. -Ken

Nov. 25, 2009

Fixing the kernel32:actctx tests on Vista+

by Paul Vriens

Hi Jacek, You are the original author of these tests. Is there any reason the "test3.manifest" name is reused? The tests currently crash (intermittently on some) on Vista+ and with the attached patch things seem to get better. I'm just renaming one of the manifest files so there are no duplicates in these tests. -- Cheers, Paul.

Nov. 25, 2009

Re: Whitespace cleanups

by Nate Gallaher

Nikolay Sivov wrote: >> or should I just fix the >> one function I'm planning on touching? Or should I grit my teeth >> and ignore the style issues >> entirely? > Yes, in most cases. If you plan to rework the whole file with > functional patches feel free to touch > formatting a bit. The common rule is to preserve existing format and > remove things like spaces before > tabs or trailing spaces (the rest is done while committing > automatically). I understand the "preserve existing format" rule, particularly in cases of braces, inter-paren spacing, variable names, function names, and alignment, but I don't see the benefit of keeping 80-cols insanity around. > What file are you talking about? dll/ntdll/signal_x86_64.c I took a first pass at 80-col fixing last night. There were some places where it wouldn't fit without breaking up some parallelism/symmetry/flow, so I just let the violation stand. From what James said, it sounds like if I hold myself to just the functions I touch, I should probably be ok. ~Nate

Nov. 25, 2009

Re: Whitespace cleanups

by James Mckenzie

Nate/Nikolay: Make sure that your patch has no white space errors and stay away from tabs, unless the current file is using them. git -apply should run without any errors. Cleaning up whitespace errors outside of code you are fixing should be very conservative. AJ likes it that way... BTW, I found whitespace errors in the code I'm working on and had to fix them as well. James McKenzie -----Original Message----- >From: Nikolay Sivov <bunglehead(a)gmail.com> >Sent: Nov 25, 2009 7:55 AM >To: Nate Gallaher <ngallaher(a)deepthought.org> >Cc: wine-devel(a)winehq.org >Subject: Re: Whitespace cleanups > >Nate Gallaher wrote: >> I'm looking at working on a new area of wine (for me) and the file I'm >> going to be working >> with is rife with whitespace issues. Literal tabs are sprinkled >> around and the 80-col limit >> has been broken badly and often in easily fixable ways. I'm wondering >> what the acceptable >> approach is to these issues. >> >> I'd like to fix these issues before I start submitting functional >> patches. My question is this: >> Is it acceptable to fix the whole file in one patch (80-cols), >No. >> or should I just fix the >> one function I'm planning on touching? Or should I grit my teeth and >> ignore the style issues >> entirely? >Yes, in most cases. If you plan to rework the whole file with functional >patches feel free to touch >formatting a bit. The common rule is to preserve existing format and >remove things like spaces before >tabs or trailing spaces (the rest is done while committing automatically). > >What file are you talking about? > > >

Nov. 25, 2009

Re: Whitespace cleanups

by Nikolay Sivov

Nate Gallaher wrote: > I'm looking at working on a new area of wine (for me) and the file I'm > going to be working > with is rife with whitespace issues. Literal tabs are sprinkled > around and the 80-col limit > has been broken badly and often in easily fixable ways. I'm wondering > what the acceptable > approach is to these issues. > > I'd like to fix these issues before I start submitting functional > patches. My question is this: > Is it acceptable to fix the whole file in one patch (80-cols), No. > or should I just fix the > one function I'm planning on touching? Or should I grit my teeth and > ignore the style issues > entirely? Yes, in most cases. If you plan to rework the whole file with functional patches feel free to touch formatting a bit. The common rule is to preserve existing format and remove things like spaces before tabs or trailing spaces (the rest is done while committing automatically). What file are you talking about?

Nov. 25, 2009

Whitespace cleanups

by Nate Gallaher

I'm looking at working on a new area of wine (for me) and the file I'm going to be working with is rife with whitespace issues. Literal tabs are sprinkled around and the 80-col limit has been broken badly and often in easily fixable ways. I'm wondering what the acceptable approach is to these issues. I'd like to fix these issues before I start submitting functional patches. My question is this: Is it acceptable to fix the whole file in one patch (80-cols), or should I just fix the one function I'm planning on touching? Or should I grit my teeth and ignore the style issues entirely? Thanks, ~Nate

Nov. 25, 2009

Re: Patch Tracker?

by Jerome Leclanche

Some people reply on wine-patches to comment on patches. Those are a safe bet to ignore when no patch is detected. There are a few examples on the page. J. Leclanche / Adys On Wed, Nov 25, 2009 at 3:37 PM, Nate Gallaher <ngallaher(a)deepthought.org> wrote: > I'm not sure what you're asking. Are you trying to ignore wine-devel threads > that > don't involve patches? > > ~Nate > > Jerome Leclanche wrote: >> >> Is it possible to ignore the Re:'s that don't have a patch attached? >> >> >> J. Leclanche / Adys >> >> >> >> On Tue, Nov 24, 2009 at 10:23 PM, Austin English >> <austinenglish(a)gmail.com> wrote: >> >>> >>> On Tue, Nov 24, 2009 at 3:22 PM, James Mckenzie >>> <jjmckenzie51(a)earthlink.net> wrote: >>> >>>> >>>> Austin English wrote: >>>> >>>>> >>>>> Sent: Nov 24, 2009 2:09 PM >>>>> To: Nate Gallaher <ngallaher(a)deepthought.org> >>>>> Cc: wine-devel(a)winehq.org >>>>> Subject: Re: Patch Tracker? >>>>> >>>>> On Tue, Nov 24, 2009 at 3:07 PM, Nate Gallaher >>>>> <ngallaher(a)deepthought.org> wrote: >>>>> >>>>>> >>>>>> There's a new patch tracker? >>>>>> >>>>> >>>>> http://source.winehq.org/patches/ >>>>> >>>>> >>>> >>>> Congratulations, Austin and Patch tracker team. >>>> >>> >>> I'm not involved, that was all Alexandre's doing. >>> >>> -- >>> -Austin >>> >>> >>> >>> >> >> >> > >

Nov. 25, 2009

Re: Patch Tracker?

by Jerome Leclanche

Is it possible to ignore the Re:'s that don't have a patch attached? J. Leclanche / Adys On Tue, Nov 24, 2009 at 10:23 PM, Austin English <austinenglish(a)gmail.com> wrote: > On Tue, Nov 24, 2009 at 3:22 PM, James Mckenzie > <jjmckenzie51(a)earthlink.net> wrote: >> Austin English wrote: >>>Sent: Nov 24, 2009 2:09 PM >>>To: Nate Gallaher <ngallaher(a)deepthought.org> >>>Cc: wine-devel(a)winehq.org >>>Subject: Re: Patch Tracker? >>> >>>On Tue, Nov 24, 2009 at 3:07 PM, Nate Gallaher >>><ngallaher(a)deepthought.org> wrote: >>>> There's a new patch tracker? >>> >>>http://source.winehq.org/patches/ >>> >> Congratulations, Austin and Patch tracker team. > > I'm not involved, that was all Alexandre's doing. > > -- > -Austin > > >

Nov. 25, 2009

Re: RFC: visual.c:783: Test failed: DSTALPHA on frame buffer returned color 0x00ff0000, expected 0x000000ff

by chris ahrendt

Roderick Colenbrander wrote: > On Wed, Nov 25, 2009 at 3:46 AM, chris ahrendt <celticht32(a)yahoo.com> wrote: >> Roderick Colenbrander wrote: >>> On Tue, Nov 24, 2009 at 5:12 AM, chris ahrendt <celticht32(a)yahoo.com> wrote: >>>> Ok going through and looking at the next failure in wine tests I found this one : >>>> >>>> >>>> If you look at the code its: >>>> >>>> >>>> 779 color = getPixelColor(device, 160, 120); >>>> 780 red = (color & 0x00ff0000) >> 16; >>>> 781 green = (color & 0x0000ff00) >> 8; >>>> 782 blue = (color & 0x000000ff); >>>> 783 ok(red == 0x00 && green == 0x00 && blue >= 0xfe && blue <= 0xff , >>>> 784 "DSTALPHA on frame buffer returned color 0x%08x, expected 0x000000ff\n", color); >>>> >>>> >>>> but in MSDN it says : >>>> >>>> This value is a 32-bit value used to specify an RGB color or CLR_INVALID >>>> >>>> Format of the rgb color is : >>>> >>>> 0x00bbggrr >>>> >>>> The low-order byte contains a value for the relative intensity of red, the second byte contains a value for green, and >>>> the third byte contains a value for blue. >>>> >>>> The high-order byte must be zero. >>>> >>>> The maximum value for a single byte is 0xFF. >>>> >>>> so shouldn't it be something like this: >>>> >>>> red = color & 0x000000FF; >>>> green = ( color & 0x0000FF00 ) >> 8; >>>> blue = ( color & 0x00FF0000 ) >> 16; >>>> >>>> not the what is in the test? because of the following C action >>>> >>>> expression1 >> shift_value >>>> >>>> Returns expression1 with its bits shifted to the right by the shift_value. The leftmost bits are replaced with zeros if >>>> the value is nonnegative or unsigned. This result is the integer part of expression1 divided by 2 raised to the power of >>>> shift_value. If expression1 is signed, then the result is implementation specific. >>>> >>>> so the test seems to be assigning the wrong values to the RGB.... Correct? >>>> >>>> chris >>>> >>> We are creating the framebuffer in the ARGB format (see init_d3d9). >>> D3D supports a variety of formats and we don't use the gdi RGB macro. >>> >>> Roderick >>> >>> >> Ok... but apparently this is returning it though in the above bbggrr format when color comes back so how do you set it >> to come back in the ARGB format??? Is that setup in the init_d3d9? >> >> chris >> > > The test passes properly on Wine + Nivida and I believe even on Intel. > There are just some bugs in the ATI drivers. That's the case with most > of the failing ddraw/d3d tests on ATI and other drivers. > > Roderick > > Oh I realise that... thats why I am trying to figure out where so I can open a bug with ATI... chris

Nov. 25, 2009

Re: Garmin watches and USB

by Stefan Dösinger

Am 24.11.2009 um 23:05 schrieb Michael Stefaniuc: >> > Stefan, let me guess, you just wanted to point him to http://wiki.winehq.org/USB ? ;) Whaaa. Searching the wiki might have saved me lots of typing...

Nov. 25, 2009

Re: RFC: visual.c:783: Test failed: DSTALPHA on frame buffer returned color 0x00ff0000, expected 0x000000ff

by Roderick Colenbrander

On Wed, Nov 25, 2009 at 3:46 AM, chris ahrendt <celticht32(a)yahoo.com> wrote: > Roderick Colenbrander wrote: >> On Tue, Nov 24, 2009 at 5:12 AM, chris ahrendt <celticht32(a)yahoo.com> wrote: >>> Ok going through and looking at the next failure in wine tests I found this one : >>> >>> >>> If you look at the code its: >>> >>> >>> 779 color = getPixelColor(device, 160, 120); >>> 780 red = (color & 0x00ff0000) >> 16; >>> 781 green = (color & 0x0000ff00) >> 8; >>> 782 blue = (color & 0x000000ff); >>> 783 ok(red == 0x00 && green == 0x00 && blue >= 0xfe && blue <= 0xff , >>> 784 "DSTALPHA on frame buffer returned color 0x%08x, expected 0x000000ff\n", color); >>> >>> >>> but in MSDN it says : >>> >>> This value is a 32-bit value used to specify an RGB color or CLR_INVALID >>> >>> Format of the rgb color is : >>> >>> 0x00bbggrr >>> >>> The low-order byte contains a value for the relative intensity of red, the second byte contains a value for green, and >>> the third byte contains a value for blue. >>> >>> The high-order byte must be zero. >>> >>> The maximum value for a single byte is 0xFF. >>> >>> so shouldn't it be something like this: >>> >>> red = color & 0x000000FF; >>> green = ( color & 0x0000FF00 ) >> 8; >>> blue = ( color & 0x00FF0000 ) >> 16; >>> >>> not the what is in the test? because of the following C action >>> >>> expression1 >> shift_value >>> >>> Returns expression1 with its bits shifted to the right by the shift_value. The leftmost bits are replaced with zeros if >>> the value is nonnegative or unsigned. This result is the integer part of expression1 divided by 2 raised to the power of >>> shift_value. If expression1 is signed, then the result is implementation specific. >>> >>> so the test seems to be assigning the wrong values to the RGB.... Correct? >>> >>> chris >>> >> We are creating the framebuffer in the ARGB format (see init_d3d9). >> D3D supports a variety of formats and we don't use the gdi RGB macro. >> >> Roderick >> >> > Ok... but apparently this is returning it though in the above bbggrr format when color comes back so how do you set it > to come back in the ARGB format??? Is that setup in the init_d3d9? > > chris > The test passes properly on Wine + Nivida and I believe even on Intel. There are just some bugs in the ATI drivers. That's the case with most of the failing ddraw/d3d tests on ATI and other drivers. Roderick

Nov. 25, 2009

Re: RFC: visual.c:783: Test failed: DSTALPHA on frame buffer returned color 0x00ff0000, expected 0x000000ff

by chris ahrendt

Roderick Colenbrander wrote: > On Tue, Nov 24, 2009 at 5:12 AM, chris ahrendt <celticht32(a)yahoo.com> wrote: >> Ok going through and looking at the next failure in wine tests I found this one : >> >> >> If you look at the code its: >> >> >> 779 color = getPixelColor(device, 160, 120); >> 780 red = (color & 0x00ff0000) >> 16; >> 781 green = (color & 0x0000ff00) >> 8; >> 782 blue = (color & 0x000000ff); >> 783 ok(red == 0x00 && green == 0x00 && blue >= 0xfe && blue <= 0xff , >> 784 "DSTALPHA on frame buffer returned color 0x%08x, expected 0x000000ff\n", color); >> >> >> but in MSDN it says : >> >> This value is a 32-bit value used to specify an RGB color or CLR_INVALID >> >> Format of the rgb color is : >> >> 0x00bbggrr >> >> The low-order byte contains a value for the relative intensity of red, the second byte contains a value for green, and >> the third byte contains a value for blue. >> >> The high-order byte must be zero. >> >> The maximum value for a single byte is 0xFF. >> >> so shouldn't it be something like this: >> >> red = color & 0x000000FF; >> green = ( color & 0x0000FF00 ) >> 8; >> blue = ( color & 0x00FF0000 ) >> 16; >> >> not the what is in the test? because of the following C action >> >> expression1 >> shift_value >> >> Returns expression1 with its bits shifted to the right by the shift_value. The leftmost bits are replaced with zeros if >> the value is nonnegative or unsigned. This result is the integer part of expression1 divided by 2 raised to the power of >> shift_value. If expression1 is signed, then the result is implementation specific. >> >> so the test seems to be assigning the wrong values to the RGB.... Correct? >> >> chris >> > We are creating the framebuffer in the ARGB format (see init_d3d9). > D3D supports a variety of formats and we don't use the gdi RGB macro. > > Roderick > > Ok... but apparently this is returning it though in the above bbggrr format when color comes back so how do you set it to come back in the ARGB format??? Is that setup in the init_d3d9? chris

Nov. 24, 2009

Re: Garmin watches and USB

by Michael Stefaniuc

On 11/24/2009 10:58 PM, Stefan Dösinger wrote: > Am 24.11.2009 um 22:43 schrieb Charles Davis: >> This really belongs on the wine-users mailing list. > I'm not sure - I think from the context of the mail Chris is a coder himself, and the answer to his question on wine-users would be "Wine currently cannot do this". > > I am not too involved into the device mapping stuff in Wine, but I think what the app is missing is the enumeration of the USB device in the Windows USB services and/or the proper registry keys. > > Currently the only way to make the device accessible for Windows apps is doing something like > > ln -s /dev/ttyUSB0 ~/.wine/dosdevices/COM1 > > Which gives you a classic serial port. But your app wants a USB-to-serial adapter with the right USB IDs etc. > > I think what is needed is an extension of the drive handling system that adds new drives when new disks are mounted to also add COM ports when serial ports appear, and add USB information when USB devices appear. I think this would be done somewhere in mountmgr.sys, but I am not sure. > > Maarten Lankhorst has written patches to get USB Storage devices listed properly a few years ago, in an attempt to make Windows Itunes sync to an Ipod. Those patches weren't committed because they need more work, but I think they would be a good starting point. Stefan, let me guess, you just wanted to point him to http://wiki.winehq.org/USB ? ;) bye michael

Nov. 24, 2009

Re: Garmin watches and USB

by Stefan Dösinger

Am 24.11.2009 um 22:43 schrieb Charles Davis: > This really belongs on the wine-users mailing list. I'm not sure - I think from the context of the mail Chris is a coder himself, and the answer to his question on wine-users would be "Wine currently cannot do this". I am not too involved into the device mapping stuff in Wine, but I think what the app is missing is the enumeration of the USB device in the Windows USB services and/or the proper registry keys. Currently the only way to make the device accessible for Windows apps is doing something like ln -s /dev/ttyUSB0 ~/.wine/dosdevices/COM1 Which gives you a classic serial port. But your app wants a USB-to-serial adapter with the right USB IDs etc. I think what is needed is an extension of the drive handling system that adds new drives when new disks are mounted to also add COM ports when serial ports appear, and add USB information when USB devices appear. I think this would be done somewhere in mountmgr.sys, but I am not sure. Maarten Lankhorst has written patches to get USB Storage devices listed properly a few years ago, in an attempt to make Windows Itunes sync to an Ipod. Those patches weren't committed because they need more work, but I think they would be a good starting point.

Nov. 24, 2009

Re: Garmin watches and USB

by Charles Davis

This really belongs on the wine-users mailing list. Chip

Nov. 24, 2009

Garmin watches and USB

by Chris Teague

I'm trying to get the Garmin ANT Agent 2.2.7 to run (http://www8.garmin.com/fitness/ant_product_page.jsp) This software talks over the ANT+ protocol (carried over USB) to the watch, to download Heart Rate and GPS info. I cannot get the program to install because it checks that the ANT dongle is plugged in before it will complete installation, and it won't detect it. I also cannot debug this .exe using IDA very effectively because it is a self-extracting zip executable. When I plug in the ANT dongle, it is recognized by Linux and mapped to ttyUSB0. The dongle came with the watch and is Garmin branded, but it's really a Dynastream ANT2USB chip. Below is what /var/log/messages shows when I insert the device. Nov 22 15:23:27 desktop kernel: [1982277.092697] usb 4-1: reset full speed USB device using uhci_hcd and address 24 Nov 22 15:23:27 desktop kernel: [1982277.335442] cp210x 4-1:1.0: cp210x converter detected Nov 22 15:23:27 desktop kernel: [1982277.452593] usb 4-1: reset full speed USB device using uhci_hcd and address 24 Nov 22 15:23:27 desktop kernel: [1982277.610343] usb 4-1: cp210x converter now attached to ttyUSB0 I'm trying to figure out exactly what the installer is looking for to see if the dongle is present. I get a "You must connect your USB ANT Stick.." message in a dialogbox, and a Retry button. I thought it was checking for the presence of a new COM port or maybe something in the Windows device tree? I have installed the app on a Windows box, copied over the directory to Linux and run the program successfully under Wine. I do not know if it is communicating with the ttyUSB0 device though, I suspect it is not and I test that out tonight. On Windows, inserting the USB Dongle does not create a new COM port - so my guess is that the software is not treating this as a virtual COM port. If so using the old dosdevices file won't work. Any suggestions for either of these problems: - debugging a self extracting zip installer - getting a Windows app to use ttyUSB0 instead of whatever Windows USB device it would normally read/write from Thanks for any ideas, Chris

Nov. 24, 2009

Re: Patch Tracker?

by Austin English

On Tue, Nov 24, 2009 at 3:22 PM, James Mckenzie <jjmckenzie51(a)earthlink.net> wrote: > Austin English wrote: >>Sent: Nov 24, 2009 2:09 PM >>To: Nate Gallaher <ngallaher(a)deepthought.org> >>Cc: wine-devel(a)winehq.org >>Subject: Re: Patch Tracker? >> >>On Tue, Nov 24, 2009 at 3:07 PM, Nate Gallaher >><ngallaher(a)deepthought.org> wrote: >>> There's a new patch tracker? >> >>http://source.winehq.org/patches/ >> > Congratulations, Austin and Patch tracker team. I'm not involved, that was all Alexandre's doing. -- -Austin

Nov. 24, 2009

Re: Patch Tracker?

by James Mckenzie

Austin English wrote: >Sent: Nov 24, 2009 2:09 PM >To: Nate Gallaher <ngallaher(a)deepthought.org> >Cc: wine-devel(a)winehq.org >Subject: Re: Patch Tracker? > >On Tue, Nov 24, 2009 at 3:07 PM, Nate Gallaher ><ngallaher(a)deepthought.org> wrote: >> There's a new patch tracker? > >http://source.winehq.org/patches/ > Congratulations, Austin and Patch tracker team. James McKenzie

Nov. 24, 2009

Re: Patch Tracker?

by Austin English

On Tue, Nov 24, 2009 at 3:07 PM, Nate Gallaher <ngallaher(a)deepthought.org> wrote: > There's a new patch tracker? http://source.winehq.org/patches/ -- -Austin

Nov. 24, 2009

Re: Patch Tracker?

by Owen Rudge

> There's a new patch tracker? http://source.winehq.org/patches/ :) -- Owen Rudge http://www.owenrudge.net/

Nov. 24, 2009

Re: Patch Tracker?

by Nate Gallaher

There's a new patch tracker? ~Nate Alexandre Julliard wrote: > Folks, > > I'll be out for the rest of the week, so there won't be a release this > Friday. 1.1.34 will be released on December 4. And with the new patch > tracker you can watch the patches pile up while I'm away ;-) > >

Nov. 24, 2009

Next release

by Alexandre Julliard

Folks, I'll be out for the rest of the week, so there won't be a release this Friday. 1.1.34 will be released on December 4. And with the new patch tracker you can watch the patches pile up while I'm away ;-) -- Alexandre Julliard julliard(a)winehq.org

Nov. 24, 2009

mapistub: add stubbed dll mapistub.dll

by Louis Lenders

I guess we can forward those functions to mapi32 later on. While running the app, no functions were called at all, it was even enough to copy a random dll into system32 , and call it mapistub.dll. That was enough to get the app going

Nov. 24, 2009

Re: ole32: Fix circular reference count in default handler objects.

by Rob Shearman

2009/11/24 Rob Shearman <robertshearman(a)gmail.com>: > This is caused by caching a pointer and reference to the data cache's > IPersistStorage interface without managing reference counts > appropriately. > --- > dlls/ole32/defaulthandler.c | 22 ++++++++++++++++++++++ > 1 files changed, 22 insertions(+), 0 deletions(-) > > Fixes memory leaks in defaulthandler tests. May also fix bugs 12419 & 14863. I should also note that the rules for aggregating objects implemented by this patch are listed here: http://msdn.microsoft.com/en-us/library/ms686558(VS.85).aspx -- Rob Shearman

Nov. 24, 2009

Re: [PATCH] kernel32: Respect the LANG environment variable on Mac OS.

by Charles Davis

I just realized something. The reason Wine doesn't respect LANG is that it overrides the LC_MESSAGES setting if it is set to the default. It will be set to the default if there is no LC_MESSAGES in the environment. So we don't want to override LC_MESSAGES if there's a LANG variable in the environment. Besides, why do all that work if we're not going to override LANG anyway if it's already set?

Nov. 24, 2009

dlls/kernel32/path.c: Fix return values for UNC pathnames in GetLongPathNameW

by Alexandre Hardy

The MSDN: http://msdn.microsoft.com/en-us/library/aa364980(VS.85).aspx states that GetLongPathNameW returns the length of the string required to hold the pathname if the buffer is too small to hold the path. In the case where the buffer is too small, the filename should not be stored in the buffer. This ensures that the buffer is not written to (for UNC pathnames) if the buffer is not large enought to store the path. Kind regards Alexandre -- -------------------------------------------------- Alexandre Hardy http://www.ahardy.za.net

Nov. 24, 2009

Re: wineserver: Mark registry hives clean after being loaded initially from file

by Alexandre Julliard

Paul Chitescu <paulc(a)voip.null.ro> writes: > @@ -1393,6 +1393,7 @@ > fprintf( stderr, "%s is not a valid registry file\n", filename ); > return; > } > + make_clean( key ); It would be better to create them with the correct flags in the first place. -- Alexandre Julliard julliard(a)winehq.org

Nov. 24, 2009

Re: opengl32: fix wglCreateContextAttribsARB on nvidia

by Roderick Colenbrander

On Tue, Nov 24, 2009 at 9:10 AM, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > "Roderick Colenbrander" <thunderbird2k(a)gmail.com> wrote: > >> +/* Nvidia converts win32 error codes to (0xc007 << 16) | win32_error_code >> */ >> +#define NVIDIA_HRESULT_FROM_WIN32(x) (HRESULT_FROM_WIN32(x) | 0x40000000) > > Using MAKE_HRESULT() with appropriate severity and facility would be > cleaner IMO. > > -- > Dmitry. > I looked at MAKE_HRESULT and tried things like: MAKE_HRESULT(SEVERITY_ERROR, FACILITY_WIN32, error_code) but this results in codes like 0x8007xxxx because it only uses 1-bit for the severity level (where ntstatus codes use bit30 for severity and bit31 for error). I wasn't able to find a MAKE_NTSTATUS, so perhaps there is something else? Roderick

Nov. 24, 2009

Re: RFC: visual.c:783: Test failed: DSTALPHA on frame buffer returned color 0x00ff0000, expected 0x000000ff

by Roderick Colenbrander

On Tue, Nov 24, 2009 at 5:12 AM, chris ahrendt <celticht32(a)yahoo.com> wrote: > Ok going through and looking at the next failure in wine tests I found this one : > > > If you look at the code its: > > > 779 color = getPixelColor(device, 160, 120); > 780 red = (color & 0x00ff0000) >> 16; > 781 green = (color & 0x0000ff00) >> 8; > 782 blue = (color & 0x000000ff); > 783 ok(red == 0x00 && green == 0x00 && blue >= 0xfe && blue <= 0xff , > 784 "DSTALPHA on frame buffer returned color 0x%08x, expected 0x000000ff\n", color); > > > but in MSDN it says : > > This value is a 32-bit value used to specify an RGB color or CLR_INVALID > > Format of the rgb color is : > > 0x00bbggrr > > The low-order byte contains a value for the relative intensity of red, the second byte contains a value for green, and > the third byte contains a value for blue. > > The high-order byte must be zero. > > The maximum value for a single byte is 0xFF. > > so shouldn't it be something like this: > > red = color & 0x000000FF; > green = ( color & 0x0000FF00 ) >> 8; > blue = ( color & 0x00FF0000 ) >> 16; > > not the what is in the test? because of the following C action > > expression1 >> shift_value > > Returns expression1 with its bits shifted to the right by the shift_value. The leftmost bits are replaced with zeros if > the value is nonnegative or unsigned. This result is the integer part of expression1 divided by 2 raised to the power of > shift_value. If expression1 is signed, then the result is implementation specific. > > so the test seems to be assigning the wrong values to the RGB.... Correct? > > chris > We are creating the framebuffer in the ARGB format (see init_d3d9). D3D supports a variety of formats and we don't use the gdi RGB macro. Roderick

Nov. 24, 2009

Re: mapistub: add stubbed dll mapistub.dll

by Rob Shearman

2009/11/23 Louis Lenders <xerox_xerox2000(a)yahoo.co.uk>: > This fixes http://bugs.winehq.org/show_bug.cgi?id=20050 > > The dll is present on my XP system This DLL is already partially implemented in a DLL called mapi32, so there should be no need to add this completely stubbed out. -- Rob Shearman

Nov. 24, 2009

Re: opengl32: fix wglCreateContextAttribsARB on nvidia

by Dmitry Timoshkov

"Roderick Colenbrander" <thunderbird2k(a)gmail.com> wrote: > +/* Nvidia converts win32 error codes to (0xc007 << 16) | win32_error_code */ > +#define NVIDIA_HRESULT_FROM_WIN32(x) (HRESULT_FROM_WIN32(x) | 0x40000000) Using MAKE_HRESULT() with appropriate severity and facility would be cleaner IMO. -- Dmitry.

Nov. 24, 2009

Re: shell32/tests: Remove atime tests in ITEMIDLIST_format test.

by Austin Lund

2009/11/23 Paul Vriens <paul.vriens.wine(a)gmail.com>: > > I'm curious how important a test on a FAT filesystem is. I'm not overly concerned, but the way it is at the moment, my test system will always fail with this test. > What happens when these tests are run on Wine with a FAT filesystem btw? I don't have such a system to test this on currently.

Nov. 24, 2009

Re: [2/3] msi/tests: Test for SELECT table.column FROM table

by Nikolay Sivov

On Tue, Nov 24, 2009 at 11:14 AM, Nathan Gallaher <ngallaher(a)deepthought.org> wrote: > Make sure that mixing table columns returns the expected > data. eg: SELECT t1.action, t2.action FROM t1, t2 > should return distinct data. > > > + // Test that selection based on prefixing the column with the table + // actually selects the right data Cpp style isn't allowed, please resend it with plain C comments. Thanks.

Nov. 23, 2009

RFC: visual.c:783: Test failed: DSTALPHA on frame buffer returned color 0x00ff0000, expected 0x000000ff

by chris ahrendt

Ok going through and looking at the next failure in wine tests I found this one : If you look at the code its: 779 color = getPixelColor(device, 160, 120); 780 red = (color & 0x00ff0000) >> 16; 781 green = (color & 0x0000ff00) >> 8; 782 blue = (color & 0x000000ff); 783 ok(red == 0x00 && green == 0x00 && blue >= 0xfe && blue <= 0xff , 784 "DSTALPHA on frame buffer returned color 0x%08x, expected 0x000000ff\n", color); but in MSDN it says : This value is a 32-bit value used to specify an RGB color or CLR_INVALID Format of the rgb color is : 0x00bbggrr The low-order byte contains a value for the relative intensity of red, the second byte contains a value for green, and the third byte contains a value for blue. The high-order byte must be zero. The maximum value for a single byte is 0xFF. so shouldn't it be something like this: red = color & 0x000000FF; green = ( color & 0x0000FF00 ) >> 8; blue = ( color & 0x00FF0000 ) >> 16; not the what is in the test? because of the following C action expression1 >> shift_value Returns expression1 with its bits shifted to the right by the shift_value. The leftmost bits are replaced with zeros if the value is nonnegative or unsigned. This result is the integer part of expression1 divided by 2 raised to the power of shift_value. If expression1 is signed, then the result is implementation specific. so the test seems to be assigning the wrong values to the RGB.... Correct? chris

Nov. 23, 2009

Re: RFC : query.c d3d9 test...

by chris ahrendt

Roderick Colenbrander wrote: > On Mon, Nov 23, 2009 at 9:23 PM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: >> Am 23.11.2009 um 21:00 schrieb chris ahrendt: >>> The test fails with : >>> >>> query.c:224: Test failed: IDirect3DQuery9_GetData a 2nd time on a ended query returned 00000001 >> This is Windows, right? Which GPU/driver? >> >> My guess is that its ok to modify the test to accept both results. Ie, ok(hr == S_OK | hr == S_FALSE, "..."); >> > > I see it all the time on my Radeon 3400 on Wine. > > Roderick > > this is the wine test I run on linux.... and I get this all the time on my Radeon as well... which is why I was asking here... do I need to open a bug on the test to fix it since what I documented is the correct behavior.... chris

Nov. 23, 2009

Re: [PATCH] ole32: Some missing error checking in FileMonikerImpl_CommonPrefixWith (Coverity)

by Rob Shearman

2009/11/23 Marcus Meissner <marcus(a)jet.franken.de>: > if(mkSys==MKSYS_FILEMONIKER){ > HRESULT ret; > > - CreateBindCtx(0,&pbind); > + ret = CreateBindCtx(0,&pbind); > + if (FAILED(ret)) > + return ret; > > /* create a string based on common part of the two paths */ > > - IMoniker_GetDisplayName(iface,pbind,NULL,&pathThis); > - IMoniker_GetDisplayName(pmkOther,pbind,NULL,&pathOther); > + ret = IMoniker_GetDisplayName(iface,pbind,NULL,&pathThis); > + if (FAILED(ret)) > + return ret; pbind is leaked here. > + ret = IMoniker_GetDisplayName(pmkOther,pbind,NULL,&pathOther); > + if (FAILED(ret)) > + return ret; pbind and pathThis are leaked here. > > nb1=FileMonikerImpl_DecomposePath(pathThis,&stringTable1); > + if (FAILED(nb1)) > + return nb1; Ditto plus pathOther. > nb2=FileMonikerImpl_DecomposePath(pathOther,&stringTable2); > + if (FAILED(nb2)) > + return nb2; Ditto plus stringTable1. > > if (nb1==0 || nb2==0) > return MK_E_NOPREFIX; > > commonPath=HeapAlloc(GetProcessHeap(),0,sizeof(WCHAR)*(min(lstrlenW(pathThis),lstrlenW(pathOther))+1)); > + if (!commonPath) > + return E_OUTOFMEMORY; Ditto plus stringTable2. > > *commonPath=0; -- Rob Shearman

Nov. 23, 2009

Re: [PATCH] kernel32: Respect the LANG environment variable on Mac OS.

by Charles Davis

Ken Thomases wrote: > The call to setenv() has 0 (false) as its third parameter, so that LANG is not overwritten. Then why does Wine not repsect the LANG setting on Mac OS X? I've seen it on wine-users. Wherever the problem lies, it lies elsewhere. (Yeah, I forgot what that third parameter to setenv() does.) > > -Ken > Chip

Nov. 23, 2009

Re: [PATCH] kernel32: Respect the LANG environment variable on Mac OS.

by Ken Thomases

The call to setenv() has 0 (false) as its third parameter, so that LANG is not overwritten. -Ken On Nov 23, 2009, at 9:12 AM, Charles Davis wrote: > --- > dlls/kernel32/locale.c | 53 > +++++++++++++++++++++++++---------------------- > 1 files changed, 28 insertions(+), 25 deletions(-) > > > > diff --git a/dlls/kernel32/locale.c b/dlls/kernel32/locale.c > index fb9b517..d9ea8eb 100644 > --- a/dlls/kernel32/locale.c > +++ b/dlls/kernel32/locale.c > @@ -2925,32 +2925,35 @@ void LOCALE_Init(void) > UINT ansi_cp = 1252, oem_cp = 437, mac_cp = 10000, unix_cp; > > #ifdef __APPLE__ > - /* MacOS doesn't set the locale environment variables so we have to do it ourselves */ > - CFArrayRef preferred_locales, all_locales; > CFStringRef user_language_string_ref = NULL; > - char user_locale[50]; > - char* p; > - > - CFLocaleRef user_locale_ref = CFLocaleCopyCurrent(); > - CFStringRef user_locale_string_ref = CFLocaleGetIdentifier( user_locale_ref ); > - > - CFStringGetCString( user_locale_string_ref, user_locale, sizeof(user_locale), kCFStringEncodingUTF8 ); > - CFRelease( user_locale_ref ); > - /* Strip modifiers because setlocale() can't parse them. */ > - if ((p = strchr( user_locale, '@' ))) *p = 0; > - if (!strchr( user_locale, '.' )) strcat( user_locale, ".UTF-8" ); > - unix_cp = CP_UTF8; /* default to utf-8 even if we don't get a valid locale */ > - setenv( "LANG", user_locale, 0 ); > - TRACE( "setting locale to '%s'\n", user_locale ); > - > - /* We still want to set the retrieve the preferred language as chosen in > - System Preferences.app, because it can differ from CFLocaleCopyCurrent(). > - */ > - all_locales = CFLocaleCopyAvailableLocaleIdentifiers(); > - preferred_locales = CFBundleCopyLocalizationsForPreferences( all_locales, NULL ); > - if (preferred_locales && CFArrayGetCount( preferred_locales )) > - user_language_string_ref = CFArrayGetValueAtIndex( preferred_locales, 0 ); > - CFRelease( all_locales ); > + if (!getenv( "LANG" )) > + { > + /* MacOS doesn't set the locale environment variables so we have to do it ourselves */ > + CFArrayRef preferred_locales, all_locales; > + char user_locale[50]; > + char* p; > + > + CFLocaleRef user_locale_ref = CFLocaleCopyCurrent(); > + CFStringRef user_locale_string_ref = CFLocaleGetIdentifier( user_locale_ref ); > + > + CFStringGetCString( user_locale_string_ref, user_locale, sizeof(user_locale), kCFStringEncodingUTF8 ); > + CFRelease( user_locale_ref ); > + /* Strip modifiers because setlocale() can't parse them. */ > + if ((p = strchr( user_locale, '@' ))) *p = 0; > + if (!strchr( user_locale, '.' )) strcat( user_locale, ".UTF-8" ); > + unix_cp = CP_UTF8; /* default to utf-8 even if we don't get a valid locale */ > + setenv( "LANG", user_locale, 0 ); > + TRACE( "setting locale to '%s'\n", user_locale ); > + > + /* We still want to set the retrieve the preferred language as chosen in > + System Preferences.app, because it can differ from CFLocaleCopyCurrent(). > + */ > + all_locales = CFLocaleCopyAvailableLocaleIdentifiers(); > + preferred_locales = CFBundleCopyLocalizationsForPreferences( all_locales, NULL ); > + if (preferred_locales && CFArrayGetCount( preferred_locales )) > + user_language_string_ref = CFArrayGetValueAtIndex( preferred_locales, 0 ); > + CFRelease( all_locales ); > + } > #endif /* __APPLE__ */ > > setlocale( LC_ALL, "" ); > > >

Nov. 23, 2009

Re: msvcrt: Calculate floating point decimals in internally used long double precision.

by Austin English

On Mon, Nov 23, 2009 at 2:43 PM, Gregor Schneider <grschneider(a)gmail.com> wrote: > This patch proposes to calculate the fp digits in scanf with the internally > used long double precision instead of simple float accuracy. > With the current implementation small errors are added with each calculation > step originating from the used float type. > This becomes obvious when parsing to more precise fp types like double or > long double and outputting a large number of digits from the created number. > Example code like the following > > double d; > swscanf(L"3.1415", L"%lf", &d); > wprintf(L"%3.12f\n", d); > > produces an output of "3.141500000478", while "3.141500000000" would be the > expected result with this precision. The attached patch fixes this problem. Please add a testcase for this behavior, to prevent regressions. -- -Austin

Nov. 23, 2009

Re: RFC : query.c d3d9 test...

by Stefan Dösinger

Am 23.11.2009 um 21:31 schrieb Roderick Colenbrander: > On Mon, Nov 23, 2009 at 9:23 PM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: >> >> Am 23.11.2009 um 21:00 schrieb chris ahrendt: >>> The test fails with : >>> >>> query.c:224: Test failed: IDirect3DQuery9_GetData a 2nd time on a ended query returned 00000001 >> This is Windows, right? Which GPU/driver? >> >> My guess is that its ok to modify the test to accept both results. Ie, ok(hr == S_OK | hr == S_FALSE, "..."); >> > > I see it all the time on my Radeon 3400 on Wine. I guess its fine to accept this result then. I think the original motivation behind these tests was that HL2 called GetData() more than once and this raised GL errors - the query code now filters such calls out to prevent calling bad GL calls.

Nov. 23, 2009

Re: RFC : query.c d3d9 test...

by Roderick Colenbrander

On Mon, Nov 23, 2009 at 9:23 PM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > > Am 23.11.2009 um 21:00 schrieb chris ahrendt: >> The test fails with : >> >> query.c:224: Test failed: IDirect3DQuery9_GetData a 2nd time on a ended query returned 00000001 > This is Windows, right? Which GPU/driver? > > My guess is that its ok to modify the test to accept both results. Ie, ok(hr == S_OK | hr == S_FALSE, "..."); > I see it all the time on my Radeon 3400 on Wine. Roderick

Nov. 23, 2009

Re: RFC : query.c d3d9 test...

by Stefan Dösinger

Am 23.11.2009 um 21:00 schrieb chris ahrendt: > The test fails with : > > query.c:224: Test failed: IDirect3DQuery9_GetData a 2nd time on a ended query returned 00000001 This is Windows, right? Which GPU/driver? My guess is that its ok to modify the test to accept both results. Ie, ok(hr == S_OK | hr == S_FALSE, "...");

Nov. 23, 2009

RFC : query.c d3d9 test...

by chris ahrendt

Looking at the wine test results for the following test: query.c in the d3d9 tests directory... hr = IDirect3DQuery9_GetData(pQuery, data, IDirect3DQuery9_GetDataSize(pQuery), D3DGETDATA_FLUSH); ok(hr == S_OK, "IDirect3DQuery9_GetData on a ended query returned %08x\n", hr); hr = IDirect3DQuery9_GetData(pQuery, data, IDirect3DQuery9_GetDataSize(pQuery), D3DGETDATA_FLUSH); ok(hr == S_OK, "IDirect3DQuery9_GetData a 2nd time on a ended query returned %08x\n", hr); the MSDK says the following : IDirect3DQuery9::GetData Polls a queried resource to get the query state or a query result. For more information about queries, see Queries (Direct3D 9). Return Values The return type identifies the query state (see Queries (Direct3D 9)). The method returns S_OK if the query data is available and S_FALSE if it is not. These are considered successful return values. If the method fails when D3DGETDATA_FLUSH is used, the return value can be D3DERR_DEVICELOST. The test fails with : query.c:224: Test failed: IDirect3DQuery9_GetData a 2nd time on a ended query returned 00000001 which is a S_FALSE (1) which just means the data is not available... which according to the MSDN site is an ok value to return... and is a success... so not sure what is being tested here? Is this a valid test? Also reading the MSDN the D3DGETDATA_FLUSH is supposed to flush the query so the value its returning may be ok... So If I am understanding the above code the first one should return a S_OK saying that it flushed the query code.... Then the second call should return a S_FALSE because the query has nothing in it..... Thoughts? Explinations??? Inpuut... <G> Chris

Nov. 23, 2009

Re: Add .cvsignore entries for .fake files

by Stephen Eilert

On Mon, Nov 23, 2009 at 7:07 AM, Paul Chitescu <paulc(a)voip.null.ro> wrote: > On Friday 20 November 2009 05:43:48 pm Charles Davis wrote: > > Paul Chitescu wrote: > > > On Monday 16 November 2009 04:11:25 pm Paul Chitescu wrote: > > >> Changelog: > > >> Add .cvsignore entries for .fake files. > > > > > > What's wrong with this? Applies cleanly to my pristine wine-CVS, tried > with > > > patch taken from wine-patches bounce. > > > > > > Whoever rejected with "fails to apply" please reply with the output. > > > > > > > > > > > We don't use CVS anymore. Now we use git. You need to first upgrade to > > git, then modify the .gitignore file. > > > > Chip > > Obviously I use CVS and the ? ......fake status reports are a nuissance. > The > fact you don't care about CVS doesn't mean everybody has to switch, > especially > since git isn't supported as widely as CVS. > What do you mean by "git isn't supported as widely as CVS"? In any case, CVS is *ancient*. You really should learn how to use git, specially if you want to contribute to wine. It'll make your life easier, after the initial learning curve. For instance, I'd hate to do regression testing using CVS, instead of a git bisect. --Stephen programmer, n: A red eyed, mumbling mammal capable of conversing with inanimate monsters.

Nov. 23, 2009

winmm: Don't stop parsing after MCI's alias keyword.

by Joerg-Cyril.Hoehle＠t-systems.com

Dan Kegel wrote: >Looks like I ignore files that only contain leak errors: >You can still see the leaks in the full log, >http://kegel.com/wine/valgrind/logs/2009-11-19-08.35.log Ah, I was surprised to find no mention of winmm in the normal log ;) >should I stop ignoring modules that only have leak errors? I was lulled into false confidence by not seing errors. Perhaps I'd have caught a message at the top of the web logs page. >Also, mci tests hang on my system and need to be killed, >so I may be missing some errors because of that. Hmm, you already mentioned this one earlier: >err:wave:wodPlayer_WriteMaxFrags Error in writing wavehdr. > Reason: Resource temporarily unavailable Is there anything you can change to your sound configuration to avoid it? I don't see why the winmm wave and capture tests pass while only mci generates hundreds of this warning. Can you run WINETEST_INTERACTIVE=1 wave.ok or capture.ok? I've only seen this error sequence once or twice in my tests. >preloader: Warning: failed to reserve range 00110000-68000000 ?? Regards, Jörg Höhle.

Nov. 23, 2009

Re: winspool: Don't use 16Bit gdi.exe function for DeviceCapabilitiesA/W

by Alexandre Julliard

Detlef Riekenberg <wine.dev(a)web.de> writes: > - if (!GDI_CallDeviceCapabilities16) > - { > - GDI_CallDeviceCapabilities16 = (void*)GetProcAddress( GetModuleHandleA("gdi32"), > - (LPCSTR)104 ); > - if (!GDI_CallDeviceCapabilities16) return -1; > - } > - ret = GDI_CallDeviceCapabilities16(pDevice, pPort, cap, pOutput, lpdm); > - > - /* If DC_PAPERSIZE map POINT16s to POINTs */ > - if(ret != -1 && cap == DC_PAPERSIZE && pOutput) { > - POINT16 *tmp = HeapAlloc( GetProcessHeap(), 0, ret * sizeof(POINT16) ); > - POINT *pt = (POINT *)pOutput; You can't remove the 16-bit conversion if you are still calling the existing driver. Probably a better approach is to first add a DrvDeviceCapabilities to the wineps driver. -- Alexandre Julliard julliard(a)winehq.org

Nov. 23, 2009

re: winmm: Don't stop parsing after MCI's alias keyword.

by Dan Kegel

Joerg wrote: > I'm surprised that valgrind did not complain about the bug... Looks like I ignore files that only contain leak errors: http://code.google.com/p/winezeug/source/browse/trunk/valgrind/valgrind-spl… on the theory that we're already overwhelmed dealing with non-leak errors. You can still see the leaks in the full log, http://kegel.com/wine/valgrind/logs/2009-11-19-08.35.log What do people think - should we focus on non-leak errors for a while (in which case I should suppress all leak errors), or should I stop ignoring modules that only have leak errors? Also, mci tests hang on my system and need to be killed, so I may be missing some errors because of that. (Finally, my automated runs are on hold while I add use-after-free detection. I'm lame, and use the same source tree for develoment and for the automated runs. One of these days I should separate them. Or somebody else could do the automated runs...) - Dan

Nov. 23, 2009

Re: Add .cvsignore entries for .fake files

by Alexandre Julliard

Paul Chitescu <paulc(a)voip.null.ro> writes: > Can someone clarify if there's a relation between .gitignore and .cvsignore > files? Are they synchronized somehow? > > If .cvsignore is generated from .gitignore then there's something wrong. > > If .cvsignore files are stored separately in CVS then the patch can be applied > only there by AJ (I've seen the repository being locked by user "juillard" > while applying the patches). They are generated, IIRC they get updated when the makefile changes or something like that. The scripts are in tools.git if you want to improve them. -- Alexandre Julliard julliard(a)winehq.org

Nov. 23, 2009

Re: server: Only require REG_OPTION_VOLATILE when creating a new key.

by Paul Vriens

Hi Alexandre, With this patch the following errors are introduced when starting anything on a clean .wine : err:setupapi:registry_callback could not create key 0x80000002 L"HARDWARE\\DEVICEMAP\\PARALLEL PORTS" err:setupapi:registry_callback could not create key 0x80000002 L"HARDWARE\\DEVICEMAP\\SERIALCOMM" -- Cheers, Paul.

Nov. 23, 2009

Re: Add .cvsignore entries for .fake files

by Paul Chitescu

On Friday 20 November 2009 05:43:48 pm Charles Davis wrote: > Paul Chitescu wrote: > > On Monday 16 November 2009 04:11:25 pm Paul Chitescu wrote: > >> Changelog: > >> Add .cvsignore entries for .fake files. > > > > What's wrong with this? Applies cleanly to my pristine wine-CVS, tried with > > patch taken from wine-patches bounce. > > > > Whoever rejected with "fails to apply" please reply with the output. > > > > > > > We don't use CVS anymore. Now we use git. You need to first upgrade to > git, then modify the .gitignore file. > > Chip Obviously I use CVS and the ? ......fake status reports are a nuissance. The fact you don't care about CVS doesn't mean everybody has to switch, especially since git isn't supported as widely as CVS. Can someone clarify if there's a relation between .gitignore and .cvsignore files? Are they synchronized somehow? If .cvsignore is generated from .gitignore then there's something wrong. If .cvsignore files are stored separately in CVS then the patch can be applied only there by AJ (I've seen the repository being locked by user "juillard" while applying the patches). Regards, Paul

Nov. 23, 2009

Re: FAT32 support (was: [RFC] Handle process token groups in server/file.c::sd_to_mode)

by Ben Peddell

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Chitescu wrote: > How should server/file.c sd_to_mode() deal with filesystems that don't support > full POSIX ownership and access permissions? It is quite popular to mount FAT > filesystems - either from a removable media or a partition shared with a > Windows installation. A workaround for the moment on linux would be to use the uid=<your_uid> option when mounting the a FAT filesystem, as the linux vfat filesystem driver basically ignores chmod (except for the u+w bit) when the user executing chmod is the owner of the filesystem. I don't know if Mac OS X, *BSD or Solaris do the same. (tracing using procmon and setacl) NtQuerySecurityObject and NtSetSecurityObject return STATUS_INVALID_DEVICE_REQUEST on Windows XP when attempting to get or set a security descriptor on a FAT filesystem. (musing) I wonder if it'd be possible to have a special SD pointer (such as -1 or a special SD_INVALID_DEVICE_REQUEST descriptor) in a wineserver object to say that neither the object nor any of its children can hold security descriptors? After all, you cannot put volume mount points on a FAT filesystem, so nothing under a FAT filesystem would be able to hold a security descriptor. obj->get_sd() and obj->set_sd() would then be made to return STATUS_INVALID_DEVICE_REQUEST on such an object. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksJ6dQACgkQTHDAI68NsukvQQCePLlkXB7aT0HrrTUjarkdNAiv OcYAn3hYtfTwBveT/6ltNIiO8b2oD7ZH =bAgm -----END PGP SIGNATURE-----

Nov. 22, 2009

Re: Firefox not installing with winetricks. Reason: need to upgrade 3.5.3 to 3.5.5.

by Albert Lee

On Sat, 21 Nov 2009 20:49:13 -0800, Ido Tal <idotal(a)gmail.com> wrote: > Hi, > > I've just now tried to install firefox with winetricks and failed. A short > scan reveals what the problem is (I think): the version winetricks is > trying > to install is 3.5.3. Looking at > http://releases.mozilla.org/pub/mozilla.org/firefox/releases/ shows that > it's not there anymore. > > Hope this helps... > > Ido Hi, you may want to report the bug at http://code.google.com/p/winezeug/ since winetricks is hosted separately from winehq.org. -Albert

Nov. 22, 2009

Re: [PATCH 1/3] gdi32/tests: Test BitBlt() to an enhanced metafile.

by Austin English

On Sun, Nov 22, 2009 at 12:00 PM, Charles Davis <cdavis(a)mymail.mines.edu> wrote: > Austin English wrote: >> On Sat, Nov 21, 2009 at 11:15 PM, Charles Davis <cdavis(a)mymail.mines.edu> wrote: >>> Dmitry Timoshkov wrote: >>>> "Charles Davis" <cdavis(a)mymail.mines.edu> wrote: >>>> >>>>>> You forgot to remove if (1). >>>>>> >>>>> It goes away in patch #3. I thought I already had this discussion with >>>>> Paul. >>>>> >>>>> There's a reason it's there. EMF_BITBLT contains two BitBlt() records, >>>>> but the EMF we're comparing it to only has one. That's because one of >>>>> them is if(0)'d out because it crashes on Wine. So, if we try to compare >>>>> the EMF we produced to the EMF we expect, it will fail. Last I checked, >>>>> Alexandre doesn't like it when tests fail. All tests must pass on his >>>>> box. >>>> There are 2 solutions for that: >>>> 1. use todo_wine in the test, and remove it in a patch with the fix >>> The test will fail on Windows if I do that. >> >> That won't affect windows. It will only fail on wine if it passes. >> > You don't understand. The expected EMF bits contain TWO BitBlt() > records, but the EMF produced by the test contains only one. It will > contain only one on both Wine and Windows, because one of the calls to > BitBlt() is if(0)'d out. So the test will fail on Windows if the call to > compare_emf_bits() is marked todo_wine. Ah, my mistake. > Oh, and you didn't reply to all. Was that intentional? Yes, didn't think everyone needed to know what todo_wine did ;-). -- -Austin

Nov. 22, 2009

Re: Firefox not installing with winetricks. Reason: need to upgrade 3.5.3 to 3.5.5.

by Austin English

On Sat, Nov 21, 2009 at 10:49 PM, Ido Tal <idotal(a)gmail.com> wrote: > Hi, > > I've just now tried to install firefox with winetricks and failed. A short > scan reveals what the problem is (I think): the version winetricks is trying > to install is 3.5.3. Looking at > http://releases.mozilla.org/pub/mozilla.org/firefox/releases/ shows that > it's not there anymore. Hm, the link must of just broken today, because I ran winetrickstest yesterday and it was fine.. Fixed in SVN winetricks. -- -Austin

Nov. 22, 2009

Re: [PATCH 1/3] gdi32/tests: Test BitBlt() to an enhanced metafile.

by Charles Davis

Austin English wrote: > On Sat, Nov 21, 2009 at 11:15 PM, Charles Davis <cdavis(a)mymail.mines.edu> wrote: >> Dmitry Timoshkov wrote: >>> "Charles Davis" <cdavis(a)mymail.mines.edu> wrote: >>> >>>>> You forgot to remove if (1). >>>>> >>>> It goes away in patch #3. I thought I already had this discussion with >>>> Paul. >>>> >>>> There's a reason it's there. EMF_BITBLT contains two BitBlt() records, >>>> but the EMF we're comparing it to only has one. That's because one of >>>> them is if(0)'d out because it crashes on Wine. So, if we try to compare >>>> the EMF we produced to the EMF we expect, it will fail. Last I checked, >>>> Alexandre doesn't like it when tests fail. All tests must pass on his >>>> box. >>> There are 2 solutions for that: >>> 1. use todo_wine in the test, and remove it in a patch with the fix >> The test will fail on Windows if I do that. > > That won't affect windows. It will only fail on wine if it passes. > You don't understand. The expected EMF bits contain TWO BitBlt() records, but the EMF produced by the test contains only one. It will contain only one on both Wine and Windows, because one of the calls to BitBlt() is if(0)'d out. So the test will fail on Windows if the call to compare_emf_bits() is marked todo_wine. Oh, and you didn't reply to all. Was that intentional?

Nov. 22, 2009

Re: shell32/tests: Remove atime tests in ITEMIDLIST_format test.

by Paul Vriens

On 11/21/2009 12:18 AM, Austin Lund wrote: > 2009/11/21 Austin Lund<austin.lund(a)gmail.com>: >> 2009/11/21 Paul Vriens<paul.vriens.wine(a)gmail.com>: >> >>> if (abs(date2 - date1) == 1) >>> skip("We dont't check access times on a FAT filesystem\n"); >> >> >>> "The date is always within 1 day (plus or minus)." >> >> It isn't quite that easy as the date field is a bitpacked struct >> holding the year, month and day. So you have to account for month and >> year boundaries. In the absence of any other ideas or tips to where I >> can find a function to do this for me, I implement the calendaring >> increments and send a patch which follows the above idea. >> > > Here is an attempt at doing this. Is there a better/cleaner way to do this? A lot of code to get around this issue. I tried playing with DosDateTimeToFileTime() and CompareFileTime() but that doesn't help much either. I'm curious how important a test on a FAT filesystem is. If it's important we should test it otherwise I'd say your previous suggestion make sense: if (date1 == date2&& time1 == time2) ok(TRUE, "Blah"); else skip("Not testing access times on this filesystem\n"); What happens when these tests are run on Wine with a FAT filesystem btw? -- Cheers, Paul.

Nov. 22, 2009

Re: Someone please update the german translation of Ubuntu download page

by Marcus Meissner

On Sat, Nov 21, 2009 at 09:16:52PM -0600, Scott Ritchie wrote: > My German is inadequate and there are no instructions for Karmic users > there at the moment. I sent one just now. Also updated de/download.template Ciao, Marcus

Nov. 22, 2009

Re: [PATCH 1/3] gdi32/tests: Test BitBlt() to an enhanced metafile.

by Charles Davis

Dmitry Timoshkov wrote: > "Charles Davis" <cdavis(a)mymail.mines.edu> wrote: > >>> You forgot to remove if (1). >>> >> It goes away in patch #3. I thought I already had this discussion with >> Paul. >> >> There's a reason it's there. EMF_BITBLT contains two BitBlt() records, >> but the EMF we're comparing it to only has one. That's because one of >> them is if(0)'d out because it crashes on Wine. So, if we try to compare >> the EMF we produced to the EMF we expect, it will fail. Last I checked, >> Alexandre doesn't like it when tests fail. All tests must pass on his >> box. > > There are 2 solutions for that: > 1. use todo_wine in the test, and remove it in a patch with the fix The test will fail on Windows if I do that. > 2. add the test in the patch after a patch with the fix Very well then. I'll resend with the test reordered after the fix. > Chip

Nov. 21, 2009

Firefox not installing with winetricks. Reason: need to upgrade 3.5.3 to 3.5.5.

by Ido Tal

Hi, I've just now tried to install firefox with winetricks and failed. A short scan reveals what the problem is (I think): the version winetricks is trying to install is 3.5.3. Looking at http://releases.mozilla.org/pub/mozilla.org/firefox/releases/ shows that it's not there anymore. Hope this helps... Ido

Nov. 21, 2009

Next step: detect double-frees and use-after-free

by Dan Kegel

Now that the heap tail check is more or less working, I'm on to implementing protection against double frees and use-after-free for recently freed blocks. The idea is that HEAP_MakeInUseBlockFree() will take the block it's called with, push it onto a FIFO, pull an old block off the FIFO, and mark that old block free. The blocks languishing in the FIFO will be marked inaccessible. If you try to free one, realloc one, or even get its size, you'll get an immediate error; if you write to one, you'll get an error when it comes out of the FIFO or when the heap is validated; and if you're running Valgrind, you'll get an immediate error on read or write to the freed block. The FIFO will be drained when the heap is destroyed. It will be implemented using a standard wine list in an optional fixed-sized block at the tail of each allocation. Remind me again why we didn't do this years ago...

Nov. 21, 2009

Re: [PATCH 1/3] gdi32/tests: Test BitBlt() to an enhanced metafile.

by Dmitry Timoshkov

"Charles Davis" <cdavis(a)mymail.mines.edu> wrote: >> You forgot to remove if (1). >> > It goes away in patch #3. I thought I already had this discussion with > Paul. > > There's a reason it's there. EMF_BITBLT contains two BitBlt() records, > but the EMF we're comparing it to only has one. That's because one of > them is if(0)'d out because it crashes on Wine. So, if we try to compare > the EMF we produced to the EMF we expect, it will fail. Last I checked, > Alexandre doesn't like it when tests fail. All tests must pass on his box. There are 2 solutions for that: 1. use todo_wine in the test, and remove it in a patch with the fix 2. add the test in the patch after a patch with the fix -- Dmitry.

Nov. 21, 2009

Someone please update the german translation of Ubuntu download page

by Scott Ritchie

My German is inadequate and there are no instructions for Karmic users there at the moment. Thanks, Scott Ritchie

Nov. 21, 2009

Re: [PATCH 1/3] gdi32/tests: Test BitBlt() to an enhanced metafile.

by Charles Davis

Dmitry Timoshkov wrote: > "Charles Davis" <cdavis(a)mymail.mines.edu> wrote: > >> + if(1 || compare_emf_bits(hMetafile, EMF_BITBLT, sizeof(EMF_BITBLT), >> + "emf_BitBlt", FALSE) != 0) >> + { >> + dump_emf_bits(hMetafile, "emf_BitBlt"); >> + dump_emf_records(hMetafile, "emf_BitBlt"); >> + } > > You forgot to remove if (1). > It goes away in patch #3. I thought I already had this discussion with Paul. There's a reason it's there. EMF_BITBLT contains two BitBlt() records, but the EMF we're comparing it to only has one. That's because one of them is if(0)'d out because it crashes on Wine. So, if we try to compare the EMF we produced to the EMF we expect, it will fail. Last I checked, Alexandre doesn't like it when tests fail. All tests must pass on his box. Chip

Nov. 21, 2009

Re: [PATCH 1/3] gdi32/tests: Test BitBlt() to an enhanced metafile.

by Dmitry Timoshkov

"Charles Davis" <cdavis(a)mymail.mines.edu> wrote: > + if(1 || compare_emf_bits(hMetafile, EMF_BITBLT, sizeof(EMF_BITBLT), > + "emf_BitBlt", FALSE) != 0) > + { > + dump_emf_bits(hMetafile, "emf_BitBlt"); > + dump_emf_records(hMetafile, "emf_BitBlt"); > + } You forgot to remove if (1). -- Dmitry.

Nov. 21, 2009

Re: Difficulties with Regression Testing

by James McKenzie

Austin English wrote: > On Thu, Nov 19, 2009 at 9:41 AM, James Mckenzie > <jjmckenzie51(a)earthlink.net> wrote: > >>> From: Austin English <austinenglish(a)gmail.com> >>> Sent: Nov 19, 2009 10:31 AM >>> To: James Mckenzie <jjmckenzie51(a)earthlink.net> >>> Cc: Wine Development Mailing List <wine-devel(a)winehq.org> >>> Subject: Re: Difficulties with Regression Testing >>> >>> > >>>> 2. Something else is causing the check.bmp file not to be found and thus the tests fail on the fourth git bisect >>>> good. The .rc file that calls this file is located in two different directorys but the check.bmp file only exists in >>>> the tools/subdirectory. >>>> >>> IIRC, that was a file for the cryptui manager that AJ forgot to >>> include with the commit needing it. Try either putting it there >>> manually from another git branch, or using make -k. >>> >>> >> Where does this need to be added? I might be able to figure it out, but I don't want to go guessing. >> > > Put it in dlls/cryptui/, or just use make -k to ignore it. > > Thanks. The bug was not in that bisect. However, it did appear later in the sequence. Only two revisions left to test now. James McKenzie

Nov. 20, 2009

Re: UMR in CertIsRDNAttrsInCertificateName()

by Juan Lang

> http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/vg-crypt32_cert.txt > shows a new UMR (purify-speak for uninitialized memory read) error Patch sent: http://www.winehq.org/pipermail/wine-patches/2009-November/081698.html --Juan

Nov. 20, 2009

Re: shell32/tests: Remove atime tests in ITEMIDLIST_format test.

by Austin Lund

2009/11/21 Austin Lund <austin.lund(a)gmail.com>: > 2009/11/21 Paul Vriens <paul.vriens.wine(a)gmail.com>: > >> if (abs(date2 - date1) == 1) >> skip("We dont't check access times on a FAT filesystem\n"); > > >> "The date is always within 1 day (plus or minus)." > > It isn't quite that easy as the date field is a bitpacked struct > holding the year, month and day. So you have to account for month and > year boundaries. In the absence of any other ideas or tips to where I > can find a function to do this for me, I implement the calendaring > increments and send a patch which follows the above idea. > Here is an attempt at doing this. Is there a better/cleaner way to do this?

Nov. 20, 2009

Re: [PATCH 2/2] mshtml: Also search by node name attribute in IHTMLDocument3::getElementById

by Andrew Eikum

Jacek Caban wrote: > Hi Andrew, > > Andrew Eikum wrote: >> --- >> dlls/mshtml/htmldoc3.c | 58 >> +++++++++++++++++++++++++++++++++++++++++++--- >> dlls/mshtml/nsiface.idl | 33 ++++++++++++++++++++++++++ >> dlls/mshtml/tests/dom.c | 29 ++++++++++++++++++++++- >> 3 files changed, 115 insertions(+), 5 deletions(-) > > [ > object, > + uuid(29fb2a18-1dd2-11b2-8dd9-a6fd5d5ad12f), > + local > + /* FROZEN */ > +] > > This interface is not frozen, please change the comment to NOT_FROZEN so > that I we will know that we have to check it for changes on the next > Gecko update. > I meant to check this before I sent it off :) Thanks for the fixes. Andrew

Nov. 20, 2009

Re: [PATCH 2/2] mshtml: Also search by node name attribute in IHTMLDocument3::getElementById

by Jacek Caban

Hi Andrew, Andrew Eikum wrote: > --- > dlls/mshtml/htmldoc3.c | 58 > +++++++++++++++++++++++++++++++++++++++++++--- > dlls/mshtml/nsiface.idl | 33 ++++++++++++++++++++++++++ > dlls/mshtml/tests/dom.c | 29 ++++++++++++++++++++++- > 3 files changed, 115 insertions(+), 5 deletions(-) [ object, + uuid(29fb2a18-1dd2-11b2-8dd9-a6fd5d5ad12f), + local + /* FROZEN */ +] This interface is not frozen, please change the comment to NOT_FROZEN so that I we will know that we have to check it for changes on the next Gecko update. + hres = IHTMLElement_get_tagName(elem2, &str); + ok(hres == S_OK, "IHTMLElement_get_tagName failed: 0x%08x\n", hres); + ok(!strcmp_wa(str, "A"), "Got wrong tag: %s\n", wine_dbgstr_w(str)); + SysFreeString(str); There is generic test_elem_tag that is meant for this. + /* getElementById with node name attributes */ + hres = IHTMLDocument2_QueryInterface(doc, &IID_IHTMLDocument3, (void**)&doc3); + ok(hres == S_OK, "Unable to get IHTMLDocument3: 0x%08x\n", hres); + if(FAILED(hres)) + return; + bstr = a2bstr("nm1"); + hres = IHTMLDocument3_getElementById(doc3, bstr, &elem); + SysFreeString(bstr); + IHTMLDocument3_Release(doc3); + ok(hres == S_OK, "getElementById failed: 0x%08x\n", hres); + if(FAILED(hres)) + return; Same here for get_doc_elem_by_id. + + hres = IHTMLElement_get_id(elem, &bstr); + ok(hres == S_OK, "IHTMLElement_get_id failed: 0x%08x\n", hres); + ok(!strcmp_wa(bstr, "fr1"), "Found ID should have been \"fr1\", was: %s", wine_dbgstr_w(bstr)); + SysFreeString(bstr); Same here for test_elem_id. Thanks, Jacek

Nov. 20, 2009

Re: shell32/tests: Remove atime tests in ITEMIDLIST_format test.

by Austin Lund

2009/11/21 Paul Vriens <paul.vriens.wine(a)gmail.com>: > if (abs(date2 - date1) == 1) > skip("We dont't check access times on a FAT filesystem\n"); > "The date is always within 1 day (plus or minus)." It isn't quite that easy as the date field is a bitpacked struct holding the year, month and day. So you have to account for month and year boundaries. In the absence of any other ideas or tips to where I can find a function to do this for me, I implement the calendaring increments and send a patch which follows the above idea.

Nov. 20, 2009

winetest + pbuffer + nvidia 190.18 drivers = X crash

by Austin English

Been happening for a few days...not sure what triggered it, but when coming back from work I see my login screen, which explains the lack of 64-bit tests/appinstall results. I don't know if any of the D3D guys could take a look, but I'd appreciate it... -- -Austin

Nov. 20, 2009

Re: Running server applications under Wine?

by Sir Gallantmon

On Fri, Nov 20, 2009 at 12:11 PM, Dan Kegel <dank(a)kegel.com> wrote: > On Fri, Nov 20, 2009 at 9:57 AM, Sir Gallantmon <ngompa13(a)gmail.com> > wrote: > > On Fri, Nov 20, 2009 at 11:07 AM, Dan Kegel <dank(a)kegel.com> wrote: > >> > What do you think about implementing wineserver kernel module or > >> > handling only performance critical items in kernel? > >> > >> There has long been talk of doing that. Linus is > >> even willing to take patches to implement win32 APIs > >> in the linux kernel. > >> But it turns out to not be what most people need. > > > > What do you mean by that? Wouldn't it be a good idea to be able to > support > > some parts of Wine in the kernel level to be more efficient? > > Of course. It's just hard, and it isn't needed for the things > we tend to use Wine for at the moment. Somebody actually > had a shot at implementing this back in 2000, see > http://lwn.net/2000/0914/a/lt-wine.php3 > And that work lives on, it seems, as a part of > http://en.wikipedia.org/wiki/Linux_Unified_Kernel > So go try it out if you like (although I'm not sure > how safe it is for production). > > I think the Wine team doesn't need to worry about > that stuff; we have our hands full just making the > win32 userland work well. > - Dan > I would think that maybe the work Wine does for Direct3D could be moved into a state tracker for Gallium, that way it shouldn't be necessary to convert from Direct3D to OpenGL to make it work. I doubt Direct3D and OpenGL include equivalents for everything, so it might be a good idea to have for a SoC project to hook up Wine's D3D implementation into Gallium.

Nov. 20, 2009

Re: Running server applications under Wine?

by Dan Kegel

On Fri, Nov 20, 2009 at 9:57 AM, Sir Gallantmon <ngompa13(a)gmail.com> wrote: > On Fri, Nov 20, 2009 at 11:07 AM, Dan Kegel <dank(a)kegel.com> wrote: >> > What do you think about implementing wineserver kernel module or >> > handling only performance critical items in kernel? >> >> There has long been talk of doing that. Linus is >> even willing to take patches to implement win32 APIs >> in the linux kernel. >> But it turns out to not be what most people need. > > What do you mean by that? Wouldn't it be a good idea to be able to support > some parts of Wine in the kernel level to be more efficient? Of course. It's just hard, and it isn't needed for the things we tend to use Wine for at the moment. Somebody actually had a shot at implementing this back in 2000, see http://lwn.net/2000/0914/a/lt-wine.php3 And that work lives on, it seems, as a part of http://en.wikipedia.org/wiki/Linux_Unified_Kernel So go try it out if you like (although I'm not sure how safe it is for production). I think the Wine team doesn't need to worry about that stuff; we have our hands full just making the win32 userland work well. - Dan

Nov. 20, 2009

Re: Running server applications under Wine?

by Sir Gallantmon

On Fri, Nov 20, 2009 at 11:07 AM, Dan Kegel <dank(a)kegel.com> wrote: > 임은지 wrote: > > > What do you think about implementing wineserver kernel module or handling > only performance critical items in kernel? > > There has long been talk of doing that. Linus is > even willing to take patches to implement win32 APIs > in the linux kernel. > But it turns out to not be what most people need. > > If you want to do some server performance stress testing > and file bugs for problems you find, by all means, go ahead! > - Dan > > > What do you mean by that? Wouldn't it be a good idea to be able to support some parts of Wine in the kernel level to be more efficient?

Nov. 20, 2009

re: Running server applications under Wine?

by Dan Kegel

임은지 wrote: > Is there anyone who uses Wine for server applications (game server, web server, etc.)? It's been done. See e.g. http://www.fpsadmin.com/forum/showthread.php?t=16481 for how one fellow ran a game server in wine. > Performance is very important issue for such applications. A server should serve a large number of clients at reasonable speeds. Yes, it would be interesting to run ab or dkftpbench against an http or ftp server running on wine. > What do you think about implementing wineserver kernel module or handling only performance critical items in kernel? There has long been talk of doing that. Linus is even willing to take patches to implement win32 APIs in the linux kernel. But it turns out to not be what most people need. If you want to do some server performance stress testing and file bugs for problems you find, by all means, go ahead! - Dan

Nov. 20, 2009

Re: New valgrind results, this time with overrun checks and lots of new errors.

by Nikolay Sivov

Dan Kegel wrote: > http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/diff-comctl32_tab.txt > http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/vg-comctl32_tab.txt > show a more inscrutable error: > Invalid write of size 4 > at TAB_SetCurSel (tab.c:255) > by TAB_WindowProc (tab.c:3367) > by ??? (library.h:159) > by call_window_proc (winproc.c:469) > by WINPROC_CallProcAtoW (winproc.c:1023) > by CallWindowProcA (winproc.c:2299) > by tabSubclassProcess (tab.c:404) > by ??? (library.h:159) > by call_window_proc (winproc.c:469) > by WINPROC_call_window (winproc.c:2223) > by call_window_proc (message.c:1635) > by send_message (message.c:2482) > by SendMessageA (message.c:2627) > by test_getters_setters (tab.c:752) > by func_tab (tab.c:1174) > by run_test (test.h:535) > by main (test.h:585) > Address 0x7f044098 is not stack'd, malloc'd or (recently) free'd This shouldn't be a case for today git - see commit 3371ba9f73367572693589905ed57af87b747b54. And thanks a lot for these test results, I'm waiting for automated daily runs a lot...

Nov. 20, 2009

Re: New version of my test for bug 4543

by Paul Vriens

On 11/20/2009 04:25 PM, Charles Davis wrote: > Paul Vriens wrote: >> On 11/19/2009 11:17 PM, Charles Davis wrote: >>> Hi, >>> >>> This is a new version of my test for bug 4543. This time, I followed >>> Dmitry's suggestion of using the existing functions for comparing the >>> contents of EMFs. I can't build tests for Windows both due to bug 20763 >>> and due to the fact that I don't have any Windows boxes, so once again I >>> need people to run this test on Windows to make sure it's an accurate >>> representation of Windows' behavior. The test currently succeeds on Wine. >>> >>> Thanks in advance. >>> >>> Chip >>> >> >> Hi, >> >> I only ran your new tests and removed that "if(0)", please find the >> results attached. >> >> Win95/98/me have the same results (as expected) and have several >> failures (as expected). Fixing them would be a bonus but we currently >> are having several metafile failures for these platforms anyway. >> > Thanks, Paul! > > Based on these results, I modified my test (and Wine to pass), using the > WinXP results as the expected bits. I've submitted the patches to > wine-patches, so now we'll see what Alexandre thinks. > > The Win9x failures mystify me. Why would CreateEnhMetaFileA() fail? I > need to look into this. The last error is set to ERROR_FILE_NOT_FOUND. > > Chip > -- Cheers, Paul.

Nov. 20, 2009

Re: Add .cvsignore entries for .fake files

by Charles Davis

Paul Chitescu wrote: > On Monday 16 November 2009 04:11:25 pm Paul Chitescu wrote: >> Changelog: >> Add .cvsignore entries for .fake files. > > What's wrong with this? Applies cleanly to my pristine wine-CVS, tried with > patch taken from wine-patches bounce. > > Whoever rejected with "fails to apply" please reply with the output. > > > We don't use CVS anymore. Now we use git. You need to first upgrade to git, then modify the .gitignore file. Chip

Nov. 20, 2009

Re: [PATCH 1/3] gdi32/tests: Test BitBlt() to an enhanced metafile.

by Paul Vriens

On 11/20/2009 04:40 PM, Paul Vriens wrote: > On 11/20/2009 04:21 PM, Charles Davis wrote: >> + if(1 || compare_emf_bits(hMetafile, EMF_BITBLT, sizeof(EMF_BITBLT), >> + "emf_BitBlt", FALSE) != 0) > > Shouldn't you get rid of that '1 ||' ? > Just saw you did that in the last one. -- Cheers, Paul.

Nov. 20, 2009

Re: [PATCH 1/3] gdi32/tests: Test BitBlt() to an enhanced metafile.

by Paul Vriens

On 11/20/2009 04:21 PM, Charles Davis wrote: > + if(1 || compare_emf_bits(hMetafile, EMF_BITBLT, sizeof(EMF_BITBLT), > + "emf_BitBlt", FALSE) != 0) Shouldn't you get rid of that '1 ||' ? -- Cheers, Paul.

Nov. 20, 2009

Re: Add .cvsignore entries for .fake files

by Paul Chitescu

On Monday 16 November 2009 04:11:25 pm Paul Chitescu wrote: > Changelog: > Add .cvsignore entries for .fake files. What's wrong with this? Applies cleanly to my pristine wine-CVS, tried with patch taken from wine-patches bounce. Whoever rejected with "fails to apply" please reply with the output.

Nov. 20, 2009

Re: New version of my test for bug 4543

by Charles Davis

Paul Vriens wrote: > On 11/19/2009 11:17 PM, Charles Davis wrote: >> Hi, >> >> This is a new version of my test for bug 4543. This time, I followed >> Dmitry's suggestion of using the existing functions for comparing the >> contents of EMFs. I can't build tests for Windows both due to bug 20763 >> and due to the fact that I don't have any Windows boxes, so once again I >> need people to run this test on Windows to make sure it's an accurate >> representation of Windows' behavior. The test currently succeeds on Wine. >> >> Thanks in advance. >> >> Chip >> > > Hi, > > I only ran your new tests and removed that "if(0)", please find the > results attached. > > Win95/98/me have the same results (as expected) and have several > failures (as expected). Fixing them would be a bonus but we currently > are having several metafile failures for these platforms anyway. > Thanks, Paul! Based on these results, I modified my test (and Wine to pass), using the WinXP results as the expected bits. I've submitted the patches to wine-patches, so now we'll see what Alexandre thinks. The Win9x failures mystify me. Why would CreateEnhMetaFileA() fail? I need to look into this. Chip

Nov. 20, 2009

Re: shell32/tests: Remove atime tests in ITEMIDLIST_format test.

by Paul Vriens

On 11/19/2009 10:45 PM, Austin Lund wrote: > 2009/11/19 Paul Vriens<paul.vriens.wine(a)gmail.com>: >> On 11/19/2009 01:23 PM, Austin Lund wrote: >>> >>> - ok (pFileStructA->uFileDate == pFileStructW->uDate2&& >>> - pFileStructA->uFileTime == pFileStructW->uTime2, >>> - "Last write time should match last access time!\n"); >>> - >> >> Hi Austin, >> >> Is there no other way to get around this? I think it's a bit of a shame >> having tests removed for that odd system that has a FAT filesystem on a NT4+ >> box. >> > > The date is always within 1 day (plus or minus). I guess it would be > possible to implement a calendar addition and subtraction algorithm. > Is there one already available somewhere that could be used with this > bit packed structure in a test? > > The time could be anything, except perhaps the seconds. On my trials > with this, it always seems to have the seconds as zero. I'm not sure > if you can set a timezone that has a delta with non-zero seconds. > > On thinking about this, the way I'd do this is: > > if dates and times are equal then pass > else check the rough rules as outlined > > But is it ok (or even sensible to do): > > if (date1 == date2&& time1 == time2) ok(TRUE, "Blah"); > else { /* some other test */ } > > or would you leave out the ok()? Would this serve it's purpose? if (abs(date2 - date1) == 1) skip("We dont't check access times on a FAT filesystem\n"); else ok(..., "Last write time should match last access time!\n") The if() is according to your statement: "The date is always within 1 day (plus or minus)." -- Cheers, Paul.

Nov. 20, 2009

what should happen when selecting no audio in winecfg?

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, I've observed 2 seemingly opposed behaviours when no audio driver is selected in winecfg's audio tab (or when winecfg's audio tab had never been opened before in this .wine prefix): - On one hand, some tests and apps still manage to produce sound. - On the other hand (OTOH), some apps cease to produce sound -- this is a simple method worth trying when some apps hang with sound issues. So I'm left wondering what a) wine's default .wine creation behaviour or b) unselecting all audio drivers in the tab ought to do. Remember that when you first visit winecfg's audio tab, you get to see a note that a default driver was chosen, which lead me to believe that no driver at all is enabled until then. Thanks, Jörg Höhle.

Nov. 20, 2009

Running server applications under Wine?

by 임은지

Is there anyone who uses Wine for server applications (game server, web server, etc.)? Performance is very important issue for such applications. A server should serve a large number of clients at reasonable speeds. What do you think about implementing wineserver kernel module or handling only performance critical items in kernel?

Nov. 20, 2009

Re: New version of my test for bug 4543

by Paul Vriens

On 11/19/2009 11:17 PM, Charles Davis wrote: > Hi, > > This is a new version of my test for bug 4543. This time, I followed > Dmitry's suggestion of using the existing functions for comparing the > contents of EMFs. I can't build tests for Windows both due to bug 20763 > and due to the fact that I don't have any Windows boxes, so once again I > need people to run this test on Windows to make sure it's an accurate > representation of Windows' behavior. The test currently succeeds on Wine. > > Thanks in advance. > > Chip > Hi, I only ran your new tests and removed that "if(0)", please find the results attached. Win95/98/me have the same results (as expected) and have several failures (as expected). Fixing them would be a bonus but we currently are having several metafile failures for these platforms anyway. -- Cheers, Paul.

Nov. 20, 2009

Re: d3dx9_36: add a stub for D3DXCreateTextureFromFileInMemory

by Austin English

On Fri, Nov 20, 2009 at 1:38 AM, Jeff Zaroyko <jeffzaroyko(a)gmail.com> wrote: > On Fri, Nov 20, 2009 at 6:18 PM, Austin English <austinenglish(a)gmail.com> wrote: >> On Fri, Nov 20, 2009 at 12:05 AM, Jeff Zaroyko <jeffzaroyko(a)gmail.com> wrote: >>> On Fri, Nov 20, 2009 at 4:56 AM, Austin English <austinenglish(a)gmail.com> wrote: >>>> Should fix http://bugs.winehq.org/show_bug.cgi?id=13605 >>>> >>>> -- >>>> -Austin >>>> >>> >>> Does it really fix it, the function still remains unimplemented, crash >>> or no crash... a bug will probably just be filed after it to say the >>> function needs to be implemented if the app really uses it, so what is >>> gained? >> >> Same as with other stubs, it prevents a crash. Many applications check >> to see if a function works, and if not, crash. When given a stub, they >> run. >> >> -- >> -Austin >> > > Given the nature of the function and the game, I'd say it's unlikely > to be of much benefit, has it been tested? No. There is no download available. It was in my 'likely abandoned' bugs list. To be fair, many programs test functions for existence and don't depend on them...there are a ton of stubs in wine for that exact reason. -- -Austin

Nov. 20, 2009

Re: d3dx9_36: add a stub for D3DXCreateTextureFromFileInMemory

by Jeff Zaroyko

On Fri, Nov 20, 2009 at 6:18 PM, Austin English <austinenglish(a)gmail.com> wrote: > On Fri, Nov 20, 2009 at 12:05 AM, Jeff Zaroyko <jeffzaroyko(a)gmail.com> wrote: >> On Fri, Nov 20, 2009 at 4:56 AM, Austin English <austinenglish(a)gmail.com> wrote: >>> Should fix http://bugs.winehq.org/show_bug.cgi?id=13605 >>> >>> -- >>> -Austin >>> >> >> Does it really fix it, the function still remains unimplemented, crash >> or no crash... a bug will probably just be filed after it to say the >> function needs to be implemented if the app really uses it, so what is >> gained? > > Same as with other stubs, it prevents a crash. Many applications check > to see if a function works, and if not, crash. When given a stub, they > run. > > -- > -Austin > Given the nature of the function and the game, I'd say it's unlikely to be of much benefit, has it been tested?

Nov. 20, 2009

Re: d3dx9_36: add a stub for D3DXCreateTextureFromFileInMemory

by Austin English

On Fri, Nov 20, 2009 at 12:05 AM, Jeff Zaroyko <jeffzaroyko(a)gmail.com> wrote: > On Fri, Nov 20, 2009 at 4:56 AM, Austin English <austinenglish(a)gmail.com> wrote: >> Should fix http://bugs.winehq.org/show_bug.cgi?id=13605 >> >> -- >> -Austin >> > > Does it really fix it, the function still remains unimplemented, crash > or no crash... a bug will probably just be filed after it to say the > function needs to be implemented if the app really uses it, so what is > gained? Same as with other stubs, it prevents a crash. Many applications check to see if a function works, and if not, crash. When given a stub, they run. -- -Austin

Nov. 20, 2009

Re: New valgrind results, this time with overrun checks and lots of new errors.

by Austin English

On Thu, Nov 19, 2009 at 11:16 PM, Dan Kegel <dank(a)kegel.com> wrote: > On Thu, Nov 19, 2009 at 8:38 PM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: >>> I'm not sure about the user (i.e. developer) interface for turning the >>> heap >>> check on. Should it be automatic when one does warn+heap? >> >> If I got it right it makes sense to enable this only running under valgrind >> control? > > Nope. It's useful all on its lonesome. FWIW, I run with warn+heap daily when running winetest.exe for http://test.winehq.org (without valgrind), so if you want me to run with an extra environment variable to get more warnings/failures for people to fix, let me know :-). -- -Austin

Nov. 20, 2009

Re: d3dx9_36: add a stub for D3DXCreateTextureFromFileInMemory

by Jeff Zaroyko

On Fri, Nov 20, 2009 at 4:56 AM, Austin English <austinenglish(a)gmail.com> wrote: > Should fix http://bugs.winehq.org/show_bug.cgi?id=13605 > > -- > -Austin > Does it really fix it, the function still remains unimplemented, crash or no crash... a bug will probably just be filed after it to say the function needs to be implemented if the app really uses it, so what is gained?

Nov. 20, 2009

Re: New valgrind results, this time with overrun checks and lots of new errors.

by Dan Kegel

On Thu, Nov 19, 2009 at 8:38 PM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: >> I'm not sure about the user (i.e. developer) interface for turning the >> heap >> check on. Should it be automatic when one does warn+heap? > > If I got it right it makes sense to enable this only running under valgrind > control? Nope. It's useful all on its lonesome. > daily script could simply run twice or so with > different zone length, results could > be a diff to default run (16 bytes) results. I think one would want to use the biggest redzone one could without hurting performance... the bigger the redzone, the more bugs one finds. The right value will depend on the app. 16 is probably a good default, but conformance tests are tiny, they can probably tolerate huge ones. - Dan

Nov. 19, 2009

Re: New valgrind results, this time with overrun checks and lots of new errors.

by Nikolay Sivov

Dan Kegel wrote: > On Thu, Nov 19, 2009 at 7:37 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > >>> http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/ >>> is the first full run with the heap tail check enabled. >>> >> So you use some private patches for that, why aren't they merged? >> > > 'Cause I just wrote it an hour before that message? > I already posted it to wine-devel for the curious. > Actually I didn't spot that, sorry, I just was interested :). > I'll try to post to wine-patches today or so. > > In the meantime I've updated > http://wiki.winehq.org/Valgrind > to link to the patch. > > I'm not sure about the user (i.e. developer) interface for turning the heap > check on. Should it be automatic when one does warn+heap? > Or should it need an environment variable or registry setting to > turn it on? How should the user control the size of the redzone > (a feature Microsoft doesn't seem to offer)? > If I got it right it makes sense to enable this only running under valgrind control? > For what it's worth, Windows seems to turn the debug heap on > by default when running apps under a debugger, and lets you disable it > by setting the environment variable _NO_DEBUG_HEAP=1. > That makes me think we should turn this feature on automatically > under warn+heap. > For finer control, setting _NO_DEBUG_HEAP=1 would disable it, > and setting WINE_HEAP_REDZONE would let you pick how big a redzone > to use. (Usually 16 bytes is enough, but I've seen bugs that misses > but 64 bytes catches.) > That's enough maybe, daily script could simply run twice or so with different zone length, results could be a diff to default run (16 bytes) results. > - Dan > >

Nov. 19, 2009