On Sun, 7 Jul 2002 15:28:41 +0200, [EMAIL PROTECTED] wrote:
>> > 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).
I understand.
>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.
Great.
>> >> 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?
Grr... In docs no any info (this option documented as win32 target). After compilation
I used emxbind .... -s -p for PM apllication :). Ok. Now all ok.
> Anyway, there _is_ a solution for this
>(DosQueryAppType) - see my other e-mail.
Yes. I see...
>> ??? You using doscalls/pmwin like stuff but don't want use other
>> standard things? Strange....
> DosCalls / PMWin are _system_ libraries, not C compiler libraries!
I consider any library is system if distributed with OS.
>> > 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.
Of couse, but I don't talk about emxlibc (see bellow)
>> Wait, wait... I don't talk about emxlibc. I'm about native libc.
> ??? Which "native" one do you mean? Libc from VAC++?
LIBCM/LIBCS in os2/dll.
------------------
The C-runtime DLL's shipped with OS/2 V4.0 (and above) are XPG4
compliant. They are based upon the source code to the VisualAge
C++ rutimes, but are modified to use OS/2 internationalization.
The DLL's in question are:
\OS2\DLL\LIBCM.DLL - Multi-threaded library
\OS2\DLL\LIBCS.DLL - Single-threaded library
\OS2\DLL\LIBCN.DLL - Subsystem library
-----------------
-----------
To unsubscribe yourself from this list, send the following message
to [EMAIL PROTECTED]
unsubscribe sibyl
end
