Re: [lazarus] Help with DLL (using pchar, etc.)
Am Freitag, den 13.01.2006, 03:23 -0700 schrieb L505: I misinterpreted the scope of your approach. But you're right, if I get there and squeeze out the last bytes for embedded systems I'll make it publicly available. Marc I was saying that basically one way of trimming down cgi programs significantly was to use CompactSysUtils - Another way to trim, is to put some functions into a DLL Yes, this is my favourite. As you can imagine, on embedded nano-computers every single byte has to be checked if it does something useful, the other ones have to go home. ;) (not compactsysutils ones, things like database access , sessions, cookies functions). Maybe you thought I was going to put compactsysutils functions in a dll - I didn't mean that. But actually it's an interesting thought - having some of the fpc RTL in a dll. Or, maybe I misinterpreted your misinterpretation :) I think from reading the message from Florian Klämpfl with the subject dyn. linked lazarus the door to dynamicylly linked basics like RTL is pushed open with fpc 2.1.1. That's a big step forward in general - good work, Florian and others involved! For small CPUs it is not sufficient, because wether a byte is linked in statically or sits in a dynamic library - it has to be loaded anyways. One way I started thinking about was to use non standard X-Server (X.org or XFree86) but something like NanoX or similar. Unfortunately none of the ones I know run on FreeBSD ... Marc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Help with DLL (using pchar, etc.)
Yes, this is my favourite. As you can imagine, on embedded nano-computers every single byte has to be checked if it does something useful, the other ones have to go home. ;) Do you think the PStrList will be useful, and some other fake (byte friendly) classes (objects) in CompactUtils? I know pure arrays and and simple variables without any objects at all, will save bytes, but hey wouldn't it be nice to have some of object oriented programming without the cost of bytes? Yes in your case embedded programming will not benefit from DLL programming of course - in fact dll programming is more inefficient than static linking because with static linking you don't have to load the entire DLL with wasted functions in it. I'm not one of those dudes who is anal about having Exe's small - it's just a matter of having a leading advantage of being able to upload a nice small 30kb powerful CGI program and of course being able to work with embedded systems. That is one advantage with FPC is being able to work with embedded systems, over say python or perl. I'm sure people would love working with Pascal rather than C for embedded systems, but in order for Pascal to have a chance in embedded systems we must have projects like this compactutils and system.ppu replacements, otherwise people will have to resort to C. Because the big 30kb hello world exe and the 90kb hello world exe with sysutils in the uses clause is not good for embedded systems. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Help with DLL (using pchar, etc.)
On 1/12/06, L505 [EMAIL PROTECTED] wrote: later with results... I still don't know why your dll was working and not mine. If this is because of the smartlinking issue... well... hum... I don't know what to say. Me neither, what was the error? I was hoping it was simply because you forgot to rename mydll.dll.dll to mydll.dll or something simple like that. But I assume you renamed it and it found the DLL correctly when statically pulling it in on application loading? Also maybe your DLL problem is somewhat related to Tony Pelton's DLL problem he had. He said when he used Lazarus his DLL didn't work, but when he chose the FP IDE his DLL worked. Which compiler version are you using with Lazarus and which Lazarus version? I was using the latest build 20060110 (an auto-generated setup for windows). My dll size with or without smart-linking was around 7xx KB and was not working with vdf 11.1, but was working in vba (office 97, for testing) and delphi 3; both under win98. To me this sounds like certain compilers don't create good DLL's but FPC 2.0.2 does. Or like you say it could also be a case of a non-smartlinked RTL causing the problem, but we could try a non-smartlinked RTL with fpc 2.0.2 and see what happens too... I would go for the compiler doing good or no good dll. I recompiled with 2.0.2 and all is working, with or without smart-linking. The difference in size few KB: 278kb with sm, 280kb without (an both works). So the 2.0.2 compiler under windows is doing a better job for dll, at least for the 'vdf 11.1' language since it was the only problematic language. -- Alexandre Leclerc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Help with DLL (using pchar, etc.)
On 1/11/06, L505 [EMAIL PROTECTED] wrote: Are you using special strip commands? (This situation is really strange for me.) I assume that you run under Windows... What does your DOS window say after you stripped the DLL? Nothing peculiar. As to the .dll.dll I just choosed not to fix it :) since this was just for a test any-way. I've read all your other mail, thank you a lot. I'm now working on that. I'll post later. Also, to fix the mydll.dll.dll problem go into project options and change it. I thought the FPC compiler had a bug where mydll.dll.junk needed to be used but in fact mydll.dll works. Maybe it was only for exe's or maybe it was fixed. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives -- Alexandre Leclerc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Help with DLL (using pchar, etc.)
What does your DOS window say after you stripped the DLL? Nothing peculiar. As to the .dll.dll I just choosed not to fix it :) since this was just for a test any-way. Since Vincent has indicated lazarus ships with a non-smartlinked RTL, you may be pulling in a big sysutils in your case causing the extra size. I don't know if that is the reason or not. And again just to be sure, take all debugging checkmarks off too. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Help with DLL (using pchar, etc.)
On 1/12/06, L505 [EMAIL PROTECTED] wrote: What does your DOS window say after you stripped the DLL? Nothing peculiar. As to the .dll.dll I just choosed not to fix it :) since this was just for a test any-way. Since Vincent has indicated lazarus ships with a non-smartlinked RTL, you may be pulling in a big sysutils in your case causing the extra size. I don't know if that is the reason or not. And again just to be sure, take all debugging checkmarks off too. Oh! It makes me think: are you compiling under linux to produce this dll? Else, is there a way to have the rtl smartlinked for windows? -- Alexandre Leclerc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Help with DLL (using pchar, etc.)
Oh! It makes me think: are you compiling under linux to produce this Nope. dll? Else, is there a way to have the rtl smartlinked for windows? Well since I use fpc 2.0.2 the RTL is smartlinked. I think you are using the compiler that comes with lazarus. i.e. in environment options, I set my compiler up as a custom one in my own directory, such as C:\FPC_2.0.2\ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Help with DLL (using pchar, etc.)
On 1/12/06, L505 [EMAIL PROTECTED] wrote: Oh! It makes me think: are you compiling under linux to produce this Nope. dll? Else, is there a way to have the rtl smartlinked for windows? Well since I use fpc 2.0.2 the RTL is smartlinked. I think you are using the compiler that comes with lazarus. i.e. in environment options, I set my compiler up as a custom one in my own directory, such as C:\FPC_2.0.2\ Marvelous! I'll try that and it will most probably work. I'll come later with results... I still don't know why your dll was working and not mine. If this is because of the smartlinking issue... well... hum... I don't know what to say. -- Alexandre Leclerc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Help with DLL (using pchar, etc.)
On 1/12/06, Alexandre Leclerc [EMAIL PROTECTED] wrote: On 1/12/06, L505 [EMAIL PROTECTED] wrote: Oh! It makes me think: are you compiling under linux to produce this Nope. dll? Else, is there a way to have the rtl smartlinked for windows? Well since I use fpc 2.0.2 the RTL is smartlinked. I think you are using the compiler that comes with lazarus. i.e. in environment options, I set my compiler up as a custom one in my own directory, such as C:\FPC_2.0.2\ Marvelous! I'll try that and it will most probably work. I'll come later with results... I still don't know why your dll was working and not mine. If this is because of the smartlinking issue... well... hum... I don't know what to say. Yes! This is finally working! The compiled exe with smart linking is 274kb (was 272kb without...) yet after striping the dll I get 91648 bytes exactly as your dll. And finally the dll is working with my obscure devel. language. Now, it would be great if the devel edition of fpc was working. :) Thank you very much for your help, L505, on all this issue. -- Alexandre Leclerc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Help with DLL (using pchar, etc.)
Marvelous! I'll try that and it will most probably work. I'll come If you decide to use fpc 2.0.2 remember that when you build a normal lazarus GUI style application you may have to change back to your old compiler in the lazarus directory. The lazarus packages and components I think need to be recompiled with the new compiler you choose if you decide to build a gui application. Myself I built a custom version of lazarus 0.9.7 with fpc 2.0.2 and all it's components and packages. What I would do if I were you would just switch back to your old compiler when you decide to build a gui program later with results... I still don't know why your dll was working and not mine. If this is because of the smartlinking issue... well... hum... I don't know what to say. Me neither, what was the error? I was hoping it was simply because you forgot to rename mydll.dll.dll to mydll.dll or something simple like that. But I assume you renamed it and it found the DLL correctly when statically pulling it in on application loading? _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Help with DLL (using pchar, etc.)
Yes! This is finally working! The compiled exe with smart linking is 274kb (was 272kb without...) yet after striping the dll I get 91648 bytes exactly as your dll. And finally the dll is working with my obscure devel. language. Now, it would be great if the devel edition of fpc was working. :) Thank you very much for your help, L505, on all this issue. Try also compactSysUtils if you want a 40KB dll It is a drop in replacement for this particular situation :) See all this fooling around with compilers is why people use scripting languages and just forget about size issues - the time we've spent chasing this down, the time we spent... :) _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Help with DLL (using pchar, etc.)
later with results... I still don't know why your dll was working and not mine. If this is because of the smartlinking issue... well... hum... I don't know what to say. Me neither, what was the error? I was hoping it was simply because you forgot to rename mydll.dll.dll to mydll.dll or something simple like that. But I assume you renamed it and it found the DLL correctly when statically pulling it in on application loading? Also maybe your DLL problem is somewhat related to Tony Pelton's DLL problem he had. He said when he used Lazarus his DLL didn't work, but when he chose the FP IDE his DLL worked. Which compiler version are you using with Lazarus and which Lazarus version? To me this sounds like certain compilers don't create good DLL's but FPC 2.0.2 does. Or like you say it could also be a case of a non-smartlinked RTL causing the problem, but we could try a non-smartlinked RTL with fpc 2.0.2 and see what happens too... _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Help with DLL (using pchar, etc.)
Maybe having the 'mydll.compiled' file could help (if there is any)... I think this is the file that has the compiler settings. The LPI file carries the settings _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Help with DLL (using pchar, etc.)
On 1/11/06, L505 [EMAIL PROTECTED] wrote: Maybe having the 'mydll.compiled' file could help (if there is any)... I think this is the file that has the compiler settings. The LPI file carries the settings Are you using special strip commands? (This situation is really strange for me.) I assume that you run under Windows... -- Alexandre Leclerc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Help with DLL (using pchar, etc.)
As an experiment for CompactSysUtils project I started a while ago, I have used this opportunity to demonstrate why FPC should reorganize the FPC sysutils unit for better smartlinking (i.e. create just one more unit than just sysutils to take care of smartlinking). Many functions in the FPC sysutils unit do not rely on any finalization or initialization code. By simple copy and pasting some of the sysutils functions into a unit of my own, called CompactSysUtils, I have gotten the DLL down to 40KB which was previously 91KB Project files showing 40KB DLL versus 91KB DLL is here: http://z505.com/pascal/MD5Hash/MD5Hash_COMPARE.zip CompactUtils and CompactSysUtils project is here: https://opensvn.csie.org/pspcgi/psp-lib-1.5.0-devel/src/extras/CompactUtils/ In order to compile the CompactUtils version in that zip file, you will need the latest copy of the compactutils.pas and compactsysutils.pas which is located on the SVN link above. Sometimes we don't worry so much about bloat like this since today's processors are getting faster, but this one is a no brainer. There is no work to be done other than copy/paste functions and reorganize them such as I have done with CompactSysUtils project. I have also made notes about this before on the mailing lists, such as mentioning how the findpart function can be cut copied and pasted right out of the StrUtils unit so that no sysutils initialization and finalization is hauled in. Maybe people can learn from this with the lazarus project too - as I'm guessing some (not all) the reason lazarus exe's are so big is because or simple initialization/finalization bloat. Sure there are abstraction bloat that is incurred for multi-platform programming in SOME CASES, but I've just proved with above CompactUtils project that abstraction has nothing to do with the majority of the bloat in this case. Rather simple reorganization in this case, to cut the EXE and DLL in half (actually, *more* than half). So either I continue to maintain this compactutils project with my elite cutting/copying/pasting skills or the FPC team decides to reorganize sysutils at the distribution level (i.e. kill the compactutils project and just do it in the RTL itself). Also anyone wishing to participate in this compactutils project I started is welcome - I started it to gain smartlinking knowledge myself and I'm sure others could benefit from knowing more about smartlinking. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Help with DLL (using pchar, etc.)
Mattias Gaertner wrote: On Wed, 11 Jan 2006 12:20:09 -0700 L505 [EMAIL PROTECTED] wrote: Also, check your FPC source RTL units directory for .a and .o files If there are no .a files then your RTL is not smartlinked. I cannot remember if Lazarus ships with the RTL units smartlinked or not? Can someone clarify? The linux rpms contain the libpunitname.a files. Are they smartlinked? The windows lazarus installer has rtl units with debug info and for therefore were created without smartlinking. At one point in time using smartlinking and debuginfo was not a good idea, I don't know if the situation has changed. Vincent. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Help with DLL (using pchar, etc.)
Hi L505,
Here is my actual implementation (and working great) of the
function... in case you would like to update your example. Thanks all
for the help. (I'm still opened to any improvements: toward the
perfect code ;). )
{ Summary:
Create a MD5 hash from a string and return the result.
Arguments:
ASource = source string from which we calculate the md5
ADestination = destination string to which we save the hexadecimal
representation of the md5 (always 32+1 in size)
ADestinationMaxSize = size of the allocated ADestination string; it should
be at least (32+1) or the function will fail.
Note:
The ADestinationMaxSize is technicaly useless, but it is introduced as an
example of a typical library working with strings.
Results:
MD5 result will be saved in ADestination. Returns the size of the md5 hash
if succesfull or -1 if failed write the hash in ADestination. }
function MakeMD5Hash(ASource: PChar; ADestination: PChar;
ADestinationMaxSize: LongInt): LongInt; stdcall;
var
s: string;
sSize: LongInt;
begin
s := MD5Print(MD5String(ASource));
sSize := Length(s) + 1;
if sSize = ADestinationMaxSize then
begin
Move(PChar(s)^, ADestination^, sSize);
Result := sSize;
end else
Result := -1;
end;
On 12/30/05, L505 [EMAIL PROTECTED] wrote:
I have made an example for md5 hash
http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=MD5Hash-Example
_
To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
--
Alexandre Leclerc
_
To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Help with DLL (using pchar, etc.)
Hi again L505, I've compiled your example, and even after strip'ing the dll, I have 2xx kb and you less than 100 kb. Are you doing something special (i'm under windows), any compiler settings, etc? -- Alexandre Leclerc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Help with DLL (using pchar, etc.)
On 1/10/06, Alexandre Leclerc [EMAIL PROTECTED] wrote: Hi again L505, I've compiled your example, and even after strip'ing the dll, I have 2xx kb and you less than 100 kb. Are you doing something special (i'm under windows), any compiler settings, etc? The DLL works in VB and Delphi apps. But from a language called Visual Dataflex, it does not work when I do compile it. But if I use your DLL (provided in ZIP file) it does work! So I'm very interesting about the way you used to compile. I used v0.9.11 from windows installer. (I'll try a recent version.) -- Alexandre Leclerc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Help with DLL (using pchar, etc.)
On 1/1/06, L505 [EMAIL PROTECTED] wrote: function MakeMD5Hash(ASource: PChar; ADestination: PChar; ADestinationMaxSize: Cardinal): Boolean; stdcall; Also probably a good idea to use fixed types such as longint and longbool, and bool rather than integer and cardinal, so the people tapping into the function know exactly what variable to declare in their language at a certain point of the year (if a new compiler comes out things sometimes change). In the documentation for the function it would be good to specify how big a longint really is, as some C programmers may have no clue what a longint really is in Pascal. Now I like a lot the way this function is desigend and I'll do it exactly like that. I'll also use a standard type as suggested because of the same reason: we all know of what we are talking about, especially with the 64bits age comming quite fast. This is an overkill design for the simple need I have, but my personal way of work is always: do it right the first time (it takes the same time to code a good or a bad function (by design). Thank you for this contrib. I'm glad to see the usual linux way to do the thing. (I was in fact asking myself of what it would have look like in linux world). -- Alexandre Leclerc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Help with DLL (using pchar, etc.)
Hi, Am Freitag, den 30.12.2005, 18:07 -0500 schrieb Alexandre Leclerc: On 12/30/05, L505 [EMAIL PROTECTED] wrote: * how can you allocate memory for a function result, on the calling side, and then free it on the calling side too? The function result is not a parameter that can be controlled by you, on the calling side. A parameter can be allocated precisely, controlled precisely, freed precisely. Now I don't have the original email - is he returning static or constant text? It may be safe. I forget now, what he was trying to do. Where is the memory being allocated for the Pchar, again? This is what looks the best to me: the calling application must passe a pointer to the DLL so that it would be filled. I'm currently doing this: function MakeMD5Hash(aValue: pchar): pchar; stdcall; var s: string; size: Integer; begin s := MD5Print(MD5String(aValue)); size := Length(s) + 1; Result := nil; GetMem(Result,size); // Result := StrAlloc(size); //Use strings; Move(Pointer(s)^, Result^, size); end; But as I see, it should be a procedure, or a function that returns an integer/boolean value. Then that would be like in a API. I need that my pascal DLL works with other languages (any of them that support stdcall and dlls). I dont know yet the best way to do that... like the calling application must 'reserve' the 32+1 chars in the string... C string handling is a mess which is why everyone avoids/wraps it. But the usual unix way at least is (ok, unix usually returns 0 or -1, not true or false, but... :)) function MakeMD5Hash(ASource: PChar; ADestination: PChar; ADestinationMaxSize: Cardinal): Boolean; stdcall; var s: string; sSize: Cardinal; begin s := MD5Print(MD5String(ASource)); sSize := Length(s) + 1; if sSize = ADestinationMaxSize then begin Move(PChar(s)^, ADestination^, sSize); Result := True; end else begin Result := False; end; end; that is _reasonably_ safe... some (i.e. snprintf) also support the especially convoluted way: function MakeMD5Hash(ASource: PChar; ADestination: PChar; ADestinationMaxSize: Cardinal): Integer; stdcall; var s: string; sSize: Cardinal; begin s := MD5Print(MD5String(ASource)); sSize := Length(s) + 1; if not Assigned(ADestination) then begin Result := sSize; end else begin if sSize = ADestinationMaxSize then begin Move(PChar(s)^, ADestination^, sSize); Result := sSize; end else begin Result := -1; end; end; end; which is safer, but for most cases overkill (depends on the use case of course). Windows sometimes has issues with freeing something that has been allocated by some other DLL, so if you go with the return a newly allocated PChar you have to either 1) be lucky and it works after all, or 2) provide a FreeMD5Hash(Destination: PChar) that does the freeing too Would that works?: procedure MakeMD5Hash(aValue, hash: pchar); stdcall; var s: string; begin s := MD5Print(MD5String(aValue)); Move(Pointer(s)^, hash^, Length(s) + 1); No, don't convert to pointer... use PChar. Other than that it looks fine for the MD5 corner case (apart from the fact that the wrapper generator for whatever language needs to know that Hash needs to be a block that is ??? bytes long - or the programmer even needs to set it manually before calling that - UGH...) end; Regards. -- Alexandre Leclerc cheers, Danny _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Help with DLL (using pchar, etc.)
What would be a practical solution... like a API solution? The calling application passing a pointer fo the result string? I'm a bit lost right now on the issue. I'll try to have a look at that after the weekend. On 12/29/05, L505 [EMAIL PROTECTED] wrote: library mydll; function MakeMD5Hash(aValue: pchar): pchar; stdcall; Pchars are not usually returned as a result, but rather passed as a parameter -- Alexandre Leclerc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Help with DLL (using pchar, etc.)
On 12/30/05, L505 [EMAIL PROTECTED] wrote: * how can you allocate memory for a function result, on the calling side, and then free it on the calling side too? The function result is not a parameter that can be controlled by you, on the calling side. A parameter can be allocated precisely, controlled precisely, freed precisely. Now I don't have the original email - is he returning static or constant text? It may be safe. I forget now, what he was trying to do. Where is the memory being allocated for the Pchar, again? This is what looks the best to me: the calling application must passe a pointer to the DLL so that it would be filled. I'm currently doing this: function MakeMD5Hash(aValue: pchar): pchar; stdcall; var s: string; size: Integer; begin s := MD5Print(MD5String(aValue)); size := Length(s) + 1; Result := nil; GetMem(Result,size); // Result := StrAlloc(size); //Use strings; Move(Pointer(s)^, Result^, size); end; But as I see, it should be a procedure, or a function that returns an integer/boolean value. Then that would be like in a API. I need that my pascal DLL works with other languages (any of them that support stdcall and dlls). I dont know yet the best way to do that... like the calling application must 'reserve' the 32+1 chars in the string... Would that works?: procedure MakeMD5Hash(aValue, hash: pchar); stdcall; var s: string; begin s := MD5Print(MD5String(aValue)); Move(Pointer(s)^, hash^, Length(s) + 1); end; Regards. -- Alexandre Leclerc _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Help with DLL (using pchar, etc.)
I have made an example for md5 hash http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=MD5Hash-Example _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Help with DLL (using pchar, etc.)
library mydll; function MakeMD5Hash(aValue: pchar): pchar; stdcall; Pchars are not usually returned as a result, but rather passed as a parameter _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
