wine-devel January 2005

wine-devel@winehq.org

149 participants
343 discussions

[AppDB] Beef up the Application Rating Guidelines
by Francois Gouget 29 Jan '05

29 Jan '05

I feel that the current 'Maintainers Ratings System Help' is awfully vague and needs to be beefed up. So I'm attaching a proposal in which I tried to keep the original spirit but make things more precise. * First I'd like to rename this page from Maintainers Ratings System Help to Maintainer's Application Rating Guidelines - I added 'Application' to the title because that's what is being rated, not the maintainers. - I removed 'System' because it does not bring anything. - And I changed 'Help' to 'Guidelines' because this page does not juse tries to help maintainers give a random rating to an application, it tries to define which rating an application can have depending on how it runs. - Finally once the old ratnig system is removed we can remove "Maintainer's" since there will be only one left. * I've also reversed the order of the medals, because it seems a more logical progression and can simplify the explanations: in order to get a Silver medal you must pass all the criterias for a Bronze medal, plus some new ones. * I still feel there's a huge gap between 'Garbage' and 'Bronze' and that it would be interesting to have statistics about the percentage of applications that fail to install, and those that install but crash on startup, both cases which are included in the Garbage category along with those that install and start up but are still not usable. (Chocolate and Tin medals?) I'm attaching the full file as it's much easier to read than a diff. I'll send a diff to wine-patches once the final form has been reached. For reference the original can be found there: http://appdb.winehq.org/help/?topic=maintainer_ratings -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ May your Tongue stick to the Roof of your Mouth with the Force of a Thousand Caramels.

2 1

[AppDB] Proposed Maintainer Guide
by Francois Gouget 29 Jan '05

29 Jan '05

The Application Database is missing a description of the job of an Application Maintainer. So I cleaned up the Maintainer Guide I posted earlier and prepared it for integration into the Application Database site. I attached it to this email for review. Let me know if there is anything missing, things to change, etc. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Cahn's Axiom: When all else fails, read the instructions.

2 1

[shlwapi/tests/shreg] Tests question
by Paul Vriens 29 Jan '05

29 Jan '05

Hi, I've been testing some of these test extensively and can make them pass on all the windows versions I have running. Doing this however means it breaks the wine test. An example is: /* * string grows during expanding * dwSize is larger then the size of part before the backslash but smaller then the expanded string * if the unexpanded string fits into the buffer it can get cut when expanded */ strcpy(buf, sEmptyBuffer); dwSize = sExpLen2 - 4; dwType = -1; dwRet = SHQueryValueExA( hKey, "Test3", NULL, &dwType, buf, &dwSize); ok( (0 == strcmp("", buf)) | (0 == strcmp(sEnvvar2, buf)), "Buffer should be the first part of the string (win98) or empty otherwise, it's (%s)\n", buf); Wine returns a part of the expanded string here: (ImARatherLongButIndeedNeededString\sub) So Wine doesn't do what either win98/winnt/win2k/winxp does (all latest version of the OS's). What's the best approach in this? - fix Wine (but what should be the correct returned buffer?) - extend the ok, by the returned buffer that Wine gives and effectively ignore the differences. Cheers, Paul.

1 0

Intent to package Winetools for Debian
by Scott Ritchie 29 Jan '05

29 Jan '05

A user recently pointed out how hard it is to install winetools on Debian. Of course he's right, so I'm making a winetools debian package much like the wine package. I'll put it in the apt repository along with the regular wine packages when I'm done. Also, I'm thinking of putting winetools in the "recommends" section of the wine package, so it's installed alongside it by default. Any objections? Thanks, Scott Ritchie

3 2

Re: ptrace single-stepping change breaks Wine
by Eric Pouech 29 Jan '05

29 Jan '05

> Btw, does wine ever _use_ PTRACE_SINGLESTEP for any of the things it does? > > If it does, then that woulc certainly explain why my "fix" made no > difference: my fix _only_ handles the case where the ptracer never > actually asks for single-stepping, and single-stepping was started > entirely by the program being run (ie by setting TF in eflags from within > the program itself). > > But if wine ends up using PTRACE_SINGESTEP because wine actually wants to > single-step over some instructions, then the kernel will set the PT_DTRACE > bit, and start tracing through signal handlers too. The way Wine doesn't > want.. wine mixes both approches, we have (to control what's generated inside the various exception) to ptrace from our NT-kernel-like process (the ptracer) to get the context of the exception. Restart from the ptracer is done with PTRACE_SINGLESTEP. (BTW: I also CC:ed wine-devel ML, that might be of interest to them too) A+

