re: dde problems

[Josh Duncan]

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, [e-mail] wrote:
> Send wine-devel mailing list submissions to
>    [e-mail]
>
> 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
>    [e-mail]
>
> You can reach the person managing the list at
>    [e-mail]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of wine-devel digest..."
>
> Today's Topics:
> - Re:problems with dde, I think... (Eric Pouech)
> - Re: Colour problems with latest DIB fix (=?iso-8859-1?Q?Fran=E7ois?= Gouget)
> - 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"
> To: [e-mail]
> Cc: [e-mail]
> > 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 
> To: Gerard Patel 
> CC: [e-mail]
> 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
> [e-mail]
>
> --__--__--
>
> Message: 3
> Date: Tue, 30 Oct 2001 10:09:05 +0100
> Subject: Re:(no subject)
> From: "Eric Pouech"
> To: [e-mail]
> Cc: [e-mail]
> > 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  -  [e-mail]
> http://www.winehq.com/mailman/listinfo/wine-devel
>
> End of wine-devel Digest