- Wine-devel - list.winehq.org

double key events
by Arjen Nienhuis 31 Oct '01

31 Oct '01

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 31 Oct '01

31 Oct '01

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 30 Oct '01

30 Oct '01

> 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

Anyone compiled Borland OWL (Object Windows Library) with winelib ?
by Grzegorz Prokopski 30 Oct '01

30 Oct '01

Hi ! I am unable to find this information in wine-devel archives, so I decided to ask here. Q1: Have You heard about anyone who compiled Borland OWL (Object Windows Library) based project with winelib ? Yeah - I know it is an old library and Borland C++ 5.02 is the last version released a few years ago and without future updates. Anyway I have a project which IS written in OWL and need to check how hard will it be to make it working under Linux without rewriting it all. I belive I have the sources for complete OWL of course. Q2: With You expirience what would You say to that statment: If my OWL-based program works under Wine it should be convertable to winelib. How true is that statment ? Q3: I have read docs about using winelib and seen that there is MS Visual C++ mentioned many times. Does MS VC++ have some kind of support in winemake or in winelib itself ? Does OWL case differ much from MS VC++ ? Thank You for Your answers. Grzegorz Prokopski

2 3

re: dde problems
by Josh Duncan 30 Oct '01

30 Oct '01

Eric, thanks for the pointers. I removed the ms versions of the user32, kernel32 dlls. I have attached a log file, containing the last ~100 lines of wine execution. (the command I ran was "wine --debugmsg +dde,+relay --managed ./LOGOS.EXE") am I doing something wrong if wine locks up my computer about half of the time that I try running this app? sometimes I can go back to a virtual console and kill the wine processes(which in turn kills X, annoying but not so bad since xdm kicks in), but often I have to reach for the power button. --Josh On Tue, Oct 30, 2001 at 07:45:05AM -0500, wine-devel-request(a)winehq.com wrote: > Send wine-devel mailing list submissions to > wine-devel(a)winehq.com > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.winehq.com/mailman/listinfo/wine-devel > or, via email, send a message with subject or body 'help' to > wine-devel-request(a)winehq.com > > You can reach the person managing the list at > wine-devel-admin(a)winehq.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of wine-devel digest..." > > > Today's Topics: > > 1. Re:problems with dde, I think... (Eric Pouech) > 2. Re: Colour problems with latest DIB fix (=?iso-8859-1?Q?Fran=E7ois?= Gouget) > 3. Re:(no subject) (Eric Pouech) > > --__--__-- > > Message: 1 > Date: Tue, 30 Oct 2001 09:56:56 +0100 > Subject: Re:problems with dde, I think... > From: "Eric Pouech"<eric.pouech(a)voila.fr> > To: duncan(a)msmd.net > Cc: wine-devel(a)winehq.com > > > I can get the "library" window to show up when running wine, and the initial > > "quick tip" window, but when I click the close button of the tip window wine > > encounters an exception. I believe the exception is in user32.dll, in the > > ddeuninitialize16 function. This is going from my memory of the one time I was > > able to attach to the wine process to catch the exception. > well you have to be sure of that... you can always trace with -debugmsg +dde,+relay and see what gives (and post the 100 lines before the exception is thrown) > > > I attempted copying the kernel32, user32 dll's from a win98 machine into my wine > > dir, but this did not help. > never do that. native kernel, user and gdi DLL won't work under wine. > 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. > > > > --__--__-- > > Message: 2 > Date: Tue, 30 Oct 2001 01:06:35 -0800 > From: =?iso-8859-1?Q?Fran=E7ois?= Gouget <fgouget(a)codeweavers.com> > To: Gerard Patel <gerard.patel(a)nerim.net> > CC: wine-devel(a)winehq.com > Subject: Re: Colour problems with latest DIB fix > > Gerard Patel wrote: > > > > At 12:53 PM 29/10/2001 -0800, you wrote: > > > > >> Anyway, the attached patch is displaying the failing picture correctly. > > >> What do you think ? > > > > > > If I apply your patch, then I see that the red and blue are exchanged > > >when I run vnc as: > > > vncserver :1 -geometry 800x600 -depth 16 -pixelformat bgr565 > > > > Could you explain a bit more what you are doing ? I would like to > > try the same but I don't see how to do it. > > I guess you don't know about VNC then. Here's a description of VNC. > VNC is a pretty cool open-source application which lets you access a > computer remotely, kind of like X but different :-) It is composed of > two parts, a server and a client. > The command above starts an VNC X server. This X server is not using > any graphics card because it is not actually displaying anything. It > just uses a chunk of memory to store the 'screen'. Because of that you > can use about any pixel representation. In the above I specified that I > wanted a 800x600 screen in 16 bits per pixel with the red, green and > blue components in BGR order. > Once you have this server, you can start the client as 'xvncviewer > :1'. This connects to the above VNC server and creates an 800x600 window > that shows you what is displayed in that X server. The client can be run > on the same computer or on another. Because the client/server protocol > involves exchanging bitmap chunks the client is very simple and can run > on about any platform. So you can access the above VNC server from an > Windows computer if you want. > There is also a VNC server for Windows. And this leads to one of the > most interesting applications of VNC: remotely controlling a Windows > computer. From another Windows computer, from any Unix platform, I > believe there's even a client for PalmOS! > > Anyway, by playing with the -depth and -pixelformat options you can > test Wine as if it were running into all sorts of X servers. > > > > Also, if you use vnc to test, did you consider the possibility that vnc > > could have a bug somewhere ? > > There's always that possibility but the results I get with VNC (based > on XFree 3.3.6) are consistent with those I get from the > neomagic&permedia drivers of XFree 4.1.0. > > > [...] > > I had (of course) a number of problems with your app. > > First on my current computer - a Mandrake 8, with Xfree 4, > > your procedure ran fine until it tried to link the thing and then it > > reported that WinMain was missing. I changed in your code > > 'main' to 'WinMain' and all was well. > > Sorry about that. By default winemaker assumes that applications are > graphical applications. So it created a .spec file with "mode guiexe" > and "init WinMain" instead of "mode cuiexe" and "init main". > > > > I tried then to do the same on my other computer (Suse 6.1 with > > Xfree 3.3 and a hand-compiled glibc 2.1.3). No joy. Configure > > always failed with libwine.so failing to find symbols like dlclose > > and the like. I did not figure out what is happening, I just > > copied the binary from my other box and it worked. > > That's strange. It should be investigated... > > > > As for the results, what I see is 11 lines of 13 blocks of 4 colors : > > black, red, green, blue. I guess that when you speak of red and > > blue exchanged, you mean that in one of these blocks the red > > and blue lines are exchanged, right ? > > Yes. > > > > What is strange is that on both of my computers the display > > of your app is the same with or without my patch. No line > > exchanged that I can see. > > 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. > > Actually I have a buffer overflow patch to send for the new DIB code. > I don't think it's related but then, who knows. I will try to send it > tomorrow morning. > > > > > As for The Sims, if you can also check the -debugmsg +bitmap output > > >and make sure it's coherent. > > > > I don't have The Sims... I use a little freeware app that is not available > > from the internet anymore, unfortunately :-/. > > Do you think you could send this freeware app to me? Would I be able > to run it without too much trouble? > > > -- > François Gouget > fgouget(a)codeweavers.com > > > --__--__-- > > Message: 3 > Date: Tue, 30 Oct 2001 10:09:05 +0100 > Subject: Re:(no subject) > From: "Eric Pouech"<eric.pouech(a)voila.fr> > To: ughbash(a)yahoo.com > Cc: wine-devel(a)winehq.com > > > 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. > > > > > --__--__-- > > _______________________________________________ > wine-devel mailing list - wine-devel(a)winehq.com > http://www.winehq.com/mailman/listinfo/wine-devel > > > End of wine-devel Digest

