Re: C# to Delphi

[Matt Siebert]

Glad to hear you had some success with the sample code.

Not sure if it helps, but if you can't keep a reference to anything global
in the Delphi dll, then maybe you could just pass a pointer back and forth -
i.e. pass the data from .NET to Delphi initially and have the Delphi code
allocate the memory and pass back a pointer to it, then have the .NET code
pass that pointer to any function that needs it.  I think this is
effectively what I did originally, although I was freeing the buffer
immediately after I'd got what I wanted on the .NET side.

Good luck.

On Thu, Dec 16, 2010 at 5:18 PM, Peter Maddin wrote:

>  Hi Matt
>
> Found this concerning state management with a Delphi dll
>
> http://stackoverflow.com/questions/1042686/delphi-dynamic-dll-global-variable
>
> The best options look like
> 1. Use a second dll that is loaded dynamically (and unload it when done).
> 2. Use COM
>
>
> There is also LoadLibraryEx and FreeLibrary (
> http://msdn.microsoft.com/en-us/library/ms684179(v=VS.85).aspx
> )
>
> On 15/12/2010 9:42 PM, Matt Siebert wrote:
>
> I'm not sure about the globals.  I did have success with allocating the
> buffer in Delphi, then cleaning it up in a separate call but can't remember
> if the Delphi code kept a reference to the buffer, or if the .NET code
> passed it into the cleanup call.
>
>

Re: C# to Delphi

[Peter Maddin]

After sleeping on it, I thought that in stead of a dll or COM server, 
why not just write an executable and start it from my c# code. I can 
pass any start-up requirements as command line  parameters . I would not 
have any problems with state management.


I could communicate with the process using any of the Interprocess 
communication options that are available 
(http://msdn.microsoft.com/en-us/library/aa365574(v=vs.85).aspx 
)


The easiest would be just to use TCP based socket connection. The Delphi 
executable would be the server and my C# code the client.


The only issue is what service port to use. While one could have that 
has a configurable item many clients aren't that savvy and   I have no 
control over what other software they install and use. I though that I 
could generate one randomly in the same way one is allocated during 
asp.net development.


After googling I found this code that enabled me to determine what ports 
are being listened to locally.


IPGlobalProperties  ipGlobalProperties 
=IPGlobalProperties.GetIPGlobalProperties();
IPEndPoint[] tcpConnInfoArray = 
ipGlobalProperties.GetActiveTcpListeners();

