wine-devel October 2010

wine-devel@winehq.org

94 participants
301 discussions

Re: [PATCH] riched20/tests: Cleaned up ITextServices::TxGetNaturalSize test and fixed test failures. (try 2)
by Austin Lund 11 Oct '10

11 Oct '10

On 11 October 2010 13:46, Austin Lund <austin.lund(a)gmail.com> wrote: > > + todo_wine ok(result == S_OK || broken(result == E_FAIL), /* WINXP Arabic Language */ > + "TxGetNaturalSize gave unexpected return value (result = %x)\n", result); I know it's slightly unorthodox to reply to your own patch, but if anyone can throw any light on why this fails for this version of windows it would be much appreciated. My guess is a problem with RTL fonts, but I'm not sure.

1 0

Re: iphlpapi: Use Windows rather than Unix values to determine family
by André Hentschel 11 Oct '10

11 Oct '10

Hi "lats", you should please provide your real name in your mail, otherwise your patch has bad chances to get in. Normally you can configure git, so that it reports your name in the "From:" field. -- Best Regards, André Hentschel

2 1

RFC: Patch to implement WSARecvMsg and IP_PKTINFO
by Erich Hoover 11 Oct '10

11 Oct '10

While searching for something else I discovered a bug relevant to the interface-bound UDP broadcast patches I've been working on. Apparently, IP_PKTINFO does work on Windows when used with the WSARecvMsg function (Bug #19493). I've attached a patch to address this issue (including tests), and I would appreciate any comments on it. This patch approaches the problem by: 1) Implementing WSARecvMsg through WS2_recvfrom 2) Passing the control buffer as an additional WSABUF with an internal flag (cleared internally to prevent confusing applications) 3) Converting the returned Unix IP_PKTINFO data to the equivalent Windows version in WS2_recv() by utilizing a temporary buffer Thanks in advance for your feedback. Erich Hoover ehoover(a)mines.edu

1 0

Re: urlmon: Added ProtocolStream_Stat implementation.
by testbot＠testbot.winehq.org 10 Oct '10

10 Oct '10

1 0

Re: user32/tests: Test FindWindowEx for empty window title (try 3)
by testbot＠testbot.winehq.org 10 Oct '10

10 Oct '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=6017 Your paranoid android. === W98SE (32 bit win) === win.c:2970: Test failed: message 000f available win.c:2982: Test failed: message 000f available win.c:2991: Test failed: message 000f available win.c:3000: Test failed: message 000f available === W7PROX64 (64 bit win) === win.c:2684: Test failed: GetActiveWindow() = 0000000000000000 win.c:2684: Test failed: GetFocus() = 0000000000000000 win.c:2710: Test failed: GetActiveWindow() = 0000000000000000 win.c:2710: Test failed: GetFocus() = 0000000000000000 win.c:2769: Test failed: GetActiveWindow() = 0000000000000000 win.c:2769: Test failed: GetFocus() = 0000000000000000

1 0

Re: [2/3] ntdll: Implement NtQuerySystemInformation/SystemLogicalProcessorInformation (try 6)
by Vitaliy Margolen 10 Oct '10

10 Oct '10

On 10/08/2010 12:22 PM, Rudolf Mayerhofer wrote: > +static SYSTEM_LOGICAL_PROCESSOR_INFORMATION cached_lpi[1024]; You think there are systems with that many CPUs running Wine? > + for (i = 0; i < (sizeof(cached_lpi) / sizeof(SYSTEM_LOGICAL_PROCESSOR_INFORMATION)); i++) To make it easier to understand what you doing here please calculate number of elements in cached_lpi array with: sizeof(cached_lpi) / sizeof(cached_lpi[0]); This way people don't need to look up what type cached_lpi is. > @@ -1069,6 +1193,160 @@ void fill_cpu_info(void) > } > } > fclose(f); > + > + /* Parse Logical Processor Information in SysFS */ > + { > + int coreflags = (cached_sci.FeatureSet & CPU_FEATURE_HTT) ? 1 : 0; > + int cpucount = 0, cachecount, nodecount, i; > + ULONG_PTR fullprocessormask = 0, processormask; > + Please don't do this. Don't create a block just so you can declare variables. Put variable declaration at the top of the outer block. > + while ((processormask = sysfs_cpu_topology_getmap(cpucount, "thread_siblings")) > 0) > + { > + /* Core information */ > + { > + /* Unique cores are found multiple times during iteration, add only once */ > + for (i = 0; i < (sizeof(cached_lpi) / sizeof(SYSTEM_LOGICAL_PROCESSOR_INFORMATION)); i++) > + { ... > + } > + } ... > + } Same thing here. > +static int sysfs_cpucache_getint(int cpu, int cache, const char *type) > + /* Cache information */ > + cachecount = 0; > + while ((processormask = sysfs_cpucache_cpumap(cpucount, cachecount)) > 0) > + { > + /* Empty Processormasks are invalid, ignore them */ What does this comment refers too? If it's for the above while() condition, then please put comment above it, not inside the block. > + BYTE level = sysfs_cpucache_getint(cpucount, cachecount, "level"); > + BYTE associativity = sysfs_cpucache_getint(cpucount, cachecount, "ways_of_associativity"); > + WORD linesize = sysfs_cpucache_getint(cpucount, cachecount, "coherency_line_size"); > + DWORD size = sysfs_cpucache_getint(cpucount, cachecount, "size"); I've already told you before - do not mix signed and unsigned. If result of sysfs_cpucache_getint is always assigned to an unsigned variable then change it's return type to unsigned type too. > + /* Determine Cachetype */ > + if (typestring[0] == 'D') > + { > + type = CacheData; > + } > + else if (typestring[0] == 'I') > + { > + type = CacheInstruction; > + } > + else if (typestring[0] == 'U') > + { > + type = CacheUnified; > + } > + else if (typestring[0] == 'T') > + { > + type = CacheTrace; > + } Either use swith case construct here or use complete words and stricmp. > + if ((processormask = sysfs_numanode_cpumap(nodecount)) > 0) > + { > + /* Numa Nodes are already unique. just add them */ > + do > + { > + } > + while ((processormask = sysfs_numanode_cpumap(nodecount)) > 0); > + } > + else > + { > + } People already asked you not to do this. From looking at the code it appears that there is always one node. So get rid of everything except do{} while() block. It will do exactly what you want with extra if()s. Vitaliy.