2 1

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

30 Oct '01

At 12:53 PM 29/10/2001 -0800, you wrote: >> Anyway, the attached patch is displaying the failing picture correctly. >> What do you think ? > > If I apply your patch, then I see that the red and blue are exchanged >when I run vnc as: > vncserver :1 -geometry 800x600 -depth 16 -pixelformat bgr565 Could you explain a bit more what you are doing ? I would like to try the same but I don't see how to do it. Also, if you use vnc to test, did you consider the possibility that vnc could have a bug somewhere ? > Without the patch everything is fine. I also checked the formula and >I see nothing wrong with it (as long as you are on a little endian >computer, but you don't have a big endian x86, do you? ;-). Never heard that Amd is doing that :-) > So the question is why doesn't it work on your system. Can you run >The Sims (I assume it's with that the problem happens) with a +bitmap >trace? Then look for cases where either the bmp or the dib has >"depth=24". Then check the masks to see if they make sense. For example, >do they match what you know of your X server. You may also put a trace >in Convert_888_to_565_reverse and check that it is invoked at the right >time. Do they have a bgr888 dib (unsupported in windows AFAIK, but, >except for 1 or 2 shortcuts, supported in Wine)? Maybe it is the DIB >masks that are wrong. That's a bit involved for this evening :-/ > Also it would be great if you could run my test application and check >whether it displays fine. The line to watch for is the sixth line >(rgb888 dib to 565 rgb/bgr bmp and back). I had (of course) a number of problems with your app. First on my current computer - a Mandrake 8, with Xfree 4, your procedure ran fine until it tried to link the thing and then it reported that WinMain was missing. I changed in your code 'main' to 'WinMain' and all was well. I tried then to do the same on my other computer (Suse 6.1 with Xfree 3.3 and a hand-compiled glibc 2.1.3). No joy. Configure always failed with libwine.so failing to find symbols like dlclose and the like. I did not figure out what is happening, I just copied the binary from my other box and it worked. As for the results, what I see is 11 lines of 13 blocks of 4 colors : black, red, green, blue. I guess that when you speak of red and blue exchanged, you mean that in one of these blocks the red and blue lines are exchanged, right ? What is strange is that on both of my computers the display of your app is the same with or without my patch. No line exchanged that I can see. > As for The Sims, if you can also check the -debugmsg +bitmap output >and make sure it's coherent. I don't have The Sims... I use a little freeware app that is not available from the internet anymore, unfortunately :-/. And again, that's a bit complex for today. I'll try later. Gerard

