- Wine-devel - list.winehq.org

change cdrom?
by Per Wigren 01 Nov '01

01 Nov '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! I have an annoying problem installing Grim Fandango. It comes on 2 cds. If I mount the cd and run "wine setup.exe" it starts to install until it asks for cd #2. But I can't unmount the CD to put in cd2 because it's busy... If I run "eject", it ejects but it still seems to be cached so it doesn't recognize that I've changed cd! Also: # wine D:\\setup.exe with the cdrom unmounted doesn't work either... :( Any solution to this problem? Regards Per Wigren -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE74YVNyjnjcyLO8HkRAuJmAKCbfxoGueuTnzVO4PZ2W1MQB7hIrgCgmhQt MembJfuT4wVuZyERmHMd+VM= =npbq -----END PGP SIGNATURE-----

2 2

Re: audio.c converted from WaitForSingleObject to poll
by Ove Kaaven 01 Nov '01

01 Nov '01

On Wed, 31 Oct 2001, Simon Britnell wrote: > 2) Removes the need to calculate a sleep interval in > the wodPlayer main loop, as it loops only when dsp is > ready to be written or a command is ready to be > received. Well, it seems like a bad idea to make the player thread enter a busy loop when there isn't enough data to fill the device buffers, don't you think? (Well, though I'd like buffer complete notifications to happen more frequently than they do in Wine's current implementation, making the player thread use 100% CPU isn't the way...)

4 10

mmsystem.c callback thread patch.
by Simon Britnell 01 Nov '01

01 Nov '01

The patch I wrote for mmsystem.c doesn't fix my problem with HomeWorld, so back to the drawing board on that one. The patch fixes a problem that I've only ever seen in HalfLife while I was messing with the innards of wodPlayer and assumes that wodPlayer_Notify can trigger a callback into the application. If that assumption is invalid, please ignore the patch and let me know so I can look into it further. Note that this also changes the semantics of the callbacks because wodPlayer is not halted waiting for the callback to complete, __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com

1 0

Re: config.h reorg part 2: config.h includes
by François Gouget 01 Nov '01

01 Nov '01

François Gouget wrote: [...] > Changelog: > > François Gouget <fgouget(a)codeweavers.com> > > * console/xterm.c, [...] > windows/x11drv/clipboard.c > > Fix the #include order for config.h > Add #include "config.h" directives where needed > Fixes the FILE_OFFSET_BITS redefinition warnings on Solaris (part 2) There was a #include config.h missing in dlls/ddraw/mesa.c in the above patch. The attached patch fixes that. It complements part 2 (p20011031-config.diff) and must thus be applied before part 3 (p20011031-config2.diff) -- François Gouget fgouget(a)codeweavers.com Index: dlls/ddraw/mesa.c =================================================================== RCS file: /home/wine/wine/dlls/ddraw/mesa.c,v retrieving revision 1.3 diff -u -r1.3 mesa.c --- dlls/ddraw/mesa.c 2000/11/27 23:54:26 1.3 +++ dlls/ddraw/mesa.c 2001/11/01 07:51:07 @@ -3,6 +3,8 @@ This file contains all MESA common code */ +#include "config.h" + #include "windef.h" #include "wine/obj_base.h" #include "ddraw.h"

1 0

Re: L"YES" is a NO NO!!!
by Dmitry Timoshkov 01 Nov '01

01 Nov '01

"Francois Gouget" <fgouget(a)free.fr> wrote: > Wine cannot use Unicode strings literals. When you write L"YES" this > is a 32bit Unicode string, not a 16bit unicode string. This means that > when you pass it to lstrcmpiW, which expects 16bit Unicode strings like > all the APIs in Wine, what it sees is this: "Y\0E\0S\0\0\0". And this is > obviously different from "YES". > > > I guess it pays to check the warnings form time to time! Sure. Why not to change L'\0' to a simple 0 in your patch then? @@ -447,10 +451,10 @@ switch (type) { case REG_SZ: data[9] = L'\0'; /* set end of string */ ^^^^^^^^^^^^^^^ -- Dmitry.

2 1

Duplicate StrRetToStr function in commdlg
by Francois Gouget 01 Nov '01

01 Nov '01

Yes, yet another duplicated StrRetToStr function: COMDLG32_StrRetToStrNW in dlls/commdlg/filedlgbrowser.c. At least this time it says that it's a copy. I guess it would be better if the implementations were pointing to each other. It would at least make it easier to maintain. But this case is not as easy as the shell32 case: * first the implementation is slightly different: the SHFree is not commented out in this one. I don't think the difference is intentional. So who is right? * commdlg is not supposed to import shell32. But it already imports a couple of other functions from shell32 so why not this one? It would be better than have another inconsisten implementation. * except that StrRetToStrNW is not exported. It is StrRetToStrN which is exported. So is it ok to call StrRetToStrN? Is StrRetToStrNW really more correct? Well, here is a proposed patch that imports StrRetToStrN from shell32 via the already-in-place GPA mechanism and removes COMDLG32_StrRetToStrNW. Comments? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ La terre est une bêta...

1 0

LockFile - any words of warning?
by Bill Medland 31 Oct '01

31 Oct '01

I am going to have to implement the LockFile/UnlockFile functions. Does anyone have any words of warning? (Like it ain't as easy as calling fcntl) Bill

1 0

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

31 Oct '01

At 12:26 AM 31/10/2001 -0800, you wrote: > > Well, 0 is always wrong. So the previous code was always initializing >it to a wrong value. I was expecting descr.compression to be different >from BI_BITFIELDS which would give the expected 0xff0000, 0xff00 and >0xff. > What is the value of descr.compression? yes, it's 0 - big oops for me; I think I forgot to do a make at the top level :-(. Your patch is fixing the problem, thanks. Gerard

1 0

Re:(no subject)
by Eric Pouech 31 Oct '01

31 Oct '01

> The idea is to have a (new) thread which does nothing > but sit in a select and then generate wine events > whenever the select returns. Various sound system > events cause /dev/dsp to be added to or removed from > the select list so that it generates a (new) > WINE_WM_DSP_READY event. my point is that you don't need an extra thread for that you just need to make a windows handle from the unix fd (the one of /dev/dsp) and do a WaitOnMultipleObjects with 2 handles : - the /dev/dsp handle - the synchronization mechanism with all the wodXXX functions. 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 Avec Voila Mail, consultez vos e-mails sur votre mobile Wap.

2 1

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

31 Oct '01

At 05:50 PM 30/10/2001 -0800, you wrote: > > No no. Usually (0,0,0) means the default rgb layout. But if you >always go to asis in that case, then things will be wrong for users with >a bgr565 X configuration (should reverse in that case). > SetImageBits_* and GetImageBits_* should never get (0,0,0) as the >color masks. They don't know how to handle it and should not have to, >their callers are supposed to take care of that. > I think i found the source of the problem, some old code I had not >changed. Can you try the attached patch? I did and it does not change anything. I don't quite see how it could, since it does not seem better to not initialize data than initialize it to a wrong value :-) I tried ff0000/ff00/ff instead, with better success... Gerard

2 1