wine-devel

wine-devel@winehq.org

3 participants
84400 discussions

Re: winsock socket.c patch fixes issues with halflife's multicasting
by Francois Gouget 21 Sep '01

21 Sep '01

On 21 Sep 2001, David Hammerton wrote: > it seems there we're a few (bugs/typos) in dlls/winsock/socket.c which > prevented binding of ports when using multicast, or something along those > lines. > heres a small patch which fixes it. Please, user -u when you do a diff: * it makes it easier to see what the patch changes * it makes it easier to find the location you changed in the file. None of my copies of socket.c match yours so all the line offsets are off * it is more robust if you want to apply the patch to a modified version of the file (translation Unified diff formats actually have a chance to apply properly, yours does not) So I suggest you put the following line in your .cvsrc: diff -u All this is also explained there: Wine Developper's Guide: "Submitting Patches" http://wine.codeweavers.com/docs/wine-devel/patches.shtml#PATCH-FORMAT That said I must appologize: I am the one who broke this piece of code. A very bad case of copy/paste. Sincere appologies. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ In theory, theory and practice are the same, but in practice they're different.

1 0

re-implementing real mode interrupts
by Mike McCormack 21 Sep '01

21 Sep '01

Hi, I was wondering if it would be a Good Thing to start re-implementing real mode interrupts using Win32 calls. For example, currently calling DeviceIoControl VWIN32_DIOC_DOS_INT_13 on the VWIN32 device calls to the real mode interrupt INT 13. It could be re-implemented so that INT_Int13Handler does a DeviceIoControl and the low level disk access code moved into the VWIN32 device implemetation. This would better seperate the DOS and Win32 implementations. Any thoughts? Mike ------------------------------------------ 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

Re: Implementation of SPI_GETSHOWSOUNDS action in SystemParametersInfo
by Gerard Patel 20 Sep '01

20 Sep '01

At 02:34 PM 20/09/2001 -0400, you (Andriy Palamarchuk <apa3a(a)yahoo.com>) wrote: >File: windows/sysparams.c <snip> use diff -u See: http://www.winehq.com/dev.shtml (section : patches) Gerard

1 0

Re: min/max and types
by Francois Gouget 20 Sep '01

20 Sep '01

On Tue, 18 Sep 2001, eric pouech wrote: [...] > however, comparaisons like min(short, int) or min(size_t, DWORD) don't > provide lots of errors. integral promotions are straightforward, and > behave as expected by any programmer. so it would be rather ugly IMO > to write something like min((int)s, i) (s being short and i int) But in this last example, wouldn't it be better to declare s as an int or i as a short? Then we would not need a cast. I believe we would rarely be forced to really compare integers of different sizes. Of course the only way to be sure is to really look at the actual warnings... -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly.

3 2

GetSystemMetrics / SetSystemMetrics ?
by Andriy Palamarchuk 20 Sep '01

20 Sep '01

Question: How to update metrics data returned by GetSystemMetrics function? Problem: Currently I'm implementing some easiest FIXMEs (e.g. SPI_GETSHOWSOUNDS) in function SystemParametersInfo. GetSystemMetrics is used to return information for a few types of SPI_GETxxx actions from this function, including the action I'm working on. Logic for corresponding SPI_SETxxx actions is not implemented and contains commented out calls to SetSystemMetrics. As I understand this comment is a mark that corresponding GetSystemMetrics data should be updated in this place. GetSystemMetrics returns data from array sysMetrics. I did not find any function which provides update access to the array. Can you advise how to deal with this problem? Regards, Andriy Palamarchuk

1 0

Quicktime 5.0.x / XVideo usage
by Matthias Dahl 20 Sep '01

20 Sep '01

