[Ffmpeg-devel] Re: Revised os2.diff

Michael Niedermayer michaelni
Mon Apr 25 17:17:00 CEST 2005


Hi

On Monday 25 April 2005 13:08, Paul Smedley wrote:
> Hi Michael,
>
> Michael Niedermayer wrote:
> > On Monday 25 April 2005 12:21, Paul Smedley wrote:
> >>Michael Niedermayer wrote:
> >>>Hi On Saturday 23 April 2005 03:32, Paul Smedley wrote:
> >>>
> >>>
> >>>IIRC there must be no spaces before #
> >>>so
> >>>+    #ifdef CONFIG_OS2
> >>>will cause problems
> >>
> >>Hmmm it compiles OK here....
> >
> > iam not doubting that, just that it will everywhere else

seems, i didnt remember correctly


> >
> >>> >> +      // Make stdout and stderr unbuffered
> >>> >> +      setbuf( stdout, NULL );
> >>> >> +      setbuf( stderr, NULL );
> >>>
> >>>why?
> >>
> >>from:
> >>http://wiki.netlabs.org/index.php/SDL#Morph_your_program_to_a_PM_program_
> >>at _runtime
> >>
> >><Begin quote>
> >>Most SDL applications assume that they can write to STDOUT, and the user
> >>will see it. In OS/2, you have to compile your application to a PM
> >>application in order to be able to have a PM Window, but the STDOUT will
> >>go to NULL in this case. The solution is to compile your code to a VIO
> >>application, and morph the application to a PM one dynamically, at
> >>runtime, before calling SDL_Init().
> >>
> >>Once you have your text output back, you might use it for showing debug
> >>messages. If you do so, it's a good idea to make the STDOUT and STDERR
> >>unbuffered, so the debug messages will be shown right at the time when
> >>the printf() is called, so every message will be visible even in case of
> >>a crash.
> >>
> >>Here is an example code on how to morph your VIO application to a PM one
> >>dynamically, at runtime, and how to set STDOUT and STDERR unbuffered:
> >><End Quote>
> >
> > STDERR should be unbuffered by default, no clue if it is or not on os2,
> > and debug messages must not be sent to STDOUT
>
> The point is that SDL libraries on OS/2 use PM - the Presentation
> Manager gui.  PM Gui apps don't show the output to stdout or stderr
> normally.  The code is basically a hack on OS/2 only to ensure those
> messages don't get lost...
>
> Can we at least get the changes to configure checked in?  I'm not so
> fussed about ffplay as at the moment - even with the changes - ffplay
> sucks on OS/2 due to the state of the SDL port :(

well, applied the whole ...

[...]
-- 
Michael

"nothing is evil in the beginning. Even Sauron was not so." -- Elrond





More information about the ffmpeg-devel mailing list