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

Re: audio.c converted from WaitForSingleObject to poll

by Simon Britnell

Please forgive the length of this missive, I have not the time to write a short one. There are a couple of (serious) bugs in my patch to do with notifications (more latere). It has, however, uncovered a couple of race conditions that applications may trigger to hang the wodPlayer with or without this patch. -- BUSY LOOP -- There is no busy loop because: retval=poll( pollfd.all, wwo->state==WINE_WS_PLAYING), -1 ); only polls the dsp when in the playing state and: if( !wodPlayer_WriteFragments(wwo) ) { /* stop playing if there's nothing to play */ wwo->state = WINE_WS_STOPPED; } Causes the state to become stopped if we run out of things to write. -- BUGS -- Some wave completions will not be notified until something else is played (Doh!). I'm still thinking about this, but the (wrong) easy solution would be to notify on completion of the write instead of completion of the playback. wodGetPosition doesn't keep pace with how much has actually been played. This causes sound to fail in HalfLife. I'd like to remedy this by keeping track of the total written rather than the total played and to return that value less the amount ioctl says is still in the buffer to be played. -- RACE CONDITION -- wodPlayer_Notify (which, as you may guess from the bugs above, is my arch nemesis) triggers a callback into the application. If the application makes any wod calls which wait on the wodPlayer thread to set an event (wodReset,wodRestart or wodPause), the wodPlayer thread hangs waiting for wodPlayer_Notify to return, which is waiting for wodPlayer to SetEvent(wwo->hEvent). Any other threads attempting to wodReset, wodRestart or wodPause will then pile up behind the stalled wodPlayer, potentially hanging the whole program. Looking at the code, it appears at first blush that we may simply remove the SetEvent() and the WaitForSingleObject() calls to remove this race condition. It seems unlikely that this will cause any problems. -- WHERE TO FROM HERE -- I shall put my poll patch to one side and provide two patches against the encumbent audio.c The first patch will remove the SetEvent -> WaitForSingleObject on wodPause,wodReset and wodRestart. The second patch will update wodGetPosition per my above suggestion. I will then re-examine the poll patch/notification timeliness issue to see if I can come up with something reasonable. Questions? Objections? Flames ? :) __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com

Oct. 31, 2001

Re: audio.c converted from WaitForSingleObject to poll

by Ove Kaaven

On Wed, 31 Oct 2001, eric pouech wrote: > > > where's the busy wait ? the code blocks on poll for two types on events > > > - /dev/dsp becomes writable (some new fragments can be written) > > > > So, what do you think happens when /dev/dsp is *always* writable (due to > > insufficient data from the app)? Then it'll never block. > you just need to change the condition in poll for the number of fd:s to > be looked upon and use 2 only when playing and some wavehdr have been > queued but not sent yet to OSS Yes... but the patch should not be applied without doing so, which was my point... but I have concerns that notification accuracy will suffer, too.

Oct. 31, 2001

Re: audio.c converted from WaitForSingleObject to poll

by eric pouech

> > where's the busy wait ? the code blocks on poll for two types on events > > - /dev/dsp becomes writable (some new fragments can be written) > > So, what do you think happens when /dev/dsp is *always* writable (due to > insufficient data from the app)? Then it'll never block. you just need to change the condition in poll for the number of fd:s to be looked upon and use 2 only when playing and some wavehdr have been queued but not sent yet to OSS A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Oct. 31, 2001

Re: audio.c converted from WaitForSingleObject to poll

by Ove Kaaven

On Wed, 31 Oct 2001, eric pouech wrote: > where's the busy wait ? the code blocks on poll for two types on events > - /dev/dsp becomes writable (some new fragments can be written) So, what do you think happens when /dev/dsp is *always* writable (due to insufficient data from the app)? Then it'll never block.

Oct. 31, 2001

Re: audio.c converted from WaitForSingleObject to poll

by eric pouech

> The Mux takes all inputs and multiplexes them into the > circular buffer. It blocks when the buffer is full. In > the case of wine, I would guess the Mux isn't really > needed, just some function that writes into the > circular buffer, blocking if its full. no the Win32 API doesn't behave like this. queueing a buffer for playback is supposed to be non blocking so we shouldn't limit the size of the buffer > Also the buffer size is a multiple of the fragment > size of the output device. For OSS the output buffer > is split into fragments, for SBLive 16 fragments of 4K > each. again, the Win32 API doesn't put any constraints on the size of input buffers, so we need to do the split in order to fill the OSS fragments A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Oct. 31, 2001

Re: audio.c converted from WaitForSingleObject to poll

by eric pouech

Ove Kaaven wrote: > > 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...) where's the busy wait ? the code blocks on poll for two types on events - /dev/dsp becomes writable (some new fragments can be written) - a new message has been sent so the playback thread is blocked otherwise (unless I underlooked something) A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Oct. 31, 2001

Re: LockFile - any words of warning?

by Rein Klazes

