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