On Sat, 6 Jul 2002 13:15:56 +0200, [EMAIL PROTECTED] wrote:
>> First alpha of the new bsedos/doscalls commited...
> I've shortly looked at it. I appreciate you have listed corrections
>to FPC sources in a standalone file, that will definitely help in
>integrating them into FPC 1.0.x RTL. I have a slight problem with the
>new files, though - I probably wouldn't like to commit them to the
>FPC RTL with those {$IFNDEF FPC} and {IFDEF OVERLOADSUPPORTED}, etc.
>directives. Do you think it can be solved somehow? Or should I take
>it it's just a temporary solution until you have everything moved
>from SPCC to FPC and these will only be modified for FPC only and
>committed to the FPC CVS tree afterwards?
Various IFDEFs is temporary until we finish porting to FPC. OVERLOADSUPPORTED and
IFDEF FPC(or something like) will be removed after succes compilation of
Sibyl by FPC..
> Regarding SysSibyl contents - if you only need this initialization,
>then we could probably integrate it in the System unit. The get
>thread ID routine should either go to the new prt0.as for the native
>OS/2 RTL target (and be rewritten to AT&T assembly and directly use
>FS: instead of the DB helper; probably preferred solution), or use
>the appropriate OS/2 API call to remove FS contents dependance (it
>doesn't matter within the prt0 loader, but I'd prefer to avoid it in
>Pascal code).
I'm not sure about this routines as yet. AppHandle can be replaced by var instead of
function (why execute one code for each function call???). But still problem with
AppHandleIntern (Which initialized only for pm applications by InitPM call) and with
ApplicationType which initialized by compiler (=1 for PM). And I don't know at&t asm.
So this work not for me.
> I'm not sure what you plan to do with "USE_LIBC" conditional
>(rtlconfig.inc), but we (FPC team) have agreed to not use libc in FPC
>RTL for whatever target (the universal POSIX target for otherwise
>unsupported Unix platforms might be the only exception to this).
I'm planning to use C functions instead of FPC implementations if USE_LIBC defined.
This is subject to discuss. But, as example, lot of code in strings unit already
presented in LIBCM.DLL(LIBCS.DLL). Why not use this code? I don't agree with rejecting
libc. Yes, dependance on libc is bad, but don't make libc only routines. Do
something like this:
function val: integer;
{$ifdef use_libc}
...
.... {lot of independed code}
....
{$else}
result:=libc_val;
{$endif}
> You can achieve smaller binary sizes by creating our own DLL with FPC RTL
>once DLL creating is ready for FPC.
:) spliting one file to two don't make program smaller. But this is also solution if
:more than one program.
-----------
To unsubscribe yourself from this list, send the following message
to [EMAIL PROTECTED]
unsubscribe sibyl
end
