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