October 2001 - Wine-Devel - list.winehq.org

Re:(no subject)

by Simon Britnell

--- Eric Pouech <eric.pouech(a)voila.fr> wrote: > 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) 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. the (existing) wodPlayer thread then sits in a WaitForSingleObject( wwo->msgEvent, INFINITE ) and the following case statement, as well as handling WINE_WM_PAUSING, etc has an extra case being: /* pseudocode */ WINE_WM_DSP_READY: /* Write data out to the DSP whenever there's * space in the queue. */ if( more_to_be_written() ) { write_fragments(): } else { remove_dsp_from_select_list(); } break; We also need to add code to the WINE_WM_HEADER case: if( !dsp_in_select_list() ) add_dsp_to_select_list(); > so you have to decide whether you use unix or > Windows sync mechanisms here. I'm not really familiar enough with the windows mechanism, but as far as I can tell, there's basically an event, which gets waited for by WaitForSingleObject and the waiting process is told to proceed by SetNotify. If wodPlayer is entirely internal to wine, there's no reason we couldn't just replace the entire innards of audio.c with something that's fed by a unix pipe and replace the WaitForSingleObject and ring buffer management with writing it all into and reading it from a pipe and using select on the data pipe and the DSP. > 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. __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com

Oct. 30, 2001

Re: Borland OWL & winelib ?

by eric pouech

> > well, it has to be further checked. I'd say likely (as it's possible > > with MFC) > May there be any other problems than with source-compiler ones ? > It is quite old lib and I wouldn't expect it to use any "new" windows > api features. Much less than current MFC - I am sure. my main concern isn't against API support (some native OWL should run in wine). it's more compilation issues that we may face (like use of pragma, specific preprocessor extents..., some 32/16 bit discrepencies). Compiling MFC under wine is not a piece of cake (and furthermore, details have never been released because of copyright issues) > Going back to the OWL sources & wine ;-) (And getting some beer as it > is late evening in Poland now ;-) don't code and drink ;-) A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Oct. 30, 2001

Borland OWL & winelib ?

by Grzegorz Prokopski

eric pouech wrote: > > > Q1: Have You heard about anyone who compiled Borland OWL (Object > > Windows Library) based project with winelib ? > not to my knowledge I am trying ATM. > > 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. > well, it might be possible. some folks have been successful with MFC > however, it has to be checked which BCC++ specific extensions were > used by OWL Yeah, I've read the docs. Gonna check it by experiment. > > 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 ? > well, it has to be further checked. I'd say likely (as it's possible > with MFC) May there be any other problems than with source-compiler ones ? It is quite old lib and I wouldn't expect it to use any "new" windows api features. Much less than current MFC - I am sure. > > Does OWL case differ much from MS VC++ ? > they are different beasts. OWL is a C++ lib, MS VC++ is > compiler/IDE/MFC... > coffee machine (oops this has been disabled lately for C# compliance) I was thinkig about OWL vs. MFC difference. Don't know why my fingers wrote MS VC++ ;-) Nevermind then. Going back to the OWL sources & wine ;-) (And getting some beer as it is late evening in Poland now ;-) Thanks Grzegorz Prokopski

Oct. 30, 2001

Re: Anyone compiled Borland OWL (Object Windows Library) with winelib ?

by eric pouech

> Q1: Have You heard about anyone who compiled Borland OWL (Object > Windows Library) based project with winelib ? not to my knowledge > 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. well, it might be possible. some folks have been successful with MFC however, it has to be checked which BCC++ specific extensions were used by OWL > I belive I have the sources for complete OWL of course. this would be necessary... since OWL is a C++ lib, the DLL linking is done on decorated names, and since GCC and BCC don't use the same you need to recompile OWL > 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 ? well, it has to be further checked. I'd say likely (as it's possible with MFC) > 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 ? what winemaker does provide is a quick way to convert an existing code base for building into winelib. however, it doesn't provide (yet) the project/dependencies/specific rules you can build in any powerful IDE > Does OWL case differ much from MS VC++ ? they are different beasts. OWL is a C++ lib, MS VC++ is compiler/IDE/MFC... coffee machine (oops this has been disabled lately for C# compliance) A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Oct. 30, 2001

Re: dde problems

by eric pouech

Josh Duncan wrote: > 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") well, this is a crash in DdeUninitialize16... I'll have a look at it... but, could resend me (directly, no need to cc wine-devel) the same trace but with --debugmsg +ddeml,+relay (instead of +dde) this would help me a bit (and also the full -debugmsg +ddeml log (without relay), because it seems that some dde activity takes place before and may be the cause of the issues) > 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. well, not really... but it's hard to tell the reason why A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Oct. 30, 2001

Anyone compiled Borland OWL (Object Windows Library) with winelib ?

by Grzegorz Prokopski

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

Oct. 30, 2001

re: dde problems

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

Oct. 30, 2001

Re:(no subject)

by Eric Pouech

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

Oct. 30, 2001

Re: Colour problems with latest DIB fix

by François Gouget

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

Oct. 30, 2001

Re:problems with dde, I think...

by Eric Pouech

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

Oct. 30, 2001