From: "Yuri Prokushev" <[EMAIL PROTECTED]>
To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Date sent: Sun, 07 Jul 2002 11:27:38 -0400 (EDT)
Priority: Normal
Subject: Re: [Sibyl] first alpha of the new bsedos/doscall
Send reply to: [EMAIL PROTECTED]
> > 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..
OK, fine. Anyway - those two versions of DosGetInfoBlocks can't be
supported at the same time (I seem to remember I already told you
about this problem?), so you'll have to comment the other (Sibyl
compatible?) and modify the calls within the IDE once the porting is
done. Your version doesn't make it possible to pass one pointer as
null (in case you only need one of those two information blocks).
The comment about Delta before the DosSetPriority call was correct
(and your is not!) - the _resulting_ priority must be in 0..31 (as it
appears in DosCalls). The _Delta_ values must be in -31..31 (I'm
adding this to DosCalls to avoid any possible misunderstanding in the
future).
More comments to come... (I'm just integrating your changes into the
FPC tree).
> > 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???).
Yes, I think so as well.
> But still problem with AppHandleIntern (Which initialized
> only for pm applications by InitPM call) and with ApplicationType
> which initialized by compiler (=1 for PM).
It should be possible to recognize this without "compiler magic"
somehow, shouldn't it?
> And I don't know at&t asm.
> So this work not for me.
I can try to do the translation myself, if needed (I don't know the
AT&T syntax very well either, but can do something and ask about the
rest). The main question is, where it will be stored. I'd probably
prefer moving it to the initialization routines.
> 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
The same is true for many other routines, and every platform. In
spite of this we (FPC) decided to avoid using libc after a thorough
discussion.
> 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}
No. Take it this way - we distribute a compiler (with a RTL). We are
expected to deliver as bugfree product as possible (this includes all
functions in our interface routines - including versions compiled
with supported IFDEFs). But we can't guarantee anything if we use 3rd
party products, and can't fix possible incompatibilities ourselves
either. Remember the known conflict between programs using EMXLIBCM
and EMXLIBCS (you can't run programs using EMXLIBCM and EMXLIBCS
simultaneously) as an example.
> > 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.
Yes, that (common use from more than program) is what I'm talking
about. BTW, the libc DLL size counts as well in your example, so
you're in (almost) exactly the same situation (with the "splitted
file"). Why do presume every Warp 4 user must have full EMX runtime
installed? This is only true under eComStation, IMHO! It's clear
really _many_ OS/2 users have full EMXRT installed now, but it
doesn't mean the same is true for everybody.
Tomas
-----------
To unsubscribe yourself from this list, send the following message
to [EMAIL PROTECTED]
unsubscribe sibyl
end
