Re: comparison between portability libraries?


"Andrew Nicholson" <andrewn@xxxxxxxxx> wrote in message
news:slrne2nvr5.q60.andrewn@xxxxxxxxxxxxxxxxxxxxxxxxx
In article <87vevfs5ky.fsf@xxxxxxxxxxx>, Friedrich Dominicus wrote:
Well it seems I'm off-topic for comp.lang.c and off topic in specific
groups also, so I try my luck here. As you probably know there do
exist quite a few portability libraries for applications on different
platforms.
[ ... examples removed ... ]
And I guess there are quite a lot of others available out there.

Now I can not remember having read about a comparison, well even the
usage is mostly in the dark AFAIKT. I wonder if I were too dump to
find something about that of that such things are still not there?

AFAIKT there is not current book which deals with libraries like that
or others. Does anyone know something else?

Wouldn't you find it useful to get access to such things?

Many of these large "portable" applications create their own
library which is replaced on each platform. The API for these
libraries tend to only be useful for the specific application
with very little thought to completeness.

There's a huge difference between a truly portable library
API (e.g. libc) and one used to achieve portability for a
particular application that only needs to abstract certain
features of each environment/OS for that program.


yeah, imo it is good to constrain most of the os-specific code to small
controlled areas, making an api (or often patching into another api) that
the rest of the app can use. this api not very useful to other apps, but it
is for the app being written. in these cases, os dependent parts of the app
can be replaced fairly easily, rather than making porting a more major task
of altering a lot of the codebase.

some things are wrapped more though just because doing so is useful, eg, the
filesystem interface. it is often useful (in my experience) to be able to
manage the filing system as one sees fit, rather than just using the os and
having little control (this is particularly useful for managing app data,
which may all be kept under a single conceptual root, which may in turn be
mapped to multiple os directories, be partly comprised by zipfiles, ...).

then again, people will sometimes debate whether I "need" to do my own fs
management, I will argue that, in comparison, the "conventional way" is a
major pita (managing paths directly).

as such, "my way" is typically very similar, often my calls differ from the
os calls by a few letters. copy/replace teqniques of changing between many
os calls and my custom api's is convinient, and sometimes clones of the apis
are implemented (interfacewise equivalent, sometimes direct wrappers for the
os calls, sometimes a different manner of wrapped machinery).

in any case, for a simple app, just using eg, stdio files, makes sense (just
like using malloc/free, ... also makes sense here). for a less trivial app,
doing things one's own way is more convinient in my experience.


other crap to wrap is more generic:
window creation, input management, setting up gl, dealing with the
soundcard, ...

the app itself becomes a set of frontends and a number of statically linked
libraries (used for dealing with the only semi-centralized building and
masses of object files floating around).

....


a fully neutral api that does all I would need would be nice, but none
exists. in my case, pieces are not good enough. getting various unrelated
libs to play together nicely is imo problematic (each lib wants to think it
is the center of the apps' world, rather than "just another piece"). one
ends up needing to control nearly everything to make things play together
nicely. likewise, each lib is also often sub-desirably portable as well.


and such...


.

Relevant Pages

  • Re: Implementation question
    ... I would like to make available to libraries, ... > portable as possible (communication between library and app). ... > I first had in mind of using an "array of array of string", ... portability, provide code to access the data structure and return simple ...
    (comp.lang.pascal.delphi.misc)
  • VB app needs to call C API
    ... Our client has a VB app. ... We offer an API that is C libraries (api.lib, ... create DLLs, then call the DLLs from VB? ...
    (microsoft.public.vb.general.discussion)
  • Re: learning asm.
    ... No need to apologise...I'm so all over the place myself with posts ... problem...such libraries are monsterous and lead to _more complex_ ... "portability" actually isn't needed or a desirable attribute then this ... loader-time to make, I suppose, a "custom jump table" for that program ...
    (alt.lang.asm)
  • Re: <ctype.h> toLower()
    ... I think you are confusing portability with binary compatibility. ... to be CPU specific. ... compiler and thencan specify the machine type. ... >> Object libraries are definately platform specific. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: A small cooking experiment
    ... which library clients need changes when you reorganize the libraries. ... Libraries that are designed to provide that same interface (e.g., ... Source files rarely exist in isolation, ... But portability is far from being the sole reason why users ...
    (comp.lang.prolog)