- Wine-Devel - list.winehq.org

Re: config.h reorg part 2: config.h includes
by François Gouget Nov. 1, 2001

Nov. 1, 2001

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 Nov. 1, 2001

Nov. 1, 2001

"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 Nov. 1, 2001

Nov. 1, 2001

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 Oct. 31, 2001

Oct. 31, 2001

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 Oct. 31, 2001

Oct. 31, 2001

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 Oct. 31, 2001

Oct. 31, 2001

> 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 Oct. 31, 2001

Oct. 31, 2001

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

double key events
by Arjen Nienhuis Oct. 31, 2001

Oct. 31, 2001

I test wine often with a game called Elastomania. Wine gets better over the years, but there is one problem that remains when playing that game: In the menus the cursor moves two positons on a key press. The biggest problem is that most of the menus have an odd number of items, so half of them are not reachable. This happens with all the versions of wine I have tested on al the platforms I tested it on. The game uses directx. The problem is not in that both the keyup AND keydown events are being interpreted, because the cursor moves twice at keydown. The cursor does not repeat when a key is held down longer. My not so very usefull guess is that the program tries to shut down some sort of messaging, but that doesnt't work with wine, and the program still listens to those events, and recieves them. Where do keyboard events go? this is the output when ran with no cmdline options: Could not stat /mnt/fd0 (No such file or directory), ignoring drive A: fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x40464254)->(00000000,00000008) fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x40386af8)->(00010021,00000013) fixme:x11drv:X11DRV_DDHAL_CreatePalette stub fixme:x11drv:X11DRV_DDHAL_CreatePalette stub fixme:x11drv:X11DRV_DDHAL_CreatePalette stub err:dinput:SysKeyboardAImpl_Unacquire \ Unacquiring a not-acquired device !!! here is a summary of the output when ran with: --debugmsg +key,+keyboard,+dinput it starts with tons of: KEYBOARD_MapDeadKeysys no character for dead keysym 0x00XXXX and X11DRV_KEYBOARD_DetectLayout matches=47, mismatches=0, score=94 X11DRV_KEYBOARD_DetectLayout Attempting to match against "United Sta... blablabla... then: X11DRV_InitKeyboard fixme:ddraw:Main_DirectDraw_SetCooperativeLevel DirectInputCreateA IDirectInputAImpl_CreateDevice keyboarddev_create_device Creating a Keyboard device (0x40464288) then tons of: IDirectInputDevice2AImpl_SetDataFormat then: IDirectInputDevice2AImpl_SetCooperativeLevel \ (this=0x40464288,0x00010021,0x00000006) DISCL_FOREGROUND DISCL_NONEXCLUSIVE it then does very often: X11DRV_MapVirtualKey ... wMapType=1 and uses the return values in: GetAsyncKeyState () which is always: -> 0 and then (at line 25711)... X11DRV_KeyEvent state = 0 X11DRV_KeyEvent KeyPress : keysym=20 (space), ascii chars=1 / 20 / ' ' X11DRV_KeyEvent keycode 0x41 converted to vkey 0x20 X11DRV_KeyEvent bScan = 0x39. queue_kbd_event wParam=0020, lParam=00390001, InputKeyState=81 TranslateMessage (WM_KEYDOWN, 0020, 00390001) TranslateMessage Translating key VK_SPACE (0020), scancode 39 X11DRV_ToUnicode (0020, 0039) : faked state = 0 X11DRV_ToUnicode Found keycode 65 (0x41) X11DRV_ToUnicode Translating char 0x20 from code page 28591 to unicode X11DRV_ToUnicode ToUnicode about to return 1 with char 20 TranslateMessage 1 -> PostMessage(WM_CHAR) TranslateMessage (WM_CHAR, 0020, 00390001) I pressed the space bar! among 'failing' GetAsyncKeyStates is now GetAsyncKeyState (20) -> 8001 GetAsyncKeyState (20) -> 8000 GetAsyncKeyState (20) -> 8000 GetAsyncKeyState (20) -> 8000 GetAsyncKeyState (20) -> 8000 and then: X11DRV_KeyEvent state = 0 X11DRV_KeyEvent KeyRelease : keysym=20 (space), ascii chars=1 / 20 / ' ' X11DRV_KeyEvent keycode 0x41 converted to vkey 0x20 X11DRV_KeyEvent bScan = 0x39. queue_kbd_event wParam=0020, lParam=c0390001, InputKeyState=1 TranslateMessage (WM_KEYUP, 0020, C0390001) and yes: GetAsyncKeyState (20) -> 0 for the VK_UP that gets interpreted twice, the only diffrence is a call to X11DRV_ToUnicode that returns 0, so there is no: TranslateMessage (WM_CHAR... so for every keypress you get: ... GetAsyncKeyState -> 0 GetAsyncKeyState -> 0 keydown: X11DRV_KeyEvent queue_kbd_event TranslateMessage (WM_KEYDOWN... GetAsyncKeyState -> 8001 GetAsyncKeyState -> 8000 ... GetAsyncKeyState -> 8000 keyup: X11DRV_KeyEvent queue_kbd_event TranslateMessage (WM_KEYUP... GetAsyncKeyState -> 0 ... A demo of the game can be downloaded at http://www.elastomania.com

1 0

Re: Colour problems with latest DIB fix
by Gerard Patel Oct. 31, 2001

Oct. 31, 2001

At 01:06 AM 30/10/2001 -0800, you wrote: <snip lot of explanations> First thanks for all this stuff, really enlightening. > This probably means that you have a 16bpp rgb565 screen. Which seems >normal. It also means that the Dib is a bgr888 Dib which does not exist >in Windows. So something weird is happening. Here are the interesting >kind of lines: > >trace:bitmap:X11DRV_DIB_SetImageBits Dib: depth=24 r=ff0000 g=ff00 b=ff >trace:bitmap:X11DRV_DIB_SetImageBits Bmp: depth=16/16 r=f800 g=7e0 b=1f > > This tells us that the Dib is a 24bpp dib and that it is an RGB dib, >the only kind of 24bit DIB in Windows. What tells us that it's an RGB >DIB is the r,g,b masks: the red color is encoded in the high bits of the >24bit value: 0xff0000. Then you hace the green, 0xff00, and the blue, >0xff, hence the rgb888 shorthand. > Similarly the 'Bmp', i.e. an XImage, is a 16bpp rgb image. Here you >will notice that the mask for the green color, 0x7e0, uses 6 bits >instead of just 5. This gives you the rgb565 denomination. > Finally we are in SetImage so we are converting the Dib into a Bmp, >i.e. from rgb888 to rgb565 so we will call Convert_888_to_565_asis >(since both are rgb). > Now I suspect that with your application the Dib masks don't look >like the above Congratulations, you are entirely right. As in many cases, Wine does not work because it is not tolerant to strange parameters Actually the dib masks are all equal to 0. Probably the correct fix is to assume an 'asis' (not reversed) conversion when the app does not set any mask. Gerard

3 2

Re:(no subject)
by Eric Pouech Oct. 31, 2001

Oct. 31, 2001

> 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. well, from a generic point of view this is something to be done however, I don't see where you'd like to dispatch the event to ? the playback thread in this case would have to wait on two different things: - the /dev/dsp fd (when the queue becomes non full) - the external events (play/pause/stop/quit) so you have to decide whether you use unix or Windows sync mechanisms here. unix would be more effective, but a bit harder to do. Windows would be nice (you just need to call the wine server request to create from a unix fd into a windows handle and wait on it. 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