On Wed, 31 Oct 2001 10:37:11 -0800, you wrote: > > > > Have a look at Corel's wine tree, where it is implemented. > > Please excuse my ignorance; how do I get at the Corel tree? Hmm, the instructions seem to have been moved off Corel's site and not reappeared at Xandra's yet. The cvs server is still working OK: export CVSROOT=:pserver:cvs(a)opensource.corel.com:/home/cvs/r cvs login (pass is "cvs") cvs co corelwine Rein. -- Rein Klazes rklazes(a)xs4all.nl

Oct. 31, 2001

RE: LockFile - any words of warning?

by Medland, Bill

Thanks, but > -----Original Message----- > From: Rein Klazes [mailto:rklazes(a)xs4all.invalid] > Sent: Wednesday, October 31, 2001 9:32 AM > To: Bill Medland > Cc: wine-devel(a)winehq.com > Subject: Re: LockFile - any words of warning? > > > On Wed, 31 Oct 2001 08:31:11 -0800, you wrote: > > > 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) > > Have a look at Corel's wine tree, where it is implemented. Please excuse my ignorance; how do I get at the Corel tree?

Oct. 31, 2001

LockFile - any words of warning?

by Bill Medland

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

Oct. 31, 2001

Re: audio.c converted from WaitForSingleObject to poll

by Paul Lorenz

Hi, I'm writing a multi-track recorder, so this is a problem I've encountered. My solution went like this. Mux in own thread, Player in own thread with circular buffer in the middle. The Mux takes all inputs and multiplexes them into the circular buffer. It blocks when the buffer is full. In the case of wine, I would guess the Mux isn't really needed, just some function that writes into the circular buffer, blocking if its full. The player reads from the buffer, blocks on empty, writes to /dev/dsp otherwise. Also the buffer size is a multiple of the fragment size of the output device. For OSS the output buffer is split into fragments, for SBLive 16 fragments of 4K each. So the player also blocks on the buffer, when there are less than fragment_size bytes available. In this model, there are no timed waits or yields, just blocks and notifies, so happily no spinlock type situations. I have all this written, unfortunately its in Java, but the concept should be translatable to C. I hope this is relevant/useful. Paul Lorenz --- Ove Kaaven <ovehk(a)ping.uio.no> wrote: > > 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...) > > > __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com

Oct. 31, 2001

Re: audio.c converted from WaitForSingleObject to poll

by Ove Kaaven

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

Oct. 31, 2001

Re: Colour problems with latest DIB fix

by Gerard Patel

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

Oct. 31, 2001

Re: Colour problems with latest DIB fix

by Gerard Patel

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

Oct. 31, 2001

Re:(no subject)

by Simon Britnell

--- Eric Pouech <eric.pouech(a)voila.fr> wrote: > 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. Didn't know I could do that. I do now :) Thanks for that. After my last post, I rampaged on ahead and converted audio.c to use poll, so that bit is now nice and unixish. I'm about to post the patch to wine-patch. __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com

Oct. 31, 2001

Re: Colour problems with latest DIB fix

by François Gouget

Gerard Patel wrote: > > 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 :-) 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? -- François Gouget fgouget(a)codeweavers.com

Oct. 31, 2001

Re:(no subject)

by Eric Pouech

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

Oct. 31, 2001

double key events

by Arjen Nienhuis

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

Oct. 31, 2001

Re: Colour problems with latest DIB fix

by François Gouget

Gerard Patel wrote: > > At 01:06 AM 30/10/2001 -0800, you wrote: [...] > > 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. 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? -- François Gouget fgouget(a)codeweavers.com Index: graphics/x11drv/dib.c =================================================================== RCS file: /home/wine/wine/graphics/x11drv/dib.c,v retrieving revision 1.81 diff -u -r1.81 dib.c --- graphics/x11drv/dib.c 2001/10/17 19:41:54 1.81 +++ graphics/x11drv/dib.c 2001/10/31 00:21:04 @@ -4644,10 +4645,6 @@ break; case 24: - descr.rMask = descr.gMask = descr.bMask = 0; - descr.colorMap = 0; - break; - case 32: descr.rMask = (descr.compression == BI_BITFIELDS) ? *(DWORD *)info->bmiColors : 0xff0000; descr.gMask = (descr.compression == BI_BITFIELDS) ? *((DWORD *)info->bmiColors + 1) : 0x00ff00; @@ -4729,10 +4726,6 @@ break; case 24: - descr.rMask = descr.gMask = descr.bMask = 0; - descr.colorMap = 0; - break; - case 32: descr.rMask = (descr.compression == BI_BITFIELDS) ? *(DWORD *)info->bmiColors : 0xff0000; descr.gMask = (descr.compression == BI_BITFIELDS) ? *((DWORD *)info->bmiColors + 1) : 0x00ff00;

Oct. 31, 2001

Re: Colour problems with latest DIB fix

by Gerard Patel

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

Oct. 31, 2001

Re: Colour problems with latest DIB fix

by Ove Kaaven

On Wed, 31 Oct 2001, Gerard Patel wrote: > 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. You may want to find out where those masks are coming from first. For example, some of the DirectDraw code in Wine doesn't set the DIB masks properly for all bit depths.

Oct. 30, 2001

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