- Wine-Devel - list.winehq.org

Patch: DSound: PhaseCancel subtracts secondary from primary
by Davin McCall Nov. 1, 2005

Nov. 1, 2005

Hi wine-devs, I have sent this patch to wine-patches, but it appears to have been dropped. I have resent it with some additional explanantion (below). Is there anything I've done wrong / anything I should do in order to get this patch accepted? Any advice would be appreciated, Thanks Davin PS. How long should I wait for a patch to be accepted before I assume it's been dropped? ---- Hi, This is my first ever wine patch. I have been doing work on DSound as discussed on wine-devel with some very promising results (see the discussion there). As a result I have a large number of changes which I intend to provide a series of patches for. This is one is probably the most trivial fix and is largely unrelated to the other fixes. But if you look at the code for a while as I have you can see that it's obviously correct - the existing implementation of PhaseCancel inverts the original waveform; with this patch it doesn't. Please consider accepting. Thanks, - Davin Changelog: DSound: PhaseCancel subtracts secondary buffer from primary buffer, not the other way around. Davin McCall davmac(a)davmac.org

2 3

Unmet dependency with Mozilla ActiveX install
by Ron Jensen Nov. 1, 2005

Nov. 1, 2005

I tried installing a free game at random [1] from a web site I found [2]. I downloaded it and tried installing it into a freshly created with "wineprefixcreate" .wine folder. The game installed without a problem. When I tried to run the game wine presented a dialog that said I needed Mozilla ActiveX controls and offered to download & install them. The download worked, however the install _FAILED_ . I found a web site [3] with troubleshooting tips. It suggested I was missing two dlls, MSVCP60.DLL and MSVCRT.DLL. I downloaded the zip file [4] and unzipped it into ~/.wine/drive_c/windows/system . Reran the game, wine presented the same dialog about ActiveX. This time it downloaded & installed properly. The game started, ran and played. Two issues come to mind for the ActiveX installer: - it need to check for MSVCP60.DLL and MSVCRT.DLL before it bothers to download ActiveX. - it should cache the ActiveX download ( in /tmp maybe? ) with an option to keep it on hand. Since wine is installed per user it is probable a machine may need to install this more than once. [1] http://www.kprobe.com/kprobe/Downloads/SetupXMasMath.exe [2] http://www.kprobe.com/kprobe/index.htm [3] http://www.iol.ie/~locka/mozilla/troubleshooting.htm [4] http://www.iol.ie/~locka/mozilla/runtime60.zip

2 1

Re: Half-Life 2 / Counter-Strike: Source under Wine
by James Liggett Nov. 1, 2005

Nov. 1, 2005

On Mon, 2005-10-31 at 15:00 +0000, Oliver Stieber wrote: > I've got quite a few optimizations to check-in, but I don't think it's a good idea putting in > optimizations that may break things until wined3d is stable enough that bugs in wined3d don't go > on to break the optimizations. I agree. Best to do it right. ;-) > > I'm in the middle of fixing pixel shaders properly, so far I've checked in the code to parse and > cross compile the pixel shaders, I just have to intergrate them with the drawing pipeline. That's great news. I'll keep my eyes open for them when they get committed. Thanks for the excellent work you're doing here. :) James

1 0

Re: Help with WINE and POSIX threading
by Marcus Meissner Oct. 31, 2005

Oct. 31, 2005