foreach  (IPEndPoint  endpointin  tcpConnInfoArray)
{
Console.WriteLine(String.Format("Port {0} - 
{1}",endpoint.Port,endpoint.Address));
}

I know that another executable or service could be started after my port scan 
and use it
but then my socket server would fail to start.

Does this sound reasonable or is there a better way.  I am not sure how the 
port is allocated during asp.net development if this code was available
then I could plagiarise that.

Re: C# to Delphi

[Peter Maddin]

Hi Matt

Found this concerning state management with a Delphi dll
http://stackoverflow.com/questions/1042686/delphi-dynamic-dll-global-variable

The best options look like
1. Use a second dll that is loaded dynamically (and unload it when done).
2. Use COM


There is also LoadLibraryEx and FreeLibrary 
(http://msdn.microsoft.com/en-us/library/ms684179(v=VS.85).aspx 
)


On 15/12/2010 9:42 PM, Matt Siebert wrote:
I'm not sure about the globals.  I did have success with allocating 
the buffer in Delphi, then cleaning it up in a separate call but can't 
remember if the Delphi code kept a reference to the buffer, or if the 
.NET code passed it into the cleanup call.

Re: C# to Delphi

[Peter Maddin]

Hi Matt

Found this concerning state management with a Delphi dll
http://stackoverflow.com/questions/1042686/delphi-dynamic-dll-global-variable

The best options look like
1. Use a second dll that is loaded dynamically (and unload it when done).
2. Use COM


There is also LoadLibraryEx and FreeLibrary 
(http://msdn.microsoft.com/en-us/library/ms684179(v=VS.85).aspx 
)


On 15/12/2010 9:42 PM, Matt Siebert wrote:
I'm not sure about the globals.  I did have success with allocating 
the buffer in Delphi, then cleaning it up in a separate call but can't 
remember if the Delphi code kept a reference to the buffer, or if the 
.NET code passed it into the cleanup call.

Re: C# to Delphi

[Peter Maddin]

  
  
Hi Matt
  
  Worked fine first time.
  


Thanks for the code.

I have Delphi 7 in  VM (XP Pro) but have managed to install Delphi
2007 (have Delphi 2009 but that uses Unicode and I expect that will
cause me grief with legacy code this old). I have installed my three
cipher controls in Delphi 2007 and then used Delphi 2007 to build
your basic dll to be consumed by my elementary C# winforms app.  So
far so good.

I really miss Resharper ( I am working at home).

On 15/12/2010 8:53 PM, Matt Siebert wrote:
Hi Peter,
  
  
  I found the code for the demo app.  Unfortunately its a
little more basic than I remember.
  
  
  On the Delphi side I have TestLib.dpr with...
  
  
  

  
library TestLib;
  

  uses
    SysUtils,
    Classes,
    Windows;
  

  {$R *.res}
  

  function TestStringConverter(InputString :
  PChar; OutputString : PChar; BufSize : Integer) : Integer;
  stdcall;
  var
    Input : String;
    Output : String;
    OutputLength : Integer;
  begin
    Input := InputString;
    // Do something with the input string
    while Length(Output) < (BufSize -
  Length(Input)) do
    begin
      Output := Output + Input;
    end;
    // Write to
  output buffer
    StrPCopy(OutputString, Output);
    Result := Length(Output);
  end;
  

  exports
    TestStringConverter name
  'TestStringConverter';
  

  begin
  end.



From memory, the key was using PChar's and stdcall.


In .NET I had:



  [DllImport("TestLib.dll")]

public static extern int TestStringConverter(string intput, StringBuilder buffer, int bufSize);




  void Test()
{
StringBuilder buffer = new StringBuilder(20);

int result = TestStringConverter("Foo", buffer, buffer.Capacity);
 
string message = string.Format("Result = {0}\n\nBuffer:\n{1}", result, buffer.ToString());

MessageBox.Show(message);
}


In the production code we were passing a filename to the
  Delphi function, which would read the contents of the file,
  convert it (the bit we didn't have time to port to .NET) and
  then pass the converted contents back to the .NET app as a
  string.  I think the first approach was to allocate the memory
  in Delphi and then copy the data in .NET but then we had to
  call another function in the Delphi library to cleanup (I
  can't remember the specifics).  This worked ok but in the end
  I think we just used the above approach to allocate a buffer
  in .NET and pass it to the Delphi function.  We were dealing
  with lots of small files so making the buffer large enough
  wasn't an issue, although we did have to check the return
  value to see if the buffer was too small (if so then make a
  bigger one and try again).


I hope this helps.  Ping me off list if you'd like the full
  code for the demo app (not much more than what I've pasted
  above).  Maybe some of the guys I used to work with might be
  willing to take a look at the code and offer some insight.


Cheers.

On Wed, Dec 15, 2010 at 7:30 PM, Peter
  Maddin 
  wrote:
  
 I would very much
appreciate a copy of your demo if you can locate it.
Thanks for the offer.

I was going to write up a limited dummy dll for proof of
concept.
If that did not work, try COM.

I have a text "Delphi COM Programming" by Eric Harmon
buts its pretty ancient (but then so is the Delphi code
I am looking at)

I have not had much exposure to COM. My only endeavour
has been to write one using C# for use by Access VBA.
That was a very simple hash function for passwords. It
worked ok but I don't think they have ever used it.
  
  

  On 15/12/2010 5:03 PM, Matt Siebert wrote:
  Hi Peter,


I found myself in a similar situation a while
  ago (wanting to pas

Re: C# to Delphi (more accurately - Delphi to C#)

[Peter Maddin]

Thanks. I give it a go.

On 16/12/2010 10:11 AM, John Li wrote:


(OT- On Experts Exchange)
If you just want to read the answers, visit the page with Google as a referrer 
and scroll all the way down.

John



Date: Thu, 16 Dec 2010 10:08:10 +0800
From: petermad...@aapt.net.au
To: ozdotnet@ozdotnet.com
Subject: Re: C# to Delphi (more accurately - Delphi to C#)

Thanks for the suggestion.

I think a dll would be less effort but this could be another option.

Use to have an Experts Exchange account. I needed this to solve a
particular problem, once I had the solution I did not have much further
use for it and it lapsed.

I think it has a free trial period. I will consider this if the other
directions I have become dead ends.


On 16/12/2010 9:59 AM, Ian Thomas wrote:

Peter

You have the VCL controls for the Delphi app, I suppose (you said you
had the source)?

There is a question (with an acceptable solution) on Experts Exchange
here
– but unless a member, you won’t be able to judge its usefulness.

Embedding VCL (Win32) control on external C# application form
Asked by roknjohn in
Delphi Programming, .NET, C# Programming Language
Tags: Delphi, C#

I have two applications, one written in C# (Windows Forms) and the
other in Delphi (Win32). Is it possible to render a TPanel (or other
component) within the running Delphi application onto some container
control within the C# application? I've tried using the SetParent API
function, but this results in a OutOfMemory runtime exception in the C#
app. However, I am able to embed the entire Delphi app's main form on
the C# app, using SetParent, but I would like to only embed a portion,
TPanel/TFrame.



I recall that someone on this list uses Experts Exchange.





Ian Thomas
Victoria Park, Western Australia



From:
ozdotnet-boun...@ozdotnet.com
[mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Peter Maddin
Sent: Thursday, December 16, 2010 9:33 AM
To: ozDotNet
Subject: Re: C# to Delphi



I tried using TurnSharp but this is really expecting a standard Delphi
project (dpr) file.
The code I needed to convert is a control (dpk) file. This is not a
selectable option.

I converted the demo project that uses this control and it claimed 93.8%.
I checked the generated code and the critical code for the
EllipticCurve was not present (In truth I did not expect it to be as
this is a control integrated into the IDE)

I would have to spend some time taking the control code and making it a
standard unit within a delphi project.
I would then have to do the same with all the other controls needed.

While this is do-able I have not coded in Delphi for quite a few years
and then the outcome may or may not provide a viable product.
I think this might take up to a week to do with an uncertain outcome.

At this stage I think the dll /COM is a more viable option.

On 15/12/2010 2:10 PM, Ian Thomas wrote:

Peter

Had you considered a Delphi to C# code converter?

There’s one
(TurnSharp) that
supports .NET 4.0 Framework and money-back if not 90%+ (not a great
metric, really), with a trial version.





Ian Thomas
Victoria Park, Western Australia



From:
ozdotnet-boun...@ozdotnet.com
[mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Peter Maddin
Sent: Wednesday, December 15, 2010 2:00 PM
To: ozDotNet
Subject: C# to Delphi



I have some cipher units written for Delphi 7.

RE: C# to Delphi (more accurately - Delphi to C#)

[John Li]

(OT- On Experts Exchange)
If you just want to read the answers, visit the page with Google as a referrer 
and scroll all the way down.

John


> Date: Thu, 16 Dec 2010 10:08:10 +0800
> From: petermad...@aapt.net.au
> To: ozdotnet@ozdotnet.com
> Subject: Re: C# to Delphi (more accurately - Delphi to C#)
>
> Thanks for the suggestion.
>
> I think a dll would be less effort but this could be another option.
>
> Use to have an Experts Exchange account. I needed this to solve a
> particular problem, once I had the solution I did not have much further
> use for it and it lapsed.
>
> I think it has a free trial period. I will consider this if the other
> directions I have become dead ends.
>
>
> On 16/12/2010 9:59 AM, Ian Thomas wrote:
>
> Peter
>
> You have the VCL controls for the Delphi app, I suppose (you said you
> had the source)?
>
> There is a question (with an acceptable solution) on Experts Exchange
> here
> – but unless a member, you won’t be able to judge its usefulness.
>
> Embedding VCL (Win32) control on external C# application form
> Asked by roknjohn in
> Delphi Programming, .NET, C# Programming Language
> Tags: Delphi, C#
>
> I have two applications, one written in C# (Windows Forms) and the
> other in Delphi (Win32). Is it possible to render a TPanel (or other
> component) within the running Delphi application onto some container
> control within the C# application? I've tried using the SetParent API
> function, but this results in a OutOfMemory runtime exception in the C#
> app. However, I am able to embed the entire Delphi app's main form on
> the C# app, using SetParent, but I would like to only embed a portion,
> TPanel/TFrame.
>
>
>
> I recall that someone on this list uses Experts Exchange.
>
>
>
> 
>
> Ian Thomas
> Victoria Park, Western Australia
>
> 
>
> From:
> ozdotnet-boun...@ozdotnet.com
> [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Peter Maddin
> Sent: Thursday, December 16, 2010 9:33 AM
> To: ozDotNet
> Subject: Re: C# to Delphi
>
>
>
> I tried using TurnSharp but this is really expecting a standard Delphi
> project (dpr) file.
> The code I needed to convert is a control (dpk) file. This is not a
> selectable option.
>
> I converted the demo project that uses this control and it claimed 93.8%.
> I checked the generated code and the critical code for the
> EllipticCurve was not present (In truth I did not expect it to be as
> this is a control integrated into the IDE)
>
> I would have to spend some time taking the control code and making it a
> standard unit within a delphi project.
> I would then have to do the same with all the other controls needed.
>
> While this is do-able I have not coded in Delphi for quite a few years
> and then the outcome may or may not provide a viable product.
> I think this might take up to a week to do with an uncertain outcome.
>
> At this stage I think the dll /COM is a more viable option.
>
> On 15/12/2010 2:10 PM, Ian Thomas wrote:
>
> Peter
>
> Had you considered a Delphi to C# code converter?
>
> There’s one
> (TurnSharp) that
> supports .NET 4.0 Framework and money-back if not 90%+ (not a great
> metric, really), with a trial version.
>
>
>
> 
>
> Ian Thomas
> Victoria Park, Western Australia
>
> 
>
> From:
> ozdotnet-boun...@ozdotnet.com
> [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Peter Maddin
> Sent: Wednesday, December 15, 2010 2:00 PM
> To: ozDotNet
> Subject: C# to Delphi
>
>
>
> I have some cipher units written for Delphi 7.
  

Re: C# to Delphi (more accurately - Delphi to C#)

[Peter Maddin]

Thanks for the suggestion.

I think a dll would be less effort but this could be another option.

Use to have an Experts Exchange account. I needed this to solve a 
particular problem, once I had the solution I did not have much further 
use for it and it lapsed.


I think it has a free trial period. I will consider this if the other 
directions I have become dead ends.



On 16/12/2010 9:59 AM, Ian Thomas wrote:


Peter

You have the VCL controls for the Delphi app, I suppose (you said you 
had the source)?


There is a question (with an acceptable solution) on Experts Exchange 
here 
<http://www.experts-exchange.com/Programming/Languages/Pascal/Delphi/Q_23707698.html> 
-- but unless a member, you won't be able to judge its usefulness.



  *Embedding VCL (Win32) control on external C# application form*


  *Asked by roknjohn
  <http://www.experts-exchange.com/M_1437683.html> in Delphi
  Programming, .NET, C# Programming Language*


  *Tags: Delphi, C#
  <http://www.experts-exchange.com/tag/Delphi%2C+C%23#allResults>*

I have two applications, one written in C# (Windows Forms) and the 
other in Delphi (Win32).  Is it possible to render a TPanel (or other 
component) within the running Delphi application onto some container 
control within the C# application?  I've tried using the SetParent API 
function, but this results in a OutOfMemory runtime exception in the 
C# app.  However, I am able to embed the entire Delphi app's main form 
on the C# app, using SetParent, but I would like to only embed a 
portion, TPanel/TFrame.


I recall that someone on this list uses Experts Exchange.



Ian Thomas
Victoria Park, Western Australia



*From:*ozdotnet-boun...@ozdotnet.com 
[mailto:ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Peter Maddin

*Sent:* Thursday, December 16, 2010 9:33 AM
*To:* ozDotNet
*Subject:* Re: C# to Delphi

I tried using TurnSharp but this is really expecting a standard Delphi 
project (dpr) file.
The code I needed to convert is a control (dpk) file. This is not a 
selectable option.


I converted the demo project that uses this control and it claimed 93.8%.
I checked the generated code and the critical code for the 
EllipticCurve was not present (In truth I did not expect it to be as 
this is a control integrated into the IDE)


I would have to spend some time taking the control code and making it 
a standard unit within a delphi project.

I would then have to do the same with all the other controls needed.

While this is do-able I have not coded in Delphi for quite a few years 
and then the outcome may or may not provide a viable product.

I think this might take  up to a week to do with an uncertain outcome.

At this stage I think the dll /COM is a more viable option.

On 15/12/2010 2:10 PM, Ian Thomas wrote:

Peter

Had you considered a Delphi to C# code converter?

There's one (TurnSharp 
<https://www.turnsharp.com/delphi-to-csharp.aspx>) that supports .NET 
4.0 Framework and money-back if not 90%+ (not a great metric, really), 
with a trial version.




Ian Thomas
Victoria Park, Western Australia



*From:*ozdotnet-boun...@ozdotnet.com 
<mailto:ozdotnet-boun...@ozdotnet.com> 
[mailto:ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Peter Maddin

*Sent:* Wednesday, December 15, 2010 2:00 PM
*To:* ozDotNet
*Subject:* C# to Delphi

I have some cipher units written for Delphi 7.

RE: C# to Delphi (more accurately - Delphi to C#)

[Ian Thomas]

Peter

You have the VCL controls for the Delphi app, I suppose (you said you had
the source)? 

There is a question (with an acceptable solution) on Experts Exchange here
<http://www.experts-exchange.com/Programming/Languages/Pascal/Delphi/Q_23707
698.html>  - but unless a member, you won't be able to judge its usefulness.



Embedding VCL (Win32) control on external C# application form


Asked by  <http://www.experts-exchange.com/M_1437683.html> roknjohn in
Delphi Programming, .NET, C# Programming Language


Tags:  <http://www.experts-exchange.com/tag/Delphi%2C+C%23#allResults>
Delphi, C#


I have two applications, one written in C# (Windows Forms) and the other in
Delphi (Win32).  Is it possible to render a TPanel (or other component)
within the running Delphi application onto some container control within the
C# application?  I've tried using the SetParent API function, but this
results in a OutOfMemory runtime exception in the C# app.  However, I am
able to embed the entire Delphi app's main form on the C# app, using
SetParent, but I would like to only embed a portion, TPanel/TFrame. 

 

I recall that someone on this list uses Experts Exchange. 

 

  _  

Ian Thomas
Victoria Park, Western Australia

  _  

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of Peter Maddin
Sent: Thursday, December 16, 2010 9:33 AM
To: ozDotNet
Subject: Re: C# to Delphi

 

I tried using TurnSharp but this is really expecting a standard Delphi
project (dpr) file.
The code I needed to convert is a control (dpk) file. This is not a
selectable option.

I converted the demo project that uses this control and it claimed 93.8%.
I checked the generated code and the critical code for the EllipticCurve was
not present (In truth I did not expect it to be as this is a control
integrated into the IDE)

I would have to spend some time taking the control code and making it a
standard unit within a delphi project.
I would then have to do the same with all the other controls needed. 

While this is do-able I have not coded in Delphi for quite a few years and
then the outcome may or may not provide a viable product.
I think this might take  up to a week to do with an uncertain outcome.

At this stage I think the dll /COM is a more viable option.

On 15/12/2010 2:10 PM, Ian Thomas wrote: 

Peter

Had you considered a Delphi to C# code converter? 

There's one (TurnSharp <https://www.turnsharp.com/delphi-to-csharp.aspx> )
that supports .NET 4.0 Framework and money-back if not 90%+ (not a great
metric, really), with a trial version. 

 

  _  

Ian Thomas
Victoria Park, Western Australia

  _  

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of Peter Maddin
Sent: Wednesday, December 15, 2010 2:00 PM
To: ozDotNet
Subject: C# to Delphi

 

I have some cipher units written for Delphi 7.

Re: C# to Delphi

[Peter Maddin]

I tried using TurnSharp but this is really expecting a standard Delphi 
project (dpr) file.
The code I needed to convert is a control (dpk) file. This is not a 
selectable option.


I converted the demo project that uses this control and it claimed 93.8%.
I checked the generated code and the critical code for the EllipticCurve 
was not present (In truth I did not expect it to be as this is a control 
integrated into the IDE)


I would have to spend some time taking the control code and making it a 
standard unit within a delphi project.

I would then have to do the same with all the other controls needed.

While this is do-able I have not coded in Delphi for quite a few years 
and then the outcome may or may not provide a viable product.

I think this might take  up to a week to do with an uncertain outcome.

At this stage I think the dll /COM is a more viable option.

On 15/12/2010 2:10 PM, Ian Thomas wrote:


Peter

Had you considered a Delphi to C# code converter?

There's one (TurnSharp 
) that supports .NET 
4.0 Framework and money-back if not 90%+ (not a great metric, really), 
with a trial version.




Ian Thomas
Victoria Park, Western Australia



*From:*ozdotnet-boun...@ozdotnet.com 
[mailto:ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Peter Maddin

*Sent:* Wednesday, December 15, 2010 2:00 PM
*To:* ozDotNet
*Subject:* C# to Delphi

I have some cipher units written for Delphi 7.

Re: C# to Delphi

[Matt Siebert]

I'm not sure about the globals.  I did have success with allocating the
buffer in Delphi, then cleaning it up in a separate call but can't remember
if the Delphi code kept a reference to the buffer, or if the .NET code
passed it into the cleanup call.

On Wed, Dec 15, 2010 at 11:11 PM, Peter Maddin wrote:

>  Thanks.
>
> That is very helpful.
>
> I'll test it out tomorrow.
>
> Do know if you call a method in the dll that stores data in global
> variables, that these are preserved. May need to allocate some memory to
> store the data but even then one must be able to maintain a pointer to it. I
> would like to be able to maintain some level of state between calls to the
> dll. I suppose I could just try this out but if you know that would be
> helpful.
>
> Very much appreciated.
> Peter.
>
> On 15/12/2010 8:53 PM, Matt Siebert wrote:
>
> Hi Peter,
>
>  I found the code for the demo app.  Unfortunately its a little more basic
> than I remember.
>
>  On the Delphi side I have TestLib.dpr with...
>
>   library TestLib;
>
>  uses
>   SysUtils,
>   Classes,
>   Windows;
>
>  {$R *.res}
>
>  function TestStringConverter(InputString : PChar; OutputString : PChar;
> BufSize : Integer) : Integer; stdcall;
> var
>   Input : String;
>   Output : String;
>   OutputLength : Integer;
> begin
>   Input := InputString;
>   // Do something with the input string
>   while Length(Output) < (BufSize - Length(Input)) do
>   begin
> Output := Output + Input;
>   end;
>   // Write to output buffer
>   StrPCopy(OutputString, Output);
>   Result := Length(Output);
> end;
>
>  exports
>   TestStringConverter name 'TestStringConverter';
>
>  begin
> end.
>
>  From memory, the key was using *PChar*'s and *stdcall*.
>
>  In .NET I had:
>
>  [DllImport("TestLib.dll")]
>
> public static extern int TestStringConverter(string intput, 
> StringBuilder buffer, int bufSize);
>
>
>  void Test()
> {
> StringBuilder buffer = new StringBuilder(20);
>
> int result = TestStringConverter("Foo", buffer, buffer.Capacity);
>
> string message = string.Format("Result = {0}\n\nBuffer:\n{1}", 
> result, buffer.ToString());
>
> MessageBox.Show(message);
> }
>
>  In the production code we were passing a filename to the Delphi function,
> which would read the contents of the file, convert it (the bit we didn't
> have time to port to .NET) and then pass the converted contents back to the
> .NET app as a string.  I think the first approach was to allocate the memory
> in Delphi and then copy the data in .NET but then we had to call another
> function in the Delphi library to cleanup (I can't remember the specifics).
>  This worked ok but in the end I think we just used the above approach to
> allocate a buffer in .NET and pass it to the Delphi function.  We were
> dealing with lots of small files so making the buffer large enough wasn't an
> issue, although we did have to check the return value to see if the buffer
> was too small (if so then make a bigger one and try again).
>
>  I hope this helps.  Ping me off list if you'd like the full code for the
> demo app (not much more than what I've pasted above).  Maybe some of the
> guys I used to work with might be willing to take a look at the code and
> offer some insight.
>
>  Cheers.
>
> On Wed, Dec 15, 2010 at 7:30 PM, Peter Maddin wrote:
>
>>  I would very much appreciate a copy of your demo if you can locate it.
>> Thanks for the offer.
>>
>> I was going to write up a limited dummy dll for proof of concept.
>> If that did not work, try COM.
>>
>> I have a text "Delphi COM Programming" by Eric Harmon buts its pretty
>> ancient (but then so is the Delphi code I am looking at)
>>
>> I have not had much exposure to COM. My only endeavour has been to write
>> one using C# for use by Access VBA. That was a very simple hash function for
>> passwords. It worked ok but I don't think they have ever used it.
>>
>> On 15/12/2010 5:03 PM, Matt Siebert wrote:
>>
>> Hi Peter,
>>
>>  I found myself in a similar situation a while ago (wanting to pass
>> strings between a Delphi DLL and .NET).
>>
>>  There was something slightly tricky about strings but it wasn't too bad.
>>  I think I did something with allocating memory which may be similar to your
>> need to store the xml in memory on the Delphi side.
>>
>>  Unfortunately I can't remember the details right now and I've since
>> changed jobs.  I remember making a demo app in my spare time as a proof of
>> concept before implementing it at work.  I'll have a look for the demo app
>> tonight and let you know.
>>
>>  Cheers,
>> Matt.
>>
>> On Wed, Dec 15, 2010 at 4:00 PM, Peter Maddin wrote:
>>
>>>  I have some cipher units written for Delphi 7.
>>> These are fairly complex (at least for me). They contain methods (sorry
>>> functions and procedures) for the elliptic curve asymmetric cipher, The
>>> Rijndael symmetric cipher and the SHA-1 hash.
>>>
>>> The system that uses these is using

Re: C# to Delphi

[Peter Maddin]

Thanks.

That is very helpful.

I'll test it out tomorrow.

Do know if you call a method in the dll that stores data in global 
variables, that these are preserved. May need to allocate some memory to 
store the data but even then one must be able to maintain a pointer to 
it. I would like to be able to maintain some level of state between 
calls to the dll. I suppose I could just try this out but if you know 
that would be helpful.


Very much appreciated.
Peter.

On 15/12/2010 8:53 PM, Matt Siebert wrote:

Hi Peter,

I found the code for the demo app.  Unfortunately its a little more 
basic than I remember.


On the Delphi side I have TestLib.dpr with...

library TestLib;

uses
  SysUtils,
  Classes,
  Windows;

{$R *.res}

function TestStringConverter(InputString : PChar; OutputString : 
PChar; BufSize : Integer) : Integer; stdcall;

var
  Input : String;
  Output : String;
  OutputLength : Integer;
begin
  Input := InputString;
  // Do something with the input string
  while Length(Output) < (BufSize - Length(Input)) do
  begin
Output := Output + Input;
  end;
  // Write to output buffer
  StrPCopy(OutputString, Output);
  Result := Length(Output);
end;

exports
  TestStringConverter name 'TestStringConverter';

begin
end.

From memory, the key was using *PChar*'s and *stdcall*.

In .NET I had:

 [DllImport("TestLib.dll")]

 public  static  extern  int  TestStringConverter(string  
intput,StringBuilder  buffer,int  bufSize);

 void  Test()
 {
 StringBuilder  buffer =new  StringBuilder(20);

 int  result = TestStringConverter("Foo", buffer, buffer.Capacity);

 string  message =string.Format("Result = {0}\n\nBuffer:\n{1}", 
result, buffer.ToString());

 MessageBox.Show(message);
 }
In the production code we were passing a filename to the Delphi 
function, which would read the contents of the file, convert it (the 
bit we didn't have time to port to .NET) and then pass the converted 
contents back to the .NET app as a string.  I think the first approach 
was to allocate the memory in Delphi and then copy the data in .NET 
but then we had to call another function in the Delphi library to 
cleanup (I can't remember the specifics).  This worked ok but in the 
end I think we just used the above approach to allocate a buffer in 
.NET and pass it to the Delphi function.  We were dealing with lots of 
small files so making the buffer large enough wasn't an issue, 
although we did have to check the return value to see if the buffer 
was too small (if so then make a bigger one and try again).


I hope this helps.  Ping me off list if you'd like the full code for 
the demo app (not much more than what I've pasted above).  Maybe some 
of the guys I used to work with might be willing to take a look at the 
code and offer some insight.


Cheers.

On Wed, Dec 15, 2010 at 7:30 PM, Peter Maddin > wrote:


I would very much appreciate a copy of your demo if you can locate it.
Thanks for the offer.

I was going to write up a limited dummy dll for proof of concept.
If that did not work, try COM.

I have a text "Delphi COM Programming" by Eric Harmon buts its
pretty ancient (but then so is the Delphi code I am looking at)

I have not had much exposure to COM. My only endeavour has been to
write one using C# for use by Access VBA. That was a very simple
hash function for passwords. It worked ok but I don't think they
have ever used it.

On 15/12/2010 5:03 PM, Matt Siebert wrote:

Hi Peter,

I found myself in a similar situation a while ago (wanting to
pass strings between a Delphi DLL and .NET).

There was something slightly tricky about strings but it wasn't
too bad.  I think I did something with allocating memory which
may be similar to your need to store the xml in memory on the
Delphi side.

Unfortunately I can't remember the details right now and I've
since changed jobs.  I remember making a demo app in my spare
time as a proof of concept before implementing it at work.  I'll
have a look for the demo app tonight and let you know.

Cheers,
Matt.

On Wed, Dec 15, 2010 at 4:00 PM, Peter Maddin
mailto:petermad...@aapt.net.au>> wrote:

I have some cipher units written for Delphi 7.
These are fairly complex (at least for me). They contain
methods (sorry functions and procedures) for the elliptic
curve asymmetric cipher, The Rijndael symmetric cipher and
the SHA-1 hash.

The system that uses these is using file downloads  and
uploads using Delphi 7 Isapi dlls.
The system while working, is suffering congestion problems
especially with uploads.

What I would like to use is WCF web services to handle data
downloads and create local server files from parameters sent
to the WCF web service on the server rather tha

Re: C# to Delphi

[Matt Siebert]

Hi Peter,

I found the code for the demo app.  Unfortunately its a little more basic
than I remember.

On the Delphi side I have TestLib.dpr with...

library TestLib;

uses
  SysUtils,
  Classes,
  Windows;

{$R *.res}

function TestStringConverter(InputString : PChar; OutputString : PChar;
BufSize : Integer) : Integer; stdcall;
var
  Input : String;
  Output : String;
  OutputLength : Integer;
begin
  Input := InputString;
  // Do something with the input string
  while Length(Output) < (BufSize - Length(Input)) do
  begin
Output := Output + Input;
  end;
  // Write to output buffer
  StrPCopy(OutputString, Output);
  Result := Length(Output);
end;

exports
  TestStringConverter name 'TestStringConverter';

begin
end.

>From memory, the key was using *PChar*'s and *stdcall*.

In .NET I had:

[DllImport("TestLib.dll")]
public static extern int TestStringConverter(string intput,
StringBuilder buffer, int bufSize);

void Test()
{
StringBuilder buffer = new StringBuilder(20);
int result = TestStringConverter("Foo", buffer, buffer.Capacity);

string message = string.Format("Result =
{0}\n\nBuffer:\n{1}", result, buffer.ToString());
MessageBox.Show(message);
}

In the production code we were passing a filename to the Delphi function,
which would read the contents of the file, convert it (the bit we didn't
have time to port to .NET) and then pass the converted contents back to the
.NET app as a string.  I think the first approach was to allocate the memory
in Delphi and then copy the data in .NET but then we had to call another
function in the Delphi library to cleanup (I can't remember the specifics).
 This worked ok but in the end I think we just used the above approach to
allocate a buffer in .NET and pass it to the Delphi function.  We were
dealing with lots of small files so making the buffer large enough wasn't an
issue, although we did have to check the return value to see if the buffer
was too small (if so then make a bigger one and try again).

I hope this helps.  Ping me off list if you'd like the full code for the
demo app (not much more than what I've pasted above).  Maybe some of the
guys I used to work with might be willing to take a look at the code and
offer some insight.

Cheers.

On Wed, Dec 15, 2010 at 7:30 PM, Peter Maddin wrote:

>  I would very much appreciate a copy of your demo if you can locate it.
> Thanks for the offer.
>
> I was going to write up a limited dummy dll for proof of concept.
> If that did not work, try COM.
>
> I have a text "Delphi COM Programming" by Eric Harmon buts its pretty
> ancient (but then so is the Delphi code I am looking at)
>
> I have not had much exposure to COM. My only endeavour has been to write
> one using C# for use by Access VBA. That was a very simple hash function for
> passwords. It worked ok but I don't think they have ever used it.
>
> On 15/12/2010 5:03 PM, Matt Siebert wrote:
>
> Hi Peter,
>
>  I found myself in a similar situation a while ago (wanting to pass
> strings between a Delphi DLL and .NET).
>
>  There was something slightly tricky about strings but it wasn't too bad.
>  I think I did something with allocating memory which may be similar to your
> need to store the xml in memory on the Delphi side.
>
>  Unfortunately I can't remember the details right now and I've since
> changed jobs.  I remember making a demo app in my spare time as a proof of
> concept before implementing it at work.  I'll have a look for the demo app
> tonight and let you know.
>
>  Cheers,
> Matt.
>
> On Wed, Dec 15, 2010 at 4:00 PM, Peter Maddin wrote:
>
>>  I have some cipher units written for Delphi 7.
>> These are fairly complex (at least for me). They contain methods (sorry
>> functions and procedures) for the elliptic curve asymmetric cipher, The
>> Rijndael symmetric cipher and the SHA-1 hash.
>>
>> The system that uses these is using file downloads  and uploads using
>> Delphi 7 Isapi dlls.
>> The system while working, is suffering congestion problems especially with
>> uploads.
>>
>> What I would like to use is WCF web services to handle data downloads and
>> create local server files from parameters sent to the WCF web service on the
>> server rather than perform uploads (the file contents is very small).
>>
>> Writing the WCF should not be too much of a challenge but I need to use
>> the delphi code to handle decryption/encryption.
>>
>> I thought of writing a Win32 dll for the encryption logic called from C#
>> WinForms (or maybe WPF) application.
>>
>> Has anyone done this sort of thing before? I understand that value types
>> are ok to exchange but reference types are a pain, this includes strings.
>>
>> I have googled and there is a fair bit out there. Most of this is dealing
>> with the pain of trying do it.
>>
>> I only need to exchange ints, bools and strings. Nothing too fancy.
>> Has anyone some sample code they would be willing to share?
>>
>> Also I w

Re: C# to Delphi

[Peter Maddin]

I would very much appreciate a copy of your demo if you can locate it.
Thanks for the offer.

I was going to write up a limited dummy dll for proof of concept.
If that did not work, try COM.

I have a text "Delphi COM Programming" by Eric Harmon buts its pretty 
ancient (but then so is the Delphi code I am looking at)


I have not had much exposure to COM. My only endeavour has been to write 
one using C# for use by Access VBA. That was a very simple hash function 
for passwords. It worked ok but I don't think they have ever used it.


On 15/12/2010 5:03 PM, Matt Siebert wrote:

Hi Peter,

I found myself in a similar situation a while ago (wanting to pass 
strings between a Delphi DLL and .NET).


There was something slightly tricky about strings but it wasn't too 
bad.  I think I did something with allocating memory which may be 
similar to your need to store the xml in memory on the Delphi side.


Unfortunately I can't remember the details right now and I've since 
changed jobs.  I remember making a demo app in my spare time as a 
proof of concept before implementing it at work.  I'll have a look for 
the demo app tonight and let you know.


Cheers,
Matt.

On Wed, Dec 15, 2010 at 4:00 PM, Peter Maddin > wrote:


I have some cipher units written for Delphi 7.
These are fairly complex (at least for me). They contain methods
(sorry functions and procedures) for the elliptic curve asymmetric
cipher, The Rijndael symmetric cipher and the SHA-1 hash.

The system that uses these is using file downloads  and uploads
using Delphi 7 Isapi dlls.
The system while working, is suffering congestion problems
especially with uploads.

What I would like to use is WCF web services to handle data
downloads and create local server files from parameters sent to
the WCF web service on the server rather than perform uploads (the
file contents is very small).

Writing the WCF should not be too much of a challenge but I need
to use the delphi code to handle decryption/encryption.

I thought of writing a Win32 dll for the encryption logic called
from C# WinForms (or maybe WPF) application.

Has anyone done this sort of thing before? I understand that value
types are ok to exchange but reference types are a pain, this
includes strings.

I have googled and there is a fair bit out there. Most of this is
dealing with the pain of trying do it.

I only need to exchange ints, bools and strings. Nothing too fancy.
Has anyone some sample code they would be willing to share?

Also I would like be able call a method in the dll to store
information in memory to be used by other method calls. This
information is stored in an xml file and I would rather it be read
and processed once rather than repeat this each time I need to use
a method. In other words in using  delphi dll, will it preserve
state between method calls?

If I can't get the dll to work I will fall back on the
crypographic support in the framework but this basically triples
the effort required and data encrypted by the current system will
not be compatible with the framework cryptographic routines.

Any help very much appreciated.

Re: C# to Delphi

[Matt Siebert]

Hi Peter,

I found myself in a similar situation a while ago (wanting to pass strings
between a Delphi DLL and .NET).

There was something slightly tricky about strings but it wasn't too bad.  I
think I did something with allocating memory which may be similar to your
need to store the xml in memory on the Delphi side.

Unfortunately I can't remember the details right now and I've since changed
jobs.  I remember making a demo app in my spare time as a proof of concept
before implementing it at work.  I'll have a look for the demo app tonight
and let you know.

Cheers,
Matt.

On Wed, Dec 15, 2010 at 4:00 PM, Peter Maddin wrote:

>  I have some cipher units written for Delphi 7.
> These are fairly complex (at least for me). They contain methods (sorry
> functions and procedures) for the elliptic curve asymmetric cipher, The
> Rijndael symmetric cipher and the SHA-1 hash.
>
> The system that uses these is using file downloads  and uploads using
> Delphi 7 Isapi dlls.
> The system while working, is suffering congestion problems especially with
> uploads.
>
> What I would like to use is WCF web services to handle data downloads and
> create local server files from parameters sent to the WCF web service on the
> server rather than perform uploads (the file contents is very small).
>
> Writing the WCF should not be too much of a challenge but I need to use the
> delphi code to handle decryption/encryption.
>
> I thought of writing a Win32 dll for the encryption logic called from C#
> WinForms (or maybe WPF) application.
>
> Has anyone done this sort of thing before? I understand that value types
> are ok to exchange but reference types are a pain, this includes strings.
>
> I have googled and there is a fair bit out there. Most of this is dealing
> with the pain of trying do it.
>
> I only need to exchange ints, bools and strings. Nothing too fancy.
> Has anyone some sample code they would be willing to share?
>
> Also I would like be able call a method in the dll to store information in
> memory to be used by other method calls. This information is stored in an
> xml file and I would rather it be read and processed once rather than repeat
> this each time I need to use a method. In other words in using  delphi dll,
> will it preserve state between method calls?
>
> If I can't get the dll to work I will fall back on the crypographic support
> in the framework but this basically triples the effort required and data
> encrypted by the current system will not be compatible with the framework
> cryptographic routines.
>
> Any help very much appreciated.
>
>
>
>
>

Re: C# to Delphi

[Peter Maddin]

 It's not a few hours, but 2 or 3
 days and you should easily get it done (at least, I'd consider
 investigating it).


Maybe for you, but I am not so sure about it myself.

I think that I would rather try out my existing options first to see how they 
try out.

system.security.cryptography already supports rijndale and sha-1. I am aware 
that sha-1 has issues but this is a legacy application so I am kind of stuck 
with it.

Bouncy Castle (http://www.bouncycastle.org/csharp/) has support for Elliptic 
Curve but I am not sure how close that would be to what the Delphi developer 
actually wrote.

While there are standards in implementing these algorithms, not everyone 
implements them in an identical fashion, especially if that developer did so 
years ago and is no longer available to ask.

Regards Peter

On 15/12/2010 3:38 PM, silky wrote:

It's not a few hours, but 2 or 3
days and you should easily get it done (at least, I'd consider
investigating it).

Re: C# to Delphi

[silky]

On Wed, Dec 15, 2010 at 6:25 PM, Peter Maddin  wrote:
> Hi Greg
>
> > Did the Delphi authors do that?!
>
> Sorry no idea. The controls were purchased from a European site because I
> could not get anything out of the States. The company, no longer exists so I
> am glad I purchased source code or I would be screwed. I tried to purchase
> TurboPower's LockBox but they would not supply it due to an export
> moratorium on cryptographic cipher technology. This has been relaxed for
> some time now but I am stuck with the legacy of went before.
>
> The code I purchased has been in use for many years and has been very
> reliable (except for a memory leak that I managed to fix). I do not feel
> competent to recode it.

FWIW, it's probably far easier then you imagine. For any popular
algorithm you'll find examples in just popular languages (java/c#),
and you can easily translate that. There will be test vectors provided
so you can test your implementation. It's not a few hours, but 2 or 3
days and you should easily get it done (at least, I'd consider
investigating it).

You should know that SHA-1 is considered "not good" as a hash:
http://valerieaurora.org/hash.html, so I'd avoid it's use if possible.


> The idea of writing a COM object to encapsulate the
> Delphi code seems like the optimal solution. I am not that well versed in
> COM so I have some study to do. At least I have texts on the subject. I
> thought that with .NET, COM was deprecated (even if COM+ is not). Oh well.
>
> I will give the Delphi to C# converter suggested by Ian, a go as well.
>
> My fall back is to use the framework's cryptographic support (RSA not
> elliptic curve) but that would mean two parallel delivery streams, the old
> and the new that are not compatible with each other.

-- 
silky

http://dnoondt.wordpress.com/

"Every morning when I wake up, I experience an exquisite joy — the joy
of being this signature."

Re: C# to Delphi

[Peter Maddin]

Hi Greg

>> Did the Delphi authors do that?!

Sorry no idea. The controls were purchased from a European site because 
I could not get anything out of the States. The company, no longer 
exists so I am glad I purchased source code or I would be screwed. I 
tried to purchase TurboPower's LockBox but they would not supply it due 
to an export moratorium on cryptographic cipher technology. This has 
been relaxed for some time now but I am stuck with the legacy of went 
before.


The code I purchased has been in use for many years and has been very 
reliable (except for a memory leak that I managed to fix). I do not feel 
competent to recode it. The idea of writing a COM object to encapsulate 
the Delphi code seems like the optimal solution. I am not that well 
versed in COM so I have some study to do. At least I have texts on the 
subject. I thought that with .NET, COM was deprecated (even if COM+ is 
not). Oh well.


I will give the Delphi to C# converter suggested by Ian, a go as well.

My fall back is to use the framework's cryptographic support (RSA not 
elliptic curve) but that would mean two parallel delivery streams, the 
old and the new that are not compatible with each other.







On 15/12/2010 2:58 PM, Greg Keogh wrote:

Did the Delphi authors do that?!

RE: C# to Delphi

[Greg Keogh]

Peter, so the core of the problem is that you want to reuse the Delphi
crypto functions in a newly written WCF service?

 

Can you wrap the Delphi stuff as a COM server? We've been using COM for
exposing .NET to scripts and VB6, and VB6 to .NET and it (eventually) works
tolerably well so long as you keep all of the interfaces reasonably vanilla
and don't create your own pain.

 

As an aside: If the Delphi crypto code is not compatible with the equivalent
Framework classes, then the Delphi code must be implemented incorrectly.
Manually coding complete crypto algorithms is a delicate process and you
have to be sure they pass all the standard test vector inputs correctly. Did
the Delphi authors do that?!

 

Cheers,

Greg

Re: C# to Delphi

[Peter Maddin]

Hi Ian

No I hadn't.

I might give that a go but I am not sure how well that will work. Still 
nothing ventured nothing gained.


Rather than move it to a standard dll, I might try COM instead. I have 
not used COM very much at all, so this require some learning.


Regards Peter.

On 15/12/2010 2:10 PM, Ian Thomas wrote:


Peter

Had you considered a Delphi to C# code converter?

There's one (TurnSharp 
) that supports .NET 
4.0 Framework and money-back if not 90%+ (not a great metric, really), 
with a trial version.




Ian Thomas
Victoria Park, Western Australia



*From:*ozdotnet-boun...@ozdotnet.com 
[mailto:ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Peter Maddin

*Sent:* Wednesday, December 15, 2010 2:00 PM
*To:* ozDotNet
*Subject:* C# to Delphi

I have some cipher units written for Delphi 7.

RE: C# to Delphi

[Ian Thomas]

Peter

Had you considered a Delphi to C# code converter? 

There's one (TurnSharp  )
that supports .NET 4.0 Framework and money-back if not 90%+ (not a great
metric, really), with a trial version. 

 

  _  

Ian Thomas
Victoria Park, Western Australia

  _  

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of Peter Maddin
Sent: Wednesday, December 15, 2010 2:00 PM
To: ozDotNet
Subject: C# to Delphi

 

I have some cipher units written for Delphi 7.