wine-devel

wine-devel@winehq.org

3 participants
84400 discussions

Re: BUG: mouse_event does not move pointer for relative coordinates
by Andriy Palamarchuk 17 Oct '01

17 Oct '01

Andriy P wrote: > The attached test program moves pointer under Windows > NT. > > Under Wine the pointer changes position on move > request in absolute coordinates and does not move for > relative coordinates. <skipped> I tracked down the bug. The issue - in mouse_event the cursor position change occured _before_ the new position was calculated. Old coordinates were used and the latest change in the pointer position did not become effective. I'll submit a patch. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com

1 0

Windows-format metafiles
by Aric Stewart 17 Oct '01

17 Oct '01

Hello all, I am doing so work trying to flesh out he implementation of SetWinMetaFileBits and as such need documentation on Windows-format metafiles (not enhanced metafiles i have that) There must exist specs and documentation from old 3.1 days, but I am having no luck finding it. Does anyone have pointers as to where i could find a spec for the windows format metafiles to help me out? thanks -aric

3 2

Re: PATCH: wine_dbgstr_an()
by Andreas Mohr 17 Oct '01

17 Oct '01

On Tue, Oct 16, 2001 at 10:58:01PM +0200, Johan Gill wrote: > Relay tracing would crash if it came upon a function call with an invalid > pointer as a parameter. > + return "(invalid)"; Hmm, is there any reason why you just return "(invalid)" ? IMHO this can be very misleading, as some programs use strings such as "invalid", "NOT_VALID" or whatever to have something to compare against to check for a valid return. Furthermore it doesn't indicate at all that this string content originates from within wine due to an invalid function argument. I'd use something like: "WINE RELAY: invalid string pointer !" or so. And, even better, sprintf() the string pointer value into a static buffer to be used as a replacement, so that the output of this buffer looks like: "WINE RELAY: invalid string pointer 0x00045213 !". -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

1 0

Re:Pajama Sam 2 and other games
by Eric Pouech 16 Oct '01

16 Oct '01

