- Wine-Devel - list.winehq.org

thread safe?
by Lonnie Cumberland Feb. 25, 2003

Feb. 25, 2003

Hello All, I was wondering if someone could please tell me if Wine is thread safe? That is, I am wondering if is possible to be running multiple Windows applications under wine at the same time without much degradation of the performance of the system? Thanks in advance, Lonnie __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/

3 2

Retiring...for now
by Dustin Navea Feb. 25, 2003

Feb. 25, 2003

Hey guys, I know its been a while.. Things have changed a lot since my last contact with you guys, just thought I would give you a heads up.. I couldnt afford the phone/dsl and let that go, lucky my email is still in tact.. Then I lost my job and couldn't afford rent, so I sold my PC.... :'-( Now, Im gettin ready to start a new job as a telemarketer, and will hopefully be able to make rent this month.. I think everything will be O.K. I just need time to get my priorities straight.. I will probably be leaving to go into the U.S. Army toward the end of the year this year or beginning of next year... Anyways, It's been fun; anyone that wants to take over my bugs on bugs.winehq.com may do so, anyone that wants to take over any of my other tasks (User's Guide, etc) may do so as well, but save a spot for in case I ever find a way to get back here.. May you all have much luck in your journeys and I hope to see you all again someday... Regards, Dustin

4 3

MoveFileW bug?
by Roderick Colenbrander Feb. 25, 2003

Feb. 25, 2003