2 1

Re:problems with dde, I think...
by Eric Pouech 30 Oct '01

30 Oct '01

> I can get the "library" window to show up when running wine, and the initial > "quick tip" window, but when I click the close button of the tip window wine > encounters an exception. I believe the exception is in user32.dll, in the > ddeuninitialize16 function. This is going from my memory of the one time I was > able to attach to the wine process to catch the exception. well you have to be sure of that... you can always trace with -debugmsg +dde,+relay and see what gives (and post the 100 lines before the exception is thrown) > I attempted copying the kernel32, user32 dll's from a win98 machine into my wine > dir, but this did not help. never do that. native kernel, user and gdi DLL won't work under wine. 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.

1 0

problems with dde, I think...
by Josh Duncan 30 Oct '01

30 Oct '01

Hi all, I'm a little new to the list, so please be forgiving if I'm asking old questions. I've tried to do some research on the net and list archives to see if my questions have been answered before. I'm trying to run a program called Logos, which is a reference system for Biblical texts and other various study materials. It has a two-(independent)-windowed type interface, with a list of reference materials in one window("library"), and a workspace-type window containing subwindows with the texts of individual books. I can get the "library" window to show up when running wine, and the initial "quick tip" window, but when I click the close button of the tip window wine encounters an exception. I believe the exception is in user32.dll, in the ddeuninitialize16 function. This is going from my memory of the one time I was able to attach to the wine process to catch the exception. I attempted copying the kernel32, user32 dll's from a win98 machine into my wine dir, but this did not help. after doing this, I could not run winedbg either, as it exits giving me the following error: err:win32:PE_fixup_imports No implementation for kernel32.dll.0(wine_get_unix_file_name) imported from winedbg, setting to 0xdeadbeef This error occurs even after removing the two dlls. If anyone can give me advice about how to fix this, I'll try to post up the winedbg results of running the program(backtrace, et al) I know that some people have mentioned dde being broken between apps, I don't know if this is the case for this app, because when I was able to do a winedbg "walk process" it only listed one w-process, with 4 w-threads running. I have attached my wine config file, any advice would be greatly appreciated. (Also, if this email should have gone to the wine-users list, please let me know) I'm using the wine-20011029.i386.rpm from LinuxEasy, linked off of the winehq.org download page. sincerely, Josh Duncan not that it matters, but a pic of the two windows I can produce are at http://www.msmd.net/logos.jpg I'd try and show a pic of the other window, but the system gets so unstable that it can hard-lockup the machine, I think this is a cpu-spinning-in-signal handler problem but I couldn't get you a log right now to prove it.

1 0

Re: problem with virtualdub.
by Roger Fujii 29 Oct '01

29 Oct '01

Nerijus Baliunas wrote: > On Mon, 29 Oct 2001 17:04:51 +0000 Gerard Patel <gerard.patel(a)nerim.net> wrote: > > GP> The web site says that this executable is compressed with a tool called UPX. This > GP> seems to be the reason for the problem, as the original program is compiled with > GP> Ms VC++ - not a very exotic tool. > You can unpack it with upx, even under Linux - http://upx.sourceforge.net/. well, this indeed seems to be part of the problem. Decompressing it makes it go further, but still dies. > GP> I tried a hack for that and virtualdub got further; however, I see that it is > GP> trying to load avicap32.dll and this is not going to work - even under Linux > I remember I was able to start Virtual Dub with wine (maybe a year ago), but don't > remember if it worked. BTW, just yesterday TAKESHIMA Hidenori added stub for avicap32. really? Doesn't seem to be in cvs yet... Looks like it's getting upset about not finding StdChannelMask, but this is just a guess. -r

1 0

(no subject)
by Simon Britnell 29 Oct '01

29 Oct '01

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. wodPlayer could then do an infinite wait and the select could be turned on or off when starting and ending playing. >From my relatively naive view a generic mechanism like this (ie. one that converts async IO selects into wine events) would be a good feature to have from a performance and code tidiness point of view. One caveat is that we'd need to ensure nothing evil happened if somebody sent the synthetic event from somewhere other than the select waiter. Comments? Am I missing something? __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com

1 0