On Sun, 7 Jul 2002 11:13:55 +0200, [EMAIL PROTECTED] wrote:
>> > 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?),
Hm... Compiler doesn't talk something about this.
BTW, this is pointers only problem? If I want declare such function:
function lalala(x: longint): Longint;
function lalala(x: longword): Longword;
will it be 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).
Hm... Ok. So, I must correct things like this
{$IFDEF OS2}
VAR tib:PTIB;
pib:PPIB;
{$ENDIF}
BEGIN
result:=AppQueueHandleIntern;
{$IFDEF OS2}
tib:=NIL;
pib:=NIL;
DosGetInfoBlocks(tib,pib);
IF ((tib<>NIL)AND(tib^.tib_ptib2<>NIL)AND(pib<>NIL)) THEN
IF tib^.tib_ptib2^.tib2_ultid>1 THEN //not for main thread
to
{$IFDEF OS2}
VAR tib:PTIB;
pib:PPIB;
{$ENDIF}
BEGIN
result:=AppQueueHandleIntern;
{$IFDEF OS2}
tib:=NIL;
pib:=NIL;
DosGetInfoBlocks(@tib,@pib);
IF ((tib<>NIL)AND(tib^.tib_ptib2<>NIL)AND(pib<>NIL)) THEN
IF tib^.tib_ptib2^.tib2_ultid>1 THEN //not for main thread
And comment second declaration of dosgetinfoblocks in doscalls.inc. Right?
> 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).
Ups... Sorry. My mistake. Yes, delta in -31..31 range and priority itself in 0..31.
> More comments to come... (I'm just integrating your changes into the
>FPC tree).
Ok. I'm waiting...
[cut]
>> 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?
Hm... Application type can be taken from the header of exe. But all FPC binaries
compiled as vio application.
>> 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.
Yep.
>> 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.
Hmm... Strange...
>> 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.
??? You using doscalls/pmwin like stuff but don't want use other standard things?
Strange....
> Remember the known conflict between programs using EMXLIBCM
>and EMXLIBCS (you can't run programs using EMXLIBCM and EMXLIBCS
>simultaneously) as an example.
Yes. I know (and fix is presented)
>> > 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.
Wait, wait... I don't talk about emxlibc. I'm about native libc.
-----------
To unsubscribe yourself from this list, send the following message
to [EMAIL PROTECTED]
unsubscribe sibyl
end