Hey there... ]) powered by Linux 2.4.8 ([ I have discovered some strange behavior with WINE and Quicktime 5.0.x. As long as the "time slider" and the "audio bars" are being updated the video runs quite sluggish. But if you open a menu or a dialog box both the "time slider" and the "audio bars" stop updating - which is normal. BUT the video itself runs at full speed as long as both are not being updated. Which is kinda strange I guess. Even those animation content which is included with some movs doesn't slow the playback down, so it cannot be a performance issue. (on PIII with 500 Mhz, 256 MB ram and X 4.1.x (G400MAX)) Also if you maximize the video to full screen or anything that is not its original size, the playback also becomes very sluggish. Doesn't WINE use the XVideo protocol for such operations? By the way. I am using yesterday's CVS checkout without any windows DLLs. I'll happily provide more informations - just let me know what you need. Last but not least. All you guys are doing a great job -- and I wanted to take the opportunity to say THANK YOU to you all. :-) -- So long, Matt ]) matthew2k(a)web.de, GPG key available at public keyservers ([

3 4

[Problem report] SetWindowWord creates infinite loop
by Gerard Patel 20 Sep '01

20 Sep '01

The following change in SetWindowWord + + WIN_ReleaseWndPtr(wndPtr); + switch(offset) { - case GWW_ID: ptr = (WORD *)&wndPtr->wIDmenu; break; - case GWW_HINSTANCE: ptr = (WORD *)&wndPtr->hInstance; break; - case GWW_HWNDPARENT: retval = SetParent( hwnd, newval ); - goto end; - default: - WARN("Invalid offset %d\n", offset ); - retval = 0; - goto end; + case GWL_ID: + case GWL_HINSTANCE: + case GWL_HWNDPARENT: + return SetWindowLongW( hwnd, offset, (UINT)newval ); + default: + WARN("Invalid offset %d\n", offset ); + return 0; } creates an infinite loop as SetWindowLong calls WIN_SetWindowLong, that calls SetWindowWord for the GWL_HINSTANCE case. Gerard

1 0

Re: [Problem report] SetWindowWord creates infinite loop
by Alexandre Julliard 19 Sep '01

19 Sep '01

Gerard Patel <gerard.patel(a)nerim.net> writes: > The following change in SetWindowWord > [...] > creates an infinite loop as SetWindowLong calls WIN_SetWindowLong, > that calls SetWindowWord for the GWL_HINSTANCE case. Oops, sorry about that. It should be fixed now. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: min/max and types
by Eric Pouech 19 Sep '01

19 Sep '01

> > however, comparaisons like min(short, int) or min(size_t, DWORD) don't > > provide lots of errors. integral promotions are straightforward, and > > behave as expected by any programmer. so it would be rather ugly IMO > > to write something like min((int)s, i) (s being short and i int) > > But in this last example, wouldn't it be better to declare s as an > int or i as a short? Then we would not need a cast. > I believe we would rarely be forced to really compare integers of > different sizes. Of course the only way to be sure is to really look at > the actual warnings... well, the warnings I looked at come of three kinds (for that's for from being exhaustive): - comparing the dwSize of a struct with the sizeof of the struct. The first being a DWORD, the second of type size_t. Using the macro means using a cast here, which I find rather ugly - comparing an unsigned int with an explicit integer : min(4, u). This could be rewritten easily into min(4u, u) for example - real potential problems with comparing unsigned char with signed short for example. IMO, the first two ones shouldn't require type casts. last but not least, I think that the basic issue here is that gcc should report a sign mismatch in the comparison... and it doesn't. If it did, we wouldn't be arguing on the matter... A+ > > > -- > Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ > Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly. > > > > --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________ Voila vous propose une boite aux lettres gratuite sur Voila Mail: http://mail.voila.fr

1 0

Re: DDE and postmessage
by eric pouech 18 Sep '01

18 Sep '01

Alexandre Julliard wrote: > > eric pouech <eric.pouech(a)wanadoo.fr> writes: > > > I've started looking at the inter-process DDE message management > > as of today, PostMessage doesn't use the packing strategy used by > > SendMessage (rightfully because of possible dangling pointer issue > > if pointers are used in message parameters) > > > > however, some DDE messages need to send additional information > > even when posting (copying all data), and DDE protocol requires > > posting messages (SendMessage is banned) > > > > do you have any plan to handle this ? > > I don't really have any plan yet. We clearly need to do a special case > for posted DDE messages; a possibility would be to use an internal > message with SendMessage to send the data across before posting the > actual DDE message. There is an undocumented message similar to > WM_COPYDATA that can be used to transfer a global memory block across > processes, which is used for stuff like WM_DROPFILES; it doesn't work > right now but I'm planning to implement it soon. This would add a > synchronisation point that may defeat the purpose of the PostMessage > though. If this is a problem we can probably add a DDE-specific server > call to transfer the data what I had in mind was somehow reusing the message packing capabilities of SendMessage for PostMessage. Moreover, we need to handle large memory chunks to be exchanged in SendMessage, so we could kill two birds with one stone. A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

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