Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2006-03

connecting with Delphi (object files,dll etc)

6 messages · 5 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Пётр Косаревский

I have a question concerning connecting FreePascal function with Delphi application (under win32).

I hope I'm totally wrong in my approach and so hope for some help.

1. DLL files created by FPC 2.0.2 are not usable under Delphi forms (there are about 5 posted unfixed bugs about it by different persons). (But they work, e.g. when you use FPC-FPC.)

2. Of course, rewriting source to be Delphi compatible is poor option: it requires some work and gets slow working program (I want (have) Delphi frontend for intensely calculating FPC console program/unit/library).

3. Connecting object file is difficult: FPC doesn't support OMF (object files), and in FPC 2.0.2 support for COFF (object files) seems to be dropped. FPC produces PECOFF (object files). Sometimes you can translate COFF to OMF by (free?) Borland utility COFF2OMF, but it's not well documented: FPC *.o files are not translated, and I don't know the exact reason (is it their PECOFFness or some other incompatibility? maybe I just use them in a wrong way?).

If this approach (DLL or object files) is despairing, I add a few words about two other methods...

4. Pipes are nice when you redirect stdout of some utility to file, but are pretty unclearly documented (yes, I do grow my hands from behind and can't get them to work stable for Delphi-FPC pair with bidirectional information flow).

5. The last approach is freaky: just run one application from the other and exchange information via named file on disk.

Can anybody suggest something on one of this method? Can anybody suggest some other way of program to program communication of Delphi-FPC?

Michael Van Canneyt
to Пётр Косаревский
???? ??????????? wrote 7 lines
4. Pipes are nice when you redirect stdout of some utility to file, but are pretty unclearly documented (yes, I do grow my hands from behind and can't get them to work stable for Delphi-FPC pair with bidirectional information flow). 5. The last approach is freaky: just run one application from the other and exchange information via named file on disk. Can anybody suggest something on one of this method? Can anybody suggest some other way of program to program communication of Delphi-FPC?

Send Windows COPY messages. dbugintf works on this principle, and works fine.

But the DLL stuff should be fixed.

Michael.

Peter Vreman
to Пётр Косаревский: I have a question concerning connecting FreePascal function with Delphi application…
Show quoted text 8 lines
I have a question concerning connecting FreePascal function with Delphi application (under win32). I hope I'm totally wrong in my approach and so hope for some help. 1. DLL files created by FPC 2.0.2 are not usable under Delphi forms (there are about 5 posted unfixed bugs about it by different persons). (But they work, e.g. when you use FPC-FPC.)

These are then mostly things not directly needed/interressed by the core developpers. We do it for fun so it can be that some complex issues likes this stay open for a long time.

2. Of course, rewriting source to be Delphi compatible is poor option: it requires some work and gets slow working program (I want (have) Delphi frontend for intensely calculating FPC console program/unit/library).

You can rewrite the frontend in Lazarus.

Show quoted text 7 lines
3. Connecting object file is difficult: FPC doesn't support OMF (object files), and in FPC 2.0.2 support for COFF (object files) seems to be dropped. FPC produces PECOFF (object files). Sometimes you can translate COFF to OMF by (free?) Borland utility COFF2OMF, but it's not well documented: FPC *.o files are not translated, and I don't know the exact reason (is it their PECOFFness or some other incompatibility? maybe I just use them in a wrong way?).

This is not correct. COFF is support, it is the object format of go32v2. Ofcourse is this not supported for the win32 target. Just like ELF is not supported for win32.

Show quoted text 10 lines
If this approach (DLL or object files) is despairing, I add a few words about two other methods... 4. Pipes are nice when you redirect stdout of some utility to file, but are pretty unclearly documented (yes, I do grow my hands from behind and can't get them to work stable for Delphi-FPC pair with bidirectional information flow). 5. The last approach is freaky: just run one application from the other and exchange information via named file on disk.

TCPIP Sockets?

Marco van de Voort
to Peter Vreman
Show quoted text 11 lines
> 3. Connecting object file is difficult: FPC doesn't support OMF (object > files), and in FPC 2.0.2 support for COFF (object files) seems to be > dropped. FPC produces PECOFF (object files). > Sometimes you can translate COFF to OMF by (free?) Borland utility > COFF2OMF, but it's not well documented: FPC *.o files are not translated, > and I don't know the exact reason (is it their PECOFFness or some other > incompatibility? maybe I just use them in a wrong way?). This is not correct. COFF is support, it is the object format of go32v2. Ofcourse is this not supported for the win32 target. Just like ELF is not supported for win32.

Note that coff2omf will probably not save you anyway due to name mangling issues. (which might also be the reason for the dll trouble?)

Пётр Косаревский
to Florian Klaempfl
Florian Klaempfl wrote
Пётр Косаревский wrote: > 3. Connecting object file is difficult: FPC doesn't support OMF (object files), and in FPC 2.0.2 support for COFF (object files) seems to be dropped. FPC produces PECOFF (object files). FPC supports OMF by using NASM/MASM/TASM as assembler (e.g. -Amasm).

Oh.

I tried several assemblers (nasm-wasm and masm=renamed ml, MS assembler). I didn't use special options, but masm and wasm didn't compile, and nasm(win32) generated GPF-ing .exe (in program mode). In all three modes program without asm usage worked (by itself or by calling function from dll/unit).

(I didn't post it as FPC bug, because I'm not using these tools regularly and don't want to prove or falsely proclaim FPC guilt.)

I had some issues (both in unit, library and program modes):

MASM (ML, version 7.10.3077)
(minor) constant strings contained symbols from 128-255 region (russian text used for debugging messages) and were converted into too long strings (not really long: no more than 320 symbols in my case) (by the way, using crt (i know it's legacy stuff) converts such symbols into '?', and so do mailers of many posters: Florian was rare one to save my russian name (unreadable by many)) (fatal for me) (line 18465 [near eof]) "fatal error A1010: unmatched block nesting : _BSS" (fatal too, but macabre [I need OMF]) (line 2 [near file beginning])"error A2214: GROUP directive not allowed with /coff option"

WASM (Open Watcom Assembler Version 1.2)
(fatal for me) (line 17949 [near eof]) "Error! E506: block nesting error".

NASM (version 0.98)
I have already typed: program was compiled, but .exe happily outputs "Run time error 216..."

I have not checked lines-too-long (i.e. db too complex) for wasm and nasm.

I wrote this message both because want my problem be solved (now I believe in some crude workaround), and to help developers expect issues of the software discussed.