- Wine-Devel - list.winehq.org

PSDRV question
by Carl Sopchak July 10, 2002

July 10, 2002

I've been trying to get Quicken 2000 Deluxe running in wine. After I figured out that it wasn't finding a DLL for the internet connection (and got that fixed), I started testing the second-most important function of Quicken that I need: check printing. All went well until I tried to print a sample check (to verify alignment), at which point Wine crashed into winedbg. I figured out why: When reading the ppd file, it sets up an *InputSlot for ManualFeed (even though it's not really an InputSlot, but most Win programs treat it as one...). The problem was that, in ppd.c, a Name wasn't given to the slot (but a FullName was), so when ps.c tried to output the header for the InputSlot it crashed (since strlen(NULL) causes a crash). I hacked the AddSlot call to name the slot "Manual", and this seems to work OK. The question that I have is, is this the way that it should REALLY get fixed (does the name matter?), or should something else be done? I'd be happy to correct my hack, if necessary. In either case, I can post the patch to sourceforge, once I know "the right way" this should be handled. Thanks for the help, Carl P.S., I added some TRACE() statements to help me debug this. These can be left in the patch that I post, right?

2 2

DOSEMU team
by friest July 10, 2002

July 10, 2002

1 0

Re: Support for 24bpp when DDBLT_KEYSRC etc are set
by Lionel Ulmer July 10, 2002

July 10, 2002

> Change log: added support for 24bpp when the flags > DDBLT_KEYSRC/DDBLT_KEYDEST and company are set. Well, I have the following comment : > + case 3: { > + int last_sy = -1; > + for (y = sy = 0; y < dstheight; y++, sy += yinc) { > + sbuf = sbase + (sy >> 16) * sdesc.u1.lPitch; > + if ((sy >> 16) == (last_sy >> 16)) { > + /* this sourcerow is the same as last sourcerow - > + * copy already stretched row > + */ > + memcpy(dbuf, dbuf - ddesc.u1.lPitch, width); Are you sure that this works ? If you have pixels in the destination surface that are NOT overwritten by the source surface (due to color-keying) you should not copy these from one line to the other. > + } else { > + LPBYTE s,d = dbuf; > + for (x = sx = 0; x < dstwidth; x++, sx+= xinc) { > + DWORD pixel; > + > + s = sbuf+3*(sx>>16); > + pixel = (s[0]<<16)|(s[1]<<8)|s[2]; > + if (pixel < keylow || pixel > keyhigh){ > + d[0] = (pixel>>16)&0xff; > + d[1] = (pixel>> 8)&0xff; > + d[2] = (pixel )&0xff; > + d+=3; Why only increase the destination pixel when the color is not keyed off ? > + } > + } > + } > + dbuf += ddesc.u1.lPitch; > + last_sy = sy; > + } > + break;} The rest of the patch looks OK :) By the way, which game uses 24 bpp ? It's *EVIL* :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

2 2

No X11 input events in DGA2 mode
by Andy MacLean July 9, 2002

July 9, 2002

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 July 9, 2002

July 9, 2002

(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 July 9, 2002

July 9, 2002

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 July 9, 2002

July 9, 2002

> -----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 July 9, 2002

July 9, 2002

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 July 9, 2002

July 9, 2002

-----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 July 9, 2002

July 9, 2002

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