On Wed, Oct 26, 2005 at 11:01:51AM -0700, ssawai wrote: > > Message body follows: > > Marcus, > > We have been using WINE for about a year to port the > Windows version of our product to Red Hat AS 3.0. We have > come up against some issues with threading and our > developers have some questions which I am including below. Please ask them on wine-devel(a)winehq.org ... I am just one of the developers ;) I am cc'ing the list. > 1) Wine version > > According to winehq.org, Wine is still alpha software. Since > we are not > interested in Wine as a complete Windows simulator and we > don't plan to > run binaries compiled on Windows, what would be the best > (development) > Wine version to use? 2 days ago we released version 0.9, our first BETA version. This is the version to use for now ;) > 2) Threading > > On several places we use third-party components that use native pthreads > from which we receive callbacks in different pthreads. > > Is it possible to use Wine/pthread mix? What would be the preferred way > of doing things? Umm. I do not know. It might be possible. We provide a kind of barebones pthread implementation ourselves to help this mix. > Our tests show that Wine implements Win32 threads by creating new > processes (via clone() syscall). This is a problem, because, pthreads > spawned from Wine thread, cannot be interlocked with Wine/Win32 Mutex or > CriticalSection. They also seem to be scheduled (by kernel) only within > parent Wine thread. If parent Wine thread terminates early - we have a > crash the moment when one of the orphan pthreads try to place a > callback. > 3) Dynamic library loading > > On many places we use dynamic library loading (LoadLibrary() on Win32). > Possibly we will need to load native libraries also. Is it possible to > load shared libraries (.so) linked with Wine, with native dlopen(), > since we don't need the Win32 DllMain mechanism. What would be the > preferred/best way of doing things? dlopen() is possible from within a WINE context. dlopen() a wine library from a non-WINE program will currently not work, you have to setup the wine context before. > Can you help with these? If not, can you suggest who may > be able to give us some expert insight with our issues? I hope some of the other developers on wine-devel(a)winehq.org can fill in here. Ciao, Marcus

5 4

Re: D3D7 -> WineD3D, 2nd attempt
by Stefan Dösinger Oct. 31, 2005

Oct. 31, 2005

Hello, I think I got the DrawIndexedPrimitiveVB going now(my tracing suggests this), and now I've hit ProcessVertices(). As someone mentioned allready, this is a complex call, and it isn't implemented in DX7, DX8 or WineD3D. This call does some Vertex Transformation, and depending on the App's requests, Lightning and other things. This is some math thing that is done in Software(According to msdn). On DX8 and DX9 this call is slightly different, and it looks like vertex shaders come into play. Does anyone know any free library which implements something like this, or any internet sources on the math behind this? I haven't found anything useable with google. If I can't find anything, I'll have a look in my university's library. One other Question: How slow is DrawStridedSlow? WineD3D uses it because of the diffuse ans specular colors. Currently I get only one useable vertex into DrawIndexedPrimitiveVB from ProcessVertices, the other 5 to draw have their values zeroed. Without drawing anything I get 70 fps(screen refresh rate, expected), with the 6 Vertices I get 1.5 fps. Is this normal for DrawStridedSlow()? Might this be because of drawing 2 triangles with useless vertices? Or might something else be wrong? Stefan

5 8

Half-Life 2 / Counter-Strike: Source under Wine
by James Liggett Oct. 31, 2005

Oct. 31, 2005

Hi, Out of curiosity, has anyone successfully been able to play HL2 or CS:S under wine? Today I finally worked out the kinks getting the original HL to work, and I know some people have been playing around with this stuff. Currently, HL2 and CS:S freeze over on startup. Has anyone even gotten it to start or even play? James Liggett

9 24

Re: wine/dlls/ntdll signal_i386.c exception.c
by Robert Shearman Oct. 31, 2005

Oct. 31, 2005

