wine-devel

wine-devel@winehq.org

3 participants
84400 discussions

(no subject)
by Simon Britnell 29 Oct '01

29 Oct '01

I had an idea for using poll or select (rather than calculating expected play time and using a timeout) in audio.c The idea is to have a thread that sits on a select and dispatches a synthetic wine event (ie. we'd make up a WM_DSP_READY event) when the select returns. wodPlayer could then do an infinite wait and the select could be turned on or off when starting and ending playing. >From my relatively naive view a generic mechanism like this (ie. one that converts async IO selects into wine events) would be a good feature to have from a performance and code tidiness point of view. One caveat is that we'd need to ensure nothing evil happened if somebody sent the synthetic event from somewhere other than the select waiter. Comments? Am I missing something? __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com

1 0

Re: problem with virtualdub.
by Gerard Patel 29 Oct '01

29 Oct '01

At 05:17 PM 26/10/2001 -0400, you wrote: > >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 > Yes, I have looked at this application. It loads fine under Windows - however, both dependancy walker and the Nt quick viewer are not happy with it (one displays that there is a format error in the exe, the other loops and finally crashes) The web site says that this executable is compressed with a tool called UPX. This seems to be the reason for the problem, as the original program is compiled with Ms VC++ - not a very exotic tool. I think that a fix could be to detect a corrupted header in dump_exports and to not try to display anything if numberoffunctions is not coherent with the export section size. I tried a hack for that and virtualdub got further; however, I see that it is trying to load avicap32.dll and this is not going to work - even under Linux ;:-) Gerard

2 1

Re: Colour problems with latest DIB fix
by Gerard Patel 29 Oct '01

29 Oct '01

At 02:18 PM 21/10/2001 -0700, you wrote: > >Johan Gill wrote: >> >> Since the big DIB fix, red and blue are exchanged in some cases, >> for example in the install program for The Sims. >> >> This happens in both depth 16 and depth 24. > > Could you give me some more information about your X server (version, >driver)? I see a very similar problem with my X server : 4.03 that comes with my Mandrake 8, graphic card is a Sis 6326. I had tested your patch before it was committed BTW but I failed to notice the problem :-/ Anyway, the attached patch is displaying the failing picture correctly. What do you think ? Gerard

2 1

struct thread in server/thread.h
by Gerald Pfeifer 29 Oct '01

29 Oct '01

In server/thread.h we have a definition of struct thread. Unfortunately, though, this clashes with struct thread as defined in /usr/include/sys/thread.h on FreeBSD 5.x and probably other systems (Solaris) as well. How should this be addressed? Would any of you mind fixing this? (If it's okay to just rename struct thread to struct winethread, I'm volunteering to handle that, else it'd be great could one of the experts have a look!) Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

1 0

Wine and Starcraft
by geschrader 29 Oct '01

29 Oct '01

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 28 Oct '01

28 Oct '01

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 27 Oct '01

27 Oct '01

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

WINE and Haxial programs
by haxial 27 Oct '01

27 Oct '01

Hi There My company produces a few programs that run on Windows and MacOS. Some of the users of these programs have been experimenting using WINE to run the programs on Linux. This is what they have been saying: "the KDX server runs FLAWLESSLY, 100% perfect, better than solitaire runs" However, there is one caveat to the above: I'm told that text input doesn't work when running KDX using WINE on Linux. I was wondering if I would be able to work with WINE developers in making KDX run perfectly on Linux using WINE. I think you would find this to be an easier task than usual because KDX only uses a *minimal* amount of windoze APIs. For example, KDX implements it's own GUI, it does not use the windoze API for that. Also, KDX even implements it's own graphics routines, it does not use the windoze GDI functions (except for the final step of getting the images onto the screen). KDX loads no obscure DLL's, it's just a single .exe file. It does not use MDI or any crap like that. It does not access the registry. It does not use MFC. So I think it would be much easier for WINE than your average windoze program. Which probably explains why it's already running well, except there is some bug, probably a minor little thing, that is preventing text input from working. The website is: http://www.haxial.com Thanks.

1 0

ReadFile behaviour on COMs
by Mike McCormack 27 Oct '01

27 Oct '01

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@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 26 Oct '01

26 Oct '01

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel