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 <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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.
