On Sun, 7 Jul 2002 19:30:21 +0200, [EMAIL PROTECTED] wrote:
>> > I (and the other FPC core team members) don't. DosCalls and PMWin
>> >form parts of the OS/2 API. Libc doesn't. Some libc is distributed on
>> > almost all platforms nowadays, but that doesn't change anything on
>> >the fact it still isn't a system library. You can have several libc
>> >versions running on top of one system (in the case of OS/2 there's
>> >EMX, VACPP, Watcom, Borland, ...).
>> Yes, I can. But such libcs not part of os. In our case libc is a part
>> of standard distribution and I don't see any logical problems (instead
>> of system independed implementation of routines) with usage of such
>> libs
> That's exactly the same as with, say, Linux.
Yep.
>> >files distributed together with OS/2. In addition to what I wrote
>> >above, these files aren't available on OS/2 Warp 3.0 at all as you
>> >noted yourself.
>> Well. Warp 3 not so widely used. And bacause I added condition instead
>> of direct implementation of libc calls.
> OK, but the distributed (precompiled) version has to be compatible
>with Warp 3. Given the fact that most users don't recompile RTL,
>you'd end up on working on something hardly ever used. But you'd
>still have to test it, fix it, etc.
Well. It is possible to distribute 2 precompiled version. With libc usage and without.
>> >BTW, how much code would you really save if using
>> >these?
>> At least strings operations (val/str/trim etc), random/randomize,
>> threads control, file operations, regexps, lot of mathematic
>> functions, date/time, stream io, memoru operations and few other. This
>> is at least strings/sysutils/math units. It is hard to predict saved
>> space. May be not so much.
> You'd still have to write some wrappers around them to make any use
>of them in RTL, because most RTL functions don't correspond directly
>to libc functions. The result is a slower program.
May be. But this is usual -> smaller program = slower program. And I consider most of
functions can be used directly, without big wrapper.
>> >Do you think it's really worth the trouble with creating and
>> >maintaining two versions of RTL functions?
>> I think, no. And this is interesting for me. Also allows easely port C
>> programs.
> The only thing you'd need for easier porting of C programs is an
>interface unit for libc. Such a thing would be needed for e.g. Kylix
>compatibility anyway, but that's a different story. Using libc
>function in our own RTL doesn't make porting from C any easier, IMHO.
Yep. Using libc in RTL doesn't make thing easier. But _having_ libc make porting easer.
-----------
To unsubscribe yourself from this list, send the following message
to [EMAIL PROTECTED]
unsubscribe sibyl
end