regarding the sound issues, there still may be some races in the buffer playback. however, there's no specification of sound latency under windows (how many buffers shall be queued in advance to ensure proper playback...). So, there's no guarantee on Wine right now of the latency to expect (in fact, I assume that wine's latency may be higher that Windows one, however I didn't check it). Which means that some program may run fine under windows and have some "holes" in their playback under wine. However, what's less understandable is that the program hangs (or at least doesn't provide any new sound) could run the program with -debugmsg +wave,+mmsys and send me the compreseed output. (BTW, if you want to look at the code, it's in dlls/winmm/wineoss/audio.c) A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________________ Faites un voeu et puis Voila ! www.voila.fr Pendant tout l'été, gagnez une Ford Ka sur Voila Gratter ! http://cybergrattage.voila.fr/voila

1 0

Pajama Sam 2 and other games
by Ori Pessach 16 Oct '01

16 Oct '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I've been trying to run several games from Humongous Entertainment under wine 20011007, installed from an RPM. They run, except for a couple of problems: The first problem is that the sound pauses sometimes. While the sound is paused, the animation animation still plays. It seems like the introduction of a new sound into the mix makes it more likely for the sound to pause. Eventually, the sound will die completely, with the message: err:wave:wodPlayer_Message buffer overflow !? written to stdout. The game will halt at that point, hanging wine. At that point I can do a 'killall wine', and rerun it. The second problem is with the cursor: When you pick up an object, the games modify the cursor to a picture of the object. This doesn't work under wine, and the cursor just disappears. It reappears when you drop the object. The games seem to use the WaveOut API's to play sounds, and the background music is a PCM, not MIDI. From my days writing similar games, I remember that the only way to have low-latency sound mixing using WaveOut was to stop and restart the device, feeding it fresh buffers with the new sounds mixed in. If none of this rings a bell with anybody, I don't mind taking a look at the sound code, to try to figure out what's broken. The cursor problem probably has something to do with trying to create a cursor object from a color bitmap, but I'm just guessing. I'm not even sure what the cursor is supposed to look like, as I've never ran the games under Windows... Any ideas? Thanks, Ori Pessach -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7zG/wRWZDICaLP5ERAktsAKDLW/1hnRwJVfAExvOj24tMtvULogCg+RsA UcS6RDI6knfCr/yKeVYZVas= =zg/k -----END PGP SIGNATURE----- _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

1 0

Re: wine/port.h #include fixes
by Roger Fujii 15 Oct '01

15 Oct '01

fgouget(a)codeweavers.com wrote: > Doing this (except for port.h) I have a tree that builds on Solaris > with no _FILE_OFFSET_BITS warning. So if the above sounds good, I have > patches that are almost ready. > does this build run on solaris? I've been trying for the last couple of days to get the beast to run (compiles ok), but it segfaults in various places (currently in NtCurrentTeb()). This in on a solaris 8 dual CPU unit. This is using gas/gld (results were worse with as/ld). Any pointers on debugging this thing? Thanks. -r -- Roger Fujii <rmf(a)lookhere.com> Underemployed, and trying to keep it that way....

2 2

Messy diff
by Johan Gill 15 Oct '01

15 Oct '01

I found that there were problems with --debugmsg=+relay when hitting a function call with an invalid pointer as parameter. wine_dbgstr_an() would try to dereference the pointer, resulting in a crash. Here's a patch for it. If anything is done the wrong way, please comment on it. /Johan Gill, johane(a)lysator.liu.se

1 0

RE: wine/port.h #include fixes
by Patrik Stridvall 15 Oct '01

15 Oct '01

> François Gouget wrote: > > > > This is a followup on the previous config.h patch, this > time tackling > > the wine/port.h case. > > Hmmm, I see it has been applied to CVS already. But I'm > not too happy > with it anymore :-/ > > I found a problem with 'dlls/winsock/async.c' and > 'dlls/winsock/socket.c' and the DELETE macro. > * DELETE is defined in winnt.h > * DELETE is also defined by a socket-related Solaris header > (arpa/nameser_compat.h, included indirectly) > * so winnt.h undefs DELETE and then defines our value Yes. That is a problem. ERR IIRC is another problem on Solaris. That is why #include "debugtools.h" is always done after all other includes. > * 'wine/port.h' includes 'winnt.h'. So if we include it > first and then > include the Solaris header we get a redefinition error. No it doesn't. At least not any longer. >From "cvs log include/wine.h": < revision 1.15 < date: 2001/07/26 21:43:29; author: julliard; state: Exp; lines: +1 -1 < Patrik Stridvall <ps(a)leissner.se> < Removed inclusion of winnt.h because the porting layer shouldn't < include Windows specific stuff. Note that as the comment says we shouldn't include Windows specific stuff in the porting layer. > One possible solution would be to handle DELETE differently, e.g. > prefix it in Wine, and not prefix it for Winelib, or something like > that. But wine/port.h is not the only header that needs to include > 'config.h'. There is also: > > cdrom.h console.h > ts_shape.h ts_xf86dga.h ts_xf86dga2.h ts_xf86vmode.h ts_xlib.h > ts_xpm.h ts_xresource.h ts_xshm.h ts_xutil.h ts_xvideo.h > wine_gl.h > x11drv.h > > I think it would be wrong to move all these #includes so that they > are first. Plus for the ts_*.h headers I am not sure it would be very > good. Also #including config.h in these is a bit pointless > since we know > that the file including them will need to include config.h too. Sounds reasonable. > So I propose the following instead: > * config.h has no multiple include protection. Add one > (__WINE_CONFIG_H > macro). > * modify the above headers so that they don't include config.h but > contain the following instead: > #ifndef __WINE_CONFIG_H > # error You must include config.h to use this header > #endif > This will make sure that no-one forgets to include config.h when > necessary. > * modify all files that include the above headers so that > they include > config.h as the first header. This actually requires relatively little > work. That is probably a good idea. > * do the same for port.h > * debugtools.h also uses config.h because it needs NO_DEBUG_MSGS and > NO_TRACE_MSGS. Modify configure.in so that these are put on > the command > line instead. They are not the of the same nature as the other macros > anyway: they are completely system independent. Also this will make it > possible to use the Wine debug macros in Winelib applications. Then > debugtools.h will no longer need to #include config.h. This cuts the > number of files causing trouble in about half. That is probably a good idea too. > * there are 3 other files that #include config.h for no good reason > that I can see: gdi.h, heap.h and thread.h. Remove the #includes from > there. Anyway, winapi_check ensures that all the .c files that need > config.h already include it directly. Yes. However that algoritm (or rather heuristics) that decide this is not perfect but it catch most of the cases and the compiler catches a few more and the linker most (all?) of the rest. > * maybe modify winapi_check to make sure that no header file includes > 'config.h' (this would be the frosting on the cake) This is easy. I will do that if Alexandre accept a patch what requires this. > Doing this (except for port.h) I have a tree that builds on Solaris > with no _FILE_OFFSET_BITS warning. So if the above sounds good, I have > patches that are almost ready. Ah. Good.

1 0

Re: wine/port.h #include fixes
by François Gouget 15 Oct '01

15 Oct '01

François Gouget wrote: > > This is a followup on the previous config.h patch, this time tackling > the wine/port.h case. Hmmm, I see it has been applied to CVS already. But I'm not too happy with it anymore :-/ I found a problem with 'dlls/winsock/async.c' and 'dlls/winsock/socket.c' and the DELETE macro. * DELETE is defined in winnt.h * DELETE is also defined by a socket-related Solaris header (arpa/nameser_compat.h, included indirectly) * so winnt.h undefs DELETE and then defines our value * 'wine/port.h' includes 'winnt.h'. So if we include it first and then include the Solaris header we get a redefinition error. One possible solution would be to handle DELETE differently, e.g. prefix it in Wine, and not prefix it for Winelib, or something like that. But wine/port.h is not the only header that needs to include 'config.h'. There is also: cdrom.h console.h ts_shape.h ts_xf86dga.h ts_xf86dga2.h ts_xf86vmode.h ts_xlib.h ts_xpm.h ts_xresource.h ts_xshm.h ts_xutil.h ts_xvideo.h wine_gl.h x11drv.h I think it would be wrong to move all these #includes so that they are first. Plus for the ts_*.h headers I am not sure it would be very good. Also #including config.h in these is a bit pointless since we know that the file including them will need to include config.h too. So I propose the following instead: * config.h has no multiple include protection. Add one (__WINE_CONFIG_H macro). * modify the above headers so that they don't include config.h but contain the following instead: #ifndef __WINE_CONFIG_H # error You must include config.h to use this header #endif This will make sure that no-one forgets to include config.h when necessary. * modify all files that include the above headers so that they include config.h as the first header. This actually requires relatively little work. * do the same for port.h * debugtools.h also uses config.h because it needs NO_DEBUG_MSGS and NO_TRACE_MSGS. Modify configure.in so that these are put on the command line instead. They are not the of the same nature as the other macros anyway: they are completely system independent. Also this will make it possible to use the Wine debug macros in Winelib applications. Then debugtools.h will no longer need to #include config.h. This cuts the number of files causing trouble in about half. * there are 3 other files that #include config.h for no good reason that I can see: gdi.h, heap.h and thread.h. Remove the #includes from there. Anyway, winapi_check ensures that all the .c files that need config.h already include it directly. * maybe modify winapi_check to make sure that no header file includes 'config.h' (this would be the frosting on the cake) Doing this (except for port.h) I have a tree that builds on Solaris with no _FILE_OFFSET_BITS warning. So if the above sounds good, I have patches that are almost ready. -- François Gouget fgouget(a)codeweavers.com

1 0

Re: [Fwd: file inheritance]
by Alexandre Julliard 13 Oct '01

13 Oct '01

eric pouech <eric.pouech(a)wanadoo.fr> writes: > this patch hasn't been committed yet > is there any issue Alexandre ? None, except that the patch conflicts with Mike's changes that I committed a few days ago. I was hoping you would submit an updated patch so I wouldn't have to merge it myself ;-) -- Alexandre Julliard julliard(a)winehq.com

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