- Wine-Devel - list.winehq.org

Re: Limit number of DirectDrawClipper_SetClipList FIXMEs
by Stefan Leichter Aug. 21, 2004

Aug. 21, 2004

Am Freitag, 20. August 2004 18:37 schrieb Tobias Burnus: > + > HRESULT WINAPI Main_DirectDrawClipper_SetClipList( > - LPDIRECTDRAWCLIPPER iface,LPRGNDATA lprgn,DWORD pdwSize > + LPDIRECTDRAWCLIPPER iface,LPRGNDATA lprgn,DWORD pdwFlag > ) { > ICOM_THIS(IDirectDrawClipperImpl,iface); > - FIXME("(%p,%p,%ld),stub!\n",This,lprgn,pdwSize); > + static int warned = 0; > + if (warned++ < 10 && lprgn != NULL) Hello, for me this looks like if (0 < 10 && lprgn != NULL) what is the same like if (lprgn != NULL) I thing you meant something different Bye Stefan

3 3

Compile on AMD Opetron
by chall＠bcrl.stcloudstate.edu Aug. 21, 2004

Aug. 21, 2004

I tried to compile wine-2004813 on a AMD Opetron this is what I found. ./configure No Problems found. make depend No Problems found. make **FAILS** chuck(a)sniper wine-20040813 $ make make[1]: Entering directory `/home/chuck/src/wine/wine-20040813/libs' make[2]: Entering directory `/home/chuck/src/wine/wine-20040813/libs/port' gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o interlocked.o interlocked.c interlocked.c:248:3: #error You must implement the interlocked* functions for your CPU make[2]: *** [interlocked.o] Error 1 make[2]: Leaving directory `/home/chuck/src/wine/wine-20040813/libs/port' make[1]: *** [port] Error 2 make[1]: Leaving directory `/home/chuck/src/wine/wine-20040813/libs' make: *** [libs] Error 2 chuck(a)sniper wine-20040813 $ After looking at the file libs/port/interlocked.c I noticed that there are special instructions for the UltraSPARC proc. Since I do not read or know asm, I looked at the #include for for Solaris (/usr/include/synch.h). pulled from solaris 9 on sparc. (/usr/include/synch.h) /* * synch.h: * definitions needed to use the thread synchronization interface */ I then looked through a number of other include files and noticed that all this seems to be is a control for threads. Under linux on the AMD Opetron could you not use the pthreads.h #include file? If you need access to a AMD Opetron box I can setup remote access (via SSH) so you can test the code, or I can try the patches (if any) sent. Have Fun! Chuck Hall

2 1

Suggestion for wine-user
by Geoffrey Leach Aug. 20, 2004

Aug. 20, 2004

Perhaps some "worked examples"? It would be helpful to be able to have a set of examples that would illustrate the basic features of Wine. For example: o A "Hello World" .exe that used only the .dll files in the dist. o A script that executed a Windoze app that required only minimal configuration -- for example, just the mount point used for C: o A script that executed a (local) .exe that had its own (local) .dll files (both on the Unix side) Kudos to whoever put together the rpm. Regards.

1 0

Document an API difference
by Shachar Shemesh Aug. 20, 2004

Aug. 20, 2004

Hi list, I'm documenting a probable API result difference between Wine and Windows. At the moment, this is no longer a problem as far as I'm concerned, so there is no point for me to write regression tests and fix it, but this may be stopping someone else. It seems that if you call "select" with a FD set that holds the same file descriptor more than once, Wine's and Window's responses are different. Under windows, you get a statement saying that only one FD is active. Under Wine, you get as many as the number of times the repeating FD is in the set. Like I said, this does not affect, as far as I know, any program, so I'm not sure we need to fix it. I just wanted the list's archive to have a mention of this issue. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

1 0

Re: Backtrace Dumps
by Alexandre Julliard Aug. 20, 2004

Aug. 20, 2004

Robert Shearman <rob(a)codeweavers.com> writes: > I propose the addition of this new debug tool that will allow > developers to output backtraces to the console, without having to > interact with a debugger. It can give a useful indication of how > functions are being called in situations where a break point is not > appropriate. I think it's better to let the debugger take care of that. If you don't want a real breakpoint you could define a custom exception to tell winedbg to just dump the backtrace and continue. -- Alexandre Julliard julliard(a)winehq.org

7 13

Re: Optimization for FindFile* (resend)
by Alexandre Julliard Aug. 20, 2004

Aug. 20, 2004

Robert Shearman <rob(a)codeweavers.com> writes: > Changelog: > Handle case of mask containing no wildcards so that it is possible to > avoid searching through hundreds of directory entries. I'm afraid this doesn't work, you need to take the file position in the directory into account, and also update it properly (which will probably defeat the optimization). -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Move include/async.h to include/wine/async.h
by Alexandre Julliard Aug. 20, 2004

Aug. 20, 2004

Robert Shearman <rob(a)codeweavers.com> writes: > Changelog: > Move include/async.h to include/wine/async.h Actually that file should be removed, we don't want to share internal data structures like that. It will require some restructuring of the async I/O support though. -- Alexandre Julliard julliard(a)winehq.org

1 0

Threading issues? [ck-request@vds.kolivas.org: ck Digest, Vol 3, Issue 16]
by Andreas Mohr Aug. 20, 2004

Aug. 20, 2004

Hi all, this is a nice little posting from the Con Kolivas Linux interactivity patches list. Note that it is about Cedega, not Wine, but it might easily affect Wine, too. Are we doing some big no-nos in the threading area here? (or maybe it's just done the way it is because we cannot do it a different, better way?) For the whole discussion, please see http://bhhdoa.org.au/pipermail/ck/2004-August/000428.html Andreas Mohr ----- Forwarded message from ck-request(a)vds.kolivas.org ----- Message: 12 Date: Mon, 16 Aug 2004 21:31:59 +1000 From: Con Kolivas <kernel(a)kolivas.org> Subject: Re: [ck] 2.6.8.1-ck1, cedega-cvs, ALSA sound (choppy) To: greblus(a)poczta.onet.pl Cc: ck(a)vds.kolivas.org Message-ID: <41209B2F.4030207(a)kolivas.org> Content-Type: text/plain; charset="us-ascii" Wiktor Grebla wrote: > On Mon, Aug 16, 2004 at 08:16:08PM +1000, Con Kolivas wrote: > > >>It wont be a preempt threshold problem. >>See if it's a priority issue on the part of wine*. Be absolutely certain >>that wineserver, wine and the game are all run the _same_ priority and >>not a better priority than X. Send me the output of 'top -b -n 1' during >>the sound being choppy. Then try running _all_ the wine things at nice >>+19. This is a simple sanity check to see where the problem lies. > > > It's in fact as you say, all parts of wine have different priorities, and > some of them are higher than X: > > greblus(a)greblus:~$ top -n 1 -b | grep wine > 1630 greblus 23 0 471m 230m 164m R 92.8 45.9 1:54.63 wine > 1666 greblus 20 0 471m 230m 164m S 2.0 45.9 0:01.64 wine > 1629 greblus 20 0 2400 1192 2176 S 0.0 0.2 0:00.00 winex > 1633 greblus 20 0 6864 5056 6756 S 0.0 1.0 0:01.10 wineserver > 1634 greblus 20 0 6864 5056 6756 S 0.0 1.0 0:00.15 wineserver > 1659 greblus 20 0 471m 230m 164m S 0.0 45.9 0:00.00 wine > 1660 greblus 21 0 471m 230m 164m S 0.0 45.9 0:00.00 wine > 1662 greblus 20 0 471m 230m 164m S 0.0 45.9 0:00.06 wine > 1663 greblus 33 0 471m 230m 164m R 0.0 45.9 0:00.41 wine > > greblus(a)greblus:~$ top -b -n 1 | grep X > 621 root 20 0 88092 18m 75m S 0.0 3.8 1:02.96 X > > After renicing all of them there is no problem with choppy sound in all of time > wasting programs I've on my disk :>, and overall (subjective) performance is > better of course. > > Full output of top -b -n 1 is here: > http://unixforge.org/~greblus/ck/top_-b_-n_1.txt > > Kindest Regards, > W. Thanks for details. You do not have different nice levels; that is PRI that is different, which is the "dynamic" priority that constantly changes by the scheduler. It is as I suspected, though - if you renice everything +19 and the problem goes away it is bad programming on the wine developers' part that use what's called sched_yield instead of proper locking between their threads. Don't concern yourself over the details, but at least you have a simple workaround... sigh Cheers, Con

2 1

Re: Different X Displays and Wine
by Eric Frias Aug. 20, 2004

Aug. 20, 2004

Alexandre Julliard (julliard_at_winehq.org) wrote:> We don't support having the same user run from different displays at> the same time. I don't think that's a common setup at all. It probably is not a common setup, but Boaz isn't the only person to have been bitten by this. It has happened both to us and to people who use our software. In our development environment, we usually use one or two common user accounts to do all development and testing in. I know this isn't ideal, but I don't have any power to change this. Anyway, with this setup, it is very easy to have two people developing or testing from the same account but displaying on separate machines. Right now we have been doing what was suggested earlier -- we have a script to launch our application and this script creates a .wine-$DISPLAY directory and points WINEPREFIX to that directory. This works well enough for now. It's inconvenient that the config file and registry aren't shared, so doing things like changing printer settings is a bit of a chore, but this hasn't bothered us too much yet. We're also making the assumption that not many users will be running this on multiple displays, so things will just work for most users and the few that do try to run on multiple displays will at least be able to do it. I'm curious how much work would be involved in fixing this correctly. I've never looked at the wineserver code, so I don't know if this would just be a matter of adding another variable to a data structure that gets passed around to all of the windowing code, or if this would require major changes to the way wineserver works. If it's reasonably easy, I might be able to make the fix or lend some assistance; if it is a large amount of work, we'll probably be happy with the workaround we have. Eric

2 2

winetest results refused by server
by Robert Reif Aug. 20, 2004

Aug. 20, 2004

The winetest server has been refusing to accept test results for a while now. Could someone look into it.

1 0