2 5

Re: shlwapi: Skip more tests on too old shlwapi.dll.
by testbot＠testbot.winehq.org 10 Oct '10

10 Oct '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=6009 Your paranoid android. === WVISTAADM (32 bit ordinal) === No test summary line found === W7PRO (32 bit ordinal) === ordinal.c:1796: Test failed: got 13 ordinal.c:1832: Test failed: got 13 ordinal.c:1877: Test failed: got 23 ordinal.c:1888: Test failed: got 26 === W7PROX64 (32 bit ordinal) === ordinal.c:1796: Test failed: got 13 ordinal.c:1832: Test failed: got 13 ordinal.c:1877: Test failed: got 21 ordinal.c:1888: Test failed: got 24 === W7PROX64 (64 bit ordinal) === ordinal.c:1783: Test failed: got 10 ordinal.c:1789: Test failed: got 26 ordinal.c:1796: Test failed: got 13 ordinal.c:1804: Test failed: got 7 ordinal.c:1817: Test failed: got 10 ordinal.c:1825: Test failed: got 10 ordinal.c:1832: Test failed: got 13 ordinal.c:1839: Test failed: got 26 ordinal.c:1847: Test failed: got 26 ordinal.c:1877: Test failed: got 21 ordinal.c:1888: Test failed: got 24

1 0

Re: cabinet/tests: Reformated output in case of test failure (try 2)
by Alexandre Julliard 09 Oct '10

09 Oct '10

Marko Nikolic <grkoma(a)gmail.com> writes: > In case of test failure, expected and received values are traced. > Format for the two values was different, corrected so both values > are traced as hex. Error values are in general more useful in decimal. -- Alexandre Julliard julliard(a)winehq.org

2 1

Debugging 64-bit Wine Apps with winedbg
by Tom Grubbe 09 Oct '10

09 Oct '10

Hello, we're the developers of a large 64-bit Windows application that uses Wine 1.3.0 64-bit on Linux. When testing began we discovered several crashes inside our windows code on startup and needed to debug them. But the problem seems to be getting any kind of stack trace information from the 64-bit winedbg. This used to work with the 32-bit version of winedbg. Even if I write a 64-bit "hello world" app that intentionally crashes I still can't get a clean stack trace from winedbg. We get a register dump and a stack dump but no back trace. So in our app, we have to resort to calculating the address of the crash in our DLLs using a MAP file and adding a bunch of printfs to try and locate the source of the SEGV. This is awkward, slow and just a bad way to debug. So here's my question - Has anyone had any luck getting a debugger stack trace using the 64-bit winedbg? Some relevant info: * We build wine 64-bit 1.3.0 ourselves * We're running on RHEL 5.5 (Tikanga) 2.6.18-194.el5 64-bit * We get the same non-results from both release and debug windows binaries * Using winedbg --gdb crashes gdb * We tried using msvsmon.exe to attach to and debug the wine process using Visual Studio but it hasn't been helpful * Setting WINEDEBUG to several debug channels has helped some but is difficult to sift through all the noise So any info on strategies to debug 64-bit Wine applications is welcome, or if you need more info I'll be glad to supply it. Thanks for your help! --Tom Grubbe ESRI

4 6

Re: [2/3] ntdll: Implement NtQuerySystemInformation/SystemLogicalProcessorInformation (try 5)
by Alexandre Julliard 08 Oct '10

08 Oct '10

Rudolf Mayerhofer <rm(a)eightyfive.net> writes: > +/*********************************************************************** > + * Several methods to retrieve data from SysFS (/sys) > + * used to retrieve cached_lpi in fill_cpu_info() > + */ > +static int sysfs_cpu_exists(int cpu) > +{ > + char buf[256]; > + > + sprintf(buf, "/sys/devices/system/cpu/cpu%d", cpu); > + return access(buf, F_OK) == 0; > +} > + > +static int sysfs_cpucache_exists(int cpu, int cache) > +{ > + char buf[256]; > + > + sprintf(buf, "/sys/devices/system/cpu/cpu%d/cache/index%d", cpu, cache); > + return access(buf, F_OK) == 0; > +} > + > +static int sysfs_numanode_exists(int node) > +{ > + char buf[256]; > + > + sprintf(buf, "/sys/devices/system/node/node%d", node); > + return access(buf, F_OK) == 0; > +} Don't do that sort of thing. You should handle failures to open the files at the point where you need them instead of doing redundant checks. -- Alexandre Julliard julliard(a)winehq.org

2 2

← Newer
1
...
18
19
20
21
22
23
24
...
31
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel October 2010