Alexandre Julliard wrote: >Index: wine/dlls/ntdll/signal_i386.c >diff -u -p wine/dlls/ntdll/signal_i386.c:1.100 wine/dlls/ntdll/signal_i386.c:1.101 >--- wine/dlls/ntdll/signal_i386.c 31 Oct 2005 14: 8: 5 -0000 >+++ /dev/null 31 Oct 2005 14: 8: 5 -0000 >@@ -1384,4 +1384,36 @@ __ASM_GLOBAL_FUNC( DbgBreakPoint, "int $ > */ > __ASM_GLOBAL_FUNC( DbgUserBreakPoint, "int $3; ret"); > >+ >+/********************************************************************** >+ * EXC_CallHandler (internal) >+ */ >+__ASM_GLOBAL_FUNC( EXC_CallHandler, >+" pushl %ebp\n" >+" movl %esp, %ebp\n" >+" subl $12, %esp\n" >+" movl 28(%ebp), %eax\n" >+" movl 12(%ebp), %edx\n" >+" movl %eax, -8(%ebp)\n" >+" movl %edx, -4(%ebp)\n" >+" leal -12(%ebp), %eax\n" >+" .byte 0x64\n" >+" movl (0),%ecx\n" > > Is it not possible to use the proper %fs prefix instead of having to put a bytecode in manually? >+" movl %ecx,(%eax)\n" >+" .byte 0x64\n" >+" movl %eax,(0)\n" >+" movl 20(%ebp), %eax\n" >+" pushl %eax\n" > > There is no need to move the variable into %eax before pushing, as "pushl 20(%ebp)" will work as shortens the assembly. >+" movl 16(%ebp), %eax\n" >+" pushl %eax\n" >+" movl 8(%ebp), %eax\n" >+" pushl %edx\n" >+" pushl %eax\n" >+" call *24(%ebp)\n" >+" movl -12(%ebp), %edx\n" >+" .byte 0x64\n" >+" movl %edx,(0)\n" >+" leave\n" >+" ret\n" >+); > #endif /* __i386__ */ >Index: wine/dlls/ntdll/exception.c >diff -u -p wine/dlls/ntdll/exception.c:1.85 wine/dlls/ntdll/exception.c:1.86 >--- wine/dlls/ntdll/exception.c 31 Oct 2005 14: 8: 5 -0000 >+++ /dev/null 31 Oct 2005 14: 8: 5 -0000 >@@ -116,7 +116,10 @@ static DWORD EXC_UnwindHandler( EXCEPTIO > * happening during the handler execution. > * Please do not change the first 4 parameters order in any way - some exceptions handlers > * rely on Base Pointer (EBP) to have a fixed position related to the exception frame >+ * >+ * For i386 this function is implemented in assembler in signal_i386.c. > > It seems bad to split the function's implementation up like this? We also now lose the TRACE's that were previously printed from within EXC_CallHandler. If they are superfluous to requirements we might as well delete them from the generic function too. > */ >+#ifndef __i386__ > static DWORD EXC_CallHandler( EXCEPTION_RECORD *record, EXCEPTION_REGISTRATION_RECORD *frame, > CONTEXT *context, EXCEPTION_REGISTRATION_RECORD **dispatcher, > PEXCEPTION_HANDLER handler, PEXCEPTION_HANDLER nested_handler) > > -- Rob Shearman

2 1

Theme issues
by Kevin DeKorte Oct. 31, 2005

Oct. 31, 2005

Using the clearlooks theme I found the following inconsistencies using WINE 0.9 1. Scroll bars don't seem to apply the theme 2. winefile the MDI minimize/maximize/close buttons have a square on them rather than something useful 3. Some of the wine icons (the file open dialog as seen from notepad) don't to have transparency implemented. (not a show stopper) Otherwise, wine is looking really really good for the apps I use it for. Notes 6.51 is the main one. Kevin -- Get my public GnuPG key from http://keyserver.veridis.com:11371/export?id=7574690260641978351

1 0

Fwd: Re: Half-Life 2 / Counter-Strike: Source under Wine
by Oliver Stieber Oct. 31, 2005

Oct. 31, 2005

--- Oliver Stieber <oliver_stieber(a)yahoo.co.uk> wrote: > Date: Mon, 31 Oct 2005 15:00:43 +0000 (GMT) > From: Oliver Stieber <oliver_stieber(a)yahoo.co.uk> > Subject: Re: Half-Life 2 / Counter-Strike: Source under Wine > To: James Liggett <jrliggett(a)cox.net> > > > --- James Liggett <jrliggett(a)cox.net> wrote: > > > On Sun, 2005-10-30 at 11:34 -0600, Evil wrote: > > > Thanks for the tip, James! Disabling all the debugging had a much > > > bigger impact than I would have expected. I've included my observations > > > and comments below, in hope that they might be of use to the devs > > > working on DX. > > Yeah, you wouldn't think turning off debugging messages would do much of > > anything but it does. Don't ask me why though... :) > > > > > > The Counter-Strike: Source Video Stress Test is now giving me 15.74fps > > > in 1024x768 windowed mode (vs. 24 in Cedega and 44 in Win98). It's a > > > definite step in the right direction, but still a little too low to > > > prevent you from getting shot by any newb. :) I get the same speed at > > > lower resolutions, which indicates that I'm CPU-limited. I can believe > > > that, since it's pegged-out the entire time I run the test. > > Hmmm... I can usually get double that. My card isn't all that different > > from yours (I have a Radeon 9800 pro) Personally I think it has more to > > do with the speed of the code and yet to be implemented features. I can > > imagine that since Oliver is still trying to stabilize things and > > implement stuff, speed isn't yet the priority. > > I've got quite a few optimizations to check-in, but I don't think it's a good idea putting in > optimizations that may break things until wined3d is stable enough that bugs in wined3d don't go > on to break the optimizations. > > You may be limited on your bus speed, d3d8/wined3d aren't using AGP and they upload the vertex > data for every frame. > > > > > > I get pretty much the same performance whether I am windowing the game > > > by setting wine to emulate a desktop, or just passing -window to the > > > hl2.exe (15.2fps). > > > > > > The odd thing to me is: I get the same speed when running in fullscreen > > > mode. This is even the case if I used XRandR to set my desktop to the > > > same resolution before starting Steam, so that I don't end up > > > accidentally scrolling across my virtual desktop when I move the mouse > > > down or to the right. Doing that is also a help because it stops my > > > newsticker from drawing over the top of the game screen, but it seems to > > > have no impact on performance. > > > > > > Do OpenGL applications typically perform the same in windowed mode as > > > fullscreen mode? My experience programming with DirectX made me expect > > > fullscreen to run faster since the video card only has to flip the > > > backbuffer pointer instead of blitting from one chunk of memory to > > > another. Of course, that all being handled by the video card, I suppose > > > this too is probably just a side-effect of my CPU-limited speed. > > I wouldn't think running a game in a window versus full-screen would > > change much of anything. Then again, I'm no 3D expert either. > > > > > > Here are the parameters I'm feeding to CS:S by the way, in case anyone's > > > interested: "-heapsize 512000 -fullscreen -width 1024 -height 768". > > > I've tried passing "-dxlevel 70" to the hl2.exe, but don't see much if > > > any performance difference. It is interesting to not that if you don't > > > pass this parameter, you will see little white boxes indicating each > > > light source. These boxes aren't clipped by any object. > > > > > > Passing "-dxlevel 80" causes the menu screen to come up completely > > > white, making it unuseable. Forcing DirectX 8.1 or 9.0 has the same > > > white-screen effect. > > Try disabling pixel shaders in winecfg to get around that. They never > > did work for me. I tried to use them yesterday with HL2 to get some > > screenshots, and they froze my computer. If you're lucky enough to even > > star a game using them, they mess things up anyway. > > I'm in the middle of fixing pixel shaders properly, so far I've checked in the code to parse and > cross compile the pixel shaders, I just have to intergrate them with the drawing pipeline. > > Oliver. > > > > > > ___________________________________________________________ > Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail > http://uk.messenger.yahoo.com > ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

1 0

Custom Windows Program Loader
by Informações Oct. 31, 2005

Oct. 31, 2005

Hey All, I've been trying to solve a problem that WINE seems to have tacked quite properly: I need to run a Windows application under Windows OS using custom DLLs in place of Windows-kernel DLLs. For instance, I wanna be able to run the Notepad application loading all its required DLLs from the Windwos/System path but, for instance, user32.dll, that I will provide as a custom implementation. As I can seem, WINE program loader does the job, but not under Windows. Does anybody have any clue on how to make this "magic" happens on a Windows environment (possibly inside cygwin) ? Does anybody know any other tool capable of providing this functionality ? Thanks a lot, FLu-X

7 8