September 2001 - Wine-Devel

Re: Quicktime 5.0.x / XVideo usage

by Matthias Dahl

On Fri, Sep 14, 2001 at 09:57:46AM +0200, Marcus Meissner wrote: [... WINE DIRECT DRAW BUILTIN SUPPORT ...] > It works better with my patch, thats why I did it ;) Strange. The builtin support just causes trouble here - and is way too slow. Even though the picture quality is somewhat better with it. *sigh* > No. If you use ddraw=n it will (I think) not use DDRAW, but fall back to use > DIB Sections. Right. And that results in windows-like performance - with the known problems I have stated earlier. > Builtin. The native version of DDRAW does not work to my knowledge. The native support works - at least with DirectX 7.0a. Yet in my case the best solution is turn them both off. *pondering* I will try a new CVS checkout and see if the problem still occurs. If it does, I hope (if you don't mind) we could try to track it down. What do you say? -- So long, Matt ]) matthew2k(a)web.de, GPG key available at public keyservers ([

Sept. 20, 2001

[Problem report] SetWindowWord creates infinite loop

by Gerard Patel

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

Sept. 20, 2001

Re: [Problem report] SetWindowWord creates infinite loop

by Alexandre Julliard

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

Sept. 19, 2001

Re: min/max and types

by Eric Pouech

> > 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

Sept. 19, 2001

Re: min/max and types

by Francois Gouget

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.

Sept. 18, 2001

Re: DDE and postmessage

by eric pouech

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

Sept. 18, 2001

Re: Dialog painting

by Niclas Karlsson MATE

On Mon, Sep 17, 2001 at 11:33:03PM +0000, Gerard Patel wrote: > Your code does not display anything because no message > is retrieved from the message queue. After the Sleep call, > WM_PAINT messages are available, but as you don't > retrieve them by calling PeekMessage or something > like that, nothing is shown. Ok, I see. I actually did compare the messages sent in windows to those sent in wine and then I noticed, among other things, that no WM_PAINT messages were received in this case. > I don't want to say that your app code is wrong, of course. It may very well be, but it works with real windows and some apps use constructs like this (and exhibit the same problems in wine). > There is a problem in Wine, but I don't know what to do > about it. My first thought would be to scan the X queue > and retrieve the expose events as was done before the > great changes of this summer, but this may be somewhat > difficult to do right. Well, the window needs to be painted during the first call to CreateDialog() - how to fix it is another matter. My naive idea would be to just set the invalid region manually and/or to send a WM_PAINT. Fetching expose events may also be a good idea, but I know very little about the interaction between Wine and X so I can't really say whether that is a good or a bad idea. > I prefer to waste my time searching for other problems, > because I have no doubt that Alexandre Julliard is > aware of this one and it's clear that he is not finished > yet with X code reorganization. Ok, thanks for clueing me in. Nicke -- -[ nkarlsso(a)abo.fi ]- Seek simplicity, and distrust it. (A. Whitehead)

Sept. 18, 2001

Re: Dialog painting

by Gerard Patel

At 12:35 AM 11/09/2001 +0300, you wrote: > >I took a closer look at this. I just ripped out the interesting parts >from Speak freely in order to find a simple program exhibiting the >problems. What I ended up with was a program which does nothing >interesting except to show a simple dialg using CreateDialog(). It >still doesn't work under Wine. The source is attached. I have looked at your source. With current Wine, expose X events are retrieved from the X server when Wine has nothing else to do. These events are setting the update region. CreateWindow does not set the update region in current Wine, even if the window is visible. This is the point that matters for your problem I think. hSplash = CreateDialog (hInstance, MAKEINTRESOURCE(IDD_SPLASH), NULL, Splash_DlgProc); SetForegroundWindow(hSplash); // here the update region is nil (Wine problem !) UpdateWindow(hSplash); // --> nothing is displayed. Sleep(5000); // events are retrieved from the X server queue. printf("Removing splash.\n"); DestroyWindow(hSplash); Your code does not display anything because no message is retrieved from the message queue. After the Sleep call, WM_PAINT messages are available, but as you don't retrieve them by calling PeekMessage or something like that, nothing is shown. I don't want to say that your app code is wrong, of course. There is a problem in Wine, but I don't know what to do about it. My first thought would be to scan the X queue and retrieve the expose events as was done before the great changes of this summer, but this may be somewhat difficult to do right. I prefer to waste my time searching for other problems, because I have no doubt that Alexandre Julliard is aware of this one and it's clear that he is not finished yet with X code reorganization. Gerard

Sept. 17, 2001

RE: dlls/advapi32/crypt.c

by Patrik Stridvall

> Vladimir Vukicevic <vladimir(a)ximian.com> writes: > > > I think that the discussion of OpenSSL vs. libgcrypt isn't really > > necessary -- there's no reason why two implementations of CryptoAPI > > can't be done, one using the gcrypt backend, one using OpenSSL. > > Granted, this is a duplication of effort, but I think there > is enough > > interest that it shouldn't be too difficult to do both. > Also, it's easy > > enough to ship two different advapi32.so's, or even create an > > intermediate cryptoapi layer that supports plugins, so that > the option > > always remains with the distributor or user whether to go with a GPL > > implementation, a BSD implementation, or even a commercial > > implementation. > > As far as the main tree is concerned, everything has to be under the > Wine license (or compatible). It's not acceptable to depend on a > library that would impose extra conditions on the Wine/Winelib > user. The problem is what constitutes extra conditions is extremly vague. If you have a Winelib application that don't for example use say any crypto functions, you really can't be said either to use or to derive a new work from a completely unused and/or unnessary library. If you do use any crypto function, well, whether that imposes any extra conditions is an extremely difficult legal issue that really can't be answered without a real court case. It might depend on whether the use is optional but it might not. That is what I have been trying to point out in my recent messages. So just saying that "I don't want any libraries that imposed extra conditions on the Wine/Winelib user" is not really a very informative answer. What you mean is (I guess): 1. No use of libraries under the GPL or other viral licenses 2. No use of commersial libraries (end user and/or developer must pay for it) Or do you mean something else? Anyway see below. > And this is not solved by having a choice between two different > sets of extra conditions. Note that you always have the choice of NOT using crypto. If Wine didn't include a working crypto implementation that would be the only choice wouldn't it? As long as it doesn't effect the performance or maintainabillity of Wine in negative way more choices are always better than less IMHO.

Sept. 17, 2001

Monkey Island 3 install

by Johan Gill

After some testing, I've found that the installation of Curse of Monkey Island works fine if winver=win98 is specified. What made the win95 install break was this: --- /opt/cvs-commit/wine/misc/version.c 2001/07/02 19:59:49 1.43 +++ /opt/cvs-commit/wine/misc/version.c 2001/07/27 23:57:38 1.44 @@ -75,7 +75,7 @@ }, /* WIN95 */ { - 0x07005F03, + 0x07000304, 0xC0000004, { sizeof(OSVERSIONINFOA), 4, 0, 0x40003B6, If that is a correct fix, the real problem is to be found somewhere else. /Johan Gill, johane(a)lysator.liu.se

Sept. 17, 2001