Hi, Today someone asked me to look at some Wine problems when running a gaming app called "Steam". Because I wasn't using the latest version of the app, the program tried to update itself. During the update process the main program (steam.exe) needs to be replaced by a new version. To do this the old program exits and another executable is being launched. The new process tries to backup the old steam.exe to wine's temp drive to restore it in case something goes wrong. Here the real problem appears. After "moving/renaming" the file the update tool gives an error stating that steam.exe still exists. After looking at the debug output I saw that to move the file the update tool is using MoveFileW. Normally nothing is wrong with this but according to MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/bas…) it can be used for about everything except for the following: "The MoveFile function will move (rename) either a file or a directory (including its children) either in the same directory or across directories. The one caveat is that the MoveFile function will fail on directory moves when the destination is on a different volume." The update tool is using something like this: MoveFileW(steam.exe, e:\\steam.exe) So it tries to move a file from c:\steam\steam.exe to e:\steam.exe which according to the MSDN docs is not possible. The same works fine on Win2k. After hacking MoveFileW to not check if the volumes are different it worked fine on Wine too. What shall we do? Shall we implement the same bugs Windows is doing or shall e listen to the docs at MSDN? (I'm sure some tests need to be made) Roderick Colenbrander

3 3

[Fwd: Re: GDI question]
by Mike Hearn Feb. 25, 2003

Feb. 25, 2003

-----Forwarded Message----- From: James Chaldecott <james(a)swythan.co.uk> To: m.hearn(a)signal.dra.hmg.gb Subject: Re: GDI question Date: 25 Feb 2003 09:32:48 +0000 Mike, I'm a Win32 developer, and I take a look at WineHQ every so often and I noticed this thread. I don't know what Wine performance is like, but I thought you might be interested to know that some Windows graphics drivers (particularly Nvidia) are also very slow doing off-screen BitBlt operations under some circumstances. BitBlt'ing between two memory DC's seems to get very slow if the "acceleration level" is set to "Full" (the default) in the driver. I'm guessing they are, in fact, trying to overoptimize and they assume that at least one of the DC's is a real device (i.e. already in video memory), although I don't really know. We have the problem with our software and found the easy way to overcome it was to drop the driver acceleration factor a notch! I also spotted a bug in Mozilla's Bugzilla DB, and did some profiling for them. http://bugzilla.mozilla.org/show_bug.cgi?id=170272 Anyway, I thought you might be interested. I suppose it means that lots of the BitBlt's being done *are* being accelerated by the hardware, and this is a corner case were performance degrades. James Chaldecott P.S. Feel free to post this to the list if it's interesting, but I don't subscribe, ATM. >Well, I just tried a simple comparison of the Adobe SVG plugin under >Wine and IE6 on Windows XP. Wine _is_ slower by a visible amount when >doing repeated bitblts such as the plugin does on an animation I have, >but it's certainly not something that'd actually affect real world >usage. I don't think GDI performance is really an issue at present, most >apps don't do these kind of repeated double-buffer switches (i assume >flash doesn't actually use the gdi to render into its backbuffer?) so it >only affects apps like photoshop and director/flash. > >In particular when I run the SVG plugin, I can see a FIXME talking about >a potential optimization, so really the issue is just a case of elbow >grease for optimizations (esp in bitblt) rather than a rewrite I'd guess. > -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

1 0

Was reading through the newest news and wondered about Transgaming's fix.
by Joe Millenbach Feb. 25, 2003

Feb. 25, 2003

Did I read that correctly, in that they fixed whatever issues Wine has with glibc 2.3? So that issue with threads being different would be fixed with this? And if the above is true then are they planning to submit this to the Wine project or is this only for thier version? Thanks for your time, Joe Millenbach _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus

3 2

Re: Spam/Bounce-Mail
by Dan Kegel Feb. 25, 2003

Feb. 25, 2003

Joerg Frings-Fuerst wrote: > first I say sorry for your trouble with my bounce-mails. > > This weekend I setup my new Mail-Backupserver. After this work I test a new > version of my Spamcheck-script. In this script I call "rblcheck". My mistake > was the test via list.dsbl.org. I don't mind -- it revealed a bug in my email setup! - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

1 0

Re: Don't use -Wpointer-arith if it produces excessive warnings
by Dmitry Timoshkov Feb. 25, 2003

Feb. 25, 2003

"Mike McCormack" <mike(a)codeweavers.com> wrote: > On Slackware 8.1, this caused a screenful of warnings for *every* file > compiled, which makes it difficult to see important warnings. Same on RH 6.2. But it's actually bug(s) in string.h and a better way IMHO is just fix it, instead of silencing warnings if a user is *really* annoyed by that avalanche of warnings. -- Dmitry.

2 4

Re: WCMD AutoExec patch
by Eric Pouech Feb. 24, 2003

Feb. 24, 2003

Dave Pickles wrote: > As discussed on Wine-devel recently this patch allows wcmd to execute a file > "autoexec.wine" if it exists in the root directory of the default drive. I think we'd better shouldn't we look in <%sysdir%>\system32\autoexec.wine instead (that's where NT puts the autoexec.nt files that cmd.exe loads on startup) ? A+ -- Eric Pouech

2 1

Re: wine/dlls/x11drv x11drv_main.c
by liu spider Feb. 24, 2003

Feb. 24, 2003

It crashed every time when I closed an app, not just "sometimes" :( And I think maybe exchange the calling order of XCloseIM and XCloseDisplay is a better method than just comments out XCloseIM ( I think this will lead to some other problems). --- Alexandre Julliard <julliard(a)wine.codeweavers.com> wrote: > ChangeSet ID: 7168 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2003/01/29 > 19:08:53 > > Modified files: > dlls/x11drv : x11drv_main.c > > Log message: > XCloseIM sometimes crashes in Xlib, don't call it. > > Patch: http://cvs.winehq.com/patch.py?id=7168 > > Old revision New revision Changes Path > 1.67 1.68 +1 -1 > wine/dlls/x11drv/x11drv_main.c > > __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

2 5

Re: Crashes in OSSs audio.c on FreeBSD
by Eric Pouech Feb. 24, 2003

Feb. 24, 2003

> BSD is probably doing the same thing, but nevertheless, -STABLE (i.e. > FreeBSD 4.x) has a bug in the pcm-driver (I think) which makes mapping > the buffer write-only impossible (at least for me). > > FreeBSD 5.x does not have that problem and sadly the pcm-code between > 4.x and 5.x is virtually the same. I think I remember BSD folks speaking of mmap changes... can someone confirm ? >>>+#ifndef __FreeBSD__ >>> /* for some reason, es1371 and sblive! sometimes have junk in here. >>> * clear it, or we get junk noise */ >>> /* some libc implementations are buggy: their memset reads from the >>> buffer... >>>@@ -1826,6 +1832,9 @@ >>> /* in all cases, fill the remaining bytes */ >>> while (len-- != 0) *p1++ = 0; >>> } >>>+#else >>>+ memset(wwo->mapping,0, wwo->maplen); >>>+#endif >> >>you shouldn't need this chunk > > > I know, this has nothing to do with mmap()ing the buffer, but it looks > like FreeBSDs libc doesn't have the bug with memset(), so I just used > that instead. sure, not all Linux distros have this bug, but it creates a new code path, which is bad for maintenance... so leaving the code as it is, is a better option A+ -- Eric Pouech

1 0