- Wine-Devel - list.winehq.org

Intent to package Winetools for Debian
by Scott Ritchie Jan. 29, 2005

Jan. 29, 2005

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 Jan. 29, 2005

Jan. 29, 2005

> 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 Jan. 28, 2005

Jan. 28, 2005

Forwarding in case someone cares about this. Ivan.

13 31

unicode "tables"
by Jonathan Wilson Jan. 28, 2005

Jan. 28, 2005

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 Jan. 28, 2005

Jan. 28, 2005

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 Jan. 28, 2005

Jan. 28, 2005

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 Jan. 28, 2005

Jan. 28, 2005

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

[WINETEST] How is a visible desktop detected
by Paul Vriens Jan. 28, 2005

Jan. 28, 2005

Hi, I was just wondering. I have a Win98/WNT/W2K (on VMWare) and a XP Home system. All are running the winrash service. All were started when I was logged in but only the W98 and WNT were considered running on a visible desktop. What's the criteria for 'running on a visible desktop'? Cheer,s Paul.

2 2

Re: X11DRV: Fix to incorrect detection and other bugs of keyboard driver in XKB presence
by Alexandre Julliard Jan. 28, 2005

Jan. 28, 2005

"Oleh R. Nykyforchyn" <nick(a)pu.if.ua> writes: > Add alternative (alpha) code to keyboard driver in x11drv that can handle > correct detection and switching of keyboard layout both with and without > XKB extension. Add temporary --enable-xkb feature to configure script > to enable compilation with new code instead of existing one. You really need to get rid of these #ifdefs. If the patch is not working well enough to be enabled by default it won't go in at all. Most likely you need to split it in smaller parts that can be tested and applied separately. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: msvcrt: translate name to locate program
by Alexandre Julliard Jan. 28, 2005

Jan. 28, 2005

Michael Wu <flamingice(a)sourmilk.net> writes: > if (args) > { > - ret = msvcrt_spawn(flags, fullname, args, envs); > + if (SearchPathA(NULL, name, exeA, MAX_PATH, fullname, NULL)) > + ret = msvcrt_spawn(flags, fullname, args, envs); That doesn't look right, spawnve is not supposed to search the path. -- Alexandre Julliard julliard(a)winehq.org

3 2