Recent

Author Topic: interfacing a program  (Read 2632 times)

mtanner

  • Sr. Member
  • ****
  • Posts: 287
interfacing a program
« on: April 28, 2016, 07:13:22 pm »
I have a simulation program, so a moderately complex lump of code, that I need to interface to a customers application. They write in C#, and my first attempt was to package the simulator as a DLL, written in Delphi(6). This worked fine when calling the DLL from a Delphi application. The interface is one large data structure, containing fields with all the many input parameters, and fields in which results are returned. So the only paramater passed to the DLL functions is the address of this interface block.
Problems arose when calling the DLL from a C# prpgram, mainly because it was difficult to get the mapping of the memory block in C# to correctly match the Delphi definitions (even though only integers, doubles, and arrays of these were used, no dynamic strings to contend with). I have no experience of C# but just looking at some C# documentation the definition of a data structure seemed obscure, at least to me.

So the current method, just to test out the results, just uses an EXE file which takes a filename as a parameter, reads the input from that file, and writes output to a file using a name derived from the input file name. This works, but is clumsy.
It does have advantages, being indepndent of Delphi/C# data definitions,and 32/64 bit issues.

I'd be interested in suggestions for how to provide a better interface. Although the simulator is in Delphi, my plan is to migrate it to Lazarus ( for Windows/Linux and 32/64 bit portability). Possibilities are:

(1)Pass the input as a parameter string to the EXE, but then still stuck with a file for the output. Pity there is not a "return parameter string" facility.

(2)Somehow use the clipboard (does Linux have a clipboard?) to pass input to the exe and results back.

(3) Do battle with C# memory mapping ("marshaling") again.  I don't even have a C# IDE so this would be a bit daunting.

(4) Stick with the file in/file out scheme, and make it as convenient as possible for multiple runs.

Leledumbo

  • Hero Member
  • *****
  • Posts: 8746
  • Programming + Glam Metal + Tae Kwon Do = Me
Re: interfacing a program
« Reply #1 on: April 28, 2016, 09:32:51 pm »
Pass the input as a parameter string to the EXE, but then still stuck with a file for the output. Pity there is not a "return parameter string" facility.
Why not? The exe could write to stdout which you can read back as a string. Everything is in memory, no disk used at all.
Somehow use the clipboard (does Linux have a clipboard?) to pass input to the exe and results back.
Yes, Linux has clipboard (otherwise how do you ctrl+c-ctrl+v in Linux?). It's the same in memory solution, just a bit odd through would work on all major OSes.
Do battle with C# memory mapping ("marshaling") again.  I don't even have a C# IDE so this would be a bit daunting.
Your problem is very likely only due to packing, you can use
Code: C#  [Select][+][-]
  1. [StructLayout(LayoutKind.Sequential, Pack = N)]
  2.  
to specify struct packing of N bytes in C#, without field reordering. I suggest to specify 1, then on Pascal side declare as packed record or with {$packrecords 1}.
Stick with the file in/file out scheme, and make it as convenient as possible for multiple runs.
Not so efficient, but if it ain't broke, don't fix it.

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1313
Re: interfacing a program
« Reply #2 on: April 29, 2016, 09:41:00 am »
The file has a big advantage over any memory-mapped interface: it is clearly defined. You know up front what each byte does.

Memory interfaces suffer a lot of problems, mostly because their structure depends on third-parties. And with C#, the memory manager and garbage collector can move them around and rearrange them.

Named pipes are much better if you want to prevent disk access.

 

TinyPortal © 2005-2018