Hello Sami,

  welcome to the project, and apologies for the late response!  I will
try to give you more timely responses in the future.

On Sat, May 31, 2008 at 07:11:21PM -0700, Sami Zerrade wrote:
> Generally, this means replacing any platform-specific calls with invocations
> of ScummVM's OSystem methods.  In some cases (video and audio drivers, for
> example), the existing abstraction allows this to be done cleanly.  It's
> presently not as clear how to proceed with file IO handling, as the existing
> code sort of assumes FILE* usage.

  To my recollection, FILE * and its API functions are standardised as
part of C89.  (FreeSCI has historically targetted C89, though we have
recently discussed migrating to C99).  Thus, FILE * is not at all
platform-specific beyond the `C89 platform'.

  However, I am not at all opposed to a migration if there is a real
problem that would be solved by that.  I would be curious to hear
about the problem first, though.

> Current suggestions include implementing a new structure to encapsulate
> FILE* pointers and ScummVM, or using two separate files that are decided
> between at compile time.

  If such a change is needed, I propose making the decision statically
(i.e., at compile time) as the dynamic approach seems to offer no
benefits but requires additional type conversions.  (For all the
practical use cases I can think of, there is no need to be able to
switch file representations at run-time).

  The easiest solution to me then seems to be the introduction of a
file abstraction API (by refactoring the existing header files) with
two underlying implementations, one relying on the one we already have
in scicore/tools.c (plus extensions as needed) and one relying on the
ScummVM mechanisms, with a flag triggering which one we use.


-- Christoph


_______________________________________________
FreeSCI-develop mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/freesci-develop

Reply via email to