comparison between portability libraries?

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.
Without any claim on completeness I pick out the following.
(restricted to C)

apr: http://apr.apache.org/
the groundwork for apache and well to my knowledge at least subversion
also

nspr: http://www.mozilla.org/projects/nspr/
The groundwork for netscape, mozilla and co?

glib: http://developer.gnome.org/doc/API/2.0/glib/index.html
base for Gnome


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?

Regards
Friedrich


--
Please remove just-for-news- to reply via e-mail.

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.
> Without any claim on completeness I pick out the following.
> (restricted to C)
>
> apr: http://apr.apache.org/
> the groundwork for apache and well to my knowledge at least subversion
> also
>
> nspr: http://www.mozilla.org/projects/nspr/
> The groundwork for netscape, mozilla and co?
>
> glib: http://developer.gnome.org/doc/API/2.0/glib/index.html
> base for Gnome
>
>
> And I guess there are quite a lot of others available out there.

The cross platform scripting languages provide a fair bit of this
functionality - I know Tcl does, Python and Ruby probably do as well.

Sounds like an interesting basis for an article.

--
David N. Welton
- http://www.dedasys.com/davidw/

Linux, Open Source Consulting
- http://www.dedasys.com/

Friedrich Dominicus wrote:
> "David N. Welton" <davidw@dedasys.com> writes:
>
>
>>The cross platform scripting languages provide a fair bit of this
>>functionality - I know Tcl does, Python and Ruby probably do as
>>well.
>
> Well I could not agree more, but my question was about C libraries and
> not scripting languages. But let me jump on you suggestion
> nevertheless.
>
> AFAIK does Tcl run on any Unix, Windows, Mac and probably more, but
> they do have implemented the things they need within their source ball
> but not used e.g one of the "portable libraries". Well agreed it's
> probably older but even in new languages I can not remember having
> seen use of such C portability libraries.
>
> Well the all expose a C interface so to some extend one can get a
> handle back into the implemented stuff, but that's quite a way.
> call an embedded Interpreter access the interface to use something to
> do the work in C ;((((

With Tcl, at least, you could probably use a fair amount of the C
interface without even instantiating the interpreter, but your point is
still valid - it's primarily intended as a programming language in any
case. Think of it as a portability library with a handy programming
language tacked onto it:-)

--
David N. Welton
- http://www.dedasys.com/davidw/

Linux, Open Source Consulting
- http://www.dedasys.com/

"David N. Welton" <davidw@dedasys.com> writes:

>
> The cross platform scripting languages provide a fair bit of this
> functionality - I know Tcl does, Python and Ruby probably do as
> well.
Well I could not agree more, but my question was about C libraries and
not scripting languages. But let me jump on you suggestion
nevertheless.

AFAIK does Tcl run on any Unix, Windows, Mac and probably more, but
they do have implemented the things they need within their source ball
but not used e.g one of the "portable libraries". Well agreed it's
probably older but even in new languages I can not remember having
seen use of such C portability libraries.

Well the all expose a C interface so to some extend one can get a
handle back into the implemented stuff, but that's quite a way.
call an embedded Interpreter access the interface to use something to
do the work in C ;((((

So at least in this languages the implementors have written all this
portability stuff.

Regards
Friedrich


--
Please remove just-for-news- to reply via e-mail.

On 2006-02-16, Friedrich Dominicus <just-for-news-frido@q-software-solutions.de> 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.
> Without any claim on completeness I pick out the following.
> (restricted to C)
>
> apr: http://apr.apache.org/
> the groundwork for apache and well to my knowledge at least subversion
> also
>
> nspr: http://www.mozilla.org/projects/nspr/
> The groundwork for netscape, mozilla and co?
>
> glib: http://developer.gnome.org/doc/API/2.0/glib/index.html
> base for Gnome


lcl: http://lazarus.freepascal.org
- groundwork for Lazarus. Delphi like environment.

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

Books about comparisons are usually old at the moment they are printed.

Marco van de Voort <marcov@stack.nl> writes:

>>
>> Wouldn't you find it useful to get access to such things?
>
> Books about comparisons are usually old at the moment they are
> printed.
Well it haven't to be a comparison but a sort detailed
instruction, or maybe a theme like "building portable applications
with..."

Well I disagree a bit with the term "old". It seems you argue that's
you can not "recognice" things in newer version. I would argue the
stuff in there is quite stable because it is used since years now.

E.g I would expect the apr people beeing very cautious on changing
exsiting APIs, the mark them deprecated but still carry them around
(however I not know for how long) and I bet the implementors of the
actual mozilla (or however it is called currently) won't be very happy
to see that the API changes beyond recognition from one version to
another.

The only book I know of which treats a portable library (to some
degree and well with quite a few unfounded remarks about C is
'The official Gnome 2 Developer's Guide'


Regards
Friedrich



--
Please remove just-for-news- to reply via e-mail.

In article <87vevfs5ky.fsf@flarge.here>, 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.

Other applications may use that library as a starting point
for their own portability but will very quickly run into
other portability issues that did not affect the original
program. They will either create their own version of the
library and probably not feed the changes back to the
original (the original team having little incentive to
accept changes not applicable to their own use).

It maybe useful to have a book that took many of these
"portability' libraries and compared the various solutions
to the same problems, but I suspect that unless you'd been
involved in writing such a library the purpose for some of
the choices would be opaque to you.

I've been involved in several large applications that were
or became portable across platforms, the "portability"
libraries shared very little in common.

--
Andrew Nicholson <andrewn@lesto.com> http://lesto.com/andrewn/
"Fear leads to anger. Anger leads to hate. Hate leads to using Windows
NT for mission-critical applications." -- What Yoda *meant* to say
-- Devin L. Ganger

On 2006-03-30, Andrew Nicholson <andrewn@lesto.com> wrote:
> 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.

That can be seen in two ways:

1) the application specific libraries are not designed portable.
2) libc is such a small subset that it is pretty much irrelevant to base on
for non trivial apps.

"Andrew Nicholson" <andrewn@lesto.com> wrote in message
news:slrne2nvr5.q60.andrewn@luggage.home.lesto.com ...
> In article <87vevfs5ky.fsf@flarge.here>, 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...

well what's your opintion about diverse offers then?
- libapr
- libcurl
- libxml2
- libpcre
- glut
- glib
- libssl (eay)
- other you name them


That's the point I checked out quite few libraries and liked quite a
few and dislike a few other, however that really is problemetic is
finding which shows how to use them.

For your example of File I/O. Have you tried what libapr offers in
that area? Or glib? or something else?

Regards
Friedrich

--
Please remove just-for-news- to reply via e-mail.

"Friedrich Dominicus" <just-for-news-frido@q-software-solutions.de> wrote in
message news:87sloxeha6.fsf@flarge.here...
> well what's your opintion about diverse offers then?

> - libapr
> - libcurl
> - libxml2
> - libpcre
> - glut
> - glib
> - libssl (eay)

most of these offer functionality that is imo a minor issue to implement...

for something as simple as xml parsing, regexps, ... why risk a library
dependency?...

> - other you name them
>
>
> That's the point I checked out quite few libraries and liked quite a
> few and dislike a few other, however that really is problemetic is
> finding which shows how to use them.
>
> For your example of File I/O. Have you tried what libapr offers in
> that area? Or glib? or something else?
>
not really, then again, I doubt they will do me much good, as for anything
one uses an external lib for, they need to make sure that lib is available.

I personally dislike using any external libraries, especially since most
encompass minor functionality anyways.

my preference is, instead, to do things like this myself.


sure, if my project has around an extra 100-200 kloc or so in basic utility
code, then maybe that is a little much, but no big loss...


for example, I don't use zlib, or libpng, or libjpg, or much else along
these lines, because, I wrote the loaders myself...

no need for dependencies for minor features. if you can do it yourself, you
can save a dependency, and a little more space on the linker's command
line...

most of these features are small, eg:
file io (core) 431 loc;
file io (directory fs type), 186 loc;
deflater, 810 loc;
inflater, 646 loc;
jpg decoder, 659 loc;
png loader, 588 loc;
xml parser/printer code (DOM-style), 1.72 kloc;
xml parse tree management code, 950 loc;
....

all of these are not all that much work to write really (if spread over a
period of time).


most of my dependencies are on things I can't do myself, eg, the win32 api,
winsock, opengl, ... which I instead try to constrain, and put behind custom
apis.

these are what I constrain whenever possible (ok, excepting opengl, which
would be easier to mock up later than to constrain...).

> Regards
> Friedrich
>
> --
> Please remove just-for-news- to reply via e-mail.

On 2006-04-01, cr88192 <cr88192@NOSPAM.hotmail.com> wrote:
>
>> - libapr
>> - libcurl
>> - libxml2
>> - libpcre
>> - glut
>> - glib
>> - libssl (eay)
>
> most of these offer functionality that is imo a minor issue to implement...
>
> for something as simple as xml parsing, regexps, ... why risk a library
> dependency?...

There can be a difference between doing the minimal thing, and the right
thing. E.g. in the XML case, accepting the full spec of e.g. an XML
standard, unicode input etc. In the SSL case security, in the glut case
possible replacement with proprietary drivers resulting in tremendous
performance gain. zlib (mentioned below) also was a security risc a few
times, when used for protocol compression. And then I comment on _your_
list, and name examples purely from memory.

I'm myself weary about adding useless dependancies too, but one must not
then also go the full mile in creating the substitute, and not doing a
naieve implementation on the level like every school-boy does.

Time is of course also a factor. The larger and more complicated libs take
way longer to duplicate.

> xml parser/printer code (DOM-style), 1.72 kloc;
> xml parse tree management code, 950 loc;

I'm mister Dombo customer. I receive an XML file that I edit in notepad, and
that file contains a few odd characters because it also has the chinese
translation in it. Notepad, stupid as it says suggests to save it as unicode
(16-bit UCS2ish) and I don't see it. Now I feed it to your program with
custom parser. What happens? Will it die horrible the first time it has a #0
in the input? Will it issue a proper warning?

What if I use 2048 char tags or so ? (no theoretic case, I really had a
customer, a pretty smart one even, that coded stuff in the identifiers)

"Marco van de Voort" <marcov@stack.nl> wrote in message
news:slrne2u23u.1gd6.marcov@snail.stack.nl...
> On 2006-04-01, cr88192 <cr88192@NOSPAM.hotmail.com> wrote:
>>
>>> - libapr
>>> - libcurl
>>> - libxml2
>>> - libpcre
>>> - glut
>>> - glib
>>> - libssl (eay)
>>
>> most of these offer functionality that is imo a minor issue to
>> implement...
>>
>> for something as simple as xml parsing, regexps, ... why risk a library
>> dependency?...
>
> There can be a difference between doing the minimal thing, and the right
> thing. E.g. in the XML case, accepting the full spec of e.g. an XML
> standard, unicode input etc. In the SSL case security, in the glut case
> possible replacement with proprietary drivers resulting in tremendous
> performance gain. zlib (mentioned below) also was a security risc a few
> times, when used for protocol compression. And then I comment on _your_
> list, and name examples purely from memory.
>
yeah, maybe not the best code, but then again, my code will build, vs.
endless (typically linux written apps) which are a total pain to make build
on windows, or vice versa.

typically, the apps will depend on endless trivial libs, many of which are
not present, eg, on cygwin or mingw.

worse yet, the app may be largely based around some toolkit library that
can't itself be gotten for windows, or is proprietary, or whatever.

better to not depend on anything.


> I'm myself weary about adding useless dependancies too, but one must not
> then also go the full mile in creating the substitute, and not doing a
> naieve implementation on the level like every school-boy does.
>
> Time is of course also a factor. The larger and more complicated libs take
> way longer to duplicate.
>
yeah.

the newer inflater, deflater, and png code took several days to implement;
likewise went for the jpeg decoder (took 3 days, slowed by mass skimming of
the T.81 spec trying to resolve various aspects of the format, it should
decode baseline images, but not much else).

>> xml parser/printer code (DOM-style), 1.72 kloc;
>> xml parse tree management code, 950 loc;
>
> I'm mister Dombo customer. I receive an XML file that I edit in notepad,
> and
> that file contains a few odd characters because it also has the chinese
> translation in it. Notepad, stupid as it says suggests to save it as
> unicode
> (16-bit UCS2ish) and I don't see it. Now I feed it to your program with
> custom parser. What happens? Will it die horrible the first time it has a
> #0
> in the input? Will it issue a proper warning?
>
it will probably not parse write. some syntax checking is done, so either it
will parse a single char and think that was the whole file, or endlessly
think the file is truncated (consistently returning a NULL result).

> What if I use 2048 char tags or so ? (no theoretic case, I really had a
> customer, a pretty smart one even, that coded stuff in the identifiers)
>
this is a worse problem. my parser code uses a rotating buffer for holding
tokens being parsed/..., however, for each token it only grabs 256
characters, and for text areas it grabs 64kB (actual allocator this time).
for each attribute, the limit for the value is 4kB.


more recently, in a memory saving effort I ended up making my internal
strdup-style function merge strings. this was partly to save memory, and
partly to help trying to track down an apparent memory corruption bug. this
is ok, because in my code, I more or less never directly modify "literal"
strings, eg, my style demends that I copy any too-be modified string into a
buffer, where it is then modified, and then potentially duplicated for the
new on-heap version or whatever (string duplication is done almost
habitually in many places, as it is figured that most likely the string is
stored in either a temporary buffer or in the 'text' section).

all this payed off some imo. the string merging, however, puts in only minor
effort, and may miss some duplicates (primarily due to hash collisions with
other strings and similar). better that it go fast though, as string
duplication is really rather frequent. at least frequent strings should
merge pretty well...

"cr88192" <cr88192@NOSPAM.hotmail.com> writes:

> "Friedrich Dominicus" <just-for-news-frido@q-software-solutions.de> wrote in
> message news:87sloxeha6.fsf@flarge.here...
>> well what's your opintion about diverse offers then?
>
>> - libapr
>> - libcurl
>> - libxml2
>> - libpcre
>> - glut
>> - glib
>> - libssl (eay)
>
> most of these offer functionality that is imo a minor issue to
>implement...
Ok, let's see

glib contains code for all kind of data structures, an minor issue to
implement?

libssl offers minimal functionality?

libcurl just contains code for handling all kind of download problems
>
> for something as simple as xml parsing, regexps, ... why risk a library
> dependency?...
Why writing such code yourself? I would really like to see you regular
expression matching code.
>>
> not really, then again, I doubt they will do me much good, as for anything
> one uses an external lib for, they need to make sure that lib is
> available.
So what why is that a problem?
>
> my preference is, instead, to do things like this myself.
you may have enough time at you hands
>
>
> sure, if my project has around an extra 100-200 kloc or so in basic utility
> code, then maybe that is a little much, but no big loss...
Not big loss? Interesting how much time have you spend to write such
code and how many errors have you found.
>
> most of these features are small, eg:
> file io (core) 431 loc;
Portable between?

I see your points.

Regards
Friedrich


--
Please remove just-for-news- to reply via e-mail.

"Friedrich Dominicus" <just-for-news-frido@q-software-solutions.de> wrote in
message news:8764lssc2r.fsf@flarge.here...
> "cr88192" <cr88192@NOSPAM.hotmail.com> writes:
>
>> "Friedrich Dominicus" <just-for-news-frido@q-software-solutions.de> wrote
>> in
>> message news:87sloxeha6.fsf@flarge.here...
>>> well what's your opintion about diverse offers then?
>>
>>> - libapr
>>> - libcurl
>>> - libxml2
>>> - libpcre
>>> - glut
>>> - glib
>>> - libssl (eay)
>>
>> most of these offer functionality that is imo a minor issue to
>>implement...
> Ok, let's see
>
> glib contains code for all kind of data structures, an minor issue to
> implement?
>
can't see what would be that hard.

maybe daunting, if one wants to implement everything, but one can implement
what they need, and thus need to implement less.


consider as a simple case, a hash table. I use these things all the time,
but I have pretty much never made any centralized code for them. why?
becuase, they are trivial to a point of not even needing to reuse the code.
the exact algo (hashing function, lookup and insertion behavior, ...) can be
varied for the particular use, but it is no big deal.

linked lists, are the same way. they can either be implemented in the
structures themselves, or externally (as in glib, lisp, ...). again, the
code is no big deal.

likewise with most of the other things there.


> libssl offers minimal functionality?
>
well, this is bending what I had said. I said "minor issue to implement" not
"minimal functionality". something can be easy to implement, and do a whole
lot, or be hard to implement, and do little.

encryption is not impossible to implement. sufficiently detailed
descriptions are not that hard to find.

libssl, however, is one where I might consider just using the library
(reason: a lot of algos are needed to be able to really negotiate).

concievably, one could do their own and only support, say, rc4, but the
security wont be there, and it won't work if, for whatever reason, the other
end doesn't know about rc4.


> libcurl just contains code for handling all kind of download problems

yeah.

http is not that complicated of a protocol either. I did this myself once
before (writing both the client code and a server).

likewise, back when I wrote an os, I did all my own network code, and also
built the webserver into my kernel. however, the problem was my os's tcp
code was horridly slow, making using tcp for much of anything an unpleasant
task (part of my problem here was that I took a very questionable approach
to designing my network stack, eg, basing it around a number of
communicating threads, and putting the speed at which data flows at the
mercy of the scheduler...).

>>
>> for something as simple as xml parsing, regexps, ... why risk a library
>> dependency?...
> Why writing such code yourself? I would really like to see you regular
> expression matching code.

in my case, I never really needed regexps, so I haven't implemented them. as
for other manner of parsing tasks (mostly c-style parsers, other customized
parsers, ...), have wrote enough of these.

>>>
>> not really, then again, I doubt they will do me much good, as for
>> anything
>> one uses an external lib for, they need to make sure that lib is
>> available.
> So what why is that a problem?

because, it is.

I personally get rather annoyed by software that I can't build because it
depends on libs which I can't get to build, or may in turn depend on other
libs that fail to build.

the software, in this case, often may as well not exist...

it is often easier to throw together one's own app than to try to understand
someone else's codebase enough to modify it so that it will work.

>>
>> my preference is, instead, to do things like this myself.
> you may have enough time at you hands
>>
>>
>> sure, if my project has around an extra 100-200 kloc or so in basic
>> utility
>> code, then maybe that is a little much, but no big loss...
> Not big loss? Interesting how much time have you spend to write such
> code and how many errors have you found.

haven't kept track of errors count, if anything, probably some huge
number...

my projects have been created over a number of years of fairly consistent
coding effort. a lot of it depends, eg, how much weight one would put on,
say, a years worth of coding (maybe a year coding on average for about 4
hours/day). this would be about 1460 hours, and for 100 kloc, one only has
to write about 68 loc/hr. this is a fairly light pace really.

now, it is rarely so even, more often it is maybe a few days without writing
much of anything, then maybe sitting around and writing a few kloc in a
single sitting (probably somewhere around 4-8 hours), followed by a lot of
time of writing code in smaller pieces, ...

most of the time is sat around pointlessly trying to think up what I am
going to do next, much more than is actually spent coding. writing misc code
(often to eliminate some annoying dependency, or improve on something
pre-existing) often can serve as a useful distraction, followed by making
actual progress once some issue has been resolved (or, I get around to
it...).

looking at it up front, that may seem scary, in retrospect (after the code
has been written already), it is no big deal. if I had to do it all again,
maybe I would have second thoughts, luckily I don't have to, so I can use
what I have written before.

>>
>> most of these features are small, eg:
>> file io (core) 431 loc;
> Portable between?
>
pretty much anything, this code is self-contained.
the one just below it (directory fs code), uses mostly ansi c, and a few
posix calls (stdio stuff, stat, opendir/readdir, ...).

most of the rest of the code is pretty much self-contained.

> I see your points.
>


> Regards
> Friedrich
>
>
> --
> Please remove just-for-news- to reply via e-mail.