- Wine-devel - list.winehq.org

No X11 input events in DGA2 mode
by Andy MacLean 10 Jul '02

10 Jul '02

I was trying to run Starcraft under wine in using the X11 DGA2 mode to get a decent frame rate. I tried running it under various versions of wine and got the same result every time. The problem is that when wine runs the game using DGA2 it ignores all input from the keyboard and mouse and so appears to hang. When running the game with DGA2 support disabled (i.e. not running as root) everything works fine but I get a much lower frame rate. I'm new to wine but I had a stab at fixing the problem which as far as I can see is the following: -> wine creates one X11 display connection for each thread and one 'global' display connection to use for various things like DGA2 which it puts in the 'gdi_display' global variable. The thread specific connections get put in x11drv_thread_data structure pointed to by the driver_data pointer in each thread's thread specific structure. -> wine then switches to DGA2 mode if it can and does an 'XSelectInput' to turn on DGA2 input events. It switches to DGA2 mode using the gdi_display connection so all input events will now come through this connection. -> at some point something asks for new X11 events. It goes into the 'X11DRV_MsgWaitForMultipleObjectsEx' function to poll the X11 display connections for each thread. This ends up calling the 'process_events' function in dlls/x11drv/event.c with the 'x11drv_thread_data' structure for each thread. This is the only function that calls 'process_events', which is the only place that calls any X11 event fetching function outside of 'wineclipserv.c' and 'clipping.c' (which seem do something irrelevant to the dga2 problem). -> but process_events can only look at the thread specific X11 display connections since this is the data it gets passed. I cannot find any code which sets up an 'x11drv_thread_data' structure for gdi_display and XNextEvent is only ever called from inside process_events on data->display. Therefore we never poll gdi_display for X11 events at all so I never get any input. I tested this with some debug output code and wine deffinitely never polls gdi_display for events at any time while running the game. X11DRV_MsgWaitForMultipleObjectsEx explicitly does an XFlush on gdi_display as though it is expecting to have to poll it separately, but it never does ... I tried changing 'process_events' in dlls/x11drv/events.c to the following: static int process_events( struct x11drv_thread_data *data ) { XEvent event; int count = 0; wine_tsx11_lock(); while ( XPending( data->display ) ) { XNextEvent( data->display, &event ); wine_tsx11_unlock(); EVENT_ProcessEvent( &event ); count++; wine_tsx11_lock(); } #ifdef FIX_DGA2_INPUT while ( DGAUsed && gdi_display != NULL && data->display != gdi_display && XPending( gdi_display ) ) { XNextEvent( gdi_display, &event ); wine_tsx11_unlock(); EVENT_ProcessEvent( &event ); count++; wine_tsx11_lock(); } #endif wine_tsx11_unlock(); return count; } And this fixed the problem. What's bugging me though is that if this is the correct answer then how do any programs work at all in DGA2 mode? Wouldn't any program hang in the same way as soon as wine switched to DGA2 mode? It would be handy if this were fixed in the wine code so I don't have to keep downloading source and patching so can someone who knows more about the code please let me know if they think this is worth submitting as a patch or point me in the right direction if this is on the wrong track? Thanks in advance, A.

2 2

RE: newbie question
by Medland, Bill 10 Jul '02

10 Jul '02

(BTW HTML email is generally sort of frowned on here) Unix doesn't run windows programs. I suggest you actually read some of the documentation at www.winehq.com <http://www.winehq.com> , especially the Winelib stuff. Basically wine is a Unix program that understands the structure of Windows DLLS and exes. Wine itself runs, loads the dlls and exes into memory and executes them. Some DLLS are replaced by plug-compatible unix so's that interface to the lower levels. So CreateBitmap will eventually result in calls into probably X11 code. Bill -----Original Message----- From: Preetham [mailto:preetham(a)student.utdallas.edu] Sent: Tuesday, July 09, 2002 5:24 PM To: wine-devel(a)winehq.com Subject: newbie question Hi all: I have a very elementary question. How does the Winodws program run in Unix. For example, i write a program where i call the CreateBitmap() method, what happens. How is a dll called in the unix environment. From what i know, unix dlls are .so files. From the wingdi.h file in the wine\include directory, how does the unix OS know how to resolve the WINAPI call. If i am right, windows dll's are implemented in unix, how is this done. I'm kinda flustered at the moment, would appreciate the help Thanks, Preetham.

4 3

newbie question
by Preetham 10 Jul '02

10 Jul '02

Hi all: I have a very elementary question. How does the Winodws program run in Unix. For example, i write a program where i call the CreateBitmap() method, what happens. How is a dll called in the unix environment. From what i know, unix dlls are .so files. From the wingdi.h file in the wine\include directory, how does the unix OS know how to resolve the WINAPI call. If i am right, windows dll's are implemented in unix, how is this done. I'm kinda flustered at the moment, would appreciate the help Thanks, Preetham.

2 1

RE: Debugger
by Medland, Bill 09 Jul '02

09 Jul '02

> -----Original Message----- > From: Max [mailto:max(a)veneto.com] > Sent: Wednesday, July 10, 2002 3:21 PM > To: wine-devel(a)winehq.com > Subject: Re: Debugger > > > thanx !!! > I'll try it just now... > Btw, two more questions, if you can answer :-) > SNIP > 2 - Starting an app, while loading dll's and symbols, > winedbg starts showing garbage like this : > > No debug information in 32bit DLL > 'C:\WINDOWS\SYSTEM\X11DRV.DLL' (0x40b55000) > Loaded debug information from ELF > '/usr/local/lib/wine/x11drv.dll.so' (0x40b45000) > failure on > type_info:T(3,1)=s8__name:/1(3,2)=*(0,2),0,32;.vf(3,1):(3,3)=* > (0,23),32;type_info::(3,4)=#(3,1),(0,21),(3,5)=*(3,1),(0,1),(0,21);:qq > > _._9type_info;2A*2;(3,1);;operator=::(3,6)=##(3,7)=&(3,1);:__a > s__9type_infoRC9type_info;0A.;type_info::(3,8)=##(3,5);:RC9type_info; > > 0A.(3,9)=##(3,5);:PCc;1A.;before::(3,10)=##(0,12);:RC9type_inf > o;2B.;name::(3,11)=##(3,2);:;2B.; > > operator==::(3,10):__eq__C9type_infoRC9type_info;2B.;operator! > =::(3,10):__ne__C9type_infoRC9type_info;2B.;; > ~%(3,1); at /1(3,2)=*(0,2),0,32;.vf(3,1):(3,3)=*( > ..............<MORE>................. > Loaded debug information from ELF > '/usr/local/lib/wine/x11drv.dll.so' (0x40b45000) > ..............<MUCH MORE>................. > Unknown type '&' > failure on arg:p(0,25)=&(3,1) at (3,1) > Nothing has been defined <> > failure on bl:p(0,26)=*(2,17) at > ..............<MUCH MUCH MORE>................. > > Is it a known bug or... ? Known issue. The debugger doesn't yet know how to handle the extended information available about C++ classes. (If it really cheeses you I have a patch that basically replaces the detailed garbage with "we don't understand") Bill

1 0

Converting resources from A to W and vica versa
by Shachar Shemesh 09 Jul '02

09 Jul '02

Hi list, Returning after a short absence, I have bug 864 to discuss (I have opened it, and will soon be closing it). The problem was that a program I wrote used "ChooseFont" with a resource. I know those are not supported, but when compiled for Unicode (in VC), the program crashed when trying to open the dialog. Investigation revealed that a function called "ChooseFontWtoA" is called, and that, in turn, assumes that lpTemplateName argument is a string. In practice, this argument was actually an int after being handled with "MAKEINTRESOURCE". I will shortly be sending a fix to wine-patches, but I just wanted to draw your attention to the fact that when handling resources, they are not necessarily strings. Failure to recognize this will crash programs. Worst, and this is not the first place I have seen this, this argument is accessed and handled even if the "CF_ENABLETEMPLATE" flag is not set. In other words, an argument that the MSDN promises will not be touched unless a flag is set can crash a program if not set correctly, even if the relevant flag is not set. In short - pay attention, people. Even when implementing stubs, do read through the arguments list and meanings. Shachar

1 0

'Runtime Error 429', and $ offered for a fix
by Sean Russell 09 Jul '02

09 Jul '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello all, I originally posted this to c.e.ms-windows.wine, but I wanted to cross post it to the developers list in the hopes of attracting the proper attention. I appologise if it is inappropriate to offer money for solutions, in this list. My wife is an author. For the past eight months, she's been happily working exclusively on Linux with OpenOffice. She just recently accepted a job doing some tech writing; the application she is to document is a Windows application, made (apparently) predominantly of VB. This application fails to run under a recent Wine. I'm considering two options: (a) Buy a copy of Windows and VMWare, and (b) donate the money I'd spend to a Wine Guru or the Wine project instead, to get the application running. I'd MUCH rather give my money to the Wine project, but this is only an option if I can reasonably hope for a quick turn-around. I'm trying desperately from having to give money to Redmond and incidentally having to maintain a Windows install on her computer :-( Windows would cost me $100, $150 with VMWare. I'll happily donate that to the Wine project, or a Wine developer. It isn't a lot, I know, but if anybody is willing to take this on, please let me know. If it looks like a simple fix, then fine. If it looks like a lot of work, then just let me know and I'll grab a copy of VMWare. I don't have the sourcecode for the application. If you're interested in taking a look at this, email me at 'ser at germane dash software dot com', and I'll send you console dumps, Wine versions, etc. The basic error that the Windows dialog gives us is: Runtime Error '429' ActiveX component can't create object Thanks, sincerely. Sean - --- SER -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD4DBQE9KKOyP0KxygnleI8RAhrWAJiTIgHSli8/GDlIdLKlqMMHBTjyAJoCQV2y 0zty1Z52wQ8TVML1Fn/C5g== =NtZe -----END PGP SIGNATURE-----

2 1

MS' hidden API
by Zhang Shu 09 Jul '02

09 Jul '02

Dear wine developers, I have one question on the development of wine. Long(one or two years) ago I've heard that Microsoft got some hidden APIs in their products of various windows, and they use these APIs in their own applications. I wonder if this is still a problem on their recent product like windows XP. If it is, I guess wine will not be able to run such MS applications which uses hidden APIs. Is this right? And, is wine designed(or its goal is) to run all applications(including MS product and non-MS product) that runs on windows? Please forgive me if this problem has appeared in the past. I just joined this list a couple of days ago. Thank you. Regards, -- Zhang Shu

10 10

wine source doubts
by Preetham 09 Jul '02

09 Jul '02

Hi All: I am a newbie to wine. I have a few queries. 1. I downloaded the wine source from cvs, however, is there any document as to where i can start lookin into the code.? 2. Where is the program(wine loader) that loads a .ece file located in the source. Appriciate the help. Regards, Preetham

2 1

One more try at bug 829 (same surface corruption)
by Tony Lambregts 09 Jul '02

09 Jul '02

After talking with Lionel Ulmer offline I came up with the following patch for bug 829. It includes a hopefully more clear comment of when the corruption can occure and a better set of rules. Change log: fix same surface corruption when no flags are set and areas are the same size Tony Lambregts tony_lambregts(a)telusplanet.net Index: dib.c =================================================================== RCS file: /home/wine/wine/dlls/ddraw/dsurface/dib.c,v retrieving revision 1.11 diff -u -r1.11 dib.c --- dib.c 28 Jun 2002 17:32:25 -0000 1.11 +++ dib.c 9 Jul 2002 03:57:37 -0000 @@ -351,6 +351,7 @@ int bpp, srcheight, srcwidth, dstheight, dstwidth, width; int x, y; LPBYTE dbuf, sbuf; + BOOL SameSurfaceOK = TRUE; TRACE("(%p)->(%p,%p,%p,%08lx,%p)\n", This,rdst,src,rsrc,dwFlags,lpbltfx); @@ -474,6 +475,18 @@ sbase = (BYTE*)sdesc.lpSurface+(xsrc.top*sdesc.u1.lPitch)+xsrc.left*bpp; xinc = (srcwidth << 16) / dstwidth; yinc = (srcheight << 16) / dstheight; + SameSurfaceOK = ((src != iface)|| + (sbase >= dbuf)|| + (xdst.top > xsrc.bottom)||(xdst.left > xsrc.right)||(xdst.right < xsrc.left)); + + /* + A little explination: Screen coruption can occure if the following set of circumstances is true + + 1.) Both the source and destination are the same surface. -->(src != iface) + 2.) The start of the source is less than the destination . -->(sbase >= dbuf) + 3.) There is overlap. -->(xdst.top < xsrc.bottom)&&(xdst.left < xsrc.right)(xdst.right < xsrc.left) + This is fixed in the case where no flags are set and the areas are the same size. + */ if (!dwFlags) { /* No effects, we can cheat here */ @@ -482,11 +495,29 @@ /* No stretching in either direction. This needs to be as * fast as possible */ sbuf = sbase; - for (y = 0; y < dstheight; y++) { - memcpy(dbuf, sbuf, width); - sbuf += sdesc.u1.lPitch; - dbuf += ddesc.u1.lPitch; - } + if (SameSurfaceOK) { + for (y = 0; y < dstheight; y++) { + memcpy(dbuf, sbuf, width); + sbuf += sdesc.u1.lPitch; + dbuf += ddesc.u1.lPitch; + } + } else { + sbuf += (sdesc.u1.lPitch*dstheight); + dbuf += (ddesc.u1.lPitch*dstheight); + if (xdst.top == xsrc.top) { /* Are the source and destination on the same line? */ + for (y = 0; y < dstheight; y++) { + sbuf -= sdesc.u1.lPitch; + dbuf -= ddesc.u1.lPitch; + memmove(dbuf, sbuf, width); + } + } else { + for (y = 0; y < dstheight; y++) { + sbuf -= sdesc.u1.lPitch; + dbuf -= ddesc.u1.lPitch; + memcpy(dbuf, sbuf, width); + } + } + } } else { /* Stretching in Y direction only */ for (y = sy = 0; y < dstheight; y++, sy += yinc) { @@ -544,6 +575,10 @@ } } else if (dwFlags & (DDBLT_KEYSRC | DDBLT_KEYDEST | DDBLT_KEYSRCOVERRIDE | DDBLT_KEYDESTOVERRIDE)) { DWORD keylow, keyhigh; + + if (!SameSurfaceOK) { + FIXME("\tSoure and destination surfaces are the same and could cause display problems\n"); + } if (dwFlags & DDBLT_KEYSRC) { keylow = sdesc.ddckCKSrcBlt.dwColorSpaceLowValue;

1 0

Re: SHLWAPI wsprintf - with patch this time
by Alexandre Julliard 09 Jul '02

09 Jul '02

Jon Griffiths <jon_p_griffiths(a)yahoo.com> writes: > +dlls/shlwapi/wsprintf.c dlls/user/wsprintf.c > Add decimal double (%f) format specifier to *printf functions. These functions are not supposed to handle %f. If you need %f you have to use the real sprintf, not the wsprintf variants. -- Alexandre Julliard julliard(a)winehq.com

1 0