From: "Yuri Prokushev" <[EMAIL PROTECTED]>
To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Date sent: Sun, 07 Jul 2002 19:30:56 -0400 (EDT)
Priority: Normal
Subject: Re: [Sibyl] first alpha of the new bsedos/doscall
Send reply to: [EMAIL PROTECTED]
> > 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.
It only appears when trying to use the functions (try compiling
FPC's dos.pas with both versions enabled in DosCalls). But - I've
found there is a workaround for this (rather simple one - shame on
me! :-( ) ; you can (of course) typecast the general pointer type
(which might result e.g. from using the '@' operator) and then it
works correctly.
> 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?
No, it is (was ;-) ) a problem just because pointers are generally
compatible with all pointer types.
> Hm... Ok. So, I must correct things like this
.
.
> And comment second declaration of dosgetinfoblocks in doscalls.inc.
> Right?
Forget it - I'll modify dos.pas in the main branch and we can keep
both prototypes then.
> >> 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.
??? What do you mean with this? Have you tried to compile e.g.
basicpm.pas with -WG? Anyway, there _is_ a solution for this
(DosQueryAppType) - see my other e-mail.
> ??? You using doscalls/pmwin like stuff but don't want use other
> standard things? Strange....
DosCalls / PMWin are _system_ libraries, not C compiler libraries!
> > 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)
Yes, I'm aware of this one. But you still can't expect every user
knows about the problem and has the fix applied.
> Wait, wait... I don't talk about emxlibc. I'm about native libc.
??? Which "native" one do you mean? Libc from VAC++?
Tomas
-----------
To unsubscribe yourself from this list, send the following message
to [EMAIL PROTECTED]
unsubscribe sibyl
end