14 85

[Fwd: Wine-Wiki.org]
by Ivan Leo Puoti 29 Jan '05

29 Jan '05

Forwarding in case someone cares about this. Ivan.

13 31

unicode "tables"
by Jonathan Wilson 29 Jan '05

29 Jan '05

I remember some people talking about some kind of "unicode tables" that WINE has but that dont match with the MS implementation. What are the tables for? And what API call(s) are involved?

4 3

Re: MSVCRT: Re-implement *printf
by Juan Lang 28 Jan '05

28 Jan '05

Hi Aneurin, > Nobody has any comments about this? Well, I held off thinking I'd give Alexandre a chance to chime in. As it's a large patch, I knew it could take a while. But since he hasn't.. My advice isn't going to be as specific as it has been in the past. You've obviously done a lot on this, and it looks like useful and well-done work. A couple tips to improve its chances then: 1. Write some test cases. For example, in the code you comment: /* Further size specifiers are swallowed; this isn't specified, but was determined from testing. * Thus "ll", for example, does not mean "long long" (I64 should be used instead), but "long" */ Writing a test case that checks this is better than commenting the code, because it really ensures future changes won't break it. Generally, test cases help demonstrate the correctness of the patch (and the incorrectness of what's already there.) Once you're written one, they get pretty simple to do. 2. I'm troubled a bit by the memory allocation. It seems as though it should be possible to output characters or formatted output one at a time, keeping track of where you are in the format string and how many characters you are allowed to output. I realize it's a bit difficult since you may be outputting to either a file pointer or to a buffer, but modulo that complication you should be able to avoid allocating temporary buffers. I know, somewhere in the FAQ it says something about correctness before efficiency, but this bit of inefficiency seems pretty avoidable ;) Hope that helps, --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: v2.: [IWineD3d + d3d9] bogus query implemetation
by Juan Lang 28 Jan '05

28 Jan '05

Hi again Oliver, > this should be better. Yeah, but this function is still borked, I think: +HRESULT WINAPI IWineD3DDeviceImpl_CreateQuery(IWineD3DDevice *iface, D3DQUERYTYPE Type, IWineD3DQuery** ppQuery){ + IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *)iface; + + if(NULL == ppQuery){ + /*Just a check to see if we support this type of query*/ + HRESULT hr = D3DERR_NOTAVAILABLE; + /*Lie and say everything is good (we can return ok fake data from a stub)*/ + switch(Type){ + case WINED3DQUERYTYPE_VCACHE: + hr = D3D_OK; + case WINED3DQUERYTYPE_RESOURCEMANAGER: + hr = D3D_OK; (a bunch more) + default: + FIXME("(%p) Unhandled query type %d\n",This , Type); + } Do you mean to print a fixme for every one? If so, why not just do it once before or after the switch? Or if you don't, something like this would be better: + switch(Type){ + case WINED3DQUERYTYPE_VCACHE: + case WINED3DQUERYTYPE_RESOURCEMANAGER: (all the other supported ones) + hr = D3D_OK; + break; + default: + FIXME("(%p) Unhandled query type %d\n",This , Type); + } Notice the added break. Also, for conciseness, I wouldn't duplicate the hr = D3D_OK assignment for each supported type; I'd just let all the supported ones fall through to one assignment statement, like I show here. --Juan __________________________________ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250

1 0

Can winedbg --auto backtrace all threads?
by Michael Ost 28 Jan '05

28 Jan '05

Is there a way to have winedbg --auto do a backtrace of all the threads in an app at exception time? In order to help track down sporadic runtime crashes in our testing process, I have turned on winedbg --auto when wine handles exceptions via the AeDebug registry entry. This is working pretty well except that often winedbg does a backtrace on a thread that I know is not the problem. If I could see a backtrace of all the threads --- lots of data, I know --- the tool might be more useful. Is this already possible? How about advisable %) ? Or must I patch winedbg to do it? Sometimes winedbg appears to hang when handling the exception, or at least doesn't print out any information. When could this happen? Is there something I could do to improve winedbg's chances of working? Cheers... mo PS: our system is using wine-20040914

3 6

← Newer
1
2
3
4
5
6
7
8
...
35
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 January 2005