- Wine-Devel - list.winehq.org

Wine and Starcraft
by geschrader Oct. 28, 2001

Oct. 28, 2001

I've been pecking away attempting to track down why the current wine build won't run Starcraft. When it starts up I get the effect that I playfully refer to as the TSOD (Technicolor Screen Of Death). What I've found is that if all of the references to gdi_display in X11DRV_DDHAL_SetPalEntries( ) are replaced with thread_display( ) then it actually starts up and looks pretty good. However, the keyboard and mouse don't work so this is at best a partial fix. I'm pretty sure that this is on the right track since X11DRV_XF86DGA2_CreatePalette( ) uses thread_display( ) to make the palette that is eventually given to X11DRV_DDHAL_SetPalEntries( ). The only other function in dlls/x11drv/x11ddraw.c that uses gdi_display is X11DRV_DDHAL_DestroyPalette( ). Should thread_display( ) be used there also? How is gdi_display related to the display returned by thread_display( )? Both are used in quite a few places but they're obviously not the same thing. Can anybody give me some hints on what might be happening with the keyboard and mouse? Thanks much, ges

1 0

FindWindow, WaitforSingleObject and Deadlock
by Uwe Bonnes Oct. 28, 2001

Oct. 28, 2001

Hallo, I reported before, some applications of the quicklogic suite starts some watchdog application and hangs at this state. I tracked this down to the following sequence of events: - master application starts, sets up an event and resets the event - master application starts the watchdog - as soon as CreateProcess return, the Master application calls WaitForSingleObject with infinite timeout on that event - watchdog application starts and calls FindWindow. This is translated in a GetWindowText Call and finally SendMessageW (WM_GETTEXT) is called - Master application never awakes from waiting for the WaitForSingleObject Event and so never processes the SendMessage and Findwindow in the watchdog never returns I found two things relates to this deadlock in the API description: For WaitForSingleObject: "Use caution when calling the wait functions and code that directly or indirectly creates windows. If a thread creates any windows, it must process messages. Message broadcasts are sent to all windows in the system. A thread that uses a wait function with no time-out interval may cause the system to become deadlocked" so the latter behaviour seems right. But GetWindowText seems to expect such a deadlock: "If the target window is owned by the current process, GetWindowText causes a WM_GETTEXT message to be sent to the specified window or control. If the target window is owned by another process and has a caption, GetWindowText retrieves the window caption text. If the window does not have a caption, the return value is a null string. This behavior is by design. It allows applications to call GetWindowText without hanging if the process that owns the target window is hung." Sending the WM_GETTEXT only for local windows in the FindWindow loop makes the application continue and at some point the event is triggered. How should wine handle that case? Sould the caption be stored on the server? I it perhaps already? Bye Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Free Software: If you contribute nothing, expect nothing --

1 0

wine nolonger accepts mIRC dcc's
by mdew Oct. 26, 2001

Oct. 26, 2001

when someone attempts to send you a file... i receive this in my status window. [06:12] DCC Get of sample_files.zip from Joe_dude: * Break: at one stage, wine+mirc did work..

1 1

ReadFile behaviour on COMs
by Mike McCormack Oct. 26, 2001

Oct. 26, 2001

Hey Uwe, There is still a number of problems with the COMM code that i am slowly fixing. They are: * comm ports opened without FILE_FLAG_OVERLAPPED don't use (any) read and write timeouts (patch in the works) * comm timeouts don't work 100% correctly * WaitCommEvent only works for EV_RXCHAR (difficult to solve correctly) Sounds like your problem might be related to #2. There are a few special cases for the values in the COMMTIMEOUTS structure that aren't being dealt with at the moment. Could you please post a -debugmsg +file,+comm trace and i'll have a look at it on Monday. Additionally, if the software is available online somewhere, please post a link to it. Mike ps. when you say the right byte, you mean the first byte, right? > Hallo, > > somebody showed me an application speaking to a device > connected to the serial port. The application failed after some > successfull communication steps. As the protocoll is available > in some other (open source programm) we could see that the > program requested two bytes from the device , but ReadFile only > delivered one byte (with that byte beeing the right one of the > expected two byte sequence). > > I suspect ReadFile to be the culprit. While the api description > tells to read all requested bytes ( beside of real errors), our > implementation happilies returns fewer bytes than requested. In > the case of COM devices, all timeouts of the SetCommTimeout > structure should be checked two. > > Anyone with an implementaion for that? > > Bye > -- > Uwe Bonnes ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

problem with virtualdub.
by Roger Fujii Oct. 26, 2001

Oct. 26, 2001

there seems to be a funky problem with virtualdub (http://virutaldub.sourceforge.net) Get differing results between solaris and linux, but both seems to fail before the app comes up. Under solaris, it seems like something is screwed up with the loader - when it tries to load the binary, it dies in dump_exports because what's at pe_exports is just garbage. Not sure where it's dying under linux (probably the same place) - don't have a devel environment there (yet). Nothing unusual seems to happen before it gets there (both solaris/linux binaries run sol.exe and other stuff just fine). My suspicion is that the IMAGE_DIRECTORY_ENTRY_EXPORT data isn't pointing to what wine thinks is there, but would like someone who knows more about the loader to say something.... can anyone help shed more light onto this? -r

1 0

Re: none
by Alexandre Julliard Oct. 26, 2001

Oct. 26, 2001

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > Ok, how about this: > Each system parameter has "is_loaded" flag which shows > whether the parameter is loaded or not. Parameters, > stored directly in SysParametersInfo are loaded from > registry only when they are requested and the flag is > "false", after the loading the flag is set to "true". > On interprocess notification of the parameter change > the corresponding parameter flag is set to "false". > The parameter will be reloaded when it is requested > the next time. Yes, something like this would work. > Are there any existing implementations of > communication between Wine processes I can use as an > example? You want to use some variant of SendMessage in this case, probably a broadcast SendNotifyMessage with an internal message code (adding a WM_WINE_ case in dlls/user/message.c). > Do you still think it is better don't affect X > settings from Wine? Yes. > While we are on this - what about other my patch - > "hello5.c"? It fixes a warning and an error message I > got when I tried to compile hello5.c. The error depends on the compiler version. You should check the DUMMYUNIONNAME defines if you want to make it work for all platforms. I'm not sure it's worth the trouble though. -- Alexandre Julliard julliard(a)winehq.com

1 0

(no subject)
by Andriy Palamarchuk Oct. 26, 2001

Oct. 26, 2001

Alexandre Julliard wrote: > Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > > >>Do you think it is better to do lazy loading for most >>parameters? >> > > Yes definitely. Ok, how about this: Each system parameter has "is_loaded" flag which shows whether the parameter is loaded or not. Parameters, stored directly in SysParametersInfo are loaded from registry only when they are requested and the flag is "false", after the loading the flag is set to "true". On interprocess notification of the parameter change the corresponding parameter flag is set to "false". The parameter will be reloaded when it is requested the next time. Parameters, backed by GetSystemMetrics are processed differently. These parameters are always loaded. They are reloaded right away on interprocess change notification. We can't do lazy loading because GetSystemMetrics returns its values from system metrics array and we don't want to complicate this function. I'm going to implement the flags as a bit array. Index constants for this array will be defined separately. >>I'll think about it more. Originally I planned to >>broadcast change notification across processes and use >>the reload function in other process to refresh values >>from registry. The problem with this approach is when >>a parameter is changed without saving. >> > > A possibility could to create a volatile registry branch to save > parameters that aren't permanently saved. This way they would be > accessible from other processes. Thank you for the idea. Are there any existing implementations of communication between Wine processes I can use as an example? Disregard the patches "SystemParametersInfo / GetSystemMetrics", "SPI_GET/SETBORDER". I'll implement the discussed above changes and resubmit them. Do you still think it is better don't affect X settings from Wine? Please let me know. While we are on this - what about other my patch - "hello5.c"? It fixes a warning and an error message I got when I tried to compile hello5.c. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com

1 0

ReadFile behaviour on COMs
by Uwe Bonnes Oct. 26, 2001

Oct. 26, 2001

Hallo, somebody showed me an application speaking to a device connected to the serial port. The application failed after some successfull communication steps. As the protocoll is available in some other (open source programm) we could see that the program requested two bytes from the device , but ReadFile only delivered one byte (with that byte beeing the right one of the expected two byte sequence). I suspect ReadFile to be the culprit. While the api description tells to read all requested bytes ( beside of real errors), our implementation happilies returns fewer bytes than requested. In the case of COM devices, all timeouts of the SetCommTimeout structure should be checked two. Anyone with an implementaion for that? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

(no subject)
by Mike McCormack Oct. 26, 2001

Oct. 26, 2001

Hi Andreas, i had a bit more free time, so i tracked down the rendering problem in NetTerm a bit more. The problem occurs after SelectVisRgn16 is called with the same region as that currently selected in the DC. (eg. dc->hVisRgn == hrgn ). I made a dodgy patch to fix the problem by incrementing the reference count of the region in this case, but i don't know how to fix it properly, because i don't know much about region handling. With the dodgy patch, NetTerm's windows paints properly. Perhaps perhaps you or somebody has a better way to fix the problem? Mike Andreas Mohr wrote: > On Tue, Oct 09, 2001 at 11:35:39AM +1000, Mike McCormack wrote: > > > > Hi All, > > > > i'm trying to solve a comms problem in NetTerm > > http://www.securenetterm.com/ but i've run into another problem. > > > > The rendering in NetTerm fails almost completely. I > > Yep, I strongly suspect a reference count problem here, too. > ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Re: cursor visibility problem
by Alexandre Julliard Oct. 25, 2001

Oct. 25, 2001

Ove Kaaven <ovehk(a)ping.uio.no> writes: > In Alexandre's new windowing architecture, we have in > dlls/x11drv/window.c, line 119, this: > > attr->cursor = X11DRV_GetCursor( display, GlobalLock16(GetCursor()) ); > > Problem: what if ShowCursor(FALSE) is called to hide the cursor *before* > the window was created? Yup, GetCursor still returns the current (arrow) > cursor, so the new window gets associated with a visible cursor, though > the app would expect the cursor to remain hidden. Yes, cursor handling has some problems right now. It also needs to be a lot more clever about setting the cursor on child windows, and not walk the full list of top-level windows on every SetCursor. It will be fixed eventually, but it's not my top priority right now. -- Alexandre Julliard julliard(a)winehq.